8198906-Segment header corruption if extent allocation operation is-1229669.1

Bug 8198906 - Segment header corruption if extent allocation operation is interrupted (文档 ID 1229669.1)

 

修改时间:2013-5-13类型:ALERT状态:PUBLISHED优先级:3

没有任何注释注释 (0)
为此文档评级
通过电子邮件发送此文档的链接在新窗口中打开文档可打印页

In this Document

Description
Occurrence
Symptoms
Workaround
Patches
History
References

Applies to:

Oracle Server - Enterprise Edition - Version 9.2.0.1 to 11.2.0.1 [Release 9.2 to 11.2]
Information in this document applies to any platform.
***Checked for relevance on 16-Mar-2012***


Description

This alert details the problems referenced in bug descriptions Note 8198906.8 and Note 9711859.8

Segment header logical corruption can be introduced to any segment if ALLOCATE EXTENT operation aborts.

If Patch 8198906 has been installed this can be reported with error ORA-600 [ktsptrn_fix-extmap].

Occurrence

This issue is specific to segments stored in a Locally Managed Tablespace (LMT) that is using Automatic Segment Space Management; ASSM (dba_tablespaces.segment_space_management='AUTO').

LOB segments are more sensitive to be affected since extent allocation for this type of segments takes longer and are larger than usual.

The problem happens when manual ALLOCATE EXTENT is used and the user aborts the session using CTRL+C  or if ALTER TABLE .. ALLOCATE EXTENT fails due to space constraint at tablespace level; e.g., ORA-1691, ORA-1653, ORA-1654, etc. 

Example of syntax of a manual extent allocation for a table and for a LOB segment:

 

alter table (allocate extent (size ));

alter table modify lob ()
(allocate extent (size ));

Testcase script. example to reproduce this issue (please do not run it in a production environment as this will introduce the problem causing SMON to crash the instance):


grant CONNECT, RESOURCE to TC identified by DONOTUSE;
drop table TC.T purge;
create tablespace TC datafile 'TC.dbf' size 100M autoextend off;
create table TC.T (i int, c clob) tablespace TC lob (c) store as (disable storage in row);
alter table TC.T modify lob (C) (allocate extent (size 100M));

  -- ORA-1691 hit during allocation introduces problem
  -- CNTRL-C during allocation introduces problem

alter table TC.T modify lob (C) (allocate extent (size 1M));

  -- subsequent attempt to modify the table shows ORA-600 [kddummy_blkchk] since segment header is now logically corrupt.

drop table TC.T purge;
drop tablespace TC including contents and datafiles;
drop user TC;
1. If the datafile is not using AUTOEXTEND, it fails to allocate an EXTENT and introduces the logical corruption reporting error ORA-600 [kddummy_blkchk].

2. If DATAFILE is using AUTOEXTEND and it is unable to EXTEND, it fails to allocate an EXTENT and  introduces the logical corruption reporting an ORA-1691: unable to extend lob segment.  Alert log reports the additional errors described in this note.

Symptoms

User process can fail with the following exceptions reported in the database alert log file.  Example:


Errors in file /oracle_base/ORCL/udump/ORCL_ora_21491.trc:
ORA-00600: internal error code, arguments: [kddummy_blkchk], [6], [16731], [18038]

Corrupt Block Found
TSN = 6, TSNAME = LOBTABLESPACE
RFN = 6, BLK = 16731, RDBA = 25182555
BJN = 76757, BJD = 76757, BJECT = SYS_LOB0000076756C00002$$, SUBOBJECT =
SEGMENT WNER = LOBOWNER, SEGMENT TYPE = Lob Segment

Errors in file /oracle_base/ORCL/udump/ORCL_ora_21491.trc:
ORA-00600: internal error code, arguments: [kddummy_blkchk], [496], [4092941], [18009], [], [], [], []

Corrupt Block Found
TSN = 9, TSNAME = LOBTABLESPACE
RFN = 496, BLK = 4092941, RDBA = 2084467725
BJN = 76258, BJD = 76258, BJECT = SYS_LOB0000076257C00005$$, SUBOBJECT =
SEGMENT WNER = LOBOWNER, SEGMENT TYPE = Lob Segment

Example of additional errors:


Errors in file /oracle_base/ORCL/udump/ORCL_ora_17807.trc:
ORA-07445: exception encountered: core dump [kteopemredo()+1544] [SIGSEGV] [Address not mapped to object] [0xAA8B9CB20] [] []
ORA-01691: unable to extend lob segment LOBOWNER.SYS_LOB0000076756C00002$$ by 128 in tablespace LOBTABLESPACE

If the segment is dropped, SMON can produce different errors to remove the associated temporary segment.  Example:


Errors in file /oracle_base/ORCL/bdump/polmnt01_smon_737372.trc:
ORA-00600: internal error code, arguments: [5467], [2], [488], [], [], [], [], []
ORACLE Instance POLMNT01 (pid = 13) - Error 600 encountered while recovering transaction (1, 37) on object 1

-- NOTE : The object 1 is a bogus message, ignore the object# reported here

User operation can fail with the following exception if Patch 8198906 is installed:


SQL> alter table

Additional symptoms due to dba=0x00000000 in the extent map are:


ORA-600 [25012] [ts#] [0] / ORA-600 [25027] [ts#] [0]

ORA-600 [5400] / ORA-600 [5463]


Example of zero dba in extent map:

Extent Map
-----------------------------------------------------------------
0x05c188c9 length:16
0x00000000 length: 0 <<<
If db_block_checking is enabled or in 10g or higher versions the next errors prevent the zero dba in the extent map:

ORA-600 [kddummy_blkchk]  [file#] [block#] [code]
ORA-600 [kdBlkCheckError] [file#] [block#] [code]

Where code can be 18009, 18038.

The trace file prints the block after image with the zero dba but it does not get propagated to disk.  The zero dba is not the only logical corruption introduced by this issue in the segment header which remains as logically corrupt.

Workaround

DROP the affected segment.

The data from the TABLE and LOB should be still accessible using EXPDP/IMPDP, CTAS , index access (in case of a table), etc ...

If the error is still produced by SMON while cleaning the temporary segment, use the next procedures from DBMS_SPACE_ADMIN to clear the segment :

segment_corrupt
segment_drop_corrupt
tablespace_rebuild_bitmaps


Example :

 

select SEGMENT_NAME, HEADER_FILE, HEADER_BLOCK
  from DBA_SEGMENTS where SEGMENT_TYPE = 'TEMPORARY'
   and TABLESPACE_NAME = '&LOBTABLESPACE';

-- Using the HEADER_FILE and HEADER_BLOCK, execute :

exec DBMS_SPACE_ADMIN.SEGMENT_CORRUPT('&LOBTABLESPACE', &HEADER_FILE, &HEADER_BLOCK );
exec DBMS_SPACE_ADMIN.SEGMENT_DROP_CORRUPT('&LOBTABLESPACE', &HEADER_FILE, &HEADER_BLOCK );

exec DBMS_SPACE_ADMIN.TABLESPACE_REBUILD_BITMAPS('&LOBTABLESPACE');
exec DBMS_SPACE_ADMIN.TABLESPACE_VERIFY('&LOBTABLESPACE');

If dropping the table you receive an ora-600 with ora-600 [kdBlkCheckError]  or ORA-600 [kddummy_blkchk]  are produced by dropping the segment, disable checksum, drop the segment and re-enable the checksum by executing:

alter system set db_block_checksum=false;

Open a new session and drop ..

alter system set db_block_checksum=true;

 

Patches

Install Patch 9711859

Refer to Note 9711859.8 for versions confirmed as affected and fixed.

Note: This fix replaces the fix in Patch 8198906

Per Note 8198906.8 its fix is included in RDBMS 11.2.0.1 (Base Release) and RDBMS 10.2.0.5 (Server Patch Set),
therefore, it is mandatory to install Patch 9711859 on top of both versions.

History

15-OCT-2010 - ALERT published.

References

NOTE:8198906.8:9711859.8
NOTE:1088018.1 - Master Note for Handling Oracle Database Corruption Issues

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/17252115/viewspace-773453/,如需转载,请注明出处,否则将追究法律责任。

user_pic_default.png
请登录后发表评论 登录
全部评论
<%=items[i].createtime%>

<%=items[i].content%>

<%if(items[i].items.items.length) { %>
<%for(var j=0;j
<%=items[i].items.items[j].createtime%> 回复

<%=items[i].items.items[j].username%>   回复   <%=items[i].items.items[j].tousername%><%=items[i].items.items[j].content%>

<%}%> <%if(items[i].items.total > 5) { %>
还有<%=items[i].items.total-5%>条评论 ) data-count=1 data-flag=true>点击查看
<%}%>
<%}%> <%}%>

转载于:http://blog.itpub.net/17252115/viewspace-773453/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值