歸檔模式下四種完全恢複的情境

來源:互聯網
上載者:User

歸檔模式下四種完全恢複的情境

在資料的備份恢複中,基本都在使用rman來做了,但是從資料庫的內部原理來說,對於介質恢複,其實還是做兩件事,restore和recover.
 restore是一個類似物理檔案的複製,而recover則在資料庫後台根據scn做相關的資料恢複。
 在歸檔模式下,一般有下面四種情境可以做完全恢複,當然前提還是在有備份的情況下。
 我們可以不依賴rman來手工完成備份恢複的這些過程。因為手工的過程其實也不複雜。
 手工備份恢複,那麼備份就是熱備了。如果連歸檔沒開,就會報出下面的錯誤。
SQL> alter tablespace data begin backup;
 alter tablespace data begin backup
 *
 ERROR at line 1:
 ORA-01123: cannot start online backup; media recovery not enabled
啟用歸檔胡,我們可以使用動態sql來產生熱備的語句,我們過濾了temp資料表空間,因為是不需要的。
select 'alter tablespace '||tablespace_name||' begin backup;' from dba_tablespaces where logging='LOGGING'
 alter tablespace SYSTEM begin backup;
 alter tablespace SYSAUX begin backup;
 alter tablespace UNDOTBS begin backup;
 alter tablespace DATA begin backup;
 alter tablespace TESTDATA begin backup;

然後拷貝物理檔案到一個指定目錄。
 最後使用end backup來完成熱備。這個過程比較常規,也比較簡單。

 有了備份,我們來看看四種完全恢複的情境。我們都可以手工破壞。
第一種是資料open狀態,普通資料檔案損壞的情況。
 假定test使用者下的表test是儲存在資料表空間data上的。

SQL> select count(*)from test.test;

  COUNT(*)
 ----------
          0
我們手工破壞一下。
SQL> !rm /u02/ora11g/oradata/TEST/data02.dbf
然後做一個全域檢查點,這個時候原來可訪問的表就報錯了。

SQL> alTer system checkpoint;

System altered.

SQL> select count(*)from test.test;
 select count(*)from test.test
 *
 ERROR at line 1:
 ORA-00376: file 4 cannot be read at this time
 ORA-01110: data file 4: '/u02/ora11g/oradata/TEST/data02.dbf'
我們可以嘗試offline資料表空間,但是因為資料檔案丟失,所以offline失敗
SQL> alter tablespace data offline;
 alter tablespace data offline
 *
 ERROR at line 1:
 ORA-01191: file 4 is already offline - cannot do a normal offline
 ORA-01110: data file 4: '/u02/ora11g/oradata/TEST/data02.dbf'
需要使用offline immediate,不會去寫入檢查點。
SQL> alter tablespace data offline immediate;

Tablespace altered.

這個時候我們可以從熱備份中找到對應的檔案走還原。
SQL>  !cp /u02/ora11g/oradata/hot_bak/data02.dbf /u02/ora11g/oradata/TEST

然後就是恢複。
SQL> recover tablespace data;
 Media recovery complete.
恢複完成之後把資料表空間置為online
 SQL> alter tablespace data online;

Tablespace altered.

這個時候表又可以訪問了。
SQL> select count(*)from test.test;

  COUNT(*)
 ----------
          0

第二種情境時在資料庫關閉的狀態下,系統檔案,undo資料表空間之類的檔案損壞。
 我們刪除幾個系統資料檔案。
[ora11g@oel1 TEST]$ rm system01.dbf
 [ora11g@oel1 TEST]$ rm sysaux01.dbf
 [ora11g@oel1 TEST]$ rm undotbs01.dbf
然後啟庫的時候肯定會報錯。
SQL> startup
 Oracle instance started.

Total System Global Area  209235968 bytes
 Fixed Size                  1335528 bytes
 Variable Size            125832984 bytes
 Database Buffers          75497472 bytes
 Redo Buffers                6569984 bytes
 Database mounted.
 ORA-01157: cannot identify/lock data file 1 - see DBWR trace file
 ORA-01110: data file 1: '/u02/ora11g/oradata/TEST/system01.dbf'

 這個時候問題也很明顯,簡單檢查一下就會發現系統資料檔案不存在。
 這個時候直接從熱備處拷貝系統檔案
SQL> !cp /u02/ora11g/oradata/hot_bak/system01.dbf /u02/ora11g/oradata/TEST
然後直接恢複資料檔案即可。
SQL> recover datafile 1;
 Media recovery complete.
完成之後可以嘗試啟庫,會發現另外幾個資料檔案丟失,方法也是類似的,還原,恢複。

SQL> !cp /u02/ora11g/oradata/hot_bak/sysaux01.dbf  /u02/ora11g/oradata/TEST

SQL> !cp /u02/ora11g/oradata/hot_bak/undo* /u02/ora11g/oradata/TEST

SQL> recover datafile 2;
 Media recovery complete.
 SQL> recover datafile 3;
 Media recovery complete.

SQL> alter database open;

Database altered.

第三種情境是在停庫的時候,刪除了普通資料檔案。這個時候操作還是存在一定的差別。
 我們還是手工破壞
[ora11g@oel1 TEST]$ rm data02.dbf
然後啟庫的時候肯定會報錯。

SQL> startup
 ORACLE instance started.

Total System Global Area  209235968 bytes
 Fixed Size                  1335528 bytes
 Variable Size            125832984 bytes
 Database Buffers          75497472 bytes
 Redo Buffers                6569984 bytes
 Database mounted.
 ORA-01157: cannot identify/lock data file 4 - see DBWR trace file
 ORA-01110: data file 4: '/u02/ora11g/oradata/TEST/data02.dbf'

 我們簡單檢查一下就會發現對應的資料表空間是DATA

SQL> select name from v$tablespace where ts# in (select ts# from v$datafile where file#=4);

NAME
 ------------------------------
 DATA
這個時候因為資料庫在mount階段,還做不了offline的操作,直接可以還原資料檔案,做資料恢複。
SQL> !cp /u02/ora11g/oradata/hot_bak/data02.dbf /u02/ora11g/oradata/TEST
 SQL> recover tablespace data;
 Media recovery complete.

SQL> alter database open;

Database altered.

第四種情境是資料庫open階段,新增的資料檔案損壞
 這個時候我們可以簡單類比一下,建立1個資料檔案。

SQL> create tablespace testdat datafile '/u02/ora11g/oradata/TEST/testdata.dbf' size 5M;

Tablespace created.
 SQL> conn test/test
 Connected.
 SQL> create table testdat tablespace testdat as select *from all_objects;

Table created.
然後我們立馬刪除這個資料檔案,這個時候資料檔案不在備份組中,是無法做還原的。
SQL> !rm /u02/ora11g/oradata/TEST/testdata.dbf

我們重新整理buffer cache,然後這個表就瞬間不能訪問了。
SQL> conn / as sysdba
 Connected.
 SQL> alter system flush buffer_cache;

System altered.

SQL> select count(*)from test.testdat
                          *
 ERROR at line 1:
 ORA-01116: error in opening database file 5
 ORA-01110: data file 5: '/u02/ora11g/oradata/TEST/testdata.dbf'
 ORA-27041: unable to open file
 Linux Error: 2: No such file or directory
 Additional information: 3
這個時候沒有備份,我們直接嘗試恢複是不行的。
SQL> recover datafile 5;
 ORA-00283: recovery session canceled due to errors
 ORA-01124: cannot recover data file 5 - file is in use or recovery
 ORA-01110: data file 5: '/u02/ora11g/oradata/TEST/testdata.dbf'
我們首先需要把對應的資料表空間給offline
 SQL> alter tablespace testdat offline immediate;

Tablespace altered.

然後嘗試建立一個空的資料檔案來恢複
SQL> alter database create datafile '/u02/ora11g/oradata/TEST/testdata.dbf';

Database altered.

恢複資料檔案
SQL> recover datafile 5;
 Media recovery complete.

 SQL> alter tablespace testdat online;

Tablespace altered.

這個時候恢複完成之後,表又可以訪問了。
SQL> select count(*)from test.testdat;

  COUNT(*)
 ----------
      5877

相關文章

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.