UPDATE STATISTICS, Lock

[kiratdeluxe]

Bonjour les amis, j'ai un petit problème depuis quelques semaines, ma base informix n'arrive plus à faire une sauvegarde avec dbexport.

La raison en est simple il y a une table qui est verrouillée donc il me fait des erreurs ( puisque lui même doit avoir l'exclusivité sur la base pour effectuer son export ) après quelques recherches, il s’avère que que c'est le thread du bTREE clean qui lock une table et qui ne la lâche pas ... il y a effectivement un update statistics qui est lancé et c'est lui qui devrait lancer ce btree.



quand on fait un onstat -u :

address  flags   sessid   user     tty      wait     tout locks nreads   nwrites

44d64a70 ---PX-B 103579   root     -        0        0    1     23939    400

et un onstat -k :

address  wtlist    owner     lklist   type     tblsnum  rowid    key#/bsiz
  
460be790 0        44d64a70   0        HDR+IX   200081   0           0   

avez-vous des idées, car je commence à être à cours des miennes ...

Merci d'avance,

Kirat

[kiratdeluxe]

j'ai avancé dans mes recherches, quand l'on fait un onstat -C :

Envoyé par onstat -C

IBM Informix Dynamic Server Version 10.00.UC6 -- On-Line -- Up 3 days 15:36:38 -- 72912 Kbytes

Btree Cleaner Info
BT scanner profile Information
==============================
Active Threads 1
Global Commands 0
Number of partition scans 2919
Main Block 0x45385ab0
BTC Admin 0x00000000


BTS info id Prio Partnum Key Cmd
0x45c9dd48 0 High 0x00300158 1 10000000 Scan index
Number of leaves pages scanned 503310006
Number of leaves with deleted items 503248613
Time spent cleaning (sec) 4391
Number of index compresses 1006495443
Number of deleted items 28958
Number of index range scans 0
Number of index leaf scans 59
Number of index alice scans 0
Scan Type Leaf

et un onstat -C clean :

Envoyé par onstat -C clean

IBM Informix Dynamic Server Version 10.00.UC6 -- On-Line -- Up 3 days 15:36:15 -- 72912 Kbytes

Btree Cleaner Info

Index Cleaned Statistics
=========================
Partnum Key Dirty Hits Clean Time Pg Examined Items Del Pages/Sec

je vous passe les tables pour en venir à celle qui nous concerne ...

0x00300158 1 C 0 107076 1616214855 142 15094.09

nous pouvons voir que btree scanne pratiquement à l'infini cet index de partition .

voici quelles requêtes il faut avoir pour connaitre à quel index il est bloqué :

l'index:

Code :

1
2
3
    SELECT indexname
    FROM sysfragments
    WHERE hex(partn) = 'partnum';

Sa table:

Code :

1
2
3
4
5
    SELECT tabname
    FROM sysfragments f, sysindexes i, systables t
    WHERE hex(f.partn) = 'partnum'
    AND f.indexname = i.idxname
    AND i.tabid = t.tabid;

exemple :

Code :

SELECT indexname FROM sysfragments WHERE hex(partn) = '0x0010016B';

l'adresse en hexa contient des caractères uniquement en majuscule.

grâce à ça je connais le nom de l'index sur lequel il bloque, on m'a conseillé de reconstruire l'index qui bloquait, seulement je ne sais pas si il est possible de le faire sans arrêter le serveur de prod.

auriez vous une idée ?

[begooden-it]

Bonjour,

je suis en train de lire ta question, et il m'en vient de suite une autre:
pourquoi t'embêtes tu à faire tes sauvegardes avec un outil qui n'est pas prévu pour celà. Cette dbexport est très simple, mais n'est pas l'outil adapté pour faire des backups informix. Tu es d'ailleurs en train de te battre avec à cause du lock sur la base.

utilise plutot ontape, qui est très facile à utiliser et paramètrer et surtout fait pour ce que tu as besoin.

D'autre part, je vois que tu es en version 10.00 qui n'est plus supportée. Il faudrait envisager un passage en 11.70 par exemple.

Si tu veux, envoie-moi les sorties suivantes sur ce mail
eric.vercelletto@begooden-it.com

onstat -u
onstat -k
onstat -g ses
onstat -g ath
onstat -g sql

au moment où tu détectes le problème.

Je pense que ton implémentation suscite un certain nombre de commentaires/améliorations que je pourrais voir avec toi, si tu le désires.

Cordialement
Eric

[nelem75]

Bonjour,

Il se pourrait que le problème se règle en arrêtant / redémarrant le btree scanner. Voir la documentation pour les détails de la commande "onmode -C stop".

Hope this help.

[kiratdeluxe]

@nelem75 : si ça fonctionne mais ça ne fonctionnait pas comme ça avant, pour l'instant j'utilise cette methode pour ne pas bloquer mon export.


@begooden-it

on ne sauvegarde pas sur bande directement du serveur, donc on n'utilise pas ontape.

et pour l'instant mes boss ne conçoivent pas de mise à jour.je dois faire avec ...

sinon

onstat -u

IBM Informix Dynamic Server Version 10.00.UC6     -- On-Line -- Up 7 days 23:06:56 -- 72912 Kbytes

Userthreads
address  flags   sessid   user     tty      wait     tout locks nreads   nwrites
44d64018 ---P--D 1        root     -        0        0    0     4871     20862
44d64544 ---P--F 0        root     -        0        0    0     0        60194
44d64f9c ---P--- 9        root     -        0        0    0     0        579
44d65f20 ---P--D 13       root     -        0        0    0     0        0
44d6644c Y--P--D 18       root     -        4407d678 0    0     0        0
44d673d0 ---PR-B 836858   root     -        0        0    1     30567    1008
44d678fc Y--P--- 841721   root     3        45b819a0 0    1     232298   1728
 7 active, 128 total, 30 maximum concurrent

onstat -k

Locks
address  wtlist    owner     lklist   type     tblsnum  rowid    key#/bsiz
45ea0688 0        44d673d0   0        HDR+IX   200081   0           0   
45ea1340 0        44d678fc   0        HDR+S    100002   207         0   
 2 active, 32000 total, 2048 hash buckets, 4 lock table overflows

onstat -g ses

session                                      #RSAM    total      used       dynamic 
id       user     tty      pid      hostname threads  memory     memory     explain 
866446   informix -        0        -        0        12288      8072       off 
841721   root     3        23624    server_b 1        135168     92520      off 
3        informix -        0        -        0        12288      9280       off 
2        informix -        0        -        0        12288      8072       off 

onstat -g ath

Threads:
 tid     tcb      rstcb    prty status                vp-class      name
 2       452c4bd0 0        2    sleeping secs: 1        6lio        lio vp 0
 3       452e0968 0        2    sleeping secs: 1        7pio        pio vp 0
 4       452f5968 0        2    sleeping secs: 1        8aio        aio vp 0
 5       4530a968 0        2    sleeping secs: 1        9msc        msc vp 0
 6       45337968 0        2    sleeping secs: 1       10aio        aio vp 1
 7       4534cba0 44d64018 4    sleeping secs: 1        3cpu        main_loop()
 8       45337c20 0        2    running                 1cpu        soctcppoll
 9       452f5ab0 0        3    sleeping forever        1cpu        soctcplst
 10      451f7430 44d64544 2    sleeping secs: 1        3cpu        flush_sub(0)
 11      451f7578 0        4    sleeping forever        1cpu        kaio
 16      4545b928 0        2    sleeping secs: 1       11aio        aio vp 2
 17      45467968 0        2    sleeping secs: 1       12aio        aio vp 3
 18      4544f968 0        2    sleeping secs: 1       13aio        aio vp 4
 19      4548f968 0        2    sleeping secs: 1       14aio        aio vp 5
 20      454a4968 0        4    sleeping forever        3cpu        kaio
 21      454a4b00 44d64f9c 3    sleeping secs: 1        3cpu        aslogflush
 38      459cd620 0        4    sleeping forever        5cpu        kaio
 39      459cd7d8 44d65f20 4    sleeping secs: 1        1cpu        onmode_mon
 44      4548fce0 0        4    sleeping forever        4cpu        kaio
 45      459cdec8 44d6644c 2    cond wait  bp_cond      3cpu        bf_priosweep()
 834885  4556bb28 44d673d0 2    running                 5cpu        btscanner_0
 839736  4556b828 44d678fc 2    cond wait  netnorm      5cpu        sqlexec

onstat -g sql

Sess  SQL            Current            Iso Lock       SQL  ISAM F.E.
Id    Stmt type      Database           Lvl Mode       ERR  ERR  Vers Explain    
841721 -              agorane            CR  Not Wait   0    0    9.03 Off

Merci pour vos reponses.

[nelem75]

Bonjour,

Tu dois rencontrer un des deux bogues suivants:

- IC52887 BTREE SCANNER RUNS IN ENDLESS LOOP
- IC52161 ONSTAT -C OUTPUT SHOWS RAPIDLY INCREASING NUMBERS WHICH CAN BECOME NEGATIVE

Ils sont tous les deux corrigés en 10.00.xC7.
Cette version n'étant plus supportée, le support technique ne fournira pas le produit sauf avec un contrat d'extension de support pour la version 10.

Il y a une méthode pour contourner ce problème.
Il faut utiliser le "range scanning" en configurant la valeur "rangesize" du paramètre BTSCANNER dans le fichier onconfig. Cela peut aussi être fait dynamiquement (sans arrêter l'instance) avec la commende 'onmode -C'.
Les partitions d'index de plus de la valeur indiquée ou avec un nombre de pages utilisées supérieur à la valeur indiquée seront prises en compte pour le "range scanning".
Se référer à la documentation (en ligne) pour les détails.

Hope this help.

[kiratdeluxe]

oui, c'est exactement ça !!

j'ai aussi des nombres négatifs, et il tourne bien à l'infini.

je vais tester ta méthode et je vous fais un retour .

J’espère vraiment que ça va m'aider .

sinon je verrai pour mettre à jour la base en uc7.

Merci en tout cas pour vos réponses .

[kiratdeluxe]

eh bien merci nelem75, c'etait exactement ça j'ai configuré le onmode -C rangesize sur 100 mais j'ai eu beau lire comment était faite cette méthode de parcours mais j'avoue que je n'ai pas tout compris.

j'ai mis 100 en cherchant sur le net des commentaires liés qui dataient à peu pres de l'année de la base.

mais je ne sais toujours pas comment configurer correctement ce rangesize.

j'ai compris qu'il parcourait les premiers et dernier index . mais ça ne me dit pas comment.

[begooden-it]

Bonjour, excuse pour le retard, je pensais être averti automatiquement de ton message.
pour ontape: tu n'es nullement obligé de faire tes sauvegardes sur bande. Le paramètre TAPEDEV du onconfig représente un file handle, qui peut être aussi bien /dev/null ( à ne pas utiliser pour une sauvegarde réelle ), un nom de fichier existant ou bien un device de tape genre /dev/rctXXXX.
Pour sauvegarder sur un fichier, il te faut faire un touch du nom que tu mettras dans TAPEDEV ( ex: /home/Backup/moninstance_tape_device ). Tu feras ensuite un chmod 660 de ce nom, puis chown informix:informix du même nom. Veille à ce que l'utilisateur Informix puisse évidemment écrire dans cette directory.
Il faut évidemment recopier ce fichier ailleurs et le garder sous un autre nom car tu dois vouloir conserver un certain historique.

Avec dbexport, tu t'imposes sans raison apparente des limitations comme l'impossibilité de faire un backup à chaud ( à cause des verrous sur la base) , et surtout le risque de perdre beaucoup d'informations en cas de restore, voire ne journée complète de transactions sur tu restores en fin de journée.

Avec ontape -s une fois par jour par exemple, + sauvegarde auto des logical logs ( toujours sur fichier si tu le veux, avec controle de l'espace disque ), en cas de restore, tu peux récupérer jusqu'à la dernière transaction committée. Intéressant non? Le système a été conçu comme celà et fonctionne ainsi depuis Informix Turbo ( 1989 ... ). Dbexport n'est pas la bonne manière de sauvegarder IDS.

Sur ton problème, directement, dans tes sorties onstat, je ne vois pas de session qui bloque quoique ce soit, ce qui tend à montrer que de dbexport n'est pas en train de marcher, car dans ce cas il poserait un lock exclusive sur base ). Donc c'est un coup dans l'eau... Si le paramètrage du BT Cleaner ne marche pas, relance les onstat pendant le dbexport et au moment ou tu as le problème.

Ceci dit, si le BT Cleaner a autant de difficultés à travailler, c'est que ta structure d'index est très complexe ( beaucoup de niveaux de BTREE), sans doute à tort. Vu que tu ne peux pas upgrader, il serait opportun de chercher des causes dans l'indexation. Le workaround de onmode -C est un workaround qui va alourdir le fonctionnement de ton instance...

regardons dans la complexité de tes index, en te connectant à ta base de données par dbaccess comme informix, et tu lances ceci:
select idxname,levels,leaves,nunique
from sysindexes
order by 2 desc
si tu vois des valeurs de "levels" supérieures à 3, ça veut dire que tes index sont "lourds" dans leur composition, ce qui est très souvent le cas, et donc rendent difficile la tâche du BTREE cleaner. Il faut dans ce cas réfléchir à leur simplification éventuelle. Un index à 5 colonnes ne sera pas plus efficace qu'un index à 3 colonnes en lecture, et sera très certainement nettement pire en écriture... Il y a des règles pour celà. Donc essaye de regarder de ce côté-là. Il est toujours bon de traiter la cause, même dans l'urgence.
Autrement, rien ne t'empêche de recréer les index que tu as identifiés avec ton instance on line, il faut seulement que les utilisateurs n'accèdent pas aux tables incriminées.
drop index index_name;
create index index_name on tablename ( xxxxx );
Ca fera déjà le ménage.
Veille à utiliser le PDQPRIORITY et avoir plusieurs tempdbspaces pour accélerer le traitement. Suivant la taille de la table ( combien ? ) une création d'index peut prendre qq secondes à quelques minutes, et fera le ménage dans ton BTREE.

Quelle edition d'IDS as tu ? Enterprise, Workgroup, Express ?
Egalement quelle taille occupe ton instance ( en pages occupées sur les dbspaces de données ).

Voila de quoi moudre du grain.
Bon week end
Eric

Pour info, quelle taille fait ta base, et les tables que tu vises

[kiratdeluxe]

waawwww, je suis étonné de toute l'information que tu me donnes, c'est vraiment un forum magnifique, malheureusement je n'ai pas eu le temps de m'y pencher aujourd'hui et je suis en vacances ce soir je reviendrai le 19 septembre.

en tout cas merci beaucoup à vous tous vous etes meveillleux !

au 19