遭遇Oracle11gR2 ASM文件无法扩展的Bug

在一个11gR2+ASM的环境中,因为产生了大量归档,导致控制文件需要扩展,结果数据库报错:

Errors in file /opt/oracle/diag/rdbms/test/test/trace/test_arc0_11146.trc:
ORA-00202: control file: '+DATA/control01.ctl'
ORA-17505: ksfdrsz:1 Failed to resize file to size 1920 blocks
ORA-15061: ASM operation not supported [41]
Control file expansion from 1600 blocks to 1920 blocks denied by OS

这是ASM的一个bug 8898852,可以在Oracle Support上找到对应的小patch,经过验证可以解决该问题。该patch已经包含在前两天刚发布的ASM的PSU中,只需要安装该PSU即可。

从目前我们使用11gR2的一些经验来看,bug还是比较多,尤其是一些影响比较大的bug,还是让人对11gR2无法完全放心,只能在特定的环境,和有足够容错方案的环境中,才能冒着风险来试用。

除了这个ASM文件不能扩展,有几个从10.2.0.4升级到11.2.0.1的库,在switchover中碰到了两次ORA-600 [ktbdchk1: bad dscn],出现问题后无法执行DML,非常严重的一个问题,并且暂时还没有好的办法解决,只能通过重建有问题的表的方式绕过,因为两次都是在切换后出现,初步推断是Active Data Guard带来的bug,开了SR和Oracle扯了很久,还在继续研究中。

据说Oracle 11.2.0.2将在年中发布,希望这个新的版本能更稳定些吧。

4月份,Oracle11.2.0.1的PSU和ASM(Grid Infrastructure)的第一个PSU都已经发布了,如果需要在产品环境中使用,建议这些PSU都打上吧

Oracle Database PSU Unix Patch Comments

11.2.0.1.1

Patch 9352237

11.2.0.1.1 for GI

Patch 9343627

11.1.0.7.3

Patch 9352179

11.1.0.7.2 for CRS

Patch 9207257

Released in January 2010

10.2.0.4.4

Patch 9352164

10.2.0.4.4 for CRS

Patch 9294403

注:该表格摘自My Oracle Support Note: 854428.1l

Oracle 11gR2 for Linux正式发布

呵呵,一大早的很多人已经在谈论这个话题了,Oracle11.2.0.1已经正式发布,并且linux版本已经可以从OTN下载。从2007年上海Oracle Open World上开始了解到不少Oracle11g的新特性开始,到现在已经过去整整两年。一般来说,Oracle新版本的第一个版本,很少有人会用在生产系统中,R2版本才是真正值得期待的Oracle11g,或许很快就能看到有人在讨论生产系统中的Oracle11g了。

OTN上的下载地址(一共两个disk,2.1GB,又是个大家伙):
Oracle11g R2 for linux x86
Oracle11g R2 for linux x86_64

Oracle11gR2文档可以从这里下载,也可以到这里在线看。相比软件,文档的提供应该更加让人激动,接下来可以花点时间来看看了。除了之前已近广为流传的新特性,Oracle11.2.0.1还包含了一个反安装工具Oracle De-install Utility (11.2.0.1.0),嗯,不错。

正在争取今年旧金山的Oracle Open World的机会,希望10月份可以去感受一下Oracle11gR2带来的震撼。

rebuild index online的锁机制浅析(续)

上一篇文章介绍了Oracle10.2.0.4中rebuild index online的锁机制,在开始和结束的时候需要对表加一个模式为4的TM锁,导致在这两个时刻会短暂的阻塞DML。到了Oracle11g,这种情况有所变化,还是通过同样的实验来观察一下Oracle11g到底做出了怎样的改进,对于DBA来说又有怎样的好处。实验环境为Oracle11.1.0.6

session 1:

SQL> delete from t where object_id=28;

1 row deleted.

session 2:

SQL> alter index ix_t rebuild online;

session 2同样被挂起,查看v$lock:

SQL> select sid,type,id1,id2,lmode,request from v$lock where type in('DL','TM','TX'); 

       SID TY        ID1        ID2      LMODE    REQUEST
---------- -- ---------- ---------- ---------- ----------
       137 DL      13596          0          3          0
       137 DL      13596          0          3          0
       137 TX     458781        377          0          4
       170 TM      13596          0          3          0
       137 TM      13596          0          2          0
       137 TM      13599          0          4          0
       170 TX     458781        377          6          0
       137 TX     524304        402          6          0

其中170为session 1,137为session 2。可以看到session 2正在请求一个模式为4的TX锁,注意和Oracle10.2.0.4请求的TM锁是不一样的,而且在我们以前的概念中,TX锁的模式都是6,这里出现了模式4的TX锁请求,应该是Oracle11g中新引入的。那么模式4的TX锁和TM锁有什么不同呢?我们继续前面的实验步骤:

session 3:

SQL> delete from t where object_id=46;

1 row deleted.

session 3的DML操作顺利完成,没有被阻塞。而在10g当中,session 3是会被session 2请求的TM锁所阻塞的,这一点改进是非常有意思的,这样即使rebuid online操作被session 1的长事务阻塞,其他会话的DML操作,只要不和session 1冲突,都可以继续操作,在Oracle10g及以前版本中的执行rebuild index online而造成锁等待的风险被大大的降低了。

接下来在session 1执行rollback,观察rebuild index online执行期间的锁的情况,136是session 3:

       SID TY        ID1        ID2      LMODE    REQUEST
---------- -- ---------- ---------- ---------- ----------
       137 DL      13596          0          3          0
       137 DL      13596          0          3          0
       137 TM      13596          0          2          0
       137 TM      13599          0          4          0
       136 TM      13596          0          3          0
       136 TX     327684        414          6          0
       137 TX     524304        402          6          0
       137 TX     524321        402          6          0

等待一段时间,rebuild index online临近结束,再次观察锁的情况:

       SID TY        ID1        ID2      LMODE    REQUEST
---------- -- ---------- ---------- ---------- ----------
       137 DL      13596          0          3          0
       137 DL      13596          0          3          0
       137 TX     327684        414          0          4
       137 TM      13596          0          2          0
       137 TM      13599          0          4          0
       136 TM      13596          0          3          0
       136 TX     327684        414          6          0
       137 TX     524304        402          6          0

可以看到session 2又在请求一个模式为4的TX锁,同样的,这个锁也不会阻塞其他的DML。由于session 3的事务没有提交,session 2被阻塞,这时再将session 3执行提交或者rollback,则session 2的rebuild立即完成。

Oracle11g在很多细节方面确实做了不少的优化,而且像这样的优化,对于提高系统的高可用性的好处是不言而喻的,在Oracle11g中,执行rebuild index online的风险将比10g以及更老版本中小得多,因为从头至尾都不再阻塞DML操作了,终于可以算得上名副其实的online操作了。

Oracle11g部分新特性移植到9i和10g

Oracle10.2.0.4出来的时候包含了属于Oracle11g的新特性Real Application Testing,现在,通过patch,可以在9i~10g各版本中获得包括SQL Performance AnalyzerDatabase Replay在内的Oracle11g新特性。

SQL Performance Analyzer可用于诊断由于系统改变等引起的SQL性能问题,通过在做出改变前后收集一个性能统计报告,然后比较得到性能改变的主要原因。

Database Replay则可以捕获产品数据库的压力等,在测试数据库中进行重演,可以更加准确的模拟产品库的压力对应用进行测试,这也是Oracle11g主推的Real Application Testing的主要功能。

要获得这两个新特性,需要安装Patch,对应的Patch请参考:Metalink Note:560977.1

无觅相关文章插件,快速提升流量