Optimieren der BCP-Leistung für BLOB-Daten


13

Ich plane die Livemigration einer 2-TB-Datenbank in partitionierte Tabellen. Das System ist im Großen und Ganzen ein Dokumentenspeicher, bei dem der größte Teil des Speicherplatzes LOBs zwischen 50 KB und 500 KB zugewiesen wird, wobei ein kleiner Prozentsatz im Bereich von 500 KB bis 1 MB liegt. Ein Teil der Migration umfasst das BCPing von Daten aus der alten in die neue Datenbank.

BCP ist der bevorzugte Ansatz, da die aktuelle / historische Aufteilung der Daten das schrittweise Extrahieren der älteren Daten (in ruhigeren Zeiträumen) vor einem endgültigen Wechsel ermöglicht, wodurch die Auswirkungen auf das Live-System minimiert werden. Das Datenvolumen und die Verfügbarkeit des Speichers schließen eine in-situ-Wiederherstellung eines Partitionsschemas aus .

Ich vermute, dass aufgrund des BLOB-Inhalts einige Leistungssteigerungen durch Experimentieren mit KILOBYTES_PER_BATCH statt mit ROWS_PER_BATCH zu verzeichnen sind. In der BCP-Dokumentation wird vorgeschlagen, dass SQL die Vorgänge basierend auf diesem Wert optimieren kann.

Was ich nicht finden kann, ist eine Anleitung zur Art dieser Optimierungen oder wo ich mit dem Testen beginnen soll. In Abwesenheit von Vorschlägen werde ich versuchen, kurze Läufe an 4/8/16/32 / 64mb-Grenzen zu starten.

Wahrscheinlich hat das Ändern der Paketgröße (BCP -a-Parameter anstelle der Einstellung auf Serverebene) einige Vorteile, aber ich bin geneigt, dies auf das Maximum von 65535 zu erhöhen, sofern niemand einen formelhafteren Ansatz verfolgt.

Antworten:


12

Dies ist keine direkte Antwort auf Ihre Frage, aber es gibt einige Artikel, die Sie lesen sollten (falls Sie sie nicht zuerst gefunden haben :-)). Hier geht es darum, viele Daten mithilfe von BCP / Massenkopien zu laden. Ich habe sie alle gelesen und keine detaillierten Informationen zu KILOBYTES_PER_BATCH gefunden. Sie verwenden alle ROWS_PER_BATCH, aber ich bin sicher, dass Sie andere nützliche Informationen finden werden.

  • Laden Sie 1 TB in weniger als 1 Stunde (vom SQL CAT-Team) - Liste der Ratschläge von hier (Zitat):

    • Führen Sie so viele Ladeprozesse aus, wie CPUs verfügbar sind. Wenn Sie 32 CPUs haben, führen Sie 32 parallele Lasten aus. Wenn Sie 8 CPUs haben, führen Sie 8 parallele Lasten aus.
    • Wenn Sie die Kontrolle über die Erstellung Ihrer Eingabedateien haben, legen Sie eine Größe fest, die gleichmäßig durch die Anzahl der Ladethreads teilbar ist, die Sie parallel ausführen möchten. Stellen Sie außerdem sicher, dass alle Datensätze zu einer Partition gehören, wenn Sie die Switch-Partitionsstrategie verwenden möchten.
    • Verwenden Sie BULK insert anstelle von BCP, wenn Sie den Prozess auf dem SQL Server-Computer ausführen.
    • Verwenden Sie die Tabellenpartitionierung, um weitere 8-10% zu erzielen. Dies ist jedoch nur dann der Fall, wenn Ihre Eingabedateien GARANTIERT sind, um mit Ihrer Partitionierungsfunktion übereinzustimmen. Dies bedeutet, dass sich alle Datensätze in einer Datei in derselben Partition befinden müssen.
    • Verwenden Sie TABLOCK, um das gleichzeitige Sperren von Zeilen zu vermeiden.
    • Verwenden Sie ROWS PER BATCH = 2500 oder etwas in der Nähe davon, wenn Sie mehrere Streams in eine Tabelle importieren.
  • Top 10 Best Practices für den Aufbau eines großen relationalen Data Warehouse (vom SQL CAT-Team) - Hinweise (Zitat):

    • Verwenden Sie beim erstmaligen Laden der Daten das Wiederherstellungsmodell SIMPLE oder BULK LOGGED.
    • Erstellen Sie die partitionierte Faktentabelle mit dem Clustered-Index.
    • Erstellen Sie nicht indizierte Staging-Tabellen für jede Partition und separate Quelldatendateien zum Auffüllen jeder Partition.
    • Füllen Sie die Staging-Tabellen parallel auf. (Verwenden Sie mehrere BULK INSERT-, BCP- oder SSIS-Tasks.)
    • Erstellen Sie einen Clustered-Index für jede Staging-Tabelle und erstellen Sie dann die entsprechenden CHECK-Einschränkungen.
    • SCHALTEN Sie alle Partitionen in die partitionierte Tabelle.
    • Erstellen Sie nicht gruppierte Indizes für die partitionierte Tabelle.
  • Das Handbuch zum Laden von Daten (vom SQL CAT-Team)

  • Laden von Massendaten in eine partitionierte Tabelle - Best Practices-Artikel zu SQL Server (Technet-Artikel)

  • Inkrementelle Bulk-Last-Fallstudie für SQL Server 2000 (Technet-Artikel)

  • Erkenntnisse und Erkenntnisse aus einem großen Fast-Track-POC (vom SQL CAT-Team)

  • Tipps zur Leistungsoptimierung für SQL Server BCP (Von Brad McGehee)

  • Auswirkung auf die Leistung: Ermitteln der optimalen Chargengröße (von Linchi Shea)

und die offensichtlichen MSDN-Verweise:

Nach meiner persönlichen Erfahrung ist es mir gelungen, durch paralleles Laden und Testen mit mehreren Chargengrößen ein schnelles Laden von Daten durchzuführen. Ich denke, dass nur persönliche Tests zu Ihnen passen. Hoffentlich finden Sie in den Referenzen einige gute Hinweise.


Vielen Dank, Marian. Ich habe ein paar neue Funde aus dieser umfassenden Liste mit einem Lesezeichen versehen. Als einmalige Aufgabe sind viele der inkrementellen / verfeinernden Schritte nicht so nützlich, aber es gibt viele Tipps, die ich verwenden kann.
Mark Storey-Smith

Ja, ich habe das Gefühl, dass auch ich eine einmalige Aufgabe war und einige nützliche Dinge in der Liste gefunden habe. Es ist aber eine tolle Aufgabe :-). Sie können auch eine kleine .NET-Anwendung ausführen (wenn Sie mit .NET vertraut sind), wie in einem anderen Artikel von Linchi Shea beschrieben: Leistungseinbußen: Das optimalste Einfügeskript kann BulkCopy nicht schlagen . Vielleicht findest du dasselbe wie er :-).
Marian

Da es keine BLOB-spezifischen Richtlinien für BCP in freier Wildbahn zu geben scheint, bezeichne ich Ihre sehr gründliche Antwort als akzeptiert. Danke noch einmal.
Mark Storey-Smith

Es tut mir leid, dass ich Ihnen nicht weiterhelfen konnte, aber ich hoffe, Sie haben etwas Nützliches darin gefunden.
Marian
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.