参考手册

Posted on 2012/01/04 by yangtingkun

这篇文档和PL/SQL PACKAGE AND TYPES REFERENCE一样，都是大部头的文档。
这两篇再加上计划中的SQL REFERENCES以及PL/SQL LANGUAGE REFERENCE，都是一直想要通读一遍的文档，只不过和其他文档相比优先级较低，且预计花费时间较长。
这篇文档虽然篇幅很长，但是实际上只包括了两部分内容：初始化参数和系统视图。视图部分又分为静态视图和动态视图两部分。
这篇文档很常用，估计没有看到的人不多，不管怎样，还是给出在线地址：http://www.oracle.com/pls/db112/to_toc?pathname=server.112/e25513/toc.htm

Posted in BOOKS | Leave a comment

ORA-600(KGHALO4)错误

Posted on 2012/01/03 by yangtingkun

客户数据库频繁出现这个错误。
详细的错误信息为：

Sat DEC 31 21:26:23 2011
Errors IN file /opt/app/oracle/admin/ynwcdma/bdump/ynwcdma_pmon_5510.trc:
ORA-00600: 内部错误代码, 参数: [KGHALO4], [0xC0000003E80CD060], [], [], [], [], [], []
Error occured while spawning process CJQ0; error = 600
Sat DEC 31 21:26:25 2011
Errors IN file /opt/app/oracle/admin/ynwcdma/bdump/ynwcdma_pmon_5510.trc:
ORA-00600: 内部错误代码, 参数: [KGHALO4], [0xC0000003E80CD060], [], [], [], [], [], []
PMON: terminating instance due TO error 472
Sat DEC 31 21:26:25 2011
Errors IN file /opt/app/oracle/admin/ynwcdma/udump/ynwcdma_ora_28532.trc:
ORA-00600: internal error code, arguments: [KGHALO4], [0xC0000003E80CD060], [], [], [], [], [], []
Sat DEC 31 21:26:30 2011
Instance TERMINATED BY PMON, pid = 5510

数据库后台日志中频繁出现ORA-600(KGHALO4)错误，在CJQ0进程启动时，引发了这个600错误，处理用户进程出现错误外，PMON进程同样产生了这个错误，并导致数据库的崩溃。
查询MOS，怀疑是文档ORA-00600: [Kghalo4] During Normal Database Operation [ID 403127.1]描述的bug，这个问题在10.2.0.2以上版本被修正。而当前的版本就是10201版本，要避免这个错误的出现，可以设置隐含参数：_enable_NUMA_optimization=FALSE，然后重启数据库。
建议客户首先逻辑备份数据库后，设置该隐含参数并重启后，这个600错误不再出现。

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

10g新增初始化参数SKIP_UNUSABLE_INDEXES

Posted on 2012/01/02 by yangtingkun

这个10.1就增加的新特性，是最近才发现的。

公司中的新人问起索引失效对表影响，于是随手做了个例子，才发现10g中已经改变了9i中的默认方式：

SQL> CREATE TABLE t_index (id NUMBER, name varchar2(30));
TABLE created.
SQL> CREATE INDEX ind_t_id ON t_index(id);
INDEX created.
SQL> CREATE INDEX ind_t_name ON t_index(name);
INDEX created.
SQL> INSERT INTO t_index VALUES (1, 'a');
1 ROW created.
SQL> commit;
Commit complete.
SQL> ALTER TABLE t_index move; 
TABLE altered.
SQL> SELECT index_name, STATUS FROM user_indexes WHERE TABLE_NAME = 'T_INDEX';
INDEX_NAME                     STATUS
------------------------------ --------
IND_T_ID                       UNUSABLE
IND_T_NAME                     UNUSABLE
SQL> INSERT INTO t_index VALUES (2, 'b');
1 ROW created.

当这个插入语句成功后，我发现自己做的例子居然和预期产生了差异，在我的印象中，这个插入语句是应该报错的。
随后马上做了三件事情：

SQL> SELECT * FROM v$version;
BANNER
----------------------------------------------------------------
Oracle DATABASE 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE    10.2.0.4.0      Production
TNS FOR Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
SQL> SELECT index_name, STATUS FROM user_indexes WHERE TABLE_NAME = 'T_INDEX';
INDEX_NAME                     STATUS
------------------------------ --------
IND_T_ID                       UNUSABLE
IND_T_NAME                     UNUSABLE
SQL> SHOW parameter INDEX
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
optimizer_index_caching              INTEGER     0
optimizer_index_cost_adj             INTEGER     100
skip_unusable_indexes                BOOLEAN     TRUE

首先第一件事情就是坚持当前数据库的版本，我可以确定在9i，最后一个INSERT会由于索引的状态不可用而导致错误，而当前可以执行成功，因此首先确定版本问题。
在确认是10.2版本后，随后又坚持了一下索引的状态，看看是否插入导致Oracle重建了索引。而当前索引的状态并未发生变化，说明Oracle在执行插入时，跳过了这些不可用的索引。
于是顺理成章的就是第三个动作，坚持包含index关键字的初始化参数，看看是否是10g中存在了一个类似的初始化参数，使得索引在不可用状态下，基表同样可以进行DML操作。
查询果然发现了这个参数，而且从名称以及设置的值来看，确认就是要找的初始化参数：

SQL> ALTER SESSION SET skip_unusable_indexes = FALSE;
SESSION altered.
SQL> INSERT INTO t_index VALUES (3, 'c');
INSERT INTO t_index VALUES (3, 'c')
*
ERROR at line 1:
ORA-01502: INDEX 'TEST.IND_T_ID' OR partition OF such INDEX IS IN unusable state
 
SQL> ALTER INDEX ind_t_id rebuild;
INDEX altered.
SQL> ALTER INDEX ind_t_name rebuild;
INDEX altered.
SQL> INSERT INTO t_index VALUES (3, 'c');
1 ROW created.
SQL> commit;
Commit complete.

将初始化参数设置为FALSE后，数据库的行为果然表现的和9i中一致。
查询了一下Oracle的文档，发现在10.1中Oracle已经引入了这个初始化参数。这个参数的引入可以避免由于表MOVE或其他DDL导致的索引失效，从而影响到整个表的可用性，同时这个参数的引入也会存在问题，它使得本来可以很快发现的问题埋藏的很深，甚至可能造成严重的性能隐患。
当然Oracle也意识到这一点，在告警日志中可以看到这些的提示信息：

Sat DEC 31 10:53:33 2011
SOME indexes OR INDEX [sub]partitions OF TABLE TEST.T_INDEX have been marked unusable

这同样也说明，任何一个参数都有两个方面，如果设置参数后只有优点而没有缺点，Oracle也就没有必要让用户去选择了。

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

数据泵导出碰到ORA-600(kcbz_check_objd_typ_3)错误

Posted on 2012/01/01 by yangtingkun

客户的数据库崩溃，被强制打开后，使用数据泵导出出现ORA-600(kcbz_check_objd_typ_3)错误。
以前碰到过一个ORA-600(kcbz_check_objd_typ_3)错误，是由于客户利用不同版本软件创建了控制文件，尝试打开数据库所致。详情可以参考：http://yangtingkun.itpub.net/post/468/517661
这次的情况其实有类似的地方，客户的数据库出现ORA-600(4000)的错误，被我们强制打开后，肯定数据字典存在不一致的情况。
导出时详细错误信息如下：

[oracle] % expdp system/manager directory=d_output dumpfile=full_bk_2011123101.dmp FULL=y logfile=full_bk_2011123101.log parallel=4
Export: Release 10.2.0.1.0 - 64bit Production ON 星期六, 31 12月, 2011 23:02:46
Copyright (c) 2003, 2005, Oracle. ALL rights reserved.
连接到: Oracle DATABASE 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
WITH the Partitioning, OLAP AND DATA Mining options
启动 "SYSTEM"."SYS_EXPORT_FULL_48": system/******** directory=d_output dumpfile=full_bk_2011123101.dmp full=y logfile=full_bk_2011123101.log parallel=4 
正在使用 BLOCKS 方法进行估计...
处理对象类型 DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA
ORA-39014: 一个或多个 worker 进程已过早地退出。
ORA-39029: worker 进程 1 (进程名为 "DW03") 过早地终止
ORA-31671: Worker 进程 DW03 有未处理的异常错误。
ORA-00600: 内部错误代码, 参数: [kcbz_check_objd_typ_3], [8], [0], [32], [], [], [], []
ORA-06512: 在 "SYS.KUPW$WORKER", line 1345
ORA-06512: 在 line 2
作业 "SYSTEM"."SYS_EXPORT_FULL_48" 因致命错误于 23:46:43 停止

首先排除并行的问题，尝试去掉PARALLEL进行导出：
[oracle] % expdp system/manager directory=d_output dumpfile=full_bk_2011123101.dmp full=y logfile=full_bk_2011123101.log
Export: Release 10.2.0.1.0 – 64bit Production on 星期六, 31 12月, 2011 23:59:23
Copyright (c) 2003, 2005, Oracle. All rights reserved.
连接到: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 – 64bit Production
With the Partitioning, OLAP and Data Mining options
启动 “SYSTEM”.”SYS_EXPORT_FULL_49″: system/******** directory=d_output dumpfile=full_bk_2011123101.dmp full=y logfile=full_bk_2011123101.log
正在使用 BLOCKS 方法进行估计…
处理对象类型 DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA
ORA-39014: 一个或多个 worker 进程已过早地退出。
ORA-39029: worker 进程 1 (进程名为 “DW01”) 过早地终止
ORA-31671: Worker 进程 DW01 有未处理的异常错误。
ORA-00600: 内部错误代码, 参数: [kcbz_check_objd_typ_3], [8], [0], [32], [], [], [], []
ORA-06512: 在 “SYS.KUPW$WORKER”, line 1345
ORA-06512: 在 line 2
作业 “SYSTEM”.”SYS_EXPORT_FULL_49″ 因致命错误于 00:30:10 停止
看来对于强制打开的这种源数据受损的数据库，数据泵还是都到影响的。尝试使用EXP导出数据库，错误不再出现。看来在极端的情况下，还是最简单的方法最有效。

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

2011年总结

Posted on 2011/12/31 by yangtingkun

2012马上就要到了，抓紧时间总结一下2011年。
2011是比较特殊的一年，是我加入恩墨的第一年，也是我工作的第十年，同时还是我接触Oracle的第十年，而今天的更是我注册到ITPUB的十周年纪念。
大学的专业是通信工程，对于数据库的认识还停留在Foxbase的层面上，到第一家工作单位实习的时候，机缘巧合接触到了Oracle，随后不久在网上搜索资料的时候歪打误撞找到了ITPUB。
我实习的公司就是我工作的第一家公司，以大学学习的那些知识，自然不能满足企业的实际需要，因此从事什么工作完全是公司的安排。当时我和另一个女同学由一个有经验的人带，当时给我们两个方向研究，一个是通过PRO*C程序访问Oracle数据库，另一个是二叉树添加和删除节点的算法。后一个虽然复杂，但是在大学的数据结构的课程中有所涉及，而当时对于Oracle是什么则完全没有概念。显然不能把困难的任务留给女生，于是我就义无反顾的踏上了Oracle这条不归路。
如果说接触Oracle，并将工作重心转到Oracle上是偶然的，那么遇到ITPUB可以说是一个必然。之所以这么说是因为ITPUB很快就发展成为国内最大的Oracle数据库论坛，在业内拥有最大的影响力，因此加入ITPUB只是迟早的事情。虽然注册日期是12月31日，但第一次访问ITPUB肯定是之前的事情，虽然具体的细节早就不记得，但是通过这个注册还是很容易推测当时的场景。在一年快要结束的最后一个工作日里，没有什么心思干活，于是就把常访问的论坛给注册了。应该说在注册这个论坛的时候，已经有了明确的在Oracle方面发展的想法了。
不管出于偶然还是必然，总之Oracle和ITPUB陪我走过了这十个年头。无论是ITPUB还是Oracle，这十年来值得记录的东西都太多太多了。不过好像都和当前的题目不沾边，明明是总结2011，怎么快变成回忆录了。
言归正传，如果要说2011年，那么肯定离不开两个字：恩墨。到了下半年，有了资本的加入，那么还要再加上两个字：云和。不管云和也好，恩墨也罢，今年注定是开花结果的一年。可能对于公司而言，今年只是打好基础，离收获还有一段距离，但是对于技术而言，今年确实是收获的一年。第一次可以把自己几乎所有的知识储备都应用到实际工作中，也是第一次发现自己的知识储备是如此的不足，几乎每天都会碰到新的挑战，几乎每天都会学习新的知识。以前靠每天的BLOG鞭策自己保持学习的惯性，有时候经常需要思考，今天研究什么，BLOG写点什么。而现在每天处理的案例，解决的bug堆成了一堆，就是没有时间整理，到了晚上同样会发愁写点什么，所以有的时候没有选择和选择太多都是痛苦。
BLOG坚持了六年，目前还在继续，能不能继续坚持不是有没有素材可写，而是有没有时间整理了。往年这个时候，肯定会更新一下我的BLOG索引，把去年一年的文章添加进去，目前看是没有这个时间了，连我新的BLOG都没有来得及补充以往的文章，何况是这个BLOG索引了，况且很多索引文章的长度都超过了BLOG所支持的最大长度，如果要再细化，又是巨大的工作量，看看以后能不能想个简单的办法解决这个问题。
今年要比往年啰嗦很多，还是赶紧打住，去帮客户解决问题去了。

Posted in NEWS | Leave a comment

使用Huge Pages后数据库启动失败

Posted on 2011/12/30 by yangtingkun

在配置Huge Pages后，启动数据库反应很慢，数据库无法正常打开。
检查告警日志，发现下面的错误：

Fri DEC 30 13:38:11 2011
Starting ORACLE instance (normal)
****************** Huge Pages Information *****************
Huge Pages memory pool detected (total: 34596 free: 34596)
Memlock LIMIT too small: 67584000000 TO accommodate segment SIZE: 68587356160
Huge Pages allocation failed (free: 34596 required: 32705)
Allocation will continue WITH DEFAULT/smaller page SIZE
**********************************************************

显然这是配置中设置的空间不足所致，手工修改limits.conf文件：

[oracle@hpc ~]$ more /etc/security/limits.conf 
# /etc/security/limits.conf
#
#Each line describes a LIMIT FOR a USER IN the form:
#
#<domain>        <type>  <item>  <value>
#
#Where:
#<domain> can be:
#        - an USER name
#        - a GROUP name, WITH @GROUP syntax
#        - the wildcard *, FOR DEFAULT entry
#        - the wildcard %, can be also used WITH %GROUP syntax,
#                 FOR maxlogin LIMIT
#
#<type> can have the two VALUES:
#        - "soft" FOR enforcing the soft limits
#        - "hard" FOR enforcing hard limits
#
#<item> can be one OF the following:
#        - core - limits the core file SIZE (KB)
#        - DATA - MAX DATA SIZE (KB)
#        - fsize - maximum filesize (KB)
#        - memlock - MAX locked-in-memory address SPACE (KB)
#        - nofile - MAX NUMBER OF OPEN files
#        - rss - MAX resident SET SIZE (KB)
#        - stack - MAX stack SIZE (KB)
#        - cpu - MAX CPU TIME (MIN)
#        - nproc - MAX NUMBER OF processes
#        - AS - address SPACE LIMIT (KB)
#        - maxlogins - MAX NUMBER OF logins FOR this USER
#        - maxsyslogins - MAX NUMBER OF logins ON the system
#        - priority - the priority TO run USER process WITH
#        - locks - MAX NUMBER OF file locks the USER can hold
#        - sigpending - MAX NUMBER OF pending signals
#        - msgqueue - MAX memory used BY POSIX message queues (bytes)
#        - nice - MAX nice priority allowed TO raise TO VALUES: [-20, 19]
#        - rtprio - MAX realtime priority
#
#<domain>      <type>  <item>         <value>
#
 
#*               soft    core            0
#*               hard    rss             10000
#@student        hard    nproc           20
#@faculty        soft    nproc           20
#@faculty        hard    nproc           50
#ftp             hard    nproc           0
#@student        -       maxlogins       4
 
# END OF file
oracle              soft    nproc   16384
oracle              hard    nproc   16384
oracle              soft    nofile  65536
oracle              hard    nofile  65536
oracle              soft    memlock 268435456
oracle              hard    memlock 268435456

不过修改后发现并未生效，启动数据库时现象依旧，错误信息依旧，记得配置这个参数是不需要重启服务器的，不过既然不生效，只好重启一下系统。
系统重启后，数据库启动正常，告警日志输出如下：

Starting ORACLE instance (normal)
****************** Huge Pages Information *****************
Huge Pages memory pool detected (total: 32768 free: 32768)
DFLT Huge Pages allocation successful (allocated: 32705)
***********************************************************

看来memlock参数的修改还是需要重启才能生效。

Posted in ORACLE | Tagged , , | 1 Comment

Database Firewall管理员手册总结

Posted on 2011/12/29 by yangtingkun

最近手头的事情太多，导致文档虽然看完了，还没有动手进行过测试。
Firewall的大部分功能基本上理解了，此外Kamus在公司里面装了一套Firewall在进行测试，因此整个安装和配置的过程也有了一定了解，不过最近实在事情太多，腾不出功夫自己动手，等过一阵闲一点的时候打算深入测试一下Firewall的功能。
虽然目前Firewall在国内的销量还不是很好，但是随着国内企业对于安全性重视程度不断增加，在加上最近各种安全事故频出，相信不久以后，Firewall的市场会有很大的发展，因此现在多做些知识储备可以未雨绸缪。

Posted in BOOKS | Leave a comment

ORA-600(opixrb-4)错误

Posted on 2011/12/28 by yangtingkun

客户环境出现ORA-600(opixrb-4)错误。
错误信息为：

Fri Oct 28 05:50:47 2011
Errors IN file /oracle9/app/admin/bill/udump/bill1_ora_11075632.trc:
ORA-00600: internal error code, arguments: [opixrb-4], [1036], [ORA-01036: illegal variable name/NUMBER], [], [], [], [], []
Fri Oct 28 05:56:44 2011
Errors IN file /oracle9/app/admin/bill/udump/bill1_ora_11075632.trc:
ORA-00600: internal error code, arguments: [opixrb-4], [1036], [ORA-01036: illegal variable name/NUMBER], [], [], [], [], []

这个错误信息比较具体，在MOS上找到明确的说明：ORA-00600 [OPIXRB-4] [1036] While Running A Select Over Dblink With Bind Variables [ID 742106.1]，当数据库是多字节字符集时，通过数据库链使用绑定变量，且绑定变量以:Q或:N结尾，就会碰到这个错误。
可惜的是，对应的TRACE文件已经被清除，无法确认导致问题的具体的SQL语句，不过其他方面还是和这个bug十分相符的。比如这个bug的引入是9.2.0.5，而客户的数据库版本是9206。且客户采用ZHS16GBK，也属于多字节字符集。
对于这个bug，在9i上可以升级版本到9208，10g可以升级到10203，当然，根据bug的描述，修改绑定变量的名称应该也可以避免这个错误的产生。

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

ORA-600(unable to load XDB library)错误

Posted on 2011/12/27 by yangtingkun

AIX上的9206数据库出现这个错误。
在alert文件中发现大量的类似错误：

Mon DEC 19 16:43:13 2011
Errors IN file /oracle9/app/admin/db/udump/db1_ora_15400980.trc:
ORA-00600: internal error code, arguments: [unable TO LOAD XDB library], [], [], [], [], [], [], []

检查对应的TRACE文件，发现是在删除PERFSTAT用户：

/oracle9/app/admin/db/udump/db1_ora_15400980.trc
Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production
WITH the Partitioning OPTION
JServer Release 9.2.0.6.0 - Production
ORACLE_HOME = /oracle9/app/product/9.2.0
System name:	AIX
Node name:	db_1
Release:	1
Version:	6
Machine:	00F64FF34C00
Instance name: db1
Redo thread mounted BY this instance: 1
Oracle process NUMBER: 79
Unix process pid: 15400980, image: oracle@db_1 (TNS V1-V3)
*** SESSION ID:(29.33289) 2011-12-19 16:43:13.766
Dynamic link error: 	0509-022 Cannot LOAD module /oracle9/app/product/9.2.0/lib32/libxdb.so.
	0509-103   The module has an invalid magic NUMBER.
*** 2011-12-19 16:43:13.774
ksedmp: internal OR fatal error
ORA-00600: internal error code, arguments: [unable TO LOAD XDB library], [], [], [], [], [], [], []
CURRENT SQL statement FOR this SESSION:
DROP USER perfstat cascade
----- Call Stack Trace -----
calling              CALL     entry                argument VALUES IN hex      
location             TYPE     point                (? means dubious VALUE)     
-------------------- -------- -------------------- ----------------------------
ksedmp+0148          bl       ksedst               10257BA84 ?
ksfdmp+0018          bl       01FD2604             
kgerinv+00e8         bl       _ptrgl               
kgeasnmierr+004c     bl       kgerinv              000000000 ? 000000000 ?
                                                   1000C5328 ? 1025C36B8 ?
                                                   11031DDC8 ?
sqmtbGetSharedData+  bl       kgeasnmierr          1100062F8 ? 110342E48 ?
0088                                               1025C36C0 ? 000000000 ?
                                                   00000007D ? 00000007D ?
                                                   968DBE1E7339340 ? 000000040 ?
qmtLoadSharedData+0  bl       sqmtbGetSharedData   FFFFFFFFFFFA658 ? 000000000 ?
074                                                000000000 ? 1103453C0 ?
                                                   FFFFFFFFFFF4590 ? 1025C2B78 ?
                                                   000000002 ? 110163730 ?
qmtbInit+00b8        bl       qmtLoadSharedData    110345238 ?
qmtInit+01f8         bl       qmtbInit             7000000BA25FF10 ?
qm_init_sga_pass1+0  bl       qmtInit              1100062F8 ?
13c                                                
qm_init_uga+0138     bl       qm_init_sga_pass1    
qmtsDropUser+0130    bl       qm_init_uga          
kzdukl+25d4          bl       qmtsDropUser         11031D636 ? 8000000000008 ?
                                                   24B0000024B ?
kzudrp+023c          bl       kzdukl               11031D4C8 ?
opiexe+2800          bl       kzudrp               3500000035 ?
opiosq0+0ae0         bl       opiexe               410320340 ? FFFFFFFFFFFC378 ?
                                                   FFFFFFFFFFFA658 ?
kpooprx+0174         bl       opiosq0              000000004 ? 000000002 ?
                                                   000000000 ? 000000001 ?
kpoal8+033c          bl       kpooprx              FFFFFFFFFFFC5E4 ?
                                                   FFFFFFFFFFFC378 ?
                                                   1A0000001A ? 100000001 ?
                                                   000000000 ? 24000000000024 ?
                                                   080000000 ? 000007FFF ?
opiodr+08e8          bl       _ptrgl               
ttcpip+0c54          bl       _ptrgl               
opitsk+0c28          bl       ttcpip               11000D210 ? 000000000 ?
                                                   000000000 ? 000000000 ?
                                                   000000000 ? 000000000 ?
                                                   000000000 ? 000000000 ?
opiino+0798          bl       opitsk               000000000 ? 000000000 ?
opiodr+08e8          bl       _ptrgl               
opidrv+032c          bl       opiodr               3C77616974 ? 4101C7438 ?
                                                   FFFFFFFFFFFF6C0 ? 000000001 ?
sou2o+0028           bl       opidrv               3C00000005 ? 44043C000 ?
                                                   FFFFFFFFFFFF6C0 ?
main+0138            bl       01FD2328             
__start+0098         bl       main                 000000000 ? 000000000 ?
--------------------- Binary Stack Dump ---------------------

显然导致这个ORA-600错误的主要原因是Dynamic link error，在详细TRACE文件中也体现了这一点。
查询MOS发现这是AIX上环境变量设置不当所致，详情可以参考文档While Running catupgrd.sql On AIX: ORA-00600 [unable to load XDB library] [ID 759401.1]。虽然当前并不是在执行升级操作，但是导致问题的原因是相同的。
由于环境变量LIBPATH中，64位的library路径应该在32位之前，而当前环境中的配置是相反的，这就造成了Oracle需要读取对应的library时，出现动态连接错误。
解决方法就是改变当前错误的配置，首先关闭数据库，然后unset LIBPATH和LD_LIBRARY_PATH，重新设置export LIBPATH=$ORACLE_HOME/lib:$ORACLE_HOME/lib32，然后重启数据库，重新执行报错的命令或脚本即可。

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

ORA-600(17087)错误

Posted on 2011/12/26 by yangtingkun

客户数据库出现这个ORA-600错误。
错误信息为：

Mon Jun 28 10:27:07 2010
Errors IN file /oracle/admin/ccicdb/udump/ccicdb_ora_767494.trc:
ORA-00600: internal error code, arguments: [17087], [0x70000076C3E8E90], [], [], [], [], [], []

检查MOS发现，这是10.2.0.3上和CURSOR有关的bug，详情可参考文档Bug 7706062 – OERI [17087] following concurrent hard parses on same cursor [ID 7706062.8]。
当存在大量并发同一个cursor的硬解析存在时，可能会导致library cache lock的不一致状态，而当前数据库存在的主要问题之一就是大量的硬解析。
显然导致这个问题的原因就是大量硬解析造成的，除了修改程序代码减少硬解析这个方法外，数据库版本升级到10.2.0.5也可以避免这个ORA-600错误的产生。

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