AskDBA.net

21:31 DBA日记第二部 (33) 外来的和尚好念经 5月12日 Richard的180度大转弯 (19630 Bytes) » DBA日记

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还觉得我的担心是多余的。

明喻告诉我，肯定是我的这个邮件惹的事，今天一早Richard就给明喻发了个邮件，建议对老万他们的系统进行扩容，而且CPU内存都要扩，否则这套系统无法渡过今年的业务旺季。

我一听也感到十分意外，前几天Richard的态度还很乐观，怎么今天一早就180度大转弯了呢？看样子Richard是看明白了摆在他面前的问题了。老外再一根筋，起码的理智还是有的，Richard有这个态度，后面的事情就很容易办了。Richard态度的大转弯让明喻感到十分不爽，本来这个项目在明喻的公司里就被很多人诟病，甚至有些领导在会上都建议宣布这个项目失败，不再追加项目投入了。如果真的像Richard要求的那样去扩容，估计明喻在公司里的日子就很难过了。花了几十万请Richard过来，最终的结果反而是再投入大几十万进行扩容，这个结果应该是最坏的结果了。

接下来明喻想要和我讨论什么，我猜都能猜得到，所以没等明喻开口，我就主动说出了明喻想说的事情：“明喻，现在开始启动应用方面的优化，已经有点晚了，我真的一点把握也没有。”

明喻说：“老白，这回我是真下决心了，如果你能保证5月底完成优化，需要多少钱都好说。”

我回答明喻说，钱不是关键的问题，关键是现在已经5月12号了，5月底业务高峰就来了，只有差不多20天的时间来做应用的优化，风险太大了，我不敢承担这个责任。目前来看，还是Richard的方案比较靠谱。现在来做硬件扩容，如果准备充分，半个月时间肯定能搞定，还赶得上在业务高峰来临前解决这个问题。老万的解决问题的期限是5月30号，现在做扩容，老万也不会有任何意见。而现在开始做应用优化，这么复杂的系统，还需要大董他们配合，软件修改了还要测试，这么短的时间，很难保证不出什么问题。

明喻看我态度比较坚决，也就没有再坚持。和明喻通完电话后，我打开了电脑，查看了一下邮件，发现昨晚Richard给我发了一封邮件。邮件内容大致是：Jackson，IO问题解决了以后，我感觉我已经没有时间来解决CPU的问题了，这个系统远比我想象的复杂，明喻开始给我的信息误导了我，前些天我看到你的邮件才意识到问题的严重性，因此我准备建议公司立即进行硬件扩容。在这个问题上，我们已经没有时间再犯错误了。另外VA 7400的问题我已经找到了，控制器的微码有问题，我们会在硬件扩容的时候一起做微码的升级，升级后部分数据文件可以回迁到VA 7400，这样IO的问题就彻底解决了。你的观点很有建设性，也对我帮助很大。我觉得要维持这套系统的稳定运行，必须进行应用方面的优化。我只是系统方面的专家，对于Oracle数据库的优化，我觉得你是真正的行家，我会建议公司和你合作继续进行应用方面的优化。希望能有机会和你见面。

我通过QQ把Richard的来信发给了老万，老万看到这封信后十分高兴，如果真的扩容4个CPU，4G内存，那么今年渡过业务旺季就没有问题了。我提醒老万，虽然Richard提了建议，不过这个项目的项目经理是明喻，必须让明喻尽快做出扩容的决定，否则时间都来不及了。

下午的时候马工发来了今天的Statspack报告，随着报告还写了一小段文字：

老白，您好！

从本周开始，有网点和工贸已经开始投诉系统速度慢的问题了，但是从报告中的平均响应时间来看还蛮好的嘛，看来他们的好生活还不能过太久，稍微一点不舒服就抱怨了。

只是这两天外网端口重启又频繁了起来，平均每天都会有一个端口要主动重启。

看来系统自4月10日到5月10日的良好表现期已经要结束了。

我马上查看了一下今天上午的STATSPACK报告，TOP 5 EVENTS有了明显的变化，LATCH FREE有了较大的增加：

Top 5 Timed Events

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

Event Waits Time (s) Ela Time

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

db file sequential read 11,832,404 168,204 56.25

latch free 3,245,207 77,591 25.95

CPU time 23,908 7.99

db file scattered read 389,737 22,638 7.57

buffer busy waits 286,856 2,590 .87

从平均事务响应时间来看，今天上午9点到10点间的平均事务响应时间是1767毫秒，下午3点到40点间的平均事务响应时间是2264毫秒，都比前几天稍微差一些，不过和3月底4月初4-6秒的平均事务响应时间相比还是好了不少。看样子马工说的不错，过了几天好日子，胃口就高了很多。从db file sequential read的平均时间来看，今天上午是14毫秒，下午是13毫秒，IO的性能基本上没有太大的问题，和前阵子比较有了很大的提升，Richard对IO的优化还是很见成效的。

不过今天的LATCH FREE等待十分高，上午的时候是25.95%，下午上升到33%。从Statspack报告上看，LATCH FREE主要集中在cache buffer chains、cache buffer lru chains和library cache、row cache objects等方面。由于CPU资源的不足，导致了闩锁争用日益严重。同时由于CPU资源的不足，导致我们无法通过加大DB CACHE等方法来减少相关闩锁的争用，因为加大DB CACHE的大小会带来更大的CPU开销，从而加剧CPU的争用。实际上Richard的扩容建议是目前解决系统问题的最佳方法，从他扩容CPU和内存的建议上看他已经对后续的调整有了一个初步的思路。

不过扩容对于明喻来说是比较痛苦的事情，因为目前的CELL板上已经没有足够的插槽，所以如果扩容就需要扩充一个扩展机箱，这么算起来，明喻他们公司要在这个项目上增加上百万的追加投资，对于目前已经在公司里抬不起头来的明喻，真是雪上加霜啊。

吃晚饭的时候，我接到了明喻的电话，邀请我明天过去参加下午的项目情况分析会议。这个会议规格很高，除了老万他们部门外，明喻的领导、老万的领导都会参与这个会议。在这个会议上，将要讨论Richard提出的硬件扩容的问题。明喻希望我能够配合Richard，让领导立即拍板进行扩容。

14:00 可以少开会吗 Meetings are indispensable? (1887 Bytes) » Orange Tiger 木匠 Creative and Flexible - go with flow

鄙人非常讨厌开会, 不过开会的时间是一个很好的打瞌睡休息时间.

除非你啥都不想干, 就去开会吧.

"Meetings are indispensable when you don't want to do anything."
-- John Kenneth Galbraith

Meetings (usually) suck. The traditional way of doing business includes company meetings throughout the day, taking an hour or more usually. This can eat up half of your day or more. Add to that individual meetings at lunch, or having drinks, or just a one-on-one in the office and you're meeting more than you re producing.

If you've sat through a lot of meetings, like I have, you know they're almost always useless. Sure, sometimes they're good, but most of the time they're boring, full of chit-chat or useless information, and really can be accomplished through a simple email or phone call. They're a waste of everyone's time, and worse yet, most people know it. And nothing changes.

有很多情况可以不用开会, 使用有效的替代方案:

Instead, learn to accomplish the tasks of a meeting through an email, a quick phone call, a quick and focused IM, an online group chat if necessary. Collaborate through online tools, such as those mentioned above. Keep meetings to a bare minimum. Sure, you still need to socialize with people, and have actual conversations, but boring and useless meetings aren't the best way to do that. If you control your company or division, do yourself and your company a favor by eliminating most of your meetings.

那么啥时候需要开会呢?

Only meeting after 3 round trip emails and the goal is still not clear.

以上摘自公司内部Email.

04:54 DBA日记第二部 (33) 外来的和尚好念经 5月8日危机再现（2） (29211 Bytes) » DBA日记

主要的等待事件并没有发生大的变化，从等待事件的明细情况来看，db file sequential read的平均等待时间为14毫秒，和优化前差不多，没有感觉到很明显的IO性能提升。不过CPU的使用率已经大幅度提升了，今天业务高峰期间，CPU使用率一直接近100%，r队列在20左右，对于一个只有8 CPU的系统来说，这个值也已经比较危险了，虽然暂时并没有因为CPU问题造成大的性能问题，但是如果系统的负载再增加一些，就很危险了。从文件IO上看

H_SP_DATA /dev/vgnew01/rh_sp_data01

126,871 35 84.3 4.0 4,319 1 3,155 57.0

/dev/vgnew01/rh_sp_data02

137,582 38 81.1 3.8 2,963 1 4,166 57.5

/dev/vgnew01/rh_sp_data03

230,139 64 77.7 2.4 5,888 2 4,542 47.2

/dev/vgnew01/rh_sp_data04

99,319 28 79.5 3.6 2,748 1 4,196 47.4

/dev/vgnew01/rh_sp_data05

137,021 38 93.3 5.5 2,208 1 4,654 58.1

/dev/vgnew01/rh_sp_data06

146,115 41 94.0 5.3 2,508 1 3,997 56.4

/dev/vgnew01/rh_sp_data07

157,663 44 109.4 5.9 2,819 1 4,193 62.3

/dev/vgnew01/rh_sp_data08

406,637 113 101.7 2.1 17,795 5 13,266 70.1

工单表所在的表空间的文件IO性能仍然不容乐观。虽然部分表空间的IO性能有所好转，但是存放工单表所在表空间的存储设备性能明显存在性能问题，这些文件是存放在VA7400上的，没有迁移到新扩容的EVA 3000上。而EVA 3000上的数据文件的IO性能目前还不错

H_SP_INDEX /dev/vgora02/rh_sp_index01

63,695 18 12.2 1.0 10,589 3 407 21.1

/dev/vgora02/rh_sp_index02

55,789 16 11.4 1.0 13,100 4 18 12.2

/dev/vgora02/rh_sp_index03

62,128 17 12.1 1.0 10,249 3 27 9.3

/dev/vgora02/rh_sp_index04

58,787 16 11.8 1.0 9,540 3 24 14.2

/dev/vgora02/rh_sp_index05

56,624 16 11.4 1.0 12,091 3 2 10.0

/dev/vgora02/rh_sp_index06

61,264 17 10.6 1.0 8,437 2 2 20.0

/dev/vgora02/rh_sp_index07

88,481 25 12.8 1.0 11,215 3 5,365 14.1

/dev/vgora02/rh_sp_index08

77,852 22 12.8 1.0 13,984 4 4,554 13.7

/dev/vgora02/rh_sp_index09

25,794 7 13.3 1.0 9,502 3 156 14.5

看样子Richard的IO优化并没有达到效果，两个存储之间的IO负载并不均衡，老的VA 7400出现了明显的瓶颈。正在这个时候，我收到了Richard的一封邮件。Richard对今天系统的IO表现感到满意，他认为系统的IO性能得到了明显的提升，通过glance的观察，IO等待队列明显下降。不过他也发现了VA 7400性能不佳的问题，建议将部分VA 7400上的数据文件转储到EVA 3000上。今天Richard他们公司的存储工程师对IO进行了半天的现场监控，发现EVA 3000还有很大的潜力，所以他们准备在近期再在EVA 3000上扩容6块硬盘，以便将更多的数据文件迁移过来。

我收到Richard的邮件马上给他回了一个邮件，把我的担忧和他说了一下，这回IO优化，在我眼里是完全失败的，IO性能虽然有所改善，但是并不是本质性的改善，危险的是CPU使用率已经相当高了，目前我们面临很大的风险。

Richard这家伙可能就在电脑边，我的邮件刚发给他，几分钟后就收到了他的邮件，Richard的意思是他的总体思路没问题，不过在细节上还是出现了一些问题，没想到VA 7400的性能这么差，如果把VA 7400上的部分数据文件移到 EVA 3000上，VA 7400的性能也会大幅度提升，这样IO优化就可以顺利结束了。

按照Richard这么折腾下去，这套系统早晚是会出问题的，现在幸亏VA7400性能不佳，CPU还没有出现致命的瓶颈，真的让Richard继续优化下去，IO的问题解决了，CPU的问题又出来了，这样风险更大。按照今天的业务量，如果再提高15%左右，就算Richard不折腾，CPU也可能出问题。于是我马上打电话给老万，让他尽快想想办法，让开发商做些动作，减少一点SQL的开销。老万接了我的电话后，马上把开发商的现场经理大董找来，我们三个人开了一个电话会议。大家想了一圈办法也没想到什么好办法，于是我想到了平安保险的做法，在业务高峰来临的时候，为确保主生产系统的性能，临时性关闭部分不常用功能。于是我建议老万能不能临时关闭部分功能，比如查询功能。

大董想了半天，只想出几个开销不是很大的模块，关闭这些模块能够减少的负载有限，对于整个系统来说，简直就是杯水车薪。突然大董叫了起来：“有办法了，我们干脆限制一下工贸公司统计的时间范围，以前我们限制统计不能超过1个月，后来由于业务人员强烈要求，才把统计查询的时间限制临时去掉了。要加上限制，只需要调整一下配置，把那个开关打开就行了，连应用都不用重启。”

我一听十分高兴：“对啊，我还忘了这茬了，1月份的时候我们就打开过这个限制，才渡过了春节前的高峰期。如果把这个限制打开，起码可以减少10%的系统开销。”

结束了三方通话，已经是6点多了。我刚刚盛了一碗饭准备坐下来吃饭，老万的电话又打进来了。他还是对系统不太放心，问我有什么好办法。

我目前也是很无奈，优化那边，明喻已经安排了Richard来做，我是插不上手的，顶多能给Richard一点建议，但是Richard好像对我的建议并不在意。我目前觉得如果要防止Richard的优化带来更大的问题，一定要让大董他们尽快优化一些应用，而从目前来看，大董他们很难在短时间内对应用做较大的优化。今天打开查询时间限制这个方法应该是近期大董他们唯一能做的事情了。

老万失望的放下了电话。从老万唉声叹气的表情看，这几天他的日子确实不好过，今晚可能又要失眠了。但是我能做的也只有这么多了，这个时候安慰他，可能是在害他。

04:53 DBA日记第二部 (33) 外来的和尚好念经 5月8日危机再现（1） (37155 Bytes) » DBA日记

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

既然老万那边没什么问题，我也就不着急回家了，到七星岩转了一圈，买了一包肇庆裹蒸粽才打道回府。到家后洗了个澡，感觉浑身还在冒汗，深圳比肇庆热多了，真有点怀念鼎湖山的清凉。打开电脑收了一下邮件，首先看到马工发过来的statspack报告，最近一年以来，每天采集两份statspack报告并发给我是马工每天雷打不动的工作。打开今天的STATSPACK报告，看到今天的平均事务响应时间是1600毫秒，响应时间和30号优化实施前差不太多，但是8号的平均每秒事务数小于29，30号，说明8号的业务量还没有恢复到节前的水平，这估计和长假后部分休假的人员还没有回来上班有关。从STATSPACK报告上看：

Load Profile

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

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

Redo size: 239,525.76 6,734.11

Logical reads: 86,551.62 2,433.34

Block changes: 1,409.14 39.62

Physical reads: 5,325.29 149.72

Physical writes: 467.88 13.15

User calls: 4,843.94 136.18

Parses: 661.67 18.60

Hard parses: 56.70 1.59

Sorts: 32.95 0.93

Logons: 0.38 0.01

Executes: 1,004.14 28.23

Transactions: 35.57

% Blocks changed per Read: 1.63 Recursive Call %: 22.12

Rollback per transaction %: 1.13 Rows per Sort: 3406.02

Instance Efficiency Percentages (Target 100%)

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

Buffer Nowait %: 99.97 Redo NoWait %: 100.00

Buffer Hit %: 94.12 In-memory Sort %: 99.95

Library Hit %: 98.24 Soft Parse %: 91.43

Execute to Parse %: 34.11 Latch Hit %: 97.38

Parse CPU to Parse Elapsd %: 4.64 % Non-Parse CPU: 93.84

Shared Pool Statistics Begin End

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

Memory Usage %: 74.54 74.51

% SQL with executions>1: 90.66 92.64

% Memory for SQL w/exec>1: 98.48 98.76

Top 5 Timed Events

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

Event Waits Time (s) Ela Time

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

db file sequential read 24,318,031 342,222 75.24

db file scattered read 711,781 39,184 8.62

latch free 2,132,500 35,154 7.73

CPU time 28,834 6.34

buffer busy waits 108,299 3,717 .82

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

Avg

Total Wait wait Waits

Event Waits Timeouts Time (s) (ms) /txn

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

db file sequential read 24,318,031 0 342,222 14 90.5

db file scattered read 711,781 0 39,184 55 2.8

latch free 2,132,500 0 35,154 16 16.7

buffer busy waits 108,299 1 3,717 34 0.8

io done 352,620 0 1,625 5 2.8

log file sync 135,975 31 1,045 8 1.1

22:10 关于 IM 工具的"群" (5703 Bytes) » DBA notes

作者：Fenng 发布在 dbanotes.net.

在我看来，如果要评选一个IM 工具的功能"更影响沟通的有效性、更能浪费生产力" 的话，恐怕非"群"莫属。

昨天在 Twitter 上发了一句对"群"这个玩意儿的牢骚，引来了不少朋友的回复，大部分朋友对"群"还是深恶痛绝的，云风随后写了一篇《关于"群"的那些破事》叙述网易泡泡的群功能出炉的来龙去脉。

经常看到有讨论技术的人会开很多 QQ 群，然后一大堆人加入，我最不屑这样的讨论技术的方式，我不相信有谁通过 IM 群学会了很多东西，当然，他们浪费了很多宝贵时间我倒是深信不疑的。所以不乏偏激的说：

"喜欢用群的人都是喜欢用开会来消磨时间的。他们享受群，认为那东西理所当然的是"好"的沟通工具。我也赞同群里面90%都是一些垃圾信息的说法。小笑话、新闻链接、有趣的小图片占据了这 90% 的大部分内容。"

这样的说法如果也在内部会议上提出的话，估计也要像 Tim Yang 那样遭受一片嘘声。（我不排除有人把"群"用的出神入化，比如昨天就有一位互联网大佬给我讲述他当年用群的功能做推广的案例，但这只是个例）。Twitter 上就有不少人不同意我的说法：

"吾之蜜糖彼之砒霜，QQ 群用的人那么多，凭什么说人家烂？不适合罢了"

也有朋友给出了建议:

建议用临时会话，说话完正事就退出。(refer)
群的成员不应该是固定的。（refer)
做个Twitter进化的桌面IM...

现在的群，如果非要继续沿用的话，改进的余地还有很大。产品经理请注意，下面是可以给你带来业绩的地方：学习 Twitter 风格的对话模式，针对每一条信息有上下文，便于群内的参与者能够知道信息的指向(这是非常关键的一点，否则就是乱七八糟胡乱抢话筒的会议而已)。第二，设计一个可以将"会议"记录发送到指定电子邮件的功能(这应该并不复杂)。学学 Gtalk 的优点应该不难吧?

欣喜的看到网易已经用不许员工上班时间用群了，这是个伟大的决定。

--EOF--

（注：众多推友对此文亦有贡献)

相关文章|Related Articles

即时通信软件的互联互通 - Jul 13, 2006
卓越(Joyo)与 Amazon 接轨后的'智能' - Oct 8, 2006
阿里旺旺推出正式版 - Mar 1, 2007
修改 Windows Live Messenger 英文版的字体 - Mar 28, 2007

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

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

20:51 11G real time query (7603 Bytes) » Alibaba DBA Team

11G standby提供了real time query的功能，通过这个功能，我们可以结合lgwr+async来做到实时standby查询，
给我们做读写分离提供了遐想空间，最近和老郑测试了下这个功能的实时性，希望对大家有所帮助

测试环境：
redhat linux as 4.7(64bit)
11.1.0.7.0 lgwr + async 20480 + real time query
主库：10组512M的联机日志
备库：11组512M的standby logfile
测试方法：
循环插入记录，为了增大日志量，起了6个进程，插入test1-test6
declare v_counter pls_integer := 0;
begin
        for i in 1..100000000 loop
                insert into $1 (id,mdate,mm) values(i,sysdate,’wo shi ni ba’);
                v_counter := v_counter + 1;
                if v_counter = 10 then
                        commit;
                        v_counter := 0;
                end if;
        end loop;
end;
/

以表test1为参考，每隔1秒查询主库和备库的最大ID，还有插入的时间，如果是完全实时，这两个数值应该相等，
通过两边的max(id)和maxid对应的时间，可以看出real time query的延迟，采样结果保存于rquery_time表
测试的日志量大家可以自己加压设置，本次测试日志量是37M/S,让我有点吃惊，但多次statspack统计的结果和日志切换的频率计算，
就是如此

Load Profile              Per Second    Per Transaction    Per Exec    Per Call
~~~~~~~~~~~~      —————— —————– ———– ———–
      DB time(s):                3.1                0.0        0.00        6.78
       DB CPU(s):                3.0                0.0        0.00        6.65
       Redo size:       37,575,874.7            5,286.1
   Logical reads:          312,674.9               44.0
   Block changes:          303,749.8               42.7
Physical reads:                8.4                0.0
Physical writes:            2,256.8                0.3
      User calls:                0.5                0.0
          Parses:                4.1                0.0
     Hard parses:                0.5                0.0
W/A MB processed:                0.0                0.0
          Logons:                0.0                0.0
        Executes:           71,089.5               10.0
       Rollbacks:                0.0                0.0
    Transactions:            7,108.4

declare v_max_stb pls_integer := 0;
v_max_pri pls_integer := 0;
v_date_stb date;
v_date_pri date;
begin
for x in 1..1000000 loop
         –获取主库最大ID，最大时间
         select max(id) into v_max_pri from test1;
  select mdate into v_date_pri from test1 where id = v_max_pri;

  –获取备库最大ID，最大时间
  select max(id) into v_max_stb from test1@ctrdmsb;
  select mdate into v_date_stb from test1@ctrdmsb where id = v_max_stb;

  –保存结果
  insert into rquery_time
  (primary_max_id,standby_max_id,primary_time,standby_time)
  values
  (v_max_pri,v_max_stb,v_date_pri,v_date_stb);

  commit;

  –get sleep
  dbms_lock.sleep(1);
end loop;
end;
/

–查询结果
select PRIMARY_MAX_ID - STANDBY_MAX_ID as max_deff,(PRIMARY_Time - standby_Time) * 24 * 3600 as time_deff
from rquery_time
order by PRIMARY_MAX_ID;
MAX_DEFF TIME_DEFF
———- ———-
      8460          0
      4720          0
      5360          1
      4770          1
      4950          0
      4240          0
      5240          0
      6300          1
      5040          0
      4680          1

两边相差大概5000笔记录，时间延迟在1秒不到的样子，对于37M/S的日志量来说，这个实时性是相当高了
当然备库是否应用跟得上主库，还要看IO的类型和存储的能力，网络传输量，具体环境具体测试

不过使用lgwr+standby logfile传输日志，对于数据的保护理论上只会丢一个async buffer的日志，但实际测试起来，结果会大跌眼镜，
特别是standby机器性能不是很好的情况下很容易发生丢几组日志

我们在32位的AS 4.4上测试出了这个情况，并且可以多次重现

备库跟不上主库的节奏，当前standby logfile 541中的日志还没有全部应用到数据文件，主库已经切换了多次日志
这些日志会以archive log的方式传到备库（如果备库的standby logfile足够的话，会直接使用standby logfile），

如果此时主库突然crash,备库的情况就是
541 standby logfile
542 archive log
543 archive log

理论上可以recover standby database until cancel;然后依次指定上面的文件，但在应用541 standby logfile时，
会遇到非常扯淡的错误(经过旺旺同学解释，数据库是最大性能模式，主库不能保证日志的完全写入，所以是corrupt)：
SQL> recover standby database until cancel;
ORA-00279: change 25661117 generated at 07/02/2009 23:38:00 needed for thread 1
ORA-00289: suggestion : /data/oradata/arch/ctrdmsb/ctrdm_1_541_690507562.arc
ORA-00280: change 25661117 for thread 1 is in sequence #541

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
+DG1/ctrdmsb/redosb_3_1.log
ORA-00283: recovery session canceled due to errors
ORA-00354: corrupt redo log block header
ORA-00353: log corruption near block 421143 change 25661598 time 07/02/2009 23:38:01
ORA-00334: archived log: ‘+DG1/ctrdmsb/redosb_3_1.log’
ORA-01112: media recovery not started

主库意外终止后，oracle会认为当前standby logfile是不可用的，这样会导致后面的两个归档根本没法应用，损失是非常大的

20:25 陈二雷 (570 Bytes) » 玉面飞龙的BLOG

最近又热播了一出战争题材的连续据，我的兄弟叫顺溜，风格和”我的团长我的团”类似，嬉笑怒骂型的战争戏剧。王宝强在里面主演神枪手陈二雷。演得还不错，王宝强在战争片里面是大有突破，游刃有余。推荐每晚追看。

最近国内再次上调石油价格，这样可以或多或少的减少石油消费，从而减少排气量，对气温和环境有好处。我是大大支持的。持续的高温实在让人憋闷。我没有车，不骂娘。

04:49 关于 I/O 的五分钟法则(Five-Minute Rule) (5514 Bytes) » DBA notes

作者：Fenng 发布在 dbanotes.net.

去年在对 SSD 做调查的时候就关注过这个五分钟法则，今天又发现了这篇文章的修订版(为了纪念 Jim Gray），这个话题倒是可以简单介绍一下，对架构师衡量 I/O 能力、Cache 评估和做硬件选型还是会有一些帮助的。

在 1987 年，Jim Gray 与 Gianfranco Putzolu 发表了这个"五分钟法则"的观点，简而言之，如果一条记录频繁被访问，就应该放到内存里，否则的话就应该待在硬盘上按需要再访问。这个临界点就是五分钟。看上去像一条经验性的法则，实际上五分钟的评估标准是根据投入成本判断的，根据当时的硬件发展水准，在内存中保持 1KB 的数据成本相当于硬盘中存储同样大小数据 400 秒的开销(接近五分钟)。这个法则在 1997 年左右的时候进行过一次回顾，证实了五分钟法则依然有效（硬盘、内存实际上没有质的飞跃)，而这次的回顾则是针对 SSD 这个"新的旧硬件"可能带来的影响。

随着闪存时代的来临，五分钟法则一分为二：是把 SSD 当成较慢的内存（extended buffer pool ）使用还是当成较快的硬盘（extended disk）使用。小内存页在内存和闪存之间的移动对比大内存页在闪存和磁盘之间的移动。在这个法则首次提出的 20 年之后，在闪存时代，5 分钟法则依然有效，只不过适合更大的内存页(适合 64KB 的页，这个页大小的变化恰恰体现了计算机硬件工艺的发展，以及带宽、延时)。

根据数据结构和数据特点的不同，对于文件系统来说, 操作系统倾向于将 SSD 当作瞬时内存(cache)来使用。而对于数据库，倾向于将 SSD 当作一致性存储来用。

这是一篇非常重要的文章(所以，建议读一下原文），其中对于数据库一节的描述尤其有趣（针对 DB 也有个五分钟)。限于篇幅，就不罗嗦了。

--EOF--

相关文章|Related Articles

Oracle 10g XE 的字符集问题 - Jan 23, 2006
Oracle XE 自带的数据库如何创建的? - Jan 24, 2006
重要图书: MySQL Stored Procedure Programming - Apr 10, 2006
代寻《Database In Depth》的技术审校 - Oct 12, 2006

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

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

01:25 Support it (5153 Bytes) » SA Notes

以下为转载!

本文将提供一种一劳永逸的翻墙方式（ssh -D），实施之后，那道墙——对你来说——将从此透明。

本文面向的用户：使用Windows作为操作系统并且使用Firefox作为常用浏览器。

第一步：免费获取拥有SSH权限的帐号和密码。

默认的免费获取方式：将本文转载到你自己的博客上，将转载后的文章网址发送到。

转载方式：拷贝文章代码至博客后台HTML编辑器中，直接发布即可，文章标题自拟，可在前后文插入自己的评论。

经过人工审核，你将收到一封附有五个拥有SSH权限的帐号和密码的电子邮件，你可以将它们赠与你自己的读者。

更多获取方式将在今后陆续激活，请关注我们的最新更新：https://friendfeed.com/fuckgfw

第二步：配置MyEntunnel软件

下载并安装MyEntunnel，该软件全名为My Encrypted Tunnel。

一键下载：https://dl.getdropbox.com/u/873345/download/myentunnel.exe

按照上图将第一步收到的帐号信息填写到相应的地方后，点击按钮，再点击按钮。

第一次连接过程中会出现一个认证对话框，按照提示确认即可。以后的自动连接中将不再出现此认证对话框。

最后点击按钮，使对话框隐藏到系统任务栏中。

提示：

为MyEntunnel创建一个快捷方式，将其复制到系统的【启动】（C:\Documents and Settings\当前用户名（需要修改成你自己的）\「开始」菜单\程序\启动）文件夹中，今后开机便可自动启动软件，并自动连接服务器。

绿色代表连接成功且稳定；黄色代表正在连接或重新连接；红色代表连接失败。

第三步：配置Firefox浏览器

假设你正使用Firefox浏览器阅读本文。

一键安装：http://autoproxy.mozdev.org/latest.xpi

点击立即安装，安装后，重新启动Firefox。然后你会看到如下对话框，选择gfwlist (P.R.China)后，点击确定。

接着你会看到Firefox主界面右上角出现有一个“福”字图案，点击“福”。

点击“代理服务器——编辑代理服务器”。

随即出现如下画面，你会看到如GAppProxy、Tor和Your Freedom这样一系列代理服务器名称。

将GAppProxy一栏的参数修改为如下图所示。

修改完毕后，点击确定。至此配置已全部就绪。

获取更多帮助，请关注反馈中心：https://friendfeed.com/fuckgfw-feedback

第四步：支持fuckGFW

获取详情，请关注捐赠与推广中心：https://friendfeed.com/fuckgfw-donation-and-marketing

版权信息：您可以自由复制、传播、演绎本作品且无需署名、无需注明原始出处。

1.1.1. 5月1日在家聊天

今天是5月1日，劳动节7天长假的第一天。我自从几年前5.1节的时候和老婆去了趟三亚，就决定再也不长假出游了。所以长假期间我一般选择在家休息，每个长假的最后2天才安排在深圳周边玩玩。由于昨晚Richard要对系统的IO做一次小的调整，最近一直担惊受怕的老万十分紧张，怕调整后系统出现严重的问题，所以他希望我今天能帮他盯一天系统。

选择昨天晚上选择优化实施实际上不是一个好主意，今天是5.1长假的第一天，即将入夏的时节，又赶上放假，正是白家电促销的好日子。今天全国的白家电销量应该是一个小高峰，根据业务部门的测算，老万他们这套系统的负载肯定高于4月30日。选择昨天晚上动手优化的风险十分高，一旦今天出现问题，那么Richard将面临的形势将十分严峻。我一直不理解Richard这么做的真实意图，也许是老外并不知道5.1这个日子的特殊性，也许真的是Richard对昨天的动作十分有把握。不过无论如何，如果是我，绝对不敢选择在CPU这么高的时候单独去优化IO，也许这回我真的遇到了高人了，如果真的是这样，那就太好了，我也可以好好和他切磋切磋。

登录到VPN后，感觉今天系统的状况出奇的好，现在已经是上午的10点左右了，按理说应该是一天中业务量比较大的时段，CPU空闲还有15%左右，IO系统的表现和很好，AVWAIT基本少接近于0，AVSERV在20左右。难道是Richard的优化起了作用？我马上做了一个STATSPACK的采样，并且和9点的采样生成了一份报告。

由于Statspack的采样很久没有清理了，所以报告生成的很慢。在报告生成的时候，我看了看QQ的在线用户，老万的QQ状态是“忙碌”。我于是发信息过去给老万打了个招呼：“万科，早”。

老万回信息说：“老白，今天的情况异常的好，我看了个把小时了，active的会话数量一直低于80，CPU使用率也不高。看样子Richard昨天的优化效果十分明显，别看这老外五大三粗的像个土匪，不过还是有两下子的。”

我说：“按照理论来说，Richard所做的优化操作并不是很合理，不应该会有这样的效果。万科，有没有可能今天的业务量不大？”

老万说：“这一点我也疑问过，所以刚才我给国内几个工贸公司都打了电话，他们反馈回来的信息是今天的产品销售量比昨天普遍略高5-10%。”

这太不正常了，难道昨天晚上Richard还做了什么我不知道的调整？这个时候Statspack报告已经生成完毕了，我马上打开了报告

Load Profile

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

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

Redo size: 184,507.91 6,333.90

Logical reads: 133,335.76 4,577.23

Block changes: 1,053.27 36.16

Physical reads: 2,535.17 87.03

Physical writes: 127.19 4.37

User calls: 3,996.10 137.18

Parses: 568.89 19.53

Hard parses: 49.98 1.72

Sorts: 26.44 0.91

Logons: 0.38 0.01

Executes: 772.16 26.51

Transactions: 29.13

% Blocks changed per Read: 0.79 Recursive Call %: 21.92

Rollback per transaction %: 0.51 Rows per Sort: 2971.01

Instance Efficiency Percentages (Target 100%)

Buffer Nowait %: 99.98 Redo NoWait %: 100.00

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

Library Hit %: 98.26 Soft Parse %: 91.22

Execute to Parse %: 26.32 Latch Hit %: 98.12

Parse CPU to Parse Elapsd %: 8.08 % Non-Parse CPU: 93.36

从单块读的响应时间来看，确实今天的IO系统性能有了十分明显的提升：

Avg

Total Wait wait Waits

Event Waits Timeouts Time (s) (ms) /txn

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

db file sequential read 6,508,594 0 41,645 6 62.0

latch free 983,166 0 12,239 12 9.4

db file scattered read 194,469 0 2,674 14 1.9

我算了一下平均事务响应时间，是732毫秒，比前一阵子的3秒左右有了很大的提升。这真是太不可思议了。我让老万立即对今天的WORK_ORDER表进行一个统计，看看业务量和昨天对比相差多大。老万统计了一下后告诉我从9点到10点的工单量来看，今天的的工单量比4月30号少15%左右，看来有些工贸公司的量还是略有下降。看样子今天虽然销售量比较大，不过安排送货安装的并不多，也许商场的送货人员也放假了，要等4号才开始工作。不过从另外一个方面考虑，15%的业务量下降也不应该有这么大的效果啊。

我认真看了看Load Profile，突然发现今天报告里的平均事务数量是每秒29个，而前几天是57，也就是说今天系统的平均事务量是30号的一半。从刚才老万他们对工单表的统计来看，不应该有这么大的差异，是什么地方出现了问题呢？

“老万，今天工贸公司放不放假？”，我突然问老万。

“放啊，今天除了值班的都放假，这有什么关系？”，老万疑惑的问我。

我恍然大悟了：“老万，你别忘了，你这个系统除了业务人员用以外，工贸公司的1500个管理岗位也在用啊，而且这1500个管理岗位消耗的系统资源是相当的大，他们总是在做一些统计和分析。今天的现象只是一个暂时性的，等长假结束了，你就会看到情况并不这么乐观。”

老万一听就笑了：“我还真忘了这茬了，这帮大爷经常自己写SQL去做统计，我们每天的主要工作就是杀那帮家伙的会话”。

如果工贸公司的1500个终端没有开的话，系统负载起码少了30%以上，看样子老万是空欢喜了一场，不过我的心情却无比的好，看来我的判断并没有错，仅仅靠Richard的那几招，想要解决问题还是不可能的。

看看时间，已经是中午12点了，我说：“万科，今天下午就没必要盯着了，估计长假前三天都不会有什么问题，4号后可能会有一些工贸公司的人加班，压力会大一些，不过也不会有大的问题，关键是8号。”

老万想了想说：“是啊，看样子这几天也不会有太大的负载，5.1节促销的效果也没有想象的那么明显，又被业务部门忽悠了一把，还增长20%的业务量，都是拍脑袋拍出来的，明显不是那回事。老白，你这几天也没必要盯着了，不过8号你一定帮我盯紧了，8号我预感会发生点什么。”

中午睡了个午觉，一觉醒来已经是3点半了。VPN连过去看了看，系统负载依然很小。看样子这几天确实都不需要怎么关心了。想想也对，以前就出过几次问题，当时是把内网工贸公司的应用停了来应急的，每次都是立竿见影的，一停内网应用，系统马上就缓过来了。

刚上网就发现马工也在网上，我问他在做什么，他说下午他值班，万科自己回家了，不过还是让他盯到5点。小马自己一个人在青岛，也没什么朋友，加班挣点加班费还是挺不错的。正和小马聊着，Richard通过MSN发了一条消息：“Hi,老兄，今天系统十分完美”。

Richard 用了perfect，足以表明他现在的心情。Richard认为今天的性能情况和他昨天的动作有很大关系。我想给他泼泼冷水，不过费了半天脑子，也没有想好怎么说。“5.1长假”这个词汇我用了好几个英文单词去描述，他还是没有听明白什么意思。后来我只好解释说今天就类似他们西方的圣诞新年假期一样，很多业务人员都休息去了，所以今天的系统负载只是平时的60-70%。总算，Richard听明白了我要表达的意思，不过他还是认为优化获得了阶段性的成果。

我想我也很难说服他，老外都是一根筋，你很难去说服他。只有到5月8日，系统真正体现出了压力，才能让他明白老万他们这个项目的优化并不像他想象的那么简单。以今天的业务量，CPU资源肯定会出现瓶颈

20:09 Oracle 10g LOGMNR挖掘日志很方便 (8724 Bytes) » Oracle Life

©作者：eygle 发布在 eygle.com

Oracle 10g可以使用LOGMNR在线分析和挖掘日志，使用当前在线的数据字典，非常方便。

首先执行一些DDL或DML操作：

SQL> connect eygle/eygle
Connected.

SQL> alter system switch logfile;

System altered.

SQL> create table eygle as select * from dba_users;

Table created.

SQL> set autotrace on
SQL> select count(*) from eygle;

COUNT(*)
----------
        19

Execution Plan
----------------------------------------------------------
Plan hash value: 3602634261

--------------------------------------------------------------------
| Id | Operation          | Name | Rows | Cost (%CPU)| Time     |
--------------------------------------------------------------------
|   0 | SELECT STATEMENT   |       |     1 |     3   (0)| 00:00:01 |
|   1 | SORT AGGREGATE    |       |     1 |            |          |
|   2 |   TABLE ACCESS FULL| EYGLE |    19 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------

Note
-----
   - dynamic sampling used for this statement

Statistics
----------------------------------------------------------
          5 recursive calls
          0 db block gets
          7 consistent gets
          5 physical reads
          0 redo size
        411 bytes sent via SQL*Net to client
        400 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          1 rows processed

然后可以执行LOGMNR解析工作：

SQL> connect / as sysdba
Connected.
SQL> select * from v$log where status='CURRENT';

    GROUP#    THREAD# SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ------------
         2          1        100   52428800          1 NO CURRENT               12729697 01-JUL-09

SQL> SELECT MEMBER from v$logfile where group#=2;

MEMBER
------------------------------------------------------------------------------------------------------------------------
/opt/oracle/oradata/mmstest/redo02.log

SQL> exec dbms_logmnr.add_logfile('/opt/oracle/oradata/mmstest/redo02.log',dbms_logmnr.new);

PL/SQL procedure successfully completed.

SQL> exec dbms_logmnr.start_logmnr(options=>dbms_logmnr.dict_from_online_catalog);

PL/SQL procedure successfully completed.

SQL> select count(*) from v$logmnr_contents;

COUNT(*)
----------
       136
SQL> select sql_redo from v$logmnr_contents;

SQL_REDO
------------------------------------------------------------------------------------------------------------------------
set transaction read write;
insert into "SYS"."OBJ$"("OBJ#","DATAOBJ#","OWNER#","NAME","NAMESPACE","SUBNAME","TYPE#","CTIME","MTIME","STIME","STATUS
","REMOTEOWNER","LINKNAME","FLAGS","OID$","SPARE1","SPARE2","SPARE3","SPARE4","SPARE5","SPARE6") values ('25847','25847'
,'31','EYGLE','1',NULL,'2',TO_DATE('01-JUL-09', 'DD-MON-RR'),TO_DATE('01-JUL-09', 'DD-MON-RR'),TO_DATE('01-JUL-09', 'DD-
MON-RR'),'1',NULL,NULL,'0',NULL,'6','1',NULL,NULL,NULL,NULL);

set transaction read write;
update "SYS"."CON$" set "CON#" = '10823' where "CON#" = '10822' and ROWID = 'AAAAAcAABAAAACqAAM';

commit;
set transaction read write;

SQL_REDO
------------------------------------------------------------------------------------------------------------------------
update "SYS"."CON$" set "CON#" = '10824' where "CON#" = '10823' and ROWID = 'AAAAAcAABAAAACqAAM';

commit;
set transaction read write;
update "SYS"."CON$" set "CON#" = '10825' where "CON#" = '10824' and ROWID = 'AAAAAcAABAAAACqAAM';

commit;
set transaction read write;
update "SYS"."CON$" set "CON#" = '10826' where "CON#" = '10825' and ROWID = 'AAAAAcAABAAAACqAAM';

commit;

set transaction read write;
update "SYS"."CON$" set "CON#" = '10827' where "CON#" = '10826' and ROWID = 'AAAAAcAABAAAACqAAM';

commit;
set transaction read write;
update "SYS"."CON$" set "CON#" = '10828' where "CON#" = '10827' and ROWID = 'AAAAAcAABAAAACqAAM';

commit;
set transaction read write;
update "SYS"."CON$" set "CON#" = '10829' where "CON#" = '10828' and ROWID = 'AAAAAcAABAAAACqAAM';

commit;
create table eygle as select * from dba_users;
set transaction read write;

Unsupported
update "SYS"."TSQ$" set "TS#" = '0', "GRANTOR#" = '43080', "BLOCKS" = '0', "MAXBLOCKS" = '0', "PRIV1" = '0', "PRIV2" = '
0' where "TS#" = '0' and "GRANTOR#" = '43072' and "BLOCKS" = '0' and "MAXBLOCKS" = '0' and "PRIV1" = '0' and "PRIV2" = '
0' and ROWID = 'AAAAAKAABAAAABbAAF';

commit;
set transaction read write;
SQL> exec dbms_logmnr.end_logmnr

PL/SQL procedure successfully completed.

很多时候拿LOGMNR来追踪一些误操作是很有效的方式，甚至在自己定制的数据同步中，LOGMNR也大有可为。

相关文章|Related Articles

评论数量(0)|Add Comments

本文网址：http://www.eygle.com/archives/2009/07/oracle10g_logmnr_easyuse.html

09:09 分区表用哪个级别的统计信息? (6885 Bytes) » AnySQL.net

这几天有几个分区表上的SQL执行计划不正常, 感觉上不应当, 已经设置了几个容易引起优化器选错执行计划的参数了.

ALTER SYSTEM SET OPTIMIZER_DYNAMIC_SAMPLING=0;
ALTER SYSTEM SET "_optim_peek_user_binds"=false;

按照现行的表分析原则, 只统计了表的全局索引, 不统计表分区上的索引, 因为分区会有增减操作, 不是每个分区都有数据, 也没有定下来要经常分析表, 而是分析后如果不出问题就不再分析. 现在SQL走错了, 可能的原因有什么呢? 重新分析一下不行, 看了一下执行计划, 发现全表扫描的COST值很底, 估计是用了分区上的统计信息了, 于是手动将全局的统计信息复制到每一个分区上得以解决.

为了得到原因, 回顾了一下当时的SQL, 发现有一个特征, 就是出问题的SQL都能定位到某个分区或某些分区, 今天就模拟了一下情况, 先只有全局统计信息. 首先用分区列范围查询, 去试了一下, 发现用的是分区级的统计信息.

SQL> select * from database_perf_statistics
2 where day > sysdate - 100 and day < sysdate + 300;

----------------------------------------------------------------
| Id | Operation | Cost (%CPU)| Pstart| Pstop |
----------------------------------------------------------------
| 0 | SELECT STATEMENT | 3 (0)| | |
|* 1 | FILTER | | | |
| 2 | PARTITION RANGE ITERATOR| 3 (0)| KEY | KEY |
|* 3 | TABLE ACCESS FULL | 3 (0)| KEY | KEY |
----------------------------------------------------------------

然后全表扫描, 涉及所有的分区时, 用的是全局的统计信息.

SQL> select * from database_perf_statistics;

----------------------------------------------------------
| Id | Operation | Cost (%CPU)| Pstart| Pstop |
----------------------------------------------------------
| 0 | SELECT STATEMENT | 2196 (1)| | |
| 1 | PARTITION RANGE ALL| 2196 (1)| 1 | 4 |
| 2 | TABLE ACCESS FULL | 2196 (1)| 1 | 4 |
----------------------------------------------------------

再测试一个开包的查询条件, 发现用的也是分区的统计信息.

SQL> select * from database_perf_statistics where day > sysdate - 100;

---------------------------------------------------------------
| Id | Operation | Cost (%CPU)| Pstart| Pstop |
---------------------------------------------------------------
| 0 | SELECT STATEMENT | 3 (0)| | |
| 1 | PARTITION RANGE ITERATOR| 3 (0)| KEY | 4 |
|* 2 | TABLE ACCESS FULL | 3 (0)| KEY | 4 |
---------------------------------------------------------------

重新设置了一下各分区的统计信息, 再验证一下上面的SQL的COST值, 就确定了是这个原因引起的, 需要更改一下我们的分析策略了.

Relative Posts:

2009/06/25 -- oramon如何收集V$SYSTEM_EVENT数据? (0)
2009/06/25 -- oramon如何从V$SESSION收集性能数据? (0)
2009/06/24 -- oramon如何从V$SYSSTAT收集性能数据? (1)
2009/05/22 -- 从oramon新报警中受益 (1)
2009/05/21 -- 用oramon的数据进行报警 (3)
2009/05/19 -- 新版oramon正式上线 (4)
2009/05/08 -- 分析性能数据之二 (3)
2009/05/08 -- 分析性能数据之一 (0)

06:31 恩墨科技为ChinaCache提供紧急救援服务 (3368 Bytes) » Oracle Life

©作者：eygle 发布在 eygle.com

近日，恩墨科技为ChinaCahce提供了紧急数据库援助服务。

ChinaCache成立于1998年，是中国领先的专业CDN服务提供商，向客户提供全方位网络内容快速分布解决方案。作为2000年就获信产部许可的 CDN服务提供商，目前ChinaCache在全国100多个大中城市拥有近500个节点，覆盖中国电信、中国网通、中国移动、中国联通、中国铁通和中国教育科研网等各大运营商。2007年，ChinaCache北美公司的建立，使ChinaCache网络覆盖了北美及亚太地区。

ChinaCahce与恩墨科技长期以来一直保持着良好的合作与联系，最近的一次意外断电事故，使得客户的数据库系统受到了影响，在经过了数小时的排查之后，客户请求我们介入协助寻求解决方案，在经过了全面的思考和一系列的尝试之后，我们成功的帮助用户恢复了数据库服务，使得TB级数据库能够再次提供服务。

感谢用户的信赖和支持，希望我们的服务能够继续为用户创造价值！

相关文章|Related Articles

评论数量(3)|Add Comments

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

23:00 对index直接rebuild的时候一定会是index fast full scan吗 (73037 Bytes) » Focus on Oracle

对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

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

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

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

| 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

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

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

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

| 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

16:35 DataReport的数据共享改进 (3547 Bytes) » AnySQL.net

用oramon将数据库的主要负载信息收集到了性能数据库, 用DataReport去显示这些性能数据时, 发现要写很多个SQL语句, 要不同的列显示一次, 例如要显示三幅图片(平均Load值, 用户CPU消耗, SQL执行次数)就得执行三个SQL.

WEBCHART.QUERY_1=SELECT TIME, LOAD FROM DATABASE_LOAD ...
WEBCHART.QUERY_2=SELECT TIME, CPUUSR FROM DATABASE_LOAD ...
WEBCHART.QUERY_3=SELECT TIME, EXECS FROM DATABASE_LOAD ...

其实DATABASE_LOAD是一个宽表, 可以一次查询出多个列的数据来, 几个图片可以共享一次查询的结果, 就可以减少数据库的执行次数, 提高页面访问速度. 如下所示, 只需要指定某个查询的SQL语句为减号.

WEBCHART.XCOL=TIME
WEBCHART.QUERY_1=SELECT TIME, LOAD, CPUUSR, EXECS
FROM DATABASE LOAD ...
WEBCHART.YCOL_1=LOAD
WEBCHART.QUERY_2=-
WEBCHART.YCOL_2=CPUUSR
WEBCHART.QUERY_3=-
WEBCHART.YCOL_3=EXECS

最近做了一次大的数据库改造, 用DataReport分析性能数据比较繁烦, 因此才注意到这个方面的性能提升.

Relative Posts:

07:41 LOB segment上的HW enqueue问题（9205 version） (6963 Bytes) » eagle's home

第一次遇到这个问题是在2006年，后来陆陆续续的遇到过好几次，都是在9205的版本上。

可是一直没有在自己的blog上好好总结一下。我以为自己写过了，今天想找给别人时才发现没有写过。

数据库版本当时为9205。问题表现为大量的active session等待在mod为6的HW enqueue上。

当前获得enqueue的session执行非常慢，平时小于一秒钟的DML操作现在大约需要几十秒钟才能完成。

查询v$lock得到下面的信息：

SID TY ID1 ———- — 3575 HW 16 159461642 3546 HW 16 159461642 3542 HW 16 159461642 3468 HW 16 159461642 3329 HW 16 159461642 2634 HW 16 159461642 2565 HW 16 159461642 2532 HW 16 159461642 2497 HW 16 159461642 2179 HW 16 159461642 1972 HW 16 159461642 1927 HW 16 159461642 1777 HW 16 159461642 1690 HW 16 159461642 1637 HW 16 159461642 1616 HW 16 159461642 1601 HW 16 159461642 1353 HW 16 159461642 1236 HW 16 159461642 1218 HW 16 159461642 1163 HW 16 159461642 1150 HW 16 159461642 1082 HW 16 159461642 1074 HW 16 159461642 987 HW 16 159461642 713 HW 16 159461642 683 HW 16 159461642 672 HW 16 159461642 535 HW 16 159461642 404 HW 16 159461642 ID2 LMODE REQUEST CTIME BLOCK
———- ———- ———- ———- ———- ———-
6 0 18 1
0 6 257 0
0 6 348 0
0 6 31 0
0 6 46 0
0 6 171 0
0 6 94 0
0 6 77 0
0 6 304 0
0 6 386 0
0 6 116 0
0 6 183 0
0 6 209 0
0 6 249 0
0 6 164 0
0 6 17 0
0 6 109 0
0 6 134 0
0 6 320 0
0 6 64 0
0 6 234 0
0 6 291 0
0 6 150 0
0 6 219 0
0 6 195 0
0 6 374 0
0 6 331 0
0 6 275 0
0 6 361 0
0 6 400 0

ID2是DBA,我们可以用“oracle DBA convertor”工具得到相应的File#和Block#

SQL> !dba 159461642

Oracle DBA convertor

by Stephan Haisley, Center Of Expertise, Oracle Corporation
RDBA: 0×981310a (159461642) File#: 38 Block#: 78090

SQL> select segment_name,partition_name,header_file,header_block from
SQL> dba_segments where segment_name=’SYS_LOB0000009458C00013$$’;

SEGMENT_NAME PARTITION_NAME HEADER_FILE HEADER_BLOCK

—————————————- —————————— ———– ————
SYS_LOB0000009458C00013$$ SYS_LOB_P19 38 65289
SYS_LOB0000009458C00013$$ SYS_LOB_P20 46 52489
SYS_LOB0000009458C00013$$ SYS_LOB_P21 38 78089 — 78090 = 78089+1

然后你会发现这个Block并不是Lob segment header，而是Lob segment header后面一个block。注意这一点非常重要，这是这一类问题的标准特征。

如果等待的block是segment header，那么你遇到的不是本文所描述的问题。

一般的HW enqueue发生在segment header上，而后面这个block是什么呢？

说到这个block，要从Lob segment的undo方式说起。Lob segment将old image存放在自己的segment中，而不是undo segment中。
这块存放old image的空间的大小有两种方式来定义，pctversion或者是retention。
对此不熟悉的同学可以参考我以前的两篇文章当ORA-01555遇到了LOB和PCTVERSION or RETENTION?

而这个block就是用来记录这些可以被回收的old image blocks，采用bitmap方式存储。

当可回收的old image space超过PCTVERSION定义的百分比时，新增加的数据可以从这些old image space中回收。

但是oracle在回收时有两个bug：

Bug 4867884(Note:4867884.8) - Lob HW lock contention with space reclaimation — fixed in 10.1.0.6, 10.2.0.3, 11g (Future version)
Bug 4113930(Note:4113930.8) - Space reclaimation shows HW enqueue contention with concurrent insert of LOBs — fixed in 9.2.0.8 , 10.1.0.5 , 10.2.0.1

触发这个bug有两个条件
1. 可回收的old image space超过PCTVERSION定义的百分比
2. concurrent transaction超过一定的数值，具体的值不清楚，我遇到问题时的concurrent transaction数目大约为30

所以解决这个问题就从上面两点来入手。

1.

最快解决问题的方法就是调大pctversion。

dump segment header后的那个block（38，78090）
alter system dump datafile 38 block 78090;

找到一行free blocks:10109615，根据这个可以算出free blocks所占的百分比，然后调整pctversion使其大于该百分比，这样就不会有回收空间的动作。
这一方法可以很快的解决问题，就是比较浪费空间。如果有维护的时间，可以通过move的方式来回收空间。

2.

从segment上的并发数入手，例如减少并发量，或者hash partition table使每个segment上面的并发数减少

06:46 恩墨科技为中电财提供顾问咨询及容灾服务 (3817 Bytes) » Oracle Life

近日，恩墨科技为中国电力财务有限公司提供数据库容灾环境实施及顾问咨询工作。

近年来，国内越来越多的公司开始认识到数据安全的重要，以各种手段和方式开始实施数据库安全架构。在众多的可选方案中，Oracle的DataGuard技术以其成本低、可用性及安全性能够满足绝大多数需求成为了很多企业的首选。在下个月即将发布的Oracle Database 11gR2版本中，Oracle Active DataGuard技术将得到进一步增强，可以预计，这一新版的的卓越新特性将为Oracle带来更多的客户。

中国电力财务有限公司（以下简称中国电财）成立于1993年，是经中国银行业监督管理委员会批准的一家全国性非银行金融机构。中国电财注册资本金50亿元，由国家电网公司控股、各省（市、区）电力公司等50家电力企、事业单位共同参股组建。经银监会批准，中国电财拥有东北、西北、华中和华东等多家区域性分公司，注册资本金、资产规模、利润总额等多项指标在国内财务公司行业中均名列前茅，在电力和金融行业树立了良好的企业形象，当选为中国财务公司协会理事长单位。

客户的数据库采用Oracle Database 10g RAC架构，异地容灾以Oracle DataGuard技术为主体实现。

感谢用户及合作伙伴用友公司的信赖与支持，希望稳健架构的实施可以帮助用户实现数据安全和业务连续性的需要。

相关文章|Related Articles

评论数量(1)|Add Comments

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

20:30 当无统计信息的时候ix_sel的值取决于什么 (53845 Bytes) » Focus on Oracle

在"利用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的值未变。

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

在无统计信息的情况下，ix_sel的值取决于#Rows，而不是取决于#Blks。

08:59 GreenPlum 架构 [Flickr] » DBA notes

02:00 Twitter 一周 for 2009-06-28 » Sky.Jian 朝阳的天空

00:08 Use index_desc » 玉面飞龙的BLOG

22:36 discuz on amoeba 乱码问题解决 » Amoeba 开发者博客

08:50 Amoeba for Mysql 1.0.0-BETA 版本发布 » Amoeba 开发者博客

04:22 DBA日记第二部 (31) 外来的和尚好念经 4月30日 IO优化 » DBA日记

03:06 常见索引扫描方式（四）：INDEX SKIP SCAN » DBARoad：我的DBA之路

20:36 如何快速安全的更改表的owner » eagle's home

2009-07-03 Fri

1.1.1. 5月12日 Richard的180度大转弯

2009-07-02 Thu

第一步：免费获取拥有SSH权限的帐号和密码。

第二步：配置MyEntunnel软件

第三步：配置Firefox浏览器

第四步：支持fuckGFW

版权信息：您可以自由复制、传播、演绎本作品且无需署名、无需注明原始出处。

相关文章

2009-07-01 Wed

Allocating Granules at Startup

Adding Granules to Components

1.1.1. 5月1日在家聊天

2009-06-30 Tue

Relative Posts:

2009-06-29 Mon

Relative Posts:

2009-06-28 Sun

2009-06-27 Sat

2009-06-26 Fri

1.1.1. 5月12日 Richard的180度大转弯

第一步：免费获取拥有SSH权限的帐号和密码。

第二步：配置MyEntunnel软件

第三步：配置Firefox浏览器

第四步：支持fuckGFW

版权信息：您可以自由复制、传播、演绎本作品且无需署名、无需注明原始出处。

相关文章

Allocating Granules at Startup

Adding Granules to Components

1.1.1. 5月1日 在家聊天

Relative Posts:

Relative Posts:

1.1.1. 5月1日在家聊天