近日遇到一个问题，就是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无法访问，需要查找备份。
|
1
2
|
SQL> show parameter control_files
+DATA/db/controlfile/current.
260.804295233
, +FRA/db/controlfile/current.
256.804295237
|
2. 通过ASM实例找到asm_diskstring
|
1
2
3
4
5
|
SQL> show parameter disk
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
asm_diskgroups string DATA, FRA
asm_diskstring string /dev/sd*
|
3. 查找asm disk的路径，后续要指定diskstring来扫描磁盘
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
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命令开始导出，遇到错误
|
1
2
3
4
|
$ 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
|
1
2
3
4
5
6
7
8
|
$ 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. 导出控制文件
|
1
2
3
4
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
|
1
2
3
4
5
6
7
8
9
10
|
$ 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文件
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
$ 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导出的数据时正确的，继续。。。。。
|
1
2
3
4
5
6
7
8
9
10
|
$ 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. 查看数据文件的位置，然后一一导出
|
1
2
3
4
5
6
7
8
9
10
11
|
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. 重命名数据文件，并移动到同一个目录下，准备挂载数据文件
|
1
2
3
4
5
6
7
8
|
$ 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，启动数据库，最终成功启动数据库
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
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损坏。
总之，数据文件弄出来了，剩下的，继续研究吧。
本文转自 hsbxxl 51CTO博客，原文链接：http://blog.51cto.com/hsbxxl/1334650，如需转载请自行联系原作者
