Version imprimable
Oui c'était bien ça. Quelle même erreur? ORA-00600[2662] ou ORA-01190?Citation:
Envoyé par Thomf
Je ne sais même pas comment tu fais le recover. Avec RMAN ou RECOVER UNTIL CANCEL USING BACKUP CONTROLFILE; sous sqlplus ?
Je pense que s'il est avant un resetlogs, ce sera le cas pour les autres fichiers. Mais tu peux essayer simplement de le mettre offline.Citation:
Envoyé par Thomf
Je rencontre l'erreur ORA-01190.Citation:
Envoyé par pachot
Je fais mon RECOVER sous sqlplus via svrmgrl. Je ne sais pas utiliser RMAN.
En fait je rencontre le problème sur 3 datafiles dont un qui ne sert pas à grand chose. Je les ai mis offline et j'ai relancé la procédure en retirant les datafiles concernés mais je rencontre les 3 anomalies suivantes:Citation:
Envoyé par pachot
Du coup j'ai remit mes 3 datafiles online car à partir de là ça dépasse mes compétences.Citation:
ORA-00200: controlfile could not to be created
ORA-00202: controlfile: nom du controlfile
ORA-27038: skgfrcre: file exists
ORA-04010: <create>, option specified. file already exists
ORA-00200 c'est parce que tu essaie de recréer le controlfile mais que l'ancien existe. Si tu tiens à le recréer alors il faut supprimer les controlfiles courants.
Donc je supprime physiquement et totalement les controlfiles courant (qui seront recrées) ? Et les 3 datafiles, je les laisse online ?Citation:
Envoyé par pachot
oui (tu as un backup de toute façon)
et tu mets off line les datafiles qui posent probleme ORA-01190 dejà pour voir si tu peux récupérer le reste.
la procédure STARTUP NOMOUNT et CREATE CONTROLFILE a bien fonctionné mais après avoir fait lancé ALTER DATABASE OPEN RESETLOGS ça me renvoie une erreur ORA-00600, internal erreur, code, argument: [2662], [2] etc..Citation:
Envoyé par pachot
Désolé, tout ça n'est pas assez précis! C'est le "ALTER DATABASE OPEN RESETLOGS" qui renvoit l'ORA-600 [2662]? Jusqu'où s'est fait le recover?
Bon. Donc s'il y a toujours cette erreur avec le restore du backup c'est que la corruption existait déjà dans le backup. C'est plus inquiétant.
Il va falloir travailler avec le support. Mais un conseil: donner un maximum d'information précises. S'ils ont les mêmes infos que sur ce thread, c'est impossible de comprendre ce qui a été fait.
Désolé, je ne peux rien conseiller de plus si le dernier backup n'est pas ok non plus.
Oui c'est bien ALTER DATABASE OPEN RESETLOGS qui renvoie l'erreur ORA-00600. Je n'ai pas fait de RECOVER DATABASE avant ça, le fallait il (ou j'ai oublié) à moins que tu voulais dire le recover des datafiles qui sont du 26/11/2019.
Finalement j'ai déjà (et enfin) eu un 1er retour d'oracle (très tardif) mais dans le même temps j'ai décidé d'installer la base sur un autre pc.
Par conséquent, j'ai réinstallé Oracle 8i 'Entreprise Edition' sachant que je pensais avoir l'option la meilleure pour créer des bases seulement je ne trouve pas oradim ce qui va peut-être m'obliger de réiinstaller avec l'option 'Management and Integration' pour avoir Oradim. Je vais poster justement poster un topic à ce sujet dans le forum.
J'en profite pour te remercier de ton aide et ta disponibilité.
Thomas
PS: en France nous sommes très gênés par les grèves et tout ça réduit le temps pour gérer ce problème très ardu mais je reconnais certaines lacunes me concernant mais là-dessus je pense que tu l'avais compris dès le début.
Bonjour,
Problème résolu hier. Oracle My Support m'a fait faire des requêtes de contrôles pour analyse. Il a été constaté qu'un Tablespace posait problème en raison d'un CHECKPOINT différent de celui du RECOVER. Il s'agissait d'un Tablespace autre que ceux que j'avais cité. Oracle m'a demandé de faire un RECOVER de ce datafile mais je rencontrais la même erreur que les autres datafiles.
Etant donné son peu d'importance et qu'il n'était plus utilisé (déjà migré sur une base Oracle 10 il y a 10 ans), Oracle m'a demandé de le mettre offline et de le droper également. J'ai fait pareil pour 4 datafiles (dont 1 déjà évoqué dans ce topic). 2 autres datafiles n'étaient plus utilisés, 1 m'était inconnu (DR01.dbf=DRSYS) et contenait aucune table et Agir_index.dbf est encore utilisé mais de façon modérée. Aussi Oracle m'a conseillé de les supprimer et de les récupérer via un Dump.
Après toutes ces manipulations, j'ai pu faire un ALTER DATABASE OPEN et tout a fonctionné normalement ce qui m'a permit de réimporter les données les plus récentes et redémarrer l'exploitation.
Pour conclure, je dirais toute chose a une fin, Ouf !
ok, cool.
J'imagine que les les résolutions 2020 c'est: upgrade en 19c et avoir une procédure qui vérifie les backups :)
Bonjour,
A titre d'information, pour ceux que ça intéresse, voilà les solutions proposées par le support Oracle pour résoudre ce problème:
Oracle Support:
Puis,Citation:
Veuillez fournir le résultat de ce qui suit:
spool /tmp/current_status_info_new.txt
set pagesize 20000
set linesize 180
set pause off
set serveroutput on
set feedback on
set echo on
set numformat 999999999999999
alter session set nls_date_format = 'dd-mon-yyyy hh24:mi:ss';
archive log list;
select name,dbid,controlfile_type,open_mode,log_mode,checkpoint_change#,archive_change# from v$database;
select * from v$database_incarnation;
col name for a75
select * from v$restore_point;
select flashback_on from v$database;
select file#,name,status,checkpoint_change#,enabled from v$datafile;
select file#,name,status,enabled from v$tempfile;
select TS#,NAME,INCLUDED_IN_DATABASE_BACKUP,FLASHBACK_ON from v$tablespace;
select * from v$recover_file;
select * from v$backup;
select * from v$log;
select * from v$logfile;
select file#,name,recover,fuzzy,checkpoint_change#,creation_change#,checkpoint_time,creation_time,RESETLOGS_TIME,status from v$datafile_header;
select status, to_char(checkpoint_change#), to_char(checkpoint_time, 'DD-MON-YYYY HH24:MI:SS') as checkpoint_time,
count(*) from v$datafile_header
group by status, checkpoint_change#, checkpoint_time order by status, checkpoint_change#, checkpoint_time;
select count(*),fhsta from x$kcvfh group by fhsta;
select count(*),fhrba_seq from x$kcvfh group by fhrba_seq;
select count(*),fhscn from x$kcvfh group by fhscn;
select count(*),fhafs from x$kcvfh group by fhafs;
select min(FHSCN) "LOW FILEHDR SCN" , max(FHSCN) "MAX FILEHDR SCN", max(FHAFS) "Min PITR ABSSCN" from X$KCVFH ;
select fhdbn,fhdbi,hxfil,fhsta,fhscn,fhafs,fhrba_seq,fhtnm tbs_name from x$kcvfh;
spool off
exit
Résultat du client:Citation:
Datafile 40 a un checkpoint différent et l’état RECOVER
40 D:\ORACLE\ORADATA\EURO\TS1_HQUIV5.DBF RECOVER 9010420579 READ WRITE
Executez
SQL> recover datafile 40;
Appliquez les logs demandés
Vérifiez à nouveau l'état
SQL> select file#,status from v$datafile where file#=40;
Mettez le datafile en ligne
SQL> alter database datafile 40 online;
Réponse d'Oracle:Citation:
Suite au recover, j'ai l'erreur suivante:
ORA-01190: controlfile or datafile 36 is before the last RESETLOGS
ORA-01110: datafile 36: d:\oracle\oradata\EURO\TS1_HQUIV5.DBF'
Qu'entendez-vous par appliquer les logs ?
Réponse du client:Citation:
Si ce datafile n'est pas important, veuillez suivre ces étapes
SQL > startup mount;
++ Suprimez offline le datafile fautif
SQL > alter database datafile <file#> offline drop;
++ Ouvrez la base de données.
SQL > alter database open;
++ Supprimez le tablespace contenant le datafile fautif.
Réponse d'OracleCitation:
J'ai le même message sur 4 autres datafiles. 2 ne sont pas importants, 1 concerne les indexe d'une base et le 4ème que je ne connais pas: dr01.dbf.
je peux droper les tablespace de ceux qui ne sont pas importants mais est-ce que je peux garder les tablespace de dr01.dbf et agir_index.dbf au cas où ?
Alter database open a bien fonctionné
Je pense faire l'import des données de tables les plus utilisées, cela est-il possible à présent ?
Citation:
Vous devez appliquer le même plan d'action si les datafiles ne peuvent pas être récupérés.
Si vous avez un export dump pour ces tablespaces vous pouvez utiliser Datapump import pour les recréer dans la base de données.