Enregistrement complet du processus de résolution des blocages DB2

DB2 est principalement utilisé dans les systèmes d'applications à grande échelle. Il a une bonne évolutivité et peut tout prendre en charge, du mainframe aux environnements mono-utilisateur. DB2 offre un niveau élevé d'utilisation, d'intégrité, de sécurité et de récupérabilité des données. Cet article présente principalement l'enregistrement complet du processus de résolution des blocages DB2. La cause du blocage dans cet article est l'instruction select. Le processus de traitement est assez difficile. Les amis dans le besoin peuvent se référer à

<.> dans l'environnement de production La base de données utilisée est DB2. Cependant, un étrange phénomène de blocage est apparu fréquemment récemment : une certaine instruction select sql se bloque toujours.

Selon l'expérience passée, les instructions SQL de mise à jour telles que update/delete provoquent généralement des problèmes de blocage. De plus, cette instruction select sql est un SQL très ordinaire, sans aucun traitement de grandes quantités de données.

En analysant cette impasse, il y a beaucoup de choses difficiles à gérer.

1. En raison de la grande quantité de données dans l'environnement de production, nous ne pouvons pas importer les données de la table d'association dans l'environnement de production dans l'environnement de test. Autrement dit, la quantité de données ne peut pas être simulée.

2. Il n'y a pas de sortie de journal. Parce que le niveau de sortie du journal de l'environnement de production est ERREUR.
3. Il ne peut pas être testé dans l'environnement de production car le client ne le permet pas.
4. La base de données dans l'environnement de production ne peut pas activer les instantanés et autres fonctions. Parce que cela affectera les performances.

Comme vous pouvez l'imaginer, sans fonctionnalités telles que les instantanés, l'analyse des blocages ne peut s'appuyer que sur l'analyse du code. Mais ce processus est très compliqué et il n’y a aucune idée en analysant simplement le code.

Étape 1 : Nous soupçonnons que cela est dû à la quantité de données
En raison de la quantité extrêmement importante de données dans l'environnement de production, ce processus implique également le traitement de nombreux autres tableaux. On se demande alors si la grande quantité de données n’a pas provoqué une surcharge du système, conduisant à une impasse ?
Nous avons donc obtenu les informations de charge du processeur, du disque dur, du réseau, etc. lorsque le blocage s'est produit. Aucun indice n'a été trouvé.


Phase 2 : Créer un programme de test et utiliser le multi-threading pour simuler plusieurs utilisateurs dans l'environnement de test pour effectuer ce traitement.
Afin de reproduire cette impasse dans l'environnement de développement, nous avons réalisé un programme de test multi-thread pour simuler un fonctionnement multi-utilisateurs. Malheureusement, il n'a toujours pas été reproduit.

Phase 3 : Analyser la différence entre la base de données de l'environnement de test et la base de données de l'environnement de production

À l'heure actuelle, nous soupçonnons que le problème est toujours causé par la quantité de données. Nous avons donc fait de notre mieux pour avoir autant de données dans l'environnement de développement que dans l'environnement de production.
Après avoir exécuté le test, il ne s'est toujours pas reproduit.


Étape 4 : Analyser le journal d'opération de l'utilisateur
Sans autre solution, il faut analyser le journal d'opération de l'utilisateur, en espérant trouver des indices. Le travail acharné porte ses fruits, et nous avons constaté que lorsque deux personnes
effectuent cette opération en même temps, une impasse se produit. Nous estimons donc que le problème est dû au fait que deux personnes opèrent en même temps. Cependant, pourquoi l'environnement de développement simule-t-il les opérations de
nombreuses personnes mais aucune impasse ne se produit ?


Phase 5 : Découverte des problèmes de paramétrage de la base de données
Nous avons modifié le programme de test pour augmenter le nombre d'utilisateurs simulés, mais malheureusement, le problème n'a pas été reproduit. À ce stade, nous avons remarqué : les paramètres de la base de données
de l'environnement de développement sont-ils différents de ceux de l'environnement de production ? Nous avons comparé les paramètres des deux bases de données et constaté que de nombreux paramètres étaient différents. Mais nous nous sommes concentrés uniquement sur les paramètres liés au verrouillage
, c'est-à-dire les paramètres contenant le mot-clé LOCK.


Étape 6 : Maintenir la cohérence des paramètres de la base de données de l'environnement de test et de la base de données de l'environnement de production
Nous avons modifié tous les paramètres liés au verrouillage pour être cohérents avec l'environnement de production. Mais l’impasse ne se reproduit toujours pas. Finalement, une personne a découvert que le paramètre "cur_commit"
était différent. J'ai donc interrogé la documentation et découvert les caractéristiques de cur_commit.
Lorsque cur_commit = false, la situation suivante provoquera un blocage :
Le thread 1 insère les données A, puis le thread 2 insère les données B.
Avant que le thread 2 n'ait soumis la transaction, le thread 1 interroge les données A, ce qui provoquera un blocage.
Dans l'environnement de développement, cur_commit = true, nous n'avons donc jamais pu simuler ce phénomène.
Nous avons donc changé cur_commit en false.


Phase 7 : Utiliser le programme de test pour simuler
Nous avons modifié le programme de test pour simuler les opérations des deux threads ci-dessus et avons reproduit avec succès le blocage. Les informations du journal des erreurs sont également cohérentes avec l'environnement de production.


Étape 8 : Utiliser les opérations d'écran pour simuler
Ensuite, nous avons modifié le programme, utilisé les opérations d'écran et reproduit avec succès le blocage.

Solution :

La solution est très simple, c'est-à-dire ajouter les conditions dans l'instruction de requête sous forme d'index, afin qu'un blocage ne se produise pas.
Étant donné que le volume de données de cette table n'est pas important, il n'y a presque aucun impact sur les performances.

Recommandations associées :

Explication détaillée de la méthode ibm_db du module python pour l'installation hors ligne de db2

Python connexion à la base de données DB2

Cinq façons d'utiliser PHP pour faire fonctionner DB2 Express C (1)_PHP tutoriel

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!