[20151025]linux下删除数据文件的恢复细节3.txt
--以前曾经写过一篇关于
--链接：http://blog.itpub.net/267265/viewspace-763969/
--里面提到实际上这种方式对于生产系统不是很合适，而且生产系统情况非常复杂，不可能出现删除数据文件时没有事务产生。
--这种方式仅仅适合no archivelog的模式(没有办法的选择)，我当时还提到这种方式一定要快，因为我的测试执行 alter system
--checkpoint;,数据库直接crash。
--正好别人问我一些检查点的问题，让我重新思考以前的解决思路。我喜欢通过例子详细说明：
--前几天重新思考这个问题，链接http://blog.itpub.net/267265/viewspace-1816212/，当时的思路有一些乱。恢复N次，测试N次。
--脑子有点乱。
--首先这种恢复是万不得已，当然如果直接crash，还可以通过一些文件恢复工具extundelete来恢复。
--链接：http://extundelete.sourceforge.net/
1.前面的测试说明如果删除了数据文件，已经登录的会话实际上不受影响的，因为文件句柄已经打开，虽然文件删除了，但是磁盘空间并
没有释放。
2.另外的我的测试如果这个时候新登录的会话(也就是进程没有打开访问文件的句柄)，如果执行
alter system flush buffer_cache; (有可能，许多情况下应该不会)
alter tablespace mssm read only ; (报ORA-03135 10g)
alter system checkpoint; (报ORA-03113 10g)
--说明1点：不知道10g与11g存在什么不同，要等以后测试再下结论。
--因为这种方式要先打开文件句柄，检查数据文件是否存在，具体写脏块应该有dbw进程完成。如果文件不存在，直接影响dbw进程写入。
--后台直接crash。
--换一个思路，如果新打开的进程看看是否要打开文件句柄，也可以验证我的判断是否正确。继续测试：
1.环境：
RMAN> report schema;
using target database control file instead of recovery catalog
Report of database schema
List of Permanent Datafiles
===========================
File Size(MB) Tablespace RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1 510 SYSTEM *** /mnt/ramdisk/test/system01.dbf
2 350 UNDOTBS1 *** /mnt/ramdisk/test/undotbs01.dbf
3 370 SYSAUX *** /mnt/ramdisk/test/sysaux01.dbf
4 100 USERS *** /mnt/ramdisk/test/users01.dbf
5 100 EXAMPLE *** /mnt/ramdisk/test/example01.dbf
6 15 MSSM *** /mnt/ramdisk/test/mssm01.dbf
List of Temporary Files
=======================
File Size(MB) Tablespace Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- --------------------
1 18 TEMP 32767 /mnt/ramdisk/test/test01.dbf
SYS@test> @ver1
PORT_STRING VERSION BANNER
------------------------------ -------------- ----------------------------------------------------------------
x86_64/Linux 2.4.xx 10.2.0.4.0 Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
--保险期间我在关闭数据库的情况下做了一个冷备份，当然仅仅备份mssm01.dbf文件。
--注：我前面的测试是11g，这次是10g。
2.开始测试：
--session 1:
SCOTT@test> create table t tablespace mssm as select * from dba_objects ;
Table created.
SCOTT@test> select count(*) from t;
COUNT(*)
------------
50650
SCOTT@test> alter system checkpoint;
System altered.
SCOTT@test>col spid new_value v_spid
SCOTT@test> @spid
SID SERIAL# SPID C50
------------ ------------ ------ --------------------------------------------------
156 23 25554 alter system kill session '156,23' immediate;
SCOTT@test> host ls -l /proc/&v_spid/fd | grep mssm01.dbf
lrwx------ 1 oracle oinstall 64 Oct 26 08:55 12 -> /mnt/ramdisk/test/mssm01.dbf
lrwx------ 1 oracle oinstall 64 Oct 26 08:55 18 -> /mnt/ramdisk/test/mssm01.dbf
--先不做删除数据文件操作，看看会话在执行一些alter system flush buffer_cache;alter tablespace mssm read only ;alter
--system checkpoint;是否会打开文件句柄。
3.检查打开句柄情况：
--session 2:
SCOTT@test> col spid new_value v_spid
SCOTT@test> @spid
SID SERIAL# SPID C50
------------ ------------ ------ --------------------------------------------------
145 7 23851 alter system kill session '145,7' immediate;
SCOTT@test> host ls -l /proc/&v_spid/fd | grep mssm01.dbf
SCOTT@test> alter system flush buffer_cache;
System altered.
SCOTT@test> host ls -l /proc/&v_spid/fd | grep mssm01.dbf
--可以发现执行alter system flush buffer_cache;无需打开/mnt/ramdisk/test/mssm01.dbf文件句柄。
SCOTT@test> alter tablespace mssm read only;
Tablespace altered.
SCOTT@test> host ls -l /proc/&v_spid/fd | grep mssm01.dbf
lrwx------ 1 oracle oinstall 64 Oct 26 09:07 16 -> /mnt/ramdisk/test/mssm01.dbf
--可以发现alter tablespace mssm read only;要先打开/mnt/ramdisk/test/mssm01.dbf文件句柄,再写涉及到的脏块与文件检查点。
SCOTT@test> alter tablespace mssm read write;
Tablespace altered.
4.退出继续测试，因为文件句柄已经打开。
--session 2:
SCOTT@test> col spid new_value v_spid
SCOTT@test> @spid
SID SERIAL# SPID C50
------------ ------------ ------ --------------------------------------------------
145 9 23994 alter system kill session '145,9' immediate;
SCOTT@test> host ls -l /proc/&v_spid/fd | grep mssm01.dbf
SCOTT@test> alter system checkpoint;
System altered.
SCOTT@test> host ls -l /proc/&v_spid/fd | grep mssm01.dbf
--恩！alter system checkpoint;也不打开吗？为什么执行这个前面的测试会崩溃呢？
--做1个跟踪测试：
$ strace -f -p 23994 -e open,statfs
Process 23994 attached - interrupt to quit
open("/u01/app/oracle/admin/test/bdump/alert_test.log", O_WRONLY|O_CREAT|O_APPEND, 0660) = 6
open("/proc/23694/stat", O_RDONLY) = 12
--下面我也做了删除数据文件，有时候执行！alter system checkpoint;可以不报错有时候不行。包括alter tablespace mssm read
--only;有时候会崩溃，有时候不会。先放弃这部分的探究。
5.如果出现这种情况，要使用这种方式，如何恢复呢：
SYS@test> alter database datafile 6 offline ;
Database altered.
# lsof | grep /mnt/ramdisk/test/mssm01.dbf
oracle 25554 oracle 12u REG 0,29 16654336 355026 /mnt/ramdisk/test/mssm01.dbf (deleted)
# ps -ef | grep 2555[4]
oracle 25554 25553 0 10:21 ? 00:00:00 oracletest (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
--而这个进程是session 1的进程号，理论讲不能保证在拷贝的过程中用户退出会话的情况。
--也就是讲先offline的方式是不行的。因为dbw等进程的文件句柄丢失了，而用户会话保留的句柄可能不会长久。
--而且实际上等1会，mmon进程也会清理无效的链接。
# lsof | grep /mnt/ramdisk/test/mssm01.dbf
--无输出。这个时候无法恢复了。
--换1句话还必须欺骗oracle保证这个文件存在才行。
6.先恢复继续测试，整个恢复过程仅仅按照链接的介绍才行：
--http://blog.itpub.net/267265/viewspace-1816212/
利用先通过dbw0进程指向的句柄，建立链接使用ln命令。
登录会话，执行alter tablespace xxxx read only;
然后使用rm删除原链接，cp /proc/xxx/fd/NN delete_file.dbf。
这个时候不能执行alter tablespace xxxx read write;(切记!!!!!)
要执行
alter database datafie 6 offline drop; --注:后面说明为什么要使用drop参数。
recover datafile 6;
alter database datafie 6 online ;
alter tablespace xxxx read write;
--补充1点，不要drop也可以。测试有点乱。我估计我自己忘记
alter database datafie 6 offline
alter database datafie 6
--不放心可以
$ lsof | grep mssm01.dbf |grep delete
删除标识deleted的进程。