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

2010年04月26日 by 1 Comment

在一个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

Filed under 技术 Tagged with , , ,

linux上大量tcp端口处于TIME_WAIT的问题

2010年04月21日 by 1 Comment

最近发现几个监控用的脚本在连接监控数据库的时候偶尔会连不上，报错：

 Couldn't connect to host:3306/tcp: IO::Socket::INET: connect: Cannot assign requested address

查看了一下发现系统中存在大量处于TIME_WAIT状态的tcp端口

$netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
TIME_WAIT 50013
ESTABLISHED 27
SYN_RECV 1

由于要监控的主机太多，监控的agent可能在短时间内创建大量连接到监控数据库(MySQL)并释放造成的。在网上查阅了一些tcp参数的相关资料，最后通过修改了几个系统内核的tcp参数缓解了该问题：

#vi /etc/sysctl.conf

net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1

#sysctl -p

其中：
net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。

修改完成并生效后，系统中处于TIME_WAIT状态的tcp端口数量迅速下降到100左右：

$netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
TIME_WAIT 82
ESTABLISHED 36

简单记录于此，备忘。

Filed under 技术 Tagged with

数据库技术大会PPT：构建高可用数据库监控系统

2010年04月04日 by 8 Comments

这两天在北京参加IT168组织的2010数据库技术大会，应该说这次大会非常的成功，场场爆满。见到了很多老朋友，认识了更多的新朋友，不亦乐乎。

今天下午第一场，我分享了一个关于数据库监控系统的topic，开场时话筒出现了些小插曲，加上发现PPT不是我后来提交给大会的最新版本，当时就有点发懵，汗就开始往外冒了。看来以后要多多练习提高演讲的水平和临场的应变控制能力了。希望我结巴的话语不至于让大家感到门票白买了。就数据库监控这个话题本身而言，我相信大部分DBA应该都是有兴趣，并且也是有自己的一些心得的，因此，我带来这个主题，一个重要的目的，是希望能起到抛砖引玉的作用，希望能有更多的DBA能去关注这方面，并且一起交流分享如何把数据库监控做到极致。如果有对数据库监控感兴趣，有想法的朋友，也非常的欢迎来杭州，和我们一起来把这个产品做得更好，或许真有一天能做成产品开源出来也是可能的。

下面是新版本的PPT，和大会上大家看到的可能有一点区别，大家如果对数据库监控有什么建议，欢迎指教。

构建高可用数据库监控系统
View more presentations from NinGoo.

Filed under 技术 Tagged with , ,

Cassandra Commitlog

2010年03月01日 by Leave a Comment

上一篇blog中，大致介绍了一下Cassandra的存储机制，通过将最新的写操作放在内存中的Memtable，然后定期刷新到磁盘持久化为SSTable，Cassandra将随机写操作转换成了顺序写操作，这可以提升IO性能。

最新写入的脏数据是在内存Memtable表中，因此必须有机制来确保异常情况下，能够将内存中的数据恢复出来。和关系型数据库系统一样，Cassandra也是采用的先写日志再写数据的方式，其日志称之为Commitlog。

和Memtable/SSTable不一样的是，Commitlog是server级别的，不是Column Family级别的。每个Commitlog文件的大小是固定的，称之为一个Commitlog Segment，目前版本(0.5.1)中，这个大小是128MB，这是硬编码在代码(src\java\org\apache\cassandra\db\Commitlog.java)中的。当一个Commitlog文件写满以后，会新建一个的文件。当旧的Commitlog文件不再需要时，会自动清除。

每个Commitlog文件(Segment)都有一个固定大小（大小根据Column Family的数目而定）的CommitlogHeader结构，其中有两个重要的数组，每一个Column Family在这两个数组中都存在一个对应的元素。其中一个是位图数组(BitSet dirty)，如果Column Family对应的Memtable中有脏数据，则置为1，否则为0，这在恢复的时候可以指出哪些Column Family是需要利用Commitlog进行恢复的。另外一个是整数数组(int[] lastFlushedAt)，保存的是Column Family在上一次Flush时日志的偏移位置，恢复时则可以从这个位置读取Commitlog记录。通过这两个数组结构，Cassandra可以在异常重启服务的时候根据持久化的SSTable和Commitlog重构内存中Memtable的内容，也就是类似Oracle等关系型数据库的实例恢复。

当Memtable flush到磁盘的SStable时，会将所有Commitlog文件的dirty数组对应的位清零，而在Commitlog达到大小限制创建新的文件时，dirty数组会从上一个文件中继承过来。如果一个Commitlog文件的dirty数组全部被清零，则表示这个Commitlog在恢复的时候不再需要，可以被清除。因此，在恢复的时候，所有的磁盘上存在的Commitlog文件都是需要的。

参考文章：
[1].http://wiki.apache.org/cassandra/ArchitectureCommitLog

Filed under 技术 Tagged with , ,