AnySQL.net

    前面遇到一个排序的问题后, 昨天在数据库中做一了下调优, 将数据库的内存排序的次数从每秒的550次减少到330次左右, 并临控数据库的负荷, 很失望地发现对于降底数据库的负荷并没有什么作用, 甚至于还变高了一些, 由于没有发现明显的效果, 因此马上取消了所有的调优操作, 返回到原来的状态.

    今天早上一来, 就做了以下测试, 首先是不需要排序时的情况:

ASQL> @TEST.SQL
ASQL> BEGIN /* Test no sorting */
    2  FOR I IN 1..10000 LOOP
    3      FOR REC IN (SELECT * FROM TEST_SORT WHERE COL2=10 AND PKEY=0
    4        AND COL1 IN (810,510,210) ORDER BY COL1) LOOP
    5        NULL;
    6      END LOOP;
    7  END LOOP;
    8 END;
    9 /

Procedure executed.
Execute time: 00:00:05.479

Statistics
---------------------------------------------------
        445  CPU used by this session
        120K  consistent gets
        10K  execute count
          1  sorts (memory)

ASQL> /

Procedure executed.
Execute time: 00:00:05.438

Statistics
---------------------------------------------------
        442  CPU used by this session
        120K  consistent gets
        10K  execute count
          1  sorts (memory)

    先来说一下时间单位和简写:

1, centi-代表"百分之一", 所以cs表示百分之一秒

2, milli-代表"千分之一", 所以ms表示千分之一秒

3, micro-代表"百万分之一", 所以us表示百万分之一秒

    我一直搞不清楚V$SYSSTAT中的CPU used by this session和V$SQL中的CPU_TIME一列的时间单位是什么, 今天就写一下来帮助自已记得更清楚一些, 查阅Oracle 9i的数据库参考手册后, 终于搞明白了:

1, V$SYSSTAT或V$SESSTAT中的CPU used by this session的单位是百分之一秒(cs)

2, V$SQL中的CPU_TIME一列中用的是百万分之一秒(us)

    从我的工具的运行状况来看, V$SQL的CPU_TIME采用百万分之一秒(us)的单位实在是太小了, 导至这个列的值经常溢出, 也就是后一个时间点的值减前一个时间点的值后居然是负值(在这儿我用的是2分钟的采样频率), 如果是15分钟或以上间隔的STATSPACK的信息, 我相信这个列的数据是不准确的, 或许应当采用大一些的计量单位.

    查了一下10g(R2)的数据库参考手册, 和上面说的一样, 没有变动.

    最近在用RMAN拷贝数据文件时, 经常遇到这样的错误:

RMAN> copy  datafile 'a.dbf' to 'b.dbf';
Starting copy at 06-SEP-06
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=644 devtype=DISK
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of copy command at 09/06/2006 19:31:09
ORA-00235: controlfile fixed table inconsistent due to concurrent update
RMAN-06010: error while looking up datafile: a.dbf

    而且最后不成功不说, 拷贝一个文件至少得10分钟, 极大地影响了进度. 最后查原因居然又是遇到Bug(2391697)了. 当你在NOCATALOG方式下用RMAN去拷贝数据文件时, 在9207以下的版本会遇到此Bug. Chao_ping说他去年去Metalink找"ORA-235"时, Oracle不承认这是个Bug, 而现在却在9.2.0.7/10.1.0.3的Bug修复列表中.

    我用的是9205版本, 后来建了一个RMAN CATALOG就没事了. 怪不得很多时侯会首先怀疑一些问题是Oracle的Bug.

    在Oracle 9i的CBO优化器中, 会对有绑定变量的SQL在硬分析时做一次Peaking, 这时如果分区表的各个分区的统计信息不一致不同能导致执行计划不同的话, Peaking就有可能出错了. 下面是我做的一个例子(9.2.0.5的库上测试的).

    创建一个测试表:

SQL> create table t_partplan
  2  (
  3    col1 number not null,
  4    col2 number not null,
  5    col3 varchar2(40),
  6    col4 varchar2(40)
  7  )
  8  partition by range(col1)
  9  (
10    partition P1 values less than (5000),
11    partition p2 values less than (maxvalue)
12  );

Table created.

    接下来插入一些数据, 建一个索引, 然后分析表, 将索引的一个分区联机重建.

    索引的键值太大的话会影响索引的效率, 还有可能出错. 但有时我们一定要为这字段建索引的话怎么办呢? 我们可以通过计算一个哈希值来实现. 比如有一个字段为NAME, 最长可能有1024个字符, 要在这个列上建一个索引的话, 可以有两种比较好的方法:

1. 增加一个字段, 如HASH_NAME, 用于保存HASH值.
2. 建一个函数索引.

    第一种方法需要有一个建在Insert或Update上的触发器来更新HASH_NAME字段, 第二种方法相对简单, 在Oracle的高版本中, 可以用第二种方法. 需要注意的是, 理论上Oracle的这个计算哈希值的算法并不能保证唯一, 因此在查询时需要注意, 需要写两个条件, 如下所示:

1. HASH_NAME = DBMS_UTILITY.GET_HASH_VALUE(:P_NAME) AND NAME=:P_NAME
2. DBMS_UTILITY.GET_HASH_VALUE(NAME) = DBMS_UTILITY.GET_HASH_VALUE(:P_NAME) AND NAME = :P_NAME

    另外在数据库升级中, 可能会升级这些系统包的定义, 因此函数索引可能会失效, 这是一个要注意的地方; 另外一个是哈希值的算法在不同的版本可能会变, 因此需要提前检查一下, 在升级后选择重新计算值或是重建一下函数索引.

    其他缺点是只能用等于来查找, 否则无法利用索引.