其实最终还是因为在短期内生成了大量的redo,造成了频繁的日志切换，导致归档占用了大量的空间，最后无法登录，从这个层面来说，我
接着上次分享的关于数据库无法登录的原因
其实最终还是因为在短期内生成了大量的redo,造成了频繁的日志切换，导致归档占用了大量的空间，最后无法登录，从这个层面来说，我们可以做一些工作来尽可能长时间的保留近期的归档，但是我们还可以换一个思路，那就是看看到底是什么操作生成了大量的redo,能不能试着减少redo的生成量。
一般来说，这个问题有点傻，日志肯定是记录尽可能完整的信息，这是做数据恢复的基础，我们还是不要过早下结论，先来分析一下再来做决定。
查看数据库的redo切换频率，在近几天内的redo切换频率极高，对于一个oltp的系统来说是很非常高的负载，这种频繁的日志切换我也只在数据迁移的一些场景中碰到过。
但是奇怪的是查看数据库的db time，却发现这个值其实并不高，看起来似乎有些矛盾，从这一点来看数据库内的数据变化频率其实并不是很高。
begin_snap end_snap snapdate duration_mins dbtime
---------- ---------- ----------------------- ----------
82560 82561 05 sep 2015 00:00 30 26
82561 82562 05 sep 2015 00:30 30 26
82562 82563 05 sep 2015 01:00 29 29
82563 82564 05 sep 2015 01:30 30 27
82564 82565 05 sep 2015 02:00 30 23
82565 82566 05 sep 2015 02:30 30 23
82566 82567 05 sep 2015 03:00 30 20
82567 82568 05 sep 2015 03:30 30 22
82568 82569 05 sep 2015 04:00 30 20
82569 82570 05 sep 2015 04:30 30 25
82570 82571 05 sep 2015 05:00 30 23
82571 82572 05 sep 2015 05:30 30 27
82572 82573 05 sep 2015 06:00 30 40
82573 82574 05 sep 2015 06:30 30 26
82574 82575 05 sep 2015 07:00 30 28
82575 82576 05 sep 2015 07:30 30 34
82576 82577 05 sep 2015 08:00 29 40
82577 82578 05 sep 2015 08:30 30 37
82578 82579 05 sep 2015 09:00 30 40
82579 82580 05 sep 2015 09:30 30 38
82580 82581 05 sep 2015 10:00 30 41
82581 82582 05 sep 2015 10:30 30 40
82582 82583 05 sep 2015 11:00 30 37
82583 82584 05 sep 2015 11:30 30 39
82584 82585 05 sep 2015 12:00 30 41
82585 82586 05 sep 2015 12:30 30 34
82586 82587 05 sep 2015 13:00 30 53
82587 82588 05 sep 2015 13:30 30 82
82588 82589 05 sep 2015 14:00 30 74
82589 82590 05 sep 2015 14:30 30 45
对于这种情况，我们还是抓取一个awr报告来看看。
在awr报告中，可以看到瓶颈还是主要在db cpu和iosh
top 5 timed foreground events
eventwaitstime(s)avg wait (ms)% db timewait class
db cpu 2,184 68.89
db file parallel read6,0964136813.02user i/o
log file sync65,199363611.47commit
db file sequential read46,03817245.43user i/o
direct path read415,6854601.47user i/o
查看时间模型，可以看到db cpu和sql相关的影响各占了主要的比例。
看到这，自己还是有些犯嘀咕，柑橘这个问题还是有些奇怪，能够关注的一个重点就是sql语句了，但是top 1的sql语句还是有些奇怪。
elapsed time (s)executionselapsed time per exec (s)%total%cpu%iosql idsql modulesql text
931.7314,4090.0629.3999.770.00jdbc thin clientupdate sync_id set ma...
这条语句执行频率极高，语句也很简单，但是cpu消耗却很高，初步怀疑是走了全表扫描。
语句如下：
update sync_id set max_id = :1 where sync_id_type = :2
简单查看执行计划，发现确实是走了全表扫描，如果碰到这个问题，第一感觉是需要走索引，没有索引可以建个索引，但是当我看到sql by executions这个部分时，自己感觉到问题其实不是那么简单。
可以看到第2个语句其实就是刚刚提到的top 1的sql，对应的指标还是很不寻常的，一次执行处理的行数近5000度行，执行了1万多次，处理的数据行数近8千万。
executionsrows processedrows per execelapsed time (s)%cpu%iosql idsql modulesql text
14,68414,6841.003.3994.7.7jdbc thin clientupdate sus_log set failed_c...
14,40978,329,3325,436.14931.7399.80jdbc thin clientupdate sync_id set ma...