碼上快樂

相關內容    簡體    繁體

ORA-00600[2662]問題 匯總

本文轉載自   查看原文   2019-07-24 17:05   403    Oracle 8-0 備份恢復

一、ORA-00600[2662]問題模擬及解決方法

這是2013年的一篇文章，也不知道數據庫是什么版本，
我的數據庫時11.2.0.4，使用下面方法模擬的時候，模擬不出來。。。。

 
參照eygle的相關技術blog，測試下_disable_logging將對 數據庫產生的影響，由於是隱含參數，所以我們通過如下方法獲取對這個參數的描述：
SQL> select ksppinm,ksppdesc from x$ksppi where ksppinm like '%logging';
 
KSPPINM              KSPPDESC
------------------------------------
_disable_logging     Disable logging
 
將其改為ture，也就是啟用了不記錄日志的方式：
SQL> alter system set "_disable_logging"=true scope=both;
 
System altered.
 
創建一個，並模擬事務運行，生成大量的redo,
SQL> create table mm tablespace marvener as select * from dba_objects;
 
Table created.
 
SQL> insert into mm  select * from dba_objects;
 
45167 rows created.
 
SQL> /
 
45167 rows created.
這個時候突然掉電了，也就是shutdown abort關閉數據庫：
SQL> shutdown abort
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
 
Total System Global Area 1610612736 bytes
Fixed Size                  2084296 bytes
Variable Size             385876536 bytes
Database Buffers         1207959552 bytes
Redo Buffers               14692352 bytes
Database mounted.
ORA-00354: corrupt redo log block header
ORA-00353: log corruption near block 81435 change 856029 time 01/30/2012
15:50:39
ORA-00312: online log 1 thread 1: '/u01/app/oracle/oradata/marven/redo01.log'
 
如上。可以發現數據庫無法正常打開，並提示重做日志塊頭損壞，在告警中可見大量的如下告警信息：
試圖通過Resetlogs方式打開數據庫：
alter system set "_allow_resetlogs_corruption"=true scope=spfile;
shutdown abort
startup
數據庫仍然會顯然如下告警，並強制關閉實例：
 
SMON: enabling cache recovery
Mon Jan 30 16:15:41 2012
Errors in file /u01/app/oracle/admin/marven/udump/marven_ora_2900.trc:
ORA-00600: internal error code, arguments: [2662], [0], [855728], [0], [855937], [8388649], [], []
Mon Jan 30 16:15:42 2012
Errors in file /u01/app/oracle/admin/marven/udump/marven_ora_2900.trc:
ORA-00600: internal error code, arguments: [2662], [0], [855728], [0], [855937], [8388649], [], []
Mon Jan 30 16:15:42 2012
Error 600 happened during db open, shutting down database
USER: terminating instance due to error 600
Instance terminated by USER, pid = 2900
ORA-1092 signalled during: alter database open resetlogs...
Mon Jan 30 16:16:34 2012
 
此時我們可以通過 Oracle的內部事件來調整SCN:
 
增進SCN有兩種常用方法:
1.通過immediate trace name方式(在數據庫Open狀態下)
alter session set events 'IMMEDIATE trace name ADJUST_SCN level x';
2.通過10015事件(在數據庫無法打開，mount狀態下)
alter session set events '10015 trace name adjust_scn level x';
注:level 1為增進SCN 10億(1 billion) (1024*1024*1024),通常Level 1已經足夠。也可以根據實際情況適當調整。
本次由於數據庫並未打開，而處於mount狀態，所以只能通過第二種方式：
 
alter session set events '10015 trace name adjust_scn level 10';
 
SQL> alter database open;
 
Database altered.

摘自 marvelyu's notes

 

二、解決方法一  10015 trace name adjust_scn level

此方法對11.2.0.4已經不適用

一、錯誤現象（alert日志中）
Errors in file /opt/oracle/admin/conner/udump/conner_ora_31607.trc:
ORA-00600: internal error code, arguments: [2662], [0], [897694446], [0], [897695488], [8388697], [], []

二、錯誤解釋
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.
注：897694446<897695488

三、錯誤原因
1.使用隱含參數_ALLOW_RESETLOGS_CORRUPTION后resetlogs打開數據庫
2.硬件錯誤引起數據庫沒法寫控制文件和重做日志文件
3.錯誤的部分恢復數據庫
4.恢復了控制文件但是沒有使用recover database using backup controlfile進行恢復
5.數據庫crash后設置了_DISABLE_LOGGING隱含參數
6.在並行服務器環境中DLM存在問題

四、解決辦法
1、如果SCN相差不多，可以通過多次重起數據庫解決（每次加1）

2、通過10015 ADJUST_SCN事件來增進current SCN
1）計算level
1.1) Arg {c}* 4得出一個數值，假設為V_Wrap
1.2) 如果Arg [d]=0，則V_Wrap值為需要的level
Arg [d] < 1073741824，V_Wrap+1為需要的level
Arg [d] < 2147483648，V_Wrap+2為需要的level
Arg [d] < 3221225472，V_Wrap+3為需要的level
1.3）SCN被增進了1024*1024*1024*level（level*10 billion）

2）執行內部事件
alter session set events ’10015 trace name adjust_scn level N’;
注：mount狀態下執行（open下無效）
alert日志中會出現：
Sat Aug 20 15:41:07 2011
Debugging event used to advance scn to 107374182400

 

三、解決方法二使用bbed解決ORA-00600[2662]

此方法也是轉載，但是內容很不詳細，不予置評

一、數據庫啟動報ORA-00600[2662]

[oracle@node1 ora11g]$ sqlplus / as sysdba
 
SQL*Plus: Release 11.2.0.3.0 Production on Thu Dec 22 14:37:00 2011
 
Copyright (c) 1982, 2011, Oracle.  All rights reserved.
 
Connected to an idle instance.
 
SQL> startup
ORACLE instance started.
 
Total System Global Area 2137886720 bytes
Fixed Size                  2230072 bytes
Variable Size            1493174472 bytes
Database Buffers          637534208 bytes
Redo Buffers                4947968 bytes
Database mounted.
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [2662], [2], [2147510731], [2],
[2164287937], [4194432], [], [], [], [], [], []
Process ID: 16829
Session ID: 96 Serial number: 3

二.alert日志錯誤顯示

Thu Dec 22 14:37:09 2011
ALTER DATABASE OPEN
LGWR: STARTING ARCH PROCESSES
Thu Dec 22 14:37:09 2011
ARC0 started with pid=20, OS id =16831
ARC0: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Thu Dec 22 14:37:10 2011
ARC1 started with pid=21, OS id =16833
Thu Dec 22 14:37:10 2011
ARC2 started with pid=22, OS id =16835
Thu Dec 22 14:37:10 2011
ARC3 started with pid=23, OS id =16837
ARC1: Archival started
ARC2: Archival started
ARC2: Becoming the 'no FAL' ARCH
ARC2: Becoming the 'no SRL' ARCH
ARC1: Becoming the heartbeat ARCH
Thread 1 opened at log sequence 17
   Current log # 2 seq# 17 mem# 0: /opt/oracle/oradata/ora11g/redo02.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
SMON: enabling cache recovery
Errors in file /opt/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_ora_16829 .trc  (incident=36156):
ORA-00600: internal error code, arguments: [2662], [2], [2147510731], [2], [2164287937], [4194432], [], [], [], [], [], []
Incident details in : /opt/oracle/diag/rdbms/ora11g/ora11g/incident/incdir_36156/ora11g_ora_16829_i36156 .trc
ARC3: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Errors in file /opt/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_ora_16829 .trc  (incident=36157):
ORA-00600: internal error code, arguments: [2662], [2], [2147510731], [2], [2164287937], [4194432], [], [], [], [], [], []
Incident details in : /opt/oracle/diag/rdbms/ora11g/ora11g/incident/incdir_36157/ora11g_ora_16829_i36157 .trc
Dumping diagnostic data in directory=[cdmp_20111222143713], requested by (instance=1, osid=16829), summary=[incident=36156].
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Undo initialization errored: err:600 serial:0 start:176607884 end:176611234 diff :3350 (33 seconds)
Errors in file /opt/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_ora_16829 .trc:
ORA-00600: internal error code, arguments: [2662], [2], [2147510731], [2], [2164287937], [4194432], [], [], [], [], [], []
Errors in file /opt/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_ora_16829 .trc:
ORA-00600: internal error code, arguments: [2662], [2], [2147510731], [2], [2164287937], [4194432], [], [], [], [], [], []
Error 600 happened during db open , shutting down database
USER (ospid: 16829): terminating the instance due to error 600
Instance terminated by USER, pid = 16829
ORA-1092 signalled during: ALTER DATABASE OPEN...
opiodr aborting process unknown ospid (16829) as a result of ORA-1092
Thu Dec 22 14:37:15 2011
ORA-1092 : opitsk aborting process

三.分析日志
ORA-00600[2662]主要參數說明見:ORA-00600 [2662]
這里補充說明:e表示出現異常問題的數據塊的DBA,這里的4194432就是一個數據塊的DBA

--通過DBA地址查詢數據塊和文件號
SQL> select dbms_utility.data_block_address_block(4194432) "blick" ,
   2    dbms_utility.data_block_address_file(4194432) "file" from dual;
 
      blick       file
---------- ----------
        128          1
 
--當前數據庫SCN
SQL> select to_char(2147510731, 'xxxxxxxxxxx' ) from dual;
 
TO_CHAR(2147
------------
     800069cb
 
--當前數據塊SCN
SQL> select to_char(2164287937, 'xxxxxxxxxxx' ) from dual;
 
TO_CHAR(2164
------------
     810069c1

四.bbed查看相關SCN

[oracle@node1 ora11g]$ bbed
Password:
BBED-00113: Invalid password. Please rerun utility with the correct password.
 
[oracle@node1 ora11g]$ bbed
Password:
 
BBED: Release 2.0.0.0.0 - Limited Production on Thu Dec 22 14:49:24 2011
 
Copyright (c) 1982, 2011, Oracle and /or its affiliates.  All rights reserved.
 
************* !!! For Oracle Internal Use only !!! ***************
 
BBED> set filename "/opt/oracle/oradata/ora11g/system01.dbf"
         FILENAME        /opt/oracle/oradata/ora11g/system01 .dbf
 
BBED> set block 1
         BLOCK #          1
 
BBED> p kcvfhckp
struct kcvfhckp, 36 bytes                   @484    
    struct kcvcpscn, 8 bytes                 @484    
       ub4 kscnbas                           @484      0x800069c8
       ub2 kscnwrp                           @488      0x0002
    ub4 kcvcptim                             @492      0x2dedee96
    ub2 kcvcpthr                             @496      0x0001
    union u, 12 bytes                        @500    
       struct kcvcprba, 12 bytes             @500    
          ub4 kcrbaseq                       @500      0x00000011
          ub4 kcrbabno                       @504      0x0000210f
          ub2 kcrbabof                       @508      0x0010
    ub1 kcvcpetb[0]                          @512      0x02
    ub1 kcvcpetb[1]                          @513      0x00
    ub1 kcvcpetb[2]                          @514      0x00
    ub1 kcvcpetb[3]                          @515      0x00
    ub1 kcvcpetb[4]                          @516      0x00
    ub1 kcvcpetb[5]                          @517      0x00
    ub1 kcvcpetb[6]                          @518      0x00
    ub1 kcvcpetb[7]                          @519      0x00
 
BBED> set block 128
         BLOCK #          128
 
BBED> p bas_kcbh
ub4 bas_kcbh                                @8        0x810069c1
 
BBED> p wrp_kcbh
ub2 wrp_kcbh                                @12       0x0002

這里看到的SCN(16進制)和我們在alert日志中看到的有一定的出入原因是在數據庫啟動的時候，當前SCN增加了，但是因為數據庫直接abort，沒有寫入到數據文件中。導致數據文件頭部的SCN比alert中顯示的稍微小一點(還有可能，系統當前的scn比system01.dbf的scn大一點)。通過對比數據塊和數據文件頭部的SCN也可以說明當數據塊的SCN>數據塊當前SCN導致ORA-00600[2662]

五.bbed修改數據塊的SCN

BBED> set offset 8
         OFFSET          8
 
BBED> m /x c8690080
BBED-00215: editing not allowed in BROWSE mode
 
 
BBED> set mode edit
         MODE            Edit
 
BBED> m /x c8690080
BBED-00209: invalid number (c8690080)
--分開修改，曲線救國策略
 
BBED> m /x c869
Warning: contents of previous BIFILE will be lost. Proceed? (Y /N ) y
  File: /opt/oracle/oradata/ora11g/system01 .dbf (0)
  Block: 128              Offsets:    8 to  519           Dba:0x00000000
------------------------------------------------------------------------
  c8690081 02000104 2f8f0000 00000000 00000000 00000000 00000000 06000000
  2f000000 20100000 00000000 00000000 07000000 81004000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 06000000 00000000 00000000
  00000040 81004000 07000000 88004000 08000000 10024000 08000000 18024000
  08000000 20024000 08000000 28024000 08000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 
  <32 bytes per line>
 
BBED> set offset +2
         OFFSET          10
 
BBED> m /x 0080
  File: /opt/oracle/oradata/ora11g/system01 .dbf (0)
  Block: 128              Offsets:   10 to  521           Dba:0x00000000
------------------------------------------------------------------------
  00800200 01042f8f 00000000 00000000 00000000 00000000 00000600 00002f00
  00002010 00000000 00000000 00000700 00008100 40000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000600 00000000 00000000 00000000
  00408100 40000700 00008800 40000800 00001002 40000800 00001802 40000800
  00002002 40000800 00002802 40000800 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 
  <32 bytes per line>
 
BBED> p tailchk
ub4 tailchk                                 @8188     0x69c10e01
 
BBED> set offset 8188
         OFFSET          8188
 
BBED> m /x 010ec869
  File: /opt/oracle/oradata/ora11g/system01 .dbf (0)
  Block: 128              Offsets: 8188 to 8191           Dba:0x00000000
------------------------------------------------------------------------
  010ec869
 
  <32 bytes per line>
 
BBED> p tailchk
ub4 tailchk                                 @8188     0x69c80e01
 
BBED> p bas_kcbh
ub4 bas_kcbh                                @8        0x800069c8
 
BBED> sum apply
Check value for File 0, Block 128:
current = 0x8e2f, required = 0x8e2f
 
BBED> exit

六.啟動數據庫

[oracle@node1 ora11g]$ sqlplus / as sysdba
 
SQL*Plus: Release 11.2.0.3.0 Production on Thu Dec 22 14:58:10 2011
 
Copyright (c) 1982, 2011, Oracle.  All rights reserved.
 
Connected to an idle instance.
 
SQL> startup
ORACLE instance started.
 
Total System Global Area 2137886720 bytes
Fixed Size                  2230072 bytes
Variable Size            1493174472 bytes
Database Buffers          637534208 bytes
Redo Buffers                4947968 bytes
Database mounted.
Database opened.

七.補充說明
一般遇到ORA-00600[2662]都是使用alter session set events ’10015 trace name adjust_scn level N’;方法處理，但是有時候會遇到ORA-01031錯誤，那就需要請bbed幫忙處理

OS Pid: 30268 executed alter session set events '10051 trace name adjust_scn level 2'
Thu Dec 22 12:04:07 2011
Errors in file /ora101/diag/rdbms/ora11/ora11/trace/ora11_ora_30268 .trc:
ORA-01031: insufficient privileges
Thu Dec 22 12:04:43 2011
Errors in file /ora101/diag/rdbms/ora11/ora11/trace/ora11_ora_846 .trc:
ORA-01031: insufficient privileges

此條目發表在 Oracle備份恢復, 非常規恢復 分類目錄，貼了 bbed, ORA-600 2662, ORA-600[2662] 標簽。將 固定鏈接加入收藏夾。

《使用bbed解決ORA-00600[2662]》有 1 條評論

    1. 惜 分飛 說：
      2011 年 12 月 22 日15:52

      通過dba查看file#,block總結

      --10進制dba
      select dbms_utility.data_block_address_block(4194432) "blick" ,
        dbms_utility.data_block_address_file(4194432) "file" from dual;
       
      --16進制
      set serveroutput on
      declare
          p_dba   VARCHAR2 (255) := '0x00800212' ;
          l_str   VARCHAR2 (255) DEFAULT NULL ;
      BEGIN
           l_str :=
                'datafile# is:'
             || DBMS_UTILITY.data_block_address_file (TO_NUMBER (LTRIM (p_dba, '0x' ), 'xxxxxxxx' ))
             || chr(10)|| 'datablock is:'
             || DBMS_UTILITY.data_block_address_block (TO_NUMBER (LTRIM (p_dba, '0x' ), 'xxxxxxxx' ));
          dbms_output.put_line(l_str);
      END ;

      10/16進制互轉

      --10 to 16
      select to_char(2147510731, 'xxxxxxxxxxx' ) from dual;
      --16 to 10
      select to_number( '800069c8' , 'xxxxxxxxxxx' ) from dual;

 

四、解決方法三  不同解決辦法對應的數據庫版本

數據庫版本：Oracle 11.2.0.1.0

數據庫服務器操作系統：Windows server 2008

事故原因：數據庫服務器異常斷電

影響：導致磁盤損壞，兩個控制文件全部損壞，通過DBV工具檢查發現，多個數據文件，產生多個壞塊；

數據庫備份情況：數據庫非歸檔，之前沒有任何物理或邏輯備份；

解決方案：手動創建控制文件，啟動數據庫到mount狀態，通過隱含參數_allow_resetlogs_corruption=TRUE跳過一致性檢查，強制open數據庫，expdp導出全部數據，重建數據庫；

問題：在設置隱含參數_allow_resetlogs_corruption=TRUE，嘗試resetlogs Open數據庫時，報錯ORA-00600: internal error code, arguments: [2662],[0],[82522462],[0],[82530638],[12583040],[],[],[],[],[],[]

 

報錯原因：

A data block SCN is ahead of the current SCN.(SCN不一致)

Bug 14351566  ORA-600 [kclchkblk_4] ORA-600 [2662] when doing flash back；

 

解決方案：

調整(提升)SCN；

方法一：

數據庫在open狀態下執行

alter session set events 'IMMEDIATE trace name adjust_scn level n';(不適用本次案例)

方法二：

數據庫在mount狀態下執行

alter session set events '10015 trace name adjust_scn level n';(只適用11.2.0.2g之前的版本，不適用11g版本數據庫)

方法三：

設置隱含參數_minimum_giga_scn=n，提升SCN(【11.2.0.2之前】適用此案例)

方法四：

oradebug工具，提升SCN(【支持11.2.0.2以后版本】)

 

 

 


其中MOS中查詢有關ORA-00600[2662]問題相關信息；

 

ORA-600/ORA-7445/ORA-700 Error Look-up Tool (文檔 ID 153788.1)

 

單擊此項可添加到收藏夾

https://support.oracle.com/epmos/adf/images/t.gif

ORA-600 [2662] "Block SCN is ahead of Current SCN" (文檔 ID 28929.1)

Note: For additional ORA-600 related information please read Note:146580.1

 

PURPOSE:           

  This article discusses the internal error "ORA-600 [2662]", what

  it means and possible actions. The information here is only applicable

  to the versions listed and is provided only for guidance.

 

ERROR:             

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

VERSIONS:

  versions 6.0 to 12.1

 

DESCRIPTION:

 

  A data block SCN is ahead of the current SCN.

 

  The ORA-600 [2662] occurs when an SCN is compared to the dependent SCN

  stored in a UGA variable.

 

  If the SCN is less than the dependent SCN then we signal the ORA-600 [2662]

  internal error.

 

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

 

FUNCTIONALITY:     

  File and IO buffer management for redo logs

 

IMPACT:

  INSTANCE FAILURE

  POSSIBLE PHYSICAL CORRUPTION

 

SUGGESTIONS:       

 

  There are different situations where ORA-600 [2662] can be raised.

 

  It can be raised on startup or during database operation.

 

  If not using Parallel Server, check that 2 instances have not mounted

  the same database.

 

  Check for SMON traces and have the alert.log and trace files ready

  to send to support.

 

  Check the SCN difference [argument d]-[argument b].

 

  If the SCNs in the error are very close, then try to shutdown and startup

  the instance several times.

 

  In some situations, the SCN increment during startup may permit the

  database to open. Keep track of the number of times you attempted a

  startup.

 

  If the Known Issues section below does not help in terms of identifying

  a solution, please submit the trace files and alert.log to Oracle

  Support Services for further analysis.

 

  Known Issues:

 

You can restrict the list below to issues likely to affect one of the following versions by clicking the relevant button: 
      

The list below is restricted to show only bugs believed to affect version 11.2.0.1.
Other bugs may affect this version but have not been confirmed as being relevant yet.

 

There is 1 bug listed.

NB

Prob

Bug

Fixed

Description

 

III

14351566

11.2.0.3.8, 11.2.0.3.BP21, 11.2.0.4, 12.1.0.1

ORA-600 [kclchkblk_4] ORA-600 [2662] when doing flash back

·         '*' indicates that an alert exists for that issue.

·         '+' indicates a particularly notable issue / bug.

·         See Note:1944526.1 for details of other symbols used

 

Bug 14351566 - ORA-600 [kclchkblk_4] ORA-600 [2662] when doing flash back (文檔 ID 14351566.8) 轉到底部轉到底部
修改時間: 2015-9-23 類型: PATCH
為此文檔評級 通過電子郵件發送此文檔的鏈接 在新窗口中打開文檔 可打印頁

Bug 14351566  ORA-600 [kclchkblk_4] ORA-600 [2662] when doing flash back

 This note gives a brief overview of bug 14351566. 
 The content was last updated on: 21-SEP-2015
 Click here for details of each of the sections below.

Affects:

Product (Component) Oracle Server (Rdbms)
Range of versions believed to be affected (Not specified)
Versions confirmed as being affected
Platforms affected Generic (all / most platforms affected)

Fixed:

The fix for 14351566 is first included in

Interim patches may be available for earlier versions - click here to check.

Symptoms:

Related To:

Description 

This fix prevents various ORA-600 internal errors relating to 
the database having the wrong versions of some blocks following 
a "flashback database" operation. Rediscovery Notes Look for all the following:
 - the DB Admin performs a "flashback database" on a database containing
   writable plugged-in datafiles (from transportable tablespaces), then
   some time after that, there are various ORA-600 errors, for example:
    ORA-600 [kclchkblk_4] and/or ORA-600 [2662] involving block types
    "KTFB Bitmapped File Space Header" or "PAGETABLE MANAGED LOB BLOCK"
 - "select file#,foreign_dbid from v$datafile" shows some non-zero
   foreign_dbid's (and BEFORE the "flashback database", these datafiles
   also had a non-zero value for v$datafile.unrecoverable_change#).
 - alter session set events 'immediate trace name controlf level 9'
   MAY show some non-zero Plugin scns (depends on compatibility history)

 

Please note: The above is a summary description only. Actual symptoms can vary. Matching to any symptoms here does not confirm that you are encountering this problem. For questions about this bug please consult Oracle Support.

 

References

Bug:14351566 (This link will only work for PUBLISHED bugs)
Note:245840.1 Information on the sections in this article
 

 

五、oradebug在mount狀態下推進SCN

環境：RHEL 6.5(x86-64) + Oracle 11.2.0.4
聲明：推進SCN屬於非常規恢復范疇，不建議非專業人員操作，否則后果自負。
需求：我這里演示下推進SCN 10W數量級，實際需求推進多少可以根據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 where the dependent SCN came from.
更多詳情可參考： ORA-600 [2662] "Block SCN is ahead of Current SCN" (文檔 ID 28929.1)
1.查看當前數據庫的Current SCN
2.重新啟動數據庫到mount階段
3.使用oradebug poke推進SCN
4.補充實際計算推進SCN的方法
1.查看當前數據庫的Current SCN
SYS@orcl> select current_scn||'' from v$database;
CURRENT_SCN||''
--------------------------------------------------------------------------------
4563483988
可以看到當前SCN是4563483988，我現在想推進SCN，在10w級別，也就是4563483988標紅數字修改為指定值。
2.重新啟動數據庫到mount階段
重新啟動數據庫到mount階段:
SYS@orcl> shutdown abort
ORACLE instance shut down.
SYS@orcl> startup mount
ORACLE instance started.
Total System Global Area 1235959808 bytes
Fixed Size                  2252784 bytes
Variable Size             788529168 bytes
Database Buffers          436207616 bytes
Redo Buffers                8970240 bytes
Database mounted.
3.使用oradebug poke推進SCN
我這里直接把十萬位的"4"改為"9"了，相當於推進了50w左右：
說明：實驗發現oradebug poke 推進的SCN值，既可以指定十六進制的0x11008DE74，也可以直接指定十進制的4563983988。
SYS@orcl> oradebug setmypid
Statement processed.
SYS@orcl> oradebug dumpvar sga kcsgscn_
kcslf kcsgscn_ [06001AE70, 06001AEA0) = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 6001AB50 00000000
SYS@orcl> select to_char(checkpoint_change#, 'XXXXXXXXXXXXXXXX') from v$database;
TO_CHAR(CHECKPOINT_CHANGE#,'XXXXXX
----------------------------------
        110013C41
SYS@orcl> oradebug poke 0x06001AE70 8 4563983988
BEFORE: [06001AE70, 06001AE78) = 00000000 00000000
AFTER:  [06001AE70, 06001AE78) = 1008DE74 00000001
SYS@orcl> oradebug dumpvar sga kcsgscn_
kcslf kcsgscn_ [06001AE70, 06001AEA0) = 1008DE74 00000001 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 6001AB50 00000000
SYS@orcl> alter database open;
Database altered.
SYS@orcl> select current_scn||'' from v$database;
CURRENT_SCN||''
--------------------------------------------------------------------------------
4563984271
可以看到已經成功將SCN推進到4563983988，SCN不斷增長，所以這里查到的值略大一些。
4.補充實際計算推進SCN的方法
本文在 2018-12-16 進一步補充說明：
在實際這類工作中，我們實際應該是要認真計算好需要推進SCN的值，而不應圖省事直接給一個很大的值。后者不但是技術水平不成熟的表現，而且是不負責任的行為。
 
--ORA-00600: internal error code, arguments: [2662], [2], [1424107441], [2], [1424142235], [8388617], [], []
select 2*power(2,32)+1424142235 from dual;
10014076827
--ORA-00600: internal error code, arguments: [2662], [2], [1424142249], [2], [1424142302], [8388649], [], []
select 2*power(2,32)+1424143000 from dual;
10014077592
總結公式：c * power(2,32) + d {+ 可適當加一點，但不要太大！}
c代表：Arg [c] dependent SCN WRAP
d代表：Arg [d] dependent SCN BASE
oradebug setmypid
oradebug dumpvar sga kcsgscn_
oradebug poke 0x060012658 8 10014077592
oradebug dumpvar sga kcsgscn_
alter database open;
最后要說的是，做事情還是多考慮些，在非常規恢復中也能溫柔的去推進SCN，高級DBA的價值從細節上體現。
 
 
 

 

 
 

轉載自：

http://blog.itpub.net/29785807/viewspace-2104794

https://www.2cto.com/database/201201/117895.html

https://www.linuxidc.com/Linux/2012-01/52851.htm

https://www.cnblogs.com/jyzhao/p/9242352.html


免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。



猜您在找 ORA-00600: internal error code, arguments: [16703], [1403], [20], [], [], [], [], [], [], [], [], [] ORA-00600: 內部錯誤代碼, 參數: [rwoirw: check ret val], [], [], [], [], [], [], [], [], [], [], [] BBED ORA-00600: internal error code, arguments: [16703], [1403], [20], [], [], [], [], [], [], [], [], [] 關於Oracle報 ORA-00600: 內部錯誤代碼, 參數: [kkqcscpopn_Int: 0], [], [], [], [], [], [], [], [], [], [], []解決 ORA錯誤小匯總 解決 ora-01795 的問題 jira使用問題匯總 WKWebView遇到的問題匯總 SpringBoot + JPA問題匯總 gamit問題匯總
 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM