Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Problème de démarrage d'instance
Bonjour,
j'utilise Informix Dynamic Server 11.5FC6
j'ai cette erreur dans les logs lorsque je démarre mon instance pour la première fois:
17:12:31 IBM Informix Dynamic Server Started.
17:12:31 Requested shared memory segment size rounded from 32656KB to 32704KB
j'ai cherché dans l'onconfig mais je ne trouve pas la ligne qui correspond.
Merci pour votre aide!
Hello,
Ce n'est pas une erreur, juste une indication.
Cette valeur, si c'est bien la shared memory initiale, et la somme du nombre de buffers (ligne BUFFERPOOL) multipliés par la taille du buffer paramétré.
merci de m'avoir répondu mais mon instance ne démarre pas donc je pense que ce message est lié
onstat -l me rend ça : shared memory not initialized for INFORMIXSERVER 'ol_hdr32b'
j'ai modifié l'onconfig
BUFFERPOOL size=4K,buffers=8165,lrus=8,lru_min_dirty=50.000000,lru_max_dirty=60.000000
4*8165=32660 donc comprit entre les valeurs indiquées dans le message...
ça n'a rien changé
pour info, le serveur a 6Go de RAM sur windows 2008 (donc 64b)
merci pour votre aide
édit: c'est de pire en pire, le fichier de log ne se remplit même plus lors des tentatives de démarrage de l'instance... il est pourtant bien configuré dans l'ONCONFIG
j'ai remis l'utilisateur informix propriétaire partout avec tous les droits au cas où (vive 2008 au passage...)
Bonjour
8000 buffers, ca te fait 15 Mb de buffer pool. avec cela tu n'arriveras jamais à démarrer IDS, les processus dameons n'ont même pas de quoi s'alimenter.
Essaye plutot quelque chose comme:
BUFFERPOOL size=2K,buffers=200000,lrus=8,lru_min_dirty=15.00,lru_max_dirty=20.00
ça devrait te donner environ 600 Mb de shared memory et au moins de quoi démarrer...
N'oublies pas de nettoyer les éventuels segments de shared memory perdus dans la nature et dus au crash au démarrage. Etant un "grand spécialiste de Windows...", je ne connais pas la commande pour ce faire, donc je ferais un reboot du système s'il n'y a pas de contre-indication :-)
Eric
Je pourrai t'aider pour affiner ton onconfig.
Quelle edition de IDS as tu? Innovator C ou une autre?
après réglage de ces erreurs et en modifiant les buffers comme tu me l'as dit, voici le nouveau log d'erreur, le problème suivant a été la version d'informix... en fait j'ai récupéré les chunks d'une base sous 11.5TC6
j'ai installé une 11.5FW3 que j'ai mise à jour en 11.5FC6w
la conversion a commencé mais ça a planté:
(c'est une version Dynamic Server si ça répond à ta question?)Wed Oct 05 16:55:20 2011
16:55:20 Booting Language <c> from module <>
16:55:20 Loading Module <CNULL>
16:55:20 Booting Language <builtin> from module <>
16:55:20 Loading Module <BUILTINNULL>
16:55:20 VPCLASS 'cpu' not enough physical procs for affinity
16:55:20 Could not disable priority aging: errno = 0
16:55:21 Could not disable priority aging: errno = 0
16:55:26 DR: DRAUTO is 0 (Off)
16:55:26 DR: ENCRYPT_HDR is 0 (HDR encryption Disabled)
16:55:26 IBM Informix Dynamic Server Version 11.50.FC6WE Software Serial Number AAA#B000000
16:55:27 Conversion from version 11.50.xC6 Started
16:55:27 Cannot convert server. DBspace 'rootdbs' is down.
16:55:27 Cannot convert server. DBspace 'log_dbs' is down.
16:55:27 Cannot convert server. DBspace 'phys_dbs' is down.
16:55:27 Cannot convert server. DBspace 'data_dbs1' is down.
16:55:27 Cannot convert server. DBspace 'sbs_data' is down.
16:55:27 Please reinstall your previous IDS version, start the server and
restore the DBspaces before attempting to convert again.
16:55:27 oninit: Fatal error in shared memory initialization
16:55:27 IBM Informix Dynamic Server Stopped.
merci!
vu avec Eric, on laisse tomber cette méthode bancale de remontage de base!
Pour la communauté:
pour dupliquer une instance, ne jamais copier les chunks en cooked files pour les utiliser sur une autre machine. Les risques de ne pas démarrer sont multiples:
1) la copie complète des chunks n'est jamais faite au même millième de seconde, mais dure un certain temps (secondes, minutes ou plus), suffisant pour que les informations copiées au début soient totalement désynchronisées de celles copiées par la suite ( notamment entre les pages de données/index et les physical et logical logs). ceci entraine un énorme risque de corruption des données et nous l'avons bien vu dans cet exemple.
2) dans le cas présent, l'instance d'origine était en 64bits mais recopiées sur une instance en 32bits, le contenu des pages système est très certainement différent, pour une fois de plus entrainer de graves corruptions empêchant le démarrage.
=> que faire?
* une méthode orthodoxe est: avoir exactement la même version Informix sur la machine cible que sur la machine source. On fait un backup de l'instance source. Ensuite on prépare l'instance cible en recopiant le onconfig, on s'assure que le chemins absolu des chunks est possible ( vérifier les droits, on peut éventuellement faire un touch des chunks et y affecter les droits requis.
Ensuite, restore à froid sur l'instance cible et ça va redémarrer.
* autre méthode : onunload/onload , base par base. Même exigence que pour la première méthode: même version et même architecture. Rapide, mais à éviter si l'on cherche à compacter les extents.
* autre méthode: High Performance Loader, pouvant travailler en parallèle, très performant mais un peu complexe à mettre en oeuvre au départ.
* dernière méthode: dbexport / dbimport, base par base. généralement plus long, mais a l'avantage de recompacter conséquemment les extents sur l'instance cible.
Voila pour aujourd'hui.
Eric
Bonjour,
La copie des chunks (cp sous unix) d'une machine à l'autre n'est vraiment pas conseillé avec des 'raw device' mais fonctionne correctement en cooked file. La procédure à respecter est de faire cette copie l'instance offline sinon il y aura des corruptions, c'est certain...
Il y a une autre méthode avec le moteur online. Il faut faire un 'external backup', voir dans la documentation la commande 'onmode -c block' pour cette méthode. Il faudra faire un 'external restore' sur la machine cible. Voir la documentation pour les détails. Après un backup fait de cette manière, il faut aussi faire un backup des logical logs.
16:55:27 Cannot convert server. DBspace 'rootdbs' is down.
Il semble que les dbspaces soient 'down'. Il se peut qu'ils le soient parce le moteur a eu un "problème" avec, par exemple une corruption. Cela paraît tout de même étonnant dans notre cas parce qu'ils sont tous 'down'...
Ce qu'il faut faire, c'est repartir de la version précédente et s'assurer que les étapes décrites au dessus sont respectées et lancer des oncheck avant de mettre l'instance offline. Faire la copie avec un outil système ensuite.
Hope this help.
merci pour vos retours
tout ça est bien compliqué, je vais regarder
je précise que j'avais copié mes chunks l'instance offline bien sûr ;-)
Bonjour,
La xC6 a la particularité qu'il y a des changements dans les catalogues systèmes contrairement aux autres interim releases (xC4, xC5). Il se peut qu'un problème provienne indirectement de là.
Reprendre la procédure que j'ai donnée précédemment mais ne pas oublier avant de faire le shutdown de l'instance de lancer aussi onmode -lc ce qui va changer de logical log et créer un checkpoint.
Pour moi, il y a bogue quelque part étant donné que tu as fait ta copie instance offline.
Si tu peux fournir tes chunks ( ? ), je suis intéressé par tester ceci par moi-même.
Hope this help.
merci pour ta réponse,
je ne pense pas pouvoir te fournir les chunks des données confidentielles de la boîte :-/ et il faut compter 200Go de toute façon...
Apparemment la copie physique des chunks ne marche pas toujours, puisque tous les dbspaces sont down au démarrage...
De toutes façons, devant un éventuel recours au support IBM, c'est un risque énorme de fin de non-recevoir et une demande de recours à une méthode conventionnelle et supportée ( restore ontape ou onbar ).
Les chunks n'ont pas été conçus pour être manipulés à partir de l'OS, mais à partir de IDS qui est le seul à pouvoir garantir leur intégrité.
L'external backup est aussi une bonne solution, mais un peu plus complexe à mettre en oeuvre. Dans le cadre d'un clonage de système, on a toujours une archive de niveau 0 à utiliser et un peu de temps pour la restaurer sur l'instance cible, car a priori ce genre de manip se prévoit avec une certaine avance. De plus, la manip est beaucoup plus simple ( tout est fait avec la même commande, ontape ou onbar), donc moins risquée.
Voila
Bonjour,
La copie physique des chunks fonctionne toujours et est supporté par Informix. Voir la documentation. C'est d'ailleurs la méthode utilisée officiellement lors d'un 'external backup', que ce soit en bloquant le moteur pendant la copie ou en utilisant une méthode plus souple et plus "haute disponibilité", le 'mirroring'.
Le fait qu'il y ait eu un problème de dbspace down doit provenir d'un bogue comme je l'ai avancé plus haut. Une copie de chunk est une copie exacte. Ainsi toute copie qui ne le serait pas produirait des corruptions avec des effets autrement plus importants sur le moteur, génération de fichier af en pagaille. Beaucoup de dba Informix utilisent notamment le 'flash copy' système, le moteur arrêté ou bloqué, cela va de soi.
Ce message de dbspace down est typique lors de l'utilisation de la réplication lorsque l'on fait la copie du primaire sur le secondaire et que l'on fait un changement de version en même temps. Ceci n'est pas supporté. Dans notre cas et si il n'y a pas de réplication en jeu, je pense que c'est un comportement anormal. C'est pourquoi, le bogue me paraît plus que probable ou le mauvais état des dbspaces avant copie ( ? ), problème de transfert entre machine ( ? ).
Pour revenir à l'external backup, c'est la méthode la plus sûr et la plus rapide (flash copy) mais pas du tout la plus flexible. L'utilisation d'outil du produit comme onbar ou ontape permet simplement au moteur de considérer les dbspaces comme physiquement restaurés puisqu'il n'y a pas besoin de 'physical recovery'. Ensuite, restauration des logical logs, ontape suffit. Cette méthode peut être considérée comme plus complexe, je ne le pense pas. Elle est en tout cas moins génératrice de problème parce que moins de produits sont utilisés (storage manager) et ceux qui le sont (onbar, ontape) le sont moins intensivement.
Tout ça est dans le cas d'une migration d'une machine vers une autre. L'utilisation flexible que permet onbar avec des gros volumes de données et un besoin de très haute disponibilité ne peut "pas vraiment" permettre le bloquage, même court, d'une instance ou d'avoir recours à des fenêtres de maintenance pour son arrêt.
Hope this help.
eh bien en fait si, les chunks proviennent d'un secondary d'un HDR (je ne peux pas arrêter le primary donc je me suis tourné vers le secondary...)
merci
je n'ai pas réussi à me servir d'ontape (apparemment on ne peux pas sur un secondary?) donc je ferai une copie des chunks étant donné que mon serveur destination est maintenant exactement le même que la source
merci à vous tous
bonjour, je suis de retour...
je n'arrive pas à passer ma base en read-only vers le mode online
j'ai utilisé onmode -m mais ça ne change rien
merci pour votre aide!
édit: c'est bon j'ai réussi à coups d'onmode -d standard et onmode -m ;-)
Utile la doc, non?
bonjour,
j'ai dû refaire la même manip' (copie des chunks du secondaire pour créer une base de test) et cette fois-ci la nouvelle instance ne se lance même pas:
j'obtiens cette erreur:
13:40:36 DR: Trying to connect to primary server = ntopcaim_tcp
13:40:36 DR: Secondary server connected
13:40:36 Onconfig parameter STORAGE_FULL_ALARM modified from 0 to 3.
13:40:36 DR: Receive error
13:40:36 ASF Echo-Thread Server: asfcode = -25582: oserr = 0: errstr = : Networ
k connection is broken.
13:40:36 DR_ERR set to -1
13:40:36 IBM Informix Dynamic Server Stopped.
merci d'avance pour votre aide
apparemment il y a eu un souci lors de la copie des chunks...
Bonjour,
-25xxx indique une rupture de communication. Un problème de réseau ou quelque chose du genre...
Les causes sont en général:
* un problème de réseau,
* changement dans les ip/hostnames
* changement dans le firewall
* changement dans les lignes de sqlhosts concernées
Statistiquement, c'est le premier que tu devrais ressentir...
Eric
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager