表空間基於時間點的恢復(TSPITR)

環境：RHEL 6.4 + Oracle 11.2.0.4

• 准備模擬環境
• 1. 驗證表空間的依賴性
• 2. 確定執行TSPITR后會丟失的對象
• 3. 自動執行TSPITR
• Reference

准備模擬環境

## 0.1 初始化表空間，用戶，表，數據 ## 初始化參考 [模擬業務最小測試用例01](http://www.cnblogs.com/jyzhao/p/4952487.html) 文章中的第1，2，3，4，5步驟初始化模擬環境。 ## 0.2 再建立一個表空間，模擬生產環境其他表空間 ## ``` -- 創建表空間 conn /as sysdba create tablespace dbs_d_test datafile size 30M autoextend off; ``` ## 0.3 數據庫確定存在有效RMAN備份 ## ``` RMAN> backup database; RMAN> list backup of database; ``` ## 0.4 誤操作截斷核心表T2 ## ``` -- 誤操作truncate核心業務表T2 conn jingyu/jingyu alter session set NLS_DATE_FORMAT="YYYY-MM-DD HH24:Mi:SS"; select sysdate from dual; truncate table t2; -- 之后創建T3表在dbs_d_test表空間 create table T3 tablespace dbs_d_test as select * from t1; ``` ## 0.5 需求 ## 恢復核心表T2（T2表數據存在DBS_D_JINGYU表空間, 索引存在DBS_I_JINGYU表空間） 采用表空間基於時間點的恢復技術，正常的話T3表（在表空間DBS_D_TEST）應該不受影響。 ``` -- 查詢現狀：當前表T2，T3數據量（表T2已被截斷，已經沒有數據；表T3在T2被截斷后創建，有數據） conn jingyu/jingyu select count(1) from t2; select count(1) from t3; ```

1. 驗證表空間的依賴性

## 1.1 查詢 TS_PITR_CHECK ## ``` conn / as sysdba set linesize 1000 col obj1_owner for a10 col obj2_owner for a10

-- 如果只恢復表空間DBS_D_JINGYU
select OBJ1_OWNER, OBJ1_NAME, TS1_NAME, OBJ2_OWNER, OBJ2_NAME, TS2_NAME
from TS_PITR_CHECK
where (ts1_name = 'DBS_D_JINGYU' and ts2_name != 'DBS_D_JINGYU') or (ts1_name != 'DBS_D_JINGYU' and ts2_name = 'DBS_D_JINGYU');

-- 如果恢復表空間DBS_D_JINGYU,DBS_I_JINGYU
select OBJ1_OWNER, OBJ1_NAME, TS1_NAME, OBJ2_OWNER, OBJ2_NAME, TS2_NAME
from TS_PITR_CHECK
where (ts1_name in ('DBS_D_JINGYU','DBS_I_JINGYU') and ts2_name not in ('DBS_D_JINGYU','DBS_I_JINGYU')) or (ts1_name not in ('DBS_D_JINGYU','DBS_I_JINGYU') and ts2_name in ('DBS_D_JINGYU','DBS_I_JINGYU'));

## 1.2 處理依賴關系 ##
可以看到，如果只恢復表空間DBS_D_JINGYU，會有T2表的索引依賴表空間DBS_I_JINGYU。
我們這里同時恢復表空間DBS_D_JINGYU,DBS_I_JINGYU，這樣就解決了依賴關系。

<h1 id="2">2. 確定執行TSPITR后會丟失的對象</h1>
## 2.1 查詢 TS_PITR_OBJECTS_TO_BE_DROPPED ##

-- 查詢執行TSPITR后會丟失的對象
select owner, name, tablespace_name, creation_time
from TS_PITR_OBJECTS_TO_BE_DROPPED
where tablespace_name in ('DBS_D_JINGYU','DBS_I_JINGYU')
and creation_time > to_date('2015-11-11 15:01:46','yyyy-mm-dd hh24:mi:ss');

## 2.2 預處理執行TSPITR后會丟失的對象 ##
我這里沒有查出結果，如果有結果，最好先expdp導出這些對象的備份，待恢復表空間后，再導入這些對象。
當然如果確定這些對象是沒有用的，可以直接忽略。

<h1 id="3">3. 自動執行TSPITR</h1>
## 3.1 RMAN自動執行TSPITR ##
恢復表空間`DBS_D_JINGYU, DBS_I_JINGYU`到`2015-11-11 15:01:46`時間點，輔助實例的臨時存放目錄為`/u01/orabak/auxiliary`

recover tablespace DBS_D_JINGYU, DBS_I_JINGYU until time '2015-11-11 15:01:46' auxiliary destination '/u01/orabak/auxiliary';

執行過程簡要輸出如下：

$ rman target / catalog vpc1/vpc1@catdb

Recovery Manager: Release 11.2.0.4.0 - Production on Wed Nov 11 15:39:27 2015

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

connected to target database: ORADB (DBID=2647366668)
connected to recovery catalog database

RMAN>
RMAN> recover tablespace DBS_D_JINGYU, DBS_I_JINGYU until time '2015-11-11 15:01:46' auxiliary destination '/u01/orabak/auxiliary';

Starting recover at 2015-11-11 15:03:29
using channel ORA_DISK_1

Creating automatic instance, with SID='nysi'

initialization parameters used for automatic instance:
db_name=ORADB
db_unique_name=nysi_tspitr_ORADB
compatible=11.2.0.4.0
db_block_size=8192
db_files=200
sga_target=1G
processes=80
db_create_file_dest=/u01/orabak/auxiliary
log_archive_dest_1='location=/u01/orabak/auxiliary'

No auxiliary parameter file used

...此省略大量輸出內容
Removing automatic instance
Automatic instance removed
auxiliary instance file /u01/orabak/auxiliary/ORADB/datafile/o1_mf_temp_jin_c45t4498_.tmp deleted
auxiliary instance file /u01/orabak/auxiliary/ORADB/datafile/o1_mf_temp_c45t4486_.tmp deleted
auxiliary instance file /u01/orabak/auxiliary/ORADB/onlinelog/o1_mf_3_c45t43b3_.log deleted
auxiliary instance file /u01/orabak/auxiliary/ORADB/onlinelog/o1_mf_2_c45t42z3_.log deleted
auxiliary instance file /u01/orabak/auxiliary/ORADB/onlinelog/o1_mf_1_c45t42gx_.log deleted
auxiliary instance file /u01/orabak/auxiliary/ORADB/datafile/o1_mf_sysaux_c45t2wr3_.dbf deleted
auxiliary instance file /u01/orabak/auxiliary/ORADB/datafile/o1_mf_undotbs1_c45t2wrf_.dbf deleted
auxiliary instance file /u01/orabak/auxiliary/ORADB/datafile/o1_mf_system_c45t2wr9_.dbf deleted
auxiliary instance file /u01/orabak/auxiliary/ORADB/controlfile/o1_mf_c45t2hn2_.ctl deleted
Finished recover at 2015-11-11 15:06:22

## 3.2 備份表空間然后使表空間聯機 ##

-- 備份表空間DBS_D_JINGYU, DBS_I_JINGYU
RMAN> backup tablespace dbs_d_jingyu, dbs_i_jingyu;
-- 表空間DBS_D_JINGYU聯機
RMAN> sql 'alter tablespace dbs_d_jingyu online';
-- 表空間DBS_I_JINGYU聯機
RMAN> sql 'alter tablespace dbs_i_jingyu online';

## 3.3 驗證結果 ##

-- 最后驗證
conn jingyu/jingyu
select count(1) from t2;
select count(1) from t3;

結果是：

SQL> conn jingyu/jingyu
SQL> select count(1) from t2;

COUNT(1)

100000

Elapsed: 00:00:00.01
SQL> select count(1) from t3;

COUNT(1)

   100

Elapsed: 00:00:00.01

至此成功執行了表空間基於時間點的恢復：T2表數據已經恢復，T3表數據未受影響。
<h1 id="4">Reference</h1>
- OCP 認證考試指南 (1Z0-053)[M]. 清華大學出版社, 2010.