In production systems of course you will probably keep at least 3 controlfiles. However a controlfile is a SPOF (single point of
failure). So even a loss of one controlfile will lead to a non available database.
Since I am doing all my test on Windows, it’s not possible to delete files while the database is in use. So I will use a small program written in Java to erase the files:
public class JavaCorrupt {
public static void main(String[] args) {
try {
FileWriter myWriter = new FileWriter(“C:/ORACLE1/APP/DRAGU/ORADATA/LYTICS/CONTROL.CTL”);
myWriter.write(“This is something evil !!!”);
myWriter.close();
System.out.println(“Successfully wrote to the file.”);
} catch (IOException e) {
System.out.println(“An error occurred.”);
e.printStackTrace();
}
}
}
If you look at alert_sid.ora file, there are ugly messages:
Errors in file C:\ORACLE1\APP\DRAGU\diag\rdbms\lytics\lytics\trace\lytics_ckpt_13688.trc (incident=110226):
ORA-00227: détection d’un bloc altéré dans le fichier de contrôle : (bloc , nbre blocs )
ORA-00202: fichier de contrôle : ‘C:\ORACLE1\APP\DRAGU\ORADATA\LYTICS\CONTROL01.CTL’
Incident details in: C:\ORACLE1\APP\DRAGU\diag\rdbms\lytics\lytics\incident\incdir_110226\lytics_ckpt_13688_i110226.trc
2023-02-05T18:15:56.417258+01:00
Errors in file C:\ORACLE1\APP\DRAGU\diag\rdbms\lytics\lytics\trace\lytics_ckpt_13688.trc:
ORA-00227: détection d’un bloc altéré dans le fichier de contrôle : (bloc , nbre blocs )
ORA-00202: fichier de contrôle : ‘C:\ORACLE1\APP\DRAGU\ORADATA\LYTICS\CONTROL01.CTL’
Errors in file C:\ORACLE1\APP\DRAGU\diag\rdbms\lytics\lytics\trace\lytics_ckpt_13688.trc (incident=110227):
ORA-227 [] [] [] [] [] [] [] [] [] [] [] []
Incident details in: C:\ORACLE1\APP\DRAGU\diag\rdbms\lytics\lytics\incident\incdir_110227\lytics_ckpt_13688_i110227.trc
2023-02-05T18:16:00.682152+01:00
USER (ospid: ): terminating the instance due to ORA error
2023-02-05T18:16:00.843959+01:00
System state dump requested by (instance=1, osid=13688 (CKPT)), summary=[abnormal instance termination].
System State dumped to trace file C:\ORACLE1\APP\DRAGU\diag\rdbms\lytics\lytics\trace\lytics_diag_13608.trc
2023-02-05T18:16:17.958672+01:00
Instance terminated by USER, pid = 13688
And of course:
1* select * from v$controlfile
select * from v$controlfile
*
ERREUR Ó la ligne 1 :
ORA-03113: fin de fichier sur canal de communication
ID de processus : 37912
ID de session : 261, NumÚro de sÚrie : 56288
RMAN> startup nomount
instance Oracle dÚmarrÚe
Total System Global Area (SGA) 2533359488 octets
Fixed Size 9031552 octets
Variable Size 536870912 octets
Database Buffers 1979711488 octets
Redo Buffers 7745536 octets
RMAN> list backup of controlfile;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: Úchec de la commande list Ó 02/05/2023 18:24:16
ORA-01507: base de donnÚes non montÚe
Hmm, so how should is proceed ?
RMAN> restore controlfile ;
DÚmarrage de restore dans 05/02/23
canal affectÚ : ORA_DISK_1
canal ORA_DISK_1 : SID=379 type d’unitÚ=DISK
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: Úchec de la commande restore Ó 02/05/2023 18:25:13
RMAN-06563: le fichier de contr¶le ou SPFILE doit Ûtre restaurÚ en utilisant FROM AUTOBACKUP
Ok, so let’s do it:
RMAN> restore controlfile from autobackup;
DÚmarrage de restore dans 05/02/23
utilisation du canal ORA_DISK_1
destination de la zone de rÚcupÚration : C:\Oracle1\app\dragu\recovery_area
nom de base de donnÚes (ou nom unique de base de donnÚes) utilisÚ pour la recherche : LYTICS
canal ORA_DISK_1 : AUTOBACKUP C:\ORACLE1\APP\DRAGU\RECOVERY_AREA\LYTICS\AUTOBACKUP\2022_08_31\O1_MF_S_1114173438_KJYGGYHD_.BKP trouvÚ dans la zone de rÚcupÚration
la recherche AUTOBACKUP n’a pas ÚtÚ tentÚe avec le format “%F” car l’identificateur DBID n’est pas dÚfini
canal ORA_DISK_1 : restauration du fichier de contr¶le Ó partir de AUTOBACKUP C:\ORACLE1\APP\DRAGU\RECOVERY_AREA\LYTICS\AUTOBACKUP\2022_08_31\O1_MF_S_1114173438_KJYGGYHD_.BKP
canal ORA_DISK_1 : la restauration du fichier de contr¶le depuis AUTOBACKUP est terminÚe
nom de fichier de sortie=C:\ORACLE1\APP\DRAGU\ORADATA\LYTICS\CONTROL01.CTL
nom de fichier de sortie=C:\ORACLE1\APP\DRAGU\RECOVERY_AREA\LYTICS\CONTROL02.CTL
Fin de restore dans 05/02/23
At this stage controlfile is restored but not mounted.
Let’s try to open the database:
alter database open;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: Úchec de la commande sql statement Ó 02/05/2023 18:29:34
ORA-01589: doit utiliser l’option RESETLOGS ou NORESETLOGS pour l’ouverture de BDD
Since the checkpoint recorded in the datafile headers is different from the checkpoint in the restored controlfile, we will need the
alter database open resetlogs;
command.
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: Úchec de la commande sql statement Ó 02/05/2023 18:30:21
ORA-01194: le fichier 1 nÚcessite plus de rÚcupÚration pour Ûtre cohÚrent
ORA-01110: fichier de donnÚes 1 : ‘C:\ORACLE1\APP\DRAGU\ORADATA\LYTICS\SYSTEM01.DBF’
You can check this difference by looking at v$datafile and$datafile_header and comparing the value of checkpoint_change# field
https://docs.oracle.com/cd/E18283_01/server.112/e17110/dynviews_1099.htm
https://docs.oracle.com/database/121/REFRN/GUID-23BA7CDD-D642-4CE7-83E2-69B7CFC328A1.htm
SQL> select checkpoint_change# from v$datafile_header;
CHECKPOINT_CHANGE#
8408344
8408344
8408344
8408344
SQL> select checkpoint_change# from v$datafiles;
select checkpoint_change# from v$datafiles
*
ERREUR Ó la ligne 1 :
ORA-01219: base de donnÚes ou base de donnÚes pluggable fermÚe : requÛtes
autorisÚes uniquement sur des vues ou des tables fixes
SQL> select checkpoint_change# from v$datafile;
CHECKPOINT_CHANGE#
2155035
2155035
2155035
2155035
Or you can check the same thing by issuing the rman command:
List backup of controlfile ;
BS Key Type LV Size Device Type Elapsed Time Completion Time
6 Full 10.27M DISK 00:00:01 31/08/22
BP Key: 6 Status: AVAILABLE Compressed: NO Tag: TAG20220831T121449
Piece Name: C:\ORACLE1\APP\DRAGU\RECOVERY_AREA\LYTICS\AUTOBACKUP\2022_08_31\O1_MF_S_1114172089_KJYF4T21_.BKP
Control File Included: Ckp SCN: 2152460 Ckp time: 31/08/22
Let’s correct it
sqlplus / as sysdba
Let’s correct it
sqlplus / as sysdba
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARC
STATUS FIRST_CHANGE# FIRST_TI NEXT_CHANGE# NEXT_TIM CON_ID
1 1 1 209715200 512 2 NO
CURRENT 2155032 31/08/22 1,8447E+19 0
3 1 0 209715200 512 2 YES
UNUSED 0 0 0
2 1 0 209715200 512 2 YES
UNUSED 0 0 0
SQL> select * from v$logfile where group#=1;
GROUP# STATUS TYPE
MEMBER
IS_ CON_ID
1 ONLINE
C:\ORACLE1\APP\DRAGU\ORADATA\LYTICS\REDO01.LOG
NO 0
1 ONLINE
C:\ORACLE1\APP\DRAGU\ORADATA\LYTICS\REDO011.LOG
NO 0
GROUP# STATUS TYPE
Indiquer le journal : {=suggÚrÚ | nomfichier | AUTO | CANCEL}
C:\ORACLE1\APP\DRAGU\ORADATA\LYTICS\REDO01.LOG
ORA-00310: le journal d’archivage contient la sÚquence 77 ; sÚquence 30 requise
ORA-00334: journal d’archivage :
‘C:\ORACLE1\APP\DRAGU\ORADATA\LYTICS\REDO01.LOG’
ORA-01547: attention : opÚration RECOVER rÚussie, mais OPEN RESETLOGS gÚnÚrera
l’erreur ci-dessous
ORA-01194: le fichier 1 nÚcessite plus de rÚcupÚration pour Ûtre cohÚrent
ORA-01110: fichier de donnÚes 1 :
‘C:\ORACLE1\APP\DRAGU\ORADATA\LYTICS\SYSTEM01.DBF’
RMAN> restore database;
DÚmarrage de restore dans 05/02/23
DÚmarrage de implicit crosscheck backup dans 05/02/23
utilisation du fichier de contr¶le de la base de donnÚes cible au lieu du catalogue de rÚcupÚration
canal affectÚ : ORA_DISK_1
canal ORA_DISK_1 : SID=140 type d’unitÚ=DISK
6 objets contre-vÚrifiÚs
Fin de implicit crosscheck backup dans 05/02/23
DÚmarrage de implicit crosscheck copy dans 05/02/23
utilisation du canal ORA_DISK_1
Fin de implicit crosscheck copy dans 05/02/23
recherche de tous les fichiers dans la zone de rÚcupÚration
catalogage des fichiers…
catalogage terminÚ
Nom de fichier : C:\ORACLE1\APP\DRAGU\RECOVERY_AREA\LYTICS\AUTOBACKUP\2022_08_31\O1_MF_S_1114173438_KJYGGYHD_.BKP
utilisation du canal ORA_DISK_1
canal ORA_DISK_1 : dÚmarrage de la restauration de l’ensemble de sauvegarde des fichiers de donnÚes
canal ORA_DISK_1 : dÚfinition du ou des fichiers de donnÚes Ó restaurer Ó partir de l’ensemble de sauvegarde
canal ORA_DISK_1 : restauration du fichier de donnÚes 00001 vers C:\ORACLE1\APP\DRAGU\ORADATA\LYTICS\SYSTEM01.DBF
canal ORA_DISK_1 : restauration du fichier de donnÚes 00003 vers C:\ORACLE1\APP\DRAGU\ORADATA\LYTICS\SYSAUX01.DBF
canal ORA_DISK_1 : restauration du fichier de donnÚes 00004 vers C:\ORACLE1\APP\DRAGU\ORADATA\LYTICS\UNDOTBS01.DBF
canal ORA_DISK_1 : restauration du fichier de donnÚes 00007 vers C:\ORACLE1\APP\DRAGU\ORADATA\LYTICS\USERS01.DBF
canal ORA_DISK_1 : lecture de l’ÚlÚment de sauvegarde C:\ORACLE1\APP\DRAGU\RECOVERY_AREA\LYTICS\BACKUPSET\2022_08_27\O1_MF_NNNDF_TAG20220827T151043_KJN5YN6H_.BKP
RMAN> restore database;
DÚmarrage de restore dans 05/02/23
DÚmarrage de implicit crosscheck backup dans 05/02/23
utilisation du fichier de contr¶le de la base de donnÚes cible au lieu du catalogue de rÚcupÚration
canal affectÚ : ORA_DISK_1
canal ORA_DISK_1 : SID=140 type d’unitÚ=DISK
6 objets contre-vÚrifiÚs
Fin de implicit crosscheck backup dans 05/02/23
DÚmarrage de implicit crosscheck copy dans 05/02/23
utilisation du canal ORA_DISK_1
Fin de implicit crosscheck copy dans 05/02/23
recherche de tous les fichiers dans la zone de rÚcupÚration
catalogage des fichiers…
catalogage terminÚ
Nom de fichier : C:\ORACLE1\APP\DRAGU\RECOVERY_AREA\LYTICS\AUTOBACKUP\2022_08_31\O1_MF_S_1114173438_KJYGGYHD_.BKP
utilisation du canal ORA_DISK_1
canal ORA_DISK_1 : dÚmarrage de la restauration de l’ensemble de sauvegarde des fichiers de donnÚes
canal ORA_DISK_1 : dÚfinition du ou des fichiers de donnÚes Ó restaurer Ó partir de l’ensemble de sauvegarde
canal ORA_DISK_1 : restauration du fichier de donnÚes 00001 vers C:\ORACLE1\APP\DRAGU\ORADATA\LYTICS\SYSTEM01.DBF
canal ORA_DISK_1 : restauration du fichier de donnÚes 00003 vers C:\ORACLE1\APP\DRAGU\ORADATA\LYTICS\SYSAUX01.DBF
canal ORA_DISK_1 : restauration du fichier de donnÚes 00004 vers C:\ORACLE1\APP\DRAGU\ORADATA\LYTICS\UNDOTBS01.DBF
canal ORA_DISK_1 : restauration du fichier de donnÚes 00007 vers C:\ORACLE1\APP\DRAGU\ORADATA\LYTICS\USERS01.DBF
canal ORA_DISK_1 : lecture de l’ÚlÚment de sauvegarde C:\ORACLE1\APP\DRAGU\RECOVERY_AREA\LYTICS\BACKUPSET\2022_08_27\O1_MF_NNNDF_TAG20220827T151043_KJN5YN6H_.BKP
ORA-00279: changement 3845229 gÚnÚrÚ Ó 10/12/2022 04:14:28 requis pour thread 1
ORA-00289: suggestion :
C:\ORACLE1\APP\DRAGU\RECOVERY_AREA\LYTICS\ARCHIVELOG\2022_10_13\O1_MF_1_22_KNJVL
RKO_.ARC
ORA-00280: le changement 3845229 pour le thread 1 se trouve au no de sÚquence
22
ORA-00278: le fichier journal
‘C:\ORACLE1\APP\DRAGU\RECOVERY_AREA\LYTICS\ARCHIVELOG\2022_10_12\O1_MF_1_21_KND8
R52L_.ARC’ n’est plus nÚcessaire pour cette rÚcupÚration
SQL> select checkpoint_change#,fuzzy from v$datafile_header;
CHECKPOINT_CHANGE# FUZ
6308047 NO
6308047 NO
6308047 NO
6308047 NO
Here I am able to open the database;
The recover was long, but it finally succeded.
alter database open resetlogs;
sql>Database opened
What may seem strange is the fact that we were forced to restore the whole database, not only the controlfile;
Let’s see why this happened…
I did another test:
SQL> select checkpoint_change# from v$datafile;
CHECKPOINT_CHANGE#
6313302
6313302
6313302
6313302
SQL> select checkpoint_change# from v$datafile_header;
CHECKPOINT_CHANGE#
6313302
6313302
6313302
6313302
Here the situation seems much better ….
However,
SQL> select checkpoint_change#,fuzzy from v$datafile_header;
CHECKPOINT_CHANGE# FUZ
6313302 YES
6313302 YES
6313302 YES
6313302 YES
The datafiles are still fuzzy , so recover will be necessary …..
SQL> recover database using backup controlfile until cancel;
ORA-00279: changement 6313302 gÚnÚrÚ Ó 02/05/2023 19:14:37 requis pour thread 1
ORA-00289: suggestion :
C:\ORACLE1\APP\DRAGU\RECOVERY_AREA\LYTICS\ARCHIVELOG\2023_02_05\O1_MF_1_1_%U_.AR
C
ORA-00280: le changement 6313302 pour le thread 1 se trouve au no de sÚquence 1
Indiquer le journal : {=suggÚrÚ | nomfichier | AUTO | CANCEL}
C:\ORACLE1\APP\DRAGU\ORADATA\LYTICS\REDO01.LOG
Indiquer le journal : {=suggÚrÚ | nomfichier | AUTO | CANCEL}
C:\ORACLE1\APP\DRAGU\ORADATA\LYTICS\REDO01.LOG
Fichier journal appliquÚ.
Restauration physique terminÚe.
SQL>
That’s it !!!!
We have applied the online redo log and it was containing the necessary redo to perform the recover….
So, to make a conclusion (for the moment) we saw 2 interesting testcases:
a) After erasing the controlfile, we were forced to restore the whole database. Normally, this should not happen this way, but it happened here. In fact I am glad to see the testcase.
b) After erasing the controlfile we were able to recover using the online redo log. Oracle never propose it to you after issuing the
recover command, it will only propose the archivelog that may still not exist.
To be continued…
See this article for more details about the information inside v$datafile and v$datafile_header.
Practical Oracle,SQL Server, other databases and Big Data & AI 