近日遇到一个问题，就是ASM diskgroup无法挂载，通过分析之后，发现有会快存在，但是由于没有备份，没有办法重建diskgroup并从backup恢复--所以所以所以....备份很重要啊！不然，哭！！是早晚的事情！

通过解决这个问题，我在自己的测试环境测试了如何在ASM diskgroup无法mount的情况下，尽量挽救数据文件。

这里使用到oracle 工具AMDU，该具体信息可以参考AMDU functionality and usage (Doc ID 855791.1)

1. 由于diskgroup无法挂载，SPFILE、CONTROLFILE、DATAFILE都无法读取

根据步骤，我们首先需要恢复spfile文件，spfile文件存在的意义就是找到control_files的位置，如果spfile无法访问，需要查找备份。

SQL> show parameter control_files

+DATA/db/controlfile/current.260.804295233, +FRA/db/controlfile/current.256.804295237

2. 通过ASM实例找到asm_diskstring

SQL> show parameter disk

NAME TYPE VALUE

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

asm_diskgroups string DATA, FRA

asm_diskstring string /dev/sd*

3. 查找asm disk的路径，后续要指定diskstring来扫描磁盘

SQL> select NAME,STATE,TYPE,OFFLINE_DISKS,VOTING_FILES from v$asm_diskgroup;

SQL> col PATH for a50

SQL> col name for a10

SQL> set line 200

SQL> select DISK_NUMBER,GROUP_NUMBER,PATH,name from v$asm_disk;

DISK_NUMBER GROUP_NUMBER PATH NAME

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

1 2 /dev/oracleasm/disks/ASMDISK5 FRA_0001

0 2 /dev/oracleasm/disks/ASMDISK4 FRA_0000

2 1 /dev/oracleasm/disks/ASMDISK3 DATA_0002

DISK_NUMBER GROUP_NUMBER PATH NAME

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

1 1 /dev/oracleasm/disks/ASMDISK2 DATA_0001

0 1 /dev/oracleasm/disks/ASMDISK1 DATA_0000

4. 在diskgroup mount状态，是不能使用amdu导出文件的

执行amdu命令开始导出，遇到错误

$ amdu -diskstring '/dev/oracleasm/disks/ASMDISK*' -extract data.260

amdu_2013_07_03_17_29_13/

AMDU-00204: Disk N0005 is in currently mounted diskgroup DATA

AMDU-00201: Disk N0005: '/dev/oracleasm/disks/ASMDISK1'

检查发现磁盘组mount

$ crsctl status res -t

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

NAME TARGET STATE SERVER STATE_DETAILS

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

ora.DATA.dg

ONLINE ONLINE single-db

ora.FRA.dg

ONLINE ONLINE single-db

5. 导出控制文件

$ amdu -diskstring '/dev/oracleasm/disks/ASMDISK*' -extract data.260

amdu_2013_07_03_17_46_07/

[oracle@Single-DB amdu]$ cd amdu_2013_07_03_17_46_07/

[oracle@Single-DB amdu_2013_07_03_17_46_07]$ ls

DATA_260.f report.txt

6. 尝试挂载control file

发现spfile也存放在磁盘组中无法nomount

$ sqlplus / as sysdba

SQL> startup nomount;

ORA-01078: failure in processing system parameters

ORA-01565: error in identifying file '+DATA/db/spfiledb.ora'

ORA-17503: ksfdopn:2 Failed to open file +DATA/db/spfiledb.ora

ORA-15056: additional error message

ORA-17503: ksfdopn:DGOpenFile05 Failed to open file +DATA/db/spfiledb.ora

ORA-17503: ksfdopn:2 Failed to open file +DATA/db/spfiledb.ora

ORA-15001: diskgroup "DATA" does not exist or is not mounted

ORA-06512: at line 4

7. 那就编辑一个新的pfile文件

$ cp init.ora spfilebk.ora

$ vi spfilebk.ora

~~~~~~~~~~~~~~~

db_name='DB'

sga_target=1G

processes = 150

audit_trail ='db'

db_block_size=8192

db_domain=''

db_recovery_file_dest_size=2G

open_cursors=300

remote_login_passwordfile='EXCLUSIVE'

undo_tablespace='UNDOTBS1'

control_files = /u01/amdu/amdu_2013_07_03_17_46_07/DATA_260.f

compatible ='11.2.0'

~~~~~~~~~~~~~~~

8. 通过导出的控制文件启动数据库到mount模式，成功启动，说明AMDU导出的数据时正确的，继续。。。。。

$ sqlplus / as sysdba

SQL> startup nomount pfile='/u01/app/oracle/product/11.2.0/dbhome_1/dbs/spfilebk.ora';

ORACLE instance started.

Total System Global Area 1068937216 bytes

Fixed Size 2220200 bytes

Variable Size 281022296 bytes

Database Buffers 780140544 bytes

Redo Buffers 5554176 bytes

SQL> alter database mount;

Database altered.

9. 查看数据文件的位置，然后一一导出

SQL> select name from v$datafile;

NAME

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

+DATA/db/datafile/system.256.804295135

+DATA/db/datafile/sysaux.257.804295137

+DATA/db/datafile/undotbs1.258.804295139

+DATA/db/datafile/users.259.804295141

$ amdu -diskstring '/dev/oracleasm/disks/ASMDISK*' -extract data.256 <<<<<<<<<<<<<<system

$ amdu -diskstring '/dev/oracleasm/disks/ASMDISK*' -extract data.257 <<<<<<<<<<<<<<sysaux

$ amdu -diskstring '/dev/oracleasm/disks/ASMDISK*' -extract data.258 <<<<<<<<<<<<<<undotbs1

$ amdu -diskstring '/dev/oracleasm/disks/ASMDISK*' -extract data.259 <<<<<<<<<<<<<<users .

10. 重命名数据文件，并移动到同一个目录下，准备挂载数据文件

$ mv amdu_2013_07_03_18_12_56/DATA_257.f sysaux.257.804295137

$ mv amdu_2013_07_03_18_22_23/DATA_259.f users.259.804295141

$ mv amdu_2013_07_03_18_23_06/DATA_258.f undotbs1.258.804295139

$ ll

-rw-r--r-- 1 oracle dba 545267712 Jul 3 18:14 sysaux.257.804295137

-rw-r--r-- 1 oracle dba 702554112 Jul 3 18:11 system.256.804295135

-rw-r--r-- 1 oracle dba 99622912 Jul 3 18:23 undotbs1.258.804295139

-rw-r--r-- 1 oracle dba 5251072 Jul 3 18:22 users.259.804295141

11. 挂载前需要修改pfile文件，下面是open数据库是control file如何识别不同路径的datafile，我使用convert参数来解决（也可以是用set newname的方式）

db_file_name_convert='+DATA/db/datafile','/u01/amdu/amdu_datafile'

添加完pfile，启动数据库，最终成功启动数据库

SQL> startup pfile='/u01/app/oracle/product/11.2.0/dbhome_1/dbs/spfilebk.ora';

[oracle@Single-DB ~]$ sqlplus / as sysdba

Connected to an idle instance.

SQL> startup pfile='/u01/app/oracle/product/11.2.0/dbhome_1/dbs/spfilebk.ora';

ORACLE instance started.

Total System Global Area 1068937216 bytes

Fixed Size 2220200 bytes

Variable Size 281022296 bytes

Database Buffers 780140544 bytes

Redo Buffers 5554176 bytes

Database mounted.

Database opened.

SQL> select status, instance_name from v$instance;

STATUS INSTANCE_NAME

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

OPEN db

总结，备份很重要！！

由于是在我测试库上进行的实验，我没有破坏数据文件来完全模拟客户问题。

但是通过这个测试，我们可以确认的是，在ASM diskgroup无法挂载的情况下，我们是有办法将数据文件读出（即使是坏的），然后我们在针对具体的坏块尝试block恢复（估计没有备份，这个也没辙了）。

但是至少，数据文件摆在我们面前了，我们还有其他很多办法去尝试修复，再不行，也只是丢失部分数据，因为其中可能只是个别数据文件的个别block损坏。

总之，数据文件弄出来了，剩下的，继续研究吧。

asm数据文件损坏AMDUOracle

ITPub博客

AMDU-- ASM文件转移工具

最新文章