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

    今天在火车上接到一个电话说,数据库有个报警,让我看看是怎么回事。

看着报警信息一直重复出现,看来是有些问题了。

    这是一个统计库,出现了DG相关的报警(自定义配置的),看起来是备库端接收归档的时候出现了问题。

Error 270 creating remote archivelog file 'sgstatdb3'

我们知道备库端其实是有一个80%的阈值控制闪回区的,当时限于在火车上,网络,信号不顺畅,所以让同事帮忙看了下,大体是说闪回区满了,但是系统层面设置了crontab定期去删除归档,每个小时会触发一次。

    
这样听起来闪回区依旧满好像也没有道理啊。我联系其之前碰到的类似问题,大体有几个猜测,一个是发生了SQL的性能问题,导致产生了大量的归档,导致闪回区使用率暂时还恢复不过来。另外一种就是闪回区设置太小,一些例行操作可能短时间生成归档,闪回区还一时应付不过来。

     结果没过一会,我发现自己的设想都不对,那是什么问题呢。

      首先尝试手工运行定时任务脚本来删除过期归档,竟然抛出了警告。

RMAN-08120: WARNING: archived log not deleted, not yet applied by standby
archived log file name=+ARCH/sgstatdb3/archivelog/2017_01_31/thread_1_seq_176745.384.934727315 thread=1 sequence=176745

我们在RMAN中设置了归档的删除策略是必须要应用到备库之后才可以删除。所以目前基本断定应该是在之前出现了一个断点。

      接着查看数据库日志发现近期的归档接收都是没有问题的,最新的归档都传输过来了,最后归档满了,新的归档接收不了了。

      原本的ADG现在状态是READ ONLY了。SQL> select open_mode from v$database;
OPEN_MODE
--------------------
READ ONLY      那么我们就需要找到之前是在哪个时间点出现了断点。

我读到了下面的一段日志内容,原来是在之前的一个时间点创建数据文件的时候报错了。

Datafile #872: '+DATA/sgstatdb3/datafile/tlbb_data.1197.933781165'
Fri xxx 15:41:40 2017
Errors in file /U01/app/oracle/diag/rdbms/sgstatdb3/statdb2/trace/statdb2_pr00_28125.trc:
ORA-01119: error in creating database file '+data'
ORA-17502: ksfdcre:4 Failed to create file +data
ORA-15041: diskgroup "DATA" space exhausted
File #873 added to control file as 'UNNAMED00873'.
Originally created as:
'/U01/app/oracle/oradata/statdb29/tlbb_data16.dbf'
Recovery was unable to create the file as a new OMF file.
MRP0: Background Media Recovery terminated with error 1274
Errors in file /U01/app/oracle/diag/rdbms/sgstatdb3/statdb2/trace/statdb2_pr00_28125.trc:
ORA-01274: cannot add datafile '/U01/app/oracle/oradata/statdb29/tlbb_data16.dbf' - file could not be created
Managed Standby Recovery not using Real Time Apply
Recovery interrupted!

通过这段日志可以看出,创建数据文件其实是这样一个动作,创建的时候空间慢了无法创建就会生成一个句柄,会默认在$ORACLE_HOME/dbs下生成。

我在备库端查看的情况如下:

SQL> select name from v$datafile where file#=873;
/U01/app/oracle/product/11.2.3/db_1/dbs/UNNAMED00873

文件管理的设置如下:

SQL> show parameter standby_file_management
NAME                                 TYPE        VALUE
------------------------------------ ----------- --------
standby_file_management              string      AUTO当然问题的原因到底是什么呢,是磁盘组的里出现了问题,备库端使用了ASM,才两个磁盘组,数据文件的磁盘组剩余16G左右,而归档所在的磁盘组剩余56M,而问题的原因是在哪里呢。是在数据文件的磁盘组+DATA上。

NAME     TOTAL_MB    FREE_MB
----------------- ----------
ARCH       204800         56
DATA      6383104      16214

      这个问题该怎么解释呢,因为主库创建一个数据文件,大概是30G,这个操作会映射到备库,也会在备库创建一个30G的数据文件,唯一的不同是数据文件名可以根据映射规则不同,但是在主库中空间充足,创建没有问题,在备库数据文件所在的磁盘组满了,创建不了一个30G的文件,所以这个操作就会生成一个断点,导致MRP直接异常退出,而我们设定的归档删除策略是保证归档应用到备库才可以删除,所以闪回区就会越放越满,直到几百GB的空间都满了。

    问题原因已经说明清楚了,接下来该怎么处理呢。这就是一个不太常规的思路了。我们就得做减法。备库空间不足,目前还无法直接扩容,所以问题处理的空间就有一定的局限性。

    我们知道主库和备库其实是有一些文件是不同的,比如temp文件,主库为30G,备库为1G也没有问题,是一种插件式的功能,而且不是必须的。所以要紧缩空间,temp就是一个首要考虑的选择,如果空间还不够怎么办,我们直接resize文件是不行的,因为主库resize的操作得等到之前的变更在备库应用完成之后才可以。那么还有哪些文件是可以暂时可清理,来应急处理这个问题呢。还有就是standby logfile了。一般是建议2*n+1的公式,我们可以在这个情况下先删掉几组,把空间先省出来,后续再调整。简单来说就是删temp文件,删除部分备库日志文件。

SQL> alter tablespace temp drop tempfile '+DATA/sgstatdb3/tempfile/temp.910.840550051';
Tablespace altered

.删除备库日志文件,如果报错,可以使用如下的方式处理。

SQL> alter database drop logfile group 26;
alter database drop logfile group 26
*
ERROR at line 1:
ORA-01624: log 26 needed for crash recovery of instance statdb2 (thread 1)
ORA-00312: online log 26 thread 1: '+DATA/sgstatdb3/onlinelog/group_26.907.840501783'
ORA-00312: online log 26 thread 1: '+DATA/sgstatdb3/onlinelog/group_26.908.840501785'

这样处理即可。

SQL> alter database clear unarchived logfile group 26;
Database altered.

SQL> alter database drop standby logfile group 26;
Database altered.

然后使用如下的方式重置数据文件,比如下面的例子:

alter database create datafile
'/U01/app/oracle/product/11.2.3/db_1/dbs/UNNAMED00874' as
'+DATA/sgstatdb3/datafile/tlbb_data17.dbf';

然后重新开启日志应用,但是发现RMAN开始不听话了。

$ rman target /
RMAN-00554: initialization of internal recovery manager package failed
RMAN-04005: error from target database:
ORA-00604: error occurred at recursive SQL level 1
ORA-01219: database not open: queries allowed on fixed tables/views only
ORA-06508: PL/SQL: could not find program unit being called: "SYS.X$DBMS_BACKUP_RESTORE"
ORA-06512: at line 1
RMAN-04015: error setting target database character set to ZHS16GBK

    看错误是在x$的一个对象上过不去了。这个时候简单想想x$是内存表,是在数据库启动的过程中初始化的,我们可以采用如下的策略来解决。

先让MRP开启归档日志应用,应用一部分归档,然后重启数据库到Mount状态,开启RMAN清理。这样闪回区的问题就解决了,都得算计着用空间。

   就这样花了个把小时的时间,问题总算是顺利解决了。

----------------------------------------------------------------------------------------

最后发起一个小活动,最近读了一些书,也交了一些书友,如果有愿意一起来参与读书的小伙伴们,咱们一起来吧,不限职业年龄,要求只有一个,喜爱读书即可。当然入群要推荐一本书。

    因为微信群扫码已满,需要加入的同学可以加我微信 jeanron100,说明来意和你推荐的一本书即可,我来加你入群。

    没啥目的,没啥动机,读书的事情我就不强求了,丰富自己,也可以互相聊聊。

时间: 2024-09-21 15:13:45

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

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

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

闪回数据库不是“万金油”(r11笔记第73天)

    闪回数据库这个特性在很多Oracle DBA眼里就是鸡肋特性,因为谁会因为恢复数据而需要在主库闪回,最后可能丢掉更多的数据,这个观点没错.     但是如果是备库呢,这个特性就顺利成章的满足了绝大多数的恢复需求,无论你是truncate,还是一些drop table的操作都是可以轻而易举的恢复.所以更多的时候我们其实更偏爱于Data Guard基础上的这种数据恢复方式,而原本的逻辑备份exp,expdp,物理备份RMAN就显得有些臃肿了.      拿一个真实的小案例来说明,有一次因为数

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

对于Oracle数据库的闪回区的设置,之前和一个同事和讨论过,总体来说有一些不同的意见. 首先这个闪回区是一个逻辑的概念,闪回区的大小不会严格依赖于磁盘空间的情况,比如磁盘空间目前剩余100G,但是你设置闪回区为200G是没有问题的. 如此一来,和只使用归档参数想比,这个闪回区似乎有一点问题,总体来说闪回区的管理还是比较方便的,可以监控管理闪回区中的归档,闪回日志,备份等的大小. 使用的视图为v$flash_recovery_area_usage,在11g做了简化,为v$recovery_are

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

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

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闪回区满

  一台老的测试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

Oracle 9i中的一个闪回查询操作实例

在利用闪回功能前需要确认: 1.用户有对dbms_flashback包有执行权限! 2.进行闪回查询必须设置自动回滚段管理,在init.ora设置参数UNDO_MANAGEMENT=AUTO,参数UNDO_RETENTION=n,决定了能往前闪回的最大时间,值越大就需要越多Undo空间. Oracle 9i中闪回查询操作实例 查看Oracle中Delete和Commit操作的流程分析 例:Oracle 9i的Flashback Query操作. (1)创建闪回查询用户 SQL> create u

我看好互联网阅读(r11笔记第63天)

    微信近几年进入了大家的视野,然后发展势头一发不可收拾,现如今已经形成了一个庞大的生态,当初看好还是看低,现如今已经经受了时间的考验,站稳了脚跟.举一个最简单的例子,今年过年拜年,除了个别亲戚朋友电话拜年外,剩下用短信拜年的我估计都是个位数吧,我个人今年只收到了一条拜年短信,剩下近千条都是微信中接收的.而前些年还在双线拜年.    而对于传统的阅读来说,是不是也能跟上互联网的大风呢.电子书本身不是个新鲜玩意,kindle,手机客户端都有读书软件,这个和互联网阅读有什么关系,我说的不一定对,

百倍性能的PL/SQL优化案例(r11笔记第13天)

我相信你是被百倍性能的字样吸引了,不过我所想侧重的是优化的思路,这个比优化技巧更重要,而结果嘛,其实我不希望说成是百倍提升,""自黑""一下.     有一个真实想法和大家讨论一下,就是一个SQL语句如果原本运行20秒,优化到了1秒,性能提升该说是20倍还是提高了95%.当然还见过一种说法,一条SQL语句每次运行20秒,每天运行100次,优化后每次运行1秒,运行还是100次,那么性能提升是说成优化累计时间为100*20-100=1990秒? 好了,我们来看看PL/S