一些什么原因导致要恢复介质文件？

yyp2009

SQL>  alter tablespace users offline Normal;

表空间已更改。

SQL>  alter tablespace users online;

表空间已更改。

SQL> alter tablespace users offline immediate;

表空间已更改。

SQL>
SQL> alter tablespace users online;
alter tablespace users online
*
第 1 行出现错误:
ORA-01113: 文件 4 需要介质恢复
ORA-01110: 数据文件 4: 'E:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\USERS01.DBF'


SQL> recover tablespace users;
完成介质恢复。
SQL> alter tablespace users online;

表空间已更改。

SQL>
SQL> alter tablespace users offline Temporary;

表空间已更改。

SQL>  alter tablespace users online;

表空间已更改。


自己玩了一下

yyp2009

贴一下这里的内容：
http://blog.sina.com.cn/s/blog_465a4a1e010005s2.html

offline drop 后的数据文件在控制文件里会删除相应的信息吗？

继续上一个话题，为什么有表空间创建后的控制文件，offline drop数据文件后，不用备份还可以恢复呢？这是因为控制文件中有数据文件的创建信息。
下面来验证：
idle>alter session set events 'immediate trace name CONTROLF level 10';
会话已更改。
DATA FILE #2: <deleted>
---之前我们drop tablespace了，看到没：这里也仅是一个deleted标识位。
---然后其它信息清 "0"。
creation size=0 block size=0 status=0x0 head=0 tail=0 dup=0
tablespace 0, index=0 krfil=0 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:0 scn: 0x0000.00000000 01/01/1988 00:00:00
Stop scn: 0x0000.00000000 01/01/1988 00:00:00
Creation Checkpointed at scn:  0x0000.00000000
thread:0 rba0x0.0.0)
enabled  threads:  00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
Offline scn: 0x0000.00000000 prev_range: 0
Online Checkpointed at scn:  0x0000.00000000
thread:0 rba0x0.0.0)
enabled  threads:  00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
Hot Backup end marker scn: 0x0000.00000000
aux_file=0
idle>create tablespace using_backcon datafile
  2  'd:\ora92\oradata\oracle\using_backcon01.dbf' size 5m reuse;
表空间已创建。
idle>alter session set events 'immediate trace name CONTROLF level 10';
会话已更改。
DATA FILE #2:
  (name #3) D:\ORA92\ORADATA\ORACLE\USING_BACKCON01.DBF
creation size=640 block size=8192 status=0xe head=3 tail=3 dup=1
tablespace 28, index=2 krfil=2 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:2 scn: 0x0000.5488c9fc 08/22/2006 11:32:24
Stop scn: 0xffff.ffffffff 08/22/2006 11:32:24
Creation Checkpointed at scn:  0x0000.5488c9fb 08/22/2006 11:32:24
thread:1 rba0x1.3b7.10)
---创建数据文件时对应的rba，恢复时，由此处开始。
enabled  threads:  01000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
Offline scn: 0x0000.00000000 prev_range: 0
Online Checkpointed at scn:  0x0000.00000000
thread:0 rba0x0.0.0)
enabled  threads:  00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
Hot Backup end marker scn: 0x0000.00000000
aux_file is NOT DEFINED

idle>alter database datafile 2 offline drop;
数据库已更改。
idle>alter session set events 'immediate trace name CONTROLF level 10';
会话已更改。
DATA FILE #2:  ---看到没，数据文件信息并未删除。
  (name #3) D:\ORA92\ORADATA\ORACLE\USING_BACKCON01.DBF
creation size=640 block size=8192 status=0x81c head=3 tail=3 dup=1
tablespace 28, index=2 krfil=2 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:2 scn: 0x0000.5488c9fc 08/22/2006 11:32:24
Stop scn: 0x0000.5488ca52 08/22/2006 11:33:39
---Stop scn表明数据文件offline了。
Creation Checkpointed at scn:  0x0000.5488c9fb 08/22/2006 11:32:24
thread:1 rba0x1.3b7.10)
enabled  threads:  01000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
Offline scn: 0x0000.00000000 prev_range: 0
Online Checkpointed at scn:  0x0000.00000000
thread:0 rba0x0.0.0)
enabled  threads:  00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
Hot Backup end marker scn: 0x0000.00000000
aux_file is NOT DEFINED

icer_repls

你这个实验说明了7L是正确的

我现在还有点其他的事干 等下回来再自己动手做做实验 好好研究一下这个知识点

^__^  大家多讨论， 多进步

leetaedong

[quote]原帖由 yyp2009 于 2011-5-19 15:25 发表
贴一下这里的内容：
http://blog.sina.com.cn/s/blog_465a4a1e010005s2.html

ls 贴的是我的文章。

yyp2009

呵呵

失敬失敬！

yyp2009

我以前真纳闷呢？

为什么 offline drop后

recover一下就可以了

正好看到你的文章解惑了

呵呵

[ 本帖最后由 yyp2009 于 2011-5-19 15:41 编辑 ]

icer_repls

1.没有显示指明脱机方式，默认为normal
SQL> alter tablespace tb1 offline;

表空间已更改。

SQL> alter tablespace tb1 online;

表空间已更改。

2.显示指明时normal
SQL> alter tablespace tb1 offline normal;

表空间已更改。

SQL> alter tablespace tb1 online;

表空间已更改。

3.显示指明为临时offline
SQL> alter tablespace tb1 offline temporary;

表空间已更改。

SQL> alter tablespace tb1 online;

表空间已更改。

上述三种脱机方式实验成功.

icer_repls

但是用immediate方式脱机表空间时，失败，错误信息如下：

SQL> alter tablespace tb1 offline immediate;
alter tablespace tb1 offline immediate
*
第 1 行出现错误:
ORA-01145: 除非启用了介质恢复, 否则不允许立即脱机

然后自己尝试先恢复这个表空间然后再immediate脱机，结果还是失败，错误信息如下：
SQL> recover tablespace tb1;
ORA-00283: 恢复会话因错误而取消
ORA-01124: 无法恢复数据文件 10 - 文件在使用中或在恢复中
ORA-01110: 数据文件 10: 'C:\DISK4\TB102.DBF'

因为提示文件正在使用或恢复中，于是我先将这个表空间用正常的方式脱机之后，再恢复，提示信息如下：


SQL> alter tablespace tb1 offline;

表空间已更改。

SQL> recover tablespace tb1;
ORA-00283: 恢复会话因错误而取消
ORA-00264: 不要求恢复

后来一想，这一步有点sb的味道，明明normal方式脱机就不需要恢复. 所以这一步就当做自己的sb之举吧,不要见笑

然后查了一下资料说在非归档模式下，不能对表空间进行offline操作，其实仔细想想也是这样的，因为我们的immediate offline在重新online时必须进行re
cover数据文件，而我们重新recover数据文件当然就需要在归档模式下记录的一些信息（非归档模式下不会记录一些相关信息）。
接着我将数据库切换到归档模式下：
默认是非归档模式
SQL> archive log list;
数据库日志模式             非存档模式
自动存档             禁用
存档终点            USE_DB_RECOVERY_FILE_DEST
最早的联机日志序列     17
当前日志序列           19

归档：
SQL> alter database archivelog;

数据库已更改。

SQL> alter database open;

数据库已更改。

SQL> archive log list;
数据库日志模式            存档模式
自动存档             启用
存档终点            USE_DB_RECOVERY_FILE_DEST
最早的联机日志序列     17
下一个存档日志序列   19
当前日志序列           19

然后再immediate方式offline表空间，提示需要介质恢复
SQL> alter tablespace tb1 offline immediate;

表空间已更改。

SQL> alter tablespace tb1 online;
alter tablespace tb1 online
*
第 1 行出现错误:
ORA-01113: 文件 9 需要介质恢复
ORA-01110: 数据文件 9: 'C:\DISK3\TB101.DBF'

然后恢复介质
SQL> recover tablespace tb1;
完成介质恢复。
SQL> alter tablespace tb1 online;

表空间已更改。

至此，immediate 方式offline实验成功.

icer_repls

刚看了这篇文章：http://dbsnake.com/2010/11/offline-offline-drop-diff.html
里面说对一个datafile执行offline或offline drop本质上是一回事，但对一个datafile执行offline只能在归档模式下；而对一个datafile执行offline drop则既可以在归档模式也可以在非归档模式下。
我还没理解offline drop到底是什么意思呢？  帮我解释一下 thx

icer_repls

刚又接着尝试了一下数据文件的脱机：
SQL> alter database datafile 'C:\DISK3\TB101.DBF' offline;

数据库已更改。

提示需要介质恢复：
SQL> alter database datafile 'C:\DISK3\TB101.DBF' online;
alter database datafile 'C:\DISK3\TB101.DBF' online
*
第 1 行出现错误:
ORA-01113: 文件 9 需要介质恢复
ORA-01110: 数据文件 9: 'C:\DISK3\TB101.DBF'

恢复介质后，然后重新设置为联机，成功
SQL> recover datafile 'C:\DISK3\TB101.DBF';
完成介质恢复。
SQL> alter database datafile 'C:\DISK3\TB101.DBF' online;

数据库已更改。

接着利用drop子句（虽然现在还是没理解这个子句的意思，但还是先把实验做完再说）脱机数据文件

SQL> alter database datafile 'C:\DISK3\TB101.DBF' offline drop;

数据库已更改。

SQL> alter database datafile 'C:\DISK3\TB101.DBF' online;
alter database datafile 'C:\DISK3\TB101.DBF' online
*
第 1 行出现错误:
ORA-01113: 文件 9 需要介质恢复
ORA-01110: 数据文件 9: 'C:\DISK3\TB101.DBF'


SQL> recover datafile 'C:\DISK3\TB101.DBF';
完成介质恢复。
SQL> alter database datafile 'C:\DISK3\TB101.DBF' online;

数据库已更改。

我们发现在这种方式下，仍然需要介质恢复才可以是脱机的数据文件改变为联机状态。这是为什么呢？因为我们一个表空间里面的数据文件可能不止一个，而我们将表空间里面的一个数据文件d1.dbf设置为脱机的时候，其他的数据文件d2.dbf可能是联机的，这是后我们在d1.dbf处于脱机的时候，可能对处于联机状态的d2.dbf进行了修改，而我们一个表空间内的几个数据文件很有可能是相关联的，比如说一个表的数据分别在两个数据文件里面存储。所以为了保持数据的一致性和正确性，在处于脱机状态的d1.dbf重新变为连接的时候我们需要对d1.dbf进行恢复，来达到数据一致性和准确性。
而表空间为什么有时候有offline改变为online时却不要进行数据恢复呢？因为表空间是一个相对独立的概念，表空间与表空间的联系不大，我们每次是对脱机联机是对整个表空间进行操作，在有些脱机模式下，比如说normal，就是执行一次检查点，将相关信息写入数据文件，然后再脱机表空间（此时所有数据都保持了一致性）。所以说，表空间重新置为联机的时候不一定需要介质恢复.