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

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

0

积分

1

好友

8

主题
1#
发表于 2014-2-28 18:13:08 | 查看: 3476| 回复: 5
--系统为redhat 5.6
[oracle@gps02 bdump]$ uname -a
Linux gps02.yto.com 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:39 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

--双节点10g RAC,数据库版本
SQL> select * from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi
PL/SQL Release 10.2.0.5.0 - Production
CORE    10.2.0.5.0      Production
TNS for Linux: Version 10.2.0.5.0 - Production
NLSRTL Version 10.2.0.5.0 - Production

--节点2上出现alert日志出现两条ORA-600,节点1没有报错,应用正常;
Fri Feb 28 15:09:02 CST 2014
Thread 2 advanced to log sequence 31261 (LGWR switch)
  Current log# 5 seq# 31261 mem# 0: +DATADG/gpsdb/redo05.log
Fri Feb 28 15:23:51 CST 2014
Thread 2 advanced to log sequence 31262 (LGWR switch)
  Current log# 6 seq# 31262 mem# 0: +DATADG/gpsdb/redo06.log
Fri Feb 28 15:27:30 CST 2014
Errors in file /opt/app/oracle/admin/gpsdb/bdump/gpsdb2_j000_19819.trc:
ORA-00600: internal error code, arguments: [729], [1600], [space leak], [], [], [], [], []
Fri Feb 28 15:27:31 CST 2014
Errors in file /opt/app/oracle/admin/gpsdb/bdump/gpsdb2_j000_19819.trc:
ORA-00600: internal error code, arguments: [729], [1600], [space leak], [], [], [], [], []
Fri Feb 28 15:27:31 CST 2014
Trace dumping is performing id=[cdmp_20140228152731]
Fri Feb 28 15:38:48 CST 2014
Thread 2 advanced to log sequence 31263 (LGWR switch)
  Current log# 7 seq# 31263 mem# 0: +DATADG/gpsdb/redo07.log
Fri Feb 28 15:53:19 CST 2014
Thread 2 advanced to log sequence 31264 (LGWR switch)
  Current log# 8 seq# 31264 mem# 0: +DATADG/gpsdb/redo08.log
Fri Feb 28 16:07:52 CST 2014
Thread 2 advanced to log sequence 31265 (LGWR switch)
  Current log# 5 seq# 31265 mem# 0: +DATADG/gpsdb/redo05.log

--trace文件位于附件,数据库前后没有手工做过更改

gpsdb2_j000_19819.zip

435.71 KB, 下载次数: 852

2#
发表于 2014-2-28 23:12:25
看trc里是 SYSMAN用户。

回复 只看该作者 道具 举报

3#
发表于 2014-2-28 23:13:41
同时之前有出现

  last wait for 'SGA: allocation forcing component growth' wait_time=0.000070 sec, seconds since wait started=0
          =0, =0, =0
          blocking sess=0x(nil) seq=31
  Dumping Session Wait History
   for 'SGA: allocation forcing component growth' count=1 wait_time=0.000070 sec
          =0, =0, =0

回复 只看该作者 道具 举报

4#
发表于 2014-3-3 10:21:03
不懂你的意思?

回复 只看该作者 道具 举报

5#
发表于 2014-3-3 12:06:46

*** ACTION NAME:(SEVERITY EVALUATION) 2014-02-28 15:27:29.431
*** MODULE NAME:(SEVERITY EVALUATION) 2014-02-28 15:27:29.431
*** SERVICE NAME:(SYS$USERS) 2014-02-28 15:27:29.431
*** SESSION ID:(470.3593) 2014-02-28 15:27:29.431
*** 2014-02-28 15:27:29.431
=================================
Begin 4031 Diagnostic Information
=================================
The following information assists Oracle in diagnosing
causes of ORA-4031 errors.  This trace may be disabled
by setting the init.ora _4031_dump_bitvec = 0
=====================================
Allocation Request Summary Informaton

这个都出现过4031了, 建议你调优下 pool,该问题应当能被 workaround

回复 只看该作者 道具 举报

6#
发表于 2014-3-3 13:27:08
嗯,我将调整shared pool从2G调整到4G大小,后续跟踪一下,谢谢~

回复 只看该作者 道具 举报

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

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

GMT+8, 2024-12-21 06:13 , Processed in 0.049413 second(s), 23 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

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