Tag Archives: 10g

Oracle In-Memory Undo

今天在无聊的售前演示中看完了一篇技术文档 All About Oracle’s In-Memory Undo，关于 Oracle 的 In-Memory Undo (IMU)，记得几年前讨论过，大部分基于猜测，这算是看到的第一篇比较细致的东西。

Oracle 公司在 10g 推出 IMU 这个特性（已经申请了专利）。Undo 作为最重要的组成部分之一，其高效与否直接关系到整个 DB 的能力。Undo 旧有的基于 Block 的段(Segment，指存储层的概念)管理模式方式，UNDO 本身的变化要记录到 Redo Log Buffer 里，而 IMU 避免了这个操作(因为是内存而不是存储)，从而减小了生成的 Redo 量。

另外，因为读一致性开销直接到了内存里而不再依赖存储段, 整体也大大降低，CPU 的负荷也会有效降低。其应用模式应该说是适合一致读的需求量比较大的 OLTP。

Oracle 10g 默认是使用 IMU 这个特性的。通过隐含参数 _in_memory_undo 可以关闭这个特性。因为是隐含参数，也侧面反映出该特性并非那么成熟。搜索一下 Metalink，有不少关于 IMU 的 Bug，而 UNOD 的 Bug 一旦遇到，不停 DB 恐怕都很难解决。所以，对于可用性要求比较高的系统，现在起用该特性还是需要三思。

附: 全部机制在专利全文里。谁有兴趣仔细读一下吧.

–EOF–

Oracle 10g PatchSet 10.2.0.4

从 Laurent Schneider 的 Blog 看到信息，Oracle 10gR2 的第三个 PatchSet 10.2.0.4 已经出来了。虽然还没有正式宣布，但是在 Metalink 上已经能够看到 Linux 平台的了。PatchSet 号码为：6810189 。

现在 Oracle 的 PatchSet 出来的顺序基本上还是 Linux 是第一个，也反应了某种趋势。若干年前都是 Solaris 平台上最早出来的，现在都变成 Linux 了，操作系统的流行变迁可见一斑。原来传言说 2007 年年底会发布的，还是拖到了现在才看到，难道 Oracle 的开发力量都投入 11g 上面去了?

有意思的是，10.2.0.4 Patch Set – List of Bug Fixes by Problem Type 这个列表下仍然写着 “Please note that 10.2.0.4 has not been released on any platform , and does not have release dates available” 。可见 Oracle 内部对文档的更新也是比较乱的。

期待这个版本在修复众多 Bug 的同时不要引入新的 Bug 了，Oracle 10g 在稳定性上还是不能让人放心，淘宝的兄弟们最近就因为 ASM 的 Bug 而折腾了一回。。11g 会好一些么?

对于 DBA ，尤其是 Oracle DBA 来说，厂商发布一个新的 PatchSet 要比发布一个新的版本来的更为实惠一些，因为前者面向解决现有存在的 Bug 问题。新的版本只会引入更多的问题。

–EOF–

About Oracle 10g/11g AWR

Oracle 10g 开始引入了AWR (Automatic Workload Repository). Oracle 建议用户用这个取代 Statspack。不过这个需要注意的是使用 AWR 需要有 Diagnostic Pack License。Oracle 后来推出了一个解决方案可以禁止掉该特性。

在 Note. 436386.1 有说明:

SQL> @dbms_awr.plb

然后执行：

dbms_awr.disable_awr();

如果用 sys 之外的用户创建 AWR 报告，则需要进行合适的授权。否则会报告错误 PACKAGE 执行错误。

CONNECT / AS SYSDBA;
GRANT ADVISOR TO foo;
GRANT SELECT_CATALOG_ROLE TO foo;
GRANT EXECUTE ON sys.dbms_workload_repository TO foo;

要注意 Bug 4597354 在创建基线数据的时候，对性能有很大影响。在一个非常繁忙的系统上不要进行此操作。

如果结合企业管理器用 AWR 是很方便的，如果用手工方式收集性能数据，多了很多可供调整的地方，是更加方便了呢？还是更加麻烦了?

–EOF–

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–