[20151025]linux下删除数据文件的恢复细节3

[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的进程。