ORA-00600 sur 11g

Version imprimable

ORA-00600 sur 11g

bonjour,

J'ai un message sur ma base 11g (un seul message, une seule fois)
Code:

1 2 3 Une erreur interne (ORA-600[krbmror_sameline_2]) a été détectée dans D:\app\administrateur\diag\rdbms\ma_base\alert\log.xml (incident=13569): ORA-00600: code d'erreur interne, arguments : [krbmror_sameline_2], [416], [704], [763046841], [763995631], [414], [704], [763045223], [763995631], [], [], []
il y a un fichier "trace" qui dit ceci :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ** 2011-10-08 13:26:19.561 *** SESSION ID:(115.52036) 2011-10-08 13:26:19.561 *** CLIENT ID:() 2011-10-08 13:26:19.561 *** SERVICE NAME:(SYS$USERS) 2011-10-08 13:26:19.561 *** MODULE NAME:(rman.exe) 2011-10-08 13:26:19.561 *** ACTION NAME:(0000003 FINISHED114) 2011-10-08 13:26:19.561 *** 2011-10-08 13:26:19.561 2046 krse.c Archived Log entry 3209 added for thread 1 sequence 1313 ID 0xa51a85f dest 1: A:\PROD\ARC0000001313_0761319400.0001 *** 2011-10-08 13:30:20.152 *** ACTION NAME:(0000022 FINISHED129) 2011-10-08 13:30:20.152 Incident 13569 created, dump file: d:\app\administrateur\diag\rdbms\ma_base\incident\incdir_13569\prod_ora_11864_i13569.trc ORA-00600: code d'erreur interne, arguments : [krbmror_sameline_2], [416], [704], [763046841], [763995631], [414], [704], [763045223], [763995631], [], [], []
Par ailleurs, dans ce répertoire "trace", j'ai un nouveau dossier à la date & heure du problème, avec tout un tas de fichiers "buckets" trc & trm...Qu'est ce que c'est que çà .... ?:cry:

Quand je regarde via OEM, le récapitulatif des dignostics, j'ai "aucune alerte ORA" & "incidents actifs = 0"...

Ma base semble tourner normalement....

Je ne sais pas trop quoi faire...s'il y a quelque chose à faire ?!

Par ailleurs, est ce normal que j'ai autant de fichiers "trace" ?? Cela se "nettoie" t-il ?

10/10/2011, 08h48
nancy_carina

Bonjour Olivier ,
essais de suivre les étapes suivantes http://mrrame.blogspot.com/2011/02/o...arguments.html
;)
10/10/2011, 09h32
olivanto

merci, W !

mais j'ai quand même un doute ; tout tourne normalement sur la base, les ARCHIVELOGS comme le backup via RMAN se comportent bien. Pourquoi une restauration ?

:cry::aie:
10/10/2011, 09h59
nancy_carina

Cette erreur est probablement a cause d'un crash de vérification de données en mémoire , dans ce cas, une restauration est toujours nécessaire, :)
et tu as la vue v$diag_info a interroger pour mieux cerner ton problème ;)
10/10/2011, 10h19
olivanto

ok, j'ai été voir cette vue, et elle me donne qq indications.

mais je répugne quand même à lancer une restauration de base, que je ne maitrise pas trop (je suis tétu ! )

S'il y a eu pb de vérification des données en mémoire (rien n'est sûr), cela ne semble pas (mais je ne suis pas un grand DBA...) avoir un quelconque impact. La base tourne, les jobs RMAN aussi, l'archivage se fait correctement...

Concrètement, qu'est ce que je gagne à faire une restauration (en dehors du fait de risquer de me planter, vu comment c'est pas simple....:lol:) ?

:cry:
10/10/2011, 19h53
Heaven93

bonjour,

c'est juste un bug (BUG 10098253).
le workaround consiste à enlever le "set echo on" du script RMAN.
le bug est corrigé en 11.2.0.3.

si ta base redémarre correctement quand tu l'arrêtes, je ne vois pas très bien l'intérêt de revenir à une sauvegarde antérieure.

pour purger le repertoire diag, l'utilitaire oracle ADRCI est plutôt bien. il sert aussi pour le diagnostic des incidents.
10/10/2011, 23h54
olivanto

Citation:

Envoyé par Heaven93

bonjour,
si ta base redémarre correctement quand tu l'arrêtes, je ne vois pas très bien l'intérêt de revenir à une sauvegarde antérieure.

ouaip, encore que ....tant que je n'ai pas fait le test .. !
il va bien falloir que je prenne le risque, visiblemement....

bon, vivement la fin de semaine (je peux "jouer" avec la base de données à ce moment...) pour tester...

merci.
11/10/2011, 13h25
Heaven93

essaie de ne pas purger tes vieilles sauvegardes valides quand même.
non, en effet, rien ne dit qu'il y ait corruption en mémoire d'après les arguments de l'ora 600. donc, pas de panique.
et essaie de corriger la cause du problème (correction du script rman si nécessaire déjà et éventuellement patcher) ce qui évitera de nouveaux stress. c'est une base de production?
tu as jeté un oeil dans les traces générées au moment du problème? ça dit quoi?
11/10/2011, 16h45
olivanto

tout d'abord, merci de ton aide.

la trace générée au moment du pb est tout en haut ; si tu veux autre chose pour te faire une idée, dis moi quoi ?

le script RMAN, il a été généré via l'interface, je veux bien le corriger, ou le refaire, pas de pb !

le pb a eu lieu au moment ou RMAN faisait un backup de la base. Je me demande s'il ne s'est pas emmelé les pinceaux avec un autre job, qui lui nettoie les ressources obsolètes...
11/10/2011, 18h27
Heaven93

et la sauvegarde de ce jour-là, elle est ok?
tu en as refait depuis?
11/10/2011, 22h34
olivanto

j'ai une sauvegarde (programmée via l'interface graphique) qui tourne tout les jours, sans aucun problème (travaux ok, fichiers bien à la date de la dernière sauvegarde). Plus un dump (je sais, ca vaut pas une sauvegarde, mais c'est mieux qui rien) qui tourne lui aussi sans soucis (programmé lui aussi via l'interface graphique).