備庫查詢導致的ORA-01110錯誤及修複

備庫查詢導致的ORA-01110錯誤及修複

最近協助業務部門解決了一個技術問題，因為發現有資料問題需要對存在問題的資料做分析。當然一個痛點就是把資料給篩選出來，當我看到他們提供的語句，在備庫做了簡單的資料評估之後，探索資料量比想象的要多，大概有200萬條左右的資料，而業務部門手頭有一個excel檔案，需要和這些資料做一些比對，當然停了下篩選邏輯還蠻複雜，最開始建議他們資料量太大，使用excel還是可能出問題，但是業務部門認為應該沒有太大的問題，他們會有excel中的公式等來處理，想想也有道理，就提供給了他們一個近40M的檔案。

等到快中午的時候，業務部門找到我說，兩個excel檔案做比對，電腦完全卡住了，還是想問問我看看有沒有好的辦法，從我的角度來看，這些操作用sql語句完全可以勝任，而且資料量更大都不是問題。簡單瞭解了需求之後，和開發的同學確認了商務邏輯，就開始準備環境了，當然思路還是比較常規的，用外部表格來實現。

首先通過excel來得到需要的幾列資料，產生csv檔案或者文字檔均可。然後在目標資料庫服務端建立外部表格來讀取這些文本資料，同時和相關的表做集合運算，比如Minus,intersect之類的操作，即可得到最終的結果。

說起來容易，在實際操作中碰到了一個比較有意思的問題。

在備庫中準備做這類的大查詢，結果拋出了一個錯誤。建立的外部表格為bkjia.temp_tab
select t1.cash,t1.TEST_TRANSACTION_ID ,t2.trade_no,t2.cash from TEST_NEW.TEST_detail t1,bkjia.temp_tab t2 where req_time >= to_date('2016-03-01 00:00:00', 'yyyy-mm-dd hh24:mi:ss') and req_time < to_date('2016-04-01 00:00:00', 'yyyy-mm-dd hh24:mi:ss') and status <> '1'  and pay_way_channel_code in ('44','45','46','15','16','17','18','19','91','93','94','146','147','148','149','150','151','159')
*
ERROR at line 1:
ORA-00376: file 21 cannot be read at this time
ORA-01110: data file 21: '/U01/app/Oracle/oradata/TEST/TEST_new_index04.dbf'
看問題提示無法讀取21號檔案，根據錯誤可以基本判斷出來應該是檔案在offline狀態。
查看資料檔案的狀態，可以看到21號檔案TEST_new_index04.dbf 目前是在RECOVER狀態。

bkjia@TEST> select file_name,status,online_status from dba_data_files;
FILE_NAME                                            STATUS    ONLINE_
-------------------------------------------------------- --------- -------
/U01/app/oracle/oradata/TEST/TEST_new_data01.dbf        AVAILABLE ONLINE
/U01/app/oracle/oradata/TEST/system01.dbf                AVAILABLE SYSTEM
...
/U01/app/oracle/oradata/TEST/TEST_new_index04.dbf        AVAILABLE RECOVER
這個問題看起來比較奇怪，查看主庫中的資料檔案狀態，都已經是online，說明在過去的某一個時間出現過一個相關的小問題。
對於這類問題，一個比較快捷的解決方案就是從主庫產生備庫控制檔案，然後啟動資料庫到Mount階段即可。
但是這一次還是出了差錯，把產生的備庫控制檔案拷貝到備庫替換之後，重啟資料庫，dg broker報了下面的錯誤。
DGMGRL> show configuration;
Configuration
Name:                TEST
Enabled:            YES
Protection Mode:    MaxPerformance
Fast-Start Failover: DISABLED
Databases:
TEST  - Primary database
sTEST4 - Physical standby database
sTEST2 - Physical standby database

 Current status for "TEST":
Warning: ORA-16607: one or more databases have failed
查看alert日誌，報出了ORA-01110的錯誤。
RFS[1]: Archived Log: '/U01/app/oracle/flash_recovery_area/STEST2/archivelog/2016_04_12/o1_mf_1_8158_cjs8mqfp_.arc'
Tue Apr 12 15:24:33 2016
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE  THROUGH ALL SWITCHOVER DISCONNECT  NODELAY
Tue Apr 12 15:24:33 2016
Attempt to start background Managed Standby Recovery process (TEST)
MRP0 started with pid=23, OS id=10683
Tue Apr 12 15:24:33 2016
MRP0: Background Managed Standby Recovery process started (TEST)
Managed Standby Recovery not using Real Time Apply
MRP0: Background Media Recovery terminated with error 1110
Tue Apr 12 15:24:38 2016
Errors in file /U01/app/oracle/admin/TEST/bdump/TEST_mrp0_10683.trc:
ORA-01110: data file 21: '/U01/app/oracle/oradata/TEST/TEST_new_index04.dbf'
ORA-01122: database file 21 failed verification check
ORA-01110: data file 21: '/U01/app/oracle/oradata/TEST/TEST_new_index04.dbf'
ORA-01203: wrong incarnation of this file - wrong creation SCN
Tue Apr 12 15:24:38 2016
Errors in file /U01/app/oracle/admin/TEST/bdump/TEST_mrp0_10683.trc:
ORA-01110: data file 21: '/U01/app/oracle/oradata/TEST/TEST_new_index04.dbf'
ORA-01122: database file 21 failed verification check
ORA-01110: data file 21: '/U01/app/oracle/oradata/TEST/TEST_new_index04.dbf'
ORA-01203: wrong incarnation of this file - wrong creation SCN
Tue Apr 12 15:24:38 2016
MRP0: Background Media Recovery process shutdown (TEST)
根據錯誤可以看出應該是檔案校正的時候有問題，creation SCN校正出現了問題。
而這個時候查看dg broker中的verbose明細資訊，顯示這個備庫目前的狀態為：
Current status for "sTEST2":
Error: ORA-16766: Redo Apply unexpectedly offline
對於這個問題，要想修複SCN的部分，有一個策略就是BBED,但是線上庫，而且考慮這種風險，與其BBED修改，我更願意保險一些重建備庫。
不過重建備庫是最後的方案，我來看看有沒有其它的方案。
這個資料檔案通過查看明細資訊發現已經處於這種狀態很久了，也就意味著這部分資訊在控制檔案中已經無法保留，資料檔案的SCN還是很早之前，比如半年前的SCN情況。這個時候如果嘗試做recover肯定是不現實的，歸檔保留也不會那麼久。不過因為是備庫，所以這個問題還好辦一些，那就是從主庫還原恢複即可。
這個資料檔案大概有5G左右，目前使用率在60%，rman備庫資料檔案大概有3G左右。
所以拷貝資料檔案的備份組到備庫之後，使用catalog start with的方式進行還原。
RMAN> catalog start with '/U01/app/oracle/temp';
using target database control file instead of recovery catalog
searching for all files that match the pattern /U01/app/oracle/temp
List of Files Unknown to the Database
=====================================
File Name: /U01/app/oracle/temp/full_1804_908984436_1
Do you really want to catalog the above files (enter YES or NO)? yes
cataloging files...
cataloging done
List of Cataloged Files
=======================
File Name: /U01/app/oracle/temp/full_1804_908984436_1
RMAN> restore datafile 21;
Starting restore at 12-APR-16
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=2976 devtype=DISK

 channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00021 to /U01/app/oracle/oradata/TEST/TEST_new_index04.dbf
channel ORA_DISK_1: reading from backup piece /U01/app/oracle/temp/full_1804_908984436_1
channel ORA_DISK_1: restored backup piece 1
piece handle=/U01/app/oracle/temp/full_1804_908984436_1 tag=TAG20160412T154036
channel ORA_DISK_1: restore complete, elapsed time: 00:00:36
Finished restore at 12-APR-16

這個時候不用重啟備庫，資料檔案的SCN就自然推進到了新的值，再次查看資料檔案的狀態就變為了ONLINE.
通過這個案例可以看出，對於資料檔案的操作還是需要非常謹慎，對於資料檔案的狀態監控也應該是營運監控的一個重要參考。