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

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

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

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

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

在備庫中準備做這類的大查詢，結果抛出了一個錯誤。建立的外部表為jeanron.temp_tab

select t1.cash,t1.TEST_TRANSACTION_ID ,t2.trade_no,t2.cash from TEST_NEW.TEST_detail t1,jeanron.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狀态。

jeanron@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

Attempt to start background Managed Standby Recovery process (TEST)

MRP0 started with pid=23, OS id=10683

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-01122: database file 21 failed verification check

ORA-01203: wrong incarnation of this file - wrong creation SCN

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

=======================

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.

通過這個案例可以看出，對于資料檔案的操作還是需要非常謹慎，對于資料檔案的狀态監控也應該是運維監控的一個重要參考。