From Tuxunix

Capture (Snapshoot)

Check configuration

#> db2 get dbm cfg
#> db2 get db cfg for [db]

Activer le monitor :

#> db2 update monitor switches using bufferpool on lock on statement on

Dynamic SQL

#> db2 get snapshot for dynamic sql on [db] > [db]_dynamic_sql.txt

Tablespaces

#> db2 get snapshot for tablespaces on [db] > [db]_tablespaces.txt

Bufferpools

#> db2 get snapshot for bufferpools on [db] > [db]_bufferpools.txt

Applications

#> db2 get snapshot for applications on [db] > [db]_applications.txt

#> db2 get snapshot for all applications | awk '/Application handle/{appid=$NF}/Inbound communication address/ && /172\.16\.2\.2/ {print appid}'
#> db2 get snapshot for application agentid appid

Health

#> db2 get health snapshot for database on [db] > [db]_health.txt

Tables info

#> db2 get snapshot for tables on [db] > [db]_tables.txt

Voir également Stat et Reorg

Statistique et Reorg

Tracer des requêtes SQL sur une table en particulier

On fait appel à l'audit ;-)

En tant que root :

créer un utilisateur (ex: db2aud) spécifique attribuer lui les droits sur les schémas voulue.

En tant que db2inst1 :

db2 connect to XXXX
db2 "grant connect on database to user db2aud"
db2 "GRANT SECADM ON DATABASE TO USER db2aud"

En tant que db2aud :

db2 connect to XXXX

Creation de l'audit

db2 "create audit policy test_audit categories EXECUTE with data status success error type normal"

Attribuer l'audit à la table

db2 "audit table schema.table using policy test_audit"
...
db2 "select * from schema.table"
...

Un fichier binaire est générer dans "/home/db2inst1/sqllib/security/auditdata/"

Extraire fichier binaire audit

Il faut ensuite l'extraire avec l'appel de cette procédure :

db2 "call sysproc.audit_archive('/tmp', -2)"

Archiver audit

Ensuite appeler la procédure sysproc.audit_del_extract(), pour analyser le contenu de l'archive!

db2 "call sysproc.audit_delim_extract(NULL, '/tmp/', '/tmp/', NULL, NULL)"

Creer les tables d'audit

Créer la table "EXECUTE" dans un tablespace :

db2 "create tablespace AUDIT_TEST"

Vérifie la création :

db2look -d databasename -l| more

Ensuite on va importer les data dans une table nommé "EXECUTE" :

cp sqllib/misc/db2audit.ddl /tmp/db2auditTest.ddl
cd /tmp/

On supprime tout ce qu'on a pas besoin ou on laisse tout a voir :

db2 -tf /tmp/db2auditTest.ddl

On autorise le user db2aud à accéder à la table :

db2 "GRANT ALL ON db2inst1.EXECUTE to user db2aud"

Importer les données archivés

Et on importe :

cd /tmp
db2 "import from execute.del of del lobs from /tmp replace into db2inst1.execute"

Et on requête dessus :

db2 "select USERID, TIMESTAMP, substr(STMTTEXT, 1, 50), ROWSMODIFIED, ACTIVITYTYPE FROM execute"

Résultat :

db2aud -OTHER 2010-11-03-14.35.29.579893 select count(*) from schema.table
...

Pour supprimer l'audit d'une table

REMOVE policy :

db2 "audit table schema.table remove policy"

Tracer requêtes longue

Activer le monitor :

db2 "update monitor switches using bufferpool on lock on ... statement on..."

Vérifier monitor :

db2 "get monitor switches"

Reset du monitor :

db2 reset monitor ALL

Ensuite capture global :

db2 "get snapshot for database nomBase"

Capture requêtes SQL :

db2 get snapshot for dynamic sql on nomBase

Variantes :

db2 get snapshot for dynamic sql on databasename | awk '/Number of executions/{if($NF==0){prt=0}else{prt=1;nexec=$NF};next};/Total execution time/{elaps=$NF};/Statement text/ && prt==1{printf("\nElapsed=%s, nbexec=%d\n%s",elaps,nexec, $0)}'

Ou

db2 get snapshot for dynamic sql on databasename | awk '/Number of executions/{if($NF==0){prt=0}else{prt=1;nexec=$NF};next};/Total execution time/{elaps=$NF};/Statement text/ && prt==1{printf("\n\nElapsed=%s, nbexec=%d\n%s",elaps,nexec, $0)}'

Captures par application:

Visible uniquement lorsque la session est en état "UOW Executing"

db2 "get snapshot for applications on nomBase"

Requête au niveau de la définitions : "Dynamic SQL Statement text"

Interpretation

worst preparation : Exprimé en ms, si beaucoup alors conseille utilisé des "Hosts variables*".

xda ... : Fait référence au traitement XML.

* Mécanisme permettant de remplacer un champ texte par une variable dans une requête. C'est un échange de donnée entre le programme et les instructions SQL. Ceci permet a l'optimiseur SQL de travailler qu'une seul fois sur la requête, lorsqu'il y a une valeur qui change.

Ex:

int v1;
varchar v2;

while (...) {
   ...
   EXEC SQL INSERT INTO maTable VALUES (:v1, 'foo', :v2);
   ...
}

v1 et v2 étant des hosts variables.

Diagnostiquer des locks

LOCKWAIT : Un lockwait se produit lorsqu'une transaction essaie d'acquérir un verrou dont le mode est déjà détenu par une autre transaction. Un lockwait peut apparaitre lorsqu'il y a un thread applicatif voulant accéder au même donnée ou avec des connexions différentes.

Paramétre DB2 : Variable "LOCKTIMEOUT".

DEADLOCK : Un deadlock est un cas particulier de lockwait qui apparait lorsque deux ou plusieurs connexions ne peuvent pas éxécuter leur transaction car chacun est en attente de verrou détenu par l'un des autres.

Paramétre DB2 : Variable "DLCHKTIME".

Monitoring de lock

#>db2 list applications show detail

Status : Une valeur de "lock-wait" désigne que l'application est bloquée par un verrou détenu par une application différente. Ne pas confondre avec "UOW Waiting" qui signifie que l'application est en cours et non bloquée, toutefois en cas de conflit de verrou il est possible que les applicatifs soit également en status "UOW Waiting" donc à surveiller.

Status Change Time : Il s'agit d'un cas particulier pour une application avec Lockwait, il montre que l'attente de verrouillage a commencé. Notez que le commutateur de moniteur UOW doit être à ON pour que cet événement soit signalé.

Appl. Handle : C'est une valeur entière qui vise à diagnostiquer 2 cas principaux.

->il permet que l'information sur la liste des applications soit mise en corrélation avec la sortie de l'instantané et des moniteurs d'événements.

-> Il fournit la valeur que vous pouvez utiliser avec la commande "force applications" pour stopper celui-ci qui pourrait-être à l'origine des problèmes.

#> db2 "force application (application_id)"

Capturer des informations sur les locks

#> db2 "GET SNAPSHOT FOR ALL ON <database>"
...
Locks held currently = 8
Lock waits = 0
Time database waited on locks (ms) = 315704
Lock list memory in use (Bytes) = 1692
Deadlocks detected = 0
Lock escalations = 0
Exclusive lock escalations = 0
Agents currently waiting on locks = 1
Lock Timeouts = 0
...

Descriptions des champs les plus importants.

Agents currently waiting on locks

Si ce nombre est supérieur à zéro, il y a plusieurs applications dans l'attente de verrouillage, et pour chacun d'eux, vous devriez voir une capture d'application avec un statut de «Lock-wait".

"Lock waits" et "Time database waited on locks (ms)"

Signifie la période durant laquel un lockwait à eu un impact réél.

Audit DB2