2008年，在成都安定了下来。上班搞自己喜欢搞的ORACLE，下班回家陪陪父母、老婆和孩子。这日子，挺不错。
2009年，我会干什么呢？大家都会说计划没有变化快。看起来，我不用计划那么多事情了。唯一计划的是，为以后的发展储备更多的能量吧。

别了，2008
欢迎你，2009

这个现象是违反直觉的，但注意，直觉的东西不一定不是正确的东西。那么为什么那个简单的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;

再建两个测试表T1，T2，使每一个表的块只能放置1行数据。

SQL> create table t1 ( a int,b char(2000),c char(2000),d char(1000));

Table created.

SQL> create table t2 ( a int,b char(2000),c char(2000),d char(1000));

Table created.

SQL> insert into t1 values (1,’a',’b',’c');

1 row created.

SQL> commit;

Commit complete.

SQL> alter table t1 minimize records_per_block;

Table altered.

SQL> insert into t2 values (1,’a',’b',’c');

1 row created.

SQL> commit;

Commit complete.

SQL> alter table t2 minimize records_per_block;

Table altered.

向这两个表中插入3999行数据，与上面插入的1行一起分别共计4000行。

SQL> insert into t1 select rownum+1,’a',’b',’c’ from dba_objects where rownum< =3999;

3999 rows created.

SQL> insert into t2 select rownum+1,’a',’b',’c’ from dba_objects where rownum< =3999;

3999 rows created.

SQL> commit;

Commit complete.

SQL> col segment_name for a20
SQL> select segment_name,blocks from dba_segments where owner=user and segment_name in (’T1′,’T2′);

SEGMENT_NAME             BLOCKS
-------------------- ----------
T2                         4096
T1                         4096

可以看到这两个表都有4096个块，每个表32MB。
刷新buffer_cache，保证buffer cache中没有任何这两个表的块。

SQL> select object_name,data_object_id from dba_objects where owner=user and object_name in (’T1′,’T2′);

OBJECT_NAME          DATA_OBJECT_ID
-------------------- --------------
T1                            52416
T2                            52417
SQL> alter system flush buffer_cache;

System altered.

SQL> select count(*) from x$bh where obj in (52416,52417) and state<>0;

COUNT(*)
----------
0

查询T1表，让T1表中的所有块填充到buffer cache中，并统计X$BH中各状态的合计：

SQL> select count(*) from t1;

COUNT(*)
----------
4000
SQL> select set_ds,
2 decode(state,0,’free’,1,’xcur’,2,’scur’,3,’cr’,4,’read’,5,’mrec’,
3 6,’irec’,7,’write’,8,’pi’) state,
4 count(*) cnt
5 from x$bh
6 group by set_ds, state
7 order by 1, 2;

SET_DS   STATE        CNT
-------- ----- ----------
2C5430B4 cr             5
2C5430B4 free          72
2C5430B4 xcur        6872

用TEST用户连接产生另一个会话（以下称之为会话2），在会话2中查询T2表：

SQL> connect test/test
Connected.
SQL> set autot on statistics
SQL> select count(*) from sys.t2;

COUNT(*)
----------
4000
Statistics
----------------------------------------------------------
        154  recursive calls
          0  db block gets
       4026  consistent gets
       4003  physical reads
          0  redo size
        411  bytes sent via SQL*Net to client
        400  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          4  sorts (memory)
          0  sorts (disk)
          1  rows processed

在会话2中反复多次查询T2表，发现T2表的物理读数几乎不再变化：

SQL> /

COUNT(*)
----------
4000

Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       4009  consistent gets
       3682  physical reads
          0  redo size
        411  bytes sent via SQL*Net to client
        400  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

SQL> /

COUNT(*)
----------
4000

Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       4009  consistent gets
       3712  physical reads
          0  redo size
        411  bytes sent via SQL*Net to client
        400  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

SQL> /

COUNT(*)
----------
4000

Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       4009  consistent gets
       3712  physical reads
          0  redo size
        411  bytes sent via SQL*Net to client
        400  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

在会话1中，对x$bh按state进行状态，其结果也趋于稳定：

SET_DS   STATE        CNT
-------- ----- ----------
2B9430B4 cr             6
2B9430B4 free          72
2B9430B4 xcur       10401

如果查询T1表，会发现，T1表不再产生逻辑读，这是因为T1表开始已经全部装入到buffer cache中。

因此，这里可以得到一个结论，如果buffer cache有足够的剩余空间，使一个全表扫描所读到的所有块全部装入到buffer cache，否则全表扫描产生的物理读仍然是相当的高，不管这个表被扫描到多少次。

虽然提出此问题的网友使用的Oracle为9.2.0.1，在这个版本下的测试，可以得到同样的结果。

即使是多个进程并发扫描同一个表，除非一个多块读操作读进buffer cache中的块，在age out之前被另一个多块读操作读到，那么多个进程对同一个表进行全表扫描，产生的物理读仍然是非常高的。

而如果一个多块读操作读进buffer cache中的块，age out之前被另一个单块读操作读到，那结果也许更糟糕，这导致一个块被移到LRU-MAIN链表中，被age out的机会相对减少，但是正是由于一个块没有被age out，下一次相同范围的多块读，将不得不分成两次多块读。

对于一个频繁全表扫描的表，如果SQL不能优化，则应该尽量放置到KEEP BUFFER中，这将显著减少物理读的数量。

大家都知道，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 + Subpartit （表+分区+子分区）

比如，要在一个做为子分区的表上，以’ALL’级别收集统计信息时，会收集”表+分区+子分区“上的统计信息，相当于需要执行下面的三类SQL：

• select …. from table
• select …. from table (partition P1) -- 在每个分区上都重复一次
• select …. from table (subpartition SP1) -- 在每个子分区上重复一次

可以看到，dbms_stats需要比analyze命令更多的时间来进行统计信息的收集。对于有子分区的表，dbms_stats至少要多花三倍的时间。

怎样查看表是否收集了global statistics？

统计信息(下面主要描述表和分区，不涉及索引）一般是通过查看下列视图来检查的：

• 表的统计信息：

[DBA|ALL|USER]_TABLES
[DBA|ALL|USER]_TAB_COL_STATISTICS

• 分区的统计信息：

[DBA|ALL|USER]_TAB_PARTITIONS
[DBA|ALL|USER]_PART_COL_STATISTICS

• 子分区的统计信息：

[DBA|ALL|USER]_TAB_SUBPARTITIONS
[DBA|ALL|USER]_SUBPART_COL_STATISTICS

在以上的视图中，如果GLOBAL_STATS列值为”YES“，表示该级对象上收集了global statistics，而值为”NO“则表示没有收集global statistics。

下面用一些实验来更深入地验证dbms_stats,analyze以及global statistics三者之间的联系。测试环境为Linux AS4上的Oracle 10.2.0.3。注意不同的Oracle可能有不同的行为。

我们先用下面的SQL创建一个测试表，这个表有2个分区，每个分区有2个子分区：

CREATE TABLE T3(i number,  p number,sp number)
PARTITION BY RANGE(p)
SUBPARTITION BY HASH(sp) SUBPARTITIONS 2 
(
  PARTITION q1 VALUES LESS THAN(3) TABLESPACE USERS,
   PARTITION q2 VALUES LESS THAN(MAXVALUE) TABLESPACE USERS
);

declare 
  i number; 
begin 
  for i in 1..100000 loop 
    insert into T3 values(i,mod(i,7), mod(i,8)); 
    if( mod(i, 1000) = 0) then commit; end if; 
  end loop; 
for i in 1..50000 loop 
    insert into T3 values(i,mod(i,7), mod(i,8)+5); 
    if( mod(i, 1000) = 0) then commit; end if; 
  end loop; 
end; 
/

我们向测试表中插入15W行数据。I列有100,000个不同的值，P列有7个不同的值，SP列有13个不同的值。为了能够方便地查看收集的统计信息，我们使用了一段来自Metalink的sql代码，点击此处下载此代码文件sosi.sql。

首先用@sosi可以看到，T3没有任何统计信息存在。
使用analyze table t3 compute statistics;收集T3表的统计信息，可以看到如下的统计信息（由于版面原因，去除了一些与本文无关的信息）：

SQL> analyze table t3 compute statistics;
SQL> @sosi
SQL> set echo off

Tables owned by TEST
------------------------------
T3

Please enter Name of Table Owner (Null = TEST):
Please enter Table Name to show Statistics for: T3

***********
Table Level
***********

Table  Number           Empty Average Chain Average Global User   Sample 
Name  of Rows   Blocks Blocks   Space Count Row Len Stats  Stats    Size 
------------- -------- ------ ------- ----- ------- ------ ------ ------ 
T3    150,000      328     32     921     0      13 NO     NO          0

Column Column    Distinct          Number Number Global User   Sample 
Name   Details     Values Density Buckets  Nulls Stats  Stats    Size 
------ ------------------ ------- ------- ------ ------ ------ ------ 
I      NUMBER(22)  59,845       0       1      0 NO     NO            
P      NUMBER(22)       7       0       1      0 NO     NO            
SP     NUMBER(22)       8       0       1      0 NO     NO            

***************
Partition Level
***************
Partition  Number           Empty Average Chain Average Global User   Sample 
Name      of Rows   Blocks Blocks   Space Count Row Len Stats  Stats    Size 
--------- ------- -------- ------ ------- ----- ------- ------ ------ ------ 
Q1         64,285      138     14     878     0      13 NO     NO            
Q2         85,715      190     18     954     0      14 NO     NO            

Partition Column Distinct          Number Number Global User   Sample 
Name      Name     Values Density Buckets  Nulls Stats  Stats    Size 
--------- ------ -------- ------- ------- ------ ------ ------ ------ 
Q1        I        44,878       0       1      0 NO     NO            
          P             3       0       1      0 NO     NO            
          SP            8       0       1      0 NO     NO            
Q2        I        59,844       0       1      0 NO     NO            
          P             4       0       1      0 NO     NO            
          SP            8       0       1      0 NO     NO       
***************
SubPartition Level
***************

Partition SubPartition  Number           Empty Average Average Global User   Sample 
Name      Name         of Rows   Blocks Blocks   Space Row Len Stats  Stats    Size 
--------- ------------ ------- -------- ------ ------- ------- ------ ------ ------ 
Q2        SYS_SUBP31    35,715       80      8     992      14 NO     NO     35,715 
Q1        SYS_SUBP29    26,785       58      6     902      14 NO     NO     26,785 
Q2        SYS_SUBP32    50,000      110     10     928      14 NO     NO     50,000 
Q1        SYS_SUBP30    37,500       80      8     861      13 NO     NO     37,500 

Partition SubPartition    Column  Distinct          Number Number Global User   Sample 
Name      Name            Name      Values Density Buckets  Nulls Stats  Stats    Size 
--------- --------------- ------- -------- ------- ------- ------ ------ ------ ------ 
Q1        SYS_SUBP29      I         24,106       0       1      0 NO     NO     26,785 
          SYS_SUBP29      P              3       0       1      0 NO     NO     26,785 
          SYS_SUBP29      SP             5       0       1      0 NO     NO     26,785 
          SYS_SUBP30      I         32,142       0       1      0 NO     NO     37,500 
          SYS_SUBP30      P              3       0       1      0 NO     NO     37,500 
          SYS_SUBP30      SP             8       0       1      0 NO     NO     37,500 
Q2        SYS_SUBP31      I         32,144       0       1      0 NO     NO     35,715 
          SYS_SUBP31      P              4       0       1      0 NO     NO     35,715 
          SYS_SUBP31      SP             5       0       1      0 NO     NO     35,715 
          SYS_SUBP32      I         42,858       0       1      0 NO     NO     50,000 
          SYS_SUBP32      P              4       0       1      0 NO     NO     50,000 
          SYS_SUBP32      SP             8       0       1      0 NO     NO     50,000

由上面的表可以看到，analyze只是收集了sub partition的统计信息，然后经过汇总和推导得到了partition和table级别的统计信息。global_stats列值均为”NO”。在表级的I字段的统计信息上看到，I的唯一值个数为59,845，而实际的值应该为100,000，这里差距是比较大的；SP的唯一值个数为8，而实际的值应该为13。

下面再将统计信息删除，然后使用dbms_stats重新收集统计信息：

SQL> exec dbms_stats.gather_table_stats(ownname=>user,tabname=>’T3′,granularity=>’ALL’);
SQL> @sosi
SQL> set echo off

Tables owned by TEST
------------------------------
T3

Please enter Name of Table Owner (Null = TEST):
Please enter Table Name to show Statistics for: T3

***********
Table Level
***********

Table   Number           Empty Average Chain Average Global User    Sample 
Name   of Rows   Blocks Blocks   Space Count Row Len Stats  Stats     Size 
------ ------- -------- ------ ------- ----- ------- ------ ------ ------- 
T3     150,000      328      0       0     0      10 YES    NO     150,000 

Column Column      Distinct          Number Number Global User    Sample Date
Name   Details       Values Density Buckets  Nulls Stats  Stats     Size MM-DD-YYYY
------ ----------- -------- ------- ------- ------ ------ ------ ------- ----------
I      NUMBER(22)   100,000       0       1      0 YES    NO     150,000 12-15-2008
P      NUMBER(22)         7       0       1      0 YES    NO       5,497 12-15-2008
SP     NUMBER(22)        13       0       1      0 YES    NO       5,497 12-15-2008
***************
Partition Level
***************

Partition  Number           Empty Average Chain Average Global User   Sample 
Name      of Rows   Blocks Blocks   Space Count Row Len Stats  Stats    Size 
--------- ------- -------- ------ ------- ----- ------- ------ ------ ------ 
Q1         64,285      138      0       0     0      10 YES    NO     64,285 
Q2         85,715      190      0       0     0      10 YES    NO     85,715 

Partition Column  Distinct          Number Number Global User   Sample 
Name      Name      Values Density Buckets  Nulls Stats  Stats    Size 
--------- ------- -------- ------- ------- ------ ------ ------ ------ 
Q1        I         42,857       0       1      0 YES    NO     64,285 
          P              3       0       1      0 YES    NO      5,584 
          SP            13       0       1      0 YES    NO      5,584 
Q2        I         57,143       0       1      0 YES    NO     85,715 
          P              4       0       1      0 YES    NO      5,443 
          SP            13       0       1      0 YES    NO      5,443

***************
SubPartition Level
***************

Partition SubPartition   Number           Empty Average Average Global User  Sample 
Name      Name          of Rows   Blocks Blocks   Space Row Len Stats  Stats   Size 
--------- ------------- ------- -------- ------ ------- ------- ------ ----- ------ 
Q2        SYS_SUBP31     35,715       80      0       0      10 YES    NO    35,715 
Q1        SYS_SUBP29     26,595       58      0       0      10 YES    NO     5,461 
Q2        SYS_SUBP32     50,000      110      0       0      10 YES    NO    50,000 
Q1        SYS_SUBP30     37,500       80      0       0      10 YES    NO    37,500

Partition  SubPartition    Column  Distinct          Number Number Global User   Sample 
Name       Name            Name      Values Density Buckets  Nulls Stats  Stats    Size 
---------- --------------- ------- -------- ------- ------- ------ ------ ------ ------ 
Q1         SYS_SUBP29      I         26,084       0       1      0 YES    NO      5,461 
           SYS_SUBP29      P              3       0       1      0 YES    NO      5,461 
           SYS_SUBP29      SP             5       0       1      0 YES    NO      5,461 
           SYS_SUBP30      I         32,142       0       1      0 YES    NO     37,500 
           SYS_SUBP30      P              3       0       1      0 YES    NO      5,459 
           SYS_SUBP30      SP             8       0       1      0 YES    NO      5,459 
Q2         SYS_SUBP31      I         32,144       0       1      0 YES    NO     35,715 
           SYS_SUBP31      P              4       0       1      0 YES    NO      5,605 
           SYS_SUBP31      SP             5       0       1      0 YES    NO      5,605 
           SYS_SUBP32      I         42,858       0       1      0 YES    NO     50,000 
           SYS_SUBP32      P              4       0       1      0 YES    NO      5,500 
           SYS_SUBP32      SP             8       0       1      0 YES    NO      5,500

从上面的统计信息可以看到，不管是在partition级，还是在table级，I列和SP列的唯一值个数都得到了正确的值。在三种级别（table,partition,subpartition）上，global_stats列值都为“YES”，表示三个级别收集的都是global statistics。

将统计信息删除，使用exec dbms_stats.gather_table_stats(ownname=>user,tabname=>’T3′,granularity=>’SUBPARTITION’);
收集子分区级别上的统计信息（此处不再列出具体的统计信息数据），则子分区统计信息中的global_stats值为”YES”，而分区和表级统计信息中的global_stats值为”NO”，这两级的统计数据则是由子分区级统计信息汇总和推导得出。
而使用exec dbms_stats.gather_table_stats(ownname=>user,tabname=>’T3′,granularity=>’PARTITION’);收集分区级上的统计信息，则子分区没有统计信息，表级的统计信息也是由分区级统计信息推导和汇总而来。
而在缺省情况下，即granularity参数为default值时，分区和表都有global statistics，而子分区级没有任何统计信息 。

在以上的测试中，在进行新的统计信息收集之前，都是先删除了原来的统计信息。但是如果我们在收集统计信息之前没有删除原来的统计数据，并且不同的统计策略，会有不同的影响。但大部分都是很不好的影响，容易造成统计信息的不准确。比如：

• 使用dbms_stats以granularity=’ALL’收集统计信息，删除一部分数据之后，再以更低级别的粒度收集统计数据：

SQL> exec dbms_stats.gather_table_stats(ownname=>user,tabname=>’T3′,granularity=>’ALL’);
SQL> delete from t3 where i<3000;
SQL> commit;
SQL> exec dbms_stats.gather_table_stats(ownname=>user,tabname=>’T3′,granularity=>’PARTITION’);
SQL>

然后对比统计信息，可以发现，表级和子分区级仍然保留着原来的过时的统计信息。综合其他的几个测试（此处不再列出），我们可以得到这个结论：使用dbms_stats收集统计信息，粒度（granularity）为较低级别时，更低级别的统计信息保持不变，而高级别的统计信息由收集的这一级别的统计信息推导和汇总得出，但不能跨级别推导和汇总。但如果高级别的统计信息之前是global statistics，则那一级别的统计信息保持不变。analyze始终是在子分区级别收集统计信息，其高级别统计信息的推导和汇总的行为与dbms_stats一样。比如，现在表级的统计信息global_stats为NO，分区级的统计信息global_stats为YES，使用SUBPARTITION级别或使用analyze命令分析后，分区级的统计信息仍然是原来的统计信息，而表级的统计信息其global_stats为NO，但由于不能跨级推导和汇总，所以表这一级的统计信息仍然是原来的统计信息。

• 使用dbms_stats以granularity=’PARTITION’收集统计信息，然后使用analyze删除统计信息：

SQL> exec dbms_stats.gather_table_stats(ownname=>user,tabname=>’T3′,granularity=>’PARTITION’);
SQL> analyze table t3 delete statistics;
SQL> exec dbms_stats.gather_table_stats(ownname=>user,tabname=>’T3′,granularity=>’ALL’);
SQL> analyze table t3 delete statistics;

执行上面的命令序列之后，我们可以发现，analyze ..delete statistics命令总是会删除子分区的统计信息，但分区级和表级，如果有global statistics统计信息，则不会删除。并且不能跨级删除，比如分区有global statistics，由表级没有global statistics，表级的统计信息也不会被删除。综合其他几个测试，也可以得到：如果某一级（partition,subpartition）上有统计信息，那么比它更高的所有级别上都会有统计信息。

• 各种情况下使用dbms_stats.delete_table_stats删除统计信息，可以发现：

dbms_stats.delete_table_stats总是可以删除表上所有的三个级别的统计信息。

• 使用analyze命令收集的统计信息，有如下特点：

analyze命令收集的统计信息，global_stats总是为”NO“。

综合以上测试和得到的结果，总结出我们在收集优化统计信息需要注意以下几个方面：

• 分区表的统计信息使用dbms_stats包中的过程，这样才能收集global statistics。
• 删除表的统计信息使用dbms_stats包中的过程，analyze命令删除统计信息，可能不是你想要的结果，因为有可能部分统计信息并没有被删除。
• 收集统计信息时，使用一致的granularity参数，比如开始用ALL，过一段时间用DEFAULT或PARTITION，这样得出的结果，在某些级别上的统计信息是过时的，不准确的。
• 由于analyze命令只在最低一级收集统计信息，而高一级的统计信息是下级统计信息汇总和推导而来。因此不要将analyze命令与dbms_stats混合使用于同一张表上，其原因如同上一条。

本文涉及到的内容，只有表（并且是普通的HEAP表），不包括索引。也没有涉及到直方图。本文部分内容来源于Metalink Note ID：236935.1 ”Global statistics - An Explanation“

如果需要深入研究analyze和dbms_stats，感兴趣的可以使用sql trace或10046事件来跟踪二者的行为。

这是一个省级电信的核心系统。

在用户反映速度很慢后，在主机上检查发现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并不复杂，查看其执行计划：

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------------------------
| Id  | Operation                             |  Name                      | Rows  | Bytes | Cost  | Pstart| Pstop |
--------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |                            |     1 |    26 |   125K|       |       |
|   1 |  SORT AGGREGATE                       |                            |     1 |    26 |       |       |       |
|   2 |   VIEW                                |                            |     1 |    26 |   125K|       |       |
|   3 |    SORT AGGREGATE                     |                            |     1 |    30 |       |       |       |
|*  4 |     TABLE ACCESS BY GLOBAL INDEX ROWID| PAYMENT                    | 19675 |   576K|   125K| ROWID | ROW L |
|*  5 |      INDEX RANGE SCAN                 | IDX_PAYMENT_CREATED_DATE8  |  1062K|       |  3919 |       |       |
--------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   4 - filter(”PAYMENT”.”STAFF_ID”=521840 AND ”PAYMENT”.”STATE”=’C0C’ AND (”PAYMENT”.”OPERATION_TYPE”=’5KA’ OR
              ”PAYMENT”.”OPERATION_TYPE”=’5KB’ OR ”PAYMENT”.”OPERATION_TYPE”=’5KC’ OR ”PAYMENT”.”OPERATION_TYPE”=’5KP’))
   5 - access(”PAYMENT”.”CREATED_DATE”>=TRUNC(SYSDATE@!))

Note: cpu costing is off

从执行计划里面可以看到，Oracle评估出，利用索引扫描返回的行数高达100万行，可想而知，这就是产生众多latch buffers chains latch争用的原因。
检查PAYMENT表的索引：

SQL> select index_name,index_type from dba_indexes where table_name=’PAYMENT’ and table_owner=’ACCT’;

INDEX_NAME                     INDEX_TYPE
------------------------------ ---------------------------
IDX_OPERATED_PAYMENT_SERIAL8   NORMAL
IDX_PAYMENT_ACCT_ID8           NORMAL
IDX_PAYMENT_CREATED_DATE8      NORMAL
IDX_PAYMENT_PAYED_METHOD8      NORMAL
IDX_PAYMENT_PAYMENT_METHOD8    NORMAL
IDX_PAYMENT_SERV_ID8           NORMAL
IDX_PAYMENT_STAFF_DATE8        NORMAL
IDX_PAYMENT_STATE_DATE8        NORMAL
PK_PAYMENT13                   NORMAL

SQL> select index_name,column_name,column_position from dba_ind_columns where table_owner=’ACCT’ and table_name=’PAYMENT’ order by 1,3;

INDEX_NAME                     COLUMN_NAME                    COLUMN_POSITION
------------------------------ ------------------------------ ---------------
IDX_OPERATED_PAYMENT_SERIAL8   OPERATED_PAYMENT_SERIAL_NBR                  1
IDX_PAYMENT_ACCT_ID8           ACCT_ID                                      1
IDX_PAYMENT_CREATED_DATE8      CREATED_DATE                                 1
IDX_PAYMENT_PAYED_METHOD8      PAYED_METHOD                                 1
IDX_PAYMENT_PAYMENT_METHOD8    PAYMENT_METHOD                               1
IDX_PAYMENT_SERV_ID8           SERV_ID                                      1
IDX_PAYMENT_STAFF_DATE8        STAFF_ID                                     1
IDX_PAYMENT_STAFF_DATE8        STATE_DATE                                   2
PK_PAYMENT13                   PAYMENT_ID                                   1

可以看到执行计划中的使用的索引IDX_PAYMENT_CREATED_DATE8是在CREATED_DATE列上建立的单列索引。

这个SQL在之前却没有出现这个问题，那问题在哪里？
如果了解电信系统的人，会知道在出帐后会有一个批量销帐的动作，这导致在这个特殊的时间里，用CREATED_DATE>=TRUNCATE(SYSDATE)这个条件会从索引扫描中返回大量的行。而实际上而回表之后用其他条件过滤后的行数仅约2万行（这是评估的数据，实际的数据远远比这个少）。很显然，如果我们建立一个复合索引，那么索引扫描返回的行数将大大减少。这里STAFF_ID这个字段是与CREATED_DATE建立复合索引最好的字段。

在STAFF_ID和CREATE_DATE列上建立复合索引后，系统马上恢复正常。不过这里把STAFF_ID做为复合索引的前导列，有两个方面的考虑，一个是根据这个SQL来看，这会大大减少索引叶块的逻辑读数量；二是会减少索引叶块的热点竞争（CREATE_DATE是单向增长的字段）。至于深层次的分析，则要结合应用，必竟做为故障处理，首要的目标是解决当前的问题。

总结：
利用合适的复合索引，能够有效地减少索引扫描返回的行数，提高性能
熟悉应用系统的业务，可以更清楚地知道问题的根源，减少故障处理时间

引起这个事故的，除了人为因素之外，ORACLE的BUG要负一半的责任。通过操作录像（客户对系统内做系统管理的所有机器的操作都作了录像，这点非常好），我们搞清楚了数据被删除的经过。

一个开发人员，通过OEM（Oracle Enterprise Manager Console）连接到数据库上，经过他确认OEM上的那个连接字符串是正确的，然后对USER做了删除操作，但很快发现，生产库的数据被删除了。操作录像也证明那个连接字符串是正确的，那么问题出在哪里呢？

操作的那台机器（Windows系统），在系统环境变量（我的电脑=>属性=>高级=>环境变量=>系统变量）中设置了TNS_ADMIN，指向了另外的目录。现在，TNS_ADMIN指向的目录（下面简称TNS_ADMIN目录）和%ORACLE_HOME%\NETWORK\ADMIN（下面简称ORACLE目录）下都有TNSNAMES.ORA这个文件。在TNS_ADMIN中，TNSNAMES.ORA有一TNSNAME，指向生产库。在ORACLE目录中，TNSNAMES.ORA中有一同样的名称的TNSNAME指向开发库。

OEM在处理TNS_ADMIN上是有问题的。OEM在启动后，在左边的数据库目录树，是从ORACLE目录的TNSNAMES.ORA中解析出来的，完全忽略了TNS_ADMIN环境变量，就算是执行”将数据库添加到树“操作，也是完全忽略了TNS_ADMIN变量，操作的是ORACLE目录中的TNSNAMES.ORA文件，显示的连接字符串信息也是从那个文件中得到的。下面是显示信息的截图：

然而，在用这个TNSNAME进行连接数据库时，却是按照TNS_ADMIN目录中的TNSNAMES.ORA文件的配置进行连接的，如果这两个TNSNAMES.ORA都有这个TNSNAME，那么不幸就发生了，本来我们期望是连接到OEM中显示的那个数据库上，结果却连接到了另一个库上。这可以是说OEM的重大BUG。

这里谈到的OEM是9i的版本，NetCA也有这个问题，但Net Manager没有这个问题。

事情虽然过去了，但是以下几件事情我们仍然值得我们牢记：

• 有效的备份，特别是归档模式下的有效物理备份，是保证数据不会被丢失的前提。
• 数据库用户权限的管理，需要遵循”最少权限“的原则，不可忽视。很多数据库管理人员为了方便，给Oracle用户太大的权限，甚至是DBA角色权限。这是非常危险的。
• 有了备份仍然不够，需要做恢复测试，避免出现问题发现备份不能恢复，否则悔之晚矣。这次事故中，由于第三方的备份软件问题，导致数据恢复至少多花了三个小时的时间。要是之前有做过完整的测试，则会发现备份软件的问题。
• 一些危险的操作，如删除用户，删除表等操作，一定要有规范的流程，确认无误后再执行。

还有以下我的一些个人观点：

• 数据库管理时，尽量少用图形化的软件，一次DEL按键就能葬送整个系统。
• 尽量将生产系统、测试系统与开发库隔离，比如禁止在开发机器上直接连接生产库，开发完成后，需要部署到生产库时，遵循专门的流程进行。也就是要规范开发流程。

SELECT NETWORKTYPEID FROM PROBLEM_TAB WHERE PREFIXNUM = SUBSTR(:B1 , 1, 7)
select provinceid into :b0 from PROBLEM_TAB where PREFIXNUM=substr(:b1,1,7)

我关注这个的原因是，为啥这两个SQL比较消耗CPU，比逻辑读更高的SQL消耗得还多。这里让我感兴趣的是，这里使用了函数，函数的参数使用了绑定变量。那么，有一个问题，那就是这个函数会被调用多少次？1次还是与表中所有行相同的次数？我的推测是对于结果确定性（deterministic）的函数，如果传入参数有绑定变量，那么会是被引用（如值的比较）的次数，如果传入的参数是确定的值，那么应该是1次。这个推测是不是正确的呢，让我们来做一些测试。

首先创建测试用的函数：

create or replace package pkg_test is

g_cnt number;

function f_substr(iv_str varchar2, iv_pos in number, iv_len in number)
return varchar2 deterministic;

end pkg_test;

create or replace package body pkg_test is

function f_substr(iv_str varchar2, iv_pos in number, iv_len in number)
return varchar2 deterministic is
begin
g_cnt:=g_cnt+1;
return substr(iv_str, iv_pos, iv_len);
end;
end pkg_test;

创建一个测试表：

SQL> create table t1 as select * from dba_objects where rownum< =1000;

Table created.

下面首先测试函数调用时传入的参数全部是常量时的情况：

SQL> set serverout on
SQL> exec pkg_test.g_cnt:=0;

PL/SQL procedure successfully completed.
SQL> select count(*) from t1 where object_name = pkg_test.f_substr(’T1AAADBAADFA’,1,2);

COUNT(*)
----------
0
SQL> exec dbms_output.put_line(pkg_test.g_cnt);
1

可以看到f_substr函数只调用了1次。
再看看函数调用时传入的参数含有绑定变量时的情况：

SQL> var str varchar2(50);
SQL> exec :str:=’T1AAADBAADFA’;

PL/SQL procedure successfully completed.
SQL> exec pkg_test.g_cnt:=0;

PL/SQL procedure successfully completed.

SQL> select count(*) from t1 where object_name = pkg_test.f_substr(:str,1,2);

COUNT(*)
----------
0
SQL> exec dbms_output.put_line(pkg_test.g_cnt);
1000
PL/SQL procedure successfully completed.

可以看到这一次，f_substr被调用了1000次。

不过，如果我们调用f_substr时，传入的参数第1个（类型为varchar2）为常量，而第2个和第3个参数（类型为number），重新进行上述测试，则f_substr被调用的次数始终为1次。看起来，在参数使用绑定变量时，函数被调用的次数与绑定变量的参数类型有关系。

如果把函数调用放在select后的字段列表（即做为选择结果），测试结果也一样。
但也有例外情况，比如：

select count(*) from t1 where pkg_test.f_substr(:str,:cnt,2)=pkg_test.f_substr(:str,:cnt,2);

函数就只调用了2次。不过这种情况非常少见，谁会这样写SQL啊？
上面的测试都是对“确定性”的函数进行的测试，如果函数不是确定性的呢？把f_substr函数定义中的deterministic关键字去掉，再进行测试：

SQL> exec pkg_test.g_cnt:=0;
SQL> select count(*) from t1 where object_name=pkg_test.f_substr(’T1AAADAF’,1,2);

COUNT(*)
----------
0
SQL> exec dbms_output.put_line(pkg_test.g_cnt);
1000

PL/SQL procedure successfully completed.
SQL> exec pkg_test.g_cnt:=0;

PL/SQL procedure successfully completed.

SQL> select count(*) from t1 where object_name=pkg_test.f_substr(:str,1,2);

COUNT(*)
----------
0

SQL> exec dbms_output.put_line(pkg_test.g_cnt);
1000

PL/SQL procedure successfully completed.
SQL> exec pkg_test.g_cnt:=0;

PL/SQL procedure successfully completed.
SQL> select count(pkg_test.f_substr(’T1AAADAF’,1,2)) from t1;

COUNT(PKG_TEST.F_SUBSTR(’T1AAADAF’,1,2))
----------------------------------------
1000

SQL> exec dbms_output.put_line(pkg_test.g_cnt);
1000

PL/SQL procedure successfully completed.

这次我们可以看到，对于不确定性的函数，即使传入的参数都是字面值(literal)常量，ORACLE也没有对其优化。在这一轮测试中，只有像

select count(*) from t1 where pkg_test.f_substr(:str,1,2)=pkg_test.f_substr(:str,1,2);

这样的SQL，函数仍然只调用了两次。

还有很多复杂的情况，没有测试。比如表连接，分析函数等。但从上面的测试中，我们还是可以得出下面的结论：

• 在SQL语句中，函数的调用次数，跟函数是否为确定性函数有关。只有在函数为确定性时，ORACLE才能进行函数调用次数的优化。
• 在SQL语句中，函数的调用次数，如果向函数传入的参数是绑定变量时，调用次数跟那个参数的类型有关。有的类型如varchar2类型会导致不能对调用次数做优化。

• 因此，如果用户自定义的函数，尽量使用deterministic关键字。以便让ORACLE能够进行优化。

• SQL语句调用函数时，传入的参数如果有绑定变量，应考虑对函数调用次数的影响。

但有的时候，数据库由于hang住，sqlplus不能连接时(在10g可以尝试用sqlplus -prelim连接数据库），可以使用操作系统上的调试工具来dump oracle系统状态。在记一次Oracle数据库无响应（hang住）故障的处理一文中，就曾使用dbx做systemstate dump，并发现问题所在，并最终解决了问题。下面是当时用dbx做dump的过程：

# dbx -a 446910
Waiting to attach to process 446910 …
Successfully attached to oracle.
Type ‘help’ for help.
reading symbolic information …
stopped in iosl.select at 0×9000000000c94d8 ($t2)
0×9000000000c94d8 (select+0xfffffffffff06318) e8410028 ld r2,0×28(r1)
(dbx) print ksudss(10)

Segmentation fault in slrac at 0×100083aa0 ($t2)
0×100083aa0 (slrac+0xe4) 88030000 lbz r0,0×0(r3)
(dbx) detach

从上面可以看到，使用dbx做dump的过程为：

• 找到有异常的进程号，比如CPU非常高，HANG住的进程等。如果做系统范围的systemstate dump，可以是其他的进程。
• dbx -a < 进程号>
• print ksudss(10) --这里是直接调用ORACLE程序中的ksudss函数，dump level为10，就等同于在sqlplus 中用oradebug dump systemstate 10
• detach
• quit

在LINUX下可以使用gdb，下面是一个例子：

[oracle@xty ~]$ ps -ef | grep LOCAL
oracle 3765 3764 1 05:55 ? 00:00:00 oraclexty (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
oracle 3767 3668 0 05:55 pts/2 00:00:00 grep LOCAL
[oracle@xty ~]$ gdb $ORACLE_HOME/bin/oracle 3765
GNU gdb Red Hat Linux (6.1post-1.20040607.62rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type “show copying” to see the conditions.
There is absolutely no warranty for GDB. Type “show warranty” for details.
This GDB was configured as “i386-redhat-linux-gnu”…(no debugging symbols found)…Using host libthread_db library “/lib/tls/libthread_db.so.1″.

Attaching to program: /u01/app/oracle/product/10.1.0/db_1/bin/oracle, process 3765
Reading symbols from /u01/app/oracle/product/10.1.0/db_1/lib/libskgxp10.so…(no debugging symbols found)…done.
Loaded symbols for /u01/app/oracle/product/10.1.0/db_1/lib/libskgxp10.so
Reading symbols from /u01/app/oracle/product/10.1.0/db_1/lib/libhasgen10.so…done.
Loaded symbols for /u01/app/oracle/product/10.1.0/db_1/lib/libhasgen10.so
Reading symbols from /u01/app/oracle/product/10.1.0/db_1/lib/libskgxn2.so…done.
Loaded symbols for /u01/app/oracle/product/10.1.0/db_1/lib/libskgxn2.so
Reading symbols from /u01/app/oracle/product/10.1.0/db_1/lib/libocr10.so…done.
Loaded symbols for /u01/app/oracle/product/10.1.0/db_1/lib/libocr10.so
Reading symbols from /u01/app/oracle/product/10.1.0/db_1/lib/libocrb10.so…done.
Loaded symbols for /u01/app/oracle/product/10.1.0/db_1/lib/libocrb10.so
Reading symbols from /u01/app/oracle/product/10.1.0/db_1/lib/libocrutl10.so…done.
Loaded symbols for /u01/app/oracle/product/10.1.0/db_1/lib/libocrutl10.so
Reading symbols from /u01/app/oracle/product/10.1.0/db_1/lib/libjox10.so…done.
Loaded symbols for /u01/app/oracle/product/10.1.0/db_1/lib/libjox10.so
Reading symbols from /u01/app/oracle/product/10.1.0/db_1/lib/libclsra10.so…done.
Loaded symbols for /u01/app/oracle/product/10.1.0/db_1/lib/libclsra10.so
Reading symbols from /u01/app/oracle/product/10.1.0/db_1/lib/libdbcfg10.so…done.
Loaded symbols for /u01/app/oracle/product/10.1.0/db_1/lib/libdbcfg10.so
Reading symbols from /u01/app/oracle/product/10.1.0/db_1/lib/libnnz10.so…done.
Loaded symbols for /u01/app/oracle/product/10.1.0/db_1/lib/libnnz10.so
Reading symbols from /usr/lib/libaio.so.1…done.
Loaded symbols for /usr/lib/libaio.so.1
Reading symbols from /lib/libdl.so.2…done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/tls/libm.so.6…done.
Loaded symbols for /lib/tls/libm.so.6
Reading symbols from /lib/tls/libpthread.so.0…done.
[Thread debugging using libthread_db enabled]
[New Thread -1219938624 (LWP 3765)]
Loaded symbols for /lib/tls/libpthread.so.0
Reading symbols from /lib/libnsl.so.1…done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/tls/libc.so.6…done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld-linux.so.2…done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_files.so.2…done.
Loaded symbols for /lib/libnss_files.so.2
0×006967a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
(gdb) print ksudss(10)
[Switching to Thread -1219938624 (LWP 3765)]
$1 = 213658428
(gdb) detach
Detaching from program: /u01/app/oracle/product/10.1.0/db_1/bin/oracle, process 3765
(gdb) quit

然后我们可以找到有dump结果的trace文件：

[oracle@xty ~]$ cd $ORACLE_BASE/admin/xty/udump
[oracle@xty udump]$ ls -lrt | grep 3765
-rw-r----- 1 oracle oinstall 599705 Nov 21 05:56 xty_ora_3765.trc

根据debugger工具attach进程的不同，trace文件一般在user_dump_dest或background_dump_dest目录下。

在LINUX下用gdb，在AIX下用dbx，那么在HP-UX下呢，可以用HP的wdb（可以到HP WDB查看HP WDB的详细信息和下载最新的版本。在solaris上，也会有dbx或gdb（各个平台有多种不同的debugger，其他还有adb,mdb等等）。有兴趣的朋友可以用用。

除了上面提到的systemstate dump，还能不能够做其他的dump？答案是肯定的，以下是一些dump相关的函数：

print ksdhng(3,1,0) 相当于oradebug hanganalyze 3
print ksudps(10) 相当于oradebug dump processstate 10
print curdmp() 相当于oradebug call curdmp（也就是oradebug dump cursordump)
print ksdtrc(4) 相当于oradebug dump events 4（这里参数表示level,1--session,2--process,4--system)

以上列出的，不一定对处理HANG有意义，只是这里觉得有些意思。^_^.其他还有意思的包括：

print ksdsel(10046,12) --相当于为attach的进程设置10046事件level 12
print skdxipc() --相当于oradebug ipc
print skdxprst() --相当于oradebug procstat

注意：不要在正常运行的生产系统上运行和测试。

当然，如果能用oradebug，那么就用oradebug，毕竟方便很多，也更安全。这里只是对使用debugger做dump一些扩充，供有兴趣研究的朋友参考。

补充：在HP-UX上使用gdb进行system dump，可能会更复杂，可以参考Oracle Metalink Doc 273324.1

测试环境：Linux AS4上的Oracle 10.2.0.1，客户端(sqlplus)版本为Windows 2003下的10.2.0.1。

首先在数据库上启用10046事件：

SQL> alter system set events ‘10046 trace name context forever’;

System altered.

先用普通的方式连接：

D:\>sqlplus /nolog

SQL*Plus: Release 10.2.0.1.0 - Production on 星期六 11月 15 15:36:02 2008

Copyright (c) 1982, 2005, Oracle. All rights reserved.

SQL> conn sys/manage@xty as sysdba
已连接。
SQL> exit
从 Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options 断开

再看看加prelim参数时的情况：

D:\>sqlplus -prelim /nolog

SQL*Plus: Release 10.2.0.1.0 - Production on 星期六 11月 15 15:36:34 2008

Copyright (c) 1982, 2005, Oracle. All rights reserved.

SQL> conn sys/manage@xty as sysdba
初级连接已建立
SQL> exit
从 ORACLE 断开

从上面的信息可以看到，在使用prelim连接时，提示为“初级连接已建立”，退出sqlplus没有显示banner。
也可以通过下面的方式来用prelim方式连接数据库：

[oracle@xty ~]$ sqlplus /nolog

SQL*Plus: Release 10.2.0.3.0 - Production on Tue Dec 2 07:04:28 2008

Copyright (c) 1982, 2006, Oracle. All Rights Reserved.

SQL> set _prelim on
SQL> connect / as sysdba
Prelim connection established

再看看数据库的10046 trace：

从生成的trace文件中，可以发现在正常连接时，连接上数据库后，sqlplus自动执行了下面的SQL：

ALTER SESSION SET NLS_LANGUAGE= ‘SIMPLIFIED CHINESE’ NLS_TERRITORY= ‘CHINA’ NLS_CURRENCY= ‘￥’ NLS_ISO_CURRENCY= ‘CHINA’ NLS_NUMERIC_CHARACTERS= ‘.,’ NLS_CALENDAR= ‘GREGORIAN’ NLS_DATE_FORMAT= ‘DD-MON-RR’ NLS_DATE_LANGUAGE= ‘SIMPLIFIED CHINESE’ NLS_SORT= ‘BINARY’ TIME_ZONE= ‘+08:00′ NLS_COMP= ‘BINARY’ NLS_DUAL_CURRENCY= ‘￥’ NLS_TIME_FORMAT= ‘HH.MI.SSXFF AM’ NLS_TIMESTAMP_FORMAT= ‘DD-MON-RR HH.MI.SSXFF AM’ NLS_TIME_TZ_FORMAT= ‘HH.MI.SSXFF AM TZR’ NLS_TIMESTAMP_TZ_FORMAT= ‘DD-MON-RR HH.MI.SSXFF AM TZR’

select value$ from props$ where name = ‘GLOBAL_DB_NAME’

select SYS_CONTEXT(’USERENV’, ‘SERVER_HOST’), SYS_CONTEXT(’USERENV’, ‘DB_UNIQUE_NAME’), SYS_CONTEXT(’USERENV’, ‘INSTANCE_NAME’), SYS_CONTEXT(’USERENV’, ‘SERVICE_NAME’), INSTANCE_NUMBER, STARTUP_TIME, SYS_CONTEXT(’USERENV’, ‘DB_DOMAIN’) from v$instance where INSTANCE_NAME=SYS_CONTEXT(’USERENV’, ‘INSTANCE_NAME’)

select decode(failover_method, NULL, 0 , ‘BASIC’, 1, ‘PRECONNECT’, 2 , ‘PREPARSE’, 4 , 0), decode(failover_type, NULL, 1 , ‘NONE’, 1 , ‘SESSION’, 2, ‘SELECT’, 4, 1), failover_retries, failover_delay, flags from service$ where name = :1

而sqlplus使用prelim连接上数据库后，没有生成10046 trace文件，看起来没有执行SQL，也就是没有执行任何初始化动作和查询必要的信息。也许这也就是称之为“初级连接”的来历吧。

由于使用prelim方式连接，没有执行sql语句的，所以在数据库的某些hang住的情况下，能够连接上数据库。比如由于library cache latch 被长时间持有不能释放，不能解析SQL语句引起的hang。有的人会说，我的应用刚连上去还没做任何操作就hang住了。这只是表面现象，连接上数据库后，一般都会做一些初始化的操作，如设定环境之类的。

sqlplus -prelim能够在数据库hang住的情况下连接数据库，但只能说是连接，并不代表能够做很多操作。比如执行SQL查询。这种情况下，可能最有用的就是使用oradebug。

本文只是简单地“inside”，其实并不很深入，Oracle还会有其他的跟prelim有关的东西，是我们还没发现的。有兴趣的朋友，可以进一步研究。比如通过抓取tns包进行分析等等。

儿子很很喜欢飞机，天上有飞机飞过，总要抬头看看，直到看不见为止。经常缠着我们在网上找飞机图片给他看。现在至少是能分辨客机和直升机了，不过他更喜欢直升机。

儿子很喜欢建筑相关的东西，喜欢看修房子，喜欢混凝土车，喜欢挖掘车。不知道他为什么会有这种奇特的喜好？似乎小孩对什么东西都是很新奇的。

儿子常常说的话是，“爸爸是老帅哥，超超是小帅哥”

儿子常常让他妈妈做的事情是，“画鱼摆摆吹泡泡”

儿子最喜欢的电视节目是每晚19点CCTV3的“动物世界”

在儿子两岁之即，特记之。

首先建一个测试表，并设置db_block_checking和db_block_checksum为false：

SQL> create table t2 (a int) tablespace test;

表已创建。
SQL> alter system set db_block_checking=false;

系统已更改。

SQL> alter system set db_block_checksum=false;

向测试表T2中四次分别插入100，000行数据：

SQL> begin
2 for i in 1..100000 loop
3 insert into t2 values(i);
4 end loop;
5 end;
6 /

PL/SQL 过程已成功完成。

已用时间: 00: 00: 06.02
SQL> commit;

提交完成。

已用时间: 00: 00: 00.00
SQL> alter system checkpoint;

系统已更改。

已用时间: 00: 00: 01.02
SQL> begin
2 for i in 1..100000 loop
3 insert into t2 values(i);
4 end loop;
5 end;
6 /

PL/SQL 过程已成功完成。

已用时间: 00: 00: 05.04
SQL> commit;

提交完成。

已用时间: 00: 00: 00.00
SQL> alter system checkpoint;

系统已更改。

已用时间: 00: 00: 01.02
SQL> begin
2 for i in 1..100000 loop
3 insert into t2 values(i);
4 end loop;
5 end;
6 /

PL/SQL 过程已成功完成。

已用时间: 00: 00: 07.04
SQL> commit;

提交完成。

已用时间: 00: 00: 00.00
SQL> alter system checkpoint;

系统已更改。

已用时间: 00: 00: 01.01
SQL> begin
2 for i in 1..100000 loop
3 insert into t2 values(i);
4 end loop;
5 end;
6 /

PL/SQL 过程已成功完成。

已用时间: 00: 00: 07.04
SQL> commit;

提交完成。

已用时间: 00: 00: 00.00
SQL> alter system checkpoint;

系统已更改。

已用时间: 00: 00: 01.01

四次数据插入中，最长的时间为7.04秒，最短时间为5.05秒，平均6.29秒。

下面再看看将这两个参数设置为true的测试结果：

SQL> alter system set db_block_checking=true;

系统已更改。

SQL> alter system set db_block_checksum=true;

系统已更改。

SQL> begin
2 for i in 1..100000 loop
3 insert into t2 values(i);
4 end loop;
5 end;
6 /

PL/SQL 过程已成功完成。

已用时间: 00: 00: 11.02
SQL> commit;

提交完成。

已用时间: 00: 00: 00.00
SQL> alter system checkpoint;

系统已更改。

已用时间: 00: 00: 01.02
SQL> begin
2 for i in 1..100000 loop
3 insert into t2 values(i);
4 end loop;
5 end;
6 /

PL/SQL 过程已成功完成。

已用时间: 00: 00: 12.01
SQL> commit;

提交完成。

已用时间: 00: 00: 00.00
SQL> alter system checkpoint;

系统已更改。

已用时间: 00: 00: 01.02
SQL> begin
2 for i in 1..100000 loop
3 insert into t2 values(i);
4 end loop;
5 end;
6 /

PL/SQL 过程已成功完成。

已用时间: 00: 00: 09.00
SQL> commit;

提交完成。

已用时间: 00: 00: 00.00
SQL> alter system checkpoint;

系统已更改。

已用时间: 00: 00: 01.04
SQL> begin
2 for i in 1..100000 loop
3 insert into t2 values(i);
4 end loop;
5 end;
6 /

PL/SQL 过程已成功完成。

已用时间: 00: 00: 11.04
SQL> commit;

提交完成。

已用时间: 00: 00: 00.00
SQL> alter system checkpoint;

系统已更改。

已用时间: 00: 00: 01.02

在上面的测试中，四次数据插入，最长的时间为12.01秒，最短时间为9.00秒，平均为10.77秒。

可以看出，这两者的差别是相当显著的，这两者参数设置为false时比设置为true竟然快了40%以上。不过这只是个简单的测试，实际情况可能没那么突出，但差异在10%以上是有可能的。

值得注意的是，性能上的差异，主要是由于CPU的消耗造成的，对于CPU资源不足的系统，将这两个参数设置为TRUE无疑会增大CPU的负担，引起性能问题。同时还会引起redo copy latch的持有时间增加和引起这个latch的竞争。

另外，由于不管db_block_checking和db_block_checksum这两个参数的值为何值，SYSTEM表空间都会进行做checking和checksum，除非把隐含参数_db_always_check_system_ts设置为FALSE，当然为了SYSTEM表空间数据安全，不建议将这个隐含参数值设置为FALSE。因此，不要将用户表和索引放到SYSTEM空间中。

在启用一起特定的功能后，SYSTEM表空间中一些表和索引会增长很快。比如启用了审计并且将审计日志存储到数据库中，则AUD$和FGA_LOG$会迅速增长；如果使用高级复制，DEF$_AQCALL表会增加很快，并且如果要复制的数据量比较大，则这个表上的DML是非常多的，在这样的情况会下，会消耗更多的CPU和引起性能降低。如果使用了审计和高级复制，建议将AUD$