oracle-SYSTEM表空間的備份與恢復

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

所謂關鍵數據文件：system表空間的數據文件與參數undo_tablespace指向的自動撤銷表空間的數據文件（undo_tablespace數據文件）。

它們的損壞（整體或局部）會導致SQL命令執行失敗、用戶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 關鍵數據文件損壞的后果

9.1.1 system表空間數據文件損壞

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

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

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

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

場景1：啟動數據庫是發現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：啟動數據庫發現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：數據庫運行時，system01.dbf文件中保存用戶賬號信息的數據字典SYS.USER$的數據塊損壞，使用后登錄失敗

$ 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：數據庫運行時system01.dbf文件中的數據字典SYS.TAB$數據塊損壞

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：數據字典SYS.PROCEDURE$中數據塊損壞，任何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表空間撤銷段同時損壞，執行DDL時候報錯

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

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

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

9.1.2 undo_tablespace數據文件損壞

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

--1 undotbs01.dbf文件丟失無法訪問，startup啟動到mount狀態 --2 undotbs01.dbf文件頭損壞，startup啟動到mount，運行時檢查點發起后實例崩潰 --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號數據塊）

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都可以備份數據文件

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

創建鏡像復制

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) }

備份所有的數據文件

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狀態或open狀態，open狀態還需要啟動歸檔模式。

9.3 恢復

恢復關鍵數據文件的核心步驟：db進入mount狀態、從備份還原（restore或switch）、使用增量備份或重做日志恢復（recover）、打開db

在整個介質恢復流程中（restore和recover），db始終處于mount狀態，而不是open狀態，在恢復完成之前db不能接受應用的連接。

9.3.1 恢復前的準備

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

顯示啟動到mount階段：startup mount

如果發現問題時實例沒有關閉，用：shutdown abort停止實例

也有可能數據字典的損壞甚至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'

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

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

9.3.2 恢復流程

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

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

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

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

再比如恢復1號數據文件

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

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

首先啟動到mount狀態

RMAN> startup mount;

查看鏡像復制信息和生成時間

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; }

現在查看1號數據文件的路徑將是鏡像復制

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

而查看鏡像復制的路徑將是原來的數據文件

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

如果原來數據文件已經是損壞的，此鏡像復制當然也是損壞的，dba需要考慮這樣的復制是否有意義，所以在使用switch之后要執行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都能再次切換回原路徑　　

轉載于:https://www.cnblogs.com/yhq1314/p/11208789.html

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。