Büyük miktarda (84 milyon satır) verinin verimli bir şekilde aktarılması

Yaklaşık 84 milyon satırım var. Bunların hepsinin aynı sunucudaki ayrı bir veritabanına aktarılması gerekiyor, daha sonra kaynak veritabanından yaklaşık 60 milyon satırı silmek için siliyorum.

84 milyon satırın hepsi aynı tabloda. Bu tablo tek başına tüm veritabanının% 90'ını oluşturmaktadır.

Yani ... Kaynak: 84 milyon satır -> 24 milyon satır Hedef: 0 satır -> 84 milyon satır

Kaynak tam kurtarma modunda çalışıyor, hedef basit çalışıyor olacak.

Bunu yapmanın en etkili yolunun ne olacağını merak ediyorum.

Plan A:

1) Hedef SEÇİNE EKLE * kaynağından

2) TRUNCATE kaynağı

3) Kaynağa SEÇİNİZ SEÇİN * HEDEF NEREDEN keep_condition = 1

B planı:

1) Kaynak veritabanı yedeklemesini hedef veritabanı olarak geri yükleme

2) Hedef veritabanında gerekli olanlar dışında her tabloyu bırakın

3) TRUNCATE kaynağı

4) Kaynağa SEÇİNİZ SEÇİN * HEDEF NEREDEN NEREDE keep_condition = 1

Plan C:

1) Hedef SEÇİNE EKLE * kaynağından

2) Kaynağı NEREDEN SİL keep_condition = 0

veya başka bir şey?

Teşekkürler

Bunu ekleyeceğim, ancak buna yaklaşmaya karar verirseniz, bu işlemleri toplu hale getirmeniz gerekecek . Son zamanlarda bağlantılı makalede çok iyi şanslar yaşadım ve gördüğüm çoğu toplu çözümlerin aksine dizinlerden yararlanma şeklini takdir ediyorum.

En az günlüğe kaydedilmiş olsa bile, bunlar büyük işlemlerdir ve anormal günlük büyümesinin (VLF'ler, kesilme, sağ boyutlandırma vb.) Sonuçlarıyla uğraşmak için çok fazla zaman harcayabilirsiniz.

Teşekkürler

"Verimli" günlük dosyası kullanımı, G / Ç performansı, CPU zamanı veya yürütme zamanı için geçerli olabilir.

Bir günlük perspektiften oldukça verimli olacak şekilde, minimum düzeyde günlüklenmiş bir işlem gerçekleştirmeye çalışacağım. Bu, bazı yürütme zamanlarına bonus kazandırmalıdır. Tempdb alanınız varsa, aşağıdakiler sizin için işe yarayabilir.

CREATE TABLE #temp;
ALTER source -> BULK_LOGGED recovery model

BEGIN TRANSACTION;

    INSERT INTO dest SELECT FROM source;
    INSERT INTO #temp SELECT FROM source WHERE keep_condition=1;
    TRUNCATE TABLE source;
    INSERT INTO source SELECT FROM #temp;

COMMIT TRANSACTION;

ALTER source -> FULL recovery model
DROP TABLE #temp;

En az günlüğe kaydedilmiş bir işlemin gerçekleşmesi için, şu anda çalışan hiçbir yedekleme, BULK_LOGGEDkurtarma moduna ayarlanmış veritabanı ve dizinlerinize bağlı olarak, hedef tablonun boş olması gibi bir takım koşulların doğru olması gerekir. Bu davranışın bir kısmı da SQL Server 2005'ten 2008'e değiştirildi (geliştirildi).

Daha sonra, tablonuzun ve verilerinizin özelliklerini bilmeden, diğer seçeneklerinizden herhangi biri daha iyi performans gösterebilir. Kullanmayı deneyin

SET STATISTICS IO ON;
SET STATISTICS TIME ON;

.. ve hangisinin en iyi olduğunu görün.

DÜZENLEME : Toplu günlüğe kaydetme işlemleri gerçekleştirirken, zamanında geri yükleme yeteneğine ihtiyacınız varsa ve veritabanında diğer etkinliklerin devam ettiğinden şüpheleniyorsanız işlemden önce ve sonra bir yedek (tam veya işlem günlüğü) yaptığınızdan emin olun. aynı zamanda ETL işiniz de çalışıyor.

Bir süre önce minimal giriş işlemleri hakkında bir blog yazısı yazdım , orada diğer yazılara ve belgelere bağlantılar var.

Neden BCP değil?

1. Sourcedb'yi yedekle
2. Sourcedb öğesini toplu olarak günlüğe kaydet

3. Komut istemini aç

4. bcp server.sourcedb.table out Filename.flt -T -c

5. bcp "SELECT * FROM sourcedb.table WHERE keep_condition = 1" queryout Filename2.flt -T -c

6. bcp Server.destinationdb.table in Filename.flt -T -c -b1000

7. verileri kontrol et

8. SSMS'den Sourcedb tablosunu kısalt
9. bcp server.sourcedb.table in Filename2.flt -T -c -b1000
10. Sourcedb öğesini tam olarak değiştir

Önceden ve sonra tam veritabanı yedeği veya t-log yedeklemesi olmadan kurtarma modelini değiştirmenizi tavsiye etmeyin . BULK_LOGGED kurtarma modelinin özelliklerinden biri, toplu günlüğe kaydedilen işlemleri içeren t günlükleri için zaman içinde kurtarma gerçekleştirme yeteneğini kaybetmenizdir. Klasik senaryo: her gece tam yedekleme, saatlik t-günlük yedekleri. Kurtarma modelini toplu olarak günlüğe kaydedersiniz ve işleminizi başlatırsınız. Bir şeyler ters gidiyor ve işlem geri dönüyor (ya da bir tane kullanmadınız). Ancak, veritabanında başka neler olup bittiğinden emin değilsiniz, böylece bilinen iyi bir noktaya geri yüklemek istiyorsunuz.

Ne zaman geri dönebilirsiniz? Gelmez Son saatlik t-günlük yedeği değil toplu oturum işlemleri içerir potansiyel işlemlerin n dakikada kaybediyor. Kurtarma modelini değiştirmeden önce tam yedekleme veya t günlük kaydı yedeği bir geri dönüş noktası oluşturur. Hangisini seçtiğiniz RTO'nuza bağlıdır.

Bölümleri tablodan çıkarmak, büyük veri parçalarını tablodan kaldırmanın gerçekten hızlı ve kaynak açısından verimli bir yoludur. Bu tablo, kaynak / hedef bölgenizi destekleyecek şekilde bölümlenmiş olsaydı, yanıt bir kopyayı geri yüklemek, gereksiz tabloları ve yedek bölümleri hedeften bırakmak ve tamamlayıcı bölümleri kaynaktan bırakmak olacaktır.

Bununla birlikte, bölümlemeyi etkinleştirmenin maliyeti, bunu genel olarak daha pahalı bir işlem haline getirebilir.