如果自己搞不定可以找诗檀软件专业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的修复已到位，来代替GI和RDBMS，如果GI和RDBMS是在12.1.0.2 BP4上。
- 我们开始先在一个磁盘组的一个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
- 我们现在通过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中脱机的单元格有备份，而且其中的所有磁盘都很好。所以，现在我们可以为 单元格/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块介质恢复来恢复这些扩展：
- 一旦MODE_STATUS列更改为ONLINE，卸载磁盘组并以常规方式将其安装:
SQL> alter diskgroup datac1 dismount;
改变磁盘组.
SQL> alter diskgroup datac1 mount;
改变磁盘组.
- 如果磁盘组DATAC1包含OCR，那么磁盘组被卸载时crsd就没命了，因为它不能访问OCR。如果是这样的话，那么这时故障磁盘组又被备份，应试图重新启动GI堆栈从而启动CRSD。如果由于丢失的写（如上所述），OCR损坏，因此未能重新启动，请遵循http://docs.oracle.com/database/121/CWADD/votocr.htm#CWADD92002，从最新的备份恢复OCR。一旦OCR已恢复，保证在后续步骤进行之前GI堆栈已完全启动。
- 一旦磁盘组联机，我们可以启动之前由于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
- 我们现在运行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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
- 现在，检查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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
- 现在执行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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
- 现在检查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