关于闪回区溢出导致的数据hang（r11笔记第12天）

对于Oracle数据库的闪回区的设置，之前和一个同事和讨论过，总体来说有一些不同的意见。

首先这个闪回区是一个逻辑的概念，闪回区的大小不会严格依赖于磁盘空间的情况，比如磁盘空间目前剩余100G,但是你设置闪回区为200G是没有问题的。

如此一来，和只使用归档参数想比，这个闪回区似乎有一点问题，总体来说闪回区的管理还是比较方便的，可以监控管理闪回区中的归档，闪回日志，备份等的大小。

使用的视图为v$flash_recovery_area_usage，在11g做了简化，为v$recovery_area_usage

一个查看闪回区的使用率的结果如下：

select *from v$flash_recovery_area_usage;

FILE_TYPE               PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
----------------------- ------------------ ------------------------- ---------------
CONTROL FILE                             0                         0               0
REDO LOG                               .18                         0               2
ARCHIVED LOG                         40.09                         0             320
BACKUP PIECE                             0                         0               0
IMAGE COPY                               0                         0               0
FLASHBACK LOG                        59.08                         0             366
FOREIGN ARCHIVED LOG                     0                         0               0

闪回区的使用有几个地方比较纠结，那就是关于闪回hang的问题。

简单来说，可以归为以下几类。

首先是闪回区空间设置大于磁盘实际空间大小，这种情况下，竟然闪回区可用，但是磁盘空间不足，这种情况下就会造成归档无法生成或切换，影响会很大，当然系统的监控是必要的，如果疏忽了，那么数据库层面的这一道防线就会因为闪回区的这种设置而被突破。

第二种情况下是闪回区的大小溢出，比如设置闪回区大小为100G,刚好达到了临界值，这个时候很可能出现两种情况，一种是无响应，表现为登录，登出都会完全没有响应，数据库直接被卡住，这种情况下很可能是有在线的事务在运行。而另外一类则是非常经典的错误。

SQL> conn test/xxxx ERROR: ORA-00257: archiver error. Connect internal only, until freed.

想必这个问题大家都见过很多次了，这个问题其实相比数据库hang的影响要略微小一些。至少应用连不进来，而第一种会造成的结果是，如果应用不断尝试连接，但是无响应，就会短时间内造成大量会话阻塞，然后消耗系统资源殆尽。如果有的服务器抗不了瞬间的压力，还可能瞬间宕机。

第二类问题其实还算是相对温和的，登录不了，连接直接被拒绝。

解决方法其实就很简单了，一种是扩大闪回区，另外一种是删除一些不需要的归档文件等，释放闪回区的空间。

当然还有一种场景会把这个问题放大，那就是核心系统一旦出现这类问题，这个影响就会非常大，这句话怎么理解，如果因为闪回区过小导致了数据库hang的问题，在5分钟的时间内是完全没有响应的，尽管你使用sysdba修改了闪回区大小，调整了空间，但是问题会短时间内（默认5分钟）内存在，如果碰上这样的情况，绝对会让人格外抓狂，在我的职业生涯中还真碰到过。在很紧急的关头，你的第一反应和冷静处理就绝对反映出了你真正的技能和知识储备。说不紧张那都是骗人的，只能让自己的心里平复一下，想明白该怎么做，避免错上加错的操作让问题向另外一个方向走去。

这个5分钟是怎么得来的，我是专门做了下这类测试，开启了多个窗口，加上人工的操作延时，抓取到的时间戳如下：

SQL*Plus: Release 11.2.0.4.0 Production on Wed Dec 14 17:52:18 2016 SQL*Plus: Release 11.2.0.4.0 Production on Wed Dec 14 17:57:38 2016从这个结果可以基本看出是一个5分钟的频率，因为有手工的延迟问题。

当然这只是猜测，有什么其他的方式来论证呢，我首先查看了数据库的隐含参数。发现还真有几个隐含参数的设置是300秒的。

_hang_ignored_hangs_interval _flashback_max_standby_sync_span _dbwr_scan_interval _hang_monitor_archiving_related_hang_interval

当然要做严谨的测试，还是很有难度，自己反复尝试没有得到一个确凿的证据指向这几个参数会直接影响Hang的问题，那还有什么问题呢。

还有一个就是数据库的归档参数，归档参数有一个属性是reopen，默认是300秒。

自己测试了几个场景，有的表现要好一些，有的则达不到预期效果，所以这个参数作为备选。

还有一个参数是LOG_ARCHIVE_MIN_SUCCEED_DEST,这个参数还是值得好好琢磨一番，但是目前来看，经过大量的测试没有完全验证。

所以经过我的一番测试，达到临界值的情况下，有些场景中以上的隐含参数和归档参数设置都会有一定的影响，但是没有产生立竿见影的效果。

这个测试还要继续进行，大家有什么更好的建议也希望一并指出。