just do it
分类： Oracle
2016-07-28 11:49:23
|
Thu Jul 28 00:05:31 2016 Errors in file /orahome/oracle/diag/rdbms/bims/bims/trace/bims_ora_10572.trc (incident=43337): ORA-00600: internal error code, arguments: [ktbdchk1: bad dscn], [], [], [], [], [], [], [], [], [], [], [] 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 /orahome/oracle/diag/rdbms/bims/bims/trace/bims_ora_10572.trc (incident=43338): ORA-00600: internal error code, arguments: [ktbdchk1: bad dscn], [], [], [], [], [], [], [], [], [], [], [] Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. |
|
bash-3.00$ more /orahome/oracle/diag/rdbms/bims/bims/incident/incdir_43297/bims_ora_10562_i43297.trc Dump file /orahome/oracle/diag/rdbms/bims/bims/incident/incdir_43297/bims_ora_10562_i43297.trc Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options ORACLE_HOME = /orahome/oracle/product/11.2.0 System name: SunOS Node name: bimsd Release: 5.10 Version: Generic_141444-09 Machine: sun4u Instance name: bims Redo thread mounted by this instance: 1 Oracle process number: 210 Unix process pid: 10562, image: oracle@bimsd
*** 2016-07-28 00:03:17.078 *** SESSION ID:(238.503) 2016-07-28 00:03:17.078 *** CLIENT ID:() 2016-07-28 00:03:17.078 *** SERVICE NAME:(SYS$USERS) 2016-07-28 00:03:17.078 *** MODULE NAME:(JDBC Thin Client) 2016-07-28 00:03:17.078 *** ACTION NAME:() 2016-07-28 00:03:17.078
Dump continued from file: /orahome/oracle/diag/rdbms/bims/bims/trace/bims_ora_10562.trc ORA-00600: internal error code, arguments: [ktbdchk1: bad dscn], [], [], [], [], [], [], [], [], [], [], []
========= Dump for incident 43297 (ORA 600 [ktbdchk1: bad dscn]) ======== ----- Beginning of Customized Incident Dump(s) ----- [ktbdchk] -- ktbgcl4 -- bad dscn dependent scn: 0x0c3e.99749b98 recent scn: 0x0c3e.27627d88 current scn: 0x0c3e.27627d88 ----- End of Customized Incident Dump(s) -----
*** 2016-07-28 00:03:17.181 dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0) ----- Current SQL Statement for this session (sql_id=gcqgyf2t3wmp5) ----- INSERT INTO DAILYSESSION_TABLE(DAYS,ACCTSESSIONID,LOGINNAME, BEGINTIME,ENDTIME,RASCLIENT,RECORDTYPE,NASPORT,PHONE,ACCTSTATUSTYPE, ACCTINPUTOCTETS,ACCTOUTPUTOCTETS,ACCTS ESSIONTIME, ACCTAUTHENTIC,FRAMEDIP,MAC, PUBLICIP,STARTPORT,ENDPORT) VALUES(:B19 ,:B18 ,:B17 ,:B16 ,:B15 ,:B14 , :B13 ,:B12 ,:B11 ,:B10 ,:B9 ,:B8 ,:B7 , :B6 ,:B5 ,:B4 , :B3 ,:B2 ,:B1 ) ----- PL/SQL Stack ----- ----- PL/SQL Call Stack ----- object line object handle number name 99b617228 293 procedure BILL.P_SUMFLUE_HEBCNC_EX_NAT 9a34ed2a0 1 anonymous block
----- Call Stack Trace ----- calling call entry argument values in hex location type point (? means dubious value) -------------------- -------- -------------------- ---------------------------- ksedst1()+124 CALL skdstdst() FFFFFFFF7FFDC9C0 ? 000000002 ? 10D382390 ? 000000000 ? FFFFFFFF7FFB3D30 ? 000000000 ? ksedst()+52 CALL ksedst1() 00010D800 ? 00010D800 ? 10D820000 ? 00010D828 ? 10D820F80 ? 10D828EFC ? dbkedDefDump()+1984 CALL ksedst() 000000000 ? 10D84B000 ? 00010D84B ? 10D828000 ? 00010D800 ? 00010D828 ? dbgexPhaseII()+1340 PTR_CALL dbkedDefDump() 000000004 ? 00010D84B ? 000000003 ? 000000000 ? 000000001 ? 00010D800 ? dbgexExplicitEndInc CALL dbgexPhaseII() 10DA065A0 ? ()+692 FFFFFFFF7B60EE08 ? 10DAD8840 ? 10071D100 ? 10D817088 ? 000000000 ? dbgeEndDDEInvocatio CALL dbgexExplicitEndInc 10DA065A0 ? 10D821490 ? nImpl()+724 () FFFFFFFF7FFE0E50 ? FFFFFFFF7B60EE08 ? 10DA065A0 ? 10BB8B9F8 ? ktbgcl1()+13744 CALL dbgeEndDDEInvocatio 10DA065A0 ? 10D821490 ? n() 10D8212D0 ? 10D821490 ? 10DA065A0 ? 00000001A ? ktbgtl0()+820 CALL ktbgcl1() 10D8212D0 ? 000000002 ? 000002878 ? 10BB8C000 ? 10D820000 ? 00010B800 ? kdiins0()+14236 CALL ktbgtl0() 51848A014 ? 000000000 ? 000000000 ? FFFFFFFF7FFE50C8 ? 10D825820 ? FFFFFFFF7FFE7A20 ? kdiinsp()+100 CALL kdiins0() 000000000 ? FFFFFFFF7FFE7A10 ? FFFFFFFF7FFF3CB8 ? 000000001 ? 000000000 ? 000000000 ? kauxsin()+2068 CALL kdiinsp() 95A3ADEEC ? 2000000000000 ? 000000000 ? FFFFFFFF7FFF3CB8 ? 0000000FF ? 0000000FF ? |
Searching for the issue on Metalink pointed to the below Document:-
ALERT Description and fix for Bug 8895202: ORA-1555 / ORA-600 [ktbdchk1: bad dscn] ORA-600 [2663] in Physical Standby after switchover (Doc ID 1608167.1)
As per metalink
In a Data Guard environment with Physical Standby (including Active Data Guard), invalid SCNs can be introduced in index blocks after a switchover.
To Resolve
The fix of Bug 8895202 is the workaround.
Although the fix of Bug 8895202 is included in patchset 11.2.0.2 and later, the fix needs to be enabled by setting parameter _ktb_debug_flags = 8.
SQL> alter system set "_ktb_debug_flags"=8 scope=both sid='*';
System altered.
SQL> exit
If you are using Oracle version less than 11.2.0.2, then rebuilding index is the option, as we did for one of the client on 11.1.0.7 version.
One thing to note is —
In rare cases blocks healed by this fix may cause queries to fail with an ORA-600 [ktbgcl1_KTUCLOMINSCN_1] as described in Note 13513004.8 / Bug 13513004.
For more detail Metalink Doc 1608167.1
This bug is alerted in Note 1608167.1; reference that article for further details.
Although this fix is included in 11.2.0.2 / 11.2.0.3 / 11.2.0.4 / 12.1.0.1.0, it has to be enabled by
setting "_ktb_debug_flags"=8.
This is the reason why this article mentions that it may affected releases where the fix is included.
For versions where this fix is not included like 11.1.0.7.0 11.2.0.1.0, install an one off patch for
bug 13513004 which contains this fix and is enabled in the same way.
Rediscovery Notes
ORA-1555 / ORA-600 [ktbdchk1: bad dscn] / ktbGetDependentScn /
Dependent scn violations as itl has higher commit scn than block scn.
This happens in a Physical Standby database after a switchover.
DBVERIFY (with fix of Bug 7517208) reports:
itl[] has higher commit scn(aaa.bbb) than block scn (xx.yy)
Page failed with check code 6056
There is NO DATA CORRUPTION in the block.
Workaround
This fix is the workaround.
For versions where this fix is not included like 11.1.0.7.0 11.2.0.1.0,
install an one off patch for bug 13513004 and enable this fix:
The fix must be enabled by setting "_ktb_debug_flags"=8 (ALL RDBMS versions where this fix is in place).
If parameter _ktb_debug_flags = 8 is proactively enabled, then no new invalid SCNs are propagated to disk;
this prevents a new invalid SCN from happening as it fixes the scn on the flight before it is written to disk.
So the parameter is a permanent workaround to prevent more new invalid SCNs on disk; the ones that are
already present on disk may be repaired.
With this fix if parameter _ktb_debug_flags = 8 the SCN is repaired when block is cleaned
out (eg: block update). While blocks are not touched dbverify still reports 6056 errors
Sometimes the fix may not repair the block and the index may need rebuilding
**********************************************
IMPORTANT:
See Note:1608167.1 for the steps to enable this fix.
**********************************************
|
Thu Jul 28 03:21:44 2016 Errors in file /orahome/oracle/diag/rdbms/bims/bims/trace/bims_ora_22952.trc (incident=43376): ORA-00600: internal error code, arguments: [4521], [3134], [1503669808], [3134], [555827220], [18446744073709551615], [18446744073709551615], [], [], [], [], [] Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. Thu Jul 28 03:21:44 2016 Sweep [inc][43376]: completed
 最终解决办法： 1、重做回滚段表空间，切换 2、重建索引 ORA-1555 / ORA-600 [ktbdchk1: bad dscn] ORA-600 [2663] in Physical Standby after switch-over (文档 ID 1498717.1) In this Document
APPLIES TO:
Oracle Database - Enterprise Edition - Version
11.2.0.2 to 11.2.0.3 [Release 11.2] SYMPTOMSORA-600 on UPDATE statement
========= Dump for incident 932331 (ORA 600 [ktbdchk1: bad dscn])
======== ...
----- Call Stack Trace ----- CHANGESModify the init.ora or spfile.ora After applying the patch for bug 8895202 you must also set the parameter "_ktb_debug_flags"=8; The flag must be added manually with the 11.2.0.2 and 11.2.0.3 PSU's, although the code fix is in PSU it still must be enabled manually to use it. CAUSEBUG 8895202 - ORA-1555 / ORA-600 [ktbdchk1: bad dscn] in Physical Standby after switch-over - closed as a duplicate of - ORA-600 [kdsgrp1] ORA-1555 / ORA-600 [ktbdchk1: bad dscn] due to Invalid Commit SCN in INDEX block (Note 22241601.8) SOLUTIONIn 11.2.0.2.0 / 11.2.0.3.0 both have the fix for it is not enable by default. This is resolved by applying the patch for bug 8895202 the fix is included in 11.2.0.2 / 11.2.0.3, but it's not enabled by default. You must set the parameter "_ktb_debug_flags"=8; in the init.ora / spfile.ora to enable the fix in these versions
See the following for details on this issue: REFERENCES
In this Document
APPLIES TO:
Oracle Database - Enterprise Edition -
Version 11.1.0.6 to 12.1.0.2 [Release 11.1 to 12.1] DESCRIPTION Invalid Itl Commit SCN in INDEX blocks (object_type=INDEX) causing dependent scn violations There is NO DATA CORRUPTION in the INDEX block. OCCURRENCE
This is commonly seen in a Data Guard Physical Standby
Database configuration after a Switchover or Failover but may also occur in all
kind of databases (with no dataguard configuration). SYMPTOMS Different errors may occur related to dependent scn such as:
ORA-1555 DBVERIFY reports the next error when the fix of is present; reference Note 7517208.8 for interim patches:
itl[
WORKAROUND Install to prevent this issue from being introduced. After installing Oracle tries to repair existent invalid ITL commit scn (healing). There is not need to set any parameter for it. _ktb_debug_flags=8 is now set by default thus the healing is enabled by default when is installed. For already existent invalid SCNs on disk, the SCN is repaired when the Index block is cleaned out (example: in a block update). While blocks are not touched, dbverify still reports the 6056 errors. Blocks are repaired when they are cleaned out. Trace file shows a message like:
Healing Corrupt
DLC ITL objd:%d objn:%d tsn:%d rdba: The above "Healing Corrupt.." tracing can be avoided by installing the fix of Bug 22756771 and adding the value 256 to the parameter _ktb_debug_flags; then _ktb_debug_flags=264 (8+256) will try to heal already affected blocks without adding tracing. Sometimes the fix may not repair the block for an already existent invalid SCN on disk; then repair this issue with:
1. Recreate
the affected Index in the Primary Database. Use Note 819533.1 to identify the INDEX reported by DBVerify. Additional Notes / Summary
PATCHES Install How to install the patch in a Dataguard configuration? In a Dataguard environment the patch must be applied to both primary and standby databases. Because the fix cannot be made as DG rolling patch installable, the procedure to install an one off patch in Dataguard is:
HISTORY 11-APR-2014 - Converted this note to an alert document 17-SEP-2014 - Clarified more that proactively setting "_ktb_debug_flags" prevents this issue from happening. 01-DEC-2014 - Typo corrected 28-APR-2015 - Included RDBMS version 12.1.0.2 in the list of Products as also affected 02-JUN-2015 - For versions where the fix of is not included like 11.1.0.7.0 and 11.2.0.1.0, install an one off patch for which also contains this fix and is enabled in the same way. 22-JUN-2015 - Added workaround of "_smu_debug_mode" for ORA-600 [ktbgcl1_KTUCLOMINSCN_1] 08-OCT-2015 - Included specific versions instead of referencing 11.2.0.2 or later, clarified what versions are exposed to ORA-600 [ktbgcl1_KTUCLOMINSCN_1] and added section "Instructions for each version" 09-OCT-2015 - In Patches section: changed by 19-FEB-2016 - Removed the reference of "_smu_debug_mode" for ORA-600 [ktbgcl1_KTUCLOMINSCN_1] as it may cause other errors. The recommendation in versions affected by Bug 13513004 (only 11.2.0.2 and 11.2.0.3) is to install 01-APR-2016 - Added reference to bug 22756771 which add the value 256 to _ktb_debug_flags to avoid tracing; then _ktb_debug_flags=264 (8+256) will be a workaround for this issue without adding tracing. 16-APR-2016 - The true root cause of this issue has been identified in bug 22241601 which replaces bug 8895202 and bug 13513004. There is not need to set _ktb_debug_flags to enable this fix as bug 22241601 is a formal fix (not a workaround). REFERENCES
- ITL HAS HIGHER COMMIT SCN THAN BLOCK SCN
Bug 22241601 ORA-600 [kdsgrp1] ORA-1555 / ORA-600 [ktbdchk1: bad dscn] due to Invalid Commit SCN in INDEX block
This note gives a brief overview of bug
22241601. Affects:
Fixed:
DescriptionThis bug is alerted in Note 1608167.1; reference that article for further details.
This is the same issue reported in workaround fix bug 8895202 replaced by the fix of bug 13513004.
This bug 22241601 replaces the fix of bug 13513004 as the root cause is identified.
ORA-600 [kdsgrp1] / ORA-1555 / ORA-600 [ktbdchk1: bad dscn] / ORA-600 [2663]
ktbGetDependentScn Dependent scn violations can occur due to an Invalid Itl Commit SCN in INDEX blocks.
This is issue has been mostly seen in Dataguard Standby Databases after a Failover or Switchover
(either in PRIMARY or STANDBY) but may also occur in all kind of databases (with no dataguard configuration).
DBVERIFY (with fix of Bug 7517208) may report the next error: itl[
Page
There is NO DATA CORRUPTION in the INDEX block; column values in the INDEX are correct.
About this fix:
The patch for this bug prevents this issue from being introduced but
may not repair all existent cases.
To install an one off patch for a Dataguard environment:
The fix cannot be made as DG rolling patch installable. The procedure to
install an one off patch is:
1. Shutdown primary database (SHUTDOWN NORMAL or IMMEDIATE)
2. Make sure all standby databases have applied redo generated by the primary
3. Shutdown the standby database
4. Apply the patch on standby databases and bring to either the mount or open read only state
5. Restart managed recover on the standby database
6. Apply the fix on primary and open the primary in read / write mode.
Workaround
Install the fix to prevent this issue from being introduced; installing the fix
also by default tries to repair existent invalid ITL commit scn (healing).
There is not need to set any parameter for it.
Databases already having init.ora parameter _ktb_debug_flags=8 can
remove the parameter after the fix is installed as _ktb_debug_flags=8 is now
the default so the healing is enabled by default. Note that this fix is not disabled
if _ktb_debug_flags is set to 0; a value not including 8 will only disable the healing
for already affected ITL SCN but the fix still solves the problem of the invalid ITL SCN
in the INDEX to be introduced as it does not depend of any parameter.
Sometimes the fix may not repair the block for an already existent invalid SCN on disk;
then repair this issue with:
1. Recreate the affected Index in the Primary Database
Create Index may also fail with the same ORA-600 [ktbdchk1: bad dscn] if Oracle
builds the index based on another index with the same corruption for which the
solution is to drop all the affected indexes for the table and recreate them.
OR
2. If the issue is in the standby database: refresh the affected file from primary to standby.
If the error is in the primary database, refresh the file from the standby to the primary database.
Further details on this issue can be found in Note 1608167.1
References
(This link will only work for PUBLISHED bugs)
|
