Gestion des tailles de lot de copie en bloc
L'objectif principal d'un lot dans des opérations de copie en bloc est de définir la portée d'une transaction. Si aucune taille de lot n'est définie, les fonctions de copie en bloc considèrent une copie en bloc entière comme une transaction. Si une taille de lot est définie, chaque lot constitue alors une transaction validée à la fin de l'exécution de ce lot.
Si une copie en bloc est effectuée sans taille de lot et qu'une erreur est détectée, la copie en bloc entière est restaurée. La récupération d'une copie en bloc de longue durée peut prendre un certain temps. Lorsqu'une taille de lot est définie, la copie en bloc considère chaque lot comme une transaction et valide chaque lot. Si une erreur est détectée, seul le dernier lot en attente doit être restauré.
La taille de lot peut également affecter la surcharge de verrouillage. Au cours d'une copie en bloc sur SQL Server, l'indicateur TABLOCK peut être spécifié à l'aide de bcp_control pour acquérir un verrou de table au lieu de verrous de ligne. Le verrou de table unique peut être maintenu avec une charge minimale pour une opération de copie en bloc entière. Si TABLOCK n'est pas spécifié, les verrous sont maintenus sur des lignes individuelles et la charge liée à la maintenance de tous les verrous pour la durée de la copie en bloc peut ralentir les performances. Les verrous étant uniquement maintenus pour la durée d'une transaction, la spécification d'une taille de lot résout ce problème en générant périodiquement une validation qui libère les verrous actuellement maintenus.
Le nombre de lignes constituant un lot peut avoir des effets significatifs sur les performances lors de la copie en bloc d'un grand nombre de lignes. Les recommandations pour la taille de lot varient selon le type de copie en bloc effectuée.
Lorsque vous effectuez une copie en bloc vers SQL Server, spécifiez l'indicateur de copie en bloc TABLOCK et définissez une taille de lot importante.
Lorsque TABLOCK n'est pas spécifié, limitez les tailles de lot à 1 000 lignes.
Lorsque vous effectuez une copie en bloc dans d'un fichier de données, la taille de lot est spécifiée en appelant bcp_control avec l'option BCPBATCH avant d'appeler bcp_exec. Lorsque vous effectuez une copie en bloc à partir de variables de programme à l'aide de bcp_bind et bcp_sendrow, la taille de lot est contrôlée en appelant bcp_batch après avoir appelé bcp_sendrow x fois, où x représente le nombre de lignes dans un lot.
Outre la spécification de la taille d'une transaction, les lots affectent également le moment où les lignes sont envoyées au serveur via le réseau. Les fonctions de copie en bloc mettent normalement en cache les lignes de bcp_sendrow jusqu'à ce qu'un paquet réseau soit rempli, puis envoient le paquet complet au serveur. Toutefois, lorsqu'une application appelle bcp_batch, le paquet actuel est envoyé au serveur qu'il ait été rempli ou non. Le fait d'utiliser une taille de lot très réduite peut ralentir les performances si cela aboutit à l'envoi de nombreux paquets partiellement remplis au serveur. Par exemple, le fait d'appeler bcp_batch après chaque bcp_sendrow entraîne l'envoi de chaque ligne dans un paquet séparé et, à moins que les lignes ne soient très importantes, entraîne un gaspillage de l'espace dans chaque paquet. La taille par défaut de paquets réseau pour SQL Server est de 4 Ko, bien qu'une application puisse modifier cette taille en appelant SQLSetConnectAttr et en spécifiant l'attribut SQL_ATTR_PACKET_SIZE.
Le fait que chaque lot soit considéré comme un jeu de résultats en attente jusqu'à ce qu'il se termine par bcp_batch constitue un autre effet secondaire. Si des autres opérations sont tentées sur un handle de connexion pendant qu'un lot est en attente, le pilote ODBC SQL Server Native Client émet une erreur avec SQLState = "HY000" et la chaîne de message d'erreur suivante :
"[Microsoft][SQL Server Native Client] Connection is busy with
results for another hstmt."