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

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

5

积分

1

好友

41

主题
1#
发表于 2013-10-11 17:10:41 | 查看: 4079| 回复: 4
本帖最后由 驻跸映辉 于 2013-10-12 20:59 编辑

今天,收到公司监视组发来的一个问题,
他们监视的一台服务器的alert日志中发现了下面的错误信息
ORA-00600: internal error code, arguments: [opixcnt1], [], [], [], [], [], [], [], [], [], [], []
对应生成的trace文件达到258M。
在里面发现由系统自动生成的一个SQL文,长度达到4M左右。

如下:
select 'DEBUG' DBG from dual union all select '00027276' DBG from dual union all select '20121101' DBG from dual union all后面省略
生成的select文 合计101374个

这台服务器是一台备用服务器,可以说一个星期可能就用一回。系统没有发生任何问题。

初步怀疑,是由于自动生成的SQL文太长造成的。
或者使用的union all过多。
数据库是11.2.0.3.0 64bit的机器。

监视组需要:
1.关于上面问题的发生原因的分析
2.影响范围
3.对应方法


2#
发表于 2013-10-11 19:20:16
1、标题无意义
2、 600的问题至少给出trace
3、 请回顾一下你发的几个帖子,提问质量都很低

回复 只看该作者 道具 举报

3#
发表于 2013-10-12 21:02:14
Maclean Liu(刘相兵 发表于 2013-10-11 19:20
1、标题无意义
2、 600的问题至少给出trace
3、 请回顾一下你发的几个帖子,提问质量都很低 ...

只是部门监视组的服务器,我们是拿不到trace
只能在他们的电脑上看。
我也只是一个转行一年多的。
接触的问题还达不到那个水平。
如果您能帮我解决或者能给一些建议,在此先谢谢您啦!

回复 只看该作者 道具 举报

4#
发表于 2013-10-12 23:47:29
1、这个社区的本意是希望做一个 平等 有一定技术含量的论坛, 我们希望网友尽可能提有价值 与有水平的问题

2、 对于ORA-600错误的分析  精确的必须要通过trace 分析stack call等信息 ,这也是我们原厂售后标准的诊断流程, 不看trace而看一个argument 就下结论 ,那太草率了

3、 给你建议是 一件小事如果做专业了,那么若干年后你也会成为 圈子里专业的人士

回复 只看该作者 道具 举报

5#
发表于 2013-10-12 23:49:24

回复 只看该作者 道具 举报

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

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

GMT+8, 2024-6-1 20:08 , Processed in 0.051311 second(s), 20 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

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