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.