这是数据库异常恢复实战第12讲，突然发现已经有2周没有更新了，实在是抱歉，最近几周真的很忙，好多已经订阅的朋友已经在伙伴群催更多次了。。。
前面我们一共用了11个小节来分别给大家讲了控制文件和redo的一些基础原理、机制；根据之前的大纲内容，接下来2个小节将为大家分享一下Oracle中的检查点机制，实际上这是一个非常关键的机制，这个月已经遇到2次跟检查点相关案例，其中某客户exadata x7环境，跑几天就反应慢，据说厂商折腾了几周无果，针对这个case的简单分析过程，这里我给大家分享一下。
首先我们来这个用户故障反应普遍比较慢的情况，我们先看load profile和top event：
接下来我们看客户反馈重启业务恢复了（据说重启后跑2-3天又会整体变慢）。
cell smart table scan可以理解为全表扫描，只不过这是Oracle exdata x7的环境，同时我们也可以看到cell single block physical reads 似乎慢了很多。
这是什么原因呢？
实际上要判断是不是IO影响了，那么我们可以找个awr中的业务sql看看就知道了。如下是前后2份报告的部分截图：
我们可以发现这个sql相对正常的情况下平均单次执行时间时0.06s，而业务反应比较慢的情况下平均单次执行时间时0.22s，看上去慢了3倍多，而且执行次数还低了几倍。
客户的数据库维护厂商和其他支持者都看了2周了，也检查了网络、包括一体机硬件等等都，都没有发现任何问题。
那么为什么业务跑2-3天就整体慢了，重启之后又好了，然后过几天又慢了？
对于这样业务量，我想说，确实有点大，但是还不至于连宇宙最强的exadata都扛不住吧。
据说厂商建议客户扩容，将exadata半配扩充为满配。。。。。
当看了厂商提供的上述2个awr之后，我大概就知道问题所在了，让运维尝试调整了一个fast_start_mttr_target参数；据反馈观察了好几天，发现居然不再变慢了，用户再也不需要每周重启了。快1个月过去了，这个案例可以公布出来了。
想想这个客户也是4年前，每2周宕机一次，折腾了大半年，后面我去帮忙处理了，最终客户采购了我们zdata一体机作为exadata的容灾库。
