oracle-SYSTEM表空間的備份與恢復(fù)

這一篇在介紹備份及恢復(fù)數(shù)據(jù)文件的方法時，以備份和重做日志（包括歸檔日志和在線日志）沒有丟失為前提

所謂關(guān)鍵數(shù)據(jù)文件：system表空間的數(shù)據(jù)文件與參數(shù)undo_tablespace指向的自動撤銷表空間的數(shù)據(jù)文件（undo_tablespace數(shù)據(jù)文件）。

它們的損壞（整體或局部）會導(dǎo)致SQL命令執(zhí)行失敗、用戶session強制斷開、sys用戶無法登陸、甚至整個實例崩潰。

SQL> select file_id,file_name from dba_data_files where tablespace_name in ('SYSTEM',(select value from v$parameter where name='undo_tablespace'));FILE_ID FILE_NAME ---------- -------------------------------------------------- 3 /u01/app/oracle/oradata/orcl/undotbs01.dbf 1 /u01/app/oracle/oradata/orcl/system01.dbf

9.1 關(guān)鍵數(shù)據(jù)文件損壞的后果

9.1.1 system表空間數(shù)據(jù)文件損壞

SYSTEM表空間內(nèi)部保存兩類重要數(shù)據(jù)：oracle數(shù)據(jù)庫的系統(tǒng)表（數(shù)據(jù)字典），是數(shù)據(jù)庫正常運行的基本保障：以及名為SYS.SYSTEM的撤銷段（undo segment）系統(tǒng)回滾段。

討論情況：文件丟失、文件頭損壞、數(shù)據(jù)庫字段損壞及SYS.SYSTEM撤銷段損壞

--1 若system01.dbf文件丟失或無法訪問，startup啟動到mount狀態(tài) --2 若system01.dbf文件頭損壞，運行時檢查點發(fā)起后實例崩潰，startup啟動到mount狀態(tài) --3 如果數(shù)據(jù)字典損壞，數(shù)據(jù)庫內(nèi)的對象定義系統(tǒng)、名稱解析系統(tǒng)、用戶賬號系統(tǒng)及權(quán)限管理都將崩潰。若損壞發(fā)生在實例運行時，通常會導(dǎo)致SQL命令產(chǎn)生ORA-00604的錯誤；若損壞發(fā)生在實例啟動時，啟動流程不一定會終止，但是alert log中會有ORA-01578和ORA-01110錯誤。 --4 system01.dbf 文件名中為SYS.SYSTEM撤銷段頭部損壞，在啟動時startup實例會強制關(guān)閉，必須使用startup mount才能進入mount狀態(tài)。

以下是一些各種是system01.dbf文件損壞的場景

場景1：啟動數(shù)據(jù)庫是發(fā)現(xiàn)system01.dbf文件丟失，啟動中斷

SQL> startup ORA-01157: cannot identify/lock data file 1 -see DBWR trace file ORA-01110:data file 1 : ‘/u01/app/oracle/oradata/orcl/system01.dbf’

場景2：啟動數(shù)據(jù)庫發(fā)現(xiàn)system01.dbf文件頭部損壞，啟動中斷

SQL> startup 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 Database mounted. ORA-01122: database file 1 failed verification check ORA-01110: data file 1: '/u01/app/oracle/oradata/orcl/system01.dbf' ORA-01210: data file header is media corrupt

場景3：數(shù)據(jù)庫運行時，system01.dbf文件中保存用戶賬號信息的數(shù)據(jù)字典SYS.USER$的數(shù)據(jù)塊損壞，使用后登錄失敗

$ sqlplus test/*** ERROR: ORA-00604: error occurred at recursive SQL level 1 ORA-01578: ORACLE data block corrupted (file # 1,block # 213) ORA-01110: data file 1: '/u01/app/oracle/oradata/orcl/system01.dbf'

場景4：數(shù)據(jù)庫運行時system01.dbf文件中的數(shù)據(jù)字典SYS.TAB$數(shù)據(jù)塊損壞

SQL> select * from test.t1; ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-01578: ORACLE data block corrupted (file # 1,block # 83226) ORA-01110: data file 1: '/u01/app/oracle/oradata/orcl/system01.dbf'

場景5：數(shù)據(jù)字典SYS.PROCEDURE$中數(shù)據(jù)塊損壞，任何create、drop和rename都報錯

SQL> create table test.t2 (id number,name varchar2(20)) tablespace test; ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-01578: ORACLE data block corrupted (file # 1,block # 89226) ORA-01110: data file 1: '/u01/app/oracle/oradata/orcl/system01.dbf'

場景6：SYS.SYSTEM撤銷段頭部損壞，實例被強制中斷

SQL> startup ORA-01092: ORACLE instance terminated, Disconnection forced ORA-01578: ORACLE data block corrupted (file # 1,block # 128) ORA-01110: data file 1: '/u01/app/oracle/oradata/orcl/system01.dbf'

場景7：SYS.SYSTEM撤銷段與undo_tablespace表空間撤銷段同時損壞，執(zhí)行DDL時候報錯

SQL> drop table test.t1; ORA-00603 : ORACLE server session terminated by fatal error

場景8：運行時，system01.dbf或undo_tablespace數(shù)據(jù)文件頭部損壞，檢查點無法順利完成，在alter log中

ORA-01243: system tablespace file suffered media failure ORA-01122: database file 1 failed verification check

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

undo_tablespace數(shù)據(jù)文件是undotbs01.dbf，它用來保存所有的變更類命令（DDL\DML）所產(chǎn)生的撤銷數(shù)據(jù)（undo data）

--1 undotbs01.dbf文件丟失無法訪問，startup啟動到mount狀態(tài) --2 undotbs01.dbf文件頭損壞，startup啟動到mount，運行時檢查點發(fā)起后實例崩潰 --3 若表空間中的某些塊損壞，DML可能失敗，若全部損壞，DML肯定全部失敗 SQL> select name from v$rollname where name<> 'SYSTEM'; NAME ------------------------------ _SYSSMU1_1925302723$ _SYSSMU2_2273571325$ _SYSSMU3_798971445$ _SYSSMU4_2493343136$ _SYSSMU5_44098047$ _SYSSMU6_4194993272$ _SYSSMU7_3978436573$ _SYSSMU8_3643869769$ _SYSSMU9_4157155965$ _SYSSMU10_1224346732$ 10 rows selected.

場景1：運行時，undotbs01.dbf頭損壞（3號文件，160號數(shù)據(jù)塊）

SQL> update test.t1 set name=’yhq’ where id=1; ERROR at line 1: ORA-00603: ORACLE server session terminated by fatal error ORA-01578: ORACLE data block corrupted (file # 3,block # 160) ORA-01110: data file 3: ‘/u01/app/oracle/oradata/orcl/undotbs01.dbf’

場景2：啟動時，undotbs01.dbf文件頭部損壞

SQL> startup ORA-01092: ORACLE instance terminated, Disconnection forced ORA-01578: ORACLE data block corrupted (file # 3,block # 128) ORA-01110: data file 3: '/u01/app/oracle/oradata/orcl/undotbs01.dbf'

9.2 備份

使用RMAN的backup database、backup datafile、backup tablespace都可以備份數(shù)據(jù)文件

RMAN> backup as backupset tablespace system,undotbs1; Starting backup at 18-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=00003 name=/u01/app/oracle/oradata/orcl/undotbs01.dbf input datafile file number=00001 name=/u01/app/oracle/oradata/orcl/system01.dbf channel ORA_DISK_1: starting piece 1 at 18-JUL-19 channel ORA_DISK_1: finished piece 1 at 18-JUL-19 piece handle=/u01/app/oracle/fra/ORCL/backupset/2019_07_18/o1_mf_nnndf_TAG20190718T111222_glzrwp9z_.bkp tag=TAG20190718T111222 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03 Finished backup at 18-JUL-19 Starting Control File and SPFILE Autobackup at 18-JUL-19 piece handle=/u01/app/oracle/fra/ORCL/autobackup/2019_07_18/o1_mf_s_1013944345_glzrwsd5_.bkp comment=NONE Finished Control File and SPFILE Autobackup at 18-JUL-19

創(chuàng)建鏡像復(fù)制

RMAN> run { allocate channel c1 device type disk; allocate channel c2 device type disk; backup as copy (datafile '/u01/app/oracle/oradata/orcl/system01.dbf' channel c1) (datafile '/u01/app/oracle/oradata/orcl/undotbs01.dbf' channel c2) }

備份所有的數(shù)據(jù)文件

RMAN> run { allocate channel c1 device type disk; allocate channel c2 device type disk; allocate channel c3 device type disk; backup as copy database; }

運行以上RMAN命令時，確保在mount狀態(tài)或open狀態(tài)，open狀態(tài)還需要啟動歸檔模式。

9.3 恢復(fù)

恢復(fù)關(guān)鍵數(shù)據(jù)文件的核心步驟：db進入mount狀態(tài)、從備份還原（restore或switch）、使用增量備份或重做日志恢復(fù)（recover）、打開db

在整個介質(zhì)恢復(fù)流程中（restore和recover），db始終處于mount狀態(tài)，而不是open狀態(tài)，在恢復(fù)完成之前db不能接受應(yīng)用的連接。

9.3.1 恢復(fù)前的準(zhǔn)備

要恢復(fù)數(shù)據(jù)文件，先要啟動到mount階段，不然就需要搞定參數(shù)文件和控制文件。

顯示啟動到mount階段：startup mount

如果發(fā)現(xiàn)問題時實例沒有關(guān)閉，用：shutdown abort停止實例

也有可能數(shù)據(jù)字典的損壞甚至SYS不能通過sqlplus和RMAN登錄的情況

$ sqlplus / as sysdba ERROR: ORA-01075：you are currently logged on

登錄不報錯，連接到空閑實例，但實例還存在

SQL> sqlplus / as sysdba SQL> select * from v$database; ERROR at line 1 : ORA-01012: not logged on Process ID: 0 Session ID: 0 Serial number :0

使用RMAN登錄也報錯

$ rman target / RMAN-00554 RMAN-04005: error from target database ORA-00604: error occurred at recursive SQL level 1 ORA-01578: ORACLE data block corrupted (file # 1,block #857) ORA-01110: data file 1: '/u01/app/oracle/oradata/orcl/system01.dbf'

此時必須終止實例才能開始恢復(fù)操作，比如將后臺進程SMON 殺死，另一個后臺進程PMON

$ kill -9 `ps aux |grep ora_smon_orcl |grep -v grep | awk '{print $2}'`

9.3.2 恢復(fù)流程

恢復(fù)操作必須在mount下進行，具體步驟：

--1 如果實例尚未崩潰，使用shutdown abort或者操作系統(tǒng)的kill將實例關(guān)閉 --2 執(zhí)行startup mount將實例啟動到mount狀態(tài) --3 使用RMAN執(zhí)行restore或switch還原損壞的關(guān)鍵數(shù)據(jù)文件 --4 使用RMAN執(zhí)行recover database 利用歸檔日志和在線日志恢復(fù)數(shù)據(jù)文件 --5 執(zhí)行alter database open 打開數(shù)據(jù)庫

第一步確保實例已經(jīng)停止，可以通過RMAN的一個運行塊完成，比如恢復(fù)undotbs1表空間的數(shù)據(jù)文件

RMAN> run { startup mount; restore tablespace undotbs1; recover database; alter database open; }

再比如恢復(fù)1號數(shù)據(jù)文件

RMAN> run { startup mount; restore datafile 1; recover database; alter database open; }

當(dāng)數(shù)據(jù)文件的鏡像復(fù)制處于磁盤上時，可用switch命令取代restore將控制文件中的數(shù)據(jù)文件名立即換成鏡像復(fù)制名，文件越大，還原操作節(jié)省的時間就越多。

首先啟動到mount狀態(tài)

RMAN> startup mount;

查看鏡像復(fù)制信息和生成時間

RMAN> list datafilecopy all; RMAN> run { switch datafile 1 to datafilecopy '/u01/app/oracle/fra/ORCL/autobackup/2019_07_18/o1_mf_s__glzrwsd5_.dbf'; recover database; alter database open; }

現(xiàn)在查看1號數(shù)據(jù)文件的路徑將是鏡像復(fù)制

SQL> select name from v$datafile where file#=1; NAME /u01/app/oracle/fra/ORCL/autobackup/2019_07_18/o1_mf_s__glzrwsd5_.dbf

而查看鏡像復(fù)制的路徑將是原來的數(shù)據(jù)文件

RMAN> list copy of tablespace system; /u01/app/oracle/oradata/orcl/system01.dbf

如果原來數(shù)據(jù)文件已經(jīng)是損壞的，此鏡像復(fù)制當(dāng)然也是損壞的，dba需要考慮這樣的復(fù)制是否有意義，所以在使用switch之后要執(zhí)行validate

RMAN> validate datafilecopy all;

如有錯誤，可以刪除

RMAN> delete noprompt datafilecopy 44; RMAN> backup as copy datafile 1 format ‘/u01/app/oracle/oradata/orcl/system01.dbf’;

將來不論是主動或被動，利用switch和recover都能再次切換回原路徑　　

轉(zhuǎn)載于:https://www.cnblogs.com/yhq1314/p/11208789.html

總結(jié)

以上是生活随笔為你收集整理的oracle-SYSTEM表空间的备份与恢复的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。