在oracle資料庫中我們可以利用oracle的內部事件調整SCN。增進SCN通常有兩種常用方法:

1.alter session set events 'IMMEDIATE trace name ADJUST_SCN level x';

--需要資料庫OPEN

2.透過10015事件

alter session set events '10015 trace name adjust_scn level x';

--在資料庫無法開啟，mount狀態下。

注:level 1為增進SCN 10億 (1 billion) (1024*1024*1024=1073741824)

測試：

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER

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

571904

SQL> alter session set events 'IMMEDIATE trace name ADJUST_SCN level 1';

Session altered

--10g的告警日誌會報這樣的錯：

Tue Mar 31 17:01:00 2009

Errors in file c:\oracle\product\10.2.0\admin\orasjh\udump\orasjh_ora_2208.trc:

ORA-01031: 許可權不足

檢視trace檔案，有這樣的報錯：

...

Clearing ORA-1031 thrown by trace 'ADJUST_SCN'

----- Dump for trace 'ADJUST_SCN': -----

*** 2009-03-31 17:01:00.828

ksedmp: internal or fatal error

ORA-01031: 許可權不足

Current SQL statement for this session:

...

我在9i測試是沒問題的。

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER

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

1073766630

在測試一下在資料庫關閉的情況下SCN的增進。

SQL> shutdown immediate;

資料庫已經關閉。

已經解除安裝資料庫。

ORACLE 例程已經關閉。

SQL>

SQL> startup mount

ORACLE 例程已經啟動。

Total System Global Area 147921840 bytes

Fixed Size 453552 bytes

Variable Size 121634816 bytes

Database Buffers 25165824 bytes

Redo Buffers 667648 bytes

資料庫裝載完畢。

SQL> alter session set events '10015 trace name adjust_scn level 10';

會話已更改。

SQL> alter database open;

資料庫已更改。

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER

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

1.0737E+10

SQL>

增進SCN的意義？

在解決ORA-00600: internal error code, arguments: [2662]錯誤的時候會用到。

這裡轉載一個案例：

參考地址：

客戶那邊資料庫突然出現一個current日誌檔案壞了，導致資料庫crash了，然後現場工程師使用_ALLOW_RESETLOGS_CORRUPTION = TRUE這個隱含引數，做了不完全恢復後強行將資料庫開啟。可是開啟資料庫後發現只能用internal使用者連線進去，別的使用者連線都報錯，錯誤資訊如下：

ORA-00600: internal error code, arguments: [2662], [0], [431267936], [0], [431273216], [0], [], []

查詢不了任何應用的表，應用也沒法使用，於是想嘗試全庫的exp出來然後重新imp進去建庫，結果發現exp資料也不成功，也是報同樣的ORA-600的錯誤，使用者當時資料沒有任何的備份過，只能想辦法儘量開啟資料庫，匯出資料了。

處理過程：

先檢查了600錯誤產生的trace檔案：

*** SESSION ID:(7.15) 2004.11.23.23.28.16.824

ksedmp: internal or fatal error

ORA-00600: internal error code, arguments: [2662], [0], [431267754], [0], [431272752], [0], [], []

Current SQL statement for this session:

SELECT * FROM "WHSB"."SB_BSBF"

得到的資訊有限，只能看到是嚴重內部錯誤，剩下的都是記憶體堆疊的一堆資訊，於是查詢了一下這個錯誤的具體相關資訊。

ORA-600 [2662] "Block SCN is ahead of Current SCN"，說明當前資料庫的資料塊的SCN早於當前的SCN，主要是和儲存在UGA變數中的dependent SCN進行比較，如果當前的SCN小於它，資料庫就會產生這個ORA-600 [2662]的錯誤了。這個錯誤一共有五個引數，分別代表不同的含義，

ORA-600 [2662] [a] [b] [c] [d] [e]

Arg [a] Current SCN WRAP

Arg [b] Current SCN BASE

Arg [c] dependent SCN WRAP

Arg [d] dependent SCN BASE

Arg [e] Where present this is the DBA where the dependent SCN came from.

我們分析錯誤中的提示，它的引數b=431267754,d=431272752,表明當前的SCN確實是小於dependent SCN，所以產生了這個600的錯誤。透過查閱文件，發現這個錯誤的產生原因主要有以下幾條：

1.使用隱含引數_ALLOW_RESETLOGS_CORRUPTION後resetlogs開啟資料庫

2.硬體錯誤引起資料庫沒法寫控制檔案和重做日誌檔案

3.錯誤的部分恢復資料庫

4.恢復了控制檔案但是沒有使用recover database using backup controlfile進行恢復

5.資料庫crash後設定了_DISABLE_LOGGING隱含引數

6.在並行伺服器環境中DLM存在問題

仔細對比了一下，發現問題可能是由於第一條產生的，由於設定了_ALLOW_RESETLOGS_CORRUPTION這個隱含引數後，雖然強制性的開啟資料庫，但是資料庫本身存在了corruption，仍然存在嚴重的問題。於是想到使用ADJUST_SCN事件來調整當前的SCN，使其大於dependent SCN，然後保證資料庫可以全庫的匯出，然後重建資料庫匯入資料。用internal使用者登陸資料庫後，連線別的使用者，還是失敗報錯，執行：

alter session set events 'IMMEDIATE trace name ADJUST_SCN level 1';

然後嘗試連線別的使用者，連線成功。最後exp整個資料庫，重建資料庫後匯入資料，整個資料庫恢復成功！

透過這個例項，我們可以看到，儘量的不要去使用那些隱含引數，這些引數是oracle所不推薦使用的，也不是萬能的！如果使用了可能會存在一些遺留的問題，如果非要使用，建議使用後一定要exp/imp重建建立資料庫。

在ORACLE中增進SCN及案例介紹

相關文章