_allow_resetlogs_corruption和adjust_scn解决ORA-01190

Posted on 2012 年 03 月 15 日 by 惜分飞

一、模拟offline文件然后resetlogs操作

1.设置datafile 5数据文件offline
2.rman备份数据库
3.关闭原数据库，删除数据文件/当前日志和部分归档日志
4.执行不完全恢复，resetlogs打开数据库(如下面操作)
[oracle@xifenfei ora11g]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Thu Mar 15 07:36:59 2012

Copyright (c) 1982, 2011, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> recover database until cancel;
ORA-00279: change 868870 generated at 03/15/2012 03:32:11 needed for thread 1
ORA-00289: suggestion :
/u01/oracle/oradata/archivelog/ora11g/1_29_777766629.dbf
ORA-00280: change 868870 for thread 1 is in sequence #29


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
Media recovery cancelled.
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open


SQL> alter database open resetlogs;

Database altered.

SQL> select file#,online_status,to_char(change#,'999999999999') from v$recover_file;

     FILE# ONLINE_STATUS  TO_CHAR(CHANGE#,'999999999
---------- -------------- --------------------------
         5 OFFLINE               868810

SQL> alter database datafile 5 online;
alter database datafile 5 online
*
ERROR at line 1:
ORA-01190: control file or data file 5 is from before the last RESETLOGS
ORA-01110: data file 5: '/u01/oracle/oradata/ora11g/xifenfei01.dbf'


SQL> select file#,to_char(checkpoint_change#,'999999999999'),
  2  to_char(last_change#,'999999999999') from v$datafile;

     FILE# TO_CHAR(CHECKPOINT_CHANGE# TO_CHAR(LAST_CHANGE#,'9999
---------- -------------------------- --------------------------
         1        868874
         2        868874
         3        868874
         4        868874
         5        868810                     868874

--可以看到offline的数据文件，没有因为resetlogs操作而改变
--CHECKPOINT_CHANGE#和RESETLOGS_CHANGE#信息
SQL> select file#,to_char(checkpoint_change#,'999999999999'),
  2  to_char(RESETLOGS_CHANGE#,'999999999999')
  3  from v$datafile_header;

     FILE# TO_CHAR(CHECKPOINT_CHANGE# TO_CHAR(RESETLOGS_CHANGE#,
---------- -------------------------- --------------------------
         1        868874                     868871
         2        868874                     868871
         3        868874                     868871
         4        868874                     868871
         5        868810                     787897

二、隐含参数设置

SQL> create pfile='/tmp/pfile' from spfile;

File created.

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.

在pfile中增加
_allow_resetlogs_corruption=true
_allow_error_simulation=TRUE(10g及其以上版本需要)

三、打开数据库,online离线文件

SQL> startup pfile='/tmp/pfile' mount;
ORACLE instance started.

Total System Global Area  368263168 bytes
Fixed Size                  1345016 bytes
Variable Size             293603848 bytes
Database Buffers           67108864 bytes
Redo Buffers                6205440 bytes
Database mounted.
--在mount状态下执行
SQL> alter session set events '10015 trace name adjust_scn level 2';

Session altered.

SQL> recover database until cancel;
ORA-00279: change 868810 generated at 03/13/2012 22:19:37 needed for thread 1
ORA-00289: suggestion :
/u01/oracle/oradata/archivelog/ora11g/1_27_777766629.dbf
ORA-00280: change 868810 for thread 1 is in sequence #27


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01190: control file or data file 1 is from before the last RESETLOGS
ORA-01110: data file 1: '/u01/oracle/oradata/ora11g/system01.dbf'


ORA-01112: media recovery not started


--[一定要]在mount状态下执行online操作
SQL> alter database datafile 5 online;

Database altered.

SQL> alter database open resetlogs;

Database altered.

SQL> select file#,online_status,to_char(change#,'999999999999') from v$recover_file;

no rows selected

姊妹篇:bbed解决ORA-01190

bbed解决ORA-01190

Posted on 2012 年 03 月 15 日 by 惜分飞

当我们使用resetlogs方式打开数据库后，发现有数据文件处于offline状态，这个时候很可能就是悲剧降临的时候，很有可能这个文件文件在resetlogs之前就处于offline状态，然后你resetlogs之后，这个文件使用常规方法很难再online，会出现ORA-01190或者ORA-01189之类的错误。
一、模拟offline文件然后resetlogs操作

1.设置datafile 5数据文件offline
2.rman备份数据库
3.关闭原数据库，删除数据文件/当前日志和部分归档日志
4.执行不完全恢复，resetlogs打开数据库(如下面操作)
[oracle@xifenfei ora11g]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Thu Mar 15 07:36:59 2012

Copyright (c) 1982, 2011, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> recover database until cancel;
ORA-00279: change 868870 generated at 03/15/2012 03:32:11 needed for thread 1
ORA-00289: suggestion :
/u01/oracle/oradata/archivelog/ora11g/1_29_777766629.dbf
ORA-00280: change 868870 for thread 1 is in sequence #29


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
Media recovery cancelled.
SQL> alter database open resetlogs;

Database altered.

SQL> select file#,online_status,to_char(change#,'999999999999') from v$recover_file;

     FILE# ONLINE_STATUS  TO_CHAR(CHANGE#,'999999999
---------- -------------- --------------------------
         5 OFFLINE               868810

SQL> alter database datafile 5 online;
alter database datafile 5 online
*
ERROR at line 1:
ORA-01190: control file or data file 5 is from before the last RESETLOGS
ORA-01110: data file 5: '/u01/oracle/oradata/ora11g/xifenfei01.dbf'


SQL> select file#,to_char(checkpoint_change#,'999999999999'),
  2  to_char(last_change#,'999999999999') from v$datafile;

     FILE# TO_CHAR(CHECKPOINT_CHANGE# TO_CHAR(LAST_CHANGE#,'9999
---------- -------------------------- --------------------------
         1        868874
         2        868874
         3        868874
         4        868874
         5        868810                     868874

--可以看到offline的数据文件，没有因为resetlogs操作而改变
--CHECKPOINT_CHANGE#和RESETLOGS_CHANGE#信息
SQL> select file#,to_char(checkpoint_change#,'999999999999'),
  2  to_char(RESETLOGS_CHANGE#,'999999999999')
  3  from v$datafile_header;

     FILE# TO_CHAR(CHECKPOINT_CHANGE# TO_CHAR(RESETLOGS_CHANGE#,
---------- -------------------------- --------------------------
         1        868874                     868871
         2        868874                     868871
         3        868874                     868871
         4        868874                     868871
         5        868810                     787897

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.

二、bbed修改相关项

下面两项与resetlogs相关
kcvfhrlc表示 reset logs count
kcvfhrls表示 resetlogs scn
下面四项与数据库文件scn相关
kscnbas (at offset 140) – SCN of last change to the datafile.
kcvcptim (at offset 148) - Time of the last change to the datafile.
kcvfhcpc (at offset 176) – Checkpoint count.
kcvfhccc (at offset 184) – Unknown, but is always 1 less than thecheckpoint point count.


BBED> set filename '/u01/oracle/oradata/ora11g/system01.dbf'
        FILENAME        /u01/oracle/oradata/ora11g/system01.dbf

BBED> p kcvfhrlc
ub4 kcvfhrlc                                @112      0x2e5eed37

BBED> p kcvfhrls
struct kcvfhrls, 8 bytes                    @116     
   ub4 kscnbas                              @116      0x000d4207
   ub2 kscnwrp                              @120      0x0000

       

BBED>  p kcvcpscn
struct kcvcpscn, 8 bytes                 @484 
   ub4 kscnbas                           @484      0x000d4495
   ub2 kscnwrp                           @488      0x0000
   
BBED> p kcvfhcpc
ub4 kcvfhcpc                                @140      0x00000078

BBED> p kcvfhccc
ub4 kcvfhccc                                @148      0x00000077

BBED> set filename '/u01/oracle/oradata/ora11g/xifenfei01.dbf'
        FILENAME        /u01/oracle/oradata/ora11g/xifenfei01.dbf

BBED> p kcvfhrlc
ub4 kcvfhrlc                                @112      0x2e5bc6e5

BBED> set mode edit
        MODE            Edit

BBED> m /x 37ed5e2e
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y

BBED> p kcvfhrlc
ub4 kcvfhrlc                                @112      0x2e5eed37

BBED> p kcvfhrls
struct kcvfhrls, 8 bytes                    @116     
   ub4 kscnbas                              @116      0x000c05b9
   ub2 kscnwrp                              @120      0x0000

BBED> m /x 07420d00

BBED> p kcvfhrls
struct kcvfhrls, 8 bytes                    @116     
   ub4 kscnbas                              @116      0x000d4207
   ub2 kscnwrp                              @120      0x0000

BBED>  p kcvcpscn
struct kcvcpscn, 8 bytes                 @484 
   ub4 kscnbas                           @484      0x000d41ca
   ub2 kscnwrp                           @488      0x0000
 
BBED> set offset 484
        OFFSET          484

BBED> m /x 95440d00
BBED-00209: invalid number (95440d00)

BBED> m /x 9544

BBED> set offset +2
        OFFSET          486

BBED> m /x 0d00

BBED> p kcvfhcpc
ub4 kcvfhcpc                                @140      0x00000003

BBED> m /x 78000000

BBED> p kcvfhcpc
ub4 kcvfhcpc                                @140      0x00000078

BBED> p kcvfhccc
ub4 kcvfhccc                                @148      0x00000002

BBED> m /x 77000000

BBED> p kcvfhccc
ub4 kcvfhccc                                @148      0x00000077

BBED> sum
Check value for File 0, Block 1:
current = 0xe079, required = 0x5940

BBED> sum apply
Check value for File 0, Block 1:
current = 0x5940, required = 0x5940
1

三、数据文件online

[oracle@xifenfei ora11g]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Thu Mar 15 07:48:48 2012

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> startup
ORACLE instance started.

Total System Global Area  368263168 bytes
Fixed Size                  1345016 bytes
Variable Size             301992456 bytes
Database Buffers           58720256 bytes
Redo Buffers                6205440 bytes
Database mounted.
Database opened.
SQL> select file#,to_char(checkpoint_change#,'999999999999'),
  2  to_char(RESETLOGS_CHANGE#,'999999999999')
  3  from v$datafile_header;

     FILE# TO_CHAR(CHECKPOINT_CHANGE# TO_CHAR(RESETLOGS_CHANGE#,
---------- -------------------------- --------------------------
         1        869528                     868871
         2        869528                     868871
         3        869528                     868871
         4        869528                     868871
         5        869525                     868871

SQL> recover datafile 5;
Media recovery complete.
SQL> alter database datafile 5 online;

Database altered.

姊妹篇:_allow_resetlogs_corruption和adjust_scn解决ORA-01190

rman 备份出现ORA-00245/RMAN-08132

Posted on 2012 年 03 月 13 日 by 惜分飞

rman备份出现如下错误

RMAN> backup full  tag 'dbfull' format '/jfkdata1/rman_bak/full_%d_%u' database 
 2>   include current controlfile  plus archivelog  format '/jfkdata1/rman_bak/arch_%d_%u'; 


Starting backup at 13-MAR-12
current log archived
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=297 instance=ykcdb2 device type=DISK
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set

input archived log thread=1 sequence=29 RECID=43 STAMP=777808820
input archived log thread=1 sequence=30 RECID=46 STAMP=777816035
input archived log thread=2 sequence=21 RECID=45 STAMP=777816033
channel ORA_DISK_1: starting piece 1 at 13-MAR-12
channel ORA_DISK_1: finished piece 1 at 13-MAR-12
piece handle=/jfkdata1/rman_bak/arch_YKCDB_01n5p1vf tag=DBFULL comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:25
Finished backup at 13-MAR-12

Starting backup at 13-MAR-12
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00002 name=/jfkdata1/oradata/ykcdb/sysaux01.dbf
input datafile file number=00001 name=/jfkdata1/oradata/ykcdb/system01.dbf
input datafile file number=00003 name=/jfkdata1/oradata/ykcdb/undotbs01.dbf
input datafile file number=00005 name=/jfkdata1/oradata/ykcdb/undotbs02.dbf
input datafile file number=00004 name=/jfkdata1/oradata/ykcdb/users01.dbf
channel ORA_DISK_1: starting piece 1 at 13-MAR-12
channel ORA_DISK_1: finished piece 1 at 13-MAR-12
piece handle=/jfkdata1/rman_bak/full_YKCDB_02n5p209 tag=DBFULL comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:25
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 13-MAR-12
channel ORA_DISK_1: finished piece 1 at 13-MAR-12
piece handle=/jfkdata1/rman_bak/full_YKCDB_03n5p213 tag=DBFULL comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 13-MAR-12

Starting backup at 13-MAR-12
current log archived
using channel ORA_DISK_1
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=2 sequence=22 RECID=48 STAMP=777816102
input archived log thread=1 sequence=31 RECID=47 STAMP=777816101
channel ORA_DISK_1: starting piece 1 at 13-MAR-12
channel ORA_DISK_1: finished piece 1 at 13-MAR-12
piece handle=/jfkdata1/rman_bak/arch_YKCDB_04n5p217 tag=DBFULL comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 13-MAR-12
ORA-00245: control file backup operation failed

RMAN-08132: WARNING: cannot update recovery area reclaimable file list

RMAN>

从这里可以看出数据库文件，归档日志，spfile和controlfile都备份完成，后面又出现一个controlfile失败，应该是控制文件快照备份失败。

错误原因

RMAN creates a copy of the control file for read consistency, this is the snapshot controlfile. 
Due to the changes made to the controlfile backup mechanism in 11gR2 any instances 
in the cluster may write to the snapshot controlfile. Therefore, 
the snapshot controlfile file needs to be visible to all instances.

The same happens when a backup of the controlfile is created directly from 
sqlplus any instance in the cluster may write to the backup controfile file.

In 11gR2 onwards, the controlfile backup happens without holding the control file enqueue. 
For non-RAC database, this doesn't change anything. 

But, for RAC database, the snapshot controlfile location 
must be in a shared file system that will be accessible from all the nodes.

The snapshot controlfile MUST be  accessible by all nodes of a RAC database.

大致意思就是rman的snapshot controlfile必须放在共享存储之上。

解决方法

The snapshot controlfile MUST be accessible by all nodes of a RAC database, 
if the snapshot controlfile does not reside in on a shared device this error will raise.

1. Check the snapshot controlfile location:
RMAN> show all;

2. Configure the snapshot controlfile to a shared disk:
RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '<shared_disk>/snapcf_<DBNAME>.f';

使用_allow_resetlogs_corruption打开无归档日志rman备份库

Posted on 2012 年 03 月 08 日 by 惜分飞

rman还原恢复操作

--还原数据库
RMAN> restore database;
--恢复数据库
RMAN> recover database;

Starting recover at 2012-03-08 21:20:45
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=65 device type=DISK

starting media recovery

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 03/08/2012 21:20:47
RMAN-06053: unable to perform media recovery because of missing log
RMAN-06025: no backup of archived log for thread 1 with sequence 2936 and starting SCN of 25991695 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 2935 and starting SCN of 25991652 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 2934 and starting SCN of 25991649 found to restore
……………………
RMAN-06025: no backup of archived log for thread 1 with sequence 2902 and starting SCN of 25991156 found to restore
这里报日志缺少，实际上是备份的数据库文件后，没有备份归档日志，归档日志全部丢失

进行不完全恢复

SQL> recover database until cancel;
ORA-00279: change 25991194 generated at 03/08/2012 20:33:58 needed for thread 1
ORA-00289: suggestion : /opt/oracle/oradata/archivelog/chf/1_2902_752334071.dbf
ORA-00280: change 25991194 for thread 1 is in sequence #2902


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/opt/oracle/oradata/chf/system01.dbf'


ORA-01112: media recovery not started


SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/opt/oracle/oradata/chf/system01.dbf'

查看相关SCN

SQL> select file#,to_char(checkpoint_change#,'999999999999') from v$datafile;

     FILE# TO_CHAR(CHECK
---------- -------------
         1      25992214
         2      25992214
         3      25992214
         4      25992214
         5      25992214
         6      25992214
         7      25992214
         8      25992214
         9      25992214
        10      25992214
        11      25992214

     FILE# TO_CHAR(CHECK
---------- -------------
        13      25992214
        14      25992214

13 rows selected.

SQL> select file#,online_status,to_char(change#,'999999999999') from v$recover_file;

     FILE# ONLINE_ TO_CHAR(CHANG
---------- ------- -------------
         1 ONLINE       25991194
         2 ONLINE       25991194
         3 ONLINE       25991194
         4 ONLINE       25991194
         5 ONLINE       25991194
         6 ONLINE       25991194
         7 ONLINE       25991194
         8 ONLINE       25991194
         9 ONLINE       25991194
        10 ONLINE       25991194
        11 ONLINE       25991194

     FILE# ONLINE_ TO_CHAR(CHANG
---------- ------- -------------
        13 ONLINE       25991194
        14 ONLINE       25991194

13 rows selected.

SQL> select file#,to_char(checkpoint_change#,'999999999999') from v$datafile_header;

     FILE# TO_CHAR(CHECK
---------- -------------
         1      25991194
         2      25991194
         3      25991194
         4      25991194
         5      25991194
         6      25991194
         7      25991194
         8      25991194
         9      25991194
        10      25991194
        11      25991194

     FILE# TO_CHAR(CHECK
---------- -------------
        13      25991194
        14      25991194

13 rows selected.

--发现数据文件scn和控制文件不一致，重建控制文件，然后查询相关scn
SQL> select file#,to_char(checkpoint_change#,'999999999999') from v$datafile;

     FILE# TO_CHAR(CHECK
---------- -------------
         1      25991194
         2      25991194
         3      25991194
         4      25991194
         5      25991194
         6      25991194
         7      25991194
         8      25991194
         9      25991194
        10      25991194
        11      25991194

     FILE# TO_CHAR(CHECK
---------- -------------
        13      25991194
        14      25991194

13 rows selected.

SQL> select file#,online_status,to_char(change#,'999999999999') from v$recover_file;

     FILE# ONLINE_ TO_CHAR(CHANG
---------- ------- -------------
         1 ONLINE       25991194
         2 ONLINE       25991194
         3 ONLINE       25991194
         4 ONLINE       25991194
         5 ONLINE       25991194
         6 ONLINE       25991194
         7 ONLINE       25991194
         8 ONLINE       25991194
         9 ONLINE       25991194
        10 ONLINE       25991194
        11 ONLINE       25991194

     FILE# ONLINE_ TO_CHAR(CHANG
---------- ------- -------------
        13 ONLINE       25991194
        14 ONLINE       25991194

13 rows selected.

SQL> select file#,to_char(checkpoint_change#,'999999999999') from v$datafile_header;

     FILE# TO_CHAR(CHECK
---------- -------------
         1      25991194
         2      25991194
         3      25991194
         4      25991194
         5      25991194
         6      25991194
         7      25991194
         8      25991194
         9      25991194
        10      25991194
        11      25991194

     FILE# TO_CHAR(CHECK
---------- -------------
        13      25991194
        14      25991194

13 rows selected.
--此时所有scn均一致

尝试打开数据库

SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/opt/oracle/oradata/chf/system01.dbf'


SQL> recover database using backup controlfile until cancel;
ORA-00279: change 25991194 generated at 03/08/2012 20:33:58 needed for thread 1
ORA-00289: suggestion : /opt/oracle/oradata/archivelog/chf/1_2902_752334071.dbf
ORA-00280: change 25991194 for thread 1 is in sequence #2902


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/opt/oracle/oradata/chf/system01.dbf'


ORA-01112: media recovery not started

SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/opt/oracle/oradata/chf/system01.dbf'

使用隐含参数打开数据库

SQL> create pfile='/tmp/pfile' from spfile;

File created.

-------/tmp/pfile中加上----------
_allow_resetlogs_corruption= TRUE
---------------------------------

SQL> startup mount pfile='/tmp/pfile' force
ORACLE instance started.

Total System Global Area  622149632 bytes
Fixed Size                  2230912 bytes
Variable Size             419431808 bytes
Database Buffers          192937984 bytes
Redo Buffers                7548928 bytes
Database mounted.
SQL> alter database open resetlogs;

Database altered.

SQL> select open_mode from v$database;

OPEN_MODE
--------------------
READ WRITE

总结
这次的试验没有多少实际意义，但是可以说明几个问题：
1.所有的数据文件的scn都一致，甚至和控制文件的也一致，数据库不一定可以open成功
(怀疑是数据文件中的scn大于data header scn)
2.对于这样的问题，如果使用bbed修改所有数据文件header的scn不知道是否可以解决
3.如果rman只备份了数据文件而没有任何一个归档日志，数据库通过隐含参数还是可以open，抢救数据

找回ASM中数据文件

Posted on 2012 年 03 月 08 日 by 惜分飞

很多时候由于asm不能正常启动，导致数据丢失。下面提供两种方法找回asm中的数据文件
一.使用AMDU工具
AMDU是Oracle 11g里自带的一个免费的工具，用于分析ASM磁盘组的元数据以及从不能mount的磁盘组中往外抽取数据文件“NOTE:553639.1 Placeholder for AMDU binaries and using with ASM 10g”明确指出：AMDU也可用于10g，并提供了可用于10g的AMDU的各个操作系统的版本供大家下载。
1.设置LD_LIBRARY_PATH

rac1-> export LD_LIBRARY_PATH=/tmp/amdu

2.查看asm磁盘信息

rac1-> ./amdu -diskstring '/dev/raw/raw*'  
amdu_2012_03_05_03_17_19/
rac1-> cd amdu_2012_03_05_03_17_19/
rac1-> ls
report.txt
rac1-> more report.txt 
-*-amdu-*-

******************************* AMDU Settings ********************************
ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1
System name:    Linux
Node name:      rac1
Release:        2.6.9-89.0.0.0.1.ELhugemem
Version:        #1 SMP Tue May 19 04:38:38 EDT 2009
Machine:        i686
amdu run:       05-MAR-12 03:17:19
Endianess:      1

--------------------------------- Operations ---------------------------------

------------------------------- Disk Selection -------------------------------
 -diskstring '/dev/raw/raw*'

------------------------------ Reading Control -------------------------------

------------------------------- Output Control -------------------------------

********************************* DISCOVERY **********************************

----------------------------- DISK REPORT N0001 ------------------------------
                Disk Path: /dev/raw/raw23
           Unique Disk ID: 
               Disk Label: 
     Physical Sector Size: 512 bytes
                Disk Size: 156 megabytes
** NOT A VALID ASM DISK HEADER. BAD VALUE IN FIELD blksize_kfdhdb **

----------------------------- DISK REPORT N0002 ------------------------------
                Disk Path: /dev/raw/raw11
           Unique Disk ID: 
               Disk Label: 
     Physical Sector Size: 512 bytes
                Disk Size: 156 megabytes
** NOT A VALID ASM DISK HEADER. BAD VALUE IN FIELD blksize_kfdhdb **

----------------------------- DISK REPORT N0003 ------------------------------
                Disk Path: /dev/raw/raw32
           Unique Disk ID: 
               Disk Label: 
     Physical Sector Size: 512 bytes
                Disk Size: 156 megabytes
** NOT A VALID ASM DISK HEADER. BAD VALUE IN FIELD blksize_kfdhdb **

----------------------------- DISK REPORT N0004 ------------------------------
                Disk Path: /dev/raw/raw31
           Unique Disk ID: 
               Disk Label: 
     Physical Sector Size: 512 bytes
                Disk Size: 156 megabytes
** NOT A VALID ASM DISK HEADER. BAD VALUE IN FIELD blksize_kfdhdb **

----------------------------- DISK REPORT N0005 ------------------------------
                Disk Path: /dev/raw/raw12
           Unique Disk ID: 
               Disk Label: 
     Physical Sector Size: 512 bytes
                Disk Size: 156 megabytes
** NOT A VALID ASM DISK HEADER. BAD VALUE IN FIELD blksize_kfdhdb **

----------------------------- DISK REPORT N0006 ------------------------------
                Disk Path: /dev/raw/raw2
           Unique Disk ID: 
               Disk Label: 
     Physical Sector Size: 512 bytes
                Disk Size: 1976 megabytes
               Group Name: DATA
                Disk Name: DATA_0001
       Failure Group Name: DATA_0001
              Disk Number: 1
            Header Status: 3
       Disk Creation Time: 2012/03/01 22:32:39.289000
          Last Mount Time: 2012/03/05 02:10:02.771000
    Compatibility Version: 0x0a100000
         Disk Sector Size: 512 bytes
         Disk size in AUs: 1976 AUs
         Group Redundancy: 1
      Metadata Block Size: 4096 bytes
                  AU Size: 1048576 bytes
                   Stride: 113792 AUs
      Group Creation Time: 2012/03/01 22:32:39.221000
  File 1 Block 1 location: AU 0

----------------------------- DISK REPORT N0007 ------------------------------
                Disk Path: /dev/raw/raw1
           Unique Disk ID: 
               Disk Label: 
     Physical Sector Size: 512 bytes
                Disk Size: 3137 megabytes
               Group Name: DATA
                Disk Name: DATA_0000
       Failure Group Name: DATA_0000
              Disk Number: 0
            Header Status: 3
       Disk Creation Time: 2012/03/01 22:32:39.289000
          Last Mount Time: 2012/03/05 02:10:02.771000
    Compatibility Version: 0x0a100000
         Disk Sector Size: 512 bytes
         Disk size in AUs: 3137 AUs
         Group Redundancy: 1
      Metadata Block Size: 4096 bytes
                  AU Size: 1048576 bytes
                   Stride: 113792 AUs
      Group Creation Time: 2012/03/01 22:32:39.221000
  File 1 Block 1 location: AU 2

******************************* END OF REPORT ********************************

从这里可以得到信息如下：
1)只有/dev/raw/raw1和raw2是有效的asm磁盘
2)磁盘组只有DATA

3.找出数据文件信息

rac1-> ../amdu -diskstring '/dev/raw/raw*'  -dump 'DATA'
amdu_2012_03_05_03_19_38/
rac1-> cd amdu_2012_03_05_03_19_38/
rac1-> ls
DATA_0001.img  DATA.map  report.txt
rac1-> strings DATA_0001.img |grep DATAFILE
DATAFILE
DATAFILE
DATAFILE
DEVDB/DATAFILE/SYSTEM.256.776817753
DEVDB/DATAFILE/SYSAUX.257.776817753
DEVDB/DATAFILE/UNDOTBS1.258.776817753
DEVDB/DATAFILE/USERS.259.776817753
DEVDB/DATAFILE/UNDOTBS2.267.776817909

从这里可以得出数据文件的file号(第一位数字)

4.恢复数据文件

rac1-> ../../amdu -diskstring '/dev/raw/raw*' -extract 'DATA.259'
amdu_2012_03_05_03_27_21/
rac1-> cd amdu_2012_03_05_03_27_21/
rac1-> ls -l
total 5148
-rw-r--r--  1 oracle oinstall 5251072 Mar  5 03:27 DATA_259.f
-rw-r--r--  1 oracle oinstall    6468 Mar  5 03:27 report.txt
rac1-> dbv file=DATA_259.f

DBVERIFY: Release 10.2.0.1.0 - Production on Mon Mar 5 03:28:00 2012

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

DBVERIFY - Verification starting : FILE = DATA_259.f


DBVERIFY - Verification complete

Total Pages Examined         : 640
Total Pages Processed (Data) : 15
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 2
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 26
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 597
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Highest block SCN            : 442362 (0.442362)

二.使用aulasm工具
1.配置ASM使用磁盘

[root@rac1 oracle]# more disk
/dev/sdb1
/dev/sdb2

2.使用aulasm

[root@rac1 oracle]# ./aulasm_linux32_trial.bin 
AUL : AnySQL UnLoader(MyDUL) for Oracle ASM, release 2.0.0

(C) Copyright Lou Fangxin 2011-2012 (AnySQL.net), all rights reserved.

ASM> help
  SET        -- set options (BLOCK_SIZE, AU_SIZE, F1B1_DISK, F1B1_AU)
  OPEN       -- open data file
  ADD        -- add disk with customized disk num (disk, path)
  LIST       -- list opened disks information (to)
  LSAU       -- list file of given AU (disk, au, count)
  FILE       -- list all file entries in ASM (file, [disk, au, block]).
  ALIAS      -- list all alias entries in ASM (file, [disk, au, block]).
  EXTENT     -- list or adjust variable extent (level, au, count).
  FMAP       -- list file extent (file, [disk, au, block], to)
  DUMP       -- dump file extent (file, [disk, au, block], offset, to)
  COPY       -- copy file to os  (file, [disk, au, block], to)
  QUIT/EXIT  -- exit the program.
ASM> open disk
2012-03-05 03:32:48
2012-03-05 03:32:48
ASM> list
2012-03-05 03:32:49
Total Disks = 2, ausize=1048576, blksize=4096

 disk     size block disk name        disk group   disk path               
===== ======== ===== ================ ============ ========================
    0     3137  4096 DATA_0000        DATA         /dev/sdb1
    1     1976  4096 DATA_0001        DATA         /dev/sdb2

f1b1disk = 0, f1b1au = 2, score=256, compat=0x0a100000
file=(1,0,2,1), disk=(2,0,2,2), alias=(6,0,2,6)
2012-03-05 03:32:49
ASM> alias
2012-03-05 03:33:15
    file          inc parent fstblk flag  refer alias                     
======== ============ ====== ====== ==== ====== ==========================
      -1           -1      0      0    4      1 DEVDB
      -1           -1      0      1    4      2 DATAFILE
      -1           -1      0      1    4      3 CONTROLFILE
      -1           -1      0      1    4      4 ONLINELOG
      -1           -1      0      1    4      5 TEMPFILE
      -1           -1      0      1    4      6 PARAMETERFILE
      -1           -1      0      1    4      7 ARCHIVELOG
     256    776817753      1      2   18     -1 SYSTEM
     257    776817753      1      2   18     -1 SYSAUX
     258    776817753      1      2   18     -1 UNDOTBS1
     259    776817753      1      2   18     -1 USERS
     267    776817909      1      2   18     -1 UNDOTBS2
     261    776817829      1      3   18     -1 Current
     260    776817829      1      3   18     -1 Current
     262    776817833      1      4   18     -1 group_1
     263    776817835      1      4   18     -1 group_1
     264    776817837      1      4   18     -1 group_2
     265    776817841      1      4   18     -1 group_2
     268    776818011      1      4   18     -1 group_3
     269    776818013      1      4   18     -1 group_3
     270    776818015      1      4   18     -1 group_4
     271    776818017      1      4   18     -1 group_4
     266    776817859      1      5   18     -1 TEMP
     272    776818021      1      6   18     -1 spfile
      -1           -1      1      7    4      8 2012_03_01
      -1           -1      1      7    4      9 2012_03_03
      -1           -1      1      7    4     10 2012_03_05
     273    776818747      7      8   18     -1 thread_1_seq_2
     274    776819571      7      8   18     -1 thread_1_seq_3
     275    776819721      7      8   18     -1 thread_2_seq_1
     276    776820331      7      8   18     -1 thread_1_seq_4
     277    776992321      7      9   18     -1 thread_1_seq_5
     278    776992321      7      9   18     -1 thread_2_seq_2
     279    777089437      7     10   18     -1 thread_1_seq_6
2012-03-05 03:33:15
ASM> fmap file 259    
2012-03-05 03:34:49
fid=259, disk=0, au=56, block=3
siz=5, ecnt=6, eeof=6, flags=17, type=12, alias=109,-1
     extid  disk       auid  cnt flg chk
========== ===== ========== ==== === ===
         1     0        428    1   0 135
         2     1        408    1   0 178
         3     0        429    1   0 134
         4     1        409    1   0 179
         5     0        430    1   0 133
         6     1        410    1   0 176
2012-03-05 03:34:49
ASM> copy file 259 to user_259
2012-03-05 03:35:01
2012-03-05 03:35:01
[root@rac1 oracle]# ll
total 6252
-rwxr-xr-x  1 root   root       84619 Mar  6  2012 aulasm_linux32_trial.bin
-rw-r--r--  1 root   root          20 Mar  5 02:52 disk
-rw-r--r--  1 root   root     6291456 Mar  5 03:35 user_259
[root@rac1 oracle]# su - oracle
rac1-> dbv file=user_259 

DBVERIFY: Release 10.2.0.1.0 - Production on Mon Mar 5 03:35:27 2012

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

DBVERIFY - Verification starting : FILE = user_259


DBVERIFY - Verification complete

Total Pages Examined         : 640
Total Pages Processed (Data) : 15
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 2
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 26
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 597
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Highest block SCN            : 442362 (0.442362)

通过dbv验证，两个数据文件(文件大小有出入，可能在对待未格式化数据块上，两者处理有出入)可以基本上确定一致，证明两种方法都可以从异常的ASM中获取数据文件

三.总结与比较
1.AMDU完全免费，aulasm超过16块硬盘需要收费
2.AMDU操作相对于aulasm麻烦一点，但是整体还是可以接受
3.获取到asm中的数据文件后恢复数据内容或者open库，那都是容易的事情
如果因为磁盘头损坏太多或者其他原因,以上方法都不能实现抽取asm磁盘组中数据文件,参考:asm disk header 彻底损坏恢复