6、ASM（自动存储管理）

6.1. ASM Fast Mirror Resync

在10g的ASM中如果因为某些硬件故障（比如接口线，比如光纤卡，比如电源）导致Diskgroup中的某些磁盘无法正常读取，这些磁盘将处于offline状态，在offline之后不久ASM就会把这些磁盘从Diskgroup中删除，并且尝试利用冗余的extent来重新在其它磁盘中构建数据，这是一个比较耗时且耗资源的操作。当我们修复了磁盘，再将它们重新加回磁盘组中，又将是另外一次的数据重整操作。如果我们仅仅是例行的维护硬件，因为磁盘中的数据并没有真正的损坏，我们只是将磁盘取出来过一会儿再加回去，那么这样的两次数据重整操作无疑是没有必要的，在11g中ASM的Fast Mirror Resync功能允许我们设置磁盘的repair时间，在repair时间内ASM将不会尝试在磁盘间重新分配extent。

ALTER DISKGROUP dgroup SET ATTRIBUTE 'DISK_REPAIR_TIME'='3H';

上述命令可以设置当磁盘组dgroup中的磁盘失效和重新有效之间的时间在3小时内的话，ASM就不会重新构建extent，当磁盘重新有效之后，ASM需要做的只是将这3小时内更改的extent重新同步到刚才失效的这些磁盘中就可以了。

6.2. ASM Preferred Mirror Read

我们知道在10g中ASM总是会去读取Primary extent，这样做的目的是为了更好的分散IO，但是在某些环境中，一个ASM磁盘组中的磁盘对于某一个特定的节点来说，有些是Local Disk而有些则是Remote Disk，从Remote Disk中读取数据效率会低于Local Disk，但是在10g中我们无法要求从哪组磁盘中读取数据，在11g中新增的ASM_PREFERRED_READ_FAILURE_GROUPS参数帮助我们完成了这个功能。给每个实例设置优先读取的Failure Group就可以了。

6.3. ASM扩展性的增强

对于外部冗余（External redundancy），ASM可以最大支持到140PB了，而在10g中这个数字仅仅是35TB。

?

7、Server Result Cache

Cache始终是提升性能的重要技术， 在Oracle 11g中增加了一种Server Result Cache, MySQL的Query Cache是根据SQL的文本来匹配的， 只有Query的文本一模一样时才可以共享， 而Oracle的Server Result Cache则只要执行计划一样或部份一样， 并且生命周期一样， 则就可以共享了。 当下面的表数据改变了， Oracle会自动清除这个Cache, 以确保查询结果的正确性。 在以读为主要的系统中， 宣称性能可以提升一倍。

这块内存从SGA中分配， 由RESULT_CACHE_MAX_SIZE控制。 Oracle允许你在系统， 会话， 表和语句级（Hint:result_cache）控制是否使用Server Result Cache技术。 Oracle提供一个PL/SQL包及相应视图来管理这个Cache区域。

对于同样的操作，如果能在多个process或者session间共享结果，对于性能优化自然是非常有帮助的。从oracle7开始提供的share pool，可以让同样的SQL可以解析一次，执行多次，有效的减少了多个session执行相同SQL语句时的硬解析，如果应用很好的使用了绑定变量，那么共享SQL对于系统整体性能的提升是不言而喻的。

那么，除了能共享SQL和执行计划，还能共享什么？直接共享SQL执行后的结果，使得相同或者部分相同的SQL语句甚至只需要执行一次，以后再次执行时就直接得到结果？没错，Oracle11g的新特性Server Result Cache就能提供这样功能。Oracle在白皮书上宣布，对于读频繁的系统，通过该特性，甚至有可能提升系统性能200%，对于大量报表的数据仓库项目来说，这个特性应该是一个不错的消息。

Server Result Cache通过在SGA中分配一个缓冲区来保存查询结果，Oracle引入了一个新的初始化参数来控制这个cache的大小：result_cache_max_size。可以在system、session、table或者语句级别来设置cache的使用。在语句级可以使用一个新的hint来控制是否缓存查询结果。另外，Oracle还提供了一个新的PL/SQL用来监控和管理Server Result Cache，比如可以清空整个cache的内容或者清空某个查询的结果，也可以生成cache的使用报告等。

既然使用了cache，自然会有cache查找和cache数据清除算法的问题。估计查找还会是通过hash算法，这样还需要引入几个相关的latch。Cache中的数据，也应该是通过LRU或者类似LRU的算法来管理其生命期。

Server Result Cache不仅仅能缓存整个查询的结果，也能缓存查询中某部分操作的结果，比如缓存一次排序的结果，就可以避免再次执行时的排序操作。对于一些比较耗资源的查询操作，缓存结果应该能很好的提升性能。

通过在服务端和客户端引入对于查询结果的缓存机制，Oracle11g或许能极大的提高查询性能。对于一些读比较频繁的系统，比如数据仓库应用，Oracle11g或者更值得期待。

?

8、提升性能 Consistent Client Cache

Cache始终是提升性能的重要技术。 除了在前面讲的Server Result Cache, Oracle 11g还增加了一种Client Cache. 这是一种在Oracle Client端的缓冲技术， 通过将中间结果或整个表缓冲在客户端， 当客户端发出查询请求时， Oracle可以直接在这个缓冲区中返回记录， 而不需要去和数据库打交道， 可以大大地着少和服务器端的网络来回， 降底服务器上的SQL调用， 根据Benchmarks测试， 对于只读或极少更新的表， 总的消耗时间可以降低500%, 而服务器上的CPU时间可以降低200%.

通过OCI接口，在Client端也可以缓存查询结果。典型的场景就是我们在应用服务器端缓存查询结果，这样在前端执行该查询时，甚至不需要到数据库中去执行该查询。客户端结果缓存在OCI进程中，可以被该进程中的多个session或者线程共享。

要使用这个Cache功能， 也很简单， 首先要使用Oracle 11g的OCI客户端， 如： JDBC-OCI, ODBC, ODB.NET, PHP, Perl等， 无须要去更改现有的程序代码； 其次需要在数据库端指定CLIENT_RESULT_CACHE_SIZE参数来指定这一块Cache的大小， 如果为0则表示禁用。 当该参数大于0时，该特性被启用，同样的，该特性也可以在system、session、table或者语句级来设置。通过在服务端设置参数而不是客户端设置，可以集中的管理该特性，但是也可以在各个客户端单独进行设置，客户端的设置将覆盖服务端的设置。

?

9、如何使用ADRCI

9.1.关于 ADR Command Interpreter （ADRCI）

一个存放数据库诊断日志、跟踪文件的目录，称作ADR base，对应初始化参数DIAGNOSTIC_DEST，如果设置了ORACLE_BASE环境变量，DIAGNOSTIC_DEST等于ORACLE_BASE，如果没有设置ORACLE_BASE，则等与ORACLE_HOME/log。

关于ADRCI:ADRCI Command-Line Utility 命令行工具，使用该工具查看ADR中的日志和跟踪信息，查看健康报告；还可以将相关错误日志和信息打包成zip文件，以便提供给oracle support分析。在ADRCI工具中可以执行很多命令，另外可以象sqlplus一样执行脚本。

9.2.开始使用ADRCI

9.2.1运行ADRCI，$ORACLE_HOME/bin/adrci

代码：

[root@ractest ~]# su - oracle

[oracle@ractest ~]$ which adrci

~/11g/bin/adrci

[oracle