Plein de questions sur Informix

[gnubibi]

Hello tout le monde,

Je dois m'occuper de l'administration d'une base informix 7.31 sur du solaris et je n'ai pas de compétence la dessus (informix) et j'ai quelques questions.

- existe t'il un mode réplication comme pour du mysql ?
- comment installer Informix Server Administrator, ou l'activer si il est installé ?
- je dois restaurer (ca sera avec ontape -r) une base de prod sur un autre serveur, est ce que les chunks vont être recréés automatiquement ou faut il les recréer manuellement ?

- avez vous un bon lien avec tout ce qu'il faut savoir pour informix ?

Bref, je patauge un peu, et surtout je dois faire super attention car c'est de la prod.

Merci d'avance pour votre aide

[gangsoleil]

Bonjour,

Le site d'IBM regorge de docs et de manuels sur Informix ; je te conseille donc de commencer par la.

Sinon, en vrac :

• 7.31 est une tres vieille version... On en est a 11.50 !
• Je te deconseille fortement de faire les manips sur la base de prod sans les avoir tester sur une base de test -> Montes-toi une machine de tetst (tu peux en profiter pour tester la migration vers une version recente du moteur)

[gnubibi]

Merci pour ton retour, et oui je m'entraîne sur une base qui n'est pas en Prod.
Je sais que c'est une version assez ancienne, mais je n'ai pas le pouvoir de faire la mise à jour, je ne peux juste que la conseiller.

Sinon j'ai 2-3 autres questions :

- Est il possible de mettre en place une réplication comme pour un mysql par exemple ?
Je vois la commande onstat -g dri qui permet d'afficher l'état, mais la seule solution de replication que j'ai trouvé semble payante.

- J'ai besoin de monitorer ma base aussi, surtout au niveau des espaces des dbspaces. J'ai trouvé un un script sql que j'essaye d'adapter mais je galère un peu, existe t'il des commandes du genre onstat qui pourrait me fournir les infos dont j'ai besoin (je n'ai rien vu de bien pertinent ?
Je viens de voir que l'on peut utiliser le snmp de informix, mais j'ai déjà en place net-snmp, avez-vous déjà mis ça en place ?

Je continue de chercher sinon sur le site.

Merci d'avance pour votre retour

[gangsoleil]

Bonjour,

En vrac aussi :

• Je ne pense pas qu'il existe un mecanisme de replication gratuit
• Est-ce que onstat -d t'aide un peu ?
• Pour l'interrogation des agents SNMP, tu peux essayer de voir du cote de Nagios

[gnubibi]

hello,

Pour la partie snmp c'est bon, j'ai la bonne requête qui va bien, le tout dans un script sh.

Comment faites vous de votre coté pour avoir un serveur informix de spare avec une base plus ou moins repliqué ?

Si je m'amuse à faire un restaure de la base de prod sur la préprod j'en ai au minimum pour 10-11H, ce n'est pas top du coup.

Reste le snapchot SAN mais pour l'instant ce n'est pas d'actualité, bref je ne sais pas trop vers quoi me tourner.

Si quelqu'un à déjà mis ça en place
Coté mécanisme repli payant qu'elle est pour vous la meilleure solution ?

++

[abdellah234]

salut,

tu peux faire un ontape pour sauvegarder/restaurer ailleurs sur un autre serveur, il faut seulement bien faire attention a garder la meme structure au niveau des dbspaces (Noms des chemins des fichiers ou raw-devices, taille de ceux-ci si c'est des raw-devices.)

Pour la replication, en 7.31 tu peux utiliser la replication HDR, je ne sais plus si la IER existait sur cette version.

[gnubibi]

Hello,

Encore une question pour vous. Est il possible de savoir facilement si des tables sont lockées lors de l'exécution d'un script ?

J'ai bien trouvé la commande onstat -g sq (id), mais mon souci vient qu'un des scripts du client met en général 5 mn pour s'exécuter mais parfois 1H voir 2H

Le script est exécuté plusieurs fois pas jours à des heures différentes, et le problème est aléatoire, ce n'est pas tjrs à la même heure.

Est il possible de loguer toutes les actions ?
Voir qu'elles sont les requêtes lentes, ou le temps pris ?

Bref, je dois trouver pourquoi cette requête prend parfois 5 mn ou 2H pour un même nombre de ligne inséré.

Merci d'avance pour votre aide

[IFA2377]

Bonjour,

- La requête n’est peut-être pas forcément pertinente en termes de performance.
- Les tables ne sont peut-être pas forcément indexées comme il faudrait pour satisfaire un join.
- Exécuter la requête pas-à-pas peut révéler l'éventuel problème.
- La requête travaille-t-elle en lockant/délockant les tables qu'elle exploite ?
- Un « update statistics high; » peut améliorer les performances.
- Le « System Catalog » doit certainement permettre de voir les tables lockées.
- J’avais fait un écran très simple qui exploitait certaines informations du « System Catalog ». J’ai oublié quel était l’objectif mais cela a peut-être un rapport avec la recherche d’une table lockée.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
{------------------------------------------------------------------------------}
{
SYSGRANT.per : Administration du System Catalog (SYSTABAUTH et SYSUSERS)
AUTEUR       : IFA2377
DATE         : 13 Avril 2000
}
{------------------------------------------------------------------------------}
 
DATABASE my_bdd
 
screen
{
+------------------------------------------------------------------------------+
|                                                                              |
|grantor [SC1     ]  username [SC5     ]                                       |
|grantee [SC2     ]  usertype [S]                                              |
|tabid   [SC3     ]  priority [SC7     ]                                       |
|tabauth [SC4    ]   password [SC8     ]                                       |
|                                                                              |
+------------------------------------------------------------------------------+
}
 
end
 
TABLES  SYSTABAUTH
        SYSUSERS
 
attributes
 
SC1  =   SYSTABAUTH.grantor,reverse,noentry,noupdate;
SC2  =   SYSTABAUTH.grantee,reverse,noentry,noupdate;
SC3  =   SYSTABAUTH.tabid,RIGHT,reverse,noentry,noupdate;
SC4  =   SYSTABAUTH.tabauth,reverse,noentry,noupdate;
 
SC5  =     SYSUSERS.username,reverse,noentry,noupdate;
S    =     SYSUSERS.usertype,reverse,noentry,noupdate;
SC7  =     SYSUSERS.priority,RIGHT,reverse,noentry,noupdate;
SC8  =     SYSUSERS.password,reverse,noentry,noupdate;
 
INSTRUCTIONS
 
{ Catalog ---------------------------------------------------------------------}
 
before editadd editupdate of SYSTABAUTH
       abort;
 
before editadd editupdate of SYSUSERS
       abort;
 
{-----------------------------------} end  {-----------------------------------}

[gnubibi]

Merci pour ton aide

Une autre question, concernant les logfiles et pouvant être la cause de mon problème.

Un onstat -l m'indique qu'ils sont tous occupés à 100%

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
----8<--------------------------
Informix Dynamic Server Version 7.31.UD1XF  -- On-Line -- Up 67 days 10:29:41 -- 1798752 Kbytes
 
Physical Logging
Buffer bufused  bufsize  numpages numwrits pages/io
  P-2  53       64       109757908 2720130  40.35
      phybegin physize  phypos   phyused  %used   
      10c793   100000   97656    9739     9.74    
 
Logical Logging
Buffer bufused  bufsize  numrecs  numpages numwrits recs/pages pages/io
  L-2  0        32       134004481 5220267  353164   25.7       14.8    
        Subsystem    numrecs  Log Space used
        OLDRSAM      134004481 1702001896    
 
address  number   flags    uniqid   begin        size     used    %used
ab0cef8  1        U-B----  76881    10274f       1000     1000   100.00
ab0cf14  2        U-B----  76882    102b37       1000     1000   100.00
ab0cf30  3        U-B----  76883    102f1f       1000     1000   100.00
ab0cf4c  4        U-B----  76884    103307       1000     1000   100.00
ab0cf68  5        U-B----  76885    1036ef       1000     1000   100.00
ab0cf84  6        U-B----  76886    103ad7       1000     1000   100.00
ab0cfa0  7        U-B----  76887    103ebf       1000     1000   100.00
ab0cfbc  8        U-B----  76888    1042a7       1000     1000   100.00
ab0cfd8  9        U-B----  76889    10468f       1000     1000   100.00
ab0cff4  10       U-B----  76890    104a77       1000     1000   100.00
ab0d010  11       U-B----  76891    104e5f       1000     1000   100.00
ab0d02c  12       U-B----  76892    105247       1000     1000   100.00
ab0d048  13       U-B----  76893    10562f       1000     1000   100.00
ab0d064  14       U-B----  76894    105a17       1000     1000   100.00
ab0d080  15       U-B---L  76895    105dff       1000     1000   100.00
ab0d09c  16       U-B----  76896    1061e7       1000     1000   100.00
ab0d0b8  17       U-B----  76897    1065cf       1000     1000   100.00
ab0d0d4  18       U---C--  76898    1069b7       1000      346    34.60
ab0d0f0  19       U-B----  76859    106d9f       1000     1000   100.00
ab0d10c  20       U-B----  76860    107187       1000     1000   100.00
ab0d128  21       U-B----  76861    10756f       1000     1000   100.00
ab0d144  22       U-B----  76862    107957       1000     1000   100.00
ab0d160  23       U-B----  76863    107d3f       1000     1000   100.00
ab0d17c  24       U-B----  76864    108127       1000     1000   100.00
ab0d198  25       U-B----  76865    10850f       1000     1000   100.00
ab0d1b4  26       U-B----  76866    1088f7       1000     1000   100.00
ab0d1d0  27       U-B----  76867    108cdf       1000     1000   100.00
ab0d1ec  28       U-B----  76868    1090c7       1000     1000   100.00
ab0d208  29       U-B----  76869    1094af       1000     1000   100.00
ab0d224  30       U-B----  76870    109897       1000     1000   100.00
ab0d240  31       U-B----  76871    109c7f       1000     1000   100.00
ab0d25c  32       U-B----  76872    10a067       1000     1000   100.00
ab0d278  33       U-B----  76873    10a44f       1000     1000   100.00
ab0d294  34       U-B----  76874    10a837       1000     1000   100.00
ab0d2b0  35       U-B----  76875    10ac1f       1000     1000   100.00
ab0d2cc  36       U-B----  76876    10b007       1000     1000   100.00
ab0d2e8  37       U-B----  76877    10b3ef       1000     1000   100.00
ab0d304  38       U-B----  76878    10b7d7       1000     1000   100.00
ab0d320  39       U-B----  76879    10bbbf       1000     1000   100.00
ab0d33c  40       U-B----  76880    10bfa7       1000     1000   100.00
----8<--------------------------

qu'est ce que je peux faire pour remédier à cela ?
En créer des nouveaux ? Peut on le faire à chaud ?
Les purger ? Si oui comment ? (ontape ?)

Merci d'avance

[abdellah234]

Le fait qu'ils soient remplies à 100% ne gene en rien, ils sont justement là pour ça. Le point sur lequel tu dois être attentif est la sauvegarde de ceux-ci pour assurer la rotation des logs au niveau de l'écriture des transactions par le moteur informix. En gros il faut que tu scripte leur sauvegarde à intervalle régulier (en bouclant la commande ontape) ou alors laisser en tâche de fond la commande ontape -c pour faire une sauvegarde continue des logs (je le conseille pas trop).

[abdellah234]

Une autre chose : La taille des journaux est très petite et il se peut que tu aies pas mal d'erreur à cause de LONG-TRANSACTION.

Augmente les à 50Mo minimum chacun

[gnubibi]

Envoyé par abdellah234

Une autre chose : La taille des journaux est très petite et il se peut que tu aies pas mal d'erreur à cause de LONG-TRANSACTION.

Augmente les à 50Mo minimum chacun

Merci pour ta réponse, je vais prévoir d'augmenter la taille des journaux car un arrêt de la base est prévu.

As tu une doc ou on explique clairement comment faire ?

Merci
A+

[gnubibi]

Bon je viens de trouver comment faire, vu que je dois arrêter la base, je vais faire la modification dans le fichier onconfig

Actuellement j'ai :

----8<-------------------
# Logical Log Configuration

LOGFILES 20 # Number of logical log files
LOGSIZE 2000 # Logical log size (Kbytes)
----8<-------------------

Et je vais donc passer le LOGSIZE à 420000 (50Mo) qu'en pensez-vous ?

Il ne me reste qu'a trouver ou sont stockés physiquement ces logs pour voir si j'ai assez de place

Edit : ils sont stockés dans la root dbspace, faut que je vois si j'ai assez de place alors !!!

[blackstreet]

Bonjour,

Je voudrais avant tout attirer votre attention à une chose, La réplication coté Informix se fais nativement, et tu n'a pas besoin de composants supplémentaires. il faut juste savoir comment.

Et en ce qui concerne l'ajour de LOG, l'opération que tu va faire, ne va pas modifier les LOGS. ça dois être fais en mode commande.

[gnubibi]

Pour la répli j'ai laissé tomber pour l'instant.

Concernant les logs logique j'ai lu ça sur le site d'IBM :

http://publib.boulder.ibm.com/infoce...c/admin532.htm

Les logs sont stockés dans le Root dbspace, il me suffit donc d'agrandir la valeur dans le onconfig et vérifier que j'ai bien assez de place dans mon root dbpsace, non ?

Edit : après test sur ma préprod ça ne fonctionne pas. Si vous avez une bonne procèdure je suis preneur.

Est ce 50Mo par fichier de log n'est pas trop ?

[blackstreet]

Le meilleur, et plus sure moyen d'ajouter des logs, est d'utiliser la commande : onparams.

ça te permet d'ajouter des logs en ligne et sans danger, bien sur la taille des logs à ajouter dépend principalement de la taille des tes traitements par jour et forcément de la taille de ton ROOTDBS.

En ce qui concerne la réplication, je sais pas pourquoi ne pas utiliser la réplication informix.

c'est simple, et très paramétrable et ça te permet de garantir une "HIGH AVAILABILITY" de ton système.

[begooden-it]

Bonjour,

désolé encore une exhumation de post mais entre Halloween et la Toussaint, c'est permis alors j'en profite

1)

- existe t'il un mode réplication comme pour du mysql ?

Si on se place sur le plan chronologique, il faudrait plutôt demander si Mysql a une réplication comme Informix Dynamic Server.
La réplication existe sur Informix depuis la version 6.0 ( exclusive à la plateforme Sequent ), et plus généralement la version 7.0 soit 1994, alors que MySql n'existait même pas. Ce mécanisme va sur ses 18ans et est plus qu'éprouvé en terme de robustesse, de de flexibilité et de performance. Ne pas l'utiliser alors que le besoin est là serait vraiment dommage.

2) Au sujet "version gratuite" IDS existe depuis quelque temps en édition Innovator-C, donc gratuite en environnement de production.
Innovator-C inclut la réplication HDR ( la totalité de l'instance est répliquée ) avec un primaire et un secondaire, ou la réplication Entreprise ( réplication en update anywhere au niveau tables ), pour 1 root node et x leaf nodes. Déjà de quoi s'amuser....

Si tu es en IDS 7.31, le chemin de migration est direct si tu restes sur la même machine ( pas d'export import de données, sauvegarde de qq fichiers, arrêt et redémarrage de l'instance), et il existe une procédure très simple de "machine arrière" ( retour à 7.31 ) en cas fortement improbable de problème grave.

Par contre Innovator-C Edition est limité en termes de nombre de CPU VP ( maximum 4 ), tournant sur maximum 1 CPU/4 coeurs.
La mémoire partagée est aussi limitée à un total de 2Gb ( page buffers + Virtual size) pour toutes les instances tournant sur cette machine.

A mon avis de quoi faire tourner déjà plusieurs centaines d'utilisateurs d'une application OLTP moyennement complexe.

Autres limitations: pas de fragmentation des tables ni de PDQPRIORITY, mais allez, pour le prix, c'est pas si mal que ça.

Pas de limite de volume ( enfin si, environ 128 Petabytes), mais il vaut mieux étudier de près ton sizing...

3) Autre chose, au sujet du backup en continu des logical logs: si tu as de la place dans le dbspace les contenant, n'hésites pas à tailler grand, c'est un bon remède contre les longues transactions comme expliqué plus haut. Mais je suis aussi partisan de ne pas donner la taille individuelle de chaque log trop grande, j'explique:

le backup continu des logical logs se fait quand chaque logical log est à 100% de remplissage. Chaque log log backupé sur un autre media constitue la garantie de recouvrer intégralement toutes les transactions contenues dans ce log en cas de crash disque par exemple. Plus un logical log met de temps à se remplir ( donc à être backupé ), moins les chances de récupérer un grand nombre de transactions sont importantes.

Exemple: un logical log de 100 Mb met 4 heures à se remplir à 100%. Si par malchance il y a un crash disque, avec obligation de restore, alors que le logical est rempli à 1%, tu perds bêtement pratiquement 4 heures de transactions.

Si le logical log ( LOGSIZE dans onconfig ) avait été sizé de façon à se remplir en 10 mn, tu maximises fortement les chances de récuper un maximum de transaction, au risque de perdre un maximum de 10mn d'activité...

Il n'y a pas de règle absolue pour le calcul de remplissage des logs: tu cherches dans le log de ton instance la durée entre chaque message " Logical Log XXX Complete' et tu calcules la moyenne. Ensuite avec une bonne règle de trois tu pourras en déduire la valeur idéale dans le cas de ton installation.

Ceci est totalement inutile si tes bases ne sont pas journalisées, vu que seules les instructions SQL de définition de données ( create table, create index etc...) seront journalisées dans ce cas de figure.

Voila
Eric

[gnubibi]

Merci pour les réponses.

Bon, on a migré vers IDS 11.50 et depuis quelques temps le client rencontre à nouveau des lenteurs sur des traitrements.

La conf actuelle :

- un serveur physique surdimenssioné (CPU 8 coeur, 32Go)
- un LUN SAN contenant des chunks
- un autre LUN SAN contenant des chunks
- un LUN pour les exports

Le serveur fait environ 15-20% de CPU wait, la cause pourrait être des lenteurs d'accès au data sur les LUN.

Un traitement équivalent peut mettre 10s comme 20mn pour s'exécuter.

A noter que la base n'est pas journalisée et qu'on reste sur une politique d'export différentiel plusieurs fois par jour. (on arrive à des 50Go d'export, pour un full de 150Go, avec 2 full par semaine).

Bref, qu'est ce que j'ai comme outils coté IDS pouvant m'aider à trouver une piste ?
Des index manquant ? Des tables lockés par une autre transaction en cours ?

A+

[begooden-it]

Bonjour,

désolé, je n'étais pas repassé ici depuis quelques jours..

je pense d'ailleurs qu'il ne serait pas une mauvaise idée de créer un nouveau post, car le sujet n'a plus rien à voir avec celui du début :-)

Bon, trève de formalisme, avec une belle configuration comme tu as, on ne devrait pas entendre parler de problèmes de perf.

Les causes potentielles sont nombreuses, il faut procéder par ordre.
0) tu as installé 11.50, mais quelle Edition ? ( growth, Innovator, Ultimate ?
1) quelle version était installée avant la migration vers 11.50 ( et pourquoi pas 11.70 d'ailleurs? )
2) peux-tu me faire parvenir ton $ONCONFIG ?
3) les statistiques sont-elles à jour et sont elles mises à jour régulièrement ?
4) Tous les index sont ils présents ?
5) si tu parles de "traitements" je comprends "batch". Un index manquant ou une requête mal construite peut donner un désastre en termes de performances. Le ralentissement est-il global ou seulement certains traitements?
6) As-tu lancé un vmstat pendant par exemple 12 heures pour comprendre le comportement global de la machine ?
7) quels sont les Temps de checkpoint?
8) Peux-tu me faire parvenir ton log informix?
9) lance onstat -k et regarde dans la colonne wtlist ( waitlist ), si il y a des valeurs différentes de 0. Si oui cela veut dire qu'il y a des sessions qui attendent le déblocage d'un lock soit sur rangée ( ou page ), soit sur table.
10) il faudrait lancer pendant quelques minutes un explain global, et je pourrais en extraire les problèmes de perf notoires.
11) le fait d'être en base non journalisée devrait au contraire être un facteur d'allègement en ce qui concerne les i/o.

On va commencer avec cela :-)

Cdt
Eric

[begooden-it]

et si tu as du temps devant toi, je tenterais en premier lieu de dropper les statistiques et les reconstruire de zéro.

Cela peut prendre du temps, mais cela ne peut qu'être bon.

Cela ne dispense pas de montrer le $ONCONFIG ainsi que le "online.log" et de vérifier onstat-k

E.