AMDU-- ASM文件转移工具


      近日遇到一个问题,就是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,oracke,数据文件损坏,amdu)