Modifications explicites de l'état de verrouillage hiérarchique et implications sur les performances

Dans un environnement Db2 pureScale®, les tables ordinaires, les tables partitionnées par plage ou les index partitionnés existent dans l'état SHARED, dans l'état NOT_SHARED ou en transition entre ces deux états.

Objets entrant ou déjà à l'état NOT_SHARED

Une table peut entrer l'état NOT_SHARED suite à l'activité suivante:
  • Si une opération INSERT, UPDATE ou DELETE ou une analyse est effectuée sur une table.
  • Si une table est partitionnée par plages de valeurs, une partition de données accessible à l'aide des actions précédentes peut passer à l'état NOT_SHARED, alors que la table logique n'est pas affectée.
  • L'opération CREATE INDEX dans les index non partitionnés déclenche une transition d'état NOT_SHARED de la table logique et des ancrages d'index. Si ces index peuvent entrer dans l'état NOT_SHARED indépendamment des partitions de données.

Comme les tables à l'état NOT_SHARED s'exécutent dans un mode similaire à Db2 Enterprise Server Edition, elles possèdent également des propriétés similaires aux tables Db2 Enterprise Server Edition . Lorsqu'une table standard est à l'état NOT_SHARED, tous ses objets de table, tels que data, index, LONG, LOB, XDA, sont également à l'état NOT_SHARED. Cependant, seuls les verrous de table et de ligne se comportent comme à l'état NOT_SHARED.

Une table partitionnée par spécification de plages de valeurs peut permettre à ses partitions d'entrer ou de quitter l'état NOT_SHARED indépendamment l'une de l'autre, ce qui est avantageux car toutes les transactions n'accéderait pas à toutes les partitions d'une table. Ainsi, l'indépendance de la partition permet aux membres d'accéder à différentes partitions sans conflit sur le verrou DATA_SHARING. De plus, tous les objets de table (tels que les index partitionnés) au sein d'une partition héritent également des propriétés, comme dans le cas d'une table standard.
Remarque: Les index non partitionnés d'une table partitionnée doivent tous entrer ou quitter l'état NOT_SHARED simultanément. Cette action simultanée est due au fait que tous les objets d'ancrage d'index sont sous la protection d'un verrou de table logique unique. En d'autres termes, lorsqu'un index non partitionné est accédé, son verrou de table logique passe à l'état NOT_SHARED, ce qui fait passer tous les index non partitionnés à l'état NOT_SHARED également. Ce comportement n'a aucun effet sur les partitions car elles possèdent leurs propres verrous de partition pour la protection.

Objets quittant l'état NOT_SHARED

Une table quitte l'état NOT_SHARED suite à l'activité suivante:
  • Tout accès à la table à partir d'un autre membre
  • Suppression de la désactivation de la table ou de la base de données
  • Partition ATTACH ou DETACH pour une table partitionnée

Tout accès à une table à partir d'un autre membre entraîne une sortie de l'état NOT_SHARED sur le premier membre pour permettre au serveur de base de données d'accorder un verrou sur la table à l'autre membre Db2® serveur de base de données d'accorder un verrou sur la table à l'autre membre. Lorsqu'une table passe de l'état NOT_SHARED à l'état SHARED, son verrou de table est maintenu en mode Z (mode super exclusif) jusqu'à ce que tous les verrous de page et de ligne soient enregistrés sur le gestionnaire de verrouillage global (GLM) et que toutes les pages de pool de mémoire tampon modifiées soient écrites dans le pool de mémoire tampon de groupe (GBP). La procédure peut être longue.

Le serveur de base de données Db2 peut détecter lorsqu'une transition vers l'état NOT_SHARED n'est pas optimale et il évite le changement d'état.

Pour la reprise sur incident de membre, la table entière n'est pas disponible tant que la reprise n'est pas terminée. Lorsque EHL est activé, la reprise sur incident des membres prend un temps similaire à la reprise sur incident pour une base de données Db2 Enterprise Server Edition . Le temps est nécessaire car les pages de données modifiées ne sont pas mises en cache dans la fonction de mise en cache (CF), mais uniquement dans le pool de mémoire tampon local. Par conséquent, les pages modifiées doivent être régénérées en rélisant les enregistrements de journal. Utilisez le paramètre de configuration de la base de données page_age_trgt_mcr pour contrôler la durée pendant laquelle les pages restent en mémoire tampon dans le pool de mémoire tampon local.

La sortie de EHL n'est pas immédiate et implique une communication CF pour les verrous et les pages de la table. La mémoire et le temps requis pour cette opération sont proportionnels au nombre de verrous et de pages détenus pour l'objet dans le pool de mémoire tampon. Une petite table ne prend généralement que quelques secondes pour quitter EHL. Cependant, une table très grande peut prendre plusieurs minutes pour quitter EHL.

Dans de très rares cas, il est possible que le GLM soit plein lors de l'exit EHL et que vous ne puissiez pas envoyer tous les verrous requis à la fonction CF. Cela empêchera l'exit EHL de se terminer. Si cette condition se produit, les autres membres ne pourront pas accéder à cette table tant que l'exit EHL ne sera pas terminé. Cela peut entraîner des événements de délai de verrouillage sur d'autres membres accédant à la table. Lorsque cette condition est détectée et si les paramètres de configuration de base de données CF_GBP_SZ et CF_LOCK_SZ sont tous deux configurés sur AUTOMATIC, le serveur de base de données Db2 tente d'échanger de la mémoire du pool de mémoire tampon de groupe vers le GLM, pour permettre l'enregistrement des verrous. La taille de la GBP sera légèrement réduite et la taille de la GLM sera augmentée de ce montant. Il existe une limite sur la quantité de mémoire GBP qui peut être échangée de cette manière. Toutefois, si les paramètres de configuration de base de données CF_GBP_SZ an CF_LOCK_SZ ne sont pas configurés sur AUTOMATIC, ou si ces actions ne libèrent pas suffisamment de mémoire GLM pour permettre à l'exit EHL de se terminer dans les 40 secondes suivant la détection de cette condition, toutes les applications détenant le verrou qui ne peut pas être envoyé au GLM seront forcées. Le fait de forcer les applications permet de libérer le verrou de sorte qu'il n'ait pas besoin d'être envoyé à la fonction CF, ce qui permet à l'exit EHL de continuer. ADM1504 sera consigné lorsque ce commerce de mémoire aura lieu et ADM1503 sera consigné pour chaque application forcée.

Prise en compte du délai de verrouillage en raison du temps nécessaire pour quitter l'état NOT_SHARED

Il peut être difficile de prévoir le temps nécessaire aux objets pour quitter l'état NOT_SHARED. Cela dépend du nombre de pages et de verrous utilisés à la fois. Une longue durée peut entraîner une erreur de délai de verrouillage indésirable (SQL0911N). Avec l'édition de Db2 11.5.8, la variable de registre DB2_AVOID_TIMEOUT_ON_EHL_LOCKS peut être définie pour empêcher une application d'expirer lorsqu'elle attend que des objets quittent l'état NOT_SHARED.

Surveillance de EHL

EHL peut être surveillé à l'aide des moniteurs et des API suivants:
  • Moniteur d'événements LOCK WAIT
  • API d'administration MON_GET_DATABASE ()
  • API d'administration MON_GET_TABLE ()
  • API d'administration MON_GET_LOCKS ()
  • MON_GET_APPL_LOCKWAIT ()-API d'administration