April 9, 2009
使用DATAPUMP导致ORA-00600 17020错误
作者:eygle
出处:http://blog.eygle.com
Oracle 10g 引入的数据泵（Datapump）带来了一系列的好处，比如Server端执行，不惧怕网络终端，任务可以中断和重启动，在数据库端通过队列来调度执行等等。
但是随着这些好处也引来一系列的问题，比如客户数据库又遇到如下问题：ORA-00600 17020错误。
这是由于导出时队列错误导致的（Oracle 10gr2支持自动的队列调度，但是据我观察，是存在很多问题的），Metalink的Bug 4334700 与此有关，Unix、Linux平台在Oracle 11g中得到修正：
Thu Apr 9 02:40:03 2009
The value (30) of MAXTRANS parameter ignored.
Thu Apr 9 02:40:07 2009
ALTER SYSTEM SET service_names='SYS$SYS.KUPC$C_1_20090409024004.ERPDB.CNC.COM' SCOPE=MEMORY SID='ERPdb1';
Thu Apr 9 02:40:07 2009
ALTER SYSTEM SET service_names='SYS$SYS.KUPC$C_1_20090409024004.ERPDB.CNC.COM','SYS$SYS.KUPC$S_1_20090409024004.ERPDB.CNC.COM' SCOPE=MEMORY SID='erpdb1';
kupprdp: master process DM00 started with pid=38, OS id=623104
to execute - SYS.KUPM$MCP.MAIN('EXPDP_BAK20090409', 'SYSTEM', 'KUPC$C_1_20090409024004', 'KUPC$S_1_20090409024004', 0);
Thu Apr 9 02:40:10 2009
ALTER SYSTEM SET service_names='SYS$SYS.KUPC$S_1_20090409024004.ERPDB.CNC.COM' SCOPE=MEMORY SID='erpdb1';
Thu Apr 9 02:40:10 2009
Errors in file /u01/admin/erpdb/bdump/erpdb1_dm00_623104.trc:
ORA-00600: internal error code, arguments: [17020], [0x70000044A750578], [], [], [], [], [], []
ORA-01460: unimplemented or unreasonable conversion requested
Thu Apr 9 02:40:10 2009
Errors in file /u01/admin/erpdb/udump/erpdb1_ora_737926.trc:
ORA-00600: internal error code, arguments: [17020], [0x70000044A750578], [], [], [], [], [], []
ORA-25207: enqueue failed, queue SYS.KUPC$C_1_20090409024004 is disabled from enqueueing
Thu Apr 9 02:40:13 2009
Trace dumping is performing id=[cdmp_20090409024013]
虽然无关大碍，但是600错误还是让人心有余悸，少用Datapump算了。
-The End-
Posted by eygle at 8:09 AM | Comments (0)
Oracle如何维护SMON_SCN_TIME表？
作者:eygle
出处:http://blog.eygle.com
今天客户的数据库再次出现了ORA-1461错误：
ORA-1461 encountered when generating server alert SMG-3500
这个错误之前已经记录过，在10.2.0.4中修正，在10.2.0.3中也并不会带来严重的问题。
但是还是又仔细看了一下这个错误提示：
update smon_scn_time set orig_thread=0, time_mp=:1, time_dp=:2, scn=:3,
scn_wrp=:4, scn_bas=:5, num_mappings=:6, tim_scn_map=:7 where thread=0 and
scn = (select min(scn) from smon_scn_time where thread=0)
这是由于数据库内部更新smon_scn_time出现的错误，这个字典表用于维护Oracle至关重要的SCN与时间的对应关系，Flashback等重要特性也以来于此。
但是这个表的记录是循环使用的，那么Oracle如何循环使用呢？
这个Bug中的这个语句说明了这个过程：
update smon_scn_time
set orig_thread=0, time_mp=:1, time_dp=:2, scn=:3,scn_wrp=:4, scn_bas=:5, num_mappings=:6, tim_scn_map=:7
where thread=0 and scn = (select min(scn) from smon_scn_time where thread=0)
原来是找出SCN最小的一个，来Update，这效率也够低的。
这个表中其实并不包含Long型数据，所以这个错误提示的根本原因其实更复杂，涉及了一连串的Bug：
SQL> desc smon_scn_time
Name Null? Type
----------------------------------------- -------- ----------------------------
THREAD NUMBER
TIME_MP NUMBER
TIME_DP DATE
SCN_WRP NUMBER
SCN_BAS NUMBER
NUM_MAPPINGS NUMBER
TIM_SCN_MAP RAW(1200)
SCN NUMBER
ORIG_THREAD NUMBER
Posted by eygle at 12:58 AM | Comments (0)