在"利用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.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

评论数(5)|添加评论 | 最近作者还说了什么? 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

• 恩墨科技为中国国际电子商务中心提供服务
  
• 恩墨科技成功签下第一个企业客户
  
• 北京恩墨科技有限公司 即日宣告成立
  

评论数量(0)|Add Comments

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

©作者：eygle 发布在 eygle.com

IPC Send timeout 是 Oracle10g Rac中非常让人头痛的一个问题，在资源紧张、网络拥堵等情况下，就有可能发生IPC超时的问题，而RAC随后就会将问题节点驱逐，引发一轮重新配置。

可喜的是Metalink上针对10.2.0.3有了一个Patch可以修正，而且在10.2.0.4中彻底修正了该问题。
常见的错误提示是这样的：

Thu Nov 27 11:32:05 2008
IPC Send timeout detected. Receiver ospid 4001974
Thu Nov 27 11:33:08 2008
Trace dumping is performing id=[cdmp_20081127113236]
Thu Nov 27 11:34:37 2008
Errors in file /oracle/app/product/admin/srs/bdump/srs1_lms1_4001974.trc:
Thu Nov 27 11:34:38 2008
Errors in file /oracle/app/product/admin/srs/bdump/srs1_lmon_3977348.trc:
ORA-29740: evicted by member 1, group incarnation 32
Thu Nov 27 11:34:38 2008
LMON: terminating instance due to error 29740

相关文章|Related Articles

• CGS 与 CGS wait for IPC msg
  
• RAC环境下根据sequence恢复指定日志
  
• RAC环境修改undo_rentention需要谨慎
  
• Oracle Database 12g将不支持裸设备
  
• Oracle 10g RAC的相关概念
  

评论数量(0)|Add Comments

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

北京时间6月26日，一代歌王迈克尔·杰克逊因心脏停动在洛杉矶逝世，享年50岁。

伴随了大多数人多年时光的天王Michael Jackson忽然间就逝去了，耀眼和平凡都是一瞬间的事情，Heal the World言犹在耳，却无法拯救自己。

对这位全球以个人名义资助慈善事业最多的人，我们心存敬意。

©作者：eygle 发布在 eygle.com

昨晚在客户Oracle数据库系统上应用一个Patch时，遇到了一幢惊心动魄的事情。

当我们刚刚应用完Patch之后，系统上就出现了一条广播消息，提示：

Broadcast message from root@p570 (tty) at 00:00:19 ...

clverify has detected cluster configuration errors on node p570. Detailed clverify output is available in standard clverify log on node p570.

[oracle@dbrac1 oracle]$ cluvfy


USAGE:
cluvfy [ -help ]
cluvfy stage { -list | -help }
cluvfy stage {-pre|-post} <stage-name> <stage-specific options>  [-verbose]
cluvfy comp  { -list | -help }
cluvfy comp  <component-name> <component-specific options>  [-verbose]

再仔细看提示才发现此clverify不是cluvfy：

在HACMP 5.1中，包括集群校验程序(clverify)和新的集群通信后台(clcomdES)都需要/var文件系统下附加的空间。

要得到详细的消息和附加的调试信息，在每个节点的/var下需要满足：

Ø        20M仅一次，包括：

-          /var/HACMP/clcomd/clcomd.log  2M

-          /var/HACMP/clcomd/clcomddiag.log  18M

Ø        在/var/HACMP/odmcache目录下附加的（1M*集群中的节点数）空间。

Ø        4M每个节点集群的效验数据。

Ø        2M的集群效验log（clverify.log[0-9]）。

在集群的每个节点中，效验工具在需要/var下4M的空间，clverify可以在同一时间最多保持四份节点效验数据的拷贝(节点初始化和同步时)。

/var/HACMP/clverify/current//*包含当前执行的效验的日志。

/var/HACMP/clverify/pass//*包含最后通过的效验的日志。

/var/HACMP/clverify/pass。prev/ /*包含倒数第二次通过效验的日志。

/var/HACMP/clverify/fail//*包含最后一次失败的效验日志。

同时，/var/HACMP/clverify/clverify.log和它的拷贝消耗1-2M的磁盘空间。

ERROR: The HACMP timestamp file for shared volume group: oraclevg is inconsistent
with the time stamp in the VGDA for the following nodes: p1 p2

相关文章|Related Articles

• 使用cldump工具查看HACMP状态
  
• CRS-0184错误与CRS初始化
  

评论数量(1)|Add Comments

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

©作者：eygle 发布在 eygle.com

OPatch是用来应用Oracle过渡性补丁的工具。

对于Oracle10.2.0.3版本来说，自带的OPatch版本过低，没有napply命令，在应用一些Patch Bundle时需要升级OPatch。
记录一下patch号及下载地址：
补10.2.0.3的Opatch，补丁号是 4898608：

-r--r--r-- 1 root other 1169856 Jun 22 00:15 p4898608_10201_GENERIC.zip
-r--r--r-- 1 root other 1169856 Jun 22 00:16 p4898608_10202_GENERIC.zip
-r--r--r-- 1 root other 1169856 Jun 22 00:17 p4898608_10203_GENERIC.zip
-r--r--r-- 1 root other 1169856 Jun 22 00:18 p4898608_10204_Generic.zip
-r--r--r-- 1 root other 1252699 Jun 22 00:13 p4898608_111000_GENERIC.zip

另外在Metalink上的所有OPatch版本的补丁号的编号是6880880，其文件有一大堆：

-r--r--r--   1 root     other      361632 Jun 19 12:39 p6880880_101000_AIX.zip
-r--r--r--   1 root     other    28287882 Jun 19 12:37 p6880880_101000_AIX64-5L.zip
-r--r--r--   1 root     other      361632 Jun 19 12:39 p6880880_101000_BS2000.zip
-r--r--r--   1 root     other    29861361 Jun 19 12:37 p6880880_101000_HP64.zip
-r--r--r--   1 root     other    35417093 Jun 19 12:37 p6880880_101000_HPUX-IA32.zip
-r--r--r--   1 root     other    35417093 Jun 19 12:37 p6880880_101000_HPUX-IA64.zip
-r--r--r--   1 root     other    29861361 Jun 22 09:38 p6880880_101000_HPUX11.zip
-r--r--r--   1 root     other    29265466 Jun 19 12:38 p6880880_101000_IBMPower.zip
-r--r--r--   1 root     other    26342584 Jun 19 12:38 p6880880_101000_LINUX.zip
-r--r--r--   1 root     other    31697049 Jun 19 12:37 p6880880_101000_Linux-IA64.zip
-r--r--r--   1 root     other    28740649 Jun 19 12:37 p6880880_101000_Linux-S390.zip
-r--r--r--   1 root     other    26342584 Jun 19 12:38 p6880880_101000_Linux-x86-64.zip
-r--r--r--   1 root     other    28740649 Jun 19 12:37 p6880880_101000_Linux-zSer.zip
-r--r--r--   1 root     other    25049780 Jun 19 12:38 p6880880_101000_MSVista.zip
-r--r--r--   1 root     other    25049780 Jun 19 12:38 p6880880_101000_MSWIN-x86-64.zip
-r--r--r--   1 root     other    25049780 Jun 19 12:38 p6880880_101000_MSwin2000.zip
-r--r--r--   1 root     other    25049780 Jun 19 12:38 p6880880_101000_MSwinXP.zip
-r--r--r--   1 root     other      361632 Jun 19 12:41 p6880880_101000_MSwinXP64.zip
-r--r--r--   1 root     other      361632 Jun 19 12:39 p6880880_101000_MVS.zip
-r--r--r--   1 root     other    27601676 Jun 19 12:38 p6880880_101000_SOLARIS.zip
-r--r--r--   1 root     other    27601676 Jun 19 12:38 p6880880_101000_SOLARIS64.zip
-r--r--r--   1 root     other    25049780 Jun 19 12:39 p6880880_101000_Ser08-x86-64.zip
-r--r--r--   1 root     other    25049780 Jun 19 12:38 p6880880_101000_Ser2003.zip
-r--r--r--   1 root     other    25049780 Jun 19 12:39 p6880880_101000_Ser2008.zip
-r--r--r--   1 root     other      361632 Jun 19 12:41 p6880880_101000_Solaris86-64.zip
-r--r--r--   1 root     other      361632 Jun 22 09:27 p6880880_101000_Solarisx86.zip
-r--r--r--   1 root     other      361632 Jun 19 12:39 p6880880_101000_Tru64.zip
-r--r--r--   1 root     other    25049780 Jun 19 12:38 p6880880_101000_WINNT.zip
-r--r--r--   1 root     other      361632 Jun 19 12:41 p6880880_101000_WINNT64.zip
-r--r--r--   1 root     other     1170379 Jun 19 12:45 p6880880_102000_AIX.zip
-r--r--r--   1 root     other    29096475 Jun 19 12:41 p6880880_102000_AIX64-5L.zip
-r--r--r--   1 root     other     1170379 Jun 19 12:45 p6880880_102000_AIX64.zip
-r--r--r--   1 root     other     1170379 Jun 21 22:20 p6880880_102000_BS2000.zip
-r--r--r--   1 root     other    30670108 Jun 19 12:41 p6880880_102000_HP64.zip
-r--r--r--   1 root     other    36225840 Jun 19 12:41 p6880880_102000_HPUX-IA32.zip
-r--r--r--   1 root     other    36225840 Jun 19 12:41 p6880880_102000_HPUX-IA64.zip
-r--r--r--   1 root     other    30670108 Jun 22 09:41 p6880880_102000_HPUX11.zip
-r--r--r--   1 root     other    30074213 Jun 19 12:43 p6880880_102000_IBMPower.zip
-r--r--r--   1 root     other    27151331 Jun 19 12:44 p6880880_102000_LINUX.zip
-r--r--r--   1 root     other    32505796 Jun 19 12:43 p6880880_102000_Linux-IA64.zip
-r--r--r--   1 root     other    29549396 Jun 19 12:43 p6880880_102000_Linux-S390.zip
-r--r--r--   1 root     other    27151331 Jun 19 12:44 p6880880_102000_Linux-x86-64.zip
-r--r--r--   1 root     other    29549396 Jun 19 12:41 p6880880_102000_Linux-zSer.zip
-r--r--r--   1 root     other    25858527 Jun 19 12:45 p6880880_102000_MSVista.zip
-r--r--r--   1 root     other    25858527 Jun 19 12:45 p6880880_102000_MSWIN-x86-64.zip
-r--r--r--   1 root     other    25858527 Jun 19 12:44 p6880880_102000_MSwin2000.zip
-r--r--r--   1 root     other    25858527 Jun 19 12:45 p6880880_102000_MSwinXP.zip
-r--r--r--   1 root     other     1170379 Jun 19 12:47 p6880880_102000_MSwinXP64.zip
-r--r--r--   1 root     other     1171143 Jun 19 12:41 p6880880_102000_MVS.zip
-r--r--r--   1 root     other    28410423 Jun 19 12:44 p6880880_102000_SOLARIS.zip
-r--r--r--   1 root     other    28410423 Jun 25 00:07 p6880880_102000_SOLARIS64.zip
-r--r--r--   1 root     other    25858527 Jun 19 12:45 p6880880_102000_Ser08-x86-64.zip
-r--r--r--   1 root     other    25858527 Jun 19 12:45 p6880880_102000_Ser2003.zip
-r--r--r--   1 root     other    25858527 Jun 19 12:45 p6880880_102000_Ser2008.zip
-r--r--r--   1 root     other     1170379 Jun 19 12:47 p6880880_102000_Solaris86-64.zip
-r--r--r--   1 root     other     1170379 Jun 19 12:47 p6880880_102000_Solarisx86.zip
-r--r--r--   1 root     other     1170379 Jun 19 12:47 p6880880_102000_Tru64.zip
-r--r--r--   1 root     other    25858527 Jun 19 12:44 p6880880_102000_WINNT.zip
-r--r--r--   1 root     other     1170379 Jun 23 22:59 p6880880_102000_WINNT64.zip
-r--r--r--   1 root     other     1253222 Jun 19 12:53 p6880880_111000_AIX.zip
-r--r--r--   1 root     other    29179318 Jun 19 12:47 p6880880_111000_AIX64-5L.zip
-r--r--r--   1 root     other     1253222 Jun 19 12:53 p6880880_111000_AIX64.zip
-r--r--r--   1 root     other     1253222 Jun 19 12:53 p6880880_111000_BS2000.zip
-r--r--r--   1 root     other    30752951 Jun 19 12:49 p6880880_111000_HP64.zip
-r--r--r--   1 root     other    36308683 Jun 19 12:47 p6880880_111000_HPUX-IA64.zip
-r--r--r--   1 root     other    30752951 Jun 22 09:43 p6880880_111000_HPUX11.zip
-r--r--r--   1 root     other    30157056 Jun 19 12:49 p6880880_111000_IBMPower.zip
-r--r--r--   1 root     other    29632239 Jun 19 12:49 p6880880_111000_LINUX-S390.zip
-r--r--r--   1 root     other    29632239 Jun 19 12:49 p6880880_111000_LINUX-zSer.zip
-r--r--r--   1 root     other    27234174 Jun 19 12:49 p6880880_111000_LINUX.zip
-r--r--r--   1 root     other    32588639 Jun 19 12:49 p6880880_111000_Linux-IA64.zip
-r--r--r--   1 root     other    27234174 Jun 19 12:49 p6880880_111000_Linux-x86-64.zip
-r--r--r--   1 root     other    25941370 Jun 19 12:51 p6880880_111000_MSVista.zip
-r--r--r--   1 root     other    25941370 Jun 19 12:53 p6880880_111000_MSWIN-x86-64.zip
-r--r--r--   1 root     other    25941370 Jun 19 12:51 p6880880_111000_MSwin2000.zip
-r--r--r--   1 root     other    25941370 Jun 19 12:51 p6880880_111000_MSwinXP.zip
-r--r--r--   1 root     other     1253222 Jun 19 12:53 p6880880_111000_MSwinXP64.zip
-r--r--r--   1 root     other     1253929 Jun 19 12:49 p6880880_111000_MVS.zip
-r--r--r--   1 root     other    28493266 Jun 19 12:53 p6880880_111000_SOLARIS64.zip
-r--r--r--   1 root     other     1253222 Jun 19 12:53 p6880880_111000_SOLARISx86.zip
-r--r--r--   1 root     other    25941370 Jun 19 12:53 p6880880_111000_Ser2003.zip
-r--r--r--   1 root     other    25941370 Jun 19 12:53 p6880880_111000_Ser2008.zip
-r--r--r--   1 root     other     1253222 Jun 19 12:53 p6880880_111000_TRU64.zip
-r--r--r--   1 root     other    25941370 Jun 19 12:53 p6880880_111000_WINNT.zip
-r--r--r--   1 root     other     1253222 Jun 19 12:53 p6880880_111000_WINNT64.zip

记录一下备忘，这一周遇到了太多的Case，忙的晕头转向！

参考链接：

Kamus写的： http://www.dbform.com/html/2008/477.html

赵宇写的： http://space.itpub.net/175005/viewspace-420428

相关文章|Related Articles

• 关注一下Oracle的CPU (Critical Patch Updates)
  
• 《深入解析Oracle》一书脚本包下载
  
• Oracle Database 11g补丁(Patchset)下载地址
  
• Oracle Database 11g 体系结构图下载
  
• ORACLE 9iR2 软件下载地址收藏
  

评论数量(0)|Add Comments

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

今天出现了较大量的latch free争用，通过后面的latch小节可以看到

                                           Pct    Avg   Wait                 Pct

                              Get          Get   Slps   Time       NoWait NoWait

Latch                       Requests      Miss  /Miss    (s)     Requests   Miss

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

cache buffers chains        647,517,611    0.1    0.4   5416   20,999,665    1.4

cache buffers lru chain       1,079,718    1.4    0.6    501   19,674,712    7.7

library cache                36,397,178    4.2    0.7  35020      168,674   16.3

library cache load lock           6,312    0.0    1.0      0            0

library cache pin            17,880,285    0.6    0.6   1887            0

library cache pin alloca     12,409,710    0.6    0.7   2024            0

redo allocation               3,037,476    0.2    0.3     62            0

redo copy                            47  100.0    1.0     18    2,618,742    1.0

redo on-disk SCN                639,357    0.0             0            0

redo writing                    778,319    0.0    0.2      0            0

resumable state object               46    0.0             0            0

row cache enqueue latch     266,547,183    5.0    0.0    548            0

row cache objects           273,903,504    6.2    0.1  17014          765    9.8

sequence cache                  188,590    0.0    0.4      0            0

session allocation            4,084,373    0.9    0.6    852            0

session idle bit             30,229,860    0.1    0.5    400            0

session queue latch             913,072    0.0    0.1      0            0

session switching                    59    0.0             0            0

session timer                     1,241    0.0             0            0

shared pool                  23,095,605    4.2    0.2   2018            0

共享池和DB CACHE相关的闩锁都出现了一定的争用。这是CPU出现瓶颈的征兆，IO，内存，CPU都出现瓶颈，这个系统确实有点撑不住了。从Statspack报告来看

Statistic                                      Total     per Second    per Trans

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

CPU used by this session                   2,439,627          678.4         11.7

CPU used when call started                 2,401,482          667.8         11.6

每秒消耗的CPU是6784毫秒，而一个8 CPU的系统，最多只能提供8000毫秒的CPU时间，Oracle消耗了接近85%的CPU资源，比昨天又增加了几个百分点。我回了个邮件，让万科他们注意。

写完邮件，FOXMAIL提示我又有一封新邮件，打开邮件一看，原来是Richard的回信：

Jackson,

Mingyu did not give me your name so I will call you Jackson.

I would like to know if you have any specific recommendations for the

database at this system. Are there any tables that you recommend should have

additional indexes added, changes to the code to use indexes rather than

full table scans etc.

The oracle reports I have seen so far only speak of the requirement for

changes/improvements not how these should be done.

Thanks for the comments. I agree with you on the server performance issues. It is not a simple problem to resolve. 

Best regards

Richard

看样子洋哥们也发现了全表扫描的问题，通过前一阵子的优化，我已经解决了绝大多数全表扫描的问题，不过仍有一定数量的全表扫描无法避免，因为这个系统是一个c/s/s结构的系统，很多SQL都是根据客户端选择的条件动态生成的，为了确保一些主要的SQL能够通过索引完成，所以在很多模块中都使用了HINT。由于SQL是动态生成的，所以不可避免的会出现对于某些情况，HINT会导致更坏的执行计划。比如说客户端选择了一些过虑条件，生成出的SQL原本使用另外一个索引效率比较高，但是由于SQL中使用了强制HINT,这样就会导致这个SQL会使用错误的索引，反而增大了开销。这种由于程序缺陷导致使用错误的执行计划的情况十分普遍，由于这些情况属于非常用功能，因此虽然有些客户投诉性能问题，开发商也没有给予理会。由于应用架构的问题，开发商想要解决这个问题也十分困难，我曾经建议过他们取消HINT，但是开发商怕取消了HINT会导致常用模块性能下降而一直不敢按照我的建议去修改应用。

快下班的时候，万科打电话过来了，他看到我的邮件后有些着急，从今天的情况来看系统的压力稍微大一些，CPU就有点悬，今天他们观察到的业务最忙的时段，CPU经常冲到100%，r队列也达到了20以上。虽然CPU还没有真正出现瓶颈，但是看上去挺悬的。万科问我这几天能不能再做些优化，缓解一下CPU资源。

我告诉万科，我和明喻他们前后一阶段的合同已经结束，老外进场后，新的合同看样子明喻是不会和我签了。目前我真没办法出面做处理，一旦做好了，功劳算老外的，做不好我的责任就大了。

万科听我这么一说就有点着急，今天和Richard开完会后，万科就觉得有点不靠谱，搭测试环境，模拟生产环境，等试验做完，不知道猴年马月了，还不知道能不能找到解决方案呢。于是万科希望我在关键的时候能够帮下忙。

我说关键时刻我可以出手，但是必须让明喻找我，否则我师出无名。万科想了想，我说的也在理，只好遗憾的挂了电话。

1.1.1. 4月29日 Richard Warham

Richard的全名是Richard Warham。今天接到Richard的电话我感到还是有点吃惊：“Hello，Jackson ，I'm Richard J Warham. You can call me Warham or Richard  ,But I think Warham is better.”

和绝大多数老外一样，Richard希望以一个幽默的开场白开始，不过对于中国人来说，这个开场白并不好玩，为了迎合外国友人，我一般会说：“AHA，You are so funny,Warham.”，我今天也不例外，打了几下哈哈后，我的英语水平的窘境就暴露了出来。Richard希望从我这里了解一些这个系统的情况，不过一谈到深入点的技术问题，我的口语就远远不够用了。于是我告诉Richard我的口语水平有限，还是发个邮件给他。

挂了电话后，我打开了金山词霸，费了九牛二虎之力写了一封邮件给Richard:

Richard ,

 You want to do someting to improve the performance of IO subsystem at first ,But I do not think this is a good idea. My recommendations is:

1. Database server is now lack of CPU,MEMORY and IO .If we improve IO only,Two others will be  overload. The system is variety at every day,The database server can  serv  only 80% users,20% requests are out of service. If IO performance is improved ,More transcations will send to database server, and CPU will be overload. So I think we must reduce buffer gets before we improve performance of  IO subsystem.

2. Performance problems of this system is mostly application level ,but we can not change any code.The developer will not tune  their application .If we want to tune the application ,we should tune at object level(tables,indexes,etc).

3. Application level tuning is very costliness.I can do the tuning,but without authorization of Your company ,I can do nothing.

If you want to discuss  with me ,PLS send me mail ,or you can   contact Andy. My job is to help customer tune their Oracle databases, I have do this job for over 10 years.I take part in this project since JUL-2006, and I have a total solution to tune  db server, but the job is pending now because of some reason.

Jackson 

Richard估计看了这封狗屁不通的邮件也能看明白个大概，和老外打交道我有经验。90年代初的时候在北京参加一个展会，产品是一家以色列公司的，他们派了个爱尔兰人过来安装演示环境。我和那个爱尔兰人一起工作过一段时间，发现其实和老外沟通挺容易的，只要你把单词说清楚，大体上他就能明白你的意思了。就像老外和我们说中文，只要说出几个单词，我们基本上就能体会完整的意思了。

下午和老万手下的马工说Richard今天一大早就到现场去了，看了看系统的情况，用glance对系统做了会分析，然后重点对IO子系统做了分析。Richard大概有50多岁了（不过老外显得老，也许只有40来岁），身材比较高大，用北京人的说法，是有点壮（北京人发音是第三声）。不过看上去Richard还挺幽默，总是笑容满面的。今天下午，Richard还和现场的人员一起开了个会，东软开发团队的人也参加了。Richard已经安排了在他们公司的实验室里搭建一个和这边生产环境一模一样的测试环境，数据库通过磁带库恢复过去。他要求东软的开发人员使用loadRunner制作一个压力测试环境，用于在实验室进行仿真模拟。Richard走后东软的工程师一直在说这个计划不可行，他们也用过loadRunner，不过模拟这么复杂的业务环境，他们没有能力做到，现在东软的区域经理正在和明喻协商这件事情。

老外的想法就是比较不同，老万他们这个系统十分复杂，到底有哪些功能模块，这些功能模块之间的业务关系是怎么样的，业务发生的频度是什么样的，连开发商里都没有几个人能彻底搞清楚，Richard居然想用loadRunner搞出一个测试环境来，真是有点异想天开。Richard还承诺从公司找到loadRunner的应用高手，给东软的工程师做相关的培训，并且协助他们完成测试脚本的编写。

我一边听一边摇头，本来听明喻说Richard是他们公司首屈一指的优化大师，以为来了个高手，还准备好好和这位高手学点东西，看样子这回来的也只是一个理论大师。搭建测试环境模拟业务系统是一种很好的方法，这样可以避免在优化过程中影响生产环境。不过针对老万他们这种复杂的业务系统，这个方法肯定是不可行的，Richard在没有做充分调研的情况下，轻易的做出了使用loadRunner搭建测试环境的决定，看样子Richard也高不到哪去。

放下电话后，收了一下邮件，马工已经把今天的Statspack报告发了过来，看了看Statspack报告里的load profile，发现今天系统的负载比昨天高了20%以上：

Load Profile

~~~~~~~~~~~~                            Per Second       Per Transaction

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

                  Redo size:            242,805.11              4,199.83

              Logical reads:            102,989.55              1,781.42

              Block changes:              1,382.96                 23.92

             Physical reads:              4,614.01                 79.81

            Physical writes:                180.68                  3.13

                 User calls:              3,951.99                 68.36

                     Parses:                595.58                 10.30

                Hard parses:                 52.85                  0.91

                      Sorts:                 38.61                  0.67

                     Logons:                  0.38                  0.01

                   Executes:              1,136.30                 19.65

               Transactions:                 57.81

  % Blocks changed per Read:    1.34    Recursive Call %:                29.65

 Rollback per transaction %:    0.32       Rows per Sort:              2621.11

Instance Efficiency Percentages (Target 100%)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

            Buffer Nowait %:   99.95       Redo NoWait %:               99.99

            Buffer  Hit   %:   95.56    In-memory Sort %:               99.99

            Library Hit   %:   98.23        Soft Parse %:               91.13

         Execute to Parse %:   47.59         Latch Hit %:               97.65

Parse CPU to Parse Elapsd %:    3.04     % Non-Parse CPU:               92.56

 Shared Pool Statistics        Begin   End

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

             Memory Usage %:   79.81   79.64

    % SQL with executions>1:   89.06   90.11

  % Memory for SQL w/exec>1:   98.83   98.83

Top 5 Timed Events

~~~~~~~~~~~~~~~~~~                                                     % Total

Event                                               Waits    Time (s) Ela Time

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

db file sequential read                        12,224,004     181,514    60.78

latch free                                      2,656,724      68,088    22.80

CPU time                                                       24,396     8.17

db file scattered read                            313,825      16,509     5.53

buffer busy waits                                 193,481       2,098      .70

在split partition时，如果所有索引都是local index并且新split出来的partition为空时，oracle不需要rebuild index，这就是fast split。

但是当新的partition非空时，则index处于unusable状态，需要rebuild index。而在rebuild index这段时间内，如果有SQL进来，就会出问题了。

oracle并没有给出一个安全的split partition的方法，比方说如果不能做fast split则不要做split。而unusable index对于7*24系统是非常危险的。

当然你可以在split的时候去跟踪，一旦发现写入新的segment，则取消操作，但是这样还是有风险。而且一般都是定期做split，通过脚本实现，不太可能每次都手工做。

要实现fast split关键是找到正确的split point。一般我们首先跑一个查询，找出当前这个partition的最大partition key，然后再加一就是split point，然后根据这个split point来做split。但是这中间有一个时间间隔，如果这中间有新的数据插入的话，split point就不对了。

对于partition key为一个列的分区表来说，查询可以走index range(max) scan，这个时间间隔很短，可能遇到该问题的概率很小，但是如果partition key为多列的话，只能走fast full index scan，这个时间间隔可能很长，风险大大增加了。

为了避免这一风险，我采用了下面的方法：

1. 查询将要做split的partition的最大partition_key
select $sql_hint max(Partition_key+1) SPLITPOINT from $tablename partition(${maxpartname})
2. 以exclusive模式lock partition
lock table $tablename partition(${maxpartname}) in EXCLUSIVE mode
3. 再次查询要做split的partition的最大partition_key
select $sql_hint max(Partition_key+1) SPLITPOINT from $tablename partition(${maxpartname})
4. 如果step1和step3得到的结果相同，则跳到step6，不同则跳到step5
5. 提交transaction，释放lock，等待30分钟后跳到step1
6. 查看v$lock表看自己有没有block别人，如果有，跳到step5，如果没有跳到step7
7. split the partition, 如果成功，退出程序，如果失败，跳转到step5

通过上面的方法就可以保证中间没有其他的transaction去做DML。

除了保证安全外，当失败时，改程序可以sleep一段时间后重试。