在项目上线之前,我们都面临着数据库版本的选择,看似简单,但绝不仅仅是找个数据容器将数据放进去就可以了,如果没有使用合适的版本,可能留下无穷的后患。下面说说我最近碰到的几个例子:
开发人员要求我将一个生产库上的数据导出一份到开发测试库,非常小的数据量,才400M不到,想着这还不简单,直接exp搞定,于是随敲个指令:
exp ZDB/ZDB file=/tmp/user1.dmp owner=user1
……
开始很正常,但导出到一个表的时候报错:
About to export specified tables via Conventional Path …
EXP-00006: internal inconsistency error
EXP-00000: Export terminated unsuccessfully
[oracle@server1 ~]$
于是尝试专门针对这个表的导出:
[oracle@server1 ~]exp ZDB/ZDB file=/tmp/TBL_ACCOUNTINGBOOKS.dmp tables=ZDB.TBL_ACCOUNTINGBOOKS
Export: Release 11.2.0.1.0 – Production on Mon Nov 10 15:07:41 2014
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 – 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Tes
Export done in AL32UTF8 character set and AL16UTF16 NCHAR character set
About to export specified tables via Conventional Path …
EXP-00006: internal inconsistency error
EXP-00000: Export terminated unsuccessfully
重复了几次,每次都报错,而这个表是分区表,怀疑是不是11G的exp对分区表的支持有问题,查了下,果然发现一个BUG:7834212。该BUG在11.1.0.7和11.2.0.1上可能会发生。Oracle给出的解决方案是1)升级到更高版本;2)使用expdp。
无奈,11.2.0.1本身在生产库上应用非常罕见,前人挖下的坑也只能接受,exp不行了,但没关系,还有expdp呢,一样用expdp轻松搞定你,于是尝试使用expdp导出数据:
expdp ZDB/ZDB dumpfile=ZDB.dmp directory=expdir schemas=ZDB
一按回车,去泡了杯茶回来,想象应该完成得差不多了吧,才400多M数据而已,但出乎意料,屏幕在缓慢的移动着,不正常!!可能就是慢,或许有些什么负载吧,一会就好了。于是去忙点别的事情,半个小时后,1个小时候忙完了别的事情,再回头看看:
还没完,太不对劲了,400M的数据量而已,开什么玩笑,系统资源看看,cpu60%的idle,系统并不忙啊。查查等待,一直在等待:wait for unread message on broadcast channel,这是一个很常见的空闲等待,每次等待时间是标准的1S,如果进程没干活的时候等待这个很正常,但放在这种情况,绝对有问题,10有8,9又是BUG。
果然,Oracle在11.2.0.1上expdp缓慢的原因非常多,例如BUG17365043:
Bug 17365043 “STREAMS AQ: ENQUEUE BLOCKED ON LOW MEMORY” WHEN REDUCING STREAMS_POOL_SIZE,
以下是这个触发这个BUG时对expdp做的trace(摘自Oracle):
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
—————————————- Waited ———- ————
wait for unread message on broadcast channel
698 1.00 684.41
Disk file operations I/O 2 0.00 0.00
Streams AQ: enqueue blocked on low memory
21 60.00 1201.93
这个情况跟我们的差不多,解决办法为:
1) 重启DB临时解决;
2) 手动指定stream_pool_size大小;
3) 升级到更高版本或者查找是否有可以应用的patch。
还有可能是这个BUG:
Bug 8774047 – EXPDP NEVER FINISHED WITH “WAIT FOR UNREAD MESSAGE ON BROADCAST CHANNEL
closed as duplicate of unpublished
Bug 6236862 – POOR PLAN FOR SQL WITH ROWNUM (OR FIRST_K_ROWS) WITH PARTITION EXTENDED NAMING
对于这个BUG的修复,只能通过升级解决。
在这个例子中,本来几分钟完成的任务,足足花掉了3个小时。
再想想之前有一次在夜晚维护的时候出现过实例异常shutdown的情况,后台日志当时报错:
ORA-00600: 内部错误代码, 参数: [1433], [60], [], [], [], [], [], [], [], [], [], []
GEN0 (ospid: 13815): terminating the instance due to error 495
这也是触发了Oracle的BUG-8879271(Bug 8879271 – GEN0 produces ORA-600[1433]
)导致数据库异常宕机,幸好当时是在半夜,没有造成损失。
这个BUG已在11.2.0.2中被修复。
其实数据库版本的选择,并没有很多的技术含量,但需要一些专业常识。Oracle的每一个大版本刚刚推出的时候,充斥着诸多BUG,这种版本作为一些技术爱好者的测试环境用于研究不错,但是不适合应用在生产环境。Oracle在未来的几年中会不断将其中发现的BUG进行修复,推出patchset,这些patchset往往被称为x.x.0.2,x.x.0.3…x.x.0.n,所以在生产环境中,我们只建议使用patchset,这些是相对比较稳定的版本,比如:10.2.0.4、10.2.0.5、11.2.0.3、11.2.0.4都是可以考虑的选择。
未经允许不得转载:SRE空间 » 关于数据库版本的选择
评论前必须登录!
注册