Optimisation des performances BCP pour les données BLOB

Je suis en train de planifier la migration en direct d'une base de données de 2 To vers des tables partitionnées. Le système est en gros un magasin de documents, la majorité de l'espace étant alloué à des LOB compris entre 50 Ko et 500 Ko, avec un petit pourcentage dans la plage de 500 Ko à 1 Mo. Une partie de la migration impliquera des données BCPing de l'ancienne à la nouvelle base de données.

Le BCP est l'approche privilégiée car la division actuelle / historique dans les données permet d'extraire les données plus anciennes par étapes (pendant les périodes plus calmes) avant un changement final, minimisant ainsi l'impact sur le système en direct. Le volume de données et la disponibilité du stockage empêchent une reconstruction in situ sur un schéma de partition .

Je pense qu'il y a peut-être des gains de performances à réaliser en expérimentant avec KILOBYTES_PER_BATCH plutôt qu'avec ROWS_PER_BATCH, en raison du contenu BLOB. Il est suggéré dans la documentation BCP que SQL peut optimiser les opérations en fonction de cette valeur.

Ce que je ne trouve pas, c'est des indications sur la nature de ces optimisations ou où commencer mes tests. En l'absence de suggestions, je vais essayer de petites séries à 4/8/16/32/64 Mo pour commencer.

Il est probable que certains gains découlent de la modification de la taille des paquets (paramètre BCP -a, plutôt que des paramètres au niveau du serveur), mais je suis enclin à faire passer cela au maximum 65535, sauf si quelqu'un a une approche plus formelle.

Ce n'est pas une réponse directe à votre question, mais il y a quelques articles dont vous pourriez bénéficier en les lisant (au cas où vous ne les auriez pas trouvés en premier :-)). Il s'agit de charger de nombreuses données à l'aide de bcp / copie en bloc. Je les ai tous lus et je n'ai rien trouvé de détaillé concernant KILOBYTES_PER_BATCH, ils utilisent tous ROWS_PER_BATCH, mais je suis sûr que vous trouverez d'autres informations utiles.

• Charger 1 To en moins d'une heure (de l'équipe SQL CAT) - liste des conseils d'ici (citation):

  • Exécutez autant de processus de chargement que vous avez de CPU disponibles. Si vous avez 32 processeurs, exécutez 32 charges parallèles. Si vous avez 8 CPU, exécutez 8 charges parallèles.
  • Si vous contrôlez la création de vos fichiers d'entrée, rendez-les d'une taille qui est également divisible par le nombre de threads de chargement que vous souhaitez exécuter en parallèle. Assurez-vous également que tous les enregistrements appartiennent à une seule partition si vous souhaitez utiliser la stratégie de partition de commutateur.
  • Utilisez l'insertion BULK au lieu de BCP si vous exécutez le processus sur la machine SQL Server.
  • Utilisez le partitionnement de table pour gagner encore 8 à 10%, mais uniquement si vos fichiers d'entrée sont GARANTIS pour correspondre à votre fonction de partitionnement, ce qui signifie que tous les enregistrements d'un fichier doivent se trouver dans la même partition.
  • Utilisez TABLOCK pour éviter le verrouillage de ligne à la fois.
  • Utilisez ROWS PER BATCH = 2500, ou quelque chose comme ceci si vous importez plusieurs flux dans une même table.

• 10 meilleures pratiques pour la construction d'un entrepôt de données relationnelles à grande échelle (de l'équipe SQL CAT) - conseils (devis):

  • Utilisez le modèle de récupération SIMPLE ou BULK LOGGED pendant le chargement initial des données.
  • Créez la table de faits partitionnée avec l'index clusterisé.
  • Créez des tables de transfert non indexées pour chaque partition et séparez les fichiers de données source pour remplir chaque partition.
  • Remplissez les tables intermédiaires en parallèle (utilisez plusieurs tâches BULK INSERT, BCP ou SSIS)
  • Créez un index cluster sur chaque table intermédiaire, puis créez les contraintes CHECK appropriées.
  • COMMUTEZ toutes les partitions dans la table partitionnée.
  • Créez des index non clusterisés sur la table partitionnée.

• Le Guide des performances de chargement des données (de l'équipe SQL CAT)

• Chargement de données en masse dans une table partitionnée - Article sur les meilleures pratiques SQL Server ( article Technet)

• Étude de cas de charge en bloc incrémentielle SQL Server 2000 (article Technet)

• Leçons apprises et résultats d'un grand POC accéléré (de l'équipe SQL CAT)

• Conseils d'optimisation des performances pour SQL Server BCP (par Brad McGehee)

• Impact sur les performances: trouver la taille de lot la plus optimale (par Linchi Shea)

et les références MSDN évidentes:

• Gestion des lots pour l'importation en bloc
• Gestion des tailles de lot de copie en masse
• Considérations relatives aux performances de la copie en bloc
• Lignes directrices pour optimiser l'importation en bloc
• Optimisation des performances d'importation en masse

Dans mon expérience personnelle, j'ai réussi à effectuer un chargement de données rapide en utilisant une charge parallèle et des tests avec plusieurs tailles de lot. Je suppose que seuls les tests personnels vous conviendront. J'espère que vous trouverez de bons conseils dans les références.