synchronisation fichiers dbf

Salut a tous
base 9.2.0.1 solaris 9

supposons que j'ai 3 fichiers journaux avec les numéro de sequence 10,11 et 12 (current 12)
quand j'essaye d'ouvrir une base de données oracle me dit qu'un fichier de données de la base(non system) nécessite une récupération (need media recovery).
est il normal qu'il me demande une sequence n° 6 de fichier archive nécessaire pour la récupération de ce fichier ? Si oui dans quel cas ce scénario peut-il arriver?

ce que je sais de la mécanique de oracle c'est qu'un fichier journal en ligne ne peut être écrasé s'il est nécéssaire à la récupération(status=ACTIVE dans v$log).Donc comment peut-il me demander une sequence autre que celle des fichiers journaux en ligne?

tu a lu mon article : http://mbouayoun.developpez.com/fichredo/ ?

Citation:

---

est il normal qu'il me demande une sequence n° 6 de fichier archive nécessaire pour la récupération de ce fichier ? Si oui dans quel cas ce scénario peut-il arriver?

---

Oui c'est normal car comme tu l'a dit dans ton titre que les fichers dbf ne sont pas synchronisés (avec le fichier de contrôle)

Citation:

---

Donc comment peut-il me demander une sequence autre que celle des fichiers journaux en ligne?

---

Quand tu monte la base, Oracle lit en premier le fichier de contrôle et dans ce fichier se trouve le numéro de sequence des fichiers redo, les historiques redo etc . pour plus d'info tu peut lire mon article :
http://mbouayoun.developpez.com/Fctladm/

Bouayo je connais parfaitement ce k'il y'a dans les liens que tu m'indique.J'ai pas un problême de compréhension de ces notions fondamentales .Si je me suis mal exprimé je reformule ma question :

En partant du principe que

1-je n'ai restauré aucun fichier à partir d'une ancienne sauvegarde (donc normalement pas de grand décalage entre fichiers dbf)

2- que je ne suis pas entrain d'essayer de récupérer une base mais juste entrain d'essayer de la démarrer

3-que independament du mode NOARCHIVELOG ou ARCHIVELOG un fichier journal en ligne ne peut etre ecrasé s'il est actif (nécessaire pour la récupération d'un fichier dbf càd contient des transactions non encore appliqués sur ce fichier)

comment peux-il me demander un numéro de sequence autre qu'un fichier journal en ligne?Bouayo si tu peux me donner un exemple concret ça serait bien.

En fait pour vous dire la vérité je soupçonne quelqu'un d'avoir restauré une ancienne version du fichier a partir d'une sauvegarde

Citation:

---

En fait pour vous dire la vérité je soupçonne quelqu'un d'avoir restauré une ancienne version du fichier a partir d'une sauvegarde

---

C'est possible

une autre possibilité c'est la fameux

Code:

---

shutdown abort

---

ou un arrête brutale de la machine ca peut desynchronisé les fichiers bdf , redo et les fichiers de contrôles.

Je te conseille de voir dans le fichiers alert s'il y'a un arrête brutal.

Bouyao même après un shutdown abort on ne devrait pas trouver un fichier dbf nécessitant un fichier archive dont la sequence est plus ancienne que les redo online.

Si j'utilise ton raisonnement cela impliquerait que en mode noarchivelog oracle permetterait l'ecrasement des journaux malgré qu'ils sont actifs et aussi que si je fais un shutdown abort je risque de perdre ma base de données or ce n'est pas vrai car un shutdown abort provoque uniquement un crash d'instance(et non pas une défaillance physique) et par définition un crash d'instance ne nécessite pas d'internvention du dba pour la récupération(pas de RECOVER), c'est le SMON qui s'en charge automatiquement en faisant une lecture de ce qu'il y'a dans les fichiers redo online uniquement(et non pas archive).C'est ce ki est ecrit dans les manuels Oracle Education.

Tu trompe, Un shutdown abort peut corrompre ta base.

Je suis sur qu'avec un shutdown abort je vais effectivement avoir des fichiers non synchronisés mais le SMON les resynchornisera avec les journaux online.Tu peux verifier dans le cours DBA-II 9i qu'il n'ya pas de récupération nécessaire par le dba lors d'un crash d'instance(sauf bien sur s'il y'a defaillance physique).

Ceci dit tu affirme le contraire

"Tu trompe, Un shutdown abort peut corrompre ta base"

et c'est la ma question .Est ce ke tu peux me donner un scénario ou cela peux arriver ?

J'ai eu le cas. Il devait être en train d'écrire dans le control ou je ne sais quoi, mais toujours est-il qu'il considérais un dbf comme étant plus récente que tous les autres fichiers alors qu'il était comme les copains (ORA-01207)

Et là, pas moyen d'ouvrir la base...


Et la cause : un shutdown abort !!!
(ok, c'était un peu fait exprès..)

Moi aussi j'ai eu la cas. Ca fait 2 ans.
un collegue à fait un shutdown abort pendant l'ecriture dans un fichier de journalisation ce qui a fait corrompre ce fichier.
Autre chose en mode archivelog si le disque est plein.
c'est une sorte de loterie : sur 100 abort tu peut avoir une corruption

Merci pour vos reponses.donc si je comprends bien c un bug oracle ?

NB : voici l'erreur ke j'ai ORA-01113 file 9 need media recovery.Oracle suppose qu'il plus ancien que les autres contrairement au cas d'Anderson.

personnellement, je ne considère pas que cela est un bug car le shutdown abort est reservé à des situations très particulières (rien ne va déjà plus) et/ou que l'on souhaite faire des tests.
C'est un tout petit peu moins violent que le kill -9 du pmon, mais guère...

anderson pour le cas qui t'est arrivé je crois qu'il suffit de recréer le fichier de controle avec un script.Pour mon cas c'est différent car oracle entrain de me demander un numéro de sequence précis(qui est nettement plus ancien que les redo online).autre chose j'ai vérifié les fichiers trace pas de shutdown abort effectué par contre j'ai effectivement un probleme de saturation de disque

Citation:

---

Envoyé par comment_ca

anderson pour le cas qui t'est arrivé je crois qu'il suffit de recréer le fichier de controle avec un script.

---

Je sais bien, mais cela oblige à faire un open reset logs ce qui est BEAUCOUP plus pénalisant qu'une restauration.
Sans compter qu'avec la restauration, je suis sûr de ce que j'ai à l'arrivée... ;-)