Tablespace système à recréer ou controlfile ?

Version imprimable

Voir 40 message(s) de cette discussion en une page

06/12/2019, 23h59
Thomf

Tablespace système à recréer ou controlfile ?

Bonjour,

Au démarrage de notre base oracle 8 (et oui) que nous utilisons pour quelques mois encore avant de migrer en 11 ou en 12, j'ai d'abord rencontré l'erreur ORA-01033: ORACLE initialization or shutdown in progress au démarrage du listener.

Après quoi j'ai un peu scruté et regardé le fichier Alert.log qui m'a indiqué une erreur ORA-01110 relatif à un fichier systeme 'SYSTEM01.DBF'.

Aussi j'ai suivi ce lien https://www.developpez.net/forums/d1...tion-datafile/

Sauf que là il s'agit d'un fichier système et je ne sais pas si après avoir supprimé celui du tablespace ou du disque je dois recrée quelque chose derrière ou exécuter des fichiers, genre dbms-stats.

Qu'importe, j'ai fait un recovery qui a plutôt bien marché et au moment de faire 'alter database open', je rencontre l'erreur et dans le fichier Alert.log, j'ai l'origine du problème:

Citation:

Errors in file D:\oracle\admin\EURO\udump\ORA02448.TRC:
ORA-00600: internal error code, arguments: [2662], [2], [1517443071], [2], [1518058603], [8388610], [], []

Fri Dec 06 16:35:53 2019
Errors in file D:\oracle\admin\EURO\udump\ORA02448.TRC:
ORA-00600: internal error code, arguments: [2662], [2], [1517443073], [2], [1518058603], [8388610], [], []
ORA-00600: internal error code, arguments: [2662], [2], [1517443071], [2], [1518058603], [8388610], [], []

Fri Dec 06 16:36:22 2019
Errors in file D:\oracle\admin\EURO\udump\ORA02448.TRC:
ORA-00600: internal error code, arguments: [2662], [2], [1517443073], [2], [1518058603], [8388610], [], []
ORA-00600: internal error code, arguments: [2662], [2], [1517443071], [2], [1518058603], [8388610], [], []

Fri Dec 06 16:36:50 2019
Errors in file D:\oracle\admin\EURO\udump\ORA02448.TRC:
ORA-00603: ORACLE server session terminated by fatal error
ORA-00600: internal error code, arguments: [2662], [2], [1517443073], [2], [1518058603], [8388610], [], []
ORA-00600: internal error code, arguments: [2662], [2], [1517443071], [2], [1518058603], [8388610], [], []

Aussi ma question est de savoir si le problème vient de mes CONTROL_FILE ou bien de mon fichier système 'SYSTEM01.DBF' (si je dois recréer celui-ci en SYSTEM02.DBF ?).

Eventuellement que dois-je faire des fichiers *.TRC du dossier udump.

Bon week-end

Thomas
08/12/2019, 10h04
Thomf

Bonjour,
Il y a autre chose que j'avais pensé faire: copier tous les datafiles et controlfile de la veille (base fermée) et importer les tables qui ont subit des modifications. Ne serait-ce pas la meilleure solution ?

Cet après-midi: je précise qu'après avoir fait un recover database using backup controlfile, j'ai le message suivant concernant un fichier d'archive qui a disparu:

Citation:

ORA-27041: unable to open file OSD-04002: unable to open

Et ensuite après avoir testé 'alter database open norestelogs ou resetlogs' Oracle m'oblige à utiliser ce dernier sauf que j'en reviens à ce message 'ORA-01245: ofline file 1 will be lost if done' ou bien 'ORA-01110: Datafile 1: nom du datafile' sachant que ces 2 options sont obligatoires.

D'avance merci pour vos contributions

Thomas
08/12/2019, 16h57
pachot

Bonjour,
L'enchaînement des erreurs et des actions décrites ici n'a aucun de sens. Sans comprendre quel est le problème les actions effectuées n'ont probablement fait que rajouter des problèmes. Si les données dans cette base sont importante, il me paraît indispensable de faire appel à un DBA Oracle expérimenté. Ce n'est pas une chose à résoudre dans un forum. Et je pense que c'est pour ça que vous n'avez pas de réponse ici: lorsque j'ai vu la question hier j'ai préféré ne pas répondre. Mais là je vois que vous risquez de tout rendre encore plus inconsistent.
Si vous avez un backup de la base et des archived logs, essayez de restaurer celà sur un autre serveur. Au moins pour voir ce qui est récupérable. Si vous ne pouvez pas faire appel à un professionnel, prenez le temps, sur cet autre serveur, de bien comprendre (= lire beaucoup) comment fonctionne le restore / recovery.
Franck.
08/12/2019, 18h04
Thomf

Citation:

Envoyé par pachot

Bonjour,
L'enchaînement des erreurs et des actions décrites ici n'a aucun de sens. Sans comprendre quel est le problème les actions effectuées n'ont probablement fait que rajouter des problèmes. Si les données dans cette base sont importante, il me paraît indispensable de faire appel à un DBA Oracle expérimenté. Ce n'est pas une chose à résoudre dans un forum. Et je pense que c'est pour ça que vous n'avez pas de réponse ici: lorsque j'ai vu la question hier j'ai préféré ne pas répondre. Mais là je vois que vous risquez de tout rendre encore plus inconsistent.
Si vous avez un backup de la base et des archived logs, essayez de restaurer celà sur un autre serveur. Au moins pour voir ce qui est récupérable. Si vous ne pouvez pas faire appel à un professionnel, prenez le temps, sur cet autre serveur, de bien comprendre (= lire beaucoup) comment fonctionne le restore / recovery.
Franck.

Bonjour,

En gros, j'ai le même problème que le lien suivant sauf que je ne peux pas faire alter database open. Or tant que je ne peux faire cela je ne peux dropper le tablespace corrompu:

https://www.developpez.net/forums/d1...tion-datafile/

Pour ce qui est du DBA expérimenté je n'ai que Oracle my support qui met un peu de temps à répondre et sans contact direct. J'ai vu dans le forum que beaucoup de gens ont résolu le même problème. Donc je ne veux pas prendre le risque. même si les utilisateurs me mettent un peu sous pression en croyant que le problème se résout en 5mn. Pour un DBA expérimenté je dirais oui, pour moi c'est plus difficile.
J'ai un backup de la base mais étrangement pas des archived logs. Je pensais soit recréer la base sous un autre nom et dans un autre dossier soit copier la sauvegarde de jeudi par-dessus sur celle qui est corrompue et redémarrer la base de cette manière.
Merci de m'avoir répondu
Thomas
08/12/2019, 18h38
pachot
Citation:

je n'ai que Oracle my support

C'est déjà pas mal d'avoir le support pour une version si vielle

Citation:

en croyant que le problème se résout en 5mn

Un problème de corruption sur une version si vielle ne se résoud pas en 5 minutes, même pour qqn d'expérimenté.

Citation:

J'ai un backup de la base mais étrangement pas des archived logs

Est-tu sûr qu'il n'y a pas les archivelogs disponibles. En MOUNT tu peux voir:

Code:

select name,next_time from v$archived_log order by first_change#

Mais pas si tu as recréé le controlfile. Dans ce cas, essaie de trouver la destination:
Code:

1 2 select name,value from v$parameter where name like 'log_archive_dest__' and value is not null show parameter db_recovery_file_dest
Citation:

copier celle de jeudi soir

Si c'est un backup à froid (base arrêtée) oui. Mais sinon tu ne pourras pas l'ouvrir sans les archived logs.
08/12/2019, 20h54
Thomf

Citation:

Envoyé par pachot

Est-tu sûr qu'il n'y a pas les archivelogs disponibles. En MOUNT tu peux voir:

Sur cette requête j'ai l'erreur ORA-01220 file based sort illegal before database is open.

Aussi j'ai retiré le tri mais il me manquerait le fameux fichier d'archive qui aurait disparu. Tous les autres sont là.

Citation:

Envoyé par pachot

Mais pas si tu as recréé le controlfile. Dans ce cas, essaie de trouver la destination:

A ma connaissance, je n'ai pas recrée les controlefile. Ta requête me donne bien la destination des fichiers d'archive que je connaissais déjà
Le show parameter db_recovery_file_dest ne me donne rien.

Citation:

Envoyé par pachot

Si c'est un backup à froid (base arrêtée) oui. Mais sinon tu ne pourras pas l'ouvrir sans les archived logs.

Oui le backup est bien à froid. Aussi je peux alors me lancer ? Et quid des archives_log existants, je les supprime ? Si tout se passe bien je n'ai plus qu'à réimporter les tables qui me concernent.
08/12/2019, 21h03
pachot
Ok, donc il doit être possible re restaurer le backup à froid, et déjà ce sera consistent.
Ensuite, appliquer le maximum d'archived log disponibles (recover) et la base devrait pouvoir être ouverte en resetlogs

Citation:

Et quid des archives_log existants, je les supprim

Non, ils peuvent servir à avancer un peu la base

Citation:

Si tout se passe bien je n'ai plus qu'à réimporter les tables qui me concernent.

Oui si l'export est plus récent que le point où le recovery est arrivé.

Pour voir jusqu'à quel point le recovery est arrivé:
Code:

1 2 select scn_to_timestamp(current_scn) from v$database;
08/12/2019, 21h17
Thomf

Si il n'y a pas de risque, je peux me lancer sachant qu'Oracle peut mettre du temps à répondre. ça va faire chaud du côté de Notre-dame de Paris, là où je bosse :D

A moins d'attendre Oracle...
08/12/2019, 21h20
pachot

Effectivement, le support Oracle peut ne pas être très rapide...
Mais comme je le disais il serait préférable de le faire sur une autre machine. Ou au moins de faire un backup complet de la situation actuelle au cas ou.
08/12/2019, 21h22
Thomf

Le problème c'est que je n'ai pas beaucoup de machines disponibles. Je voulais le faire sur la même machine dans un autre dossier si possible ou en écrasant les fichiers existants (après les avoir copié). Et j'en ai pour 56Go.
09/12/2019, 10h14
Thomf

Bonjour,

J'ai décidé de faire un robocopy de ma base car cela prenant trop de temps. Une fois la base recopiée, j'ai pas trop compris, dois-je faire un recover ?

Thomas
09/12/2019, 17h14
pachot

oui, l'idée est restore (des datafiles à partir du backup) et recover (du maximum d'archivelogs disponibles)
09/12/2019, 17h23
Thomf

Citation:

Envoyé par pachot

oui, l'idée est restore (des datafiles à partir du backup) et recover (du maximum d'archivelogs disponibles)

A partir du moment où j'ai recopié les datafiles, je fais un startup mount suivi d'un alter database open resetlogs puis recover database (avant ou après avec ou sans database using backup controlfile until cancel) voie même un 'ALTER DATABASE BACKUP CONTROLFILE TO TRACE;', je ne sais plus trop l'ordre et l'importance à vrai dire. Le possible soucis c'est que mon tablespace SYSTEM est peut-être offline donc je vais le mettre online avant de faire tout ça.

Pour le moment rien n'est fait car depuis ce matin je suis toujours sur mon robocopy où il a fait les 3/4. Je ferais la copie de la sauvegarde dans la nuit depuis chez moi.
09/12/2019, 17h29
pachot

le RECOVER se fait en MOUNT, avant l'OPEN.
09/12/2019, 23h13
Thomf

Depuis 18h30 mon robocopy est toujours bloqué sur le même fichier de 1,8Go et je suis embêté. De plus Oracle ne donne pas beaucoup de nouvelles et les utilisateurs s'impatientent.
10/12/2019, 08h07
pachot

Citation:

Envoyé par Thomf

Depuis 18h30 mon robocopy est toujours bloqué sur le même fichier de 1,8Go

Le but du robocopy c'est de sauvegrder la situation actuelle avant de l'écraser avec le backup de jeudi. A mon avis c'est indispensable. D'autant plus que je suppose que le restore de backup n'a jamais été testé donc on ne sait pas si le backup est ok.

Citation:

Envoyé par Thomf

Oracle ne donne pas beaucoup de nouvelles

Pour avoir un suivi régulier il faut passer en Severité 1 mais cela oblige a avoir un contact 24/7 donc si tu es tout seul côté client c'est impossible.

Citation:

Envoyé par Thomf

les utilisateurs s'impatientent.

Ils ont raisons de s'impatienter. Mais ce n'est pas une raison pour prendre plus de risques de faire des bêtises. Il faut les adresser au responsable qui a décidé un jour d'opérer une base de donnée importante
- sans avoir de DBA expérimenté (plusieurs internes ou contrat SLA avec une entreprise sérieuse)
- en restant sur un version qui n'a plus de correction de bugs ou faille depuis plus de 13 ans!
- qui n'investit pas dans un serveur de spare pour pouvoir faire un restore de base
- qui ne planifie aucun test de restore pour valider la technique de backup et les compétences de restore
- ...

Il faut être clair que ces choix sont une erreur qui amènent à la perte des données, pour lesquelles ni toi ni Oracle n'est responsable. Avec un peu de chance et en y mettant les moyens, il y a peut-être moyen de récupérer les données jusqu'à un certain point, mais sans aucune garantie du temps que ça peut mettre.
10/12/2019, 09h41
Thomf

Bonjour Pachot,

Citation:

Envoyé par pachot

Le but du robocopy c'est de sauvegrder la situation actuelle avant de l'écraser avec le backup de jeudi. A mon avis c'est indispensable. D'autant plus que je suppose que le restore de backup n'a jamais été testé donc on ne sait pas si le backup est ok.

J'ai pu restaurer rapidement les datafiles du 26/11/2019, c'est déjà ça.

Citation:

Envoyé par pachot

Pour avoir un suivi régulier il faut passer en Severité 1 mais cela oblige a avoir un contact 24/7 donc si tu es tout seul côté client c'est impossible.

J'ai demandé à passer en sévérité 1.

Citation:

Envoyé par pachot

Ils ont raisons de s'impatienter. Mais ce n'est pas une raison pour prendre plus de risques de faire des bêtises. Il faut les adresser au responsable qui a décidé un jour d'opérer une base de donnée importante
- sans avoir de DBA expérimenté (plusieurs internes ou contrat SLA avec une entreprise sérieuse)
- en restant sur un version qui n'a plus de correction de bugs ou faille depuis plus de 13 ans!
- qui n'investit pas dans un serveur de spare pour pouvoir faire un restore de base
- qui ne planifie aucun test de restore pour valider la technique de backup et les compétences de restore
- ...

Il faut être clair que ces choix sont une erreur qui amènent à la perte des données, pour lesquelles ni toi ni Oracle n'est responsable. Avec un peu de chance et en y mettant les moyens, il y a peut-être moyen de récupérer les données jusqu'à un certain point, mais sans aucune garantie du temps que ça peut mettre.

J'ai eu une formation DBA il y a 12 ans et mon dernier recover date d'il y a 10 ans. Depuis, j'ai un peu perdu la main il est vrai.
On va passer prochainement sous Oracle 12 avec l'acquisition d'un serveur.
Pour Oracle 8, nous n'avons pas de contrat SLA et je suis un peu face à moi-même.

Depuis ce matin , j'ai fait un MOUNT et un RECOVER mais cette fois-ci je rencontre l'anomalie sur un autre datafile:

Citation:

ORA-01190: controlfile or datafile 36 is before the last RESETLOGS
ORA-01110: datafile 36: d:\oracle\oradata\agir\Agir_index.dbf'

J'ai fait un 'Alter database backup controlfile to trace' qui me donne cela

Citation:

STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "EURO" NORESETLOGS ARCHIVELOG
MAXLOGFILES 32
MAXLOGMEMBERS 2
MAXDATAFILES 254
MAXINSTANCES 1
MAXLOGHISTORY 29041
LOGFILE
GROUP 1 'D:\ORACLE\ORADATA\EURO\REDO01.LOG' SIZE 1M,
GROUP 2 'D:\ORACLE\ORADATA\EURO\REDO02.LOG' SIZE 1M,
GROUP 3 'D:\ORACLE\ORADATA\EURO\REDO03.LOG' SIZE 1M
DATAFILE
'D:\ORACLE\ORADATA\EURO\SYSTEM01.DBF',
'D:\ORACLE\ORADATA\EURO\RBS01.DBF',
'D:\ORACLE\ORADATA\EURO\USERS01.DBF',
'D:\ORACLE\ORADATA\EURO\TEMP01.DBF',
'D:\ORACLE\ORADATA\EURO\TOOLS01.DBF',
'D:\ORACLE\ORADATA\EURO\INDX01.DBF',
'D:\ORACLE\ORADATA\EURO\TS1_DOMUS_DATA2.DBF',
'D:\ORACLE\ORADATA\EURO\TS1_DOMUS_DATA.DBF',
'D:\ORACLE\ORADATA\EURO\TS2_DOMUS_IND2.DBF',
'D:\ORACLE\ORADATA\EURO\TS2_DOMUS_IND.DBF',
'D:\ORACLE\ORADATA\EURO\TS1_EHC_DATA.DBF',
'D:\ORACLE\ORADATA\EURO\TS1_EHC_INDEX.DBF',
'D:\ORACLE\ORADATA\EURO\TS3_OUTILS.DBF',
'D:\ORACLE\ORADATA\EURO\TS2_OUTILS.DBF',
'D:\ORACLE\ORADATA\EURO\TS1_OUTILS.DBF',
'D:\ORACLE\ORADATA\EURO\TS1_HQUIV4.DBF',
'D:\ORACLE\ORADATA\EURO\TS1_HQUIV3.DBF',
'D:\ORACLE\ORADATA\EURO\TS1_HQUIV2.DBF',
'D:\ORACLE\ORADATA\EURO\BO.DBF',
'D:\ORACLE\ORADATA\EURO\HISTO.DBF',
'D:\ORACLE\ORADATA\EURO\IND_HISTO.DBF',
'D:\ORACLE\ORADATA\EURO\IND_HISTO_T.DBF',
'D:\ORACLE\ORADATA\EURO\IND_STRUCT.DBF',
'D:\ORACLE\ORADATA\EURO\STRUCT.DBF',
'D:\ORACLE\ORADATA\EURO\TAB_HISTO.DBF',
'D:\ORACLE\ORADATA\EURO\TAB_HISTO_T.DBF',
'D:\ORACLE\ORADATA\EURO\TAB_STRUCT.DBF',
'D:\ORACLE\ORADATA\EURO\AGIR_DATA.DBF',
'D:\ORACLE\ORADATA\EURO\TEMPORARY.DBF',
'D:\ORACLE\ORADATA\EURO\TS1_DOMUS_IND2.DBF',
'D:\ORACLE\ORADATA\EURO\TS1_DOMUS_IND1.DBF',
'D:\ORACLE\ORADATA\EURO\FIAMOFI_DATA.DBF',
'D:\ORACLE\ORADATA\EURO\FIAMOFI_INDEX.DBF',
'D:\ORACLE\ORADATA\EURO\MIG_PREM.DBF',
'D:\ORACLE\ORADATA\EURO\MIG_PREM2.DBF',
'D:\ORACLE\ORADATA\AGIR\AGIR_INDEX.DBF',
'D:\ORACLE\ORADATA\AGIR\GERICO_DATA.DBF',
'D:\ORACLE\ORADATA\AGIR\GERICO_INDEX.DBF',
'D:\ORACLE\ORADATA\AGIR\DR01.DBF',
'D:\ORACLE\ORADATA\EURO\TS1_HQUIV5.DBF',
'D:\ORACLE\ORADATA\EURO\AGIR_DATA2',
'D:\ORACLE\ORADATA\EURO\TS1_HQUIV1.DBF',
'D:\ORACLE\ORADATA\EURO\TS1_DOMUS_IND3.DBF'
CHARACTER SET WE8ISO8859P1
;

Aussi la question est de savoir si je peux lancer cela sans problème et si je ne risque pas d'écraser les datafiles existants que je viens de copier (en mettant SET à la place de REUSE et RESETLOGS comme conseillé sur le lien https://www.developpez.net/forums/d1...90-ora-0110-a/). En précisant si je ne dois pas renommer les controlefile*.ctl existants.

D'avance merci pour ton retour
10/12/2019, 18h00
pachot

re-creer le controlfile n'est pas forcément une bonne idée. Au moins, soit sûr d'avoir un backup du controlfile courant avant. Mais, non, ça n'écrasera pas les datafiles.
peut-être restaurer le controlfile d'avant ce resetlogs serait plus judicieux (et recover using backup controlfile).
10/12/2019, 21h34
Thomf

En faisant tout simplement un startup mount (ou nomount) suivi d'un recover database using backup controlfile (Il me semble l'avoir déjà fait) en récupérant quel controlfile: celui du 06/12 après la panne ou bien celui du 26/11 la plus récente avant la panne (*) ?

Sinon je copie les controlfile (et les redo ?) par sécurité et je lance la procédure ? what is the best ?

(*) je précise que c'est une ancienne base qui vit encore ses derniers mois mais qu'on utilise pour l'exploitation avant de migrer.
10/12/2019, 23h03
Thomf

Sachant qu'il fallait que j'avance car je prends du retard, j'ai essayé la chose suivante en copiant les controlfile du 08/12/2019 et j'ai la même erreur en faisant MOUNT suivi de RECOVER DATABASE USING BACKUP CONTROLFILE. Du coup, j'ai remis mes CONTROLFILE les plus récents avant la sauvegarde.

Et j'ai essayé la procédure STARTUP NOMOUNT avec le CREATE CONTROLFILE (en SET et RESETLOGS au lieu de REUSE et NORESTLOGS) mais le problème reste entier. A moins d'une autre solution ou autre chose qui m'a échappé (je pensais utiliser REUSE si je n'ai que ça qui me reste).

Ce matin: sinon j'avais pensé relancer la procédure STARTUP NOMOUNT sans le fameux fichier d'index

Citation:

d:\oracle\oradata\agir\Agir_index.dbf'

qui pose problème.

Voir 40 message(s) de cette discussion en une page