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

简介: 对于Oracle数据库的闪回区的设置,之前和一个同事和讨论过,总体来说有一些不同的意见。 首先这个闪回区是一个逻辑的概念,闪回区的大小不会严格依赖于磁盘空间的情况,比如磁盘空间目前剩余100G,但是你设置闪回区为200G是没有问题的。

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

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

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


目录
相关文章
|
6天前
|
存储 Oracle 关系型数据库
Oracle的段:深入数据段与日志段的奥秘
【4月更文挑战第19天】Oracle数据库中的数据段和日志段是存储管理的核心。数据段存储表和索引的实际数据,随数据增长动态调整;日志段记录变更历史,保障数据完整性和恢复。两者协同工作,确保数据库稳定性和并发控制。了解和优化它们的配置能提升数据库性能和可靠性,为业务发展提供支持。
|
6天前
|
存储 关系型数据库 MySQL
认真学习InnoDB的数据存储结构中的区、段与表空间
认真学习InnoDB的数据存储结构中的区、段与表空间
59 2
|
10月前
|
NoSQL
XLOG段文件跳号现象分析
XLOG段文件跳号现象分析
30 0
|
10月前
|
消息中间件 关系型数据库 Shell
记录贴:sentry磁盘占用过大如何清理?
记录贴:sentry磁盘占用过大如何清理?
881 0
|
SQL 安全 关系型数据库
需要binlog的场景下,“暴力”干掉历史binlog文件,尽情释放磁盘空间
需要binlog的场景下,“暴力”干掉历史binlog文件,尽情释放磁盘空间
|
SQL 安全 关系型数据库
正确、安全的手动删除历史binlog,尽情释放磁盘空间。
正确、安全的手动删除历史binlog,尽情释放磁盘空间。
274 0
|
监控 关系型数据库 数据库