Discussion :

[jf4db]

Bonjour,

Je suis en train de mettre en place mon premier environnement 9I(9.2.0.6)RAC composé de deux instances INST1 et INST2 . Tout à l'aire de bien fonctionner tant que les process oracm fonctionnent . Si je fais un reboot violent (genre coupure electrique )sur le noeud2 pour tester la haute dispo je me rend conte que l'instance INST (composé de INST1 et INST2) se crache completement... alors que INST1 devrait continuer à tourner...RAC n'est pas sensé gérer ce genre de problème ?
Faut-il que les process oracm tourne pour garantir le bon fonctionnment de RAC? Ai-je oublié un paramétrage ?

Par contre si les deux noeuds systemes tournent avec leurs process oracm pas de problème quand je lance des arrets violents d'instance.

Je fouille les docs

Merci pour vôtre aide.

[jf4db]

Je viens de m'apercevoir que j'ai le même problème en faisant un kill des process oracm sur un noeud..la base tombe aussi...

[LeoAnderson]

dans le noeud qui est censé rester up, que disent les alertes ?

quel est le système de fichier du cluster ? ASM ?

[jf4db]

dans le noeud qui est censé rester up, que disent les alertes ?

quel est le système de fichier du cluster ? ASM ?

Type de fichier OCFS et voici le contenu de l'alerte lors du crash :

alertes :

Fri Jul 27 16:37:56 2007
Errors in file XXXX/bdump/toto1_lck0_10029.trc:
ORA-07445: exception encountered: core dump [skgxpdmpctx()+183] [SIGFPE] [Integer divide by zero] [0x7C1E3F] [] []


Peut-être un problème de hangchecktimer car bien paramétré au niveau oracm mais lorsque je lance un lsmode je vois bien qu'il est loadé sur les 2 noeuds mais 'not used' lorsque les bases tournent...

[LeoAnderson]

C'est un bug corrigé en 9.2.0.7 ==> upgradez

Note:4145827.8

[jf4db]

C'est un bug corrigé en 9.2.0.7 ==> upgradez

Note:4145827.8

Je vais regarder ce patch. merci

Mais est-ce normal que lors d'un lsmod j'ai :

lsmod
Module Size Used by Tainted: GF
hangcheck-timer 2808 0 (unused)

On constate aucun process lié au hangchek_timer alors que sur chaque noeud oracm devrait s'appuyer dessus non?

De plus il est signallé comme unused ...

Merci

[LeoAnderson]

le hangcheck_timer n'est pas obligatoire...

http://www.rampant-books.com/art_hun...nel_module.htm

dans votre cas, il est chargé mais non utilisé... c'est tout.
mais upgradez !

[jf4db]

le hangcheck_timer n'est pas obligatoire...

http://www.rampant-books.com/art_hun...nel_module.htm

dans votre cas, il est chargé mais non utilisé... c'est tout.
mais upgradez !

[jf4db]

J'ai installé le Patch 9.2.0.7 qui a résolu ce problème .

Merci bien LeoAnderson .

[jf4db]

Une question encore :

Le noeud principal doit toujours rester up?

exemple :
noeud1 = principal
noeud 2 = secondaire

si je reboot noeud2 l'instance RAC continue de tourner sur 1 noeud
si je reboot noeud1 l'instance RAC tombe

Est-ce normal?

le noeud2 est dépendant du noeud1 ?

La notion de cluster est sensée gerer la chutte de n'importe quel des noeuds non?

[LeoAnderson]

ce fonctionnement n'est pas normal

que dit l'alert log du noeud 2 ?

[jf4db]

ce fonctionnement n'est pas normal

que dit l'alert log du noeud 2 ?

Il dit :

replication_dependency_tracking turned off (no async multimaster replication found)
Completed: ALTER DATABASE OPEN
Tue Jul 31 09:31:40 2007
Errors in file /oracle/admin/TEST9I/bdump/t2_lmon_17505.trc:
ORA-29702: error occurred in Cluster Group Service operation
Tue Jul 31 09:31:40 2007
LMON: terminating instance due to error 29702
Instance terminated by LMON, pid = 17505
Tue Jul 31 09:34:12 2007
Starting ORACLE instance (normal)
Tue Jul 31 09:34:12 2007
global Enqueue Service Resources = 4086, pool = 2
Tue Jul 31 09:34:12 2007


Je regarde en même temps sur metalink ...

[LeoAnderson]

Il dit :

replication_dependency_tracking turned off (no async multimaster replication found)
Completed: ALTER DATABASE OPEN
Tue Jul 31 09:31:40 2007
Errors in file /oracle/admin/TEST9I/bdump/t2_lmon_17505.trc:
ORA-29702: error occurred in Cluster Group Service operation
Tue Jul 31 09:31:40 2007
LMON: terminating instance due to error 29702
Instance terminated by LMON, pid = 17505
Tue Jul 31 09:34:12 2007
Starting ORACLE instance (normal)
Tue Jul 31 09:34:12 2007
global Enqueue Service Resources = 4086, pool = 2
Tue Jul 31 09:34:12 2007


Je regarde en même temps sur metalink ...

et le /oracle/admin/TEST9I/bdump/t2_lmon_17505.trc ??

mais metalink n'est pas avare à propos de la ora-27902 !

[jf4db]

PAs faux

Il y en a une floppée


voici le log :

res_master_weight for node 0 is 3898
res_master_weight for node 1 is 3898
Total master weight = 7796
Dead inst
Join inst 0 1
Exist inst
Active Sendback Threshold = 50 %
Communication channels reestablished
Master broadcasted resource hash value bitmaps
Non-local Process blocks cleaned out
Resources and enqueues cleaned out
Resources remastered 0
0 GCS shadows traversed, 0 cancelled, 0 closed
0 GCS resources traversed, 0 cancelled
set master node info
Submitted all remote-enqueue requests
kjfcrfg: Number of mesgs sent to node 0 = 0
Update rdomain variables
Dwn-cvts replayed, VALBLKs dubious
All grantable enqueues granted
*** 2007-07-31 09:12:42.595
0 GCS shadows traversed, 0 replayed, 0 unopened
Submitted all GCS cache requests
0 write requests issued in 844 GCS resources
3 PIs marked suspect, 0 flush PI msgs
*** 2007-07-31 09:12:42.762
Reconfiguration complete
*** 2007-07-31 09:12:48.079
kjxgrtmc2: Member 1 thread 2 mounted
CMCLI WARNING: ReadCommPort: poll() failed
kjxgmpoll: skgxn error (12 2)
Return code from kjxggpoll: 10
error 29702 detected in background process
ORA-29702: error occurred in Cluster Group Service operation
ksuitm: waiting for [5] seconds before killing DIAG

[jf4db]

je me demande si le problème n'est pas lié à ma version de oracm que je n'ai pas pu upgrader lors de mon install 9.2.0.7...

ma version 9.2.0.2.0.47
Metalink parle d'upgrader en 9.2.0.2.0.49


Metalink en parle un peu donc je vais fouiller dans ce sens

[jf4db]

je me demande si le problème n'est pas lié à ma version de oracm que je n'ai pas pu upgrader lors de mon install 9.2.0.7...

ma version 9.2.0.2.0.47
Metalink parle d'upgrader en 9.2.0.2.0.49


Metalink en parle un peu donc je vais fouiller dans ce sens

Pour corrigé les crash suite à arret noeud 1 par kill oracm :
Je suis passé en oracm 9.2.0.2.0.49 et j'ai du mettre à jour le repertoire lib sur le neoud 2

Maintenant d'autres pb genre le listener ne se met pas à jour tout seul lors de l'arret violent d'un noeud et obligé de faire un reload...