4月3日 索引危机（3）效果不错昨天晚上重建了T_PRODUCT_INFO，整个操作还是比较顺利，客户申请了一个小时的停机窗口。不到半小时，整个操作就做完了。由于晚上8点有一个很重要的日报表要跑，所以原本计划8点开始停机，最后拖到了10点多才开始。在这段时间里，我又对几个buffer get和buffer busy waits比较大的索引进行了一些分析。发现有一张表，表的大小是200M，而索引的大小接近300M，看样子索引的碎片十分严重。于是我对一些访问比较频繁的表上的索引进行了一番检查，发现这种现象还是比较普遍存在的。于

点击此处查看原文

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

点击此处查看原文

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

点击此处查看原文

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

点击此处查看原文

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

点击此处查看原文

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

点击此处查看原文

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

点击此处查看原文

1.1.1. 6月15日 又陷危机前几天一个客户系统上线，给客户做了48小时不间断护航，在家里睡了一整天。昨天晚上又在阿斌家里打了一晚上麻将，今天早上4点多才昏昏沉沉的睡着了。昨晚的手气不好，一直输，所以梦里还一直延续着输牌的情景，好不容易摸上了一副好牌，眼看着大三元要听牌了，一阵手机铃声把我惊醒了。迷迷糊糊的拿起手机一看，已经是早上9点多钟了。电话是老万打来的，这个时间有电话进来肯定不是什么好事情。最近这几天我也没有怎么关注老万他们的系统，Richard的优化工作也在10号左右结束了，Richard回国前还给我发了一个邮件，说是感谢我这段时间对他的支持，并且会很怀念我们一起工作的日子。我以前一直以为老外一般不太会说外交辞令，看样子Richard是老外中的异类。

点击此处查看原文

1.1.1. 5月14日 Richard请客今天Richard要和开发商一起确定系统升级的具体实施方案。实际上这回要做的事情还是很多的，服务器要换，另外存储也要做扩容，为了配合扩容，很多数据文件要迁移。不过做这种事情，开发商那边的集成人员很在行，又有Richard在那里主持，所以我也不用多花心思。早上到老万他们办公室的时候已经9点半了，今天的系统状态还不错，小马和老万都优哉游哉的坐在那里喝茶。Richard和开发商的技术人员坐在里间的会议室里讨论问题，明喻在不时的做着翻译工作。我进去和他们打了个招呼就回到外间，老万见到我满面笑容的，和昨天判若两人。我说：“万科，你这演技不当演员算是白瞎了。昨天见到我的时候愁眉苦脸的，今天就春风满面了。”

点击此处查看原文

1.1.1. 5月13日 系统扩容今天起了个大早，坐早班飞机飞青岛，下了飞机直接打了个车就到老万他们公司去了。我到老万他们那的时候正好是午饭时间，老万特意请我去旁边吃了顿石锅拌饭，老万他们公司附近没什么吃饭的地方，不过那个地方韩国人比较多，旁边有一条街上韩国人开的餐厅不少。这家馆子也是韩国人开的，做的比较地道。吃饭的时候老万比较高兴，今天的会议基调已经定下了，扩容是必然的，让老万这几天吃不好饭的问题可以彻底解决了。吃完饭回到办公室已经是中午一点了，我问老万是不是需要休息一下再去会议室。老万说我们两个先到会议室统一一下思路吧，估计明喻他们要2点才会到，他们开会从来都不准时。于是我和老万就在会议室里讨论起今天下午的思路。从目前的情况来看，经过Richard这段时间的折腾，IO问题确实解决了不少，通过扩磁盘，IO的负载下降了一些，不过从目前来看，如果下个月业务量上升2

点击此处查看原文

1.1.1. 5月12日 Richard的180度大转弯5.1长假后，系统的业务量比较平稳，Richard也对IO进行了几次小的调整，移到EVA 3000上的文件的IO性能都比较好，但是留在VA 7400上的文件IO仍然很慢。我和老万都有点怀疑是不是VA 7400出了什么故障，HP的工程师也到现场做了几次检查，没有发现什么问题。昨天晚上Richard把剩余的几个数据文件全部移到了EVA 3000上，现在VA 7400上只剩下UNDO表空间和TEMP表空间的几个文件了。从IO性能上来看，经过Richard的一系列优化后，确实明显有了提高，文件系统IO的性能有了不小的提升。虽然IO性能有了较大的改善，但是CPU的负载一直都没有降下来。虽然开发商对查询的时间做了限制，限制统计查询不能跨月。这个限制打开后，刚开始的几天CPU使用率还有明显的下降，不过随着这几天IO性能的优化，以及系统负载逐渐增加，这几天CPU的使用率又增加到了100%。今天早上我正在刷牙，明喻就打电话来问我，Richard和我昨天交流了些什么？我说没有啊 ，前几天给Richard发了个邮件，告诉他CPU可能会吃紧，Richard还觉得我的担心是多余的。

点击此处查看原文

1.1.1. 5月8日 危机再现原来计划5月6号去肇庆鼎湖山玩，6号下了一场大雨，就把行程推迟到7号了。原本计划7号当天回家的，鼎湖山新鲜的空气让大家都决定在鼎湖住一夜，回到深圳的时候已经是8号的下午了。8号早上和老万通了一个电话，问问那边的情况，老万说早上CPU使用率有点吓人，已经冲到100%了，不过从数据库的状态来看，倒是还可以，活跃会话的数量一直在100-120之间，按照老万他们的经验，活跃会话数量小于200的时候，系统是比较稳定的，超过200的时候，一般来说系统的性能就有问题了。

点击此处查看原文