www.eygle.com

---

December 7, 2009

Oracle 11gR2 Solaris x86-64 发布

作者:eygle

出处:http://blog.eygle.com

终于在年内，Oracle如期发布了Oracle Database 11gR2的第三个版本Solaris (x86-64)，这是Oracle收购SUN之后的重要变化，之前已经多年见不到Solaris X86的版本了。

(11.2.0.1.0)
Linux x86                            Disk 1, Disk 2 (2.1 GB) | See All (Including Client, Gateways, Grid Infrastructure, more)
Linux x86-64                      Disk 1, Disk 2 (2.2 GB) | See All (Including Client, Gateways, Grid Infrastructure, more)
Solaris (SPARC) (64-bit) Disk 1, Disk 2 (2.3 GB) | See All (Including Client, Gateways, Grid Infrastructure, more)
Solaris (x86-64)                Disk 1, Disk 2 (2.2 GB) | See All (Including Client, Gateways, Grid Infrastructure, more)

现在11gR2已经有4个发布Release出来了，接下来该轮到AIX/HP/Windows了吧。

Posted by eygle at 9:46 AM | Comments (2)

---

ORA-600 17285 错误 与 PL/SQL Developer

作者:eygle

出处:http://blog.eygle.com

最近遇到一则ORA-600 17285错误，着实吓人一跳，在繁忙的高峰时段出现这个错误，还真是让人紧张的。

Fri Dec  4 10:11:24 2009
Errors in file /u01/admin/cnderpdb/udump/cnderpdb2_ora_377482.trc:
ORA-00600: internal error code, arguments: [17285], [0x1104679C0], [4294967295], [0x70000033D7A52B0], [], [], [], []
ORA-00604: error occurred at recursive SQL level 2
ORA-03135: connection lost contact
Fri Dec  4 10:11:26 2009
Trace dumping is performing id=[cdmp_20091204101126]
Fri Dec  4 10:11:26 2009
Errors in file /u01/admin/erpdb/udump/erpdb2_ora_377482.trc:
ORA-00600: internal error code, arguments: [17285], [0x1104679C0], [4294967295], [0x70000033D7A52B0], [], [], [], []
ORA-00600: internal error code, arguments: [], [], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [17285], [0x1104679C0], [4294967295], [0x70000033D7A52B0], [], [], [], []
ORA-00604: error occurred at recursive SQL level 2
ORA-03135: connection lost contact
Fri Dec  4 10:11:26 2009
Errors in file /u01/admin/erpdb/udump/erpdb2_ora_377482.trc:
ORA-07445: exception encountered: core dump [] [] [] [] [] []
ORA-00600: internal error code, arguments: [17285], [0x1104679C0], [4294967295], [0x70000033D7A52B0], [], [], [], []
ORA-00600: internal error code, arguments: [], [], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [17285], [0x1104679C0], [4294967295], [0x70000033D7A52B0], [], [], [], []
ORA-00604: error occurred at recursive SQL level 2
ORA-03135: connection lost contact

查看跟踪文件，可以发现这是一个PL/SQL Developer的客户端调用出现的问题，那么就不怕了，这应当仅仅是客户端处理异常导致的：

*** 2009-12-04 09:32:23.348
*** ACTION NAME:(Test Window - Script for procedu) 2009-12-04 09:32:23.335
*** MODULE NAME:(PL/SQL Developer) 2009-12-04 09:32:23.335
*** SERVICE NAME:(SYS$USERS) 2009-12-04 09:32:23.335
*** SESSION ID:(754.58117) 2009-12-04 09:32:23.335
Probe:read_pipe: receive failed, status 3
*** 2009-12-04 10:11:24.194
*********START PLSQL RUNTIME DUMP************
***Got internal error Exception caught in pfrrun() while running PLSQL***
***Got ORA-604 while running PLSQL***
PACKAGE BODY SYS.PBREAK:
library unit=7000002d541e670 line=1129 opcode=0 static link=0 scope=1
FP=110448310 PC=7000002e28c37c2 Page=1 AP=1104470d0 ST=110448510
DL0=110545dc8 GF=110545e60 DL1=110545e08 DPF=110545e50 DS=7000002e28c5250

也就是说，可能某个客户端正在调用PL/SQL Developer进行某个Procedure的测试。

查询一下Metalink获得基本信息，也可以知道问题不大：

Oracle is in the process of deleting an instantiation object when it discovers that the object is currently on the call stack.

也就是说Oracle在处理删除对象时，发现对象还在被调用，这类错误显然并不会带来数据损失。

在跟踪文件部分也可以看到错误出现在dbms_debug包的调用过程中：

*** 2009-12-04 10:11:24.213
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [17285], [0x1104679C0], [4294967295], [0x70000033D7A52B0], [], [], [], []
ORA-00604: error occurred at recursive SQL level 2
ORA-03135: connection lost contact
Current SQL statement for this session:
begin
  sys.dbms_debug.default_timeout := 3600;
  sys.dbms_debug.debug_off;
end;
----- PL/SQL Call Stack -----
  object      line  object
  handle    number  name
----- Call Stack Trace -----
calling              call     entry                argument values in hex     
location             type     point                (? means dubious value)    
-------------------- -------- -------------------- ----------------------------

Metalink上还有个历史悠久的Bug中提到：
Bug 377047  PLSQL: ORA-600 [17285] if Ctrl-C in critical code

可见客户端在编译或执行过程中取消某些操作就可以导致这个600错误。

也可以参考Yangtingkun遇到的： http://space.itpub.net/4227/viewspace-254385

-The End-

Posted by eygle at 8:24 AM | Comments (0)

---