Oracle高可用最佳实践

如果需要了解或架构高可用环境,建议看一下这篇文档。
这篇文档介绍了Oracle高可用相关的知识点,包括ASM、CLUSTER、RAC、DATA GUARD、GOLDENGATE、BACKUP、RESTORE等等,此外还介绍了高可用环境的监控,以及如何利用这些高可用功能来减少维护的停机时间。
从文档的名称高可用最佳实践和文档的页数高,这篇文档中不会包括这些知识点的具体概念,而应该是这些功能在哪些场合使用最合适,以及相互之间如何配合。
照例给出网址:http://www.oracle.com/pls/db112/to_toc?pathname=server.112%2Fe10803%2Ftoc.htm&remark=portal+%28Books%29

Posted in NEWS | Leave a comment

启动取消导致ORA-600(2658)错误

客户数据库在SHUTDOWN的过程中执行了取消操作,导致了ORA-600错误。
数据库版本为10.2.0.4 RAC for HP-UX,详细错误信息为:

Thu Oct 22 15:05:14 2009
Shutting down instance: further logons disabled
Thu Oct 22 15:05:15 2009
Stopping background process QMNC
Thu Oct 22 15:05:15 2009
Stopping background process CJQ0
Thu Oct 22 15:05:17 2009
Stopping background process MMNL
Thu Oct 22 15:05:18 2009
Stopping background process MMON
Thu Oct 22 15:05:19 2009
Shutting down instance (immediate)
License high water mark = 8
Thu Oct 22 15:05:19 2009
Stopping Job queue slave processes, flags = 7
Thu Oct 22 15:05:19 2009
Job queue slave processes stopped
Thu Oct 22 15:05:20 2009
ALTER DATABASE CLOSE NORMAL
Thu Oct 22 15:05:20 2009
SMON: disabling tx recovery
SMON: disabling cache recovery
Thu Oct 22 15:05:21 2009
LGWR: Waiting FOR ORLs TO be archived...
Thu Oct 22 15:05:36 2009
Reconfiguration started (OLD inc 2, NEW inc 4)
List OF nodes:
0 1
Global Resource Directory frozen
Communication channels reestablished
* DOMAIN 0 valid = 1 according TO instance 0 
Thu Oct 22 15:05:36 2009
Master broadcasted resource hash VALUE bitmaps
Non-LOCAL Process blocks cleaned OUT
Thu Oct 22 15:05:36 2009
LMS 0: 0 GCS shadows cancelled, 0 closed
Thu Oct 22 15:05:36 2009
LMS 1: 0 GCS shadows cancelled, 0 closed
SET master node info 
Submitted ALL remote-enqueue requests
Dwn-cvts replayed, VALBLKs dubious
ALL grantable enqueues GRANTED
Thu Oct 22 15:05:36 2009
LMS 1: 2008 GCS shadows traversed, 1001 replayed
Thu Oct 22 15:05:36 2009
LMS 0: 1988 GCS shadows traversed, 1034 replayed
Thu Oct 22 15:05:36 2009
Submitted ALL GCS remote-cache requests
Fix WRITE IN gcs resources
Reconfiguration complete
Thu Oct 22 15:05:51 2009
CLOSE: Error 1013 during DATABASE close
Thu Oct 22 15:05:51 2009
SMON: enabling cache recovery
SMON: enabling tx recovery
Thu Oct 22 15:05:51 2009
ORA-1013 signalled during: ALTER DATABASE CLOSE NORMAL...
Thu Oct 22 15:05:51 2009
Errors IN file /u01/app/oracle/admin/orcl3/bdump/orcl32_lns1_4678.trc:
ORA-00600: internal error code, arguments: [2658], [4], [2], [], [], [], [], []
Thu Oct 22 15:05:52 2009
Trace dumping IS performing id=[cdmp_20091022150552]
Thu Oct 22 15:05:52 2009
Errors IN file /u01/app/oracle/admin/orcl3/bdump/orcl32_lns1_4678.trc:
ORA-00600: internal error code, arguments: [2658], [4], [2], [], [], [], [], []
Thu Oct 22 15:05:55 2009
LGWR: ORLs successfully archived
Shutting down archive processes
Archiving IS disabled
Thu Oct 22 15:06:00 2009
ARCH shutting down
ARC3: Archival stopped
Thu Oct 22 15:06:05 2009
ARCH shutting down
ARC2: Archival stopped
Thu Oct 22 15:06:10 2009
ARCH shutting down
ARC1: Archival stopped
Thu Oct 22 15:06:15 2009
ARCH shutting down
ARC0: Archival stopped
Thu Oct 22 15:06:16 2009
Thread 2 closed at log SEQUENCE 23
Successful close OF redo thread 2

可以看到,用户在执行了SHUTDOWN IMMEDIATE操作后,执行了CTRL+C取消操作,导致了ORA-1031错误,之后同一时间引发了ORA-600[2658]错误。显然这个错误的产生和用户发出的取消命令直接相关,而且最终这个命令并未生效,数据库成功的被关闭。
在MOS上查询了一下ORA-600[2658]的相关错误,发现多部分错误都出现在7.3和8.1版本上,在9i以后这个错误已经很少见了,从这一点也可以看出,导致这个错误出现的是偶然的因素,那么取消操作显然是导致这个错误的最大可能性。
数据库本身处于关闭过程中,因此这个错误没有影响,可以直接忽略掉。

Posted in BUG | Tagged , , , | Leave a comment

ORA-600(17175)错误

又是一个导致实例崩溃的BUG。
数据库版本10.2.0.4 RAC for Hp-UX 11.31,在出现这个错误的同时还出现了ORA-601的错误:

Wed DEC 1 01:57:55 2010
Errors IN file /u01/app/oracle/admin/orcl2/bdump/orcl21_pmon_3250.trc:
ORA-00600: internal error code, arguments: [17175], [255], [], [], [], [], [], []
ORA-00601: cleanup LOCK conflict
Wed DEC 1 01:57:57 2010
Trace dumping IS performing id=[cdmp_20101201015757]
Wed DEC 1 01:58:05 2010
LGWR: terminating instance due TO error 472
Wed DEC 1 01:58:05 2010
Errors IN file /u01/app/oracle/admin/orcl2/bdump/orcl21_lms1_3291.trc:
ORA-00472: PMON process TERMINATED WITH error
Wed DEC 1 01:58:05 2010
Errors IN file /u01/app/oracle/admin/orcl2/bdump/orcl21_lms2_3293.trc:
ORA-00472: PMON process TERMINATED WITH error
Wed DEC 1 01:58:05 2010
Errors IN file /u01/app/oracle/admin/orcl2/bdump/orcl21_lms3_3295.trc:
ORA-00472: PMON process TERMINATED WITH error
Wed DEC 1 01:58:05 2010
Errors IN file /u01/app/oracle/admin/orcl2/bdump/orcl21_lms0_3289.trc:
ORA-00472: PMON process TERMINATED WITH error
Wed DEC 1 01:58:05 2010
Errors IN file /u01/app/oracle/admin/orcl2/bdump/orcl21_lmon_3283.trc:
ORA-00472: PMON process TERMINATED WITH error
Wed DEC 1 01:58:05 2010
Errors IN file /u01/app/oracle/admin/orcl2/bdump/orcl21_lmd0_3287.trc:
ORA-00472: PMON process TERMINATED WITH error
Wed DEC 1 01:58:05 2010
Shutting down instance (abort)
License high water mark = 421
Wed DEC 1 01:58:11 2010
Instance TERMINATED BY LGWR, pid = 3307
Wed DEC 1 01:58:15 2010
Instance TERMINATED BY USER, pid = 3444

在MOS上查询,发现最接近的描述为:Bug 7590297 : ORA-600 [17175] [255] ORA-601: CLEANUP LOCK CONFLICT CRASHED THE DATABASE。出现错误的同样是HP-UX平台,数据库版本10.2.0.3也非常接近。出现了ORA-600 17175的错误和ORA-601错误,而且连17175错误的第二个参数255都和当前的环境是一样的。可惜的是,Oracle并没有对这个BUG给出任何有价值的描述,而是认为需要进一步信息才能判断问题的原因。
对于已知的问题,ORA-600 [17175] in PMON when the Event 10235 Is Set with a Wrong Level描述的现象和当前十分接近,不过当前版本并未设置EVENT。
如果从错误信息看,在SHUTDOWN ABORT后出现了接连两个Instance terminated信息,一个描述是实例被LGWR中止,另一个描述是实例被用户中止。问题有可能出现在用户发出SHUTDOWN ABORT命令后,Oracle的PMON进程尝试清理锁进程是出现了异常。
这个错误应该属于比较罕见的问题,在MOS上也没有太多的信息,应该属于偶然产生的问题。

Posted in BUG | Tagged , , , , , | Leave a comment

标签安全管理员手册总结

Oracle的标签安全是通过在数据上添加标识,来实现安全性访问的。
和其他很多安全性方式的实现不同,标签安全需要对数据本身进行修改,虽然不会修改表中的原有字段,但是会新增一个字段并写入不同的值,然后根据这个值来确定用户是否有权限访问。虽然这个字段可以设置为隐藏,也可以通过触发器实现自动的更新,但是这种对表结构的修改并非是大部分应用可以接受的。事实上,这也是标签安全选件在平时很少使用的原因之一。
不过如果确实对于数据的行级需要设置不同的访问权限控制,那么标签安全可能是最合适的选择,虽然精细存储控制可以实现部分功能,但是访问的粒度以及能支持的权限控制的复杂程度要比标签安全差多了。

Posted in BOOKS | Leave a comment

ORA-600(kccsbck_first)错误

客户Oracle10.2.0.4 RAC数据库出现ORA-600(kccsbck_first)错误。
详细错误信息为:

Wed Oct 14 17:43:34 2009
ALTER DATABASE FORCE LOGGING
Wed Oct 14 17:43:34 2009
ORA-12920 signalled during: ALTER DATABASE FORCE LOGGING...
Wed Oct 14 17:43:42 2009
ALTER SYSTEM SET db_unique_name='PRIMARY' SCOPE=SPFILE;
Wed Oct 14 17:44:01 2009
ALTER SYSTEM SET log_archive_config='DG_CONFIG=(primary,standby)' SCOPE=SPFILE;
Wed Oct 14 17:44:11 2009
ALTER SYSTEM SET log_archive_dest_state_1='ENABLE' SCOPE=SPFILE;
Wed Oct 14 17:44:20 2009
ALTER SYSTEM SET log_archive_dest_state_2='ENABLE' SCOPE=SPFILE;
Wed Oct 14 17:44:27 2009
ALTER SYSTEM SET remote_login_passwordfile='EXCLUSIVE' SCOPE=SPFILE;
Wed Oct 14 17:44:39 2009
ALTER SYSTEM SET log_archive_format='%t_%s_%r.arc' SCOPE=SPFILE;
Wed Oct 14 17:44:47 2009
ALTER SYSTEM SET log_archive_max_processes=4 SCOPE=SPFILE;
Wed Oct 14 17:44:57 2009
ALTER SYSTEM SET fal_client='PRIMARY' SCOPE=SPFILE;
Wed Oct 14 17:45:03 2009
ALTER SYSTEM SET fal_server='STANDBY' SCOPE=SPFILE;
Wed Oct 14 17:45:20 2009
ALTER SYSTEM SET standby_file_management='MANUAL' SCOPE=SPFILE;
Wed Oct 14 17:45:34 2009
Shutting down instance: further logons disabled
Wed Oct 14 17:45:35 2009
Stopping background process CJQ0
Wed Oct 14 17:45:35 2009
Stopping background process MMNL
Wed Oct 14 17:45:36 2009
Stopping background process MMON
Wed Oct 14 17:45:37 2009
Shutting down instance (immediate)
License high water mark = 7
Wed Oct 14 17:45:37 2009
Stopping Job queue slave processes, flags = 7
Wed Oct 14 17:45:37 2009
Job queue slave processes stopped
Wed Oct 14 17:45:39 2009
ALTER DATABASE CLOSE NORMAL
Wed Oct 14 17:45:39 2009
SMON: disabling tx recovery
SMON: disabling cache recovery
Wed Oct 14 17:45:41 2009
Shutting down archive processes
Archiving IS disabled
Wed Oct 14 17:45:46 2009
ARCH shutting down
ARC1: Archival stopped
Wed Oct 14 17:45:51 2009
ARCH shutting down
ARC0: Archival stopped
Wed Oct 14 17:45:52 2009
Thread 2 closed at log SEQUENCE 1
Successful close OF redo thread 2
Wed Oct 14 17:45:52 2009
Completed: ALTER DATABASE CLOSE NORMAL
Wed Oct 14 17:45:52 2009
ALTER DATABASE DISMOUNT
Completed: ALTER DATABASE DISMOUNT
ARCH: Archival disabled due TO shutdown: 1089
Shutting down archive processes
Archiving IS disabled
Archive process shutdown avoided: 0 active
ARCH: Archival disabled due TO shutdown: 1089
Shutting down archive processes
Archiving IS disabled
Archive process shutdown avoided: 0 active
Wed Oct 14 17:45:57 2009
freeing rdom 0
Wed Oct 14 17:47:03 2009
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Interface TYPE 1 lan906 192.168.0.0 configured FROM OCR FOR USE AS a cluster interconnect
Interface TYPE 1 lan905 10.200.32.0 configured FROM OCR FOR USE AS a public interface
Picked latch-free SCN scheme 3
Autotune OF undo retention IS turned ON. 
LICENSE_MAX_USERS = 0
SYS auditing IS disabled
ksdpec: called FOR event 13740 prior TO event GROUP initialization
Starting up ORACLE RDBMS Version: 10.2.0.4.0.
System parameters WITH non-DEFAULT VALUES:
processes = 600
sessions = 665
timed_statistics = TRUE
sga_max_size = 17179869184
lock_sga = TRUE
__shared_pool_size = 1644167168
__large_pool_size = 16777216
__java_pool_size = 16777216
__streams_pool_size = 0
spfile = /dev/DATA/ORCL1_spfile
sga_target = 12029263872
control_files = /dev/DATA/ORCL1_control01, /dev/DATA/ORCL1_control02, /dev/DATA/ORCL1_control03
control_file_record_keep_time= 15
db_block_size = 8192
__db_cache_size = 10284433408
db_writer_processes = 4
compatible = 10.2.0.3.0
log_archive_config = DG_CONFIG=(PRIMARY,standby)
log_archive_dest_1 = LOCATION=/orabak/arch
log_archive_dest_state_1 = ENABLE
log_archive_dest_state_2 = ENABLE
log_archive_max_processes= 4
log_archive_format = %t_%s_%r.arc
fal_client = PRIMARY
fal_server = STANDBY
log_buffer = 52428800
db_file_multiblock_read_count= 32
cluster_database = TRUE
cluster_database_instances= 2
standby_file_management = MANUAL
thread = 2
fast_start_mttr_target = 600
instance_number = 2
undo_management = AUTO
undo_tablespace = UNDOTBS2
undo_retention = 43200
remote_login_passwordfile= EXCLUSIVE
db_domain = 
remote_listener = LISTENERS_ORCL1
job_queue_processes = 10
bitmap_merge_area_size = 1048576
parallel_max_servers = 80
background_dump_dest = /u01/app/oracle/admin/orcl1/bdump
user_dump_dest = /u01/app/oracle/admin/orcl1/udump
max_dump_file_size = 20971520
core_dump_dest = /u01/app/oracle/admin/orcl1/cdump
audit_file_dest = /u01/app/oracle/admin/orcl1/adump
hpux_sched_noage = 178
db_name = orcl1
db_unique_name = PRIMARY
open_cursors = 1500
pga_aggregate_target = 2147483648
workarea_size_policy = Auto
Cluster communication IS configured TO USE the following interface(s) FOR this instance
192.168.0.102
Wed Oct 14 17:47:10 2009
cluster interconnect IPC version:Oracle UDP/IP (generic)
IPC Vendor 1 proto 2
PMON started WITH pid=2, OS id=22684
DIAG started WITH pid=4, OS id=22706
PSP0 started WITH pid=6, OS id=22708
LMON started WITH pid=8, OS id=22710
LMD0 started WITH pid=10, OS id=22712
LMS0 started WITH pid=12, OS id=22714
LMS1 started WITH pid=14, OS id=22716
LMS2 started WITH pid=16, OS id=22723
LMS3 started WITH pid=18, OS id=22725
MMAN started WITH pid=20, OS id=22727
DBW0 started WITH pid=22, OS id=22729
DBW1 started WITH pid=24, OS id=22731
DBW2 started WITH pid=26, OS id=22733
DBW3 started WITH pid=28, OS id=22735
LGWR started WITH pid=30, OS id=22737
CKPT started WITH pid=32, OS id=22739
SMON started WITH pid=34, OS id=22741
RECO started WITH pid=36, OS id=22743
CJQ0 started WITH pid=38, OS id=22745
MMON started WITH pid=40, OS id=22747
MMNL started WITH pid=42, OS id=22749
Wed Oct 14 17:47:17 2009
lmon registered WITH NM - instance id 2 (internal mem no 1)
Wed Oct 14 17:47:17 2009
Reconfiguration started (OLD inc 0, NEW inc 2)
List OF nodes:
1
Global Resource Directory frozen
* allocate DOMAIN 0, invalid = TRUE 
Communication channels reestablished
Master broadcasted resource hash VALUE bitmaps
Non-LOCAL Process blocks cleaned OUT
Wed Oct 14 17:47:17 2009
LMS 1: 0 GCS shadows cancelled, 0 closed
Wed Oct 14 17:47:17 2009
LMS 3: 0 GCS shadows cancelled, 0 closed
Wed Oct 14 17:47:17 2009
LMS 0: 0 GCS shadows cancelled, 0 closed
Wed Oct 14 17:47:17 2009
LMS 2: 0 GCS shadows cancelled, 0 closed
SET master node info 
Submitted ALL remote-enqueue requests
Dwn-cvts replayed, VALBLKs dubious
ALL grantable enqueues GRANTED
Post SMON TO START 1st pass IR
Wed Oct 14 17:47:17 2009
LMS 1: 0 GCS shadows traversed, 0 replayed
Wed Oct 14 17:47:17 2009
LMS 2: 0 GCS shadows traversed, 0 replayed
Wed Oct 14 17:47:17 2009
LMS 3: 0 GCS shadows traversed, 0 replayed
Wed Oct 14 17:47:17 2009
LMS 0: 0 GCS shadows traversed, 0 replayed
Wed Oct 14 17:47:17 2009
Submitted ALL GCS remote-cache requests
Fix WRITE IN gcs resources
Reconfiguration complete
LCK0 started WITH pid=44, OS id=22761
Wed Oct 14 17:47:18 2009
ALTER DATABASE MOUNT
Wed Oct 14 17:47:18 2009
This instance was FIRST TO mount
Wed Oct 14 17:47:22 2009
Errors IN file /u01/app/oracle/admin/orcl1/udump/orcl12_ora_22762.trc:
ORA-00600: internal error code, arguments: [kccsbck_first], [1], [559446173], [], [], [], [], []
Wed Oct 14 17:47:23 2009
Trace dumping IS performing id=[cdmp_20091014174723]
Wed Oct 14 17:47:24 2009
ORA-600 signalled during: ALTER DATABASE MOUNT...
Wed Oct 14 17:47:58 2009
Shutting down instance (abort)
License high water mark = 1
Instance TERMINATED BY USER, pid = 23014

虽然ORA-600错误只是在上面信息的最后几行,但是前面的初始化参数修改和实例重启和这个错误有直接的关系。
很明显,这是一个配置DATA GUARD的过程,不过当前实例在配置DATA GUARD后进行了重启,而这个错误恰好和实例的重启有关。
跟进MOS文档Startup (mount) of 2nd RAC instance fails with ORA-00600 [kccsbck_first] [ID 395156.1],导致这个错误的原因是两个RAC实例设置的DB_UNIQUE_NAME参数不同所致。前面通过ALTER SYSTEM设置了DB_UNIQUE_NAME,并重启使之生效,而对于另外的节点,由于没有重启系统,DB_UNIQUE_NAME的设置没有改变,因此造成了当前启动的实例与另一个节点上一直运行的实例出现了冲突。
解决这个问题很简单,将另外一个实例也进行重启,就可以解决。

Posted in BUG | Tagged , , , , | Leave a comment

GoldenGate导致的Streams miscellaneous event等待事件

客户一个并不繁忙的数据库出现长时间Streams miscellaneous event等待。

 

 

数据库版本是RAC 11.2.0.2 for Linux X64,其中一个节点的TOP 5等待信息为:

Event

Waits

Time(s)

Avg wait (ms)

% DB time

Wait Class

Streams miscellaneous event

62,377

31,274

501

93.26

Other

DB CPU

1,887

5.63

log file sequential read

648,206

276

0

0.82

System I/O

control file sequential read

519,487

122

0

0.36

System I/O

Disk file operations I/O

483,960

99

0

0.30

User I/O

显然,这个数据库的主要负载发生在这个等待事件上,而这个系统中部署了Goldengate。查询MOS,很容易找到文档Why do I see Streams Miscellaneous Event in AWR as a Top Event When GoldenGate Extract is Running [ID 1317122.1]。

文档对这个问题进行了简单的描述,这个等待事件是Goldengate在等待日志中的额外工作的,在11.2.0.2.X版本以后,这个等待事件改名为Waiting for additional work from the logfile,而且被记入到空闲等待中。

对于这个问题,可以安全的将其忽略掉。

 

Posted in NEWS | Tagged , , | Leave a comment

系统空间不足产生ORA-1错误

ORA-1错误代表唯一冲突,而空间不足时出现这个错误还是第一次碰到。
错误信息如下:

Tue May 01 05:00:11 2012
Non critical error ORA-00001 caught while writing TO trace file "/home/oracle/base/diag/rdbms/orcl/orcl/trace/orcl_ora_31131.trc"
Error message: Linux-x86_64 Error: 28: No SPACE LEFT ON device
Additional information: 1
Writing TO the above trace file IS disabled FOR now ON...

这个错误是11.2.0.2引入的,Oracle本应该返回操作系统上的错误,结果返回了ORA-00001错误信息,这是一个未发布的BUG 8367518导致的,可以参考文档Non Critical Error ORA-00001 Caught While Writing To Trace File [ID 1354863.1]。
Oracle给出的解决方法就是应用BUG 8367518的补丁,当然这个问题并不严重,完全可以将其忽略。

Posted in BUG | Tagged , , | Leave a comment

20120526ACOUG活动

这次ACOUG活动是一个整天的活动,上午请了Oracle原厂的人介绍Exadata,下午仍然是ACOUG的照常活动。
上午的活动由Oracle的原厂专家聂智兵和娄恒给我们带来了Exadata一体机的主题。在Exadata上取得的成功,使得Oracle坚定的在一体机的道理上走了下去,目前Oracle推出的一体机的产品包括Exadata、Exalogic、Oracle Database Appliance、SuperCluster、Exalytics和Oracle Big Data Appliance。而且Oracle将一体机作为Oracle的云解决方案,提出了数据库等核心组件应该采用PaaS平台来实现。
下午的技术主题,我分享了在DTCC上的主题《Think Different》,上次由于时间的限制,很多东西没有展开,这次在ACOUG上的时间相对充裕一些,可以有更多的时间描述一些思路,期望能对与会的人有些帮助。
随后是崔华分享了《基于Oracle的SQL优化》,这个主题在他的公司内部需要30个小时左右,今天只是分享了其中关于子查询展开和视图合并的相关内容。崔华的课程会持续3期,对于SQL优化感兴趣的会员,一定不要错过这个难得的机会。
最后是张云帆Kevin__Zhang给我们带来的《Oracle Clusterware 故障诊断思路》。Kevin__Zhang这个ID近期在ITPUB上非常活跃,这次又在ACOUG上和大家分享了自己的心得。只要能保持不断的学习、积累和分享,用不了太长时间,技术水平就可以得到很快的提升。这里也希望更多的后起之秀能快速的成长起来。

Posted in NEWS | Leave a comment

ORA-600(kkzisf3g.5)错误

这个错误是在物化视图刷新过程中产生的。
数据库版本为10.1.0.4,在刷新物化视图时出现这个错误:

Fri Nov 5 01:00:03 2010
Errors IN file /oracle/admin/orcl/bdump/orcl_j002_254624.trc:
ORA-00600: internal error code, arguments: [kkzisf3g.5], [], [], [], [], [], [], []
Fri Nov 5 01:00:04 2010
Errors IN file /oracle/admin/orcl/bdump/orcl_j002_254624.trc:
ORA-00600: internal error code, arguments: [kkzisf3g.5], [], [], [], [], [], [], []
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 1883
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2089
ORA-06512: at "SYS.DBMS_IREFRESH", line 683
ORA-06512: at "SYS.DBMS_REFRESH", line 195
ORA-06512: at line 1

显然错误是由于物化视图的刷新导致的,不过Oracle的MOS只是有一个bug的描述,但是并没有给出解决的方法:Bug 6280249 : ORA-00600 [KKZISF3G.5] OCCURS WHEN MVIEW IS REFRESHED。
虽然Oracle并没有提供解决方法,但是这个错误发生在比较少见的10.1环境中,且整个MOS中只出现过一次,理论上讲,升级到10.2就应该可以避免该错误的产生。

Posted in BUG | Tagged , , , | Leave a comment

ORA-600(1234)和ORA-600(729)错误

客户的ORACLE 10.1.0.4出现了这两个错误。
10.1的数据库并不多见,大部分使用10.1版本的也都升级到了10.2。而对于这两个错误而言,ORA-600[729]错误是很常见的内存泄漏问题,而相对来说ORA-600[1234]错误就少见得多了:

Sun Sep 14 14:42:51 2008
Errors IN file /oracle/admin/orcl/udump/orcl_ora_266736.trc:
ORA-00600: internal error code, arguments: [729], [160], [SPACE leak], [], [], [], [], []
Sun Sep 14 14:42:52 2008
Errors IN file /oracle/admin/orcl/udump/orcl_ora_266736.trc:
ORA-00600: internal error code, arguments: [1234], [], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [729], [160], [SPACE leak], [], [], [], [], []

显然这个问题最开始还是729导致的,因此问题根本上仍然是一个内存泄漏相关的问题,查询MOS文档,发现和问题Bug 5871524 : GETTING ERROR ORA-600 [1234] / ORA-600 [729] CONTINUOUSLY的描述一致,除了错误信息详细,版本相符度也很高。
导致这个问题指向bug:6870937,确认影响的版本包括10.2.0.4和11.1.0.6,Oracle在10.2.0.4.1、10.2.0.5、11.1.0.7和11.2.0.1中解决了这个问题。对于少量的内存泄漏,可以采用忽略的策略,个人不推荐使用10262事件屏蔽该错误信息。

Posted in BUG | Tagged , , , | Leave a comment