oracle-控制文件的備份和恢復


本篇將介紹各種備份及恢復控制文件的方法,在介紹恢復時,以備份和重做日志(包括歸檔日志和在線日志)沒有丟失為前提

無備份情況下的控制文件恢復參考13.3,丟失重做日志的情況請參考12篇“不完全數據庫恢復”

8.1 控制文件損壞的后果

數據庫的控制文件不止一個,進程對其寫的操作是針對所有的控制文件,並且寫的內容是相同的,所以多個控制文件的內容是完全一樣的;

當進程讀取控制文件時,讀的卻總是第一個控制文件的內容(第一個控制文件的定義時control_files初始化參數的第一個文件)。當第一個控制文件損壞,讀寫操作都是出錯。

8.1.1 實例啟動時發現損壞

YHQT@ orcl >show parameter control_files
NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
control_files			     string	 /u01/app/oracle/oradata/orcl/c
						 ontrol01.ctl, /u01/app/oracle/
						 oradata/orcl/control02.ctl

3個文件中,任意一個出錯,實例將啟動不到mount階段,啟動報錯

--ORA-00205: error in identifying control file, check alert log for more info

其中一個文件損壞

--ORA-00227: corrupt block detected in control file: (block 0, # blocks )

如果是3個文件全部被刪除

ORA-00210: cannot open the specified control file

ORA-00202: control file: '/u01/app/oracle/oradata/orcl/control01.ctl'

場景1db啟動時,任意一個控制文件的數據塊損壞時的告警

SQL> startup mount;
ORACLE instance started.
Total System Global Area 1185853440 bytes
Fixed Size     2252664 bytes
Variable Size   754974856 bytes
Database Buffers   419430400 bytes
Redo Buffers     9195520 bytes
ORA-00227: corrupt block detected in control file: (block 0, # blocks )

場景2db啟動時,任意一個控制文件頭損壞,告警日志

ORA-00210: cannot open the specified control file
ORA-00202: control file: '/u01/app/oracle/oradata/orcl/control01.ctl'
ORA-27048: skgfifi: file header information is invalid
ORA-205: signalled during: ALTER DATABASE MOUNT ...

場景3db啟動時,任意控制文件丟失

ORA-00210: cannot open the specified control file
ORA-00202: control file: '/u01/app/oracle/oradata/orcl/control01.ctl'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
ORA-205 signalled during: ALTER DATABASE   MOUNT...

8.1.2 實例運行時發現損壞

如果任意一個控制在實例運行時損壞,實例起先能夠保持OPEN狀態,但不能保證所有功能可以正常進行:某些操作可以正常使用,某些直接報錯,

最終,實例還是要被關閉(自動或手動)。首先發現問題的極有可能是CKPT進程(該進程每3秒就會寫一下控制文件),在alert文件中

ORA-00227: corrupt block detected in control file: (block 1, # blocks 1)

ORA-00202: control file: '/u01/app/oracle/oradata/orcl/control01.ctl'

此時,CKPT將不停的報錯,11g自動的洪流控制會選擇性的屏蔽重復信息的產生,因為每3秒更新的不屬於特別重要的檢查點信息,

而是一種對在線重做日志最新狀態和當前SCN號的確認信息,只要重做日志健康,這些信息還是可以從重做日志中取得的,實例也不會終止。

對於服務器進程來說,執行一些需要對控制文件讀寫(只要第一個文件健康,讀寫操作不報錯)的操作,同樣也會報錯,比如v$database\v$log\v$logfile\v$datafile\v$tempfile等動態視圖

SQL> select * from v$datafile;
ORA-00227: corrupt block detected in control file: (block 1, # blocks 1)
ORA-00202: control file: '/u01/app/oracle/oradata/orcl/control01.ctl'

比如再創建表空間

SQL>create tablespace yhqt datafile '/u01/app/oracle/oradata/orcl/yhqt01.dbf' size 50M;

也會報同樣的錯誤

CKPT會在發起檢查點時終止實例,因為檢查點需要寫控制文件,並且檢查點被認為是不允許有任何差錯的重要操作

CKPT (ospid:15711): terminating the instance due to error 227

即使發起命令alter system switch logfile日志切換命令,LGWR也會終止實例。切換日志的完整性操作包括把日志序列號更新到控制文件,而控制文件損壞,無法更新,

LWGR(ospid:11529): terminating the instance due to error 227

在實例被終止前,只要不直接或間接地訪問控制文件,服務器進程的一切(select\dml\ddl\commit\rollback)等可以正常執行。否則,輕則報錯,重則服務器進程被殺導致實例被終止。

SQL> alter tablespace example read only; ---實例將被終止

當遇到這種情況,如果實例還沒有被關閉,能提交的事務可以抓緊提交,因為commit重做記錄寫入在線日志可以進行,然后shutdown abort;

SQL> shutdown abort;

場景4:實例正常運行,在linuxrm刪除掉控制文件

這種情況實例不會被關閉,CKPT,LGWR進程已經打開了控制文件,而rm命令並不能把這些進程已經打開的控制文件的句柄刪掉,

也沒有真正地物理上把控制文件刪掉,rm只是在文件系統上刪除了指向控制文件的“索引”而已。

8.2 備份控制文件

控制文件的備份類型主要分為:在線鏡像備份、自動備份和手動備份

8.2.1 在線鏡像備份

在線鏡像備份,或稱為在線副本的路徑,有control_files參數指定

YHQT@ orcl >show parameter control_files

8.2.2 自動備份

--1 顯示自動備份

顯示自動備份功能默認是關閉的,在沒有catalog的情況下,建議打開,使用RMANconfigure命令設置

--show all
--rman> configure controlfile autobackup on;
RMAN> show controlfile autobackup;
RMAN configuration parameters for database with db_unique_name ORCL are:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
RMAN> backup tablespace ogg;
Starting backup at 16-JUL-19
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00009 name=/u01/app/oracle/oradata/orcl/ogg01.dbf
channel ORA_DISK_1: starting piece 1 at 16-JUL-19
channel ORA_DISK_1: finished piece 1 at 16-JUL-19
piece handle=/u01/app/oracle/fra/ORCL/backupset/2019_07_16/o1_mf_nnndf_TAG20190716T174825_glv7c9gc_.bkp tag=TAG20190716T174825 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 16-JUL-19
Starting Control File and SPFILE Autobackup at 16-JUL-19
piece handle=/u01/app/oracle/fra/ORCL/autobackup/2019_07_16/o1_mf_s_1013795306_glv7cbwp_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 16-JUL-19 ---->自動備份控制文件和參數文件

當數據庫物理結構發生變化時,如創建或刪除表空間、添加或刪除數據文件、表空間上下線切換、表空間可讀寫切換等,從11.2開始,這樣的物理結構變化導致的自動備份oracleMMON后台進程延時處理

隱含參數_controlfile_autobackup_delay’修改時間間隔

--2 隱式自動備份

指即便在controlfile autobackup=off,只要使用RMAN備份system表空間的第一個數據文件,控制文件就會被自動備份。

RMAN> configure controlfile autobakcup off;
RMAN> backup datafile 1;

但是oracle並不認為這是自動備份,這種控制文件備份根本沒有保存在快速恢復區的autobackup目錄下,而是在backupset目錄。

--3手動備份

使用RMANsqlplus手動備份控制文件。備份可分為備份集鏡像復制備份和重建腳本

備份集和鏡像復制的默認路徑是快速恢復區,沒有使用快速恢復區的一般在’$ORACLE_HOME/dbs目錄。重建腳本則寫入常規的追蹤文件路徑中。

--3.1 備份集備份

RMAN> backup as backupset current controlfile;
Starting backup at 17-JUL-19
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
channel ORA_DISK_1: starting piece 1 at 17-JUL-19
channel ORA_DISK_1: finished piece 1 at 17-JUL-19
piece handle=/u01/app/oracle/fra/ORCL/backupset/2019_07_17/o1_mf_ncnnf_TAG20190717T103715_glx2gwl8_.bkp tag=TAG20190717T103715 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 17-JUL-19
Starting Control File and SPFILE Autobackup at 17-JUL-19  ---》》自動備份了參數文件
piece handle=/u01/app/oracle/fra/ORCL/autobackup/2019_07_17/o1_mf_s_1013855838_glx2gy3s_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 17-JUL-19
RMAN> list backup of controlfile;

--3.2 鏡像復制備份

RMAN> backup as copy current controlfile format '/home/oracle/control.backup';
Starting backup at 17-JUL-19
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile copy
copying current control file
output file name=/home/oracle/control.backup tag=TAG20190717T103956 RECID=2 STAMP=1013855996
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
Finished backup at 17-JUL-19
Starting Control File and SPFILE Autobackup at 17-JUL-19
piece handle=/u01/app/oracle/fra/ORCL/autobackup/2019_07_17/o1_mf_s_1013855997_glx2mxy4_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 17-JUL-19
或通過sqlplus備份控制文件
SYS@ orcl >alter database backup controlfile to '/home/oracle/control.backup.2';
Database altered.
RMAN> list copy of controlfile; ##查看鏡像復制備份

--3.3 重建腳本

SYS@ orcl >alter database backup controlfile to trace as '/home/oracle/control20190717.sql';

Database altered.

不指定位置通過視圖查詢

SQL> select * from v$diag_info where name=’Default Trace File’;

查看腳本片段

[oracle@DSI ~]$ sed -n "/NORESETLOGS/,/REUSE AUTOEXTEND ON/p" /home/oracle/control20190717.sql |grep -v '^--'

首先實例啟動到nomount,通過create controlfile創建控制文件(maxlogfileslogfiledatafile等)

[oracle@DSI ~]$ sed -n "/NORESETLOGS/,/REUSE AUTOEXTEND ON/p" /home/oracle/control20190717.sql |grep -v '^--'


STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "ORCL" NORESETLOGS FORCE LOGGING ARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 292
LOGFILE
  GROUP 1 (
    '/u01/app/oracle/oradata/orcl/redo01.log',
    '/u01/app/oracle/oradata/orcl/redo11.log'
  ) SIZE 50M BLOCKSIZE 512,
  GROUP 2 '/u01/app/oracle/oradata/orcl/redo02.log'  SIZE 50M BLOCKSIZE 512,
  GROUP 3 '/u01/app/oracle/oradata/orcl/redo03.log'  SIZE 50M BLOCKSIZE 512
DATAFILE
  '/u01/app/oracle/oradata/orcl/system01.dbf',
  '/u01/app/oracle/oradata/orcl/sysaux01.dbf',
  '/u01/app/oracle/oradata/orcl/undotbs01.dbf',
  '/u01/app/oracle/oradata/orcl/users01.dbf',
  '/home/oracle/backup/test01.tts',
  '/u01/app/oracle/oradata/orcl/assm01.dbf',
  '/u01/app/oracle/oradata/orcl/mssm01.dbf',
  '/u01/app/oracle/oradata/orcl/rc_data01.dbf',
  '/u01/app/oracle/oradata/orcl/ogg01.dbf',
  '/u01/app/oracle/oradata/orcl/yhqt01.dbf'
CHARACTER SET AL32UTF8
;

EXECUTE SYS.DBMS_BACKUP_RESTORE.CFILESETSNAPSHOTNAME('/u01/app/oracle/product/11.2.0/db_1/dbs/snapcf_orcl.f');
VARIABLE RECNO NUMBER;
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('RETENTION POLICY','TO RECOVERY WINDOW OF 7 DAYS');
VARIABLE RECNO NUMBER;
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('CONTROLFILE AUTOBACKUP','ON');
VARIABLE RECNO NUMBER;
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('BACKUP OPTIMIZATION','ON');
VARIABLE RECNO NUMBER;
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('SNAPSHOT CONTROLFILE NAME','TO ''/u01/app/oracle/product/11.2.0/db_1/dbs/snapcf_orcl.f''');
RECOVER DATABASE

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
ALTER SYSTEM ARCHIVE LOG ALL;

ALTER DATABASE OPEN;

ALTER TABLESPACE TEMP ADD TEMPFILE '/u01/app/oracle/oradata/orcl/temp01.dbf'
     SIZE 61865984  REUSE AUTOEXTEND ON NEXT 655360  MAXSIZE 32767M;
View Code

8.3 恢復控制文件

8.3.1 控制文件備份的時間跨度分類

在時間跨度上控制文件備份分3類:在線鏡像備份、結構備份和歷史備份

--1 在線鏡像備份:在線副本,control_files參數指向的除了損壞的控制文件以外的其他健康的控制文件,當前數據庫的物理結構,知道最新的檢查點、

最新的在線日志序列號、最新的SCN\數據庫SCN、控制文件序列號、控制文件SCN、各個數據文件頭部檢查點信息及歸檔日志等。

--2 結構備份:該備份中數據庫的物理結構信息(數據文件和在線重做日志)和當前控制文件一致,但最新的檢查點最新的重做日志序列號、SCN數據庫SCN

控制文件序列號控制文件SCN各個數據文件都不檢查點歸檔信息比當前控制文件中的舊。在產生自動備份或手動備份之后,如果數據庫的結構沒有發生任何變化,

如添加刪除表空間、添加刪除在線日志,那么它們就是結構備份。

--3 歷史備份:該備份數據庫的物理結構和當前控制文件不一致(更不用提SCN)。在產生自動或手動備份后,物理結構發生變化,那么它們就是歷史備份。

大多數情況,恢復控制文件時先考慮使用在線鏡像備份,其次是結構備份最后是歷史備份。

除了在線鏡像備份意外,利用其它備份恢復的程序順序3個步驟

--1 從備份中還原控制文件
--2 用重做日志介質恢復數據庫(apply log)
--3 以重設日志的方式打開數據庫

8.3.2 恢復前的准備

為了恢復控制文件,實例應該處於nomount狀態。如果發現問題時實例還未關閉,首先應該用shutdown abort命令關閉,

接着雖然可以使用startup nomount啟動,但是建議使用startup啟動實例,卡在nomount狀態,可以知道很多告警日志和追蹤日志中產生更多的有用信息

8.3.3 利用在線鏡像備份恢復

若在線鏡像備份可用,恢復主要流程如下:

--1 使用startup啟動到nomount狀態
--2 查看alert log和追蹤日志觀察損壞的具體情況
--3 用os 系統命令用健康的在線鏡像備份替換已損壞或丟失的控制文件
--4 啟動到mount狀態
--5 啟動到open狀態
例如:手工修改一個控制文件,然后恢復
[oracle@DSI orcl]$ pwd
/u01/app/oracle/oradata/orcl
[oracle@DSI orcl]$ echo \"database_name:orcl\" > db
[oracle@DSI orcl]$ dd if=db  of=control01.ctl  bs=16834  seek=1 count=1 conv=notrunc
SQL> shutdown immediate;
ORA-00227: corrupt block detected in control file: (block 1, # blocks 1)
ORA-00202: control file: '/u01/app/oracle/oradata/orcl/control01.ctl'
SQL> shutdown abort;
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.
Total System Global Area  784998400 bytes
Fixed Size            2257352 bytes
Variable Size          511708728 bytes
Database Buffers      264241152 bytes
Redo Buffers            6791168 bytes
ORA-00227: corrupt block detected in control file: (block 0, # blocks )
--可以cp control01.ctl  /tmp/control01.ctl 防止被誤刪
[oracle@DSI orcl]$ rm control01.ctl 
[oracle@DSI orcl]$ cp control02.ctl control01.ctl ##利用在線鏡像進行快速恢復
SQL> startup mount;
ORA-01081: cannot start already-running ORACLE - shut it down first
SQL> alter database mount;
Database altered.
SQL> alter database open;
Database altered.

在線鏡像備份即當前備份具有所有的最新信息,所以在恢復的流程中,不需要使用recover,主要依靠操作系統的cp命令。

8.3.4 利用自動備份恢復

若自動備份可用,恢復流程

--1 startup啟動到nomount狀態
--2 restore controlfile from autobackup還原控制文件
--3 啟動到mount狀態
--4 recover database恢復數據庫
--5 resetlogs打開數據庫
SQL> startup;
[oracle@DSI ~]$ rman target
RMAN> restore controlfile from autobackup; ##使用了快速恢復區
RMAN> mount database;
RMAN> recover database; ##自動在快速恢復區內找備份和歸檔日志、自動找最當前的在線日志、判斷控制文件是否需要恢復、讀取日志信息以恢復數據文件和控制文件的不行信息。
RMAN> alter database open resetlogs;
SYS@ orcl >show parameter db_recovery
NAME                     TYPE     VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest             string     /u01/app/oracle/fra
db_recovery_file_dest_size         big integer 4G

3recover database命令,分別在sqlplusrman中執行

--1 SQL> recover database; 用來對所有數據文件進行恢復,並且只能使用保存在文件系統上的歸檔日志及在線日志。使用此命令的前提是控制文件,不可以是還原或重建而來的。

--2 SQL> recover database using backup controlfile用來對所有數據文件及控制文件進行恢復,並且只能使用保存在文件系統上的歸檔日志和在線日志。

--3 RMAN> recover database; 用來對所有數據文件及控制文件進行恢復,並且可以使用增量備份、備份中的和文件系統上的歸檔日志,以及文件系統上的在線日志

本例子中最后使用resetlog打開數據庫,原因是recover只能修復控制文件中數據庫物理結構信息,而無法修改控制文件中的當前重做日志的序列號等信息,

recover執行完成后,控制文件中當前在線日志序列號還是備份是的。若按照alter database open打開,將報錯,為了抹去控制文件的這個念頭,采用重設日志功能,日志序列號就從1重新開始。

 這里雖然使用了resetlogs,但是recover database成功執行已提交的事務不會丟失,resetlogs僅僅是為了照顧控制文件,與不完全恢復的resetlogs是不同的。

 如果遺漏了recover database步驟,直接執行alter database open resetlogs會報錯

ORA-01194: file 1 needs more recovery to be consistent--1號數據文件需要更多恢復。

8.3.5 利用手動備份恢復

利用手動備份恢復流程

--1 啟動nomount狀態
--2 搜索備份集的位置
--3 用指定備份集路徑的restore controlfile from ‘路徑’命令還原控制文件或者用操作系統命令把鏡像復制到原位
--4 啟動到mount狀態
--5 recover database恢復數據庫
--6 用resetlogs打開數據庫

在第三步還原控制文件之前,dba必須確定控制文件備份集的位置,如果使用catalog則不必,否則restore controlfile會報錯

#錯誤示范
RMAN> restore controlfile; ##會報錯,rman找不到rman資料庫,找不到備份集
RMAN> restore controlfile from autobackup; ##使用自動備份找不到文件
正確姿勢
RMAN> restore controlfile from '/home/oracle/backup/20190430_ORCL_6_1_1534031567.ctl';
RMAN> mount database;

查看當前數據庫中的控制文件狀態和數據文件頭狀態

SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
       1191079
SQL> select file#,checkpoint_change# from v$datafile;
     FILE# CHECKPOINT_CHANGE#
---------- ------------------
     1          1191079
     2          1191079
     3          1191079
     4          1191079
     5          1191079
SQL> select checkpoint_change# from v$datafile_header;
CHECKPOINT_CHANGE#
------------------
       1191079
       1191079
       1191079
       1191079
       1191079
RMAN> recover database;
RMAN> alter database open resetlogs;

如果使用了rman catalog,在restore controlfile時不需要指定from,也不會報錯

RMAN-06563

[oracle@DSI ~]$ rman target sys/***@orcl catalog rcowner/***@orcl
RMAN> run {
startup force nomount;
restore controlfile;
mount database;
recover database;
alter database open resetlogs;
}

8.3.6 利用歷史備份恢復

注意,恢復時如果有在線鏡像備份或結構備份,歷史備份是不需要考慮也是不應該考慮的,因為此時備份和當前數據庫物理結構不一致,會帶來一定的麻煩

第二類和第三類recover database命令可以自動修復某一些不一致:

--1 備份控制文件中沒有某個數據文件和表空間信息,但實際上存在,比如:備份控制文件后,又新建了表空間

--2 備份控制文件中沒有某個在線日志組的信息,實際上存在,比如:備份控制文件后,在添加了日子組,並且shutdown abort或實例崩潰時

新添加的那個日志組可以是currentactive狀態,這種情況下,recover database命令將直接以控制文件中的信息為准,結果是恢復時就當新添加的日志組不存在過一樣,恢復過程中沒有阻礙。

--3 備份控制文件中有某個在線日志組信息,但實際上不存在,比如:備份控制文件后,再刪除日志組,這種情況下以控制文件中的信息為准,

結果是恢復時刪除的日志組將復活,也就是又被創建回來,恢復過程沒有任務阻礙。

而另一些不一致不能依賴recover database命令自動修復,恢復過程需要人為干預,只能使用第二類recover database或特殊的recover命令才能恢復。

具體如下:

--1 備份控制文件中具有某個數據文件或表空間信息,但實際上不存在,比如:備份控制文件后,再刪除表空間,

需要SQL> recover database using backup controlfile或者 recover database skip tablespace命令才能修復

--2 備份中沒有某個在線日志組,但實際上存在,比如:備份控制文件之后在添加新日志組,並且新添加的日志組剛好是在shutdown abort

實例崩潰時的currentactive狀態的日志組,那么在RMAN執行recover database時就會報錯RMAN-06054: media recovery requesting unknown archived log

請求未知歸檔的錯誤,需要使用SQL> recover database using backup controlfile命令,手動指定重做日志的路徑才能完成恢復。

SQL> RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;

SQL> ALTER DATABASE OPEN RESETLOGS;

--1 自動修復不一致

場景1:控制文件自動備份功能關閉,在備份了控制文件之后,dba創建了一個test01表空間,在備份中這個表空間並不存在,

及物理結構與當前不一致,備份就此成了一個歷史備份。目前狀態時所有在線控制文件損壞,無在線鏡像備份和自動備份可用

首先還原控制文件

RMAN> restore controlfile from ‘/u01/app/oracle/fra/ORCL/autobackup/2019_07_17/o1_mf_s_1013855838_glx2gy3s_.bkp’;
還原結束后啟動到mount狀態
RMAN> mount database;
觀察還原出來的控制文件,查看datafile是否有新建的test01表空間,答案是否定的
SQL> select name from v$datafile;
然后用第三類recover database恢復
RMAN> recover database;
再次查詢
SQL> select name from v$datafile;
RMAN> alter database open resetlogs;

--簡單記錄,詳細點擊查看

SYS@ orcl >create tablespace test01 datafile '/u01/app/oracle/oradata/orcl/test011.dbf' size 10m autoextend on;
SYS@ orcl >shutdown abort;
[oracle@DSI orcl]$ mv control01.ctl c1.ctl
[oracle@DSI orcl]$ mv control02.ctl c2.ctl
[oracle@DSI ~]$ rman target /
RMAN> startup;
Oracle instance started
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of startup command at 07/17/2019 15:49:37
ORA-00205: error in identifying control file, check alert log for more info
RMAN> restore controlfile from '/u01/app/oracle/fra/ORCL/autobackup/2019_07_17/o1_mf_s_1013855838_glx2gy3s_.bkp';
RMAN> mount database;
SQL> select name from v$datafile;
RMAN> recover database;
SQL> select name from v$datafile;
RMAN> alter database open resetlogs;
查看控制文件
[oracle@DSI orcl]$ ll control0*
-rw-r----- 1 oracle oinstall 10076160 Jul 17 16:03 control01.ctl
-rw-r----- 1 oracle oinstall 10076160 Jul 17 16:03 control02.ctl
--手動備份自動修復
1308    Full    9.67M      DISK        00:00:00     17-JUL-19      
        BP Key: 1310   Status: AVAILABLE  Compressed: NO  Tag: TAG20190717T103718
        Piece Name: /u01/app/oracle/fra/ORCL/autobackup/2019_07_17/o1_mf_s_1013855838_glx2gy3s_.bkp
  Control File Included: Ckp SCN: 10509720     Ckp time: 17-JUL-19

SYS@ orcl >create tablespace test01 datafile '/u01/app/oracle/oradata/orcl/test011.dbf' size 10m autoextend on;
Tablespace created.
SYS@ orcl >shutdown abort;
ORACLE instance shut down.
[oracle@DSI orcl]$ mv control01.ctl c1.ctl
[oracle@DSI orcl]$ mv control02.ctl c2.ctl

[oracle@DSI ~]$ rman target /

Recovery Manager: Release 11.2.0.4.0 - Production on Wed Jul 17 15:47:54 2019

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

connected to target database (not started)

RMAN> startup;

Oracle instance started
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of startup command at 07/17/2019 15:49:37
ORA-00205: error in identifying control file, check alert log for more info
RMAN> restore controlfile from '/u01/app/oracle/fra/ORCL/autobackup/2019_07_17/o1_mf_s_1013855838_glx2gy3s_.bkp';

Starting restore at 17-JUL-19
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=135 device type=DISK

channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
output file name=/u01/app/oracle/oradata/orcl/control01.ctl
output file name=/u01/app/oracle/oradata/orcl/control02.ctl
Finished restore at 17-JUL-19

RMAN> mount database;

database mounted
released channel: ORA_DISK_1
SQL> select name from v$datafile;

NAME
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/orcl/system01.dbf
/u01/app/oracle/oradata/orcl/sysaux01.dbf
/u01/app/oracle/oradata/orcl/undotbs01.dbf
/u01/app/oracle/oradata/orcl/users01.dbf
/home/oracle/backup/test01.tts
/u01/app/oracle/oradata/orcl/assm01.dbf
/u01/app/oracle/oradata/orcl/mssm01.dbf
/u01/app/oracle/oradata/orcl/rc_data01.dbf
/u01/app/oracle/oradata/orcl/ogg01.dbf
/u01/app/oracle/oradata/orcl/yhqt01.dbf

10 rows selected.
RMAN> recover database;

Starting recover at 17-JUL-19
Starting implicit crosscheck backup at 17-JUL-19
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=10 device type=DISK
Crosschecked 5 objects
Finished implicit crosscheck backup at 17-JUL-19

Starting implicit crosscheck copy at 17-JUL-19
using channel ORA_DISK_1
Finished implicit crosscheck copy at 17-JUL-19

searching for all files in the recovery area
cataloging files...
cataloging done

List of Cataloged Files
=======================
File Name: /u01/app/oracle/fra/ORCL/autobackup/2019_07_17/o1_mf_s_1013855838_glx2gy3s_.bkp
File Name: /u01/app/oracle/fra/ORCL/autobackup/2019_07_17/o1_mf_s_1013855997_glx2mxy4_.bkp

using channel ORA_DISK_1

starting media recovery

archived log for thread 1 with sequence 50 is already on disk as file /u01/app/oracle/oradata/orcl/redo02.log
archived log file name=/u01/app/oracle/oradata/orcl/redo02.log thread=1 sequence=50
creating datafile file number=11 name=/u01/app/oracle/oradata/orcl/test011.dbf
archived log file name=/u01/app/oracle/oradata/orcl/redo02.log thread=1 sequence=50
media recovery complete, elapsed time: 00:00:01
Finished recover at 17-JUL-19

SQL> /

NAME
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/orcl/system01.dbf
/u01/app/oracle/oradata/orcl/sysaux01.dbf
/u01/app/oracle/oradata/orcl/undotbs01.dbf
/u01/app/oracle/oradata/orcl/users01.dbf
/home/oracle/backup/test01.tts
/u01/app/oracle/oradata/orcl/assm01.dbf
/u01/app/oracle/oradata/orcl/mssm01.dbf
/u01/app/oracle/oradata/orcl/rc_data01.dbf
/u01/app/oracle/oradata/orcl/ogg01.dbf
/u01/app/oracle/oradata/orcl/yhqt01.dbf
/u01/app/oracle/oradata/orcl/test011.dbf

11 rows selected.

RMAN> alter database open resetlogs;

database opened
[oracle@DSI orcl]$ ll control0*
-rw-r----- 1 oracle oinstall 10076160 Jul 17 16:03 control01.ctl
-rw-r----- 1 oracle oinstall 10076160 Jul 17 16:03 control02.ctl
View Code

--2 手動修復不一致

場景1:控制文件自動備份關閉,在備份了控制文件后,dba刪除了一個test01表空間,在備份中這個表空間及數據文件還是存在的,

目前的狀況是所有控制文件損壞,無在線鏡像備份和自動備份可用。

首先還原控制文件

RMAN> restore controlfile from '/u01/app/oracle/fra/ORCL/autobackup/2019_07_17/o1_mf_s_1013855838_glx2gy3s_.bkp';
RMAN> mount database;
SQL> select name from v$datafile; ##查看被刪除的數據文件是否在存在
RMAN> recover database; ##此時會報錯 RMAN-06094:datafile 11 must be restored
SQL> alter database datafile 11 offline; ##使該數據文件下線
SQL> alter database using backup controlfile; ##使用該命令恢復數據庫,並在提示出現后輸入AUTO。注意L這可能在最后階段報錯ORA-27037和ORA-00308,意思是找不到某個歸檔日志,如果歸檔日志並沒有丟失或損壞,在sqlplus中找還沒有來得及歸檔的在線日志。
根據提示,輸入相應的在線重做日志
SQL> alter database using backup controlfile; ##如果dba不知道那個日志,隨便輸入任意在線重做日志,不是的話還是會報錯,不會用用錯的危險,在恢復途中使用的重做日志中一定有關於刪除test01表空間的記錄。
SQL> select name from v$datafile;
實際上,解決這個問題還可以采用一個更簡單的方法,在recover database時候使用skip tablespace跳過test01表空間,比如
RMAN> recover database skip tablespace test01;
注意,此時使用skip tablespace只能精確到表空間內所有的數據文件,前者可以精確到某一個數據文件
RMAN> alter database open resetlogs; ##最后resetlogs打開數據庫
--測試
RMAN> backup as backupset current controlfile;
SQL> drop tablespace test01;
SQL> select name from v$datafile;
[oracle@DSI orcl]$ mv control02.ctl c2.ctl
[oracle@DSI orcl]$ mv control01.ctl c1.ctl
[oracle@DSI orcl]$ ll control0*
[oracle@DSI ~]$ rman target /
RMAN>  startup;
RMAN> restore controlfile from '/u01/app/oracle/fra/ORCL/backupset/2019_07_17/o1_mf_ncnnf_TAG20190717T161208_glxp2spk_.bkp';
RMAN> mount database;
SQL> select name from v$datafile;
RMAN> recover database;
RMAN> alter database open resetlogs;

詳細點擊查看

--手動備份手動修復
RMAN> backup as backupset current controlfile;

Starting backup at 17-JUL-19
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
channel ORA_DISK_1: starting piece 1 at 17-JUL-19
channel ORA_DISK_1: finished piece 1 at 17-JUL-19
piece handle=/u01/app/oracle/fra/ORCL/backupset/2019_07_17/o1_mf_ncnnf_TAG20190717T161208_glxp2spk_.bkp tag=TAG20190717T161208 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 17-JUL-19
SQL> drop tablespace test01;

Tablespace dropped.

SQL> select name from v$datafile; 

NAME
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/orcl/system01.dbf
/u01/app/oracle/oradata/orcl/sysaux01.dbf
/u01/app/oracle/oradata/orcl/undotbs01.dbf
/u01/app/oracle/oradata/orcl/users01.dbf
/home/oracle/backup/test01.tts
/u01/app/oracle/oradata/orcl/assm01.dbf
/u01/app/oracle/oradata/orcl/mssm01.dbf
/u01/app/oracle/oradata/orcl/rc_data01.dbf
/u01/app/oracle/oradata/orcl/ogg01.dbf
/u01/app/oracle/oradata/orcl/yhqt01.dbf

10 rows selected.
[oracle@DSI orcl]$ mv control02.ctl c2.ctl
[oracle@DSI orcl]$ mv control01.ctl c1.ctl
[oracle@DSI orcl]$ ll control0*
ls: cannot access control0*: No such file or directory
[oracle@DSI ~]$ rman target /

Recovery Manager: Release 11.2.0.4.0 - Production on Wed Jul 17 16:14:32 2019

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

connected to target database (not started)

RMAN>  startup;

Oracle instance started
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of startup command at 07/17/2019 16:14:44
ORA-00205: error in identifying control file, check alert log for more info

RMAN> restore controlfile from '/u01/app/oracle/fra/ORCL/backupset/2019_07_17/o1_mf_ncnnf_TAG20190717T161208_glxp2spk_.bkp';

Starting restore at 17-JUL-19
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=135 device type=DISK

channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
output file name=/u01/app/oracle/oradata/orcl/control01.ctl
output file name=/u01/app/oracle/oradata/orcl/control02.ctl
Finished restore at 17-JUL-19
RMAN> mount database;

database mounted
released channel: ORA_DISK_1
SQL> select name from v$datafile;

NAME
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/orcl/system01.dbf
/u01/app/oracle/oradata/orcl/sysaux01.dbf
/u01/app/oracle/oradata/orcl/undotbs01.dbf
/u01/app/oracle/oradata/orcl/users01.dbf
/home/oracle/backup/test01.tts
/u01/app/oracle/oradata/orcl/assm01.dbf
/u01/app/oracle/oradata/orcl/mssm01.dbf
/u01/app/oracle/oradata/orcl/rc_data01.dbf
/u01/app/oracle/oradata/orcl/ogg01.dbf
/u01/app/oracle/oradata/orcl/yhqt01.dbf
/u01/app/oracle/oradata/orcl/test011.dbf

11 rows selected.
RMAN> recover database;

Starting recover at 17-JUL-19
Starting implicit crosscheck backup at 17-JUL-19
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=135 device type=DISK
Crosschecked 6 objects
Finished implicit crosscheck backup at 17-JUL-19

Starting implicit crosscheck copy at 17-JUL-19
using channel ORA_DISK_1
Finished implicit crosscheck copy at 17-JUL-19

searching for all files in the recovery area
cataloging files...
cataloging done

List of Cataloged Files
=======================
File Name: /u01/app/oracle/fra/ORCL/backupset/2019_07_17/o1_mf_ncnnf_TAG20190717T161208_glxp2spk_.bkp
File Name: /u01/app/oracle/fra/ORCL/autobackup/2019_07_17/o1_mf_s_1013875930_glxp2ts0_.bkp
File Name: /u01/app/oracle/fra/ORCL/autobackup/2019_07_17/o1_mf_s_1013855838_glx2gy3s_.bkp
File Name: /u01/app/oracle/fra/ORCL/autobackup/2019_07_17/o1_mf_s_1013855997_glx2mxy4_.bkp

using channel ORA_DISK_1

starting media recovery

archived log for thread 1 with sequence 1 is already on disk as file /u01/app/oracle/oradata/orcl/redo01.log
archived log file name=/u01/app/oracle/oradata/orcl/redo01.log thread=1 sequence=1
media recovery complete, elapsed time: 00:00:00
Finished recover at 17-JUL-19
SQL> /

NAME
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/orcl/system01.dbf
/u01/app/oracle/oradata/orcl/sysaux01.dbf
/u01/app/oracle/oradata/orcl/undotbs01.dbf
/u01/app/oracle/oradata/orcl/users01.dbf
/home/oracle/backup/test01.tts
/u01/app/oracle/oradata/orcl/assm01.dbf
/u01/app/oracle/oradata/orcl/mssm01.dbf
/u01/app/oracle/oradata/orcl/rc_data01.dbf
/u01/app/oracle/oradata/orcl/ogg01.dbf
/u01/app/oracle/oradata/orcl/yhqt01.dbf

10 rows selected.

RMAN> alter database open;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of alter db command at 07/17/2019 16:17:27
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open

RMAN> alter database open resetlogs;

database opened
View Code

這里測試與實際的有點差異,就是使用了存在快速恢復區里的多個控制文件的備份

8.3.7 缺少歸檔日志情況下的恢復

在恢復控制文件時recover database命令需要使用歸檔日志,所謂歸檔缺少就是指控制文件從備份還原后,在執行recover database命令時找不到相應的日志導致恢復終止的情況。

SQL> recover database until cancel;
ORA-00279: change 9793080 generated at 06/06/2019 15:42:14 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/fra/ORCL/archivelog/2019_06_06/o1_mf_1_32_%u_.arc
ORA-00280: change 9793080 for thread 1 is in sequence #32

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

ORA-00308: cannot open archived log
'/u01/app/oracle/fra/ORCL/archivelog/2019_06_06/o1_mf_1_32_%u_.arc'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/u01/app/oracle/oradata/orcl/system01.dbf'

這種情況下的恢復主要流程:

--1 首先還原控制文件,方式不限
--2 執行recover database報錯RMAN-06054,找不到某歸檔
--3 查看相關動態性能事務,對問題定性,確認問題與控制文件,而不是與數據文件相關
--4 利用create controlfile重建控制文件
--5 再次執行recover database,還會報RMAN-06054錯誤,這次是找不到另外一個歸檔日志
--6 查看v$log視圖確定第5步中索要的日志
--7 在sqlplus中執行recover database using backup controlfile等specify log提示符出現后給出正確的在線日志路徑,直到命令成功結束
--8 以resetlog命令打開數據庫
--9 添加temp臨時表空間
--10 將控制文件內其他丟失的信息用catalog和configure添加回去。

可以參考dsi系列的控制文件的相關恢復

8.4 noresetlogs收尾

前面的恢復操作都是使用alter database open resetlogs進行打開數據庫

其實不使用resetlogs打開也是可以的,關鍵方法是首先讓recover database命令成功完成,然后再重新創建一個控制文件,並在創建的命令中使用noresetlogs關鍵字

主要步驟:

--1 首先必須完成控制文件和數據庫的恢復(不可以是不完全恢復,因為不完全恢復無法擺脫resetlogs的命運)
--2 在將要使用resetlogs打開數據庫之前,執行alter database backup controlfile to trace 將恢復后的控制文件備份為追蹤文件
--3 重啟實例到nomount狀態
--4 用追蹤文件中的noresetlogs版本的create controlfile命令重新創建控制文件並進入mount狀態
--5 直接使用alter database open打開數據庫,如果遇到ORA-01113錯誤,先執行recover database命令,在打開數據庫
--6 創建temp臨時表空間
--7 將控制文件內丟失的其他信息補回,比如configure等

有關控制文件與只讀數據文件同時損壞的情況的恢復請參考之后的章節

有關控制文庫無備份的情況下的恢復請參考之前的dsi系列或之后的章節

如果參數文件和控制文件同時損壞,必須先恢復參數文件,並至少留意參數文件中幾個會影響控制文件恢復的參數

--db_recovery_file_dest

--db_namedb_unique_name(默認和db_name一樣)

決定備份和歸檔日志默認的搜索路徑;

--control_files確定restore controlfile的默認目的地,必要時可以先修改這些參數后再還原控制文件


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM