对index直接rebuild的时候一定会是index fast full scan吗？

呵呵，当然不是，我们来看一个反例：

SQL> create table testindex

  2  (pvalue varchar2(1),

  3   pkey number)

  4  partition by range (pkey)

  5  (

  6  partition testindex_part_1 values less than (2)

  7  tablespace TESTTBS1,

  8  partition testindex_part_2 values less than (3)

  9  tablespace TESTTBS2

 10  )

 11  enable row movement;

Table created

SQL> insert into testindex values('a',1);

1 row inserted

SQL> insert into testindex values('b',1);

1 row inserted

SQL> insert into testindex values('c',2);

1 row inserted

SQL> insert into testindex values('d',2);

1 row inserted

SQL> commit;

Commit complete

SQL> create index idx_testindex_pvalue on testindex(pvalue);

Index created

我把pvalue='a'的那条记录的pkey由1改为2，这时候因为上述分区在不同的表空间下，所以索引idx_testindex_pvalue中对应于键值为'a'的global rowid一定会变。

好了，我们来验证一下：

未改之前：

row#0[8017] flag: -----, lock: 0

col 0; len 1; (1):  61

col 1; len 10; (10):  00 01 50 dd 21 80 07 99 00 00

row#1[8002] flag: -----, lock: 0

col 0; len 1; (1):  62

col 1; len 10; (10):  00 01 50 dd 21 80 07 99 00 01

row#2[7987] flag: -----, lock: 0

col 0; len 1; (1):  63

col 1; len 10; (10):  00 01 50 de 22 00 11 19 00 00

row#3[7972] flag: -----, lock: 0

col 0; len 1; (1):  64

col 1; len 10; (10):  00 01 50 de 22 00 11 19 00 01

SQL> update testindex set pkey=2 where pvalue='a';

1 row updated

SQL> commit;

Commit complete

SQL> select * from testindex;

PVALUE       PKEY

------ ----------

b               1

c               2

d               2

a               2

改过之后：

row#0[8017] flag: ---D-, lock: 2

col 0; len 1; (1):  61

col 1; len 10; (10):  00 01 50 dd 21 80 07 99 00 00

row#1[7957] flag: -----, lock: 2

col 0; len 1; (1):  61

col 1; len 10; (10):  00 01 50 de 22 00 11 19 00 02

row#2[8002] flag: -----, lock: 0

col 0; len 1; (1):  62

col 1; len 10; (10):  00 01 50 dd 21 80 07 99 00 01

row#3[7987] flag: -----, lock: 0

col 0; len 1; (1):  63

col 1; len 10; (10):  00 01 50 de 22 00 11 19 00 00

row#4[7972] flag: -----, lock: 0

col 0; len 1; (1):  64

col 1; len 10; (10):  00 01 50 de 22 00 11 19 00 01

这里我们可以从trace文件中看到索引idx_testindex_pvalue中对于键值为'a'的global rowid已经由00 01 50 dd 21 80 07 99 00 00变成了00 01 50 de 22 00 11 19 00 02。

现在我们重建上述index，再来验证将上述index设为unusable的情况下索引idx_testindex_pvalue中对应于键值为'a'的global rowid是否会变？

SQL> update testindex set pkey=1 where pvalue='a';

1 row updated

SQL> commit;

Commit complete

SQL> select * from testindex;

PVALUE       PKEY

------ ----------

b               1

a               1

c               2

d               2

SQL> drop index idx_testindex_pvalue;

Index dropped

SQL> create index idx_testindex_pvalue on testindex(pvalue);

Index created

未改之前：

row#0[8017] flag: -----, lock: 0

col 0; len 1; (1):  61

col 1; len 10; (10):  00 01 50 dd 21 80 07 99 00 02

row#1[8002] flag: -----, lock: 0

col 0; len 1; (1):  62

col 1; len 10; (10):  00 01 50 dd 21 80 07 99 00 01

row#2[7987] flag: -----, lock: 0

col 0; len 1; (1):  63

col 1; len 10; (10):  00 01 50 de 22 00 11 19 00 00

row#3[7972] flag: -----, lock: 0

col 0; len 1; (1):  64

col 1; len 10; (10):  00 01 50 de 22 00 11 19 00 01

SQL> alter index idx_testindex_pvalue unusable;

Index altered

SQL> update testindex set pkey=2 where pvalue='a';

update testindex set pkey=2 where pvalue='a'

ORA-01502: index 'DRAS.IDX_TESTINDEX_PVALUE' or partition of such index is in unusable state

SQL> ALTER SESSION SET SKIP_UNUSABLE_INDEXES = TRUE;

Session altered

SQL> update testindex set pkey=2 where pvalue='a';

1 row updated

SQL> commit;

Commit complete

SQL> select * from testindex;

PVALUE       PKEY

------ ----------

b               1

c               2

d               2

a               2

改过之后：

row#0[8017] flag: -----, lock: 0

col 0; len 1; (1):  61

col 1; len 10; (10):  00 01 50 dd 21 80 07 99 00 02

row#1[8002] flag: -----, lock: 0

col 0; len 1; (1):  62

col 1; len 10; (10):  00 01 50 dd 21 80 07 99 00 01

row#2[7987] flag: -----, lock: 0

col 0; len 1; (1):  63

col 1; len 10; (10):  00 01 50 de 22 00 11 19 00 00

row#3[7972] flag: -----, lock: 0

col 0; len 1; (1):  64

col 1; len 10; (10):  00 01 50 de 22 00 11 19 00 01

可以从结果里看到，这时候当我将上述index设为unusable的情况下索引idx_testindex_pvalue中对应于键值为'a'的global rowid没有变！

这时候如果我们rebuild online的话是能修正上述错误的，因为rebuild online走的是全表扫描。但是如果我们只是rebuild，因为rebuild走的是index fast full scan，那这里oracle能正确的修正上述global rowid的错误吗？我们来验证一下：

SQL> alter index idx_testindex_pvalue rebuild;

Index altered

rebuild之后：

row#0[8017] flag: -----, lock: 0

col 0; len 1; (1):  61

col 1; len 10; (10):  00 01 50 de 22 00 11 19 00 03

row#1[8002] flag: -----, lock: 0

col 0; len 1; (1):  62

col 1; len 10; (10):  00 01 50 dd 21 80 07 99 00 01

row#2[7987] flag: -----, lock: 0

col 0; len 1; (1):  63

col 1; len 10; (10):  00 01 50 de 22 00 11 19 00 00

row#3[7972] flag: -----, lock: 0

col 0; len 1; (1):  64

col 1; len 10; (10):  00 01 50 de 22 00 11 19 00 01

从结果里我们可以看到，即便我这里用的是rebuild，oracle这里也已经将上述global rowid的错误修正。

为什么会这样？

很简单，因为在index是unusable的情况下，即使是直接rebuild，oracle这里也会走全表扫描。

SQL> select status from dba_indexes where index_name='IDX_TESTINDEX_PVALUE';

STATUS

--------

VALID

SQL> explain plan for alter index idx_testindex_pvalue rebuild;

Explained

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

| Id  | Operation              |  Name                 | Rows  | Bytes | Cost  |

--------------------------------------------------------------------------------

|   0 | ALTER INDEX STATEMENT  |                       |  9802 | 19604 |    13 |

|   1 |  INDEX BUILD NON UNIQUE| IDX_TESTINDEX_PVALUE  |       |       |       |

|   2 |   SORT CREATE INDEX    |                       |  9802 | 19604 |       |

|   3 |    INDEX FAST FULL SCAN| IDX_TESTINDEX_PVALUE  |  9802 | 19604 |       |

--------------------------------------------------------------------------------

Note: cpu costing is off, PLAN_TABLE' is old version

11 rows selected

SQL> alter index idx_testindex_pvalue unusable;

Index altered

SQL> select status from dba_indexes where index_name='IDX_TESTINDEX_PVALUE';

STATUS

--------

UNUSABLE

SQL> explain plan for alter index idx_testindex_pvalue rebuild;

Explained

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

| Id  | Operation              |  Name                 | Rows  | Bytes | Cost  |

--------------------------------------------------------------------------------

|   0 | ALTER INDEX STATEMENT  |                       |  9802 | 19604 |    13 |

|   1 |  INDEX BUILD NON UNIQUE| IDX_TESTINDEX_PVALUE  |       |       |       |

|   2 |   SORT CREATE INDEX    |                       |  9802 | 19604 |       |

|   3 |    PARTITION RANGE ALL |                       |       |       |       |

|   4 |     TABLE ACCESS FULL  | TESTINDEX             |  9802 | 19604 |    13 |

--------------------------------------------------------------------------------

Note: cpu costing is off, PLAN_TABLE' is old version

12 rows selected

在"利用10053分析执行计划的一个例子"这篇文章里，我提到----"这个默认值不是固定的，感觉这里这个默认值取决于Blks"。

当时为什么这么说是因为我看到的所有关于10053的文章中都或直接或隐约的指出当没有统计信息的时候，oracle是根据Blks来计算默认的统计信息。

呵呵，这个观点误导了我，我们来看一下真相是什么。

SQL> create table tb0624 (type number,ts timestamp) pctfree 90;

Table created

SQL> begin

  2  for i in 1..10000 loop

  3  insert into tb0624 values (1,sysdate);

  4  insert into tb0624 values (3,sysdate);

  5  end loop;

  6  commit;

  7  end;

  8  /

PL/SQL procedure successfully completed

SQL> begin

  2  for i in 1..10 loop

  3  insert into tb0624 values (2,sysdate);

  4  end loop;

  5  commit;

  6  end;

  7  /

PL/SQL procedure successfully completed

SQL> exec dbms_stats.gather_table_stats('IPRA','TB0624',CASCADE=>FALSE,METHOD_OPT => 'FOR ALL INDEXED COLUMNS')

PL/SQL procedure successfully completed

SQL> SELECT NUM_ROWS,BLOCKS,AVG_ROW_LEN FROM USER_TABLES WHERE TABLE_NAME='TB0624';

  NUM_ROWS     BLOCKS AVG_ROW_LEN

---------- ---------- -----------

     20010        438          14

SQL> create index idx_type on tb0624(type);

Index created

这里我们分别修改NUM_ROWS，BLOCKS和AVG_ROW_LEN，以便来看看ix_sel到底取决于哪个值。

1、修改#Blks后的10053：

SQL> exec dbms_stats.set_table_stats(ownname => 'IPRA',tabname => 'TB0624',numblks => 538);

PL/SQL procedure successfully completed

SQL> SELECT NUM_ROWS,BLOCKS,AVG_ROW_LEN FROM USER_TABLES WHERE TABLE_NAME='TB0624';

  NUM_ROWS     BLOCKS AVG_ROW_LEN

---------- ---------- -----------

     20010        538          14

***************************************

BASE STATISTICAL INFORMATION

***********************

Table Stats::

  Table: TB0624  Alias: TB0624

    #Rows: 20010  #Blks:  538  AvgRowLen:  14.00

Index Stats::

  Index: IDX_TYPE  Col#: 1

    LVLS: 1  #LB: 40  #DK: 3  LB/K: 13.00  DB/K: 267.00  CLUF: 801.00

***************************************

SINGLE TABLE ACCESS PATH

  Column (#1): TYPE(NUMBER)  NO STATISTICS (using defaults)

    AvgLen: 22.00 NDV: 625 Nulls: 0 Density: 0.0015992

  Table: TB0624  Alias: TB0624    

    Card: Original: 20010  Rounded: 200  Computed: 200.10  Non Adjusted: 200.10

  Access Path: TableScan

    Cost:  121.28  Resp: 121.28  Degree: 0

      Cost_io: 119.00  Cost_cpu: 7837335

      Resp_io: 119.00  Resp_cpu: 7837335

  Access Path: index (AllEqGuess)

    Index: IDX_TYPE

    resc_io: 17.00  resc_cpu: 151884

    ix_sel: 0.004  ix_sel_with_filters: 0.004

    Cost: 17.04  Resp: 17.04  Degree: 1

  Best:: AccessPath: IndexRange  Index: IDX_TYPE

         Cost: 17.04  Degree: 1  Resp: 17.04  Card: 200.10  Bytes: 0

可以看到，当我在只改变#Blks的情况下，ix_sel的值未变。

2、修改#Rows后的10053

SQL> exec dbms_stats.set_table_stats(ownname => 'IPRA',tabname => 'TB0624',numblks => 438,numrows => 30010);

PL/SQL procedure successfully completed

SQL> SELECT NUM_ROWS,BLOCKS,AVG_ROW_LEN FROM USER_TABLES WHERE TABLE_NAME='TB0624';

  NUM_ROWS     BLOCKS AVG_ROW_LEN

---------- ---------- -----------

     30010        438          14

***************************************

BASE STATISTICAL INFORMATION

***********************

Table Stats::

  Table: TB0624  Alias: TB0624

    #Rows: 30010  #Blks:  438  AvgRowLen:  14.00

Index Stats::

  Index: IDX_TYPE  Col#: 1

    LVLS: 1  #LB: 40  #DK: 3  LB/K: 13.00  DB/K: 267.00  CLUF: 801.00

***************************************

SINGLE TABLE ACCESS PATH

  Column (#1): TYPE(NUMBER)  NO STATISTICS (using defaults)

    AvgLen: 22.00 NDV: 938 Nulls: 0 Density: 0.0010663

  Table: TB0624  Alias: TB0624    

    Card: Original: 30010  Rounded: 300  Computed: 300.10  Non Adjusted: 300.10

  Access Path: TableScan

    Cost:  100.66  Resp: 100.66  Degree: 0

      Cost_io: 98.00  Cost_cpu: 9127191

      Resp_io: 98.00  Resp_cpu: 9127191

  Access Path: index (AllEqGuess)

    Index: IDX_TYPE

    resc_io: 18.00  resc_cpu: 173806

    ix_sel: 0.005999  ix_sel_with_filters: 0.005999

    Cost: 18.05  Resp: 18.05  Degree: 1

  Best:: AccessPath: IndexRange  Index: IDX_TYPE

         Cost: 18.05  Degree: 1  Resp: 18.05  Card: 300.10  Bytes: 0

可以看到，当我在只改变#ROWS的情况下，ix_sel的值已经发生了改变。

3、修改AvgRowLen后的10053：

SQL> exec dbms_stats.set_table_stats(ownname => 'IPRA',tabname => 'TB0624',numblks => 438,numrows => 20010,avgrlen => 24);

PL/SQL procedure successfully completed

SQL> SELECT NUM_ROWS,BLOCKS,AVG_ROW_LEN FROM USER_TABLES WHERE TABLE_NAME='TB0624';

  NUM_ROWS     BLOCKS AVG_ROW_LEN

---------- ---------- -----------

     20010        438          24

***************************************

BASE STATISTICAL INFORMATION

***********************

Table Stats::

  Table: TB0624  Alias: TB0624

    #Rows: 20010  #Blks:  438  AvgRowLen:  24.00

Index Stats::

  Index: IDX_TYPE  Col#: 1

    LVLS: 1  #LB: 40  #DK: 3  LB/K: 13.00  DB/K: 267.00  CLUF: 801.00

***************************************

SINGLE TABLE ACCESS PATH

  Column (#1): TYPE(NUMBER)  NO STATISTICS (using defaults)

    AvgLen: 22.00 NDV: 625 Nulls: 0 Density: 0.0015992

  Table: TB0624  Alias: TB0624    

    Card: Original: 20010  Rounded: 200  Computed: 200.10  Non Adjusted: 200.10

  Access Path: TableScan

    Cost:  100.08  Resp: 100.08  Degree: 0

      Cost_io: 98.00  Cost_cpu: 7125191

      Resp_io: 98.00  Resp_cpu: 7125191

  Access Path: index (AllEqGuess)

    Index: IDX_TYPE

    resc_io: 17.00  resc_cpu: 151884

    ix_sel: 0.004  ix_sel_with_filters: 0.004

    Cost: 17.04  Resp: 17.04  Degree: 1

  Best:: AccessPath: IndexRange  Index: IDX_TYPE

         Cost: 17.04  Degree: 1  Resp: 17.04  Card: 200.10  Bytes: 0

可以看到，当我在只改变AvgRowLen的情况下，ix_sel的值未变。

从上述测试中我们可以很清晰的得出如下结论：

Fenng(dbanotes) posted a photo:

GreenPlum 还是给DB集群带来一些新的思路和可能的。

或许，DBA 真的不应该只关注关系数据库了。

• MySQL5.0.3开始,VARCHAR的最大存储限制已经更改为字节数，且不再存在单独的固定限制，而受到单条记录除TEXT和BLOB类型字段外最大长度不超过65536 Bytes的限制。定义的M仍是字符数，所以定义后的VARCHAR字段实际最大可存放数据长度与字符集相关的。 #
• RT: @fireshort: mysql的varchar是从哪个版本开始储存最多65535个字符的？一直记得是只能存储最多255个字符的啊。[5.0.3] #
• 今年到目前起床最早的一个周末，7:30 醒！ #
• RT: @chagel: rt @virushuo上海塌房事件直播 http://is.gd/1fi3z [这幢房子倒得还真是很整齐啊，幸好还没有人入住，否则...] #
• RT:@kimihuang: 为了纪念MJ，今晚晚上去跑西湖了，从北山路开始，苏堤一个往返…在上白堤…在edushi.com上测量了一下，刚好10公里 (via @karlzheng)关键是用多少时间。10公里不多，我晨跑也有5公里呢[锻炼身体的长跑在于慢而久，而不是快] #
• RT: @eygle: 据说 Oracle Database 11gr2下个月亚洲将举行新闻发布会 #
• RT: @esunchien: 迈克尔·杰克逊的唱片和传记要大卖了。 #
• RT: @esunchien: … RT @momoran80: RT: @huairen: RT @virushuo: 强烈谴责百度 http://is.gd/1cKCd 【未成年人请勿点击，成人教育图片，当然出品人：更懂中文的那口子】[很强大] #
• RT:@Fenng:方滨兴，首先提出了建设国家网络与信息安全基础设施的理念，并组织研制、实现了相应的系统…在信息安全理论方面，将涉及了物理、运行(网络安全）、数据（狭义的信息安全）及内容的信息安全概念给出了统一的形式化定义…[是要人肉么？] #
• RT: @Fenng: 寻找 Zion http://www.dbanotes.net/review/zion.html [这个值得一推] #
• RT: @niedongming: 刚才求证了下，原来我们公司自己架了DNS服务器，直接把google访问地址解析到了访问IP上去了。［造福大家啊，值得称颂］ #
• RT: @smallfish_xy: RT: @sky000: 太阳… Linux下通过Pidgin上msn也能中毒？【这个要顶，没遇见过】[好几个人反应总收到我MSN发出的减肥广告信息。。。] in reply to smallfish_xy #
• 太阳… Linux下通过Pidgin上msn也能中毒？ #

Powered by Twitter Tools.

No related posts.

常见的例子，表中记录按照creation_date作purge，且该字段上有个索引。

如果不加index_desc hint，purge job执行时间长了可能会越来越慢。如下consistent read明显要比current read多很多。是因为Index range scan从index tree的最左面开始扫描，扫描了很多空块。

SQL> DELETE FROM  vltb_data_0   where creation_date < (SYSDATE - 3)  and rownum < 1000;
999 rows deleted.

———————————————————-
| Id  | Operation          | Name                        |
———————————————————-
|   0 | DELETE STATEMENT   |                             |
|   1 |  DELETE            | RULE_OBJECT_ATTR_DATA_0     |
|*  2 |   COUNT STOPKEY    |                             |
|*  3 |    INDEX RANGE SCAN| RULE_OBJECT_ATTR_DATA_0_IX3 |
———————————————————-
Predicate Information (identified by operation id):
—————————————————
2 - filter(ROWNUM<1000)
3 - access(”CREATION_DATE”<SYSDATE@!-3)

Statistics
———————————————————-
1  recursive calls
21167  db block gets
427848  consistent gets
0  physical reads
1341824  redo size
1  sorts (memory)
0  sorts (disk)
999  rows processed

通过添加index_desc, Index range descending scan从index tree的中间或者右边进入扫描，更快定位到存在纪录的block.

SQL> DELETE /*+ index_desc(rule_object_attr_data_0) */ FROM  vltb_data_0   where creation_date < (SYSDATE - 3)  and rownum < 1000;
999 rows deleted.

Statistics
———————————————————-
1  recursive calls
21177  db block gets
59  consistent gets
288  physical reads
1368592  redo size
814  bytes sent via SQL*Net to client
833  bytes received via SQL*Net from client
3  SQL*Net roundtrips to/from client
1  sorts (memory)
0  sorts (disk)
999  rows processed

从而避免了无用功。这样的例子时常在工作中遇到。

—————-人工分割线————————

最近上海一个刚盖的差不多快结盘的13层房子倒了一个，整体倒的。是有一个小的房地产开发公司开发的。全国人民都知道了。

估计会对房地产市场特别是中小房地产开发公司开发的楼盘带来严重信任危机。那些早些年盖的二手房或许将火爆。

很壮观。

Amoeba 默认设置支持客户端设置编码的方式是 ： set names gbk 其他方式目前还没考虑到。

Discuz遇到编码问题，可以通过修改 include/db_mysql.class.php 里的 设置编码方式改成：

 set names utf8

 –即支持utf8编码格式

  原文来自：

http://hi.baidu.com/hlxwell/blog/item/ea0d445913af102d2834f0d5.html

该版本基于0.32版本之上进行bugs fixed,非常感谢阿权提供的一些bug列表

这次版本跳跃比较大，也是我打算在amoeba这个项目花下时间的决心。因此将amoeba提升到新的起点1.0.0版本

下面是这次主要的变更：

1、修复sql解析 explain 关键字开始的sql
2、修复FORCE INDEX (xx) 之类的sql无法解析问题
3、修复包含转义符合在内的sql 比如：insert into xx values(’\'test\’)
4、修复包含 Order by rand()的sql
5、调整默认 网络接受发送缓冲区成128k

下载地址： http://www.sf.net/projects/amoeba

作者：Fenng 发布在 dbanotes.net.

我在Twitter上的这个试验性的：每日推荐一位推友计划，已经来到了第二季。在 5月35 日那几天短暂被封之后，Twitter 用户依旧活跃。短短的消息即可迅速传递我们的情绪，表达我们的愤怒。这是这个时代最好的工具。

再次说一下推荐的几条理由：

• Twitter 背后的那个人在某个领域要有一定影响力或者有趣或是 Twitter 内容比较有价值。
• 订阅人数(followers)不超过 500 个才可能会加入推荐候选列表。如果订阅者少于100，基本发现很难形成良性互动，有的新用户就会意兴阑珊--毕竟自言自语不是很有意思的事情。而一旦超过200，就基本到了一个比较良性的循环了。对于超过500的,基本上不用推荐也会自然增长，边界效益不高。
• 非商业行为。同时避免侵犯隐私，每个人的介绍以网络可以搜索到的为准。
• 在每个工作日进行推荐，一般在下午 15:00 左右，这个时间也是公司下午茶时间，基本不影响工作。

如果要跟踪这个推荐计划，请 follow 我(@Fenng )，另请参考之前的第一季。介绍语基本上都是我拟就的，如果有不合适之处，那肯定是我没说好。如果你看到某个 Twitter 用户比较有趣，可以给我留言( @Fenng) 告诉我。

• @mujiang
  朱一, 曾是Abebook.com架构师，现 Amazon的 Database Architect，海外华人，不明白为啥总自称木匠:) 另：他友情帮我们做了TOP第四章初稿。
• @fengchunpei
  冯春培, 常年活动于ITPUB,id: biti_rainy，发帖数万... Oracle ACE，现任阿里巴巴 B2B 研究员。在国内数据库界人称大师。
• @yeka52
  周筠, 博文视点出版社(武汉)负责人，IT图书出版界奇才，众多重量级IT技术图书出自她的策划。 对所有教育及出版，以及设计相关的事情都感兴趣。
• @hdcola
  黄冬, 为国内 FreeBSD 社区默默贡献不小。曾负责过新浪研发中心的多个部门和产品，后离职创业，现在供职无限讯奇，为中国移动12580核心合作伙伴。
• @delphij
  Xin LI, FreeBSD commiter...新浪北美的，操作系统界领域的大牛
• @freebat
  王慧文, 校内网的Cofounder。现为 冒泡网 的站长。maopao.com 是一个类似 Twitter/FriendFeed 的网站，据说要做自己的特色。
• @eygle
  盖国强, 知名数据库专家, 是数本Oracle技术图书的作者。恩墨科技创建人(八卦一下，恩墨是他儿子的名字) 他的个人站点：http://www.eygle.com/ 。
• @lastmailbox
  邹欣, 微软亚洲研究院资深人士。搜索一下，你就知道！ 《移山之道》、《编程之美》(合作) 作者。 他的Blog耐看。
• @funy
  付宁, SNS第三方应用开发者与实践者，他捣鼓的 SNS 应用曾日收入$2000。Web2.0 创业人。
• @wulujia
  吴鲁加, 资深网络安全技术牛人。大成天下创建者，总经理。他的Blog：http://wulujia.com/ 。
• @milkr
  稻草, 设计师，Blogger，虾米网设计总监。 UCDChina 杭州联系人，他的Blog：http://www.v4uu.com/blog/ 。
• @chedong
  车东, 著名Blogger, 资深互联网人，前雅虎高级技术经理，前BlogBus CTO，现已加盟搜狐，任职产品总监。
• @yanhui
  阎辉, CSDN 产品总监（对CSDN有意见可以找他)。《程序员》杂志创刊就做，五年，后任CSDN执行总编。现在在做高端技术管理者社区CTO俱乐部，以及正在研究和实践基于社区的新型商务产品模型。
• @chndonny
  陈栋，来自阿里 B2B DBA 团队，技术杠杠嘀, 爱好摄影。想当年兄弟我刚到杭州的时候就借住在他的房子。
• @Crossday
  戴志康, Discuz! 创建人。80 后科技精英代表人物之一(其它几个不知道都跑哪里去了)。
• @hutuworm
  冯亮, 阿里最有趣的技术Geek之一。沉浸于 Linux 系统管理十余年，以此为业逾五载。现为运维架构师。业余偶猎文史哲社政法诸学。《Linux Network Cookbook 中文版》译者。
• @gaochunhui
  高春辉, 老网民应该都知道他，当年中国个人站长第一人。手机之家（imobile.com.cn)创建人，ECSHOP创建人... 我眼中的老高：仍然对技术有着极高热情的家伙。
• @Kimihuang
  黄航飞, 老阿里人，我们并肩为支付宝战斗过。电子产品爱好者，F1粉丝。现在在阿里妈妈(淘宝)做产品运营。擅长给支付宝找茬。他的Blog是我见过用Mac用户装修最差的一个，他的女儿比他可爱，哈
• @syutlyc
  杨帆, cnBeta.com 副站长(有IT新闻给他爆料吧)。IT Pro, 企业解决方案咨询顾问，曾在微软总部IT部门和微软中国的顾问咨询部门工作了4年。擅长微软企业服务器产品。喜好古典音乐。
• @zhuzhijun
  祝志军，互联网资深人士。TechWeb.com.cn 创建人。老祝的Blog 最近很有料：http://zhijun.techweb.com.cn/ 。
• @zhangjb
  张翼轸，潮人。我喜欢看他的Blog： http://blog.earlzhang.com/ "用理性的视角去探讨护肤品、时尚、男装、奢侈品、爱情这些风花雪月" 。
• @xdanger
  戴云杰，VeryCD 的联合创建人、CTO（有谁没有用过电驴麽?) 。技术高手，Geek。也是 Google 和苹果的粉丝。
• @arthur369
  西乔，Magicome公司创建人，提供 Web 技术开发项目外包开发及产品端顾问咨询。这位同学在2009年六月四日结婚，新郎是 @virushuo 同学 。
• @aimingoo
  周爱民, 刚加盟支付宝的牛人。国内软件开发界资深软件工程师。《Delphi源代码分析》、《大道至简》、《JAVASCRIPT语言精髓与编程实践》等图书作者。
• @Peoplecbc
  人物·志，中文网志年会人际交流平台-http://people.cnbloggercon.org/ 。
• @jinghuaz
  晶华, 前谷歌中国，现在在美国 Mozilla Labs。关于用户体验与开源软件。
• @csdncto
  蒋涛, CSDN 掌门人。《程序员》杂志总编。IT人，太极拳、围棋重度爱好者。
• @horse
  詹膑, 高校教师, 独立顾问, Blogger, 奇遇花园咖啡馆老板。典型的跨界人。
• @jeffz_cn
  赵劼, 网名老赵，洋名Jeffrey Zhao。目前担任上海柏盛网络技术有限公司架构师。InfoQ 中文站编辑。
• @zhidong
  王志东, 软件英雄。中文之星、四通利方和新浪创始人。点击科技创始人，Lava-Lava ，正在体验 Twitter 中。
• @gigix
  熊节, 笔名透明，知名 IT 技术专家，现为 Thought Works 咨询师。多本重量级图书的译者，最近的译作是《卓有成效的程序员》。
• @zhuangbiaowei
  庄表伟, 年轻的老技术人。印客网(http://www.inker.com.cn/) 技术总监。
• @anson_ho
  何烨, Geek. 独立策划人. 涉猎：网络、电台、公关、品牌、汽车。他的Blog：http://www.anson-ho.com 。
• @ShooterPlayer
  沈晟, 射手网（http://shooter.cn/）站长，射手播放器（http://splayer.org/）主要开发者。
• @jinhuang
  黄劲, 走秀网创始人之一。走秀网(http://www.zoshow.com/) 是一家定位于时尚电子商务领域的新锐网站。
• @liuyan
  今日推荐推友:刘岩, 六间房(6.cn)的创建人。刘岩参与过新浪网和亚信公司的融资和上市，并领导完成了亚信公司对杭州德康公司的收购。现任六间房CEO。

现在是广告时间：

• @BetaCafe
  贝塔咖啡馆...支持Twitter订咖啡，定期发放Twitter 优惠券
• @JobsDigg
  帮找工作 ...我的实验性项目
• @Alipay
  来自支付宝的半官方小道消息

最后，或许你应该关注一下这个" 热门锐推用户"榜

--EOF--

相关文章|Related Articles

• 怎么跑出去? 《越狱》第二季猜测 - May 16, 2006
• 数独(Sudoku) 游戏 - Sep 15, 2006
• 我的桌面 - Oct 12, 2006
• 提前的生日礼物--森海塞尔耳机 - Mar 12, 2007

评论数(6)|添加评论 | 最近作者还说了什么? Follow Fenng@Twitter
本文网址：http://www.dbanotes.net/geek/twitter_recommend_users_s2.html

DBA Notes 理念: 用简约的技术取得最大的收益...

1.1.1. 4月30日 IO优化

今天早上没什么事，明天就开始7天的五一长假了，所以我今天和公司的同事打了个招呼，今天就不过去了。这个五一节并没有什么安排，只是准备6号的时候出去跑一趟短途，要么去桔钓沙游泳，要么去巽寮湾玩玩。早上躺在床上看了会电视，才懒懒的爬起来洗脸刷牙，吃完早饭的时候已经块10点钟了。打开电脑收了下邮件，发现马工发了一封邮件给我：

老白，您好！

自月中系统好转之后，明喻真又开始冗长的不着边际的动作了。

老万和明喻关于数据库方面增加费用的谈判也没有成功，按他的说法是明喻他们负责项目的这个部门准备放弃项目了，但是销售和客户部门却坚持要把项目继续下去，而继续项目的方法不是找你商量而是通过内部挖国内外资源的办法来进行，对于你的数据库方面的计划他们也没有任何回应，把我郁闷得......

18号那天我离开青岛开始休假，直到26日回青岛，这期间关于项目的事情我一概不过问，听之任之。

现在明喻他们的动作：

1、请了一个系统测试工程师准备进行实验室测试，以“科学”的数据得出一个系统和硬件的解决方案；

2、请了新西兰的数据库专家Richard来进行数据库方面的分析和优化，以得出一个数据库方面的优化解决方案。

目前第一个动作正在准备过程中，用的是LoadRunner软件，这两天东软在学习如何用LoadRunner准备测试脚本，非常不顺利，居然来教他们用LoadRunner的工程师对于如何根据东软现在的应用架构配置LoadRunner这一步都没能跨过去，两天了，没有什么进展。

第二个动作限于英语水平我没能跟老外有更多的交流，他有几个举措：增加EVA3000的4块硬盘、增加VA7410的3块硬盘以提高IO吞吐，昨天改了一个操作系统参数，虽然没有对数据库参数进行修改，但昨晚停数据库进行系统数据和应用数据DD复制，而后在数据库重起时东软居然发现参数文件找不到了，于是用了一个旧版本的，而且后来是在奕华的协助下把数据库给起来了，害我又没有睡好觉。今天中午老蒋说找到了原来的参数文件，要重启数据库。

老万的时间要求是必须在5月31日解决问题，但是明喻做法可真是有趣啊！

我读了邮件，马上给马工打了个电话，他对目前的情况比较悲观，在老万的压力下，Richard已经准备不经过严格的测试直接开始做优化动作了。他的第一个动作就是优化IO，明喻他们已经申请好了几块硬盘，今天晚上就要实施存储的扩容，按照Richard的想法，增加磁盘的数量，让IO分布到更多的磁盘上，可以提高IO的性能。另外Richard建议取消每个REDO LOG组的镜像，改为每个组一个member，以减少IO的负担。Richard 的做法是IO性能优化中常用的办法，我也经常使用这个方法，但是在老万他们这个系统里，目前不仅仅是IO存在问题，和IO相比，更为危险的是CPU资源。一旦IO性能得到提升，每秒钟将有更多的事务被处理，那样就要消耗更多的CPU资源，一旦CPU出现了瓶颈，闩锁争用将急剧上升，数据库的整体性能不会提高反而会有所下降。

刚刚和马工通完电话，老万的电话就打了进来，他告诉我今天晚上Richard想对IO进行优化，增加几块硬盘。Richard提出的取消一个日志组成员的建议被东软拒绝了，东软他们不愿意降低系统的可靠性来换取IO成本的下降。老万问我Richard的方案我是否赞成。

我说：“万科，如果纯粹是优化IO，Richard的做法无可厚非。不过按照目前系统的情况，单独优化IO风险很大，一旦CPU过载那么后果更严重。最好是能够首先减少一些逻辑读，再进行IO优化，两个步骤一起实施才能确保万无一失。”

老万实际上也有类似的担心，于是老万希望我能够给Richard发个邮件，把这个问题和Richard说一下，看看Richard能不能考虑的充分一些再做动作。于是我马上写了封邮件给Richard。写完邮件后，我发了个短信给明喻，让明喻通知Richard收一下邮件。通过第一次和Richard的口语交流，我对自己的口语能力基本上丧失了信心。

发完邮件后一看时间已经快中午了，由于早饭吃的晚，也没有心思做午饭吃了。冰箱里还有半个西瓜，就权当我的午饭了吧。吃完西瓜回到电脑边上的时候，发现Richard已经回了邮件：

Hi Jackson,

Just following up on this message, 

I agree that if we improve IO we will run into the CPU bottleneck. The CPU is very high now. 

My reason for fixing the IO first is if we upgrade the server to faster/more CPU then we will 

not get any more performance from the server as the additional resource will be waiting IO.

So I believe that we need to change both but to change them one at a time. IO is the bottleneck now, 

then only when this is removed will we raise the processing to become a CPU bottleneck. The question 

is if we can improve the IO performance will the system performance meet the customer needs without 

the cost of the server upgrade.

As to Memory the Oracle database has over 6Gb of memory now for SGA. If this is not enough then how 

large does the memory on this system need to be?. It is already 2Gb memory per CPU so is on the larger 

size. What would your suggestion for the system memory size?

As to the code, I agree it is not only hard but expensive. I am interested in your comments re the 

tuning that you plan to do. Mingyu do you know why this has been put on hold?.

Best regards

Richard

这封信是发给我，同时抄送明喻的，很明显最后一句"Mingyu do you know why this has been put on hold?"是问明喻的。在这封邮件里Richard认为CPU和IO都需要调整，但是必须一个一个做，他准备首先从IO调整入手。Richard认为IO调整单独做没有问题，这是基于封闭系统的理论，如果平均每秒事务的数量是固定的，那么像Richard所说的一样，CPU负载不会大幅度提升。另外一种可以这么调整的情况是CPU资源比较充足。但是目前的情况恰恰都不是这两种情况，CPU已经出现了较为严重的瓶颈，但是Richard并没有意识到这一点。我在给Richard的邮件中谈到了排队效用，排队效应这个词汇是我自己创造的，可能Richard并没有明白是什么意思，我把排队效应翻译成“effect of waiting queue”，当时觉得翻译的还有点靠谱，现在看来这不是一个很准确的翻译，起码Richard并没有看懂。

今天晚上Richard要在EVA 3000上增加四块盘，组成一个RAID 0+1，在VA7400上增加3块盘，组成一个RAID 5。Richard准备把REDO LOG移到EVA3000上新创建的这个RAID 0+1大的磁盘组上，同时从EVA 3000上迁移部分写IO较多的数据文件到这个盘组上。然后会将VA7400上一部分写入较少的数据文件移到VA7400上的新增的磁盘组上，以减轻存储的负担，提高IO的性能。Richard这个动作做的很漂亮，肯定能较大幅度的提高IO的性能，不过这也正是我所担心的，Richard这一手的效果越好我越担心，我担心这哥们会把我前一阵子花了九牛二虎之力才降下来的CPU负载再折腾上去。

下午的时候，马工又给我打了一个电话，他经过一番努力，希望劝阻今天晚上的盘阵扩容操作，不过最终还是失败了。明天是5.1节，这个系统的业务量肯定会比今天有所上升，而今晚这个操作让马工十分担心，如果明天系统真的出了什么问题，那么这个5.1节都过不好了。我正和马工聊着，突然马工说：“老白，你别挂电话，万科有话和你说”。

老万第一句就问我：“老白，明天你准备去哪里玩？”

我说：“明天能上哪玩去，5.1节哪都是人，出去玩？还不如在家睡大觉。”刚说完，我就觉得好像哪里不对。还没等我补充，老万就接上话了：“那好，老白，明天你帮我盯一下系统，今天晚上这个操作我是实在不放心，你在家就好了，我也就放心了。为了今天晚上的这个扩容，我明天也只能在办公室里了，我们明天一起聊QQ”。原来老万这个老狐狸在这里等着我呢，既然前面已经说了明天在家睡觉，我也就不好推辞了，只能答应了老万，明天在家上网，陪他聊QQ。

索引跳跃式扫描（INDEX SKIP SCAN），需要在CBO模式下才能起作用，当查询谓词中不带有前导列，且前导列唯一值较少时，才有可能用上该索引扫描方式。下面来看看INDEX SKIP SCAN 是如何扫描的：

准备测试数据：

SQL> create table test(x number,y number);
 
Table created.
 
SQL> insert into test
  2  select decode(mod(rownum,2),0,1,2),rownum
  3  from dba_objects where rownum<10000;
 
9999 rows created.
 
SQL> commit;
 
Commit complete.
 
SQL> create index ind_xy on test(x,y);
 
Index created.
 
SQL> exec dbms_stats.gather_table_stats('SYS','TEST');
 
PL/SQL procedure successfully completed.
 
SQL> set autot trace exp
SQL> select * from test where y=5;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 854635220
 
---------------------------------------------------------------------------
| Id  | Operation        | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT |        |     1 |     6 |     3   (0)| 00:00:01 |
|*  1 |  INDEX SKIP SCAN | IND_XY |     1 |     6 |     3   (0)| 00:00:01 |
---------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   1 - access("Y"=5)
       filter("Y"=5)
 
SQL> select * from test where y between 1000 and 1200;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 217508114
 
--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |   202 |  1212 |     5   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| TEST |   202 |  1212 |     5   (0)| 00:00:01 |
--------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   1 - filter("Y"< =1200 AND "Y">=1000)
 
SQL> set autot off

为了让类似于“y between 1000 and 1200”的范围查询也走索引，我们修改一下统计信息：

SQL> exec dbms_stats.set_table_stats('SYS','TEST',numrows=>1000000,numblks=>3000000);
 
PL/SQL procedure successfully completed.
 
SQL> exec dbms_stats.set_index_stats('SYS','IND_XY',NUMROWS=>1000000,NUMLBLKS=>3000000);
 
PL/SQL procedure successfully completed.
 
SQL> set autot trace exp
SQL> select * from test where y between 1000 and 2500;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 854635220
 
---------------------------------------------------------------------------
| Id  | Operation        | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT |        |   150K|   880K|   407K  (1)| 10:27:02 |
|*  1 |  INDEX SKIP SCAN | IND_XY |   150K|   880K|   407K  (1)| 10:27:02 |
---------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   1 - access("Y">=1000 AND "Y"< =2500)
       filter("Y"<=2500 AND "Y">=1000)

先设置10046事件，看看读取的是哪些BLOCK：

SQL> alter system flush buffer_cache;
 
System altered.
 
SQL> oradebug setmypid
Statement processed.
SQL> oradebug event 10046 trace name context forever,level 12;
Statement processed.
SQL> select * from test where y=1000;
 
         X          Y
---------- ----------
         1       1000
 
PARSING IN CURSOR #3 len=31 dep=0 uid=0 oct=3 lid=0 tim=28576548594261 hv=3600506749 ad='3c10ae90'
select * from test where y=1000
END OF STMT
PARSE #3:c=10000,e=9280,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=28576548594242
BINDS #3:
EXEC #3:c=0,e=152,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=28576548594524
WAIT #3: nam='SQL*Net message to client' ela= 4 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=28576548594595
WAIT #3: nam='db file sequential read' ela= 74 file#=1 block#=69522 blocks=1 obj#=109868 tim=28576548594838
WAIT #3: nam='db file sequential read' ela= 106 file#=1 block#=69523 blocks=1 obj#=109868 tim=28576548595032
WAIT #3: nam='db file sequential read' ela= 18 file#=1 block#=69524 blocks=1 obj#=109868 tim=28576548595141
FETCH #3:c=0,e=533,p=3,cr=3,cu=0,mis=0,r=1,dep=0,og=1,tim=28576548595199
WAIT #3: nam='SQL*Net message from client' ela= 515 driver id=1650815232 #bytes=1 p3=0 obj#=109868 tim=28576548595798
WAIT #3: nam='db file sequential read' ela= 19 file#=1 block#=69535 blocks=1 obj#=109868 tim=28576548595905
WAIT #3: nam='db file sequential read' ela= 50 file#=1 block#=69536 blocks=1 obj#=109868 tim=28576548596016
WAIT #3: nam='db file sequential read' ela= 18 file#=1 block#=69548 blocks=1 obj#=109868 tim=28576548596098
FETCH #3:c=0,e=294,p=3,cr=5,cu=0,mis=0,r=0,dep=0,og=1,tim=28576548596129
WAIT #3: nam='SQL*Net message to client' ela= 1 driver id=1650815232 #bytes=1 p3=0 obj#=109868 tim=28576548596199
WAIT #3: nam='SQL*Net message from client' ela= 500 driver id=1650815232 #bytes=1 p3=0 obj#=109868 tim=28576548596726
STAT #3 id=1 cnt=1 pid=0 pos=1 obj=109868 op='INDEX SKIP SCAN IND_XY (cr=8 pr=6 pw=0 time=517 us)'

可以看到Block读取的顺序为：69522->69523->69524->69535->69536->69548

再来看看“y between 1000 and 2500”的BLOCK读取顺序：

select * from test where y between 1000 and 2500
WAIT #3: nam='db file sequential read' ela= 966 file#=1 block#=69522 blocks=1 obj#=109868 tim=28579403261397
WAIT #3: nam='db file sequential read' ela= 101 file#=1 block#=69523 blocks=1 obj#=109868 tim=28579403261570
WAIT #3: nam='db file sequential read' ela= 17 file#=1 block#=69524 blocks=1 obj#=109868 tim=28579403261677
WAIT #3: nam='db file sequential read' ela= 19 file#=1 block#=69525 blocks=1 obj#=109868 tim=28579403274372
WAIT #3: nam='db file sequential read' ela= 19 file#=1 block#=69526 blocks=1 obj#=109868 tim=28579403291497
WAIT #3: nam='db file sequential read' ela= 19 file#=1 block#=69535 blocks=1 obj#=109868 tim=28579403294076
WAIT #3: nam='db file sequential read' ela= 51 file#=1 block#=69536 blocks=1 obj#=109868 tim=28579403294187
WAIT #3: nam='db file sequential read' ela= 18 file#=1 block#=69537 blocks=1 obj#=109868 tim=28579403297464
WAIT #3: nam='db file sequential read' ela= 19 file#=1 block#=69538 blocks=1 obj#=109868 tim=28579403313975
WAIT #3: nam='db file sequential read' ela= 20 file#=1 block#=69548 blocks=1 obj#=109868 tim=28579403325960

为69522->69523->69524->69525->69526->69535->69536->69537->69538->69548

我们先将几个重要的BLOCK DUMP出来，再来分析下INDEX SKIP SCAN为何是这样读取的。
查询首先读取的分支节点69522：

Branch block dump
=================
header address 9223372041152863300=0x80000001002f9c44
kdxcolev 1
KDXCOLEV Flags = - - -
kdxcolok 0
kdxcoopc 0x80: opcode=0: iot flags=--- is converted=Y
kdxconco 3
kdxcosdc 0
kdxconro 25
kdxcofbo 78=0x4e
kdxcofeo 7741=0x1e3d
kdxcoavs 7663
kdxbrlmc 4263827=0x410f93
kdxbrsno 0
kdxbrbksz 8040 
kdxbr2urrc 0
row#0[8028] dba: 4263828=0x410f94 ##BLOCK：69524
col 0; len 2; (2):  c1 02
col 1; len 3; (3):  c2 09 05      对应Y值804
col 2; TERM
row#1[8017] dba: 4263829=0x410f95 ##BLOCK：69525
col 0; len 2; (2):  c1 02
col 1; len 2; (2):  c2 11         对应Y值1600
col 2; TERM
row#2[8005] dba: 4263830=0x410f96 ##BLOCK：69526
col 0; len 2; (2):  c1 02
col 1; len 3; (3):  c2 18 61      对应Y值2396
col 2; TERM
row#3[7993] dba: 4263831=0x410f97 ##BLOCK：69527
col 0; len 2; (2):  c1 02
col 1; len 3; (3):  c2 20 5d      对应Y值3192
col 2; TERM
row#4[7981] dba: 4263832=0x410f98
col 0; len 2; (2):  c1 02
col 1; len 3; (3):  c2 28 59
col 2; TERM
row#5[7969] dba: 4263833=0x410f99
col 0; len 2; (2):  c1 02
col 1; len 3; (3):  c2 30 55
col 2; TERM
row#6[7957] dba: 4263834=0x410f9a
col 0; len 2; (2):  c1 02
col 1; len 3; (3):  c2 38 51
col 2; TERM
row#7[7945] dba: 4263835=0x410f9b
col 0; len 2; (2):  c1 02
col 1; len 3; (3):  c2 40 4d
col 2; TERM
row#8[7933] dba: 4263836=0x410f9c
col 0; len 2; (2):  c1 02
col 1; len 3; (3):  c2 48 49
col 2; TERM
row#9[7921] dba: 4263837=0x410f9d
col 0; len 2; (2):  c1 02
col 1; len 3; (3):  c2 50 45
col 2; TERM
row#10[7909] dba: 4263838=0x410f9e
col 0; len 2; (2):  c1 02
col 1; len 3; (3):  c2 58 41
col 2; TERM
row#11[7897] dba: 4263839=0x410f9f ##BLOCK：69535
col 0; len 2; (2):  c1 02
col 1; len 3; (3):  c2 60 3d      对应Y值9560
col 2; TERM
row#12[7885] dba: 4263840=0x410fa0 ##BLOCK：69536
col 0; len 2; (2):  c1 03
col 1; len 3; (3):  c2 04 40      对应Y值363
col 2; TERM
row#13[7873] dba: 4263841=0x410fa1 ##BLOCK：69537
col 0; len 2; (2):  c1 03
col 1; len 3; (3):  c2 0c 3c      对应Y值1159
col 2; TERM
row#14[7861] dba: 4263842=0x410fa2 ##BLOCK：69538
col 0; len 2; (2):  c1 03
col 1; len 3; (3):  c2 14 38      对应Y值1955
col 2; TERM
row#15[7849] dba: 4263843=0x410fa3 ##BLOCK：69539
col 0; len 2; (2):  c1 03
col 1; len 3; (3):  c2 1c 34       对应Y值2751
col 2; TERM
row#16[7837] dba: 4263844=0x410fa4
col 0; len 2; (2):  c1 03
col 1; len 3; (3):  c2 24 30
col 2; TERM
row#17[7825] dba: 4263845=0x410fa5
col 0; len 2; (2):  c1 03
col 1; len 3; (3):  c2 2c 2c
col 2; TERM
row#18[7813] dba: 4263846=0x410fa6
col 0; len 2; (2):  c1 03
col 1; len 3; (3):  c2 34 28
col 2; TERM
row#19[7801] dba: 4263847=0x410fa7
col 0; len 2; (2):  c1 03
col 1; len 3; (3):  c2 3c 24
col 2; TERM
row#20[7789] dba: 4263848=0x410fa8
col 0; len 2; (2):  c1 03
col 1; len 3; (3):  c2 44 20
col 2; TERM
row#21[7777] dba: 4263849=0x410fa9
col 0; len 2; (2):  c1 03
col 1; len 3; (3):  c2 4c 1c
col 2; TERM
row#22[7765] dba: 4263850=0x410faa
col 0; len 2; (2):  c1 03
col 1; len 3; (3):  c2 54 18
col 2; TERM
row#23[7753] dba: 4263851=0x410fab
col 0; len 2; (2):  c1 03
col 1; len 3; (3):  c2 5c 14
col 2; TERM
row#24[7741] dba: 4263852=0x410fac ##对应BLOCK：69548
col 0; len 2; (2):  c1 03
col 1; len 3; (3):  c2 64 10       对应Y值9915
col 2; TERM
----- end of branch block dump -----

再DUMP出BLOCK：69535，可以看出该BLOCK有X值为1的索引条目，也有X值为2的索引条目，我们可以这样认为，该BLOCK是索引中X值为1的最左边，X值为2的最右边：

Leaf block dump
===============
header address 9223372041152863324=0x80000001002f9c5c
kdxcolev 0
KDXCOLEV Flags = - - -
kdxcolok 0
kdxcoopc 0x80: opcode=0: iot flags=--- is converted=Y
kdxconco 3
kdxcosdc 0
kdxconro 401
kdxcofbo 838=0x346
kdxcofeo 1654=0x676
kdxcoavs 816
kdxlespl 0
kdxlende 0
kdxlenxt 4263840=0x410fa0
kdxleprv 4263838=0x410f9e
kdxledsz 0
kdxlebksz 8016
row#0[8000] flag: ------, lock: 0, len=16
col 0; len 2; (2):  c1 02
col 1; len 3; (3):  c2 60 3d
col 2; len 6; (6):  00 41 0f 89 01 cd
row#1[7984] flag: ------, lock: 0, len=16
col 0; len 2; (2):  c1 02
col 1; len 3; (3):  c2 60 3f
col 2; len 6; (6):  00 41 0f 89 01 cf
..........................................
.................省略部份.................
..........................................
row#217[4532] flag: ------, lock: 0, len=16
col 0; len 2; (2):  c1 02
col 1; len 3; (3):  c2 64 5f
col 2; len 6; (6):  00 41 0f 8a 01 21
row#218[4516] flag: ------, lock: 0, len=16
col 0; len 2; (2):  c1 02
col 1; len 3; (3):  c2 64 61
col 2; len 6; (6):  00 41 0f 8a 01 23
row#219[4500] flag: ------, lock: 0, len=16
col 0; len 2; (2):  c1 02                  X：1
col 1; len 3; (3):  c2 64 63               Y：9998（X为1时，Y的最大值）
col 2; len 6; (6):  00 41 0f 8a 01 25
row#220[4485] flag: ------, lock: 0, len=15
col 0; len 2; (2):  c1 03                  X：2
col 1; len 2; (2):  c1 02                  Y：1 （X为2时，Y的最小值）
col 2; len 6; (6):  00 41 0e da 00 00
row#221[4470] flag: ------, lock: 0, len=15
col 0; len 2; (2):  c1 03
col 1; len 2; (2):  c1 04
col 2; len 6; (6):  00 41 0e da 00 02
row#222[4455] flag: ------, lock: 0, len=15
col 0; len 2; (2):  c1 03
col 1; len 2; (2):  c1 06
col 2; len 6; (6):  00 41 0e da 00 04
..........................................
.................省略部份.................
..........................................
row#400[1654] flag: ------, lock: 0, len=16
col 0; len 2; (2):  c1 03
col 1; len 3; (3):  c2 04 3e
col 2; len 6; (6):  00 41 0e da 01 68
----- end of leaf block dump -----
 
SQL> select max(y) from test where x=1;
 
    MAX(Y)
----------
      9998
SQL> select dump(9998,16) from dual;    
 
DUMP(9998,16)
---------------------
Typ=2 Len=3: c2,64,63

从上面这些trace中可以看出，查询读取了Branch block后，便分别在X值为1，及X值为2的两个范围内的leaf block中进行扫描。例如查询，y=1000,读取顺序为：

69522->69523->69524->69535->69536->69548：
 
69522 Branch block
 
69523 X值为1的leaf block的起始BLOCK
69524 Y值范围为804至1599,所以1000可能在其中，需要读取
 
69535 X值为1的leaf block的结束BLOCK，及X值为2的leaf block的起始BLOCK
 
69536 Y值范围为363至1158,所以1000可能在其中，需要读取
69548 X值为2的leaf block的结束BLOCK

查询，y between 1000 and 2500 读取顺序为：

69522->69523->69524->69525->69526->69535->69536->69537->69538->69548
 
69522 Branch block
 
69523         X值为1的leaf block的起始BLOCK
69524 - 69526 Y值范围为804至3191,“y between 1000 and 2500”可能在其中，需要读取
 
69535         X值为1的leaf block的结束BLOCK，及X值为2的leaf block的起始BLOCK
 
69536 - 69538 Y值范围为363至2750,“y between 1000 and 2500”可能在其中，需要读取
69548         X值为2的leaf block的结束BLOCK

我们可以这样认为，INDEX SKIP SCAN就相当于要在X=1及X=2的两个子索引(也可以说是虚拟索引）中进行扫索，因而，前导列X如果有多个不同的值，就要在多个不同的子索引中进行扫描，个数越多，代价也越高，优化器最终也就不会选择使用INDEX SKIP SCAN了。例如，我们更改X的唯一值为10000，查询就不再采用INDEX SKIP SCAN：

SQL> exec dbms_stats.SET_COLUMN_STATS('SYS','TEST','X',DISTCNT=>10000);
 
PL/SQL procedure successfully completed.
 
SQL> select * from test where y=1000;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 1066898076
 
-------------------------------------------------------------------------------
| Id  | Operation            | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |        |   100 |   600 |   389K  (1)| 14:06:10 |
|*  1 |  INDEX FAST FULL SCAN| IND_XY |   100 |   600 |   389K  (1)| 14:06:10 |
-------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   1 - filter("Y"=1000)

— The End —

前两天有人问我这个问题，我说你先自己去搜索下答案吧。

后来他说没有找到合适的方法，我搜索了一下，竟然发现没有人提到exchange partition的方法。

exchange partition的方法是最安全，也是最快速的方法。

所以这里写出这种方法供大家参考。

假设有A,B两个用户，我们想把TEST表从A用户移到B用户。

我们以非分区表作为例子:

SQL> conn a/a
Connected.
SQL> create table test(x int);

Table created.

SQL> create index test_idx on test(x);

Index created.

SQL> insert into test select rownum from dual connect by level <10000;

9999 rows created.

SQL> commit;

Commit complete.

SQL> conn b/b
Connected.

SQL> create table temp(x int) partition by range (x)
2 (partition part0 values less than (-1),
3 partition part1 values less than (maxvalue));

Table created.

SQL> create table test(x int);

Table created.

SQL> create index temp_idx on temp(x) local;

Index created.

SQL> create index test_idx on test(x);

Index created.

SQL> alter table temp exchange partition part1 with table a.test including indexes without validation;

Table altered.

SQL> alter table temp exchange partition part1 with table test including indexes without validation;

Table altered.

SQL> select count(*) from a.test;

COUNT(*)
———-
0

SQL> select count(*) from b.test;

COUNT(*)
———-
9999

如果是分区表，操作过程如下：

SQL> conn a/a
Connected.

SQL> create table test(x int) partition by range (x)
2 (partition part0 values less than (100),
3 partition part1 values less than (maxvalue));

Table created.

SQL> create index test_idx on test(x) local;

Index created.

SQL> insert into test select rownum from dual connect by level <1000;

999 rows created.

SQL> commit;

Commit complete.

SQL> conn b/b
Connected.
SQL> create table temp(x int);

Table created.

SQL> create index temp_idx on temp(x);

Index created.

SQL> create table test(x int) partition by range (x)
2 (partition part0 values less than (100),
3 partition part1 values less than (maxvalue));

Table created.

SQL> create index test_idx on test(x) local;

Index created.

SQL> select count(*) from a.test;

COUNT(*)
———-
999

SQL> select count(*) from b.test;

COUNT(*)
———-
0

SQL> alter table a.test exchange partition part0 with table temp including indexes without validation;

Table altered.

SQL> alter table test exchange partition part0 with table temp including indexes without validation;

Table altered.

SQL> select count(*) from a.test;

COUNT(*)
———-
900

SQL> select count(*) from b.test;

COUNT(*)
———-
99

SQL> alter table a.test exchange partition part1 with table temp including indexes without validation;

Table altered.

SQL> alter table test exchange partition part1 with table temp including indexes without validation;

Table altered.

SQL> select count(*) from a.test;

COUNT(*)
———-
0

SQL> select count(*) from b.test;

COUNT(*)
———-
999

复合分区表的情况大同小异，大家可以自己试验一下。

一、rac安装步骤主要分以下几步：
1、安装操作系统。
2、配置时间同步，如ntp
3、创建oracle用户和配置rsa和dsa
4、配置hosts文件
5、配置hangcheck-timer
6、配置共享存储（ocr和voting disk）
7、安装clusterware（crs）
8、配置asm
9、安装数据库软件和创建实例。

二、cluster如果需要重装，可以
方法1、按照$CRS_HOME/install/rootdeinstall.sh进行卸载。
方法2、手工卸载：

三、检查clusterware是否安装正确：

四、检查crs是否运行正常

五、rac无法启动，检查发现是asm无法启动，在asm的启动时有报错：

这个时候检查给asm的raw device的权限，linux下重启时会自动把raw device的属主改为root，因此需要在/etc/rc.local文件中添加（有时修改/etc/udev/permissions.d/50-udev.permissions文件没用，必须修改rc.local文件）:
chown oracle:dba /dev/raw/raw[1-3]
chmod 660 /dev/raw/raw[1-3]

六、如果某些application状态为UNKNOWN，可以用crs_stop NAME -f，再crs_start NAME -f来重启解决：

由于ODU命令比较多，特别是关键的unload命令比较复杂，本文将简单介绍几种场景下使用ODU进行数据恢复时，使用的命令序列。本文不会详细介绍每个命令的使用，详细的命令请参考本网站ODU页面下的链接。

场景1. 数据库不能启动，但是SYSTEM表空间中的数据字典是完整的。

• 生成数据字典：unload dict
• 列出用户: list user
• 列出用户下的所有表: list table username
• 恢复表: unload table username.tablename
• 也可以按用户恢复： unload user username

场景2. 表被TRUNCATE。

• OFFLINE表所在的表空间
• 生成数据字典：unload dict
• 显示表的段头：desc username.tablename
• 找到实际的data object id： dump datafile file# block block#
• 恢复表：unload table username.tablename object object_id

场景3. 表被DROP。

• OFFLINE表所在的表空间
• 使用logminer从日志里面挖掘被drop掉的表其data object id，如果不能挖掘，按下面的场景4进行恢复。
• 扫描数据：scan extent
• 如果没有表结构信息，需要自动来判断：unload object data_object_id sample
• 恢复表：unload object data_object_id column coltype coltype…

场景4. 系统表空间损坏。

• 扫描数据：scan extent
• 搜索数据：unload object all sample
• 从结果文件sample.txt查找需要的数据
• 恢复需要的表：unload object data_object_id column coltype coltype…

场景5. 表中数据被DELETE。

• 将参数unload_deleted设置为YES
• 生成数据字典：unload dict
• 恢复表: unload table username.tablename

远邦昨天给我出了一道题，里面涉及到了用10053分析执行计划，很有趣，我这里paste一下分析过程，与大家共享。

远邦的题目是这样的：

create table tb0624 (type number,ts timestamp) pctfree 90;

begin

for i in 1..10000 loop

insert into tb0624 values (1,sysdate);

insert into tb0624 values (3,sysdate);

end loop;

commit;

end;

/

begin

for i in 1..10 loop

insert into tb0624 values (2,sysdate);

end loop;

commit;

end;

/

SELECT TYPE,COUNT(*) FROM TB0624 GROUP BY TYPE;

      TYPE   COUNT(*)

---------- ----------

         1      10000

         3      10000

         2         10

exec dbms_stats.gather_table_stats('IPRA','TB0624',CASCADE=>FALSE,METHOD_OPT => 'FOR ALL INDEXED COLUMNS')

-------检查列是否有柱状图

SET LINESIZE 200 PAGESIZE 100

COL ENDPOINT_ACTUAL_VALUE FOR A20

COL COLUMN_NAME FOR A5

SELECT * FROM USER_TAB_HISTOGRAMS WHERE TABLE_NAME='TB0624';

SELECT * FROM USER_HISTOGRAMS WHERE TABLE_NAME='TB0624';

SELECT TABLE_NAME,/* LOW_VALUE,HIGH_VALUE , */ COLUMN_NAME,NUM_NULLS,DENSITY,NUM_DISTINCT,HISTOGRAM FROM USER_TAB_COLUMNS WHERE TABLE_NAME='TB0624';

SELECT NUM_ROWS,BLOCKS FROM USER_TABLES WHERE TABLE_NAME='TB0624';

SELECT NUM_ROWS,BLEVEL,LEAF_BLOCKS,CLUSTERING_FACTOR,DISTINCT_KEYS FROM USER_INDEXES WHERE INDEX_NAME='IDX_TYPE';

-------开始分析索引

create index idx_type on tb0624(type);

-------再次检查列是否有柱状图

SET LINESIZE 200 PAGESIZE 100

COL ENDPOINT_ACTUAL_VALUE FOR A20

COL COLUMN_NAME FOR A5

SELECT * FROM USER_TAB_HISTOGRAMS WHERE TABLE_NAME='TB0624';

SELECT * FROM USER_HISTOGRAMS WHERE TABLE_NAME='TB0624';

SELECT TABLE_NAME,/* LOW_VALUE,HIGH_VALUE , */ COLUMN_NAME,NUM_NULLS,DENSITY,NUM_DISTINCT,HISTOGRAM FROM USER_TAB_COLUMNS WHERE TABLE_NAME='TB0624';

SELECT NUM_ROWS,BLOCKS FROM USER_TABLES WHERE TABLE_NAME='TB0624';

SELECT NUM_ROWS,BLEVEL,LEAF_BLOCKS,CLUSTERING_FACTOR,DISTINCT_KEYS FROM USER_INDEXES WHERE INDEX_NAME='IDX_TYPE';---因为是10G，这里建索引的时候会帮你分析

---开始测试

SQL> set autotrace on

SQL> select * from tb0624 where type=2;

Plan hash value: 4077598990

----------------------------------------------------------------------------------------

| Id  | Operation                   | Name     | Rows  | Bytes | Cost (%CPU)| Time     |

----------------------------------------------------------------------------------------

|   0 | SELECT STATEMENT            |          |   353 |  9178 |     5   (0)| 00:00:01 |

|   1 |  TABLE ACCESS BY INDEX ROWID| TB0624   |   353 |  9178 |     5   (0)| 00:00:01 |

|*  2 |   INDEX RANGE SCAN          | IDX_TYPE |   141 |       |     1   (0)| 00:00:01 |

为什么oracle这里自己知道走索引？

10053显示索引选择率为0.004而不是1/3?

按照上述测试过程原封不动的做一遍，然后分析一下10053产生的trace文件，我这里称这个文件为trace文件1，因为后续我还会产生两个10053的trace文件2和trace文件3。

Trace文件1的部分内容：

***************************************

BASE STATISTICAL INFORMATION

***********************

Table Stats::

  Table: TB0624  Alias: TB0624

    #Rows: 20010  #Blks:  438  AvgRowLen:  14.00

Index Stats::

  Index: IDX_TYPE  Col#: 1

    LVLS: 1  #LB: 40  #DK: 3  LB/K: 13.00  DB/K: 267.00  CLUF: 801.00

***************************************

SINGLE TABLE ACCESS PATH

  Column (#1): TYPE(NUMBER)  NO STATISTICS (using defaults)

    AvgLen: 22.00 NDV: 625 Nulls: 0 Density: 0.0015992

  Table: TB0624  Alias: TB0624    

    Card: Original: 20010  Rounded: 200  Computed: 200.10  Non Adjusted: 200.10

  Access Path: TableScan

    Cost:  100.08  Resp: 100.08  Degree: 0

      Cost_io: 98.00  Cost_cpu: 7125191

      Resp_io: 98.00  Resp_cpu: 7125191

  Access Path: index (AllEqGuess)

    Index: IDX_TYPE

    resc_io: 17.00  resc_cpu: 151884

    ix_sel: 0.004  ix_sel_with_filters: 0.004

    Cost: 17.04  Resp: 17.04  Degree: 1

  Best:: AccessPath: IndexRange  Index: IDX_TYPE

         Cost: 17.04  Degree: 1  Resp: 17.04  Card: 200.10  Bytes: 0

这里index range scan的cost是17.04，table scan的cost是100.08，idx_type的DK是3，ix_sel确实是0.004。

其实远邦的问题上述trace文件已经给出答案了，就是我红字标明的部分，即：

上述测试案例里ix_sel=0.004而不是1/3，这是因为在type这一列上没有统计信息，所以oracle在这里用到了默认值来计算ix_sel，而不是用index上的DK来计算ix_sel（什么情况下也不会用DK来计算ix_sel）。换句话说，这里即使你用条件type=2（或者3）来查询的话，oracle这个地方也会用index range scan。

远邦，这个默认值不是固定的，感觉这里这个默认值取决于Blks，我这里证明给你看。

将上述表drop掉，插入数据的语句更改成

begin

for i in 1..10000 loop

insert into tb0624 values (1,sysdate);

insert into tb0624 values (3,sysdate);

insert into tb0624 values (4,sysdate);

end loop;

commit;

end;

/

begin

for i in 1..10 loop

insert into tb0624 values (2,sysdate);

end loop;

commit;

end;

/

然后再如法炮制分析10053产生的trace文件2：

Table Stats::

  Table: TB0624  Alias: TB0624

    #Rows: 30681  #Blks:  628  AvgRowLen:  14.00

Index Stats::

  Index: IDX_TYPE  Col#: 1

    LVLS: 1  #LB: 59  #DK: 4  LB/K: 14.00  DB/K: 450.00  CLUF: 1801.00

***************************************

SINGLE TABLE ACCESS PATH

  Column (#1): TYPE(NUMBER)  NO STATISTICS (using defaults)

    AvgLen: 22.00 NDV: 959 Nulls: 0 Density: 0.001043

  Table: TB0624  Alias: TB0624    

    Card: Original: 30681  Rounded: 307  Computed: 306.81  Non Adjusted: 306.81

  Access Path: TableScan

    Cost:  142.09  Resp: 142.09  Degree: 0

      Cost_io: 139.00  Cost_cpu: 10614604

      Resp_io: 139.00  Resp_cpu: 10614604

  Access Path: index (AllEqGuess)

    Index: IDX_TYPE

    resc_io: 22.00  resc_cpu: 203032

    ix_sel: 0.0040894  ix_sel_with_filters: 0.0040894

    Cost: 22.06  Resp: 22.06  Degree: 1

  Best:: AccessPath: IndexRange  Index: IDX_TYPE

         Cost: 22.06  Degree: 1  Resp: 22.06  Card: 306.81  Bytes: 0

看到了吗，这里的ix_sel已经变成了0.0040894。

现在我们来让type这一列上产生统计信息：

将上述表drop掉，全部重来一遍，只不过在create index idx_type on tb0624(type)之后再执行一下

exec dbms_stats.gather_table_stats('IPRA','TB0624',CASCADE=>FALSE,METHOD_OPT => 'FOR ALL INDEXED COLUMNS SIZE 1')

或

exec dbms_stats.gather_table_stats('IPRA','TB0624',CASCADE=>FALSE,METHOD_OPT => 'FOR ALL INDEXED COLUMNS SIZE REPEAT')

上述两个之一执行完后，type这一列上已经有统计信息了：

SQL> SELECT TABLE_NAME,/* LOW_VALUE,HIGH_VALUE , */ COLUMN_NAME,NUM_NULLS,DENSITY,NUM_DISTINCT,HISTOGRAM FROM USER_TAB_COLUMNS WHERE TABLE_NAME='TB0624';

TABLE_NAME                     COLUMN_NAME                     NUM_NULLS    DENSITY NUM_DISTINCT HISTOGRAM

------------------------------ ------------------------------ ---------- ---------- ------------ ---------------

TB0624                         TYPE                                    0       0.25            4 NONE

TB0624                         TS                                                                NONE

而且这里居然也产生了histogram信息，这和文档里描述的不一致，这里我的本意是不想产生histogram的：

SQL> SELECT * FROM USER_TAB_HISTOGRAMS WHERE TABLE_NAME='TB0624';

TABLE_NAME                     COLUMN_NAME                                                                      ENDPOINT_NUMBER ENDPOINT_VALUE ENDPOINT_ACTUAL_VALUE

------------------------------ -------------------------------------------------------------------------------- --------------- -------------- --------------------------------------------------------------------------------

TB0624                         TYPE                                                                                           0              1

TB0624                         TYPE                                                                                           1              4

再次产生10053的trace文件3，发现现在oracle已经走全表扫描了，我们来看一下这个trace文件的内容：

***************************************

BASE STATISTICAL INFORMATION

***********************

Table Stats::

  Table: TB0624  Alias: TB0624

    #Rows: 29590  #Blks:  628  AvgRowLen:  14.00

Index Stats::

  Index: IDX_TYPE  Col#: 1

    LVLS: 1  #LB: 59  #DK: 4  LB/K: 14.00  DB/K: 450.00  CLUF: 1801.00

***************************************

SINGLE TABLE ACCESS PATH

  Column (#1): TYPE(NUMBER)

    AvgLen: 3.00 NDV: 4 Nulls: 0 Density: 0.25 Min: 1 Max: 4

  Table: TB0624  Alias: TB0624    

    Card: Original: 29590  Rounded: 7398  Computed: 7397.50  Non Adjusted: 7397.50

  Access Path: TableScan

    Cost:  142.07  Resp: 142.07  Degree: 0

      Cost_io: 139.00  Cost_cpu: 10538224

      Resp_io: 139.00  Resp_cpu: 10538224

  Access Path: index (AllEqRange)

    Index: IDX_TYPE

    resc_io: 466.00  resc_cpu: 6095551

    ix_sel: 0.25  ix_sel_with_filters: 0.25

    Cost: 467.78  Resp: 467.78  Degree: 1

  Best:: AccessPath: TableScan

         Cost: 142.07  Degree: 1  Resp: 142.07  Card: 7397.50  Bytes: 0

©作者：eygle 发布在 eygle.com

相关文章|Related Articles

• 恩墨科技为ChinaCache提供紧急救援服务
  
• 恩墨科技为中电财提供顾问咨询及容灾服务
  
• 恩墨科技为中国国际电子商务中心提供服务
  
• 恩墨科技成功签下第一个企业客户
  
• 北京恩墨科技有限公司 即日宣告成立
  

评论数量(6)|Add Comments

本文网址：http://www.eygle.com/archives/2009/06/enmotech_zihexin.html