RAC创建数据文件放错目录修复方法（居然还能有使用场景）

前段时间遇到了个用户，甲方人员看到数据文件不足想自己尝试增加，然后网上找了一个语句去执行。执行后完成数据文件添加，一查询发现的确表空间增加了。正在他觉得自己牛逼的时候有用户反馈如下错误了。。。

报错信息
ORA-01157: 无法标识/锁定数据文件 8 - 请参阅 DBWR 跟踪文件
ORA-01110: 数据文件 8: '/u01/app/oracle/auditdata01.dbf'

分析
rac中因为是共享存储，所以创建数据文件一定要在共享存储里面创建。如果指定了本地目录，那他会在你链接的节点的服务器上对应位置创建文件，虽然会创建成功，但是只有改节点正常读取，其它节点就无法读取该文件。

根据该情况也可以给出相应的解决方案：

1、集群资源消耗较小，可以只用有这个文件的一个节点提供服务，这样就不会报错了。

2、这个数据文件的业务可以影响一小会，离线文件挪到asm中（因为只要查询到插入到这个新数据文件的才会报错，所以一般影响可能较小）

错误复现

--创建测试表空间
create tablespace AUDITDATA datafile '+DATA' size 100m autoextend on next 10m;
--创建测试数据文件
alter tablespace AUDITDATA add datafile '/u01/app/oracle/auditdata01.dbf' size 100m autoextend on next 10m;
--查询数据文件（只有创建文件的节点可以正常执行，其它节点报错）
select * from dba_data_files;
--确认当前所在节点
select * from v$instance;

解决方法
本文介绍了三种影响面稍微较小的方法，这里面三个方法整体思路都是一样就是把文件复制到asm磁盘中，然后恢复数据文件。

离线数据文件

alter database datafile '/u01/app/oracle/auditdata01.dbf' offline;

三种解决方法
dbms_file_transfer

--先创建两个目录，dbms_file_transfer需要用到这里两个目录一个是当前数据文件的位置，另一个目录就是需要挪到的位置。
create directory errodir as '/u01/app/oracle/';
create directory okdir as '+DATA/zhanky/datafile/';

--dbms_file_transfer复制文件
exec dbms_file_transfer.copy_file('errodir','auditdata01.dbf','okdir','auditdata01.dbf');

rman copy datafile

rman target /
copy datafile '/u01/app/oracle/auditdata01.dbf' to '+DATA/zhanky/datafile/auditdata01.dbf';

asm cp

mv /u01/app/oracle/auditdata01.dbf /home/grid/
chown grid:asmadmin /home/grid/auditdata01.dbf
su - grid
asmcmd
cd +DATA/zhanky/datafile
cp /u01/app/oracle/auditdata01.dbf auditdata01.dbf

修改控制文件的位置

alter database rename file '/u01/app/oracle/auditdata01.dbf' to '+DATA/zhanky/datafile/auditdata01.dbf';

恢复文件

alter database recover datafile '+DATA/zhanky/datafile/auditdata01.dbf';
alter database datafile '+DATA/zhanky/datafile/auditdata01.dbf' online;

扩展知识
复制到asm的文件他会自动重命名，你的名字会变成链接一样的
auditdata01、auditdata03采用dbms_file_transfer恢复的
auditdata02采用
auditdata01

ASMCMD> ls -l
Type Redund Striped Time Sys Name
DATAFILE UNPROT COARSE MAY 21 21:00:00 Y AUDITDATA.281.1169588019
DATAFILE UNPROT COARSE MAY 21 22:00:00 Y AUDITDATA.283.1169590343
DATAFILE UNPROT COARSE MAY 21 21:00:00 Y COPY_FILE.282.1169588519
DATAFILE UNPROT COARSE MAY 21 22:00:00 Y COPY_FILE.284.1169590551
DATAFILE UNPROT COARSE MAY 21 21:00:00 Y SYSAUX.257.1165835573
DATAFILE UNPROT COARSE MAY 21 21:00:00 Y SYSTEM.256.1165835573
DATAFILE UNPROT COARSE MAY 21 21:00:00 Y UNDOTBS1.258.1165835573
DATAFILE UNPROT COARSE MAY 21 21:00:00 Y UNDOTBS2.264.1165835685
DATAFILE UNPROT COARSE MAY 21 21:00:00 Y USERS.259.1165835573
N auditdata01.dbf => +DATA/ZHANKY/DATAFILE/COPY_FILE.282.1169588519
N auditdata02.dbf => +DATA/ZHANKY/DATAFILE/AUDITDATA.283.1169590343
N auditdata03.dbf => +DATA/ASM/DATAFILE/auditdata03.dbf.285.1169591759
N auditdata04.dbf => +DATA/ZHANKY/DATAFILE/COPY_FILE.284.1169590551

你还蛮有耐心的，都看到这里来了，那我给你在补一课。关于这种情况不调整的情况下服务器可以重启吗。

在这种情况下，数据库集群可以正常重启吗。如果一个节点一个节点的重启呢。如果我是进实例一个个重启呢。

登录到节点登录到实例一个个重启（shutdown immediate）

1. 如果一个个重启，不会有影响正常启动
2. 如果是先启动有文件的节点则不会报错。
3. 如果同时关闭先启动没有文件的节点会报错（如果报错后你去把有文件那个节点起来后，你可以alter database open在把节点起来）

集群可以正常重启吗（crsctl stop cluster）

1. 如果一个个重启，不会有影响正常启动
2. 如果是先启动有文件的节点则不会报错。
3. 如果同时关闭先启动没有文件的节点会报错（如果报错后你去把有文件那个节点起来后，你可以alter database open在把节点起来）

全部集群重启（crsctl start cluster -all）

显示没有文件的节点error但是后面有启动成功了

[root@rac2:/root]$ crsctl stat res -t
CRS-4535: Cannot communicate with Cluster Ready Services
CRS-4000: Command Status failed, or completed with errors.
[root@rac2:/root]$ crsctl start cluster -all
CRS-2672: Attempting to start 'ora.cssdmonitor' on 'rac2'
CRS-2676: Start of 'ora.cssdmonitor' on 'rac2' succeeded
CRS-2672: Attempting to start 'ora.cssd' on 'rac2'
CRS-2672: Attempting to start 'ora.diskmon' on 'rac2'
CRS-2676: Start of 'ora.diskmon' on 'rac2' succeeded
CRS-2676: Start of 'ora.cssd' on 'rac2' succeeded
CRS-2672: Attempting to start 'ora.ctssd' on 'rac2'
CRS-2676: Start of 'ora.ctssd' on 'rac2' succeeded
CRS-2672: Attempting to start 'ora.evmd' on 'rac2'
CRS-2672: Attempting to start 'ora.cluster_interconnect.haip' on 'rac2'
CRS-2676: Start of 'ora.evmd' on 'rac2' succeeded
CRS-2676: Start of 'ora.cluster_interconnect.haip' on 'rac2' succeeded
CRS-2672: Attempting to start 'ora.asm' on 'rac2'
CRS-2676: Start of 'ora.asm' on 'rac2' succeeded
CRS-2672: Attempting to start 'ora.crsd' on 'rac2'
CRS-2676: Start of 'ora.crsd' on 'rac2' succeeded
CRS-4690: Oracle Clusterware is already running on 'rac1'
CRS-4000: Command Start failed, or completed with errors.

ora.zhanky.db
      1        ONLINE  ONLINE       rac1                     Open                
      2        ONLINE  OFFLINE                               Instance Shutdown,S 
                                                             TARTING             过一会。。。。。ora.zhanky.db
      1        ONLINE  ONLINE       rac1                     Open                
      2        ONLINE  ONLINE       rac2                     Open     

[root@rac2:/root]$ srvctl status database -d zhanky
Instance zhanky1 is running on node rac1
Instance zhanky2 is running on node rac2

所以重启是可以的，及时失败了把有文件的节点起来后在open也是可以的。

那基于上述条件、这个特性虽然有影响，但是也可以进行利用，他有个小应用，asm磁盘不足，但是本地空间大，就只用这个节点和这个节点的服务器磁盘。也不是不行。毕竟用户的想法你怎么能理解呢，你只需要告诉可不可以，如何做就好了，你说是吧