RMAN備份與恢復之UNDO表空間丟失

一 UNDO表空間講解

      

        在上一篇文章(RMAN備份與恢復之可脫機數據文件丟失)中,我們講到可脫機數據文件丟失怎麼處理,這篇文章我們講解UNDO表空間丟失的解決辦法。

 

        UNDO表空間用於存放UNDO數據,當執行DML操作(INSERT、UPDATE、DELETE)的時候,ORACLE會將這些操作的舊數據寫入到UNDO段。UNDO數據也稱爲回滾數據,用於確保數據的一致性。作用包括:回退事、讀一致性、事務恢復、閃回查詢。9i開始,管理UNDO數據可以使用UNDO表空間,也可以使用回滾段。10g開始,ORACLE已經放棄使用回滾段。提到UNDO表空間,不得不提UNDO段。UNDO Segment分爲兩個部分,一個是UNDO Segment Head,還有一個是UNDO Segment Block(也稱爲事務槽)。UNDO Segment Head中包含了這個回滾段的事務信息,而且有一個指針指向Undo Segment Block。UNDO表空間是非常重要的,如果丟失,會出現無法對數據進行更新。平時的數據庫管理中應該注意UNDO表空間的空間是否足夠,採用自動擴展還是限制大小,undo_retention值的設定等等。

 

二 備份與恢復UNDO表空間講解

 

        備份與恢復UNDO表空間,首先要有備份。使用RMAN備份完成後,我們模擬UNDO表空間丟失。此時做更新操作仍然成功,因爲shared pool和buffer cache存放了更新的信息。如果我們刷新shared pool和buffer cache,再做連接用戶或者更新操作,會提示數據文件找不到。因爲UNDO表空間丟失,並且UNDO表空間不可脫機,所以我們不能在數據庫運行狀態下對UNDO表空間進行恢復。這就要求我們關閉數據庫進行恢復操作。如果在真實環境中進行操作,務必在業務低峯期或者測試庫進行操作。我們使用一致性關閉數據庫會失敗,只有強制關閉。此時參數文件、控制文件正常,只是數據文件不正常,所以我們能把數據庫啓動到MOUNT狀態。啓動到MOUNT狀態後,我們需要使UNDO表空間數據文件離線,注意此時的數據文件編號。然後登錄到RMAN中,還原UNDO表空間數據文件,實際上做了一個拷貝的操作,從備份文件中拷貝UNDO表空間數據文件到數據目錄,待拷貝完成後,我們需要對UNDO表空間數據文件進行恢復。恢復完成後,再使UNDO表空間數據文件在線,此時的數據庫是MOUNT狀態,我們需要打開數據庫。如果所有的操作都成功,就可以對數據進行更新。

 

三 模擬


Step 1,RMAN中備份全庫

RMAN> BACKUP DATABASE;

Starting backup at 12-DEC-13
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=00001 name=/u01/oracle/oradata/justdb/system01.dbf
input datafile file number=00002 name=/u01/oracle/oradata/justdb/sysaux01.dbf
input datafile file number=00003 name=/u01/oracle/oradata/justdb/undotbs01.dbf
input datafile file number=00004 name=/u01/oracle/oradata/justdb/users01.dbf
channel ORA_DISK_1: starting piece 1 at 12-DEC-13
channel ORA_DISK_1: finished piece 1 at 12-DEC-13
piece handle=/u01/oracle/fast_recovery_area/JUSTDB/backupset/2013_12_12/o1_mf_nnndf_TAG20131212T095816_9bl61rrn_.bkp tag=TAG20131212T095816 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:25
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
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 12-DEC-13
channel ORA_DISK_1: finished piece 1 at 12-DEC-13
piece handle=/u01/oracle/fast_recovery_area/JUSTDB/backupset/2013_12_12/o1_mf_ncsnf_TAG20131212T095816_9bl62lw2_.bkp tag=TAG20131212T095816 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 12-DEC-13


Step 2,模擬UNDO表空間丟失

SQL> CONN / AS SYSDBA
Connected.
SQL> HO mv /u01/oracle/oradata/justdb/undotbs01.dbf /opt/learn/


Step 3,SQL Plus中連接到sys用戶,刷新shared pool和buffer cache

SQL> CONN / AS SYSDBA
Connected.

SQL> CONN / AS SYSDBA
Connected.
SQL> ALTER SYSTEM FLUSH shared_pool;

System altered.

SQL> ALTER SYSTEM FLUSH buffer_cache;

System altered.


Step 4,SQL Plus連接到scoot用戶,發現報ORA-01110錯誤,數據文件不能找到

SQL> CONN SCOTT/tiger;
ERROR:
ORA-00604: error occurred at recursive SQL level 1
ORA-01116: error in opening database file 3
ORA-01110: data file 3: '/u01/oracle/oradata/justdb/undotbs01.dbf'
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3


Warning: You are no longer connected to ORACLE.


Step 5,SQL Plus一致性關閉數據庫,失敗,只有強制關閉數據庫

SQL> CONN / AS SYSDBA
CONN / AS SYSDBA
Connected.
SQL> SHUTDOWN IMMEDIATE;
ORA-01116: error in opening database file 3
ORA-01110: data file 3: '/u01/oracle/oradata/justdb/undotbs01.dbf'
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
SQL> SHUTDOWN ABORT;
ORACLE instance shut down.


Step 6,再次登錄到SQL Plus,啓動數據庫到MOUNT狀態

[oracle@orcl ~]$ sqlplus 
[uniread] Loaded history (157 lines)

SQL*Plus: Release 11.2.0.3.0 Production on Thu Dec 12 10:37:52 2013

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> STARTUP MOUNT;
ORACLE instance started.

Total System Global Area 1269366784 bytes
Fixed Size        2227984 bytes
Variable Size     754974960 bytes
Database Buffers    503316480 bytes
Redo Buffers        8847360 bytes
Database mounted.


Step 7,SQL Plus中使3號文件(UNDO表空間)離線

SQL> ALTER DATABASE DATAFILE 3 OFFLINE;

Database altered.


Step 8,使用sys用戶登錄到RMAN

[oracle@orcl ~]$ uniread rman target /
[uniread] Loaded history (96 lines)

Recovery Manager: Release 11.2.0.3.0 - Production on Thu Dec 12 10:38:26 2013

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


connected to target database: JUSTDB (DBID=57321598, not open)

RMAN> 


Step 9,RMAN中還原3號文件

RMAN> RESTORE DATAFILE 3;

Starting restore at 12-DEC-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=20 device type=DISK

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00003 to /u01/oracle/oradata/justdb/undotbs01.dbf
channel ORA_DISK_1: reading from backup piece /u01/oracle/fast_recovery_area/JUSTDB/backupset/2013_12_12/o1_mf_nnndf_TAG20131212T095816_9bl61rrn_.bkp
channel ORA_DISK_1: piece handle=/u01/oracle/fast_recovery_area/JUSTDB/backupset/2013_12_12/o1_mf_nnndf_TAG20131212T095816_9bl61rrn_.bkp tag=TAG20131212T095816
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
Finished restore at 12-DEC-13


Step 10,RMAN中恢復3號文件

RMAN> RECOVER DATAFILE 3;
RECOVER DATAFILE 3;

Starting recover at 12-DEC-13
using channel ORA_DISK_1

starting media recovery
media recovery complete, elapsed time: 00:00:00

Finished recover at 12-DEC-13


Step 11,SQL Plus中使3號數據文件在線

SQL> ALTER DATABASE DATAFILE 3 ONLINE;

Database altered.


Step 12,SQL Plus中打開數據庫

SQL> ALTER DATABASE OPEN;

Database altered.


Step 13,SQL Plus查看數據,插入數據,成功

SQL> SELECT * FROM scott.dept;

    DEPTNO DNAME    LOC
---------- -------------- -------------
  10 ACCOUNTING   NEW YORK
  20 RESEARCH   DALLAS
  30 SALES    CHICAGO
  40 OPERATIONS   BOSTON

SQL> INSERT INTO dept VALUES(89,'GZ','DBA');

1 row created.

SQL> COMMIT;

Commit complete.


四 相關文章



  我的郵箱[email protected]
  新浪微博@jutdb         
  微信公衆平臺:JustOracle(微信號:justoracle)
  數據庫技術交流羣:336882565(加羣時驗證 From CSDN XXX)
  All is well
  2014年1月16日
  By Larry Wen


katoon Sina CSDN
@Wentasy 博文僅供參考,歡迎大家來訪。如有錯誤之處,希望批評指正。原創博文如需轉載請註明出處,謝謝 :) [CSDN博客]
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章