使用alter database datafile 'XXX' offline drop 是否能够恢复(非归档模式下)

本文通过实验揭示在非归档模式下,使用`alter database datafile 'XXX' offline drop`命令无法恢复数据。在日志未切换时可能误以为成功,但一旦日志切换,由于缺乏归档,数据无法恢复。强调在非归档模式下避免使用drop命令,以免造成不可逆的数据丢失,特别是在高日志切换频率的生产环境中。
今天在群里面听到一位网友在说使用了alter database datafile 'XXX' offline drop命令是否能够恢复数据,在非归档模式下,下面是用一个实验来验证一下
 
SQL> create tablespace test datafile '/u01/app/oracle/oradata/orcl/test01.dbf' size 10M autoextend on next 1M;

Tablespace created.

SQL> create table test(id number,name varchar2(12)) tablespace test;                                               

Table created.

SQL> insert into test values (1,'colin');

1 row created.

SQL> insert into test values (2,'janey');

1 row created.

SQL> insert into test values (3,'tom');

1 row created.

SQL> insert into test values (4,'adele');

1 row created.

SQL> commit;

Commit complete.

SQL> select * from test;

        ID NAME
---------- ------------
         1 colin
         2 janey
         3 tom
         4 adele

SQL> alter database datafile '/u01/app/oracle/oradata/orcl/test01.dbf' offline drop;

Database altered.

SQL> commit;

Commit complete.

SQL> select * from test;
select * from test
              *
ERROR at line 1:
ORA-00376: file 2 cannot be read at this time
ORA-01110: data file 2: '/u01/app/oracle/oradata/orcl/test01.dbf'

SQL> select LOG_MODE,OPEN_MODE from v$database;

LOG_MODE     OPEN_MODE
------------ ----------
NOARCHIVELOG READ WRITE

SQL> alter database datafile '/u01/app/oracle/oradata/orcl/test01.dbf' online;
alter database datafile '/u01/app/oracle/oradata/orcl/test01.dbf' online
*
ERROR at line 1:
ORA-01113: file 2 needs media recovery
ORA-01110: data file 2: '/u01/app/oracle/oradata/orcl/test01.dbf'


SQL> recover datafile '/u01/app/oracle/oradata/orcl/test01.dbf';
Media recovery complete.
SQL> alter database datafile '/u01/app/oracle/oradata/orcl/test01.dbf' online;

Database altered.

SQL> select * from test;

        ID NAME
---------- ------------
         1 colin
         2 janey
         3 tom
         4 adele

恢复成功。那是因为日志还米有切换,使用了online日志。
 
切换日志来测试:

SQL> alter database datafile '/u01/app/oracle/oradata/orcl/test01.dbf' offline drop;

Database altered.

SQL> select * from test;
select * from test
*
ERROR at line 1:
ORA-00376: file 2 cannot be read at this time
ORA-01110: data file 2: '/u01/app/oracle/oradata/orcl/test01.dbf'


SQL> alter system switch logfile;

System altered.

SQL> /

System altered.

SQL> /
/

System altered.

SQL> 
System altered.

SQL> recover datafile '/u01/app/oracle/oradata/orcl/test01.dbf';
ORA-00279: change 654004 generated at 07/09/2012 21:07:18 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/arch/1_32_777559117.arc
ORA-00280: change 654004 for thread 1 is in sequence #32


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
Media recovery cancelled.
SQL> /

System altered.

SQL> recover datafile '/u01/app/oracle/oradata/orcl/test01.dbf';
ORA-00279: change 654004 generated at 07/09/2012 21:07:18 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/arch/1_32_777559117.arc
ORA-00280: change 654004 for thread 1 is in sequence #32


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00308: cannot open archived log '/u01/app/oracle/arch/1_32_777559117.arc'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3


ORA-00308: cannot open archived log '/u01/app/oracle/arch/1_32_777559117.arc'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3

 

         通过以上测试表明,在非归档模式下使用了alter database datafile 'XXX' offline drop命令是不能被恢复的,虽然我上面的第一次实验成功了,那是因为online日志还没有切换,在日志中还能够找到相应的反操作。在第二个实验中,手工切换日志,会提示不能打开归档日志,因为我根本就没有归档,肯定找不到啊,所以不能够恢复的。切记,在非归档模型下不要随意使用一些drop命令,在实际生产环境中日志的切换是很频繁且快的,否则只有掏钱找oracle了。当然,如果在业务不繁忙的系统可以及时的通过online日志进行恢复,这种几率比较小。

 

在 Oracle 数据库中,执行 `ALTER DATABASE DATAFILE 32 OFFLINE FORCE;` 报错通常与数据文件的状态、数据库的运行模式或介质恢复需求相关。以下是可能导致该命令报错的一些常见原因及相应的解决方法: ### 原因一:数据库未处于归档日志模式 如果数据库不在归档日志模式下(ARCHIVELOG 模式),则不能使用 `OFFLINE FORCE` 强制将数据文件离线。此时需要手动切换数据库至归档日志模式[^1]。 #### 解决方法: 1. 关闭数据库: ```sql SHUTDOWN IMMEDIATE; ``` 2. 启动数据库到 mount 状态并启用归档日志模式: ```sql STARTUP MOUNT; ALTER DATABASE ARCHIVELOG; ``` 3. 打开数据库: ```sql ALTER DATABASE OPEN; ``` 完成以上操作后,再尝试执行强制离线命令。 --- ### 原因二:数据文件不存在或状态异常 目标数据文件可能已损坏、丢失或被标记为不可用。这种情况下,Oracle 不允许直接将其离线。 #### 解决方法: 1. 查询数据文件状态: ```sql SELECT file#, status, enabled FROM v$datafile WHERE file# = 32; ``` 2. 如果发现数据文件处于 `INVALID` 或其他异常状态,需先修复其物理路径和文件内容。 3. 若无法立即修复,可考虑从备份中恢复数据文件: ```sql RECOVER DATAFILE 32; ``` 确认数据文件可用后再尝试强制离线操作。 --- ### 原因三:表空间正在使用中 如果目标数据文件所在的表空间当前正被用户事务占用,则无法安全地将其离线。 #### 解决方法: 1. 查询当前连接到表空间的会话信息: ```sql SELECT s.sid, s.serial# FROM v$session s JOIN v$access a ON s.sid = a.sid WHERE a.object = (SELECT tablespace_name FROM dba_data_files WHERE file_id = 32); ``` 2. 杀掉阻塞的会话: ```sql ALTER SYSTEM KILL SESSION 'sid,serial#'; ``` 3. 再次尝试执行: ```sql ALTER DATABASE DATAFILE 32 OFFLINE FORCE; ``` --- ### 原因四:权限不足 执行 `ALTER DATABASE DATAFILE ... OFFLINE FORCE` 需要具有 `ALTER DATABASE` 权限的用户,例如 `DBA` 角色。 #### 解决方法: 1. 确认当前用户是否具备相应权限: ```sql SELECT * FROM session_privs WHERE privilege = 'ALTER DATABASE'; ``` 2. 如果权限不足,请使用具有足够权限的账户重新登录后执行操作。 --- ### 原因五:数据库处于只读模式 当数据库处于只读模式时,不允许对数据文件进行任何修改操作,包括强制离线。 #### 解决方法: 1. 查看数据库模式: ```sql SELECT log_mode FROM v$database; ``` 2. 如果处于只读模式,关闭数据库并以读写模式重新启动: ```sql SHUTDOWN IMMEDIATE; STARTUP; ``` 之后再执行强制离线命令。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值