十二
31
再过1小时，2008年就要过去了。
别了，2008
这一年里，发生了太多的事。
咱平民小百姓，不谈国家大事。谈谈自己的就好了。
2008年，在成都安定了下来。上班搞自己喜欢搞的ORACLE，下班回家陪陪父母、老婆和孩子。这日子，挺不错。
2009年，我会干什么呢？大家都会说计划没有变化快。看起来，我不用计划那么多事情了。唯一计划的是，为以后的发展储备更多的能量吧。
别了，2008
欢迎你，2009
十二
23
QQ群里有位兄弟提出一个很有意思的问题，在一个db_cache_size为1.6G，几乎没有什么活动的数据库（版本为9.2.0.1)里面，一个简单的查询SELECT * FROM T，反复执行，这个查询的物理读始终很高。被查询的表不大，完全可以容纳在cache里面。根据直觉，频繁被读取的块，是应该cache在内存中的，不应该会有物理读，并且当时数据库没有其他的活动，cache中的块也不会被挤出去。
这个现象是违反直觉的，但注意，直觉的东西不一定不是正确的东西。那么为什么那个简单的SQL，在反复执行的情况下，怎么会有那么高的物理读呢？
这还得从Oracle的buffer cache管理说起。一个oracle进程在做全表扫描时，buffer会放置到LRU-AUX链表的尾端。如果在读块时，如果已经没有free buffer，那么进程就会查找可以被age out的块，这个查找过程是从LRU-AUX链表的尾端开始的。也就是说LRU-AUX链表尾端的buffer，总是第一个被替换的。
基于Oracle的这种LRU算法，我们假设，现在系统中已经没有free buffer，也就是buffer cache已经用完。实际上这种情况是最常见的，必竟现在的库相对于db_cache_size来说，总是大很多倍，buffer cache很快就会被填满。那么，在做全表扫描时，第1次多块读(multiblock read)的buffer会放置到LRU-AUX链表的尾端（不管这个buffer是从哪里得到的），第2次多块读时，需要buffer时，oracle也会从LRU-AUX链表的的尾端开始进行查找可以被替换的buffer，而刚好LRU-AUX链表的尾端的buffer正是上一次多块读时的buffer。也就是说前一次读到的块，很快就会被后面读的块替换掉了。
因此，不难理解，为什么在数据库活动很少时，反复扫描同一个表（这里不是同时扫描），其物理读仍然很高。并不是我们直觉的那样，这个表已经很“热”，应该全部在内存中命中。
下面我们通过一个测试来验证我们的推断。
测试环境：
Oracle 10.2.0.3 32Bit for Linux
我们设置如下的参数，以便让buffer cache的大小在我们控制的范围内：
SQL> alter system set shared_pool_size=100m;
System altered.
SQL> alter system set db_cache_size=30m;
System altered.
SQL> alter system set sga_target=200m;
十二
15
什么是global statistics？
大家都知道，dbms_stats是Oracle 9i及后续的版本中用于收集优化器统计信息的包，虽然analyze命令也一直可用，但是现在已经不推荐使用analyze来收集统计信息，而是使用dbms_stats。二者之间一个很大的不同，也是dbms_stats一个很突出的优点就是能够正确收集分区表的统计信息，换言之就是global statistics。而analyze命令只会收集最低层次对象的统计信息，然后推导和汇总出高一级的统计信息，如分区表只会收集分区信息，然后再汇总所有分区的统计信息，得到表一级的统计信息。
那什么是global statistics？简单地说global statistics就是指直接从对象本身这一级收集到的统计信息，而不是从下一级对象“推导”或“汇总”出来的统计信息。比如，表的global statistics指直接通过表收集到的统计信息，而不是从分区收集的统计信息进行汇总或推导出的。同样，分区的global statistics是指直接通过分区收集到的统计信息，而不是从子分区收集的统计信息进行汇总或推导出的。global statistics对优化器来说是非常重要的，一个SQL，除非其查询条件限定了数据只在部分分区上，否则在大多数情况下需要global statistics才能得到正确的执行计划。
有的统计值可以从对象的下一级对象进行汇总后得到，比如表的总行数，可以通过各分区的行数相加得到。但有的统计值则不能从下一级对象得到，比如列上的唯一值数量(distinct value）以及密度值（density）。
怎样收集global statistics？
global statistics只能通过dbms_stats包来收集。注意，用analyze命令得到的统计信息，虽然也会有表一级的统计值，但是，那些值是从分区或子分区推导和汇总出来的，是不精确的。后面的实验中，将会验证这一点。
使用dbms_stats收集统计信息时，参数granularity（比如gather_table_stats过程） 指定了哪个级别上的统计信息会被收集：
- Global -- Table （表）
- Partition -- Partition （分区）
- SubPartition -- SubPartition （子分区）
- Default -- Table + Partition （表+分区）
- All -- Table + Partition + Subpartition （表+分区+子分区）
- Auto -- Table + Partition + Subpartition （10g，表+分区，当子分区是list分区时还包括子分区）
比如，要在一个做为子分区的表上，以'ALL'级别收集统计信息时，会收集”表+分区+子分区“上的统计信息，相当于需要执行下面的三类SQL：
- select .... from table
- select .... from table (partition P1) -- 在每个分区上都重复一次
- select .... from table (subpartition SP1) -- 在每个子分区上重复一次
可以看到，dbms_stats需要比analyze命令更多的时间来进行统计信息的收集。对于有子分区的表，dbms_stats至少要多花三倍的时间。 Read the rest of this entry
十二
08
故障发生时间：12月6日早上
系统环境：HP Superdome系列，128G内存，64CPU,Oracle 9.2.0.8
故障现象：CPU占用将近100%，运行队列达到60-80，应用反应速度很慢。
这是一个省级电信的核心系统。
在用户反映速度很慢后，在主机上检查发现CPU很高，将近100%，而运行队列达到了60-80。检查Oracle，发现很多的会话在等待latch free，latch#为98
SQL> select * from v$latchname where latch#=98;
LATCH# NAME
---------- ----------------------------------------------------------------
98 cache buffers chains
检查正在等待latch free的会话正在执行的SQL，大部分都在执行类似于下面的SQL：
SELECT SUM(cnt),
to_char(nvl(SUM(nvl(amount, 0)) / 100, 0), 'FM9999999999990.90') amount
FROM (select count(payment_id) cnt, SUM(amount) amount
from payment
where staff_id = 592965
and CREATED_DATE >= trunc(sysdate)
and state = 'C0C'
and operation_type in ('5KA', '5KB', '5KC', '5KP'))
看起来这个SQL并不复杂，查看其执行计划： Read the rest of this entry