ITPub博客

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

原创 Oracle 作者:jeanron100 时间:2016-12-14 23:33:45 0 删除 编辑

对于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,这个参数还是值得好好琢磨一番,但是目前来看,经过大量的测试没有完全验证。

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

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


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/23718752/viewspace-2130620/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2012-05-14

  • 博文量
    1667
  • 访问量
    14197218