Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Vous pouvez gérer le comportement spécifique des opérations d’écriture simultanées en décidant quand et comment exécuter différents types de commandes. Les commandes suivantes sont pertinentes pour cette discussion :
-
Les commandes COPY, qui effectuent les chargements (initiaux ou incrémentiels)
-
Les commandes INSERT qui ajoutent une ou plusieurs lignes à la fois
-
Les commandes UPDATE, qui modifient les lignes existantes
-
Les commandes DELETE, qui suppriment des lignes
Les opérations COPY et INSERT sont de pures opérations d'écriture. Les opérations DELETE et UPDATE sont des opérations de lecture/écriture (pour que les lignes soient supprimées ou mises à jour, elles doivent d'abord être lues). Les résultats des opérations d’écriture simultanées dépendent des commandes spécifiques qui sont exécutées simultanément.
Les opérations UPDATE et DELETE se comportent différemment, car elles s’appuient sur une table initiale lue avant toute écriture. Étant donné que les transactions simultanées sont invisibles les unes pour UPDATEs les autres, les deux DELETEs doivent lire un instantané des données du dernier commit. Lorsque la première opération UPDATE ou DELETE libère son verrou, la deuxième opération UPDATE ou DELETE doit déterminer si les données qu’il va utiliser sont potentiellement obsolètes. Elles ne le sont pas, car la deuxième transaction n’obtient pas son instantané des données tant que la première transaction n’a pas libéré son verrou.
Situation d'impasse potentielle pour les transactions d'écriture simultanées impliquant plusieurs tables
Lorsque les transactions impliquent la mise à jour de plusieurs tables, il est toujours possible que des transactions exécutées simultanément soient bloquées lorsqu'elles essaient toutes deux d'écrire dans le même ensemble de tables. Une transaction libère tous ses verrous de table en même temps lorsqu'elle est validée ou annulée ; elle ne renonce pas aux verrous un par un.
Par exemple, supposons que les transactions T1 et T2 commencent approximativement en même temps. Si T1 commence à écrire dans la table A et T2 commence à écrire dans la table B, les deux transactions peuvent se poursuivre sans conflit. Cependant, si T1 finit d'écrire dans la table A et doit commencer à écrire dans la table B, il ne pourra pas continuer car T2 maintient toujours le verrou B. De même, si T2 finit d'écrire dans la table B et doit commencer à écrire dans la table A, il ne pourra pas non plus continuer car T1 maintient toujours le verrou A. Aucune transaction ne peut libérer ses verrous tant que toutes ses opérations d'écriture n'ont pas été validées, aucune des transactions ne peut continuer. Pour éviter ce type de blocage, vous devez planifier avec soin les opérations d'écriture simultanées. Par exemple, vous devez toujours mettre à jour les tables dans le même ordre des transactions et, si vous spécifiez des verrous, verrouillez les tables dans le même ordre avant d’effectuer les opérations DML.
Situation de blocage potentielle pour les transactions d'écriture simultanées impliquant une seule table
Dans un environnement d'isolation de snapshots, des blocages peuvent se produire lors de l'exécution de transactions d'écriture simultanées sur la même table. Le blocage de l'isolation des instantanés se produit lorsque des instructions INSERT ou COPY simultanées partagent un verrou et progressent, et qu'une autre instruction doit effectuer une opération (opération UPDATE, DELETE, MERGE ou DDL) nécessitant un verrou exclusif sur la même table.
Réfléchissez au scénario suivant :
Transaction 1 (T1) :
INSERT/COPY INTO table_A;Transaction 2 (T2) :
INSERT/COPY INTO table_A;
<UPDATE/DELETE/MERGE/DDL statement> table_AUn blocage peut se produire lorsque plusieurs transactions comportant des opérations INSERT ou COPY sont exécutées simultanément sur la même table avec un verrou partagé, et que l'une de ces transactions suit son opération d'écriture pure par une opération nécessitant un verrou exclusif, telle qu'une instruction UPDATE, MERGE, DELETE ou DDL.
Pour éviter les blocages dans ces situations, vous pouvez séparer les instructions nécessitant un verrouillage exclusif (UPDATE/MERGE/DELETE/DDL statements) to a different transaction so that any INSERT/COPY statements can progress simultaneously, and the statements requiring exclusive locks can execute after them. Alternatively, for transactions with INSERT/COPY statements and MERGE/UPDATE/MERGEinstructions) sur la même table. Vous pouvez inclure une logique de nouvelle tentative dans vos applications pour contourner les blocages potentiels.
