Oracle中文件損壞如何處理

今天就跟大家聊聊有關(guān)Oracle中文件損壞如何處理，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

概述

本文將給大家介紹oracle各類(lèi)文件損壞的現(xiàn)象和應(yīng)對(duì)策略，請(qǐng)注意所有的恢復(fù)都是基于有備份的情況，所以請(qǐng)開(kāi)啟數(shù)據(jù)庫(kù)的日常備份。

文章將從以下文件展開(kāi)：

a. 密碼文件

b. 參數(shù)文件

c. 控制文件

d. 數(shù)據(jù)文件(分普通表空間數(shù)據(jù)文件，其它表空間數(shù)據(jù)文件如system、sysaux、undo)

e. 日志文件(分current、active、inactive)

在正式實(shí)驗(yàn)之前，我先問(wèn)一個(gè)問(wèn)題，上面這些文件，哪個(gè)損壞最致命？歡迎在文末留言處留言。

環(huán)境準(zhǔn)備

本實(shí)驗(yàn)在oracle 11G歸檔模式下進(jìn)行，實(shí)驗(yàn)前先對(duì)數(shù)據(jù)庫(kù)做個(gè)全庫(kù)備份。

創(chuàng)建一個(gè)普通表空間和一些測(cè)試表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;  // 全庫(kù)備份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

密碼文件損壞

文件說(shuō)明：密碼文件存儲(chǔ)的是sys密碼

模擬故障：清空該文件

echo '' > $ORACLE_HOME/dbs/orapworcltest  // orcltest是該數(shù)據(jù)庫(kù)的實(shí)例名

現(xiàn)象：使用sys通過(guò)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ù)文件損壞

文件說(shuō)明：這里所說(shuō)的參數(shù)文件指的是spfile，該文件存儲(chǔ)的是實(shí)例啟動(dòng)的參數(shù)和控制文件的路徑

模擬故障：清空該文件

echo '' > $ORACLE_HOME/dbs/spfileorcltest.ora

現(xiàn)象：修改數(shù)據(jù)庫(kù)參數(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è)新的路徑，然后手工移過(guò)去

PS：參數(shù)文件也可以從內(nèi)存中直接創(chuàng)建一個(gè)新的，更省事（create spfile='/home/oracle/spfileorcltest.ora' from memory;）

控制文件損壞

文件說(shuō)明：控制文件記錄數(shù)據(jù)庫(kù)文件的信息和日志的信息等

查看控制文件

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ù)庫(kù)宕機(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ù)庫(kù)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對(duì)控制文件進(jìn)行恢復(fù)  RMAN> alter database open resetlogs;

說(shuō)明：

a. 不要使用刪控制文件的方式去模擬該實(shí)驗(yàn)，這是由于ckpt、lgwr進(jìn)程已經(jīng)打開(kāi)了控制文件，內(nèi)存中已經(jīng)有了這個(gè)控制文件的鏡像，而rm命令并不能把這些進(jìn)程已經(jīng)打開(kāi)的控制文件的句柄刪掉。所以你會(huì)發(fā)現(xiàn)實(shí)例并沒(méi)有掛掉。

b. 對(duì)數(shù)據(jù)庫(kù)resetlogs之后，之前的備份就作廢了，所以應(yīng)該第一時(shí)間對(duì)數(shù)據(jù)庫(kù)做一個(gè)全備。

c. 可能大家也注意到了，該實(shí)驗(yàn)中只有一個(gè)controlfile，當(dāng)controlfile被破壞了之后，實(shí)例就掛了。如果是controlfile的多路復(fù)用，其中一個(gè)controlfile壞了數(shù)據(jù)庫(kù)又是什么影響？我這里先說(shuō)下我的結(jié)論：controlfile只要有一個(gè)壞了，實(shí)例就會(huì)奔潰，同時(shí)在alert日志中會(huì)提示具體是哪個(gè)controlfile損壞，解決辦法就是復(fù)制一份好的controlfile去替換損壞的controlfile，重新啟庫(kù)即可。實(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ù)庫(kù)resetlogs，這將會(huì)導(dǎo)致之前的備份片無(wú)效，所以恢復(fù)控制文件后最好做一個(gè)全庫(kù)備份。

2. 對(duì)控制文件最好設(shè)置兩個(gè)，一個(gè)壞了還能利用另一個(gè)恢復(fù)，對(duì)數(shù)據(jù)庫(kù)的影響和恢復(fù)的時(shí)間都是最小的。

數(shù)據(jù)文件損壞

為了繼續(xù)實(shí)驗(yàn)，請(qǐng)手工刪除之前所有的歸檔日志和備份文件，并對(duì)現(xiàn)在的數(shù)據(jù)庫(kù)做一個(gè)全備

RMAN> backup database;  // 全庫(kù)備份

6.1 普通數(shù)據(jù)文件損壞

模擬故障：將該文件清空

echo '' > /u01/app/oracle/oradata/orcltest/tbs01.dbf  // tbs01是一個(gè)普通表空間數(shù)據(jù)文件

現(xiàn)象：查詢(xún)?cè)摂?shù)據(jù)文件上的對(duì)象報(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ù)：先對(duì)數(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)象：查詢(xú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)庫(kù)，然后使用rman還原恢復(fù)，最后啟庫(kù)

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)象：訪問(wèn)sysaux表空間的對(duì)象報(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)前正在寫(xiě)入的日志組，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ù)庫(kù)切換到該日志組時(shí)，數(shù)據(jù)庫(kù)并不知道磁盤(pán)上的日志文件有問(wèn)題，只是將內(nèi)容寫(xiě)到日志文件在內(nèi)存的拷貝中，等到切換的時(shí)候，日志文件落盤(pán)就會(huì)發(fā)現(xiàn)該日志是有問(wèn)題的，然后alert日志出現(xiàn)報(bào)錯(cuò)，不過(guò)不影響數(shù)據(jù)庫(kù)正常運(yùn)行，只是以后數(shù)據(jù)庫(kù)切換日志會(huì)跳過(guò)該日志組

SQL> insert into scott.t01 select * from scott.t01;  // 重復(fù)對(duì)一張表進(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一直沒(méi)有被用到

修復(fù)：將該日志文件重新初始化

SQL> alter database clear unarchived logfile group 3;  // active的日志損壞也是類(lèi)似處理，使用該命令后數(shù)據(jù)庫(kù)歸檔會(huì)斷，所以在恢復(fù)日志組后，應(yīng)立即進(jìn)行全庫(kù)備份。

7.2 current日志文件損壞

為了繼續(xù)實(shí)驗(yàn)，請(qǐng)手工刪除之前所有的歸檔日志和備份文件，并對(duì)現(xiàn)在的數(shù)據(jù)庫(kù)做一個(gè)全備

RMAN> backup database;  // 全庫(kù)備份

查看當(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ù)庫(kù)宕機(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ù)打開(kāi)

sqlplus / as sysdba  SQL> startup mount  SQL> recover database until cancel;  // 不完全恢復(fù)

SQL> alter database open resetlogs;  // 會(huì)發(fā)現(xiàn)啟庫(kù)失敗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;

說(shuō)明：

a. 使用該方式恢復(fù)的庫(kù)，可能會(huì)造成數(shù)據(jù)的丟失，而且也并不能保證一定成功。

b. 恢復(fù)成功后，應(yīng)將表全部使用expdp導(dǎo)出，重建庫(kù)。

c. 上面的實(shí)驗(yàn)每個(gè)日志組都只有一個(gè)member，如果每個(gè)日志組有兩個(gè)member又是什么樣子呢？

先說(shuō)下我的結(jié)論：損壞其中任何一個(gè)member對(duì)數(shù)據(jù)庫(kù)沒(méi)什么影響，只是在切換到有member損壞的日志組時(shí)，會(huì)在alert日志中提示告警ORA-00313 ORA-00312 ORA-27048，解決辦法就是刪掉這個(gè)member，重新添加，不需要對(duì)數(shù)據(jù)庫(kù)進(jìn)行重啟，實(shí)驗(yàn)過(guò)程我就不展示了。所以最好是每組日志中設(shè)置2個(gè)成員。

這兒我有個(gè)疑問(wèn)想不通：對(duì)inactive的日志進(jìn)行破壞，數(shù)據(jù)庫(kù)切換到這個(gè)被破壞的日志時(shí)，數(shù)據(jù)庫(kù)正常寫(xiě)，只是在日志切換的時(shí)候報(bào)錯(cuò)，這個(gè)能理解，因?yàn)橄到y(tǒng)內(nèi)存中有這個(gè)被破壞的日志之前的拷貝，所有的寫(xiě)可能都是在內(nèi)存中。切換的時(shí)候該日志文件就必須要落盤(pán)，所以提示報(bào)錯(cuò)。而對(duì)current的日志進(jìn)行破壞，數(shù)據(jù)庫(kù)也正常寫(xiě)，但是在日志切換的時(shí)候數(shù)據(jù)庫(kù)直接崩了。沒(méi)弄懂這兩個(gè)為什么會(huì)有這個(gè)區(qū)別。

看完上述內(nèi)容，你們對(duì)Oracle中文件損壞如何處理有進(jìn)一步的了解嗎？如果還想了解更多知識(shí)或者相關(guān)內(nèi)容，請(qǐng)關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。