數據庫中ORA-600各個參數含義分析

本篇內容主要講解“數據庫中ORA-600各個參數含義分析”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“數據庫中ORA-600各個參數含義分析”吧!

一. ORA-600 概述

ORA-600 是一個非常頭疼的一個錯誤。比如：

       ORA-00600:internal error code, arguments: [4194], [43], [46], [], [], [], [], []

       這個就是undo 損壞出現故障的一個提示信息。

二. 第一個參數說明

在[ID 175982.1]文檔上的定義分成了2種：

       （1）the first parameter is a number which reflects the source componentor layer the error is connected with; or

       （2）the first parameter is a mnemonic which indicates the source modulewhere the error originated. This type of internal error is now used inpreference to an internal error number.

2.1 Internal Errors Categorised by numberrange（數字類型）

       Thefollowing table provides an indication of internal error codes used in theOracle server. Thus, if ora-600[X] is encountered, it is possible to glean somehigh level background information : the error in generated in the Y layer whichindicates that there may be a problem with Z. 

2.2 Internal Errors Categorised by mnemonic（字符串類型）

      Thefollowing table details mnemonics error stems which are possible. If you haveencountered : ora-600[kkjsrj:1] for example, you should look down the ErrorMnemonic column (errors in alphabetical order) until you find the matchingstem. In this case, kkj indicates that something unexpected has occurred in jobqueue operation. 

三. 其他參數說明

      在MOS 的文檔： [ID28929.1] 上有說明。

       ORA-600[2662] Block SCN is ahead of Current SCN [ID 28929.1]

       http://blog.csdn.net/tianlesoftware/article/details/6106130

       Oracle DB 服務器 系統時間修改問題 與 SCN 關系的深入研究

       http://blog.csdn.net/tianlesoftware/article/details/6163859

ORA-600 各個參數的格式和說明如下：

ERROR: 

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

ARGUMENTS:

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 wherethe dependent SCN came from.

注意，這里的DBA 指的是Data Block Address. 相關說明，參考我的Blog：

       Oracle rdba和 dba 說明

       http://blog.csdn.net/tianlesoftware/article/details/6529346

From kcrf.h:

       Ifthe SCN comes from the recent or current SCN then a dba of zero is saved. If itcomes from undo$ because the undo segment is not available then the undosegment number is saved, which looks like a block from file 0. If the SCN isfor a media recovery redo (i.e. block number == 0 in change vector), then thedba is for block 0 of the relevant datafile. If it is from another database fora distributed transaction then dba is DBAINF(). If it comes from a TX lock thenthe dba is really usn<<16+slot.

       在MOS 的文檔：[ID 365536.1] 里提到了SCN 與SCN WRAP，SCN BASE這兩個參數的關系。

SCN value is storedinternally as :

（1）SCN_wrap

（2）SCN_base

       Wheneverthe SCN is incremented, the BASE component is incremented first unil it reachesit maximum. Once the BASE reaches the maximum value allowed, it is initializedto zero again after incrementing the WRAP by 1.

--開始時WRAP 為0，即SCN_WRP=0.當BASE增長到最大值后，SCN_BAS變為0. 同時SCN_WRP增長到1

Using this logic, we cancalculate the timestamp of the SCN as follows:

       (SCN_WRP* 4294967296) + SCN_BAS should give us the SCN in the number format

      --SCN 的計算公式，這里我們看出SCN 是根據SCN_BAS計算出來的。和系統時間是沒有關系的。 只是方便我們來進行操作，如閃回恢復，而將SCN 和 系統時間每隔5分鐘進行一次映射。 映射完后，由SMON進程將映射關系寫入SMON_SCN_TIME表。 可以把SCN 看成是Oracle內部的時間。

To get the time/date for an SCN value in9i, use the following example:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-- (a) Get the current SCN base.

SQL>select max(scn_bas) SCN_BASE fromsmon_scn_time;

1603342197

--(b) Get the complete SCN and thetimestamp.

SQL> alter session setNLS_DATE_FORMAT='DD-MON-YY HH:MI:SS';

SQL> select time_dp TIMESTAMP,scn_wrp*4294967296+SCN_bas SCN from smon_scn_time where scn_bas='1603342197';

TIMESTAMP SCN

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

28-JUL-06 05:31:08 8252235517813

       現在來看下這5個參數之間的關系。

ARGUMENTS:

Arg [a] Current SCN WRAP

Arg [b] Current SCN BASE

Arg [c] dependent SCNWRAP

Arg [d] dependent SCN BASE 

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

       根據SCN WRAP 和 SCN BASE，我們可以計算出當前SCN 對應的timestamp。 

對與depent SCN 和 current SCN 關系，咨詢了一下dbsnake。給出的回復如下：

       當一個庫是clean shutdown的時候，Oracle一定會做full checkpoint，把所有的dirty block都寫回各自的datafile，同時把當前的SCN作為checkpoint SCN寫回到各個datafile的datafile header中。也就是說，如果一個庫是clean shutdown，那么這個庫不可能有一個數據塊的塊里的SCN（Oracle的一個數據塊里的SCN有三種，分別是塊頭的SCN，CSC和ITL中記錄的commit SCN）比剛才寫回的checkpoint SCN要大。

       當一個庫啟動時，Oracle會做一系列的校驗，其中有一個檢查就是Oracle會去檢查system表空間下的某些塊，如果Oracle發現這些塊里的SCN要比這個庫當前的current SCN（實際上，啟庫時的current SCN就來源于shutdown時記錄在datafileheader中的checkpoint SCN）要大的時候，就表明這個庫是有問題了，

       此時Oracle就會報跟SCN相關的一系列錯誤，ORA-600[2662]只是其中的一種。對于ORA-600[2662]這種情況，dependent SCN實際上就是Oracle發現有問題的system表空間下的某些塊里的SCN，這個SCN可能是這個塊里ITL中記錄的commit SCN，也有可能是CSC (cleanout SCN)。

       根據dbsnake 的說明，這個dependent SCN 是某個數據塊里的SCN. 正常情況下，這個SCN 是要小于current SCN的，當dependent SCN 大于current SCN 就會報相關的錯誤。instance failure 和physical corruption 都可能會造成這個問題。

到此，相信大家對“數據庫中ORA-600各個參數含義分析”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！