Archive for January 27th, 2008
优秀的DBA要求是什么？
Sunday, January 27th, 2008
我不喜欢长篇累牍，我只喜欢写章节性的东西。可能是以前方案，标书写多了。貌似现代人，也普遍喜欢看短小精悍的东西。
我把我认为优秀DBA的标准整理如下：
1：具备优秀的心理素质；
2：丰富的经验；
3：扎实的基本功；
4：清晰的思路；
That’s all! Not anyone can be a good and success dba!!!
下雪引发的一系列事件联想到
Sunday, January 27th, 2008
周末下雪了，早没有了小时候孩童的那种兴奋，或许是看到太多的下雪，已经习惯了。可是对于那些出门在外的人来说，心情应该非常的不同。因为大雪，很多出行方式都被管制了，那些等待回家或有急事需出门的人，必定非常焦急。 气象部门很多天前就已经预测了最近的天气变化，然而估计大多数人都习惯了按照既定计划来安排最近要处理的事情，不会太在意这种变化带来的潜在问题，真的到那时遇到出行问题，估计只能叹气了。
联想到我们日常的工作，因为我们岗位的特殊性，必须尽可能避免这种类似事情的发生，这就要求我们要尽可能保持对周遭变化的敏感度，捕捉日常工作的看似平常的事情，关注某些变化可能带来的影响，做好预防工作。
基于时间的统计需求的一点技巧
Sunday, January 27th, 2008
当遇到一个基于时间的统计需求时，有些情况下是我们可能无法根据系统时间来得到需要统计的时间段（当然是指较精确的两个时间点之间），因为我们的job的执行时间点并不一定非常精确的是真正在我们设定想要的时间点来运行，很可能会有几秒甚至更长的差距。所以我们不可能完全根据job的执行时间点来简单的设定，在OLTP这样的高并发系统上尤其如此。
这种情况下，大多是通过额外方法来记录住上一次统计发生的时间点（在此我们只基于最新数据的统计），然后在下一次统计时就先拿到该时间，从该时间点来开始统计。这里就有一个记录统计时间点的问题：我们到底该记录哪个时间点合适呢？是统计开始的时候还是统计结束的时间点？
我们知道，Oracle为了保证数据的一致性，您在做查询的时候所读取的数据是基于查询开始的那个时刻一致的，也就是说您的查询过程中所读取的数据都是在该时间点的，不管在查询过程中是否有update或者insert都是如此。这就是Oracle非常著名的一致读特性，是基于回滚段和SCN来完成的。而且当查询时间太长以至于在此过程中有太多的transaction进行了commit使该查询需要的回滚段中的数据被覆盖的话，Oracle并不会给您一个不一致的结果，而是返回一个经典的错误，Ora-01555错误（snapshot too old）。
所以，我们最好将统计查询开始的时间定为该次统计的时间点，以此避免在统计过程的新数据在下一次（其实是永远）无法统计进来。但是就算是这样做我们也无法做到绝对精确。因为在更新统计时间和进行统计查询之间不管怎么做都是有一个时间差的，虽然可能只是毫秒级，但还是有可能在这段时间之间有事务提交，而这时候提交的数据同样也是永远无法统计进来了。
此外，还有一个办法可以避免此问题的出现，那就是如果是希望在统计结束的时候再更新您的统计时间的话，您必须将统计时间回退一个时间段，而且这个时间段的长短取决于您的系统中transaction的最长时间，一般一个oltp系统中的事务应该在10分钟之内吧。但是这个解决方案是有一个前提的，那就是我们的统计脚本重复运行（取决于统计脚本）不会影响统计结果。
因此，如何选择更新统计时间点的问题还是需要根据统计需求和系统事务的繁忙程度来决定。
