Oracle恢復和介質恢復的方法是什么

這篇文章主要介紹“Oracle恢復和介質恢復的方法是什么”，在日常操作中，相信很多人在Oracle恢復和介質恢復的方法是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Oracle恢復和介質恢復的方法是什么”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

一、恢復解決方案

錯誤類型及解決方案

注意：恢復依賴于備份，當生產環境中部署完成就應該確保有一次數據庫的全庫備份，且確保歸檔Redo日志被打開。

二、SCN時間機制

SCN（System Change Number，系統改變號）是Oracle內容非常重要的時間機制，一致性、數據恢復都與SCN有著非常密切的關系。Oracle啟動時，也是通過SCN的驗證來確認數據庫是否需要執行實例恢復的。雖然RAC有多個實例，但是只有一個數據庫，SCN是對應數據庫級別的改變號，所以在不同的實例產生的SCN都必須是唯一的、有序的，這是由SCN生成器完成的工作。系統時間和SCN之間可以非常容易的相互轉換，下面是系統時間和SCN相互轉換的例子：

SQL> select timestamp_to_scn(sysdate) from dual;

TIMESTAMP_TO_SCN(SYSDATE)

-------------------------

               6980593

SQL> select scn_to_timestamp(6980593) from dual;

SCN_TO_ TIMESTAMP (6980593)

-------------------------

02-DES-13 11.12.21.000000000 PM

SQL>

以下為幾種常見的SCN：

?  檢查點SCN

查詢當前最近的檢查點SCN：

SQL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#

------------------

        3.6555E+12

SQL>

每執行一次檢查點就由CKPT進程來更新，這個SCN保存在控制文件中。檢查點的執行能夠確保檢查點執行時刻數據的完整性和一致性。實例恢復也是從上一次檢查點開始進行恢復，檢查點執行的頻率決定了Crash恢復或者實例恢復需要花費的時間。當發生日志切換或者請求的SGA空間不足等情況時就會觸發檢查點。發生檢查點，DBWn進程會將所有的臟數據寫回磁盤，從而能夠確保已提交的一致性數據被寫回磁盤。單個聯機Redo日志文件越大，發生檢查點的間隔時間可能越長，實例恢復的時間也相應地增長，日志文件的丟失也會導致更多的數據丟失。

?  最新SCN

執行以下SQL語句查看數據庫最新的SCN：

SQL> select current_scn from v$database;

CURRENT_SCN

------------

3.6555E+12

SQL>

該SCN是最新生成的全局SCN，它在不斷更新，并且只會增大不會減小。

?  數據文件SCN

執行以下SQL查看所有數據文件的SCN：

SQL> select checkpoint_change# from v$datafile;

CHECKPOINT_CHANGE#

------------------

        3.6555E+12

        3.6555E+12

        3.6555E+12

        3.6555E+12

        3.6555E+12

        3.6555E+12

6 rows selected.

SQL>

每個數據文件都有一個數據文件SCN，每執行一次檢查點便由CKPT進程來更新一次，該SCN保存在控制文件中。

?  啟動SCN

執行以下SQL語句查詢所有數據文件的啟動SCN：

SQL> select checkpoint_change# from v$datafile_header;

CHECKPOINT_CHANGE#

------------------

        3.6555E+12

        3.6555E+12

        3.6555E+12

        3.6555E+12

        3.6555E+12

        3.6555E+12

6 rows selected.

SQL>

每個數據文件都有一個啟動SCN，沒執行一次檢查點都由CKPT進程來更新一次，該SCN存儲在數據文件頭中。

?  終止SCN

執行下面SQL語句查詢所有數據文件的終止SCN：

SQL> select last_change# from v$datafile;

LAST_CHANGE#

------------

6 rows selected.

SQL>

        每個數據文件都有一個終止SCN，沒執行一次檢查點都由CKPT進程更新一次。該SCN保存在控制文件中，當數據庫打開時，由于沒有終止SCN存在，所以看到的是空，表示無窮大。

        數據庫啟動過程中，首先會檢查控制文件和數據文件的檢查點執行次數是否一致，如果不一致需要對數據文件進行介質恢復。如果一致，進一步檢查數據文件的啟動SCN和終止SCN是否相同。如果數據庫是非正常關閉，那么終止SCN肯定是空，這個時候需要執行Crash恢復或實例恢復的過程。Crash恢復或實例恢復過程需要用到聯機Redo日志和UNDO表空間執行前滾和回滾操作，如果聯機Redo日志或者UNDO表空間被損壞，那么數據庫可能無法正常打開。如果啟動SCN和終止SCN相同，那么數據庫就可以正常打開。

?  日志SCN

執行以下SQL語句查詢與日志相關的SCN：

SQL> select status,first_time,first_change#,next_time,next_change# from v$log;

STATUS               FIRST_TIME     FIRST_CHANGE# NEXT_TIME      NEXT_CHANGE#

-------------------- -------------- ------------- -------------- ------------

INACTIVE             02-12鏈13        3.6555E+12 02-12鏈13       3.6555E+12

CURRENT              02-12鏈13        3.6555E+12                  2.8147E+14

CURRENT              02-12鏈13        3.6555E+12                  2.8147E+14

INACTIVE             02-12鏈13        3.6555E+12 02-12鏈13       3.6555E+12

SQL>

    在上面查詢中，first_time表示該日志組開始的時間，first_change#表示該日志組開始的SCN。可以看到，狀態為current的日志組的first_change#值與前面討論到的檢查點的SCN值相同，說明發生日志切換的時候會觸發檢查點生成一致的檢查點SCN。Next_time表述結束日志組的時間，next_change#表示結束日志組的SCN，該SCN值等于下一個日志組的first_change#值。當前日志組的next_time為空，next_change#是一個很大的值。

三、日志線程與聯機Redo日志

Redo日志記錄了數據的所有操作，以及操作的順序。Redo日志主要包括聯機Redo日志、歸檔Redo日志和Standby Redo日志三種類型，這三種類型的日志在結構上是完全相同的，只有用途不同而已。

Redo數據只有在數據庫恢復時才能體現出它的價值。在RAC環境中，每個實例的歸檔Redo日志可以存放在本地文件系統，但是恢復的時候需要將所有節點的歸檔Redo日志放在一起，確保恢復的實例能夠訪問到所有實例的歸檔Redo日志。

每個實例都對應一個維護日志的日志線程（Redo thread），單實例只有一個線程號為1的日志線程。對于RAC來說，日志線程與實例的關系可以通過以下SQL語句查詢得到。

1）   查詢來自控制文件的線程信息：

SQL> select thread#,checkpoint_change#,last_redo_change# from gv$thread;

   THREAD# CHECKPOINT_CHANGE# LAST_REDO_CHANGE#

---------- ------------------ -----------------

         1         3.6555E+12        3.6555E+12

         2         3.6555E+12        3.6555E+12

         1         3.6555E+12        3.6555E+12

         2         3.6555E+12        3.6555E+12

SQL>

2）   查詢線程與實例之間的關系：

SQL> select thread#,instance_name from gv$instance;

   THREAD# INSTANCE_NAME

---------- ------------------------------------------------

         1 PROD1

         2 PROD2

SQL>

3）  查詢線程與日志組之間的關系：

SQL> select group#,thread# from v$log;

    GROUP#    THREAD#

---------- ----------

         1          1

         2          1

         3          2

         4          2

SQL>

四、UNDO表空間

UNDO表空間存放的是數據塊的前鏡像，是塊的多版本數據，用于數據庫恢復、一致性讀和事務回滾，對數據庫并發下讀一致性起著重要的作用。

在RAC環境中，與連接Redo日志一樣，每個實例都有自己的UNDO表空間，UNDO表空間必須放在共享存儲上，每個實例都能訪問到所有實例的UNDO表空間，以便任一活動實例都能執行所有實例的恢復操作。每個實例都有自己獨立的UNDO表空間還能減少實例間對UNDO表空間的爭用。

實例對應的Redo日志組由Redo線程來指定，實例對應的UNDO表空間是直接通過初始化參數文件中的參數指定。下面是參數文件中指定UNDO表空間對應實例的參數：

Prod01.undo_tablespace = ‘UNDOTBS1’

Prod02.undo_tablespace = ‘UNDOTBS2’

1.       UNDO參數

l   UNDO_MANAGEMENT初始化參數

UNDO_MANAGEMENT指定系統使用的UNDO空間管理模式。設置為AUTO，實例打開自動化UNDO管理模式；設置為MANUAL表示使用回滾段的手動管理模式自動UNDO管理（AUM）是從Oracle9i開始引入，以代替回滾段，也可以稱為系統管理UNDO（SMU）。自動UNDO管理自動分配和管理DML操作所需空間的UNDO表空間，代替分配很多不同大小的回滾段。

l   UNDO_RETENTION初始化參數

UNDO_RETENTION指定的是事務提交之后UNDO數據保留的時間。事務提交之后，UNDO數據不再需要用于回滾或者事務恢復，但一致性讀可能還需要用到這些UNDO數據。

l   UNDO_TABLESPACE初始化參數

每個數據庫可以有多個UNDO表空間，但是對于每個實例只有一個活動的UNDO表空間。在RAC環境中，每個實例都對應一個UNDO表空間，UNDO_TABLESPACE用于指定實例對應的UNDO表空間。UNDO表空間無法進行收縮，如果UNDO表空間過大，只有通過替換的方式縮小UNDO表空間的大小。

l   GUARANTEED UNDO RETENTION特性

默認guaranteed undo retention特性是禁用的，如果啟動這個特性意味著數據庫不能覆蓋已提交但保留時間為超過undo_retention指定時間的UNDO數據。啟用這個特性需要更大的UNDO表空間來支撐，如果UNDO表空間沒有足夠的空間會導致DML操作分配UNDO段失敗。啟用這個特性能夠緩解出現ORA-01555錯誤幾率，確保在一定的時間內能夠使用部分Flashback特性閃回數據。執行以下SQL語句啟用UNDO表空間的RETENTION特性：

SQL> alter tablespace undotbs1 retention guarantee;

2.       UNDO視圖

l   V$undostat視圖

V$undostat是v$rollstat的代替和提升，包含很多對UNDO空間的監控和統計信息。這個視圖對于了解實例對UNDO空間的使用情況非常有用，能夠通過監控估算出當前負載需要的UNDO表空間大小，能夠根據統計信息提供建議調整UNDO_RETENTION，還能夠找出長時間運行的SQL語句。在系統中，數據也使用這個視圖提供的信息調整UNDO表空間的使用。只有自動化UNDO管理模式才能使用該視圖。

l   dba_undo_extents視圖

dba_undo_extents描述了在數據中所有undo表空間包含的區間。這個視圖顯示UNDO中每個區間大小。執行以下SQL語句顯示UNDO表空間中不同區間狀態的統計信息。

l   v$transaction

l   dba_rollabck_segs視圖


Oracle實例恢復 

只有當參數值是TYPICAL或者FULL，并且塊的最后一次寫是存儲了一個校驗和時，讀取這個塊，校驗和才會被驗證。在FULL模式，Oracle用update/delete語句改變數據之前會驗證校驗和，改變被應用之后還會重新計算校驗和。

從Oracle Database 11g開始，大多數日志校驗和都是通過前臺進程產生的，同時LGWR執行其余的工作，這是為了更好地發揮CPU和緩存的效率。當這個參數設置為FULL，寫日志塊到磁盤之前，LGWR驗證通過前臺進程生成的每個日志塊的校驗和。在Oracle Database 11g之前的版本中，LGWR獨自執行日志塊校驗和。數據文件塊的校驗和是由DBWR進程負責計算和管理的。

這個參數設置為OFF時，DBWn只為SYSTEM表空間計算校驗和，不為用戶表空間計算校驗和。另外，此時數據庫也不會執行日志的校驗工作。

校驗和可以使Oracle數據庫察覺到磁盤、存儲系統或者I/O系統引起的損壞。如果設置為FULL,DB_BLOCK_CHECKSUM也會捕捉在內存中的損壞，并停止它們對磁盤的操作。設置這個參數為TYPICAL值只會引起系統額外的1%~2%的負載，設置為FULL會引起4%~5%的負載。Oracle推薦設置DB_BLOCK_CHECKSUM為TYPICAL。為了保持向后兼容性，TRUE和FALSE值被保留，TRUE等同于TYPICAL，FALSE等同于OFF。

如果DB_BLOCK_CHECKSUM不等于FALSE值，每次讀取塊，Oracle計算校驗和，都與存儲在塊頭中的校驗和進行對比。如下例子：

Corrupt block relative dba: 0x0380a58f (file 14,block 42383)

Bad check value found during buffer read

……

參數2 DB_BLOCK_CHECKING

DB_BLOCK_CHECKING參數主要是用于數據塊的邏輯一致檢查，但只是在塊內，不包括塊間的邏輯檢查。主要用于防止在內存中損壞或數據損壞。

無論該參數如何設置，對SYSTEM表空間來說，邏輯一致檢查始終處于“打開”狀態，在其他表空間該參數默認是關閉的。

DB_BLOCK_CHECKING參數的屬性

Oracle通過遍歷在塊中的數據來檢查一個塊，確保它在邏輯上手尾一致。根據系統負載和參數值，塊檢查通常一起1%~10%的負載。打開塊檢查，大量的UPDATE或者INSERT將造成更大負載，對于一個繁忙的系統，特別有大量插入或者更新操作的系統來說，性能影響是比較明顯的。如果性能負載可以被接受，應該考慮設置DB_BLOCK_CHECKING為FULL。為了保持向后的兼容性，TURE和FALSE參數值同樣可以使用，FALSE等同于OFF，TRUE等同于FULL。

如果啟用DB_BLOCK_CHECKING參數，在磁盤的塊發生邏輯損壞，下一次塊更新將作為軟損壞標記這個塊，之后讀取這個塊產生ORA-1578的錯誤。

n   塊錯位

當Oracle察覺讀取塊的內容屬于不同塊但是校驗和又是正確的時，會產生錯誤。

l   邏輯塊損壞

若塊包含一個正確的校驗和，塊頭以下的結構是損壞的（塊內容損壞），這可能引起不同的ORA-600錯誤。邏輯塊損壞的詳細損壞描述通常不會打印到告警日志。DBV將報告塊具體的邏輯錯誤。

3.        壞塊的檢測工具

以下為損壞塊的檢測工具和使用方法：

l   DBVERIRY壞塊驗證工具

DBVERIRY不能驗證聯機Redo日志、歸檔Redo日志、控制文件和RMAN備份集，只能用于數據文件的塊驗證。

n   DBV驗證傳統數據文件

下面是使用DBV工具驗證數據文件塊的例子：

$ dbv file=/testdb/test01.dbf blocksize=8192

注意：DBV工具除了用于檢測數據文件是否有壞塊外，也用于獲得壞塊的詳細信息。

n   DBV驗證裸設備數據文件

DBV要求file后面跟的必須是一個包含擴展名的文件，所以如果數據庫使用裸設備作為存儲方式，就必須使用ln命令連接裸設備一個帶擴展名的文件，然后使用DBV工具通過對鏈接文件的驗證實現對裸設備數據文件的驗證。

n   DBV驗證ASM存儲的數據文件

如果是驗證存儲在ASM中的數據文件則需要指定用戶名和密碼，如果不指定用戶名和密碼，將收到DBV-00008：USERID must bu specified for OSM files的報錯。下面是使用DBV工具驗證存儲在ASM中的數據文件的塊的例子：

$ dbv file=+DATAFILE/testdb/datafile/test.234.648839 userid=sys/oracle

l   ANALYZE命令

Analyze命令的主要目的是通過分析數據庫對象，為優化器收集數據庫對象的統計量信息，以便優化器生成準確的執行計劃。同時，它也能檢查某個表或索引是否存在損壞的情況。Analyze執行壞塊檢查，但是不會標記壞塊為corrupt，檢測結果保存在USER_DUMP_DEST目錄下的用戶trace文件中。Analyze語法：

Analyze table/index / validate structure ;

Analyze命令會驗證每個數據塊、每條記錄和索引的完整性。CASCADE關鍵字表示驗證表及其相關的所有索引。與DBVERIFY不同的是，analyze只驗證高水位線以下的數據塊，analyze不會對未使用的空間進行驗證。

SQL> analyze table fengpin.test validate structure;

l   RMAN工具

RMAN是一塊備份工具，就像一個過濾器，RMAN需要通過緩存過濾每一個塊，其中一個特點就是檢查塊是否被損壞。如果備份的數據庫中包含有壞塊，將會收到錯誤

l   EXP工具

對于包含壞塊的表執行導出操作，會收到相關的錯誤信息。對于這種情況，在非歸檔模式無法通過塊恢復修復塊的情況下，有如下兩種處理方法：

方法1：啟用10231事件

通過設置10231診斷事件可以在導出的時候讓Oracle忽略表損壞的塊，10231是Oracle的內部診斷事件，設置在全表掃描時跳過壞塊的數據塊，只導出包含正確塊的數據，之后把表刪除，再把導出的表數據導入新表，從而修復該表。

1）   啟用10231診斷事件

SQL> alter system set events=’10231 trace name context forever,level 10’;

2）   禁用10231診斷事件：

SQL> alter system set events=’10231 trace name context forever,level 0’;

方法2：使用DBMS_REPAIR包標記損壞的塊。

可以使用DBMS_REPAIR包標記損壞的數據庫對象，這樣在對損壞的對象執行全表掃描的時候會跳過損壞的塊。語法如下：

SQL> exec dbms_repair.skip_corrupt_blocks(‘’,’tablename’);

EXP壞塊檢查有一定的局限性，不會發現如下類型的壞塊：

ü   HWM（高水位線）以上的壞塊

ü   索引中存在的壞塊

ü   數據字典中存在的壞塊

l   Expdp工具

使用expdp工具不會給出壞塊的提示，只會將對象正確的數據導出。

不完全恢復的選項

不完全恢復只能針對整個數據庫而言，并不能執行數據文件和表空間的不完全恢復；另外，對于非歸檔模式的恢復來說，也不能執行不完全恢復。

1）   基于時間點的不完全恢復

RMAN> run {

shutdown immediate;

startup mount;

SQL “alter session set nls_date_format=’’YYYY-MM-DD HH24:MI:SS’’”;（兩個單引號之間沒有空格）

set until time ‘2013-12-07 17:24:00’;

restore database;

recover database;

alter database open resetlogs;}

SET UNTIL TIME時間可以使用多種表示方式，可以使用TO_DATE函數來表示時間，還可以使用SYSDATE-1方式來表示時間。

注意：不完全恢復是針對整個數據而言，如果在上面的腳本中，還原和恢復的是某個數據文件或表空間，那么腳本將忽略set until time設置，對數據文件或表空間進行完全恢復。對RESTORE命令指定until time或者until scn的意義在于這樣可以自動選擇最近的RMAN備份來恢復數據，以上的批量命令相當于為RESTORE和RECOVER都指定了until time子句，這樣比單命令模式更加簡單和合理。基于時間點的恢復不能恢復到最終備份完成時間點以前的時段。

2）   基于序列號的不完全恢復

基于序列號的不完全恢復須指定某個Redo線程的序列號，那么在這個序列號切換時間點之前的所有實例的歸檔日志都需要的，每個節點的負載不同，其他實例的序列號可能比指定的Redo線程序列號要大。

以下是在RMAN中基于日志序列號的不完全恢復的例子：

RMAN> run {

Shutdown immediate;

Startup mount;

Set until sequence 10350 thread 1;

Restore database;

Recover database;

Alter database open resetlogs;}

注意：指定線程序列號為10350，但是恢復是不包含該序列號的日志的，也就是說恢復只會恢復到thread 1 sequence 10304的日志，時間點和scn恢復同樣如此。

3）   基于SCN的不完全恢復

下面是在RMAN中基于SCN的不完全恢復的例子：

RMAN> run {

shutdown immediate;

startup mount;

set until scn 324394;

restore database;

recover database;

alter database open resetlogs;}

注意：對打開的數據庫執行的全庫備份或者0級備份，即使不完全恢復到執行全庫備份或者0級備份的備份時間點也可能需要部分Redo日志，原因在于對打開的數據庫執行RMAN備份是一個不一致的備份。

7.表空間時間點恢復

表空間時間點恢復（Tablespace Point-in-time Recovery，TSPITR）特性可以恢復一個或更多的表空間早于數據庫其他部分的某個時間點。表空間時間點恢復是表空間的不完全恢復，操作起來比較復雜。

表空間時間點恢復能在不影響數據庫其它表空間和對象的情況下，恢復一個或更多的用戶表空間到之前的某個時間點。表空間時間點恢復是對某個表空間執行基于某個時間點的恢復，是特殊的不完全恢復。RMAN TSPITR可以用于以下場景：

n   一個不正確的job或者DML語句破壞了數據庫其中一個表空間的數據，RMAN TSPITR可用于被破壞表空間的恢復。

n   DDL操作改變了表的結構之后，RMAN TSPITR可用于丟失數據的恢復。這種情況不能使用Flashback Table找回表之前的結構的數據，如表結構變化后的一個TRUNCATE表操作。

n   一個表被一個drop語句加了purge選項徹底drop。RMAN TSPITR可用于這種情況的恢復。

n   恢復drop的表空間，當沒有使用恢復目錄，RMAN能對被drop的表空間執行TSPITR。

n   從一個表的邏輯損壞中恢復。

表空間時間點恢復和Flashback有點類似，在沒有介質失敗的情況下，數據也可以使用Flashback Database找回，但是Flashback Database會導致整個數據庫被閃回到之前的某個時間點。與TSPITR不同的是，Flashback Database特性必須產生Flashback日志，使用Flashback Database閃回數據庫比使用TSPITR有更多的限制，TSPITR可以擴展到能找回可用于恢復的更早備份數據。

1）   TSPITR的工作原理

TSPITR工作原理的5個步驟：

步驟1 在輔助實例上用目標數據庫的備份集還原數據文件。

步驟2 在輔助實例上用目標數據庫的歸檔文件恢復數據文件。

步驟3 在輔助數據庫上導出相關數據。

步驟4 修改主庫的控制文件。

步驟5 將輔助數據上導出的文件導入目標數據庫。

2）   RMAN TSPITR模式

表空間時間點恢復使用的是RMAN的RECOVER tablespace命令，執行RMAN TSPITR有幾個選項，不同的選項協調各種不同的操作模式之間對特定環境的自動化操作。

a.        全自動化（默認方式）

在這種模式下，RMAN管理整個TSPITR過程。制定表空間的恢復集、輔助目的地、目標時間和允許RMAN管理所有TSPITR的其它方面。

b.        自動化

可以覆蓋一些默認RMAN TSPITR設置，但仍然使用RMAN管理輔助實例和輔助目的地。這是默認方式的變種，RMAN TSPITR提供一些固定管理的同事允許手動指定一些參數，主要包含以下兩個參數：

n   輔助集或恢復集文件的位置

n   初始化參數文件

除了在TSPITR之后的恢復集文件位置，在TSPITR期間的輔助集文件、通道設置和參數或輔助實例的其它方面等更多控制都推薦使用默認方式。全自動和自動化都是使用RMAN自動管理輔助實例。

c.        非自動化

使用這種模式是手動創建和管理輔助實例的所有方面和一部分TSPITR過程。當必須分配不同的通道或者使用用戶管理輔助實例改變參數時，使用這種模式是合適的。

3）   執行全自動化的TSPITR

下面以默認的全自動化模式在目標數據庫服務器創建輔助數據庫構建TSPITR，恢復在目標數據庫對表的一個誤操作。目標數據庫與輔助數據庫都在一臺服務器上，下表是兩個數據庫的實例名和數據庫名稱對照表：

a.        創建模擬環境

步驟1 在目標數據創建測試表空間xy_tbs:

SQL> create tablespace xy_tbs datafile ‘/u01/app/oracle/test/xy_tbs01.dbf’ size 5M;

步驟2 確保目標數據庫處在歸檔模式，使用RMAN查找出xy_tbs表空間的file_id，對它進行備份：

RMAN> report schema;

……

RMAN> backup datafile 5;

步驟3 創建測試用戶xiaoyang：

SQL> create user xiaoyang identified by xiaoyang default tablespace xy_tbs tempory tablespace temp;

SQL> grant create session,create table,unlimited tablespace to xiaoyang;

SQL> connect xiaoyang/xiaoyang;

步驟4 創建兩個測試表：x1和x2，每個表插入一條測試數據：

SQL> create table x1(D date);

SQL> create table x2(D2 date);

SQL> insert into x1 values(sysdate);

SQL> insert into x2 values(sysdate);

SQL> commit;

步驟5 查看當前時間作為表空間的恢復時間點：

SQL> alter session set nls_date_format=’YYYY-MM-DD HH24:MI:SS’;

SQL> select sysdate from dual;

步驟6 在恢復時間點之后向x2表中插入一條數據和創建一個新表x3，向x3插入一條測試數據：

SQL> insert into x2 values(sysdate);

SQL> create table x3(D3 date);

SQL> insert into x3 values(sysdate);

SQL> commit;

步驟7 手動drop掉表x1：

SQL> drop table x1 purge;

假設drop x1表是一個誤操作，現在要通過TSPITR恢復技術恢復該表。

b.        檢查表空間是否自關聯

執行以下SQL語句檢查表空間自關聯情況：

SQL> execute dbms_tts.transport_set_check(‘xy_tbs’,true,true);

SQL> select * from transport_set_violations;

如果查詢transport_set_violations視圖有值返回，說明表空間有自關聯，需要手動處理提示的問題。

c.        標識TSPITR之后將會丟失的對象

步驟1 通過時間標識TSPITR之后將會丟失的對象：

SQL> select owner,name,tablespace_name,to_char(creation_time,’YYYY-MM-DD HH24:MI:SS’) from ts_pitr_objects_to_be_dropped where tablespace_name in(‘xy_tbs’) and creation_time > to_date(‘2013-12-08 09:43:00’,’YYYY-MM-DD HH24:MI:SS’) order by tablespace_name,creation_time;

步驟2 通過SCN標識TSPITR之后將會丟失的對象：

SQL> select owner,names,tablespace_name,to_char(creation_time,’YYYY-MM-DD HH24:MI:SS’) from ts_pitr_objects_to_be_dropped where tablespace_name in(‘xy_tbs’) and creation_time > to_date(to_char(scn_to_timestamp(1638492),’YYYY-MM-DD HH24:MI:SS’),’YYYY-MM-DD HH24:MI:SS’) order by tablespace_name,creation_time;

如果以上兩個查詢有結果返回，那么在執行TSPITR之前應該先將這些對象進行邏輯備份，TSPITR完成之后，再將這些對象以替換的方式導入，以恢復產生數據丟失的對象。

d.        創建輔助數據庫參數文件

轉儲目標數據庫參數文件，將該參數文件拷貝到$ORACLE_HOME目錄，重命名為inittest2.ora，參考如下參數文件內容調整inittest2.ora實例的初始化參數文件：

*.audit_file_dest=’/u01/app/oracle/admin/test2/adump’

*.control_files=’/u01/app/oracle/oradata/test2/control01.ctl’

……

db_file_name_convert=(“/u01/app/oracle/oradata/test”,”/u01/app/oracle/oradata/test2”)

log_file_name_convert=(“/u01/app/oracle/oradata/test”,”/u01/app/oracle/oradata/test2”)

log_archive_start=false

lock_name_space=test2

修改test2實例初始化參數文件中的audit_file_dest、control_file參數，確保與原有數據庫的存儲位置不同。添加db_file_name_convert、log_file_name_convert、log_archive_start和lock_name_space參數設置。

e.        創建目錄結構

根據實例test2參數的設置創建相應的目錄結構：

$ mkdir –p /u01/app/oracle/admin/test2/adump

$ mkdir –p /u01/app/oracle/oradata/test2

f.         創建test2實例密碼文件

$ cd $ORACLE_HOME/dbs/

$ orapwd file=orapwtest2 password=oracle entries=5

g.        創建輔助數據庫實例的靜態注冊

在grid用戶下的$GRID_HOME/network/admin/listener.ora文件中修改如下配置：

$ cat listener.ora

SID_LIST_LISTENER =

  (SID_LIST =

    (SID_DESC =

      (GLOBAL_DBNAME = test2)

      (ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)

      (SID_NAME = test2)

   )

)

h.        添加Oracle Net本地服務名

在Oracle用戶下的$ORACLE_HOME/network/admin/tnsnames.ora文件中添加如下配置：

TEST2 =

  (DESCRIPTION =

(ADDRESS_LIST =

  (ADDRESS = (PROTOCOL = TCP)(HOST = rhel2)(PORT = 1521))

)

(CONNECT_DATA =

  (SERVICE_NAME = test2)

)

                       )

i.         啟動輔助數據庫到NOMOUNT狀態

$ export ORACLE_SID=test2

$ sqlplus / as sysdba

SQL> create spfile from pfile;

SQL> startup nomount

j.         執行TSPITR恢復

使用RMAN同時連接到目標數據庫和輔助數據庫，使用RECOVER TABLESPACE命令執行TSPITR操作：

$ rman target /

RMAN> connect auxiliary sys/oracle@test2

RMAN> run {

allocate auxiliary channel a1 type disk;

allocate channel c1 type disk;

recover tablespace xy_tbs until time “to_date(‘2013-12-08 09:30:00’,’YYYY-MM-DD HH24:MI:SS’)”;

release channel c1;

}

執行TSPITR需要手動分配auxiliary通道

使目標數據中xy_tbs表空間ONLINE：

SQL> alter tablespace xy_tbs online;

k.        驗證恢復結果

SQL> select * from xiaoyang.x1;

SQL> select * from xiaoyang.x2;

SQL> select * from xiaoyang.x3;

到此，關于“Oracle恢復和介質恢復的方法是什么”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！