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

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

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

时间: 2024-09-20 11:02:30

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

闪回区空间不足引发的SQL问题分析

有一天上班的时候,收到一封报警邮件. ZABBIX-监控系统: ------------------------------------报警内容: archive_area_usage ------------------------------------报警级别: PROBLEM ------------------------------------监控项目: archive_area_usage:ARCHIVED LOG-->70.25--> ---------------------

一个闪回区报警的数据恢复(r11笔记第63天)

    今天在火车上接到一个电话说,数据库有个报警,让我看看是怎么回事. 看着报警信息一直重复出现,看来是有些问题了.     这是一个统计库,出现了DG相关的报警(自定义配置的),看起来是备库端接收归档的时候出现了问题. Error 270 creating remote archivelog file 'sgstatdb3' 我们知道备库端其实是有一个80%的阈值控制闪回区的,当时限于在火车上,网络,信号不顺畅,所以让同事帮忙看了下,大体是说闪回区满了,但是系统层面设置了crontab定期去

Oracle闪回区满

  一台老的测试AIX服务器,没人理过,最近一看Oracle闪回满了.清理了下. Version: Oracle 10gR2 for AIX 现象: ? 1 2 3 4 5 6 7 SQL> alter database open; alter database open * ERROR at line 1: ORA-16014: log 3 sequence# 157 not archived, no available destinations ORA-00312: online log 3

闪回区报警引发的性能问题分析(r11笔记第11天)

自从有了Zabbix+Orabbix,很多监控都有了一种可控的方式,当然对于报警处理来说,报警是表象,很可能通过表象暴露出来的是一些更深层次的问题.这不又来一个,不看不知道,一看让自己着实吓了一跳. 首先是一个报警信息,可以看到是闪回区超过了报警的阈值,为了尽可能提前发现问题,我把阈值设置为了70%,和Oracle默认的80%有一些差别. ZABBIX-监控系统: ------------------------------------ 报警内容: archive_area_usage ----

oracle闪回区管理

Errors in file /home/oracle/diag/rdbms/orarpt/orarpt/trace/orarpt_mmon_22508.trc: ORA-19815: WARNING: db_recovery_file_dest_size of 2147483648 bytes is 98.55% used, and has 31102976 remaining bytes available. *****************************************

用Oracle闪回功能恢复偶然丢失的数据

[导读]本文提出了闪回功能的原理,描述了利用Oracle 9i或Oracle 10g的闪回功能进行恢复偶然丢失数据的方法. 前言 人为的错误是数据库系统失败的重要原因之一,根据调查约40%的系统问题是操作失误或者用户错误引起的,这些人为的错误又特别难以避免.传统上当发生数据丢失.数据错误问题时,解决的主要方法就是数据的导入/导出.备份/恢复技术.这些方法都需要发生数据错误之前有一个正确的备份,才能进行恢复.恢复时不取决于错误程度,而只取决于备份/恢复策略.这种方法既耗时又使数据库系统不能提供服务

物化视图实现的特殊数据复制(r11笔记第42天)

  今天开发同事碰到一个有些复杂的数据复制需求,想让我帮忙看看能否实现,当然猛一听需求是不可能实现的.不过还是耐着性子和他们讨论了一下,不过我想了下,似乎还是有改进的余地,也算是拨云见雾吧.   目前有一个表做了拆分,即分库分表.在统计业务中还是需要把数据整合起来查询.大体就是下面的架构方式. 源端是一些分库,存在一些不同的用户,里面存放着相同结构的表.数据根据拆分规则进入不同的分库. 目标端是统计业务所用,没有使用OGG,而直接使用物化视图的方式做了数据刷新复制,当然目标端由此就有了相同数量的

10g关闭归档/启用闪回恢复区归档

一.关闭归档 1.启动SQL*PLUS以管理身份登录Oracle数据库: SQL> connect / as sysdba 2.关闭数据库实例 SQL> shutdown immediate 3.备份数据库:在对数据库做出任何重要的改变之前,建议备份数据库以免出现任何问题. 4.启动一个新的实例并装载数据库,但不打开数据库: SQL> startup mount 5.禁止自动存档 SQL> alter system archive log stop; 6.禁止存档联机重做日志:转换

Oracle 闪回技术详细介绍及总结_oracle

Oracle闪回技术详解,这里整理了4种闪回技术,对Oracle 闪回技术做一个整理总结.  概述: 闪回技术是Oracle强大数据库备份恢复机制的一部分,在数据库发生逻辑错误的时候,闪回技术能提供快速且最小损失的恢复(多数闪回功能都能在数据库联机状态下完成).需要注意的是,闪回技术旨在快速恢复逻辑错误,对于物理损坏或是介质丢失的错误,闪回技术就回天乏术了,还是得借助于Oracle一些高级的备份恢复工具如RAMN去完成(这才是Oracle强大备份恢复机制的精髓所在啊)  撤销段(UNDO SEG