La table Informix est verrouillée

Question

Notre application Web J2EE est exécutée sur Informix 9.40.

Parfois une table est verrouillée, puis toute JSP ayant du code SQL accédant à cette table renverra une erreur. Je sais comment utiliser onstat -k pour voir les verrous actuels, mais je veux savoir est-il un moyen de suivre tous les verrous se sont produits dans l'histoire et la session connexe et l'instruction SQL qui a causé le verrouillage de la table?

Parce que je ne sais pas quand la même erreur se produira à côté ...

Answer 1

D'abord, vous devez savoir que la version IBM Informix Dynamic Server (IDS) 9,40 est plus pris en charge par IBM; pas plus que la version suivante, 10.00. Vous devriez prévoir de mettre à niveau, probablement à 11,70, peut-être juste à 11,50.

Il n'existe pas de façon de suivre complètement les verrous. Une raison à cela est qu'un tel suivi imposerait un ralentissement considérable du système - un ralentissement très important. Les verrous sont généralement le deuxième plus gros composant de la mémoire partagée (derrière le ou les pools de mémoire tampon contenant des pages de données), donc ils sont nombreux, et ils sont souvent très actifs, et les verrous sont souvent éphémères (pour de petites fractions de une seconde, ou même des fractions de milliseconde). Le volume de données générées par cette exploitation serait extraordinairement grand et très difficile à passer au crible. Si vous étiez sur une version plus récente, il pourrait y avoir quelques options pour aider avec DB-Cron et l'API Admin (pas certain de cela, mais les chances seraient meilleures), mais avec 9.40 les options sont plutôt strictement limitées .

L'approche la plus proche que je peux penser est snapshotting avec onstat -k -u -r 1. Les rapports -k sur la table de verrouillage (comme vous le savez déjà); les rapports -u sur les utilisateurs (sessions) et le -r 1 répète la commande toutes les secondes. Vous pouvez ajouter d'autres demandes de données comme bon vous semble; -g ses fournirait un rapport plus détaillé sur les sessions (si vous êtes le DBSA, généralement l'utilisateur informix, lors de l'exécution de la commande). Mais ceci est une seconde d'échantillonnage ... la seule bonne nouvelle est que lorsque le verrou est placé sur la table, il est susceptible de traîner pendant un moment (parce que vous remarquez le problème), donc la sortie -g ses ou -u vous dira qui ou quoi applique le verrou. Mais le volume de données dans l'intervalle sera important.

Vous devez passer en revue tout le SQL autour du système, recherchant des trucs de verrouillage de table. Y a-t-il une cohérence avec le moment? Est-ce que cela pourrait être UPDATE STATISTICS être exécuté par un travail cron, par exemple? Cela acquiert des serrures de table fugitivement, je crois; c'est aussi quelque chose qui a été amélioré dans les versions depuis votre version d'IDS.