Écriture de transactions performantes
Il est important de réduire la durée des transactions au minimum. Au démarrage d'une transaction, le SGBD, autrement dit le système de gestion de base de données, doit utiliser de nombreuses ressources pour toute la durée de la transaction afin de préserver les propriétés ACID (atomicité, cohérence, isolement et durabilité) de la transaction. En cas de modification des données, les lignes modifiées doivent être protégées par des verrous exclusifs qui empêchent les autres transactions de lire ces lignes, et ces verrous doivent être maintenus jusqu'à ce que la transaction soit validée ou restaurée. En fonction des paramètres de niveau d'isolement des transactions, les instructions SELECT peuvent activer des verrous qui doivent être maintenus jusqu'à la restauration ou la validation de la transaction. Dans le cas de systèmes comprenant de nombreux utilisateurs, les transactions doivent être aussi courtes que possible afin de limiter le blocage des ressources par les verrous pour des connexions concurrentes. Des transactions longues et peu performantes peuvent ne pas poser de problème pour un nombre réduit d'utilisateurs, mais elles sont inacceptables dans le cas d'un système comprenant plusieurs milliers d'utilisateurs.
Directives de codage
Vous trouverez ci-dessous des directives vous permettant de coder des transactions performantes :
- Évitez l'entrée de données par l'utilisateur au cours d'une transaction.
Effectuez toutes les entrées de données par l'utilisateur avant le début d'une transaction. Si d'autres données doivent être entrées par l'utilisateur au cours d'une transaction, restaurez la transaction en cours et redémarrez-la après l'entrée des données. Même si les utilisateurs répondent immédiatement, le temps de réaction d'un être humain est incomparablement plus lent que la vitesse d'un ordinateur. Toutes les ressources utilisées par la transaction sont verrouillées pendant un temps extrêmement long, ce qui peut entraîner des problèmes de blocage du système. Si les utilisateurs ne répondent pas, la transaction reste active et verrouille les ressources critiques jusqu'à ce qu'ils répondent, ce qui peut prendre plusieurs minutes, voire des heures. - Si possible, n'ouvrez pas une transaction alors que vous êtes en train de consulter des données.
Ne démarrez pas de transaction avant que l'analyse préliminaire des données soit terminée. - Limitez la durée de la transaction autant que possible.
Lorsque vous connaissez les modifications effectuées, démarrez une transaction, exécutez les instructions de modification, puis validez-les ou restaurez-les immédiatement. N'ouvrez pas la transaction tant que ce n'est pas nécessaire. - Pour réduire les blocages, envisagez d'utiliser un niveau d'isolement basé sur le versioning de ligne pour les requêtes en lecture seule. Pour plus d'informations, consultez Utilisation de niveaux d'isolement basés sur la gestion de la version des lignes.
- Utilisez avec discernement les niveaux d'isolement de transaction inférieurs.
De nombreuses applications peuvent être facilement codées pour utiliser le niveau d'isolement de lecture validée. Toutes les transactions ne nécessitent pas l'utilisation d'un niveau d'isolement de transaction sérialisable. - Utilisez les options de concurrence d'accès des curseurs les plus faibles, telles que les options de concurrence d'accès optimistes.
Dans un système pour lequel la probabilité de modifications concurrentes est faible, le temps supplémentaire nécessaire pour traiter une erreur causée par la modification de vos données par un autre utilisateur après que vous les ayez lues peut être inférieur à celui qu'entraîne le verrouillage systématique des lignes au moment de leur lecture. - Limitez autant que possible le volume de données auxquelles accède votre transaction.
Le nombre de lignes verrouillées est ainsi limité, ce qui limite également le blocage des transactions.
Prévention des problèmes de concurrence et de ressources
Pour prévenir les problèmes de concurrence et de ressources, soyez minutieux dans la gestion des transactions implicites. Dans les transactions implicites, l'instruction Transact-SQL qui suit une instruction COMMIT ou ROLLBACK démarre automatiquement une nouvelle transaction. Une nouvelle transaction risque ainsi d'être ouverte alors que l'application consulte des données, ou qu'elle attend une entrée de données par l'utilisateur. Après avoir terminé la dernière transaction nécessaire à la protection des modifications, désactivez les transactions implicites jusqu'à ce qu'une transaction doive à nouveau protéger les modifications de données. Cette procédure permet à Moteur de base de données SQL Server d'utiliser le mode autocommit lorsque l'application consulte des données ou attend une entrée de données par l'utilisateur.
De plus, lorsque le niveau d'isolement de capture instantanée est activé, même si une nouvelle transaction ne contient pas de verrous, une exécution très longue empêche la suppression des anciennes versions dans tempdb.
Voir aussi
Concepts
Transactions (moteur de base de données)