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