ORACLE 11g ASM文件系统OMF模式DATA GUARD搭建注意事项
Sep182012
最近为客户的一个20TB数据库搭建DATA GUARD，环境是OEL 5.7 X86_64，ORACLE 11.2.0.2.0 for LINUX X86_64，数据文件存在ASM文件系统，并且开启OMF自动管理数据文件，在搭建时遇到很多问题，本文摘取RMAN恢复数据文件时数据文件名发生变化部分，以下是RMAN恢复数据文件时，RMAN窗口的日志信息，此时RMAN日志显示的数据文件名称是正确的。
[oracle@dbserver1 ~]$ rman target / Recovery Manager: Release 11.2.0.2.0 - Production on Wed Sep 12 19:01:24 2012 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. connected to target database: FHACDB (DBID=51367985, not open) RMAN> restore database; Starting restore at 12-SEP-12 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=62 device type=DISK channel ORA_DISK_1: starting datafile backup set restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set channel ORA_DISK_1: restoring datafile 00001 to +DATA/fhacdb/datafile/system.261.784217547 channel ORA_DISK_1: restoring datafile 00002 to +DATA/fhacdb/datafile/sysaux.262.784217553 channel ORA_DISK_1: restoring datafile 00003 to +DATA/fhacdb/datafile/undotbs1.263.784217557 channel ORA_DISK_1: restoring datafile 00004 to +DATA/fhacdb/datafile/users.265.784217587 ... ... channel ORA_DISK_1: restoring datafile 00023 to +DATA/fhacdb/datafile/xingzhen01.dbf channel ORA_DISK_1: reading from backup piece /mnt/full_7inkinbq_1_1_20120907 channel ORA_DISK_1: piece handle=/mnt/full_7inkinbq_1_1_20120907 tag=TAG20120907T032649 channel ORA_DISK_1: restored backup piece 1 ... ... channel ORA_DISK_1: reading from backup piece /mnt/full_7inkinbq_15_1_20120908 channel ORA_DISK_1: piece handle=/mnt/full_7inkinbq_15_1_20120908 tag=TAG20120907T032649 channel ORA_DISK_1: restored backup piece 15 channel ORA_DISK_1: restore complete, elapsed time: 43:55:42 Finished restore at 14-SEP-12
下面是告警日志中相关内容，此时OMF管理的数据文件名称已经改变。
Fri Sep 14 11:27:39 2012 Full restore complete of datafile 3 +DATA/fhacdb/datafile/undotbs1.275.793970675. Elapsed time: 0:03:04 checkpoint is 1605330379 last deallocation scn is 1605606714 ... ... Fri Sep 14 11:58:03 2012 Full restore complete of datafile 1 +DATA/fhacdb/datafile/system.261.793971825. Elapsed time: 0:14:18 checkpoint is 1605330379 last deallocation scn is 1561445122 Full restore complete of datafile 4 +DATA/fhacdb/datafile/users.259.793972671. Elapsed time: 0:00:12 checkpoint is 1605330379 last deallocation scn is 1555118324 Full restore complete of datafile 2 +DATA/fhacdb/datafile/sysaux.262.793971781. Elapsed time: 0:15:08 checkpoint is 1605330379 last deallocation scn is 1605564949
控制文件中记录的数据文件名如下：
SQL> select file#,name from v$datafile where name not like '%dbf';
FILE# NAME
---------- ------------------------------------------------------------
1 +DATA/fhacdb/datafile/system.261.784217547
2 +DATA/fhacdb/datafile/sysaux.262.784217553
3 +DATA/fhacdb/datafile/undotbs1.263.784217557
4 +DATA/fhacdb/datafile/users.265.784217587
此时ASMCMD命令行下看到的就是新的数据文件名，而且不能用CP命令拷贝文件到原来的名字。
[grid@dbserver1 ~]$ asmcmd ASMCMD> cd data/fhacdb/datafile ASMCMD> ls APPLICATION.271.793971383 application01.dbf ARRANGEMENTS.273.793971089 arrangements01.dbf AUTHSYSTEM.270.793971555 authsystem01.dbf CES.267.793971613 ces01.dbf COMPOSE.269.793971571 compose01.dbf DIGITAL.272.793971311 digital01.dbf EARLY_DATA.276.793969683 early_data01.dbf HANLONG.258.793971707 hanlong01.dbf HANWANG.268.793971673 hanwang01.dbf RESOURCEDB.274.793970859 resourcedb01.dbf SYSAUX.262.793971781 SYSTEM.261.793971825 UNDOTBS1.275.793970675 USERS.259.793972671 XINGZHEN.263.793971741 xingzhen01.dbf
通过LS -L命令可以看到，除了这4个建库时自动生成的数据文件，其他手动建立的数据文件由于手动指定了以.DBF结尾的文件名，而.DBF结尾的文件名其实是以数字结尾的文件的别名，相当于LINUX的软链接。
ASMCMD> ls -l
Type Redund Striped Time Sys Name
DATAFILE UNPROT COARSE SEP 17 18:00:00 Y APPLICATION.271.793971383
DATAFILE UNPROT COARSE SEP 17 18:00:00 Y ARRANGEMENTS.273.793971089
DATAFILE UNPROT COARSE SEP 17 18:00:00 Y AUTHSYSTEM.270.793971555
DATAFILE UNPROT COARSE SEP 17 18:00:00 Y CES.267.793971613
DATAFILE UNPROT COARSE SEP 17 18:00:00 Y COMPOSE.269.793971571
DATAFILE UNPROT COARSE SEP 17 18:00:00 Y DIGITAL.272.793971311
DATAFILE UNPROT COARSE SEP 17 18:00:00 Y EARLY_DATA.276.793969683
DATAFILE UNPROT COARSE SEP 17 18:00:00 Y HANLONG.258.793971707
DATAFILE UNPROT COARSE SEP 17 18:00:00 Y HANWANG.268.793971673
DATAFILE UNPROT COARSE SEP 17 18:00:00 Y RESOURCEDB.274.793970859
DATAFILE UNPROT COARSE SEP 17 18:00:00 Y SYSAUX.262.793971781
DATAFILE UNPROT COARSE SEP 17 18:00:00 Y SYSTEM.261.793971825
DATAFILE UNPROT COARSE SEP 17 18:00:00 Y UNDOTBS1.275.793970675
DATAFILE UNPROT COARSE SEP 17 18:00:00 Y USERS.259.793972671
DATAFILE UNPROT COARSE SEP 17 18:00:00 Y XINGZHEN.263.793971741
N application01.dbf => +DATA/FHACDB/DATAFILE/APPLICATION.271.793971383
N arrangements01.dbf => +DATA/FHACDB/DATAFILE/ARRANGEMENTS.273.793971089
N authsystem01.dbf => +DATA/FHACDB/DATAFILE/AUTHSYSTEM.270.793971555
N ces01.dbf => +DATA/FHACDB/DATAFILE/CES.267.793971613
N compose01.dbf => +DATA/FHACDB/DATAFILE/COMPOSE.269.793971571
N digital01.dbf => +DATA/FHACDB/DATAFILE/DIGITAL.272.793971311
N early_data01.dbf => +DATA/FHACDB/DATAFILE/EARLY_DATA.276.793969683
N hanlong01.dbf => +DATA/FHACDB/DATAFILE/HANLONG.258.793971707
N hanwang01.dbf => +DATA/FHACDB/DATAFILE/HANWANG.268.793971673
N resourcedb01.dbf => +DATA/FHACDB/DATAFILE/RESOURCEDB.274.793970859
N xingzhen01.dbf => +DATA/FHACDB/DATAFILE/XINGZHEN.263.793971741
解决方法就是将这4个数据文件分别建立别名，然后修改控制文件中这4个文件的路径就可以了，但是不能将这4个文件直接建立控制文件中记录的名字，这一点就有点恶心啦。
ASMCMD> mkalias SYSTEM.261.793971825 SYSTEM.261.784217547 ORA-15032: not all alterations performed ORA-15177: cannot operate on system aliases (DBD ERROR: OCIStmtExecute)
可以将这4个文件的别名起成.dbf结尾的正规数据文件名，然后修改控制文件里面对应的路径信息即可。
ASMCMD> mkalias SYSTEM.261.793971825 SYSTEM01.dbf ASMCMD> mkalias SYSAUX.262.793971781 SYSAUX01.dbf ASMCMD> mkalias UNDOTBS1.275.793970675 UNDOTBS01.dbf ASMCMD> mkalias USERS.259.793972671 USERS01.dbf ASMCMD> ls -l Sys Name N SYSTEM01.dbf => +DATA/FHACDB/DATAFILE/SYSTEM.261.793971825 N SYSAUX01.dbf => +DATA/FHACDB/DATAFILE/SYSAUX.262.793971781 N UNDOTBS01.dbf => +DATA/FHACDB/DATAFILE/UNDOTBS1.275.793970675 N USERS01.dbf => +DATA/FHACDB/DATAFILE/USERS.259.793972671
由于控制文件记录的这4个数据文件名称和ASM磁盘里真实存在的数据文件名字不一样，所以在数据库MOUNT状态时，找不到这4个文件。
SQL> select FILE#,ONLINE_STATUS,ERROR from v$recover_file where error is not null;
FILE# ONLINE_ ERROR
---------- ------- ----------------
1 ONLINE FILE NOT FOUND
2 ONLINE FILE NOT FOUND
3 ONLINE FILE NOT FOUND
4 ONLINE FILE NOT FOUND
修改控制文件中这4个文件的名字为新建的以.dbf结尾的别名，ORACLE就会找到这4个文件，此时备库应用归档的话，就可以恢复备库了。
SQL> alter system set standby_file_management=MANUAL;
System altered.
SQL> alter database rename file '+DATA/fhacdb/datafile/system.261.784217547' to
'+DATA/fhacdb/datafile/system01.dbf';
Database altered.
SQL> alter database rename file '+DATA/fhacdb/datafile/sysaux.262.784217553' to
'+DATA/fhacdb/datafile/SYSAUX01.dbf';
Database altered.
SQL> alter database rename file '+DATA/fhacdb/datafile/undotbs1.263.784217557' to
'+DATA/fhacdb/datafile/undotbs01.dbf';
SQL> alter database rename file '+DATA/fhacdb/datafile/users.265.784217587' to
'+DATA/fhacdb/datafile/users01.dbf';
SQL> select FILE#,ONLINE_STATUS,ERROR from v$recover_file;
FILE# ONLINE_ ERROR
---------- ------- ------------------------------
1 ONLINE
2 ONLINE
3 ONLINE
4 ONLINE
5 ONLINE
6 ONLINE
7 ONLINE
8 ONLINE
9 ONLINE
10 ONLINE
11 ONLINE
12 ONLINE
13 ONLINE
14 ONLINE
15 ONLINE
16 ONLINE
17 ONLINE
18 ONLINE
19 ONLINE
20 ONLINE
21 ONLINE
22 ONLINE
23 ONLINE
23 rows selected.
如果备库没有切换需求的话，这个问题只需要修改备库控制文件中这4个数据文件的名字为ASM磁盘中真实存在的数据文件名，也可以解决这个问题，但是不建议这么做，因为万一主/备库需要切换，由于主备库控制文件记录的数据文件名不一致，在备库创建的STANDBY控制文件，传送给主库后，主库将不能用这个STANDBY控制文件找到这4个数据文件，在主库切换为备库后，也就无法应用日志了。
ORACLE 11g ASM文件系统OMF模式DATA GUARD搭建注意事项：等您坐沙发呢！
发表评论
