Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
发新帖

133

积分

0

好友

17

主题
1#
发表于 2012-6-14 15:03:01 | 查看: 8034| 回复: 6
  1. 没有找到可以匹配的bug环境:
  2. Release 10.2.0.4.0

  3. [oracle@dbserver4 ~]$ uname -a
  4. Linux dbserver4 2.6.9-89.ELsmp #1 SMP Mon Apr 20 10:33:05 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
  5. [oracle@dbserver4 ~]$
  6. [oracle@dbserver4 ~]$ cat /etc/redhat-release
  7. Red Hat Enterprise Linux AS release 4 (Nahant Update 8)

  8. alter 日志显示:

  9. Thu Jun 14 11:43:30 2012
  10. ORA-01555 caused by SQL statement below (SQL ID: 5r2qj3gnucfxn, Query Duration=1339645410 sec, SCN: 0x0006.55793d11):
  11. Thu Jun 14 11:43:30 2012
  12. create index LOG_RECORD_DETAIL_4_IX2 on LOG_RECORD_DETAIL_4 (USER_ID) local online
  13. tablespace ESTAGING_INDEX01
  14. Thu Jun 14 11:43:31 2012
  15. Errors in file /u01/app/oracle/admin/BI/udump/bi_ora_5926.trc:
  16. ORA-00600: internal error code, arguments: [13004], [], [], [], [], [], [], []
  17. Thu Jun 14 11:44:07 2012
  18. LGWR: Standby redo logfile selected to archive thread 1 sequence 41388
  19. LGWR: Standby redo logfile selected for thread 1 sequence 41388 for destination LOG_ARCHIVE_DEST_2

  20. trace文件在附件中

  21. 在https://supporthtml.oracle.com/没有找到匹配的bug

  22. ID 729170.1
  23. 这个还像一点,但是说在10.0.2.0.4已经修复了啊
复制代码

[ 本帖最后由 saup007 于 2012-6-14 15:04 编辑 ]

bi_ora_5926.rar

1.97 MB, 下载次数: 908

2#
发表于 2012-6-14 20:29:28

回复 1# 的帖子

请问你张表是什么表,这张表还有别的索引吗?

回复 只看该作者 道具 举报

3#
发表于 2012-6-14 22:50:23
ODM DATA:

10.2.0.4.0 + Linux x86_64

ORA-00600: internal error code, arguments: [13004], [], [], [], [], [], [], []
Current SQL statement for this session:
create index LOG_RECORD_DETAIL_4_IX2 on LOG_RECORD_DETAIL_4 (USER_ID) local online
tablespace ESTAGING_INDEX01


stack call kdicdrv => kdicrws=> qergiFetch=>qerliFetch=>qersoFetch=>qerliRop=>ksesic0=> 报错

13000         dict/if         dictionary access routines associated with kernel compilation

这个stack call 和 argument 与 以下描述一致;


ORA-00600 [13004]

Applies to:
Oracle Server - Enterprise Edition - Version: 9.2.0.7 to 9.2.0.7
This problem can occur on any platform.
Symptoms

You are receiving the following errors in your Alert log while attempting to create an index on a table:

ORA-00600: internal error code, arguments: [13004], [], [], [], [], [], [], []

The Trace file shows the following,

ORA-00600: internal error code, arguments: [13004], [], [], [], [], [], [], []
Current SQL statement for this session:
create index tony_test_mro_ix on mr_orders(order_date)

----- Call Stack Trace -----
ksedmp,kgeriv,kgesiv,ksesic0,qerliRop,qersoFetch,qerliFetch,kdicrws,
kdicdrv,opexe,opiosq0,kpooprx,kpoal8,opiodr,ttcpip,opitsk,opiino,opiodr,
opidrv,sou2o,main
Cause

POSSIBLE BUGS:
---------------------

1) Unpublished Bug 3041474
Abstract: ORA-12801/ORA-600 [13004] ON CREATING INDEX PARALLEL)Status Closed (9.2.0.3, not a Bug)

2) Unpublished Bug 476878
Abstract: ALTER INDEX REBUILD NOPARALLEL
Status Closed ( fixed in 7.3.4.3 and 8.0.3.0 releases)

3) Unpublished Bug 1228658
Abstract: ORA-600 [13004] ON CREATE INDEX ON SNAPSHOT WHEN COMPATIBLE SET TO 8.1.6 Status:  Fixed in 8.1.6.2

The above Bugs are very simiar in their resolutions which follow,

1. Do not create the index using parallelism.

2. Do not create the index on a partitioned table.

3. Do recreate the temporary tablespace with an uniform extent size of 100MB.

You check and determine that you aren't using parallelism to create the index,

the table is not partitioned, and your temporary tablespace is created with an

an uniform extent size of 100MB.




Solution

IMPORTANT:

Check to determine whether the table was created using the 'nologging' option.

If the 'nologging' option was used to create the table, the indexes will not be

created and the ORA-00600 [13004] error is generated.

The resolution to this issue is to create indexes on this table without the 'nologging' option.



建议:

follow 以上note的建议

避免 并行创建索引、 避免使用nologging , 重建统一extent size=100MB的temp tablespace ,

回复 只看该作者 道具 举报

4#
发表于 2012-6-15 01:03:52

回复 3# 的帖子

谢谢。


是这篇文章吧?
ID 434203.1

我之前有看,没关注这个,原来依据函数链来判断是不是这个bug。

Applies to:

Oracle Server - Enterprise Edition - Version: 9.2.0.7 to 9.2.0.7
This problem can occur on any platform.

怎么还会涉及到10.2.0.4版本呢?

google出老熊的文章
(可以参考Metalink Doc ID 146580.1:What is an ORA-600 Internal Error?)如果是数字,最高位通常是指一个大的模块,而接下来的一位是小的模块。比如这里[4042],4000,最高位是4,是Transaction Layer(事务层),而次高位是0,Transaction Undo(详见Metalink Doc ID : 175982.1 ORA-600 Lookup Error Categories)。

那13000或者其他4代理事务层,在哪查的,175982.1搜索没有结果,146580.1也没有介绍代码代表哪个模块的,Orz~

回复 只看该作者 道具 举报

5#
发表于 2012-6-18 11:01:28
Metalink的Doc ID: 175982.1的确没的搜索结果
还好有博客记录,直接拿过来用鸟
http://www.ningoo.net/html/2009/ora-600_internal_error_categories.html

数字类型的Ora-600

汗,总是贴的很乱,神马情况。


此次创建index,并没有使用并行,而且是DG环境,肯定force_logging的,所以很不明白,怎么触发这个bug?

只是分区表。




[ 本帖最后由 saup007 于 2012-6-18 11:57 编辑 ]

回复 只看该作者 道具 举报

6#
发表于 2012-6-18 13:31:41
不是每一个 数字模块的600代码 都可以查到 你只需要知道大致的code layer就可以了, 可以参考这里 http://www.oracledatabase12g.com ... 7-4-0-bug-note.html

回复 只看该作者 道具 举报

7#
发表于 2012-7-2 17:53:31

回复 6# 的帖子

同一个库,同样的问题,再次出现。
trace文件在附件里

disable  gg的DDL支持的触发器即可。

alter  trigger   sys.ggs_ddl_trigger_before  Disable;

再执行就没有发生此问题。完成时间为47.12秒

我想应该与这个功能有关系吧。而且DDL create index怎么也会触发ORA-01555

bi_ora_32297.rar

1.75 MB, 下载次数: 773

回复 只看该作者 道具 举报

您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-11-15 23:59 , Processed in 0.060352 second(s), 24 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569