4月2日 索引危机（2）索引范围扫描的优化方法昨天下午又优化了几个SQL,对于这几个SQL来说，优化后都有了明显的性能提升，不过从今天上午10点多观察到的CPU使用率来看，好像变化不大。由于排队效应的存在，简单的减法并不能完全解决问题。以前排在前面的几个SQL解决了以后，又冒出了几条新的SQL，其中一条SQL每次执行的BUFFER GET数量高达3万多：select a.file

点击此处查看原文

3月29日 理解索引（2）反转键索引的误区昨天我们回顾了索引的一些基础知识，今天我们需要了解一些索引优化相关的知识。首先我们从索引的分类来研究一下索引的主要种类以及各类索引在使用时的一些要点。首先我们来看看最常见的B树索引，B树索引适用于几乎所有的场合，也是系统中使用最为广泛的索引形式。实际上我们所说的普通索引，反转键索引、降序索引、函数索引等都是B树结构的，其物理存储结构是完全相同的。与之相对应的位图索引是完全不同的存储结构，位图索引不是树状结构，没有枝节点，只有叶节点。对于B树索引的操作可以进行索引唯一性扫描、索引范围扫描、快速索引全扫描和索引全扫描，而对于位图索引的访问方式只有一种，就是索

点击此处查看原文

3月28日 理解索引（1）索引时什么东西？恐怕很多DBA玩了几年Oracle还没有彻底理解索引到底是什么东西。为什么有时候通过索引访问一张表会比较快呢？我们需要从头去了解一下索引到底是什么东西。可能70后的朋友小时候都用过新华字典，而80后、90后就可能没用过了。新华字典是按照拼音字母排序的，因此我们查找字典的时候可以通过汉字的拼音来查找。最简单的方式是根据拼音字母的大体位置先随便翻开一页，然后根据这一页的内容在此翻页，直到找到这个汉字。这种翻字典的方式有点土，速度也比较慢，不过这是我们使用的一种最原始的索引方式。为了提高查字典的速度，我们一般都会在字典侧面标出某个字母所在的位置，这样我们可以首先根据字母所在的位置，更为精确的判断某个字可能的位置。这种具有两级的索引，加快了定位的速度。

点击此处查看原文

3月27日 简单任务 （4）更大的意外昨天晚上调整了表结构，我建议把REDO LOG也相应做些调整。目前南坪系统的LOG BUFFER是1M，REDO LOG文件大小是61M，人和系统的LOG BUFFER是120K，REDO LOG文件大小是100M，不过人和系统每个日志组有2个成员。对于这种REDO

点击此处查看原文

最近这段时间比较忙，很少写案例了。今天补一个。前些天处理了一个案例，用户的系统出现了短暂HANG住的现象，一般情况2、3分钟，然后自动好了，有时候HANG住时间接近10分钟，这种故障几乎每隔1、2天就会出现。这个系统是用户最为核心的客服系统，因此需要尽快解决问题。从STATSPACK报告上看：Load Profile~~~~~~~~~~~~                            Per Second       Per Transaction                                   ---------------       ---------------                  Redo size:            331,508.40              2,565.77              Logical reads:            485,862.63              3,760.43              Block changes:              3,251.90                 25.17             Physical reads:              7,697.25                 59.57&nbs

点击此处查看原文

DBA日记 第三部 像Oracle一样思考 3月26日简单任务（3）令人惊讶的结果最近系统的业务量不大，所以客户也同意我们白天就做测试。为了防止误操作，客户把SCOTT账号提供给我做测试。今天我准备做几个测试：l

点击此处查看原文

3月25日简单任务（2）解决之道今天一早老方就回北京了，昨天晚上我和老方一直在讨论这个项目，从采集到的信息来看，只能通过调整操作系统、数据库的参数，以及调整表的一些参数来达到提升系统总体性能的目标。而对于系统性能来说，最为关键的也就是大量的话单插入操作。目前话单插入是由8个并发进程完成的，每次的插入批量试800条记录。

点击此处查看原文

3月24日简单任务（1）令人意外的开始今天第一天到用户现场，我到香格里拉酒店和老方会合，老方在原厂，出差必须享受五星级标准，我就觉得400多块钱的酒店有点奢侈，住在旁边的迎宾馆。迎宾馆是原来的市委招待所，后来改造成了一个三星级酒店，虽然房间有点旧，不过十分干净。很大的院子，里面十分安静。最关键的是，一个市政府的朋友帮我打了个很不错的折扣，不到200块的价格是我选择这里的很重要的因素。

点击此处查看原文

在实际的生产环境中，我们可能不总是那么幸运，我们肯定会碰到两方面的需求。一方面是热块冲突必须解决，另外一方面可能我们还存在一定的应用要对这些数据做范围扫描。在这种情况下，我们必须进行综合的评估，到底哪种需求是主要需求。如果我们优化范围扫描对系统更为有利，那么我们就必须放弃HASH分区；如果解决热块冲突更为重要，那么我们就必须牺牲范围扫描。实际上Oracle就是这样的，任何技术都是矛盾的，都是有缺陷的，否则我们就只需要记住一些准则，就可以成为大师了。Oracle的大师不是那么容易当的，因为在绝大多数情况下，没有永恒的准则。HASH(HASH CLUSTER TABLE)簇表不是分区表，但是HASH簇表和普通的表（也就是术语是哪个说的堆表，HEAP TABLE

点击此处查看原文

3月23日理解表的存储结构（4）减少热块冲突的方法实际上今天要讨论的内容在之前也零零星星讨论过，只是想通过今天的讨论，加深大家的印象。热块冲突是最为常见的现象，是DBA讨论最多的，不过也是DBA做的最少的部分。几乎所有的系统都存在热块冲突的问题，只是严重程度不同而已，一般系统的热块冲突

点击此处查看原文

3月18日理解表的存储结构（2）PCTFREE和行迁移昨天我们了解了表的基本结构，从表的存储结构上我们讨论了几个建表的参数。实际上在绝大多数项目中，开发团队并没有对表进行合理的设计，从而导致了系统上线后出现大量的性能问题。一个最常见的问题就是行链和行迁移。行链的出现在绝大多数系统中是由于我们的设计不合理，比如说某张表的行长度超过了一

点击此处查看原文

今天碰到一个案例，虚惊了一场。一个客户说今天换了块板子，重启数据库的时候数据库启动后很快就宕了，ALERT LOG信息如下：Errors in file /oracle/app1/oracle/product/9.2/admin/xxxlyg/udump/xxxlyg_ora_4964.trc:ORA-07445: 出现异常: 核心转储 [kgllkdl()+3072] [SIGSEGV] [Address not mapped to object] [0x290000000000008] [] []Wed Mar 10 21:52:12 2010Errors in file /oracle/app1/oracle/product/9.2/admin/xxx/udump/xxxlyg_ora_4894.trc:ORA-00600: 内部错误代码，参数: [26599], [1], [229], [], [], [], [], []ORA-29549: 类SYS.oracle/jdbc/dbacc我问客户做了什么改动，客户说没有任何改动，只是正常SHUTDOWN，然后关机，换板子，重启服务器，再重启数据库，数据库启动后，LISTENER一启动，数据库就报错宕了。我查了一下，发现有两个BUG和这个情况类似：Bug 3691672和 Bug 2882661 ，于是建议客户先打PATCH 3691672，并且建议客户查查JVM有没有什么问题。由于这是一个限制性PATCH,于是找人下补丁。对于BUG 2882661,可以通过下面的方法修复JVM：begin    initjvmaux.rollbacksetup;commit;    initjvmaux.rollbackset;delete from java$rmjvm$aux;commit;    initjvmaux.rollbackset;insert into java$rmjvm$aux (select joxftobn from x$joxfc where bitand(joxftflags,96)=0);commit;    initjvmaux.rollbackset;delete from java$rmjvm$aux where obj# in    (select obj# from obj$ where type#=29 and    mtime>(select date_loaded from registry$ where cid='CATPROC'));commit;    initjvmaux.rollbackset;delete from dependency$ where d_obj# in (select obj# from java$rmjvm$aux);    commit;initjvmaux.rollbackset;    update obj$ set status=5 wheretype#=29 and obj# in (select obj# from java$rmjvm$aux);    commit;initjvmaux.rollbackset;    delete from java$rmjvm$aux;commit;   

点击此处查看原文

1.   前言-写作初衷最近一直在考虑DBA日记的第三部该写点什么，不少网友也提出了很多好的建议，不过我觉得总是没有抓住要领。老白写DBA日记的本意是写一系列介绍方法的书，而不希望DBA日记写成介绍技术的，因为介绍技术的书实在是太多了，老白目前公务缠身，没有那么大的精力来编写一本精益求精的技术书籍。DBA日记一直以来都是把老白的经历介绍给大家，把老白的一些处理问题的思路介绍给大家，我想第三部也应该是如此。今年的元旦我是在客户现场度过的，为一家银行的年终决算做护航，期间我和客户的IT部的两位老总分别聊了半个多小时，两位老总都提出了在我们的合作中，希望我能够

点击此处查看原文

5月21日 奇怪的性能问题（上）前一段时间我在广州参加一个研讨会的时候认识了刘工，他给我讲了一个困扰了他们很久的问题。刘工负责维护的一套RAC系统存在一个很大的问题，其中一个节点启动后是正常的，不过运行一段时间后，性能就会变慢，随着系统启动的时间越长，性能越差，最后只能重启数据库，而另外一个节点就很正常。这个问题在1年前就出现了，只是刚开始的时候每隔2、3个月出现一次，而最近1号节点变慢的周期从2、3个月缩短到10来天了，每隔10多天重启一次数据库，对于一个7*24的系统来说，是十分讨厌的，因此他们想尽快解决这个问题。不过他们已经请了原厂在内的好几批人，都没有任何进展。这种情况我还真没碰到过，所以我和刘

点击此处查看原文

刚才帮一个朋友看了一个案例
创建一张很普通的表，居然报ORA022914,NESTED TABLES NOT SUPPORTED。这也太离谱了吧。怎么办呢？马上做个10046TRACE，看看到底哪里报错吧：=====================PARSING IN CURSOR #12 len=70 dep=2 uid=0 oct=3 lid=0 tim=1227340204003259 hv=3849548163 ad='30ad511c'select intcol#,nvl(pos#,0),col#,nvl(spare1,0) from ccol$ where con#=:1END OF STMTEXEC #12:c=0,e=26,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,tim=1227340204003255FETCH #12:c=0,e=25,p=0,cr=3,cu=0,mis=0,r=1,dep=2,og=4,tim=1227340204003353FETCH #12:c=0,e=9,p=0,cr=1,cu=0,mis=0,r=0,dep=2,og=4,tim=1227340204003392STAT #12 id=1 cnt=3 pid=0 pos=1 obj=32 op='TABLE ACCESS BY INDEX ROWID CCOL$ (cr=10 pr=0 pw=0 time=78 us)'STAT #12 id=2 cnt=3 pid=1 pos=1 obj=54 op='INDEX RANGE SCAN I_CCOL1 (cr=7 pr=0 pw=0 time=54 us)'FETCH #3:c=0,e=10,p=0,cr=1,cu=0,mis=0,r=0,dep=2,og=4,tim=1227340204003490STAT #3 id=1 cnt=2 pid=0 pos=1 obj=31 op='TABLE ACCESS BY INDEX ROWID CDEF$ (cr=8 pr=0 pw=0 time=62 us)'STAT #3 id=2 cnt=2 pid=1 pos=1 obj=51 op='INDEX RANGE SCAN I_CDEF2 (cr=6 pr=0 pw=0 time=45 us)'EXEC #5:c=361945,e=377347,p=5,cr=2084,cu=0,mis=0,r=0,dep=1,og=4,tim=1227340204003645ERROR #5:err=22914 tim=1295043034XCTEND rlbk=1, rd_only=1STAT #8 id=1 cnt=3 pid=0 pos=1 obj=0 op='SORT ORDER BY (cr=206 pr=0 pw=0 time=16251 us)'STAT #8 id=2 cnt=8498 pid=1 pos=1 obj=702 op='TABLE ACCESS FULL RECYCLEBIN$ (cr=206 pr=0 pw=0 time=17690 us)'EXEC #4:c=574912,e=601099,p=6,cr=4376,cu=30,mis=0,r=0,dep=0,og=1,tim=1227340204003956ERROR #4:err=604 tim=1295043034*** 2009-10-29 14:06:47.644一看10046 TRACE就发现问题了，'TABLE ACCESS FULL RECYCLEBIN$ ，检查一下RECYCLEBIN吧，一检

点击此处查看原文

1.1.1. 6月8日 ITL等待引发的RAC性能问题从这几天的情况来看，虽然说系统性能还很不错，不过我从IO和CPU的性能趋势上，已经感觉到了不妙。我习惯于每天把STATSPACK报告中的关键数据采集到一个EXECL表格里，定期生成一个折线图来查看趋势。这几天我明显看到折线的斜率在持续增加，以我的经验，这是很不好的先兆。今天早上和老万在QQ上聊了几句，和他说了我的担心。老万随后又咨询了一下Richard，Richard认为目前IO上升只是因为这几天的系统负载在不断增长，IO系统经过前一段时间的优化已经有了数倍的提升，肯定可以确保不会成为瓶颈。看样子老万也是被最近良好的系统状态迷住了眼睛，对我

点击此处查看原文

一个客户突然说某个业务今天变慢了。我查了一下相关的执行计划------------------------------------------------------------------------------------------------| Id  | Operation                     | Name           | Rows  | Bytes | Cost (%CPU)| Time     |------------------------------------------------------------------------------------------------|   0 | SELECT STATEMENT              |                |    39 |   741 |   121   (0)| 00:00:02 ||*  1 |  TABLE ACCESS BY INDEX ROWID  | T_ORDER_DETAIL |     1 |     7 |     3   (0)| 00:00:01 ||   2 |   NESTED LOOPS                |                |    39 |   741 |   121   (0)| 00:00:02 ||   3 |    TABLE ACCESS BY INDEX ROWID| T_ORDER_INFO   |    39 |   468 |     4   (0)| 00:00:01 ||*  4 |     INDEX RANGE SCAN          | IDX_DATE       |    39 |       |     3   (0)| 00:00:01 ||*  5 |    INDEX RANGE SCAN           | IDX_ORDERID    |     1 |   &nb

点击此处查看原文

一般qerpx开头的600号错误和查询中的PX(PARALLEL QUERY）有关，在alert log中出现大量：Errors in file /u01/admin/HDSFOSS/udump/hdsfoss_ora_22149.trc:ORA-00600: internal error code, arguments: [qerpxSObjGdefVI3], [0], [1], [4], [3], [], [], []Mon Sep 14 18:45:44 2009

点击此处查看原文

说实在的流复制环境虽然也帮客户实施过几个，但是大多数还是单向单目标的项目。虽然也做过一对多的单向复制，但是都是在局域网环境或者网络带宽超过100M的广域网环境。这回听说客户是做一个三个节点的双向复制，不免对带宽有些担忧。客户申请的DDN是10M的带宽，据说通过测算，实际生产环境的数据量顶多4、5M的带宽就能支持了。在局域网中做测试的时候双向复制都很正常，所以系统就按计划上线了。由于复制节点在外省，因此我们在主生产系统上exp导出数据，然后通过ems将硬盘快递到容灾中心，然后倒入数据。倒入数据后，启动主生产系统上的capture，开始捕获数据并在两个目的服务器上同步数据。我们的计划是当两台服务器和主生产系统同步后，再启动这两台服务器上的CAPTURE，真正实现三节点的双向复制。开始的时候复制进度很正常，生产数据和复制数据之间的差异大约为230000秒，将近3天的数据延时。我们通过监控脚本发现大约一小时可以减少一个多小时的延时，也就是说大约2

点击此处查看原文

1.1.1. 6月16日 IO负载均衡昨天下午系统负载更高，不过系统的平均事务响应时间稳定在2.5秒左右，WIO也基本上小于20%，看样子把REDO LOG移到VA 7410上，对EVA 3000的IO负载减轻还是很明显的。我们以前也做过测试，移走REDO LOG后，可以减少20-30%的IO负载。今天早上老万给我打了个电话，告诉我昨天全天的单量达到了15万，这也是去年最高的一天的单量，按照这个趋势，今年估计最高峰的时候日处理单量会达到18万。看样子把

点击此处查看原文