使用12.1.0.2版”mount restricted force for recovery”功能,磁盘组恢复故障–一个例子

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638    QQ号:47079569    邮箱:service@parnassusdata.com

 

 

应用于:

Oracle数据库- 企业版- 12.1.0.2版本和更高版本

本文档中的信息适用于任何平台。

目标

描述这个新功能并利用该功能演示一个程序,以简化故障磁盘组的恢复

解决方案

范围

此功能适用于ASM以下版本

对于 12c, ASM 版本必须 >= 12.1.0.2 BP4

对于 11g, ASM 版本必须 >= 11.2.0.4 BP16

 

概述Overview
12.1.0.2 BP4引入的一个功能就是”mount restricted force for recovery”选项,在磁盘组安装时用于复活故障磁盘组。此功能仅适用于普通冗余磁盘组。

正如下面的例子所示,当一个普通冗余磁盘组遇到瞬态故障迫使盘处于离线状态时,此功能是非常有用的,接下来便是合伙盘的永久性故障。

对于那些非暂时的磁盘故障,且因此磁盘无法联机,该功能可以配合使用“替换磁盘”功能,来进行数据库恢复。

对于数据库云服务器的安装,以下的failgroup指的是单元格。

对于正常的冗余磁盘组,如果failgroup的一部分或整个failgroup失败,或离线后有额外的合伙磁盘故障,磁盘组被拆卸,并且由于丢失太多的磁盘,用常规的“alter diskgroup mount”命令不能将其再次安装。如果没有 “mount restricted force for recovery”功能,我们需要使用amdu从卸载的磁盘组提取文件,或是在重建故障磁盘组后从完整的数据库备份进行恢复。这使得恢复过程耗时且有难度。

有了这项新功能,我们实际上就可以安装限制恢复的磁盘组,即使有太多磁盘离线/丢失。然后,如果脱机的磁盘现已上市,且有资格上线(例如,在数据库云服务器环境中,离线的单元格现在备份),我们可以使这些磁盘在线,并随后尝试恢复数据库。

值得注意的是,如果第二个磁盘/ failgroup故障是暂时的,例如数据库云服务器单元被关闭,随后开始备份。当被关闭的第二个单元格开始备份,我们就不再需要此功能来安装磁盘组。在这种情况下,我们就能以正常方式进行安装。

在第一个故障 failgroup 中,出故障的第二个盘将是一些离线磁盘的合伙盘。因此,当我们使第一个failgroup中之前的脱机磁盘联机,重新同步活动将找不到同步的镜像范围(它是在第二个出故障的磁盘中)。所以,在第一个failgroup故障磁盘上无论丢失了什么 写,其镜像副本是在第二故障磁盘上,在第一failgroup磁盘出错之后,随后的第二磁盘故障出现之前这间隔期间,将在重新同步活动期间得到BADFDA7A并腐败块。但是,我们有这些损坏块列表,且本文档也演示了如何找到该列表。然后,我们可以在这些块上执行RMAN块介质恢复,或在备用数据库上将其截取,并在之后恢复故障数据库。

此功能的好处是,我们不需要用amdu提取文件或还原完整的数据库并恢复,从而节省了大量的时间来获取故障数据库的备份。

 

只有满足以下条件,这种新行为才可用:

  • ASM磁盘组是正常冗余磁盘组,由3个或更多failgroups。
  • ASM 软件版本 >= 12.1.0.2 DBBP4 and 11.2.0.4 DBBP 16
  • 经历了瞬时故障的磁盘都处于离线状态。没有磁盘应该处于强制状态。

潜在的使用案例,这一程序将适用于:
1.云服务器单元格滚动升级/修补,同时合伙磁盘出现故障

2.单元格中暂时的云服务器磁盘故障,之后会有永久性的合伙盘故障,之后第一个故障磁盘恢复联机。

 

下面演示了上述安装故障磁盘组的步骤中所描述的故障情景,并最终使得故障数据库重新运行起来。 

示范

所有的测试都在数据库云服务器环境中进行,因此一个failgroup对应一个Exadata单元。

开始之前,我们需要确保对错误20217875的修复已到位,来代替GIRDBMS,如果GIRDBMS是在12.1.0.2 BP4上。

 

  1. 我们开始先在一个磁盘组的一个failgroup 中使所有磁盘脱机。

使一个完整的Exadata单元离线就可以模拟这种情况:

CellCLI> Alter cell shutdown services all;

在非数据库云服务器环境中,使用”alter diskgroup datac1 offline disks in failgroup CELLFG1″;

对于磁盘组datac1 (group#1), CELLFG1单元格中的所有磁盘变成脱机状态:

ASMCMD> lsdsk -p

Group_Num  Disk_Num      Incarn  Mount_Stat  Header_Stat  Mode_Stat  State   Path

1         0  3940618960  MISSING     UNKNOWN      OFFLINE    NORMAL

1         2  3940618963  MISSING     UNKNOWN      OFFLINE    NORMAL

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

2         1  3940618995  MISSING     UNKNOWN      OFFLINE    NORMAL

2         2  3940618996  MISSING     UNKNOWN      OFFLINE    NORMAL

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

3        10  3940619036  MISSING     UNKNOWN      OFFLINE    NORMAL

3        11  3940619026  MISSING     UNKNOWN      OFFLINE    NORMAL

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

ASM alert.log也显示,退出磁盘超时已经启动,如下所示:

WARNING: Started Drop Disk Timeout for Disk 0 (DATAC1_CD_00_CELLFG1) in group 1 with a value 86400

WARNING: Disk 0 (DATAC1_CD_00_CELLFG1) in group 1 will be dropped in: (86400) secs on ASM inst 2

WARNING: Started Drop Disk Timeout for Disk 2 (DATAC1_CD_02_CELLFG1) in group 1 with a value 86400

 

  1.    我们现在通过failgroup中的磁盘故障来引入第二个磁盘故障,但不是在第一步中操作的failgroup中(我们在failgroup CELL FG2中引入第二次故障):

在数据库云服务器环境中,可以从单元格中发出”alter physicaldisk <disk> simulate failureType=failed;”命令。对于非云服务器环境,需要用适当的方法来模拟磁盘故障。

从ASM alert.log中可以看到,由于离线磁盘太多,磁盘组就会被卸载:

ERROR: disk 15(DATAC1_CD_03_CELLFG2) in group 1(DATAC1) cannot be offlined because all disks [15(DATAC1_CD_03_CELLFG2), 3(DATAC1_CD_03_CELLFG1)] with mirrored data would be offline.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 

ERROR: too many offline disks in PST (grp 1)

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 

Sat Jan 31 14:09:11 2015

SUCCESS: alter diskgroup DATAC1 dismount force /* ASM SERVER:1797125976 */

SUCCESS: ASM-initiated MANDATORY DISMOUNT of group DATAC1

因此在数据库alert.log中我们看到数据库崩溃,因为被卸载的DATAC1 磁盘组拥有着所有的数据库数据文件:

Errors in file /u01/app/oracle/diag/rdbms/dbm01/dbm012/trace/dbm012_dbw2_59801.trc:

ORA-63999: data file suffered media failure

ORA-01114: IO error writing block to file 2 (block # 7966)

ORA-01110: data file 2: ‘+DATAC1/DBM01/DATAFILE/sysaux.258.870285515’

ORA-15081: failed to submit an I/O operation to a disk

ORA-15081: failed to submit an I/O operation to a disk

ORA-15066: offlining disk “DATAC1_CD_03_CELLFG2” in group “DATAC1” may result in a data loss

USER (ospid: 59801): terminating the instance due to error 63999

  1.    这时,我们假设步骤1中脱机的单元格有备份,而且其中的所有磁盘都很好。所以,现在我们可以为 单元格/failgroup联机磁盘组 datac1 中的所有磁盘。但是要做到这一点,首先要安装磁盘组。

由于过多的磁盘仍处于脱机状态,磁盘组的常规安装尝试将失败:

SQL> alter diskgroup datac1 mount;

alter diskgroup datac1 mount

*

ERROR at line 1:

ORA-15032: not all alterations performed

ORA-15040: diskgroup is incomplete

ORA-15066: offlining disk “15” in group “DATAC1” may result in a data loss

ORA-15042: ASM disk “15” is missing from group number “1

我们需要使用新的 mount restricted force for recovery”选项来安装磁盘组,这样我们就有机会使得之前脱机的磁盘联机。由于这里使用限制安装,必须从ASM实例开始尝试。

请参考 http://docs.oracle.com/database/121/OSTMG/asminst.htm#OSTMG13640 有更多关于限制安装的信息

SQL> alter diskgroup datac1 mount restricted force for recovery;

磁盘组变更.

开始之前,核实并确认 failgroup CELLFG2重的第二个故障磁盘状态在v$asm_disk.中显示为脱机。 ASMCMD lsdsk-p”可以显示。

这里应当注意的,当磁盘组在这种模式下被安装,离线定时器会停止滴答。所以该模式下安装磁盘组时ASM服务器不可能强制该磁盘退出。

现在,我们要为最初的故障failgroup CELLFG1将脱机的磁盘联机:

SQL> alter diskgroup datac1 online disks in failgroup CELLFG1;

磁盘组变更.

一旦发出上面的命令,联机磁盘上 v$asm_disk中的MODE_STATUS列将成为SYNCING。

应当指出,如果任何其他磁盘/单元格脱机,而磁盘组在限制安装模式下又被卸载,就必须在限制模式下从头开始重新装载磁盘组。

这时一定要等到V $ ASM_DISK中正联机的磁盘MODE_STATUS列从SYNCING变为ONLINE,这一点非常重要。 V $ asm_operation可用于跟踪重新同步活动的进展情况,若没有行返回,V $ ASM_DISK中磁盘的MODE_STATUS应更改为ONLINE。

如果mode_status栏显示SYNCING,不要执行后续步骤,否则会导致数据损坏。

当如上所述发出 “online disks” 命令,ASM将尝试重新同步新联机的磁盘,ASM alert.log会显示如下条目::

SUCCESS: alter diskgroup datac1 online disks in failgroup CELLFG1

Mon Feb 02 09:17:35 2015

NOTE: starting rebalance of group 1/0xfca7960f (DATAC1) at power 1

Starting background process ARB0

Mon Feb 02 09:17:35 2015

ARB0 started with pid=30, OS id=42778

但是,重新同步的一部分,Arb0会试图读取新联机盘的合伙盘,用于更新旧的扩展。但由于第二个磁盘故障,无法读取所需的扩展(在第二个故障磁盘中),因此将那些丢失的扩展标记为BADFDA7A。这个在arb0跟踪文件中会显示,ASM alert.log中已获悉:

ERROR: ORA-15000 thrown in ARB0 for group number 1

Mon Feb 02 09:17:37 2015

Errors in file /u01/app/oracle/diag/asm/+asm/+ASM1/trace/+ASM1_arb0_42778.trc:

ORA-15000: command disallowed by current instance type

Mon Feb 02 09:17:37 2015

NOTE: stopping process ARB0

Mon Feb 02 09:17:38 2015

上面强调的文件“u01/app/oracle/diag/asm/+asm/+ASM1/trace/+ASM1_arb0_42778.trc” 显示了带BADFDA7A标记的文件扩展

 WARNING: group 1, file 258, extent 100: filling extent with BADFDA7A during recovery

 WARNING: group 1, file 258, extent 100: filling extent with BADFDA7A during recovery

 WARNING: group 1, file 258, extent 100: filling extent with BADFDA7A during recovery

 WARNING: group 1, file 258, extent 100: filling extent with BADFDA7A during recovery

  

在后续步骤中我们可以用RMAN块介质恢复来恢复这些扩展:

  1. 一旦MODE_STATUS列更改为ONLINE,卸载磁盘组并以常规方式将其安装:

SQL>  alter diskgroup datac1 dismount;

改变磁盘组.

SQL> alter diskgroup datac1 mount;

改变磁盘组.

  1. 如果磁盘组DATAC1包含OCR,那么磁盘组被卸载时crsd就没命了,因为它不能访问OCR。如果是这样的话,那么这时故障磁盘组又被备份,应试图重新启动GI堆栈从而启动CRSD。如果由于丢失的写(如上所述),OCR损坏,因此未能重新启动,请遵循http://docs.oracle.com/database/121/CWADD/votocr.htm#CWADD92002从最新的备份恢复OCR。一旦OCR已恢复,保证在后续步骤进行之前GI堆栈已完全启动。
  2. 一旦磁盘组联机,我们可以启动之前由于datac1 磁盘组强制卸载而崩溃的数据库,因为该磁盘组持有数据文件。  

一旦数据库启动,alert.log 中会报告块损坏,如下所示:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 

Corrupt block relative dba: 0x0080c841 (file 2, block 51265)

Bad header found during multiblock buffer read

Data in bad block:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 

 consistency value in tail: 0xbadfda7a

 check value in block header: 0xda7a

 block checksum disabled

Reading datafile ‘+DATAC1/DBM01/DATAFILE/sysaux.258.870285515’ for corruption at rdba: 0x0080c841 (file 2, block 51265)

Read datafile mirror ‘DATAC1_CD_01_CELLFG1’ (file 2, block 51265) found same corrupt data (no logical check)

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 

在受影响的文件上运行 dbverify,报告损坏 :

样本 dbv 输出:

DBVERIFY – Verification complete

Total Pages Examined         : 1536000

Total Pages Processed (Data) : 8406

Total Pages Failing   (Data) : 0

>>>>>>>>>>>>>>>>>>>>>>>>>

Total Pages Empty            : 1501923

Total Pages Marked Corrupt   : 512

Total Pages Influx           : 0

Total Pages Encrypted        : 0

Highest block SCN            : 0 (0.0

 

  1. 我们现在运行rman backup validate ,该操作将损坏的数据文件扩展与相应的文件号填充到V $ DATABASE_BLOCK_CORRUPTION

RMAN> backup validate database;

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

List of Datafiles

=================

File Name: +DATAC1/DBM01/DATAFILE/sysaux.258.870285515

Block Type Blocks Failing Blocks Processed

————— —————– ————————-

Data       0              10277

Index      0              10822

Other      1294           19622          

validate found one or more corrupt blocks

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 

List of Datafiles

=================

File Name: +DATAC1/DBM01/DATAFILE/system.257.870285509

Block Type Blocks Failing Blocks Processed

———- ————– —————-

Data       0              329137

Index      0              6874

Other      2303           6073           

validate found one or more corrupt blocks

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

 

  1. 现在,检查V $ DATABASE_BLOCK_CORRUPTION是否充斥着损坏的数据文件扩展,确实如此:

SQL> select * from V$DATABASE_BLOCK_CORRUPTION;

 

FILE#     BLOCK#     BLOCKS CORRUPTION_CHANGE# CORRUPTIO     CON_ID

———- ———- ———- —————— ——— ———-

2      37079          2                  0 CORRUPT            0

2      37083          1                  0 CORRUPT            0

2      37087          2                  0 CORRUPT            0

1      47936          1                  0 CORRUPT            0

2      51246          1                  0 CORRUPT            0

2      51222          1                  0 CORRUPT            0

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

2      37200         41                  0 CORRUPT            0

2      37246          1                  0 CORRUPT            0

2      37256        120                  0 CORRUPT            0

1      47872         64                  0 CORRUPT            0

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

1      74752        512                  0 CORRUPT            0

1      84480        512                  0 CORRUPT            0

1      97280        512                  0 CORRUPT            0

1     102912        512                  0 CORRUPT            0

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

 

  1. 现在执行RMAN块介质恢复以恢复损坏的块,如 v$database_block_corruption视图中所示。

这里我们假设,数据库的良好备份和归档日志都存在,尚未备份的归档日志与联机redo日志在磁盘上都可用,以帮助实现完全恢复。如果不是这种情况,就选择不完全恢复。

RMAN> blockrecover corruption list;

Starting recover at 02-FEB-15

>>>>>>>>>>>>>>>>>>>>>

channel ORA_DISK_1: restoring block(s)

channel ORA_DISK_1: specifying block(s) to restore from backup set

restoring blocks of datafile 00001

channel ORA_DISK_1: reading from backup piece +RECOC1/DBM01/BACKUPSET/2015_01_30/nnndf0_tag20150130t131121_0.281.870354683

channel ORA_DISK_1: piece handle=+RECOC1/DBM01/BACKUPSET/2015_01_30/nnndf0_tag20150130t131121_0.281.870354683 tag=TAG20150130T131121

>>>>>>>>>>>>>>>>>>>

starting media recovery

archived log for thread 1 with sequence 5 is already on disk as file +RECOC1/DBM01/ARCHIVELOG/2015_01_30/thread_1_seq_5.285.8

70354687

archived log for thread 1 with sequence 7 is already on disk as file +RECOC1/DBM01/ARCHIVELOG/2015_01_30/thread_1_seq_7.292.8

70357777

archived log for thread 1

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

media recovery complete, elapsed time: 00:01:16

Finished recover at 02-FEB-15

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

>

 

  1. 现在检查V $ DATABASE_BLOCK_CORRUPTION,结果什么都不存在,以确认所有损坏的区块都已修复:

SQL> select count(*) from V$DATABASE_BLOCK_CORRUPTION;

COUNT(*)

———-

0

Dbverify 也报告 0 损坏:

Total Pages Examined         : 1536000

Total Pages Processed (Data) : 9120

Total Pages Failing   (Data) : 0

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Total Pages Empty            : 1500769

Total Pages Marked Corrupt   : 0

Total Pages Influx           : 0

Total Pages Encrypted        : 0

Highest block SCN            : 0 (0.0)

 

结论

若两个合伙盘出故障或无法访问,该事件是灾难性的。使用此功能,恢复过程大大简化,且有可能以更少的时间成本和数据损失实现完全恢复。本例中的数据库恢复时间明显减少,相当于少数块的块介质恢复,而不是一个完整的数据库还原和恢复,这大大减少了恢复时间。

Comment

*

沪ICP备14014813号-2

沪公网安备 31010802001379号