linux 软连接temp文件覆盖数据文件导致数据库故障

概述：有时为了操作系统管理上的方便会建立软连接，但是会出现错误的将软连接的文件指错导致数据被覆盖的悲剧；本文记录网上老师分享的一个HPunix HA 切换 由于资源自的乱连接错误指向导致的悲剧。本文就老师所说的原理做个测试记录保存。

实验内容为，错误的将oracle temp文件软连接指向数据文件，导致数据丢失；

实验：

SQL> select name from v$datafile;

NAME
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/CUBE/system01.dbf
/u01/app/oracle/oradata/CUBE/sysaux01.dbf
/u01/app/oracle/oradata/CUBE/undotbs01.dbf
/u01/app/oracle/oradata/CUBE/users01.dbf

SQL> select name from v$tempfile;

NAME
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/CUBE/temp01.dbf

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

[root@six CUBE]# ls -l
total 1439076
-rw-r----- 1 oracle oinstall   9748480 Dec 29 14:36 control01.ctl
-rw-r----- 1 oracle oinstall  52429312 Dec 29 14:36 redo01.log
-rw-r----- 1 oracle oinstall  52429312 Dec 29 14:26 redo02.log
-rw-r----- 1 oracle oinstall  52429312 Dec 29 14:26 redo03.log
-rw-r----- 1 oracle oinstall 492838912 Dec 29 14:36 sysaux01.dbf
-rw-r----- 1 oracle oinstall 775954432 Dec 29 14:36 system01.dbf
-rw-r----- 1 oracle oinstall  20979712 Dec 29 14:19 temp01.dbf
-rw-r----- 1 oracle oinstall  31465472 Dec 29 14:36 undotbs01.dbf
-rw-r----- 1 oracle oinstall   5251072 Dec 29 14:36 users01.dbf
[root@six CUBE]# rm temp01.dbf 
rm: remove regular file `temp01.dbf'? y
[root@six CUBE]# ln -s users01.dbf temp01.dbf
[root@six CUBE]# ls -l
total 1438052
-rw-r----- 1 oracle oinstall   9748480 Dec 29 14:36 control01.ctl
-rw-r----- 1 oracle oinstall  52429312 Dec 29 14:36 redo01.log
-rw-r----- 1 oracle oinstall  52429312 Dec 29 14:26 redo02.log
-rw-r----- 1 oracle oinstall  52429312 Dec 29 14:26 redo03.log
-rw-r----- 1 oracle oinstall 492838912 Dec 29 14:36 sysaux01.dbf
-rw-r----- 1 oracle oinstall 775954432 Dec 29 14:36 system01.dbf
lrwxrwxrwx 1 root   root            11 Dec 29 14:37 temp01.dbf -> users01.dbf
-rw-r----- 1 oracle oinstall  31465472 Dec 29 14:36 undotbs01.dbf
-rw-r----- 1 oracle oinstall   5251072 Dec 29 14:36 users01.dbf

数据能够启动 但是数据文件里的内容就会被冲掉了

SQL> startup
ORACLE instance started.


Total System Global Area  839282688 bytes
Fixed Size                  2257880 bytes
Variable Size             545262632 bytes
Database Buffers          289406976 bytes
Redo Buffers                2355200 bytes
Database mounted.
Database opened.

[oracle@six CUBE]$ dd if=./users01.dbf bs=8192 skip=1 count=1|strings
1+0 records in
1+0 records out
8192 bytes (8.2 kB) copied, 3.2334e-05 s, 253 MB/s
CUBE
TEMP

再次数据库重启的时候就会提示错误的了

SQL> shutdown immediate
ORA-01122: database file 4 failed verification check
ORA-01110: data file 4: '/u01/app/oracle/oradata/CUBE/users01.dbf'
ORA-01210: data file header is media corrupt

只能够shutdow  abort  被冲掉后 数据库将再也启动不了了

SQL> shutdown abort
ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Total System Global Area  839282688 bytes
Fixed Size                  2257880 bytes
Variable Size             545262632 bytes
Database Buffers          289406976 bytes
Redo Buffers                2355200 bytes
Database mounted.
ORA-01122: database file 4 failed verification check
ORA-01110: data file 4: '/u01/app/oracle/oradata/CUBE/users01.dbf'
ORA-01210: data file header is media corrupt

只能够使用备份恢复了 使用 restore datafile 4；recover datafile 4；

[oracle@six ~]$ rman target /


Recovery Manager: Release 11.2.0.4.0 - Production on Fri Dec 29 14:45:41 2017


Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.


connected to target database: CUBE (DBID=3147500147, not open)


RMAN> restore datafile 4;


Starting restore at 29-DEC-17
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=18 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 00004 to /u01/app/oracle/oradata/CUBE/users01.dbf
channel ORA_DISK_1: reading from backup piece /u01/app/oracle/fast_recovery_area/CUBE/backupset/2017_12_29/o1_mf_nnndf_TAG20171229T142632_f4cr0s77_.bkp
channel ORA_DISK_1: piece handle=/u01/app/oracle/fast_recovery_area/CUBE/backupset/2017_12_29/o1_mf_nnndf_TAG20171229T142632_f4cr0s77_.bkp tag=TAG20171229T142632
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
Finished restore at 29-DEC-17


RMAN> recover datafile 4;


Starting recover at 29-DEC-17
using channel ORA_DISK_1


starting media recovery
media recovery complete, elapsed time: 00:00:00


Finished recover at 29-DEC-17

此时如果不讲错误的软连接删除 那又将重复上面的操作，又将再次的破坏；此时需要先删除软连接再起库就ok了

[oracle@six CUBE]$ rm -rf /u01/app/oracle/oradata/CUBE/temp01.dbf
[oracle@six CUBE]$ ls -l
total 1438052
-rw-r----- 1 oracle oinstall   9748480 Dec 29 14:47 control01.ctl
-rw-r----- 1 oracle oinstall  52429312 Dec 29 14:45 redo01.log
-rw-r----- 1 oracle oinstall  52429312 Dec 29 14:38 redo02.log
-rw-r----- 1 oracle oinstall  52429312 Dec 29 14:38 redo03.log
-rw-r----- 1 oracle oinstall 492838912 Dec 29 14:44 sysaux01.dbf
-rw-r----- 1 oracle oinstall 775954432 Dec 29 14:44 system01.dbf
-rw-r----- 1 oracle oinstall  31465472 Dec 29 14:44 undotbs01.dbf
-rw-r----- 1 oracle oinstall   5251072 Dec 29 14:45 users01.dbf

SQL> alter database open;
Database altered.

再次验证user01.dbf的文件是否是正常的库：

[oracle@six CUBE]$ dd if=./users01.dbf bs=8192 skip=1 count=1|strings
CUBE
USERS
1+0 records in
1+0 records out
8192 bytes (8.2 kB) copied, 0.000481972 s, 17.0 MB/s

[oracle@six CUBE]$ dbv help=y


DBVERIFY: Release 11.2.0.4.0 - Production on Fri Dec 29 14:51:52 2017


Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.


Keyword     Description                    (Default)
----------------------------------------------------
FILE        File to Verify                 (NONE)
START       Start Block                    (First Block of File)
END         End Block                      (Last Block of File)
BLOCKSIZE   Logical Block Size             (8192)
LOGFILE     Output Log                     (NONE)
FEEDBACK    Display Progress               (0)
PARFILE     Parameter File                 (NONE)
USERID      Username/Password              (NONE)
SEGMENT_ID  Segment ID (tsn.relfile.block) (NONE)
HIGH_SCN    Highest Block SCN To Verify    (NONE)
            (scn_wrap.scn_base OR scn)           
[oracle@six CUBE]$ dbv file=/u01/app/oracle/oradata/CUBE/users01.dbf blocksize=8192


DBVERIFY: Release 11.2.0.4.0 - Production on Fri Dec 29 14:52:21 2017


Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.


DBVERIFY - Verification starting : FILE = /u01/app/oracle/oradata/CUBE/users01.dbf




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): 590
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 33
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Total Pages Encrypted        : 0
Highest block SCN            : 921351 (0.921351)

总结风险提示：请妥善管理数据库文件；temp文件将冲掉数据文件，那如果是数文件软连接数据文件呢？

[oracle@six CUBE]$ ln -s users01.dbf system02.dbf
[oracle@six CUBE]$ ls -l
total 1439076
-rw-r----- 1 oracle oinstall   9748480 Dec 29 14:58 control01.ctl
-rw-r----- 1 oracle oinstall  52429312 Dec 29 14:58 redo01.log
-rw-r----- 1 oracle oinstall  52429312 Dec 29 14:58 redo02.log
-rw-r----- 1 oracle oinstall  52429312 Dec 29 14:58 redo03.log
-rw-r----- 1 oracle oinstall 492838912 Dec 29 14:58 sysaux01.dbf
-rw-r----- 1 oracle oinstall 775954432 Dec 29 14:58 system01.dbf
lrwxrwxrwx 1 oracle oinstall        11 Dec 29 15:00 system02.dbf -> users01.dbf
-rw-r----- 1 oracle oinstall  20979712 Dec 29 14:48 temp01.dbf
-rw-r----- 1 oracle oinstall  31465472 Dec 29 14:58 undotbs01.dbf
-rw-r----- 1 oracle oinstall   5251072 Dec 29 14:58 users01.dbf
[oracle@six CUBE]$ ls -l
total 1439076
-rw-r----- 1 oracle oinstall   9748480 Dec 29 15:00 control01.ctl
-rw-r----- 1 oracle oinstall  52429312 Dec 29 15:00 redo01.log
-rw-r----- 1 oracle oinstall  52429312 Dec 29 15:00 redo02.log
-rw-r----- 1 oracle oinstall  52429312 Dec 29 15:00 redo03.log
-rw-r----- 1 oracle oinstall 492838912 Dec 29 15:00 sysaux01.dbf
-rw-r----- 1 oracle oinstall 775954432 Dec 29 15:00 system01.dbf
lrwxrwxrwx 1 oracle oinstall        11 Dec 29 15:00 system02.dbf -> users01.dbf
-rw-r----- 1 oracle oinstall  20979712 Dec 29 14:48 temp01.dbf
-rw-r----- 1 oracle oinstall  31465472 Dec 29 15:00 undotbs01.dbf
-rw-r----- 1 oracle oinstall   5251072 Dec 29 15:00 users01.dbf
[oracle@six CUBE]$ dd if=./users01.dbf bs=8192 skip=1 count=1|strings
1+0 records in
1+0 records out
8192 bytes (8.2 kB) copied, 1.6961e-05 s, 483 MB/s
CUBE
USERS
[oracle@six CUBE]$ dbv file=./users01.dbf 


DBVERIFY: Release 11.2.0.4.0 - Production on Fri Dec 29 15:01:36 2017


Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.


DBVERIFY - Verification starting : FILE = /u01/app/oracle/oradata/CUBE/users01.dbf


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): 590
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 33
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Total Pages Encrypted        : 0
Highest block SCN            : 921351 (0.921351)
[oracle@six CUBE]$ 

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


Total System Global Area  839282688 bytes
Fixed Size                  2257880 bytes
Variable Size             545262632 bytes
Database Buffers          289406976 bytes
Redo Buffers                2355200 bytes
Database mounted.
Database opened.

SQL> select count(*) from scott.emp;


  COUNT(*)
----------
        14

数据库正常，user01数据文件没有被覆盖冲毁；