史上最全Oracle文件損壞處理辦法 (附實(shí)驗(yàn)步驟)
概述
本文將給大家介紹oracle各類文件損壞的現(xiàn)象和應(yīng)對策略，請注意所有的恢復(fù)都是基于有備份的情況，所以請開啟數(shù)據(jù)庫的日常備份。
文章將從以下文件展開：
a. 密碼文件
b. 參數(shù)文件
c. 控制文件
d. 數(shù)據(jù)文件(分普通表空間數(shù)據(jù)文件，其它表空間數(shù)據(jù)文件如system、sysaux、undo)
e. 日志文件(分current、active、inactive)
在正式實(shí)驗(yàn)之前，我先問一個(gè)問題，上面這些文件，哪個(gè)損壞最致命？歡迎在文末留言處留言。
環(huán)境準(zhǔn)備
本實(shí)驗(yàn)在oracle 11G歸檔模式下進(jìn)行，實(shí)驗(yàn)前先對數(shù)據(jù)庫做個(gè)全庫備份。
- 創(chuàng)建一個(gè)普通表空間和一些測試表create tablespace tbs01 datafile '/u01/app/oracle/oradata/orcltest/tbs01.dbf' size 500m;create table scott.t01 tablespace tbs01 as select * from dba_objects where rownum<=100;RMAN> backup database; // 全庫備份RMAN> list backup; // 查看備份
- BS Key Type LV Size Device Type Elapsed Time Completion Time------- ---- -- ---------- ----------- ------------ ---------------21 Full 1.14G DISK 00:01:33 17-MAR-20 BP Key: 21 Status: AVAILABLE Compressed: NO Tag: TAG20200317T133425 Piece Name: /home/oracle/backupdir/ORCLTEST_2750922031_133_1_20200317_1035293665.bkp List of Datafiles in backup set 21File LV Type Ckp SCN Ckp Time Name---- -- ---- ---------- --------- ----1 Full 1606913 17-MAR-20 /u01/app/oracle/oradata/orcltest/system01.dbf2 Full 1606913 17-MAR-20 /u01/app/oracle/oradata/orcltest/sysaux01.dbf3 Full 1606913 17-MAR-20 /u01/app/oracle/oradata/orcltest/undotbs01.dbf4 Full 1606913 17-MAR-20 /u01/app/oracle/oradata/orcltest/users01.dbf5 Full 1606913 17-MAR-20 /u01/app/oracle/oradata/orcltest/example01.dbf6 Full 1606913 17-MAR-20 /u01/app/oracle/oradata/orcltest/tbs01.dbfBS Key Type LV Size Device Type Elapsed Time Completion Time------- ---- -- ---------- ----------- ------------ ---------------22 Full 9.73M DISK 00:00:02 17-MAR-20 BP Key: 22 Status: AVAILABLE Compressed: NO Tag: TAG20200317T133602 Piece Name: /home/oracle/backupdir/c-2750922031-20200317-00SPFILE Included: Modification time: 17-MAR-20SPFILE db_unique_name: ORCLTEST Control File Included: Ckp SCN: 1606985 Ckp time: 17-MAR-20
密碼文件損壞
文件說明：密碼文件存儲(chǔ)的是sys密碼
模擬故障：清空該文件
- echo '' > $ORACLE_HOME/dbs/orapworcltest // orcltest是該數(shù)據(jù)庫的實(shí)例名
現(xiàn)象：使用sys通過oracle net登錄報(bào)密碼錯(cuò)誤
sqlplus sys/123456@10.40.16.120:1521/orcltest as sysdba
- SQL*Plus: Release 11.2.0.4.0 Production on Tue Mar 17 13:57:52 2020Copyright (c) 1982, 2013, Oracle. All rights reserved.ERROR:ORA-01017: invalid username/password; logon deniedEnter user-name:
修復(fù)：使用自帶工具orapwd重新生成密碼文件
- orapwd file=$ORACLE_HOME/dbs/orapworcltest password=123456 force=y // force=y如果原密碼文件存在，強(qiáng)制覆蓋
參數(shù)文件損壞
文件說明：這里所說的參數(shù)文件指的是spfile，該文件存儲(chǔ)的是實(shí)例啟動(dòng)的參數(shù)和控制文件的路徑
模擬故障：清空該文件
- echo '' > $ORACLE_HOME/dbs/spfileorcltest.ora
現(xiàn)象：修改數(shù)據(jù)庫參數(shù)時(shí)會(huì)報(bào)錯(cuò)
- SQL> alter system set open_cursors=400;alter system set open_cursors=400*ERROR at line 1:ORA-01565: error in identifying file'/u01/app/oracle/product/11.2.0/db_1/dbs/spfileorcltest.ora'ORA-27046: file size is not a multiple of logical block sizeAdditional information: 1
修復(fù)：使用rman還原參數(shù)文件
- RMAN> list backup of spfile;BS Key Type LV Size Device Type Elapsed Time Completion Time------- ---- -- ---------- ----------- ------------ ---------------22 Full 9.73M DISK 00:00:02 17-MAR-20BP Key: 22 Status: AVAILABLE Compressed: NO Tag: TAG20200317T133602Piece Name: /home/oracle/backupdir/c-2750922031-20200317-00SPFILE Included: Modification time: 17-MAR-20SPFILE db_unique_name: ORCLTEST
- RMAN> restore spfile to '/home/oracle/spfileorcltest.ora' from '/home/oracle/backupdir/c-2750922031-20200317-00';
- mv /home/oracle/spfileorcltest.ora /u01/app/oracle/product/11.2.0/db_1/dbs/
- SQL> shutdown immediate
- SQL> startup
注意在還原spfile的時(shí)候如果還原到spfile原先的位置，會(huì)報(bào)ORA-32011: cannot restore SPFILE to location already being used by the instance
所以需要還原到一個(gè)新的路徑，然后手工移過去
PS：參數(shù)文件也可以從內(nèi)存中直接創(chuàng)建一個(gè)新的，更省事（create spfile='/home/oracle/spfileorcltest.ora' from memory;）
控制文件損壞
文件說明：控制文件記錄數(shù)據(jù)庫文件的信息和日志的信息等
查看控制文件
- SQL> show parameter control_files
- NAME TYPE VALUE
- ------------------------------------ ----------- ------------------------------
- control_files string /u01/app/oracle/oradata/orclte
- st/control01.ctl
模擬故障：將該文件清空
- echo '' > /u01/app/oracle/oradata/orcltest/control01.ctl
現(xiàn)象：前臺(tái)正常的增刪改查不受影響，但一旦出現(xiàn)切換日志或產(chǎn)生檢查點(diǎn)時(shí)數(shù)據(jù)庫宕機(jī)
- SQL> alter system switch logfile;alter system switch logfile*ERROR at line 1:ORA-03113: end-of-file on communication channelProcess ID: 3433Session ID: 1 Serial number: 5
數(shù)據(jù)庫alert日志
- Tue Mar 17 17:39:06 2020Errors in file /u01/app/oracle/diag/rdbms/orcltest/orcltest/trace/orcltest_ckpt_3415.trc:ORA-00202: control file: '/u01/app/oracle/oradata/orcltest/control01.ctl'ORA-27072: File I/O error...LGWR (ospid: 3413): terminating the instance due to error 227Tue Mar 17 17:40:37 2020System state dump requested by (instance=1, osid=3413 (LGWR)), summary=[abnormal instance termination].System State dumped to trace file /u01/app/oracle/diag/rdbms/orcltest/orcltest/trace/orcltest_diag_3403_20200317174037.trcDumping diagnostic data in directory=[cdmp_20200317174037], requested by (instance=1, osid=3413 (LGWR)), summary=[abnormal instance termination].Instance terminated by LGWR, pid = 3413
可以看到ckpt這個(gè)進(jìn)程最先發(fā)現(xiàn)控制文件損壞了，實(shí)例之后被lgwr進(jìn)程殺掉?？赡艽蠹以谧鰧?shí)驗(yàn)的時(shí)候發(fā)現(xiàn)實(shí)例是被ckpt殺掉，這也是有可能的，反正可以肯定的一點(diǎn)是，實(shí)例最后肯定會(huì)掛掉
修復(fù)：使用rman還原控制文件
- rman target /
- RMAN> startup nomount
- RMAN> restore controlfile from '/home/oracle/backupdir/c-2750922031-20200317-00';
- RMAN> alter database mount;
- RMAN> recover database; // 這一步其實(shí)是使用archivedlog + redolog對控制文件進(jìn)行恢復(fù)
- RMAN> alter database open resetlogs;
說明：
a. 不要使用刪控制文件的方式去模擬該實(shí)驗(yàn)，這是由于ckpt、lgwr進(jìn)程已經(jīng)打開了控制文件，內(nèi)存中已經(jīng)有了這個(gè)控制文件的鏡像，而rm命令并不能把這些進(jìn)程已經(jīng)打開的控制文件的句柄刪掉。所以你會(huì)發(fā)現(xiàn)實(shí)例并沒有掛掉。
b. 對數(shù)據(jù)庫resetlogs之后，之前的備份就作廢了，所以應(yīng)該第一時(shí)間對數(shù)據(jù)庫做一個(gè)全備。
c. 可能大家也注意到了，該實(shí)驗(yàn)中只有一個(gè)controlfile，當(dāng)controlfile被破壞了之后，實(shí)例就掛了。如果是controlfile的多路復(fù)用，其中一個(gè)controlfile壞了數(shù)據(jù)庫又是什么影響？我這里先說下我的結(jié)論：controlfile只要有一個(gè)壞了，實(shí)例就會(huì)奔潰，同時(shí)在alert日志中會(huì)提示具體是哪個(gè)controlfile損壞，解決辦法就是復(fù)制一份好的controlfile去替換損壞的controlfile，重新啟庫即可。實(shí)驗(yàn)就留給大家自己做吧。附一段我實(shí)驗(yàn)的alert日志（ORA-00227: corrupt block detected in control file: (block 1, # blocks 1) ORA-00202: control file: '/u01/app/oracle/oradata/orcltest/control02.ctl'）
總結(jié)：
1. 控制文件恢復(fù)不會(huì)丟失任何事務(wù)，但會(huì)要求數(shù)據(jù)庫resetlogs，這將會(huì)導(dǎo)致之前的備份片無效，所以恢復(fù)控制文件后最好做一個(gè)全庫備份。
2. 對控制文件最好設(shè)置兩個(gè)，一個(gè)壞了還能利用另一個(gè)恢復(fù)，對數(shù)據(jù)庫的影響和恢復(fù)的時(shí)間都是最小的。
數(shù)據(jù)文件損壞
為了繼續(xù)實(shí)驗(yàn)，請手工刪除之前所有的歸檔日志和備份文件，并對現(xiàn)在的數(shù)據(jù)庫做一個(gè)全備
- RMAN> backup database; // 全庫備份
6.1 普通數(shù)據(jù)文件損壞
模擬故障：將該文件清空
echo '' > /u01/app/oracle/oradata/orcltest/tbs01.dbf // tbs01是一個(gè)普通表空間數(shù)據(jù)文件
現(xiàn)象：查詢該數(shù)據(jù)文件上的對象報(bào)錯(cuò)
- SQL> select * from scott.t01; // t01表在tbs01.dbf文件上select * from scott.t01 *ERROR at line 1:ORA-01115: IO error reading block from file (block # )ORA-01110: data file 6: '/u01/app/oracle/oradata/orcltest/tbs01.dbf'ORA-27072: File I/O errorAdditional information: 4Additional information: 130
修復(fù)：先對數(shù)據(jù)文件offline，然后使用rman還原恢復(fù)，最后online
- SQL> alter database datafile 6 offline;RMAN> restore datafile 6;RMAN> recover datafile 6; SQL> alter database datafile 6 online;
6.2 system表空間數(shù)據(jù)文件損壞
模擬故障：將該文件清空
- echo '' > /u01/app/oracle/oradata/orcltest/system01.dbf
現(xiàn)象：查詢數(shù)據(jù)字典報(bào)錯(cuò)
- SQL> select * from dba_users;select * from dba_users *ERROR at line 1:ORA-00604: error occurred at recursive SQL level 1ORA-01115: IO error reading block from file (block # )ORA-01110: data file 1: '/u01/app/oracle/oradata/orcltest/system01.dbf'ORA-27072: File I/O errorAdditional information: 4Additional information: 95524
修復(fù)：先關(guān)庫，然后使用rman還原恢復(fù)，最后啟庫
- SQL> shutdown abortSQL> startup mountRMAN> restore datafile 1;RMAN> recover datafile 1; SQL> alter database open;
6.3 sysaux和undo表空間數(shù)據(jù)文件損壞
sysaux表空間的文件損壞處理手段與普通表空間數(shù)據(jù)文件損壞處理手段相同，undo表空間的文件損壞處理手段與system表空間數(shù)據(jù)文件損壞處理手段相同，因?yàn)閡ndo表空間的數(shù)據(jù)文件也不能offline。限于篇幅省略實(shí)驗(yàn)步驟，僅貼出文件損壞的現(xiàn)象。
sysaux表空間文件損壞現(xiàn)象：訪問sysaux表空間的對象報(bào)錯(cuò)
- SQL> select * from sys.WRI$_OPTSTAT_HISTHEAD_HISTORY;
- ERROR:
- ORA-01578: ORACLE data block corrupted (file # 2, block # 986)
- ORA-01110: data file 2: '/u01/app/oracle/oradata/orcltest/sysaux01.dbf'
undo表空間文件損壞現(xiàn)象：所有修改操作全部報(bào)錯(cuò)
- SQL> insert into scott.t01 select * from scott.t01;insert into scott.t01 select * from scott.t01 *ERROR at line 1:ORA-00603: ORACLE server session terminated by fatal errorORA-01578: ORACLE data block corrupted (file # 3, block # 144)ORA-01110: data file 3: '/u01/app/oracle/oradata/orcltest/undotbs01.dbf'ORA-01578: ORACLE data block corrupted (file # 3, block # 144)ORA-01110: data file 3: '/u01/app/oracle/oradata/orcltest/undotbs01.dbf'Process ID: 2835Session ID: 20 Serial number: 85
日志文件損壞
7.1 inactive或active日志文件損壞
查看當(dāng)前日志狀態(tài)：current-當(dāng)前正在寫入的日志組，active-還未歸檔的日志組，inactive-已歸檔的日志組
- SQL> select a.group#, a.member, b.status from v$logfile a, v$log b where a.group#=b.group# order by group#;
- GROUP# MEMBER STATUS
- ---------- -------------------------------------------------- ------------
- 1 /u01/app/oracle/oradata/orcltest/redo01.log INACTIVE
- 2 /u01/app/oracle/oradata/orcltest/redo02.log CURRENT
- 3 /u01/app/oracle/oradata/orcltest/redo03.log INACTIVE
模擬故障：將inactive日志文件清空
- echo '' > /u01/app/oracle/oradata/orcltest/redo03.log
現(xiàn)象：當(dāng)數(shù)據(jù)庫切換到該日志組時(shí)，數(shù)據(jù)庫并不知道磁盤上的日志文件有問題，只是將內(nèi)容寫到日志文件在內(nèi)存的拷貝中，等到切換的時(shí)候，日志文件落盤就會(huì)發(fā)現(xiàn)該日志是有問題的，然后alert日志出現(xiàn)報(bào)錯(cuò)，不過不影響數(shù)據(jù)庫正常運(yùn)行，只是以后數(shù)據(jù)庫切換日志會(huì)跳過該日志組
- SQL> insert into scott.t01 select * from scott.t01; // 重復(fù)對一張表進(jìn)行插入，模擬產(chǎn)生大量的日志
觀察alert日志
- Errors in file /u01/app/oracle/diag/rdbms/orcltest/orcltest/trace/orcltest_arc0_9006.trc:
- ORA-00313: open failed for members of log group 3 of thread 1
- ORA-00312: online log 3 thread 1: '/u01/app/oracle/oradata/orcltest/redo03.log'
- ORA-27048: skgfifi: file header information is invalid
- Additional information: 12
- Master archival failure: 313
- SQL> alter system switch logfile;
查看v$log，可以看到group 3一直沒有被用到
修復(fù)：將該日志文件重新初始化
- SQL> alter database clear unarchived logfile group 3; // active的日志損壞也是類似處理，使用該命令后數(shù)據(jù)庫歸檔會(huì)斷，所以在恢復(fù)日志組后，應(yīng)立即進(jìn)行全庫備份。
7.2 current日志文件損壞
為了繼續(xù)實(shí)驗(yàn)，請手工刪除之前所有的歸檔日志和備份文件，并對現(xiàn)在的數(shù)據(jù)庫做一個(gè)全備
- RMAN> backup database; // 全庫備份
查看當(dāng)前日志狀態(tài)
- SQL> select a.group#, a.member, b.status from v$logfile a, v$log b where a.group#=b.group# order by group#; GROUP# MEMBER STATUS---------- -------------------------------------------------- ------------1 /u01/app/oracle/oradata/orcltest/redo01.log INACTIVE2 /u01/app/oracle/oradata/orcltest/redo02.log INACTIVE3 /u01/app/oracle/oradata/orcltest/redo03.log CURRENTSQL> create table scott.t02 as select * from dba_users;
模擬故障：current日志文件清空
- echo '' > /u01/app/oracle/oradata/orcltest/redo03.log
現(xiàn)象：前臺(tái)正常的增刪改查不受影響，但一旦出現(xiàn)切換日志數(shù)據(jù)庫宕機(jī)
- SQL> create table scott.t03 as select * from dba_users;SQL> alter system switch logfile;alter system switch logfile*ERROR at line 1:ORA-03113: end-of-file on communication channelProcess ID: 3758Session ID: 1 Serial number: 9
查看alert日志
- Errors in file /u01/app/oracle/diag/rdbms/orcltest/orcltest/trace/orcltest_lgwr_8969.trc:
- ORA-00316: log 2 of thread 1, type 0 in header is not log file
- ORA-00312: online log 2 thread 1: '/u01/app/oracle/oradata/orcltest/redo02.log'
- LGWR (ospid: 8969): terminating the instance due to error 316
- Instance terminated by LGWR, pid = 3458
恢復(fù)：使用不完全恢復(fù)打開
- sqlplus / as sysdba
- SQL> startup mount
- SQL> recover database until cancel; // 不完全恢復(fù)
- SQL> alter database open resetlogs; // 會(huì)發(fā)現(xiàn)啟庫失敗alter database open resetlogs*ERROR at line 1:ORA-01194: file 1 needs more recovery to be consistentORA-01110: data file 1: '/u01/app/oracle/oradata/orcltest/system01.dbf'
這個(gè)時(shí)候就需要加入隱含參數(shù)，再啟動(dòng)
- SQL> alter system set "_allow_resetlogs_corruption"=true scope=spfile; SQL> shutdown abortSQL> startup mountSQL> recover database until cancel; // 不完全恢復(fù)輸入cancelSQL> alter database open resetlogs;
說明：
a. 使用該方式恢復(fù)的庫，可能會(huì)造成數(shù)據(jù)的丟失，而且也并不能保證一定成功。
b. 恢復(fù)成功后，應(yīng)將表全部使用expdp導(dǎo)出，重建庫。
c. 上面的實(shí)驗(yàn)每個(gè)日志組都只有一個(gè)member，如果每個(gè)日志組有兩個(gè)member又是什么樣子呢？
先說下我的結(jié)論：損壞其中任何一個(gè)member對數(shù)據(jù)庫沒什么影響，只是在切換到有member損壞的日志組時(shí)，會(huì)在alert日志中提示告警ORA-00313 ORA-00312 ORA-27048，解決辦法就是刪掉這個(gè)member，重新添加，不需要對數(shù)據(jù)庫進(jìn)行重啟，實(shí)驗(yàn)過程我就不展示了。所以最好是每組日志中設(shè)置2個(gè)成員。
這兒我有個(gè)疑問想不通：對inactive的日志進(jìn)行破壞，數(shù)據(jù)庫切換到這個(gè)被破壞的日志時(shí)，數(shù)據(jù)庫正常寫，只是在日志切換的時(shí)候報(bào)錯(cuò)，這個(gè)能理解，因?yàn)橄到y(tǒng)內(nèi)存中有這個(gè)被破壞的日志之前的拷貝，所有的寫可能都是在內(nèi)存中。切換的時(shí)候該日志文件就必須要落盤，所以提示報(bào)錯(cuò)。而對current的日志進(jìn)行破壞，數(shù)據(jù)庫也正常寫，但是在日志切換的時(shí)候數(shù)據(jù)庫直接崩了。沒弄懂這兩個(gè)為什么會(huì)有這個(gè)區(qū)別。
總結(jié)
1. 生產(chǎn)中應(yīng)制定好備份策略
2. 控制文件和日志文件最好是設(shè)置大于一個(gè)成員
3. 當(dāng)前日志組損壞最為致命，如果日志寫很繁忙，可以只為日志文件配置一個(gè)成員，但同時(shí)需要配置一個(gè)dataguard，方便切換
4. 此博客僅為個(gè)人理解，如有不對的地方，歡迎大家指出
