一个数据库报警的数据恢复(r11笔记第62天)-dbf文件怎么打开

一个数据库报警的数据恢复(r11笔记第62天)

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

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

这是一个统计库，出现了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;