Oracle 10g ASM 的一点经验

Oracle 10g 的 ASM (自动存储管理) 真是一把双刃剑，对于存储的管理给 DBA 带来了不少便利，可也存在无穷多的问题。

ASM_POWER_LIMIT 参数

这个参数 ASM_POWER_LIMIT 参数控制 ASM 后台进程 ARBx 的数量。ARBx 进程用来进行 ASM 磁盘数据重新分布打散。ASM_POWER_LIMIT 取值从 0 到 11(据说从 10gR2 开始可以设置为 0 ). 当新添加磁盘或者删除磁盘后，ASM 会启动 ARBx 进行 IO 分散操作，这是个非常消耗资源的动作，所以一定要选择系统空闲的时候进行。

关于 ASM 的条带与分配单元

ASM 默认的 Stripe Size 为 128K。 (一般操作系统的一个 IO 最大是 1M，对于 Block Size 为 8K 的系统，一般来说，db_file_multiblock_read_count 设置为 16 即可)。分配单元（ Allocation Unit ）是 1M，这个 AU 对应 extent 。在一些 DW 环境，随着数据量增大，AU 会非常的多，会产生性能影响。Stripe Size 和 AU 是可以通过 ASM 实例上的两个隐含参数调整的：

_asm_ausize
_asm_stripesize(注意最大1M，否则会有负面影响)

磁盘组不能 mount

错误信息类似如下：

ORA-15063: ASM discovered an insufficient number of disks for diskgroup "FOO"

这个问题是因为设备 PVID 导致的，一般可以通过如下三个方法解决：

对磁盘组中的设备进行 dd 操作抹去磁盘 0 块的内容
用 FORCE 选项把磁盘添加到其他磁盘组中。
用 FORCE 选项用所有这些磁盘创建新的磁盘组。

哪一种方式都有风险，操作需要谨慎。
–EOF–

MT 4 Beta 版经验

今天将 dbanotes.net 所用的 Movable Type 从 Beta 2 升级到了 Beta 5 测试了一下，遇到了大小毛病都有，不得不退回来。有些怀疑这个 MT 4 将会是一个比较失败的版本。

插件目录的变化

Beta 5 要求插件必须在 Plugins 目录下的子目录下，不允许脚本直接裸奔在插件目录下了。Beta 3 和 4 我没有还用过。不知道是从哪一个版本发生的变化。当然，这个变化不是问题，问题是即使这样设置了，很多插件仍然识别不到。包括 relatedkeyword.pl 插件。这个插件虽然简单，但却是我原来 Blog 不可或缺的。

更新导致的数据库错误

如果重复运行了升级操作，似乎就有这个问题:

lib/MT/Author.pm line 337

可以参考论坛上提供的修改数据库的解决办法。

Media Manager 插件不兼容

因为 Media Manager 不兼容会带来如下错误信息：

Unknown action mm_entry_edit

这个插件作用不大，直接删掉。

Updated: 测试了一下最新的 Beta 6 ，又回滚了
Beta 6 还是有新问题。MTinclude 后面的模块名字中间不能有空格。
–EOF–

网站统计系统–中国雅虎新产品

中国雅虎站长工具又将新增一个产品：统计系统。

上手比较简单，只需要添加站点的相关述即可获取一段 JavaScript 脚本，把这段脚本粘贴到自己 Blog/页面模版中。稍后片刻即可看到数据了，数据更新还是比较及时的。数据展现的纬度也比较多，有些数据也是直接针对中文用户而展现的(比如 PV 与 IP 单独的统计与对比)，从这一点来说，倒是比 Google Analysis 更为贴近用户。

统计数据可以选择是否公开，如果公开的话，还可以接受留言，这是个很讨好用户的功能，促进个人站长之间的互动。

刚开始使用，参见 Blog 右下角的小图标不少功能还没有完全体验到。回头再和大家交流一下经验。

–EOF–

DRBD 提升了 MySQL 的集群能力

前几天 MySQL 站点上有个为期 12 天以 Scale-Out 为主题的活动，列举了不少成功的案例，每个页面有下方的这个图很引人注意：

注意到主备服务器之间的 HA 是通过 DRBD(Distributed Replicated Block Device)做到的。DRBD 号称是 “网络 RAID”，开源软件，由 LINBIT 公司开发，MySQL 与 LINBIT 达成了合作关系，大张旗鼓的搞了这个 “12 天 Scale-Out” 活动也是这个商业合作驱动的吧。DRBD 助力 MySQL, 号称可以得到四个 9 的可靠性，这不低于任何一款商业数据库软件了。

DRBD 的出现的确对 MySQL 集群的可用性有很大提高。而且，有独到的特点，非常适合面向互联网的应用。因为是在存储层的数据块同步，很容易的做到应用层的 IO 负载均衡(备机承担一定的读压力)，不但支持数据库失败接管，还能做到 IP 失败接管，接管时间小于 30 秒，真是穷人的绝佳集群解决方案(相比 Oracle 下的一些方案，比如 eBay 采用的方案，性价比还是不错的)。国外已经有很多成功的实现案例，国内的 Web 2.0 站点不知道是否已经有人在用，在这里推荐一下。更为有趣的是，已经有人通过 DRBD 来实现 Oracle 的另类集群。

怪不得前一阵子已经有开源爱好者开始宣称类似 “RAID即将成为过去式” 的激进言论。

–EOF–