4.        块的损坏与恢复

块已经不是Oracle的格式，或者其内部是不一致的，那么这个块就被认为已损坏。块介质恢复是当数据文件是联机时，还原和恢复数据块的技术。如果只有一些块被破坏，那么块介质恢复是较好的恢复选择。

BBED（Block Brower and EDitor）是Oracle的一款内部工具，可以用来直接查看和修改Oracle数据文件块的内容。BBED是一个针对Oracle的二进制编译工具。该工具不受Oracle支持，默认是不生成可执行文件的，在使用钱需要重新编译。

1）   编译BBED

直接在Oracle 11gR2 的环境中编译BBED，将收到以下错误信息：

$ cd $ORACLE_HOME/rdbms/lib

$ make –f ins_rdbms.mk $ORACLE_HOME/rdbms/lib/bbed

……

gcc: /u01/app/oracle/11.2.0/db_1/rdbms/lib/ssbbded.o: No such file or directory

gcc: /u01/app/oracle/11.2.0/db_1/rdbms/lib/sbbdpt.o: No such file or directory

Oracle 11gR2 环境中编译BBED可执行文件所需要的ssbbded.o和sbbdpt.o对象文件被移除，不过可以从Oracle 10g环境中将这两个文件拷贝到Oracle 11g环境中进行编译。

除了将上面的ssbbded.o和sbbdpt.o文件拷贝到Oracle 11g环境外，BBED还需要用到$ORACLE_HOME/rdbms/mesg目录下的bbedus.msg和bbedus.msb两个信息文件，这几个文件都需要从Oracle 10g中拷贝到Oracle 11g中对应的目录中。下面是将以上4个文件从Oracle 10g中拷贝到Oracle 11g对应目录之后的编译过程：

            $ cd $ORACLE_HOME/rdbms/lib

            $ make –f ins_rdbms.mk $ORACLE_HOME/rdbms/lib/bbed

            $ file bbed

            $ size bbed

            $ ldd bbed

            $ cp bbed $ORACLE_HOME/bin/

            $ cd /

            $ which bbed

             /u01/app/oracle/product/11.2.0/db_1/bin/bbed

            编译成功后登录BBED，登录时需要密码（默认密码是：blockedit）

            $ bbed

2）   BBED模拟表数据块的损坏

a.        创建测试表

SQL> create table test.testbbed as select * from dba_tables;

b.        创建BBED参数文件

由于BBED无法对ASM进行操作，所以这里将表创建到ACFS文件系统的存储设备上。这里创建两个BBED参数文件，filelist.txt保存要操作的数据文件的ID和路径，bbed.par保存数据文件的块大小、filelist.txt的位置和操作模式：

$ more filelist.txt

6 /testbbed/tbtbs01.dbf

$ more bbed.par

blocksize=8192

listfile=filelist.txt

mode=edit

filelist.txt的内容可通过select file_id，file_name from dba_data_filesSQL查询得到。

c.        BBED基本操作

ü   使用指定的参数文件登录BBED：

$ bbed parfile=bbed.par

ü  显示BBED配置文件中指定的数据文件信息：

BBED> info

ü  设置要操作的数据文件：

BBED> set file 6

ü  显示要操作的数据文件的详细信息：

BBED> show

d.        模拟坏块

修改文件号为6的第136号块：

BBED> modify 1000 file 6 block 136

如果修改错误，可以执行revert命令回滚。

e.        验证坏块

在BBED执行以下命令验证数据块，发现block 136已经损坏

BBED> verify

f.         使用DBV工具验证

使用DBV工具验证发现file 6 block 136已经损坏

$ dbv file=/testbbed/tbtbs01.dbf blocksize=8192

g.        执行块读取操作

执行一个test.testbbed的全表扫描，收到ORA-01578错误

SQL> alter system flush buffer_cache;

SQL> select /*+FULL(T)*/ COUNT(1) FROM TEST.TESTBBED T;

3）   RMAN的块恢复

块介质恢复用来恢复一个单独的块或者数据文件中数据块的集合，如果是小数据量的数据丢失或损坏，而不是整个数据文件，这种类型的恢复是很有用的。通常，块损坏会在跟踪文件中报告错误信息。

块级别的数据丢失通常是由以下两个原因造成的：

n   I/O错误引起的镜像数据丢失。

n   内存损坏，刷新到磁盘。

a.        使用RMAN BLOCKRECOVER命令的注意事项

n   目标数据库必须在MOUNT或者OPEN状态，如果执行某个数据文件的块介质恢复，那么该数据文件不能是脱机状态。

n   块介质恢复不支持基于时间点的块恢复。

n   只能在损坏的块上执行块介质恢复。

n   块被标记为介质损坏之后是不能访问的，直达恢复完成。

n   当使用备份的控制文件加载数据库时，不能执行块的介质恢复。

n   必须有一个包含损坏块文件的全备份，块介质恢复不能使用增量备份。

n   如果RMAN访问块介质恢复需要特定归档Redo日志文件失败，那么将执行还原FAILOVER,尝试使用RMAN资料库中列出的适合这个操作的所有其它备份，如果没有合适的备份存在执行才会失败。

n   数据文件头不能被恢复

n   不能在非归档模式下执行块介质恢复。

b.        RMAN BLOCKRECOVER命令的使用方式

RMAN BLOCKRECOVER命令有以下三种使用方式：

方式1 使用BLOCKRECOVER CORRUPTION LIST命令恢复在V$DATABASE_BLOCK_CORRUPTION视图中报告的所有块：

RMAN> blockrecover corruption list;

方式2 使用BLOCKRECOVER 命令的时候指定文件号和块号：

RMAN> blockrecover datafile block ;

方式3 执行blockrecover命令的时候指定表空间和数据块地址（DBA）：

RMAN> blockrecover tablespace DBA ;

c.        RMAN BLOCKRECOVER使用的例子

例子1 恢复3个数据文件的损坏块：

RMAN> BLOCKRECOVER DATAFILE 2 BLOCK 12,13 DATAFILE 3 BLOCK 5,98,99 DATAFILE 4 BLOCK 19;

例子2：从数据文件拷贝中还原、恢复一系列块：

RMAN> RUN

{

BLOCKRECOVER DATAFILE 3 BLOCK 2,3,4,5 TABLESPACE sales DBA 4194405,4194409,4194412 from DATAFILECOPY;

}

例子3：从指定的tag备份总还原、恢复块

RMAN> BLOCKRECOVER TABLESPACE SYSTEM DBA 4194404,4194405 FROM TAG “weekly_backup”;

例子4：从用于恢复数据到两天以前的备份中还原、恢复SYSTEM表空间中的两个块：

RMAN> BLOCKRECOVER TALBESPACE SYSTEM DBA 4194404,4194405 RESOTRE UNTILL TIME ‘sysdate-2’;

例子5：运行备份验证数据库，修复在V$DATABASE_BLOCK_CORRUPTION中记录的所有损坏块：

RMAN> BACKUP VALIDATE DATABASE;

RMAN> BLOCKRECOVER CORRUPTION LIST;

4）   确定损坏块对应的对象

要确定一个损坏的对象需要知道AFN(Absolute File Numbe，绝对文件号)和BL(Block Number,块号)。AFN和RFN（Relative File Number，相对文件号）通常是相同的，但是也可能不同（特别是如果数据库从Oracle7迁移或者如果使用的是可传输、可插拔的表空间），获得正确的AFN和RFN就显得非常重要，如果指定了错误的AFN将导致找不到对象或错误识别对象。

a.        确定AFN和BL

方法1：从ORA-1578得到AFN

ORA-1578之后产生的ORA-1110错误提供AFN号码。

方法2：从DBVERIFY输出获得AFN。

通过使用DBV工具会报告损坏的块，DBV工具通过提供与相关的RDBA、RFN和BL信息。

方法3：从RMAN获得AFN

RMAN在V$DATABASE_BLOCK_CORRUPTION视图报告损坏的块。该视图的字段FILE#表示AFN，字段BLOCK#表示BL。

b.        定位损坏的对象

一旦AFN被识别，执行以下SQL语句定位损坏的对象：

SQL> select *

From DBA_EXTENTS

Where file_id=&AFN

And &BL BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS-1;

5.数据库完全恢复

如果损坏的块是数据文件开头，这将导致数据库无法正常启动和关闭，并且使用RMAN BLOCKRECOVER也不能恢复。因此此时就要进行完全恢复或者尝试使用BBED修改块头。

1）   模拟损坏数据文件头的块

使用BBED方法将数据文件6的第1个块损坏，DBV的检查结果如下：

$ dbv file=/test/test01.dbf

2）   尝试使用RMAN BLOCKRECOVER进行恢复

执行以下命令使用RMAN的BLOCKRECOVER对数据文件6的第1个块进行恢复：

RMAN> blockrecover datafile 6 block 1;

Starting recover as 2013-12-07 16:24

Using channel ORA_DISK_1

 

Starting media recovery

Media recovery complete,elapsed time: 00:00:00

 

Finished recover at 2013-12-07 16:24

恢复显示是完成的，也没有报错。但是执行DBV验证命令发现标记的坏块还是两个，及没有真正修复。说明使用RMAN BLOCKRECOVER对数据文件头的修复是没有作用的。

尝试正常关闭数据库，由于数据库无法完成检查点工作，所以正常关闭操作失败：

SQL> shutdown immediate

ORA-01122: database file 6 failed verification check

ORA-01110: data file 6: ‘/test/test01.dbf’

ORA-01210: data file header is media corrupt

强制关闭数据库：

SQL> shutdown abort

重启数据库，发现数据库无法打开数据文件：

SQL> startup

……

ORA-01122: database file 6 failed verification check

ORA-01110: data file 6: ‘/test/test01.dbf’

ORA-01210: data file header is media corrupt

3）   执行数据文件的完全恢复

执行以下命令还原、恢复6号数据文件：

RMAN> restore datafile 6;

RMAN> recover datafile 6;

尝试打开数据库：

SQL> alter database open;

Database altered.

Oracle数据库中有各种各样的块，如空块、表头块、数据块、索引块、数据文件头块、UNDO段块等。如果损坏的是普通表的数据块，那即不会影响启动数据库，也不会影响其他表的正常访问，只是在访问该表的时候会出现问题。如果损坏的是数据文件的块头，那么将导致数据库无法正常启动和停止，执行块恢复不能修复这个问题，执行数据文件的完全恢复才能恢复数据文件块头的损坏或尝试使用BBED修改数据文件块头。

6.数据库不完全恢复

不完全恢复又称为数据库基于时间点恢复，是将整个数据库恢复到之前的某个时间点、日志序列号或者SCN号。如下不完全恢复的选项：

不完全恢复的选项

不完全恢复方式	RMAN选项	用户管理备份选项
恢复到某个时间点	until time	until time
恢复到某个日志序列号	until suquence	until cancel
恢复到某个SCN号	until SCN	until change

不完全恢复只能针对整个数据库而言，并不能执行数据文件和表空间的不完全恢复；另外，对于非归档模式的恢复来说，也不能执行不完全恢复。

1）   基于时间点的不完全恢复

RMAN> run {

shutdown immediate;

startup mount;

SQL “alter session set nls_date_format=’’YYYY-MM-DD HH24:MI:SS’’”;（两个单引号之间没有空格）

set until time ‘2013-12-07 17:24:00’;

restore database;

recover database;

alter database open resetlogs;}

SET UNTIL TIME时间可以使用多种表示方式，可以使用TO_DATE函数来表示时间，还可以使用SYSDATE-1方式来表示时间。

注意：不完全恢复是针对整个数据而言，如果在上面的脚本中，还原和恢复的是某个数据文件或表空间，那么脚本将忽略set until time设置，对数据文件或表空间进行完全恢复。对RESTORE命令指定until time或者until scn的意义在于这样可以自动选择最近的RMAN备份来恢复数据，以上的批量命令相当于为RESTORE和RECOVER都指定了until time子句，这样比单命令模式更加简单和合理。基于时间点的恢复不能恢复到最终备份完成时间点以前的时段。

2）   基于序列号的不完全恢复

基于序列号的不完全恢复须指定某个Redo线程的序列号，那么在这个序列号切换时间点之前的所有实例的归档日志都需要的，每个节点的负载不同，其他实例的序列号可能比指定的Redo线程序列号要大。

以下是在RMAN中基于日志序列号的不完全恢复的例子：

RMAN> run {

Shutdown immediate;

Startup mount;

Set until sequence 10350 thread 1;

Restore database;

Recover database;

Alter database open resetlogs;}

注意：指定线程序列号为10350，但是恢复是不包含该序列号的日志的，也就是说恢复只会恢复到thread 1 sequence 10304的日志，时间点和scn恢复同样如此。

3）   基于SCN的不完全恢复

下面是在RMAN中基于SCN的不完全恢复的例子：

RMAN> run {

shutdown immediate;

startup mount;

set until scn 324394;

restore database;

recover database;

alter database open resetlogs;}

注意：对打开的数据库执行的全库备份或者0级备份，即使不完全恢复到执行全库备份或者0级备份的备份时间点也可能需要部分Redo日志，原因在于对打开的数据库执行RMAN备份是一个不一致的备份。

7.表空间时间点恢复

表空间时间点恢复（Tablespace Point-in-time Recovery，TSPITR）特性可以恢复一个或更多的表空间早于数据库其他部分的某个时间点。表空间时间点恢复是表空间的不完全恢复，操作起来比较复杂。

表空间时间点恢复能在不影响数据库其它表空间和对象的情况下，恢复一个或更多的用户表空间到之前的某个时间点。表空间时间点恢复是对某个表空间执行基于某个时间点的恢复，是特殊的不完全恢复。RMAN TSPITR可以用于以下场景：

n   一个不正确的job或者DML语句破坏了数据库其中一个表空间的数据，RMAN TSPITR可用于被破坏表空间的恢复。

n   DDL操作改变了表的结构之后，RMAN TSPITR可用于丢失数据的恢复。这种情况不能使用Flashback Table找回表之前的结构的数据，如表结构变化后的一个TRUNCATE表操作。

n   一个表被一个drop语句加了purge选项彻底drop。RMAN TSPITR可用于这种情况的恢复。

n   恢复drop的表空间，当没有使用恢复目录，RMAN能对被drop的表空间执行TSPITR。

n   从一个表的逻辑损坏中恢复。

表空间时间点恢复和Flashback有点类似，在没有介质失败的情况下，数据也可以使用Flashback Database找回，但是Flashback Database会导致整个数据库被闪回到之前的某个时间点。与TSPITR不同的是，Flashback Database特性必须产生Flashback日志，使用Flashback Database闪回数据库比使用TSPITR有更多的限制，TSPITR可以扩展到能找回可用于恢复的更早备份数据。

1）   TSPITR的工作原理

TSPITR工作原理的5个步骤：

步骤1 在辅助实例上用目标数据库的备份集还原数据文件。

步骤2 在辅助实例上用目标数据库的归档文件恢复数据文件。

步骤3 在辅助数据库上导出相关数据。

步骤4 修改主库的控制文件。

步骤5 将辅助数据上导出的文件导入目标数据库。

2）   RMAN TSPITR模式

表空间时间点恢复使用的是RMAN的RECOVER tablespace命令，执行RMAN TSPITR有几个选项，不同的选项协调各种不同的操作模式之间对特定环境的自动化操作。

a.        全自动化（默认方式）

在这种模式下，RMAN管理整个TSPITR过程。制定表空间的恢复集、辅助目的地、目标时间和允许RMAN管理所有TSPITR的其它方面。

b.        自动化

可以覆盖一些默认RMAN TSPITR设置，但仍然使用RMAN管理辅助实例和辅助目的地。这是默认方式的变种，RMAN TSPITR提供一些固定管理的同事允许手动指定一些参数，主要包含以下两个参数：

n   辅助集或恢复集文件的位置

n   初始化参数文件

除了在TSPITR之后的恢复集文件位置，在TSPITR期间的辅助集文件、通道设置和参数或辅助实例的其它方面等更多控制都推荐使用默认方式。全自动和自动化都是使用RMAN自动管理辅助实例。

c.        非自动化

使用这种模式是手动创建和管理辅助实例的所有方面和一部分TSPITR过程。当必须分配不同的通道或者使用用户管理辅助实例改变参数时，使用这种模式是合适的。

3）   执行全自动化的TSPITR

下面以默认的全自动化模式在目标数据库服务器创建辅助数据库构建TSPITR，恢复在目标数据库对表的一个误操作。目标数据库与辅助数据库都在一台服务器上，下表是两个数据库的实例名和数据库名称对照表：

数据库类型	实例名称	数据库名称
目标数据库	test	test
辅助数据库	test2	test

a.        创建模拟环境

步骤1 在目标数据创建测试表空间xy_tbs:

SQL> create tablespace xy_tbs datafile ‘/u01/app/oracle/test/xy_tbs01.dbf’ size 5M;

步骤2 确保目标数据库处在归档模式，使用RMAN查找出xy_tbs表空间的file_id，对它进行备份：

RMAN> report schema;

……

RMAN> backup datafile 5;

步骤3 创建测试用户xiaoyang：

SQL> create user xiaoyang identified by xiaoyang default tablespace xy_tbs tempory tablespace temp;

SQL> grant create session,create table,unlimited tablespace to xiaoyang;

SQL> connect xiaoyang/xiaoyang;

步骤4 创建两个测试表：x1和x2，每个表插入一条测试数据：

SQL> create table x1(D date);

SQL> create table x2(D2 date);

SQL> insert into x1 values(sysdate);

SQL> insert into x2 values(sysdate);

SQL> commit;

步骤5 查看当前时间作为表空间的恢复时间点：

SQL> alter session set nls_date_format=’YYYY-MM-DD HH24:MI:SS’;

SQL> select sysdate from dual;

步骤6 在恢复时间点之后向x2表中插入一条数据和创建一个新表x3，向x3插入一条测试数据：

SQL> insert into x2 values(sysdate);

SQL> create table x3(D3 date);

SQL> insert into x3 values(sysdate);

SQL> commit;

步骤7 手动drop掉表x1：

SQL> drop table x1 purge;

假设drop x1表是一个误操作，现在要通过TSPITR恢复技术恢复该表。

b.        检查表空间是否自关联

执行以下SQL语句检查表空间自关联情况：

SQL> execute dbms_tts.transport_set_check(‘xy_tbs’,true,true);

SQL> select * from transport_set_violations;

如果查询transport_set_violations视图有值返回，说明表空间有自关联，需要手动处理提示的问题。

c.        标识TSPITR之后将会丢失的对象

步骤1 通过时间标识TSPITR之后将会丢失的对象：

SQL> select owner,name,tablespace_name,to_char(creation_time,’YYYY-MM-DD HH24:MI:SS’) from ts_pitr_objects_to_be_dropped where tablespace_name in(‘xy_tbs’) and creation_time > to_date(‘2013-12-08 09:43:00’,’YYYY-MM-DD HH24:MI:SS’) order by tablespace_name,creation_time;

步骤2 通过SCN标识TSPITR之后将会丢失的对象：

SQL> select owner,names,tablespace_name,to_char(creation_time,’YYYY-MM-DD HH24:MI:SS’) from ts_pitr_objects_to_be_dropped where tablespace_name in(‘xy_tbs’) and creation_time > to_date(to_char(scn_to_timestamp(1638492),’YYYY-MM-DD HH24:MI:SS’),’YYYY-MM-DD HH24:MI:SS’) order by tablespace_name,creation_time;

如果以上两个查询有结果返回，那么在执行TSPITR之前应该先将这些对象进行逻辑备份，TSPITR完成之后，再将这些对象以替换的方式导入，以恢复产生数据丢失的对象。

d.        创建辅助数据库参数文件

转储目标数据库参数文件，将该参数文件拷贝到$ORACLE_HOME目录，重命名为inittest2.ora，参考如下参数文件内容调整inittest2.ora实例的初始化参数文件：

*.audit_file_dest=’/u01/app/oracle/admin/test2/adump’

*.control_files=’/u01/app/oracle/oradata/test2/control01.ctl’

……

db_file_name_convert=(“/u01/app/oracle/oradata/test”,”/u01/app/oracle/oradata/test2”)

log_file_name_convert=(“/u01/app/oracle/oradata/test”,”/u01/app/oracle/oradata/test2”)

log_archive_start=false

lock_name_space=test2

修改test2实例初始化参数文件中的audit_file_dest、control_file参数，确保与原有数据库的存储位置不同。添加db_file_name_convert、log_file_name_convert、log_archive_start和lock_name_space参数设置。

e.        创建目录结构

根据实例test2参数的设置创建相应的目录结构：

$ mkdir –p /u01/app/oracle/admin/test2/adump

$ mkdir –p /u01/app/oracle/oradata/test2

f.         创建test2实例密码文件

$ cd $ORACLE_HOME/dbs/

$ orapwd file=orapwtest2 password=oracle entries=5

g.        创建辅助数据库实例的静态注册

在grid用户下的$GRID_HOME/network/admin/listener.ora文件中修改如下配置：

$ cat listener.ora

SID_LIST_LISTENER =

  (SID_LIST =

    (SID_DESC =

      (GLOBAL_DBNAME = test2)

      (ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)

      (SID_NAME = test2)

   )

)

h.        添加Oracle Net本地服务名

在Oracle用户下的$ORACLE_HOME/network/admin/tnsnames.ora文件中添加如下配置：

TEST2 =

  (DESCRIPTION =

(ADDRESS_LIST =

  (ADDRESS = (PROTOCOL = TCP)(HOST = rhel2)(PORT = 1521))

)

(CONNECT_DATA =

  (SERVICE_NAME = test2)

)

                       )

i.         启动辅助数据库到NOMOUNT状态

$ export ORACLE_SID=test2

$ sqlplus / as sysdba

SQL> create spfile from pfile;

SQL> startup nomount

j.         执行TSPITR恢复

使用RMAN同时连接到目标数据库和辅助数据库，使用RECOVER TABLESPACE命令执行TSPITR操作：

$ rman target /

RMAN> connect auxiliary sys/oracle@test2

RMAN> run {

allocate auxiliary channel a1 type disk;

allocate channel c1 type disk;

recover tablespace xy_tbs until time “to_date(‘2013-12-08 09:30:00’,’YYYY-MM-DD HH24:MI:SS’)”;

release channel c1;

}

执行TSPITR需要手动分配auxiliary通道

使目标数据中xy_tbs表空间ONLINE：

SQL> alter tablespace xy_tbs online;

k.        验证恢复结果

SQL> select * from xiaoyang.x1;

SQL> select * from xiaoyang.x2;

SQL> select * from xiaoyang.x3;

数据库特殊情况的恢复

1. 联机Redo日志损坏与恢复

对于正常关闭的数据库来说，关闭前会执行一个检查点以保证数据库的一致性，重启之后，联机日志是是否存在都不会导致数据的丢失。然而，如果是非正常关闭的数据库，重启之后会执行实例恢复的过程，如果实例恢复过程需要的UNDO活Redo日志丢失，那么就可能造成数据的不一致和数据的丢失。

a.       连接Redo日志损坏的4种情况

联机Redo日志文件的损坏有以下4中情况：

情况1 非当前日志损坏，正常关闭数据库。

情况2 非当前日志损坏，非正常关闭数据库。

情况3 当前日志损坏，正常关闭数据库。

情况4 当前日志损坏，非正常关闭数据库。

b.       处理方法

1）  情况1和情况2的处理方法

情况1和情况2的处理方法一样，直接把日志文件清除即可：

SQL> alter database clear logfile group 3;

2）  情况3的处理方法

在SQLPLUS中执行以下的SQL语句以RESETLOGS模式重新打开数据库：

SQL> startup mount;

SQL> recover database until cancel;

SQL> alter database open resetlogs;

3）  情况4的处理方法

这种情况会导致联机Redo日志中的一部分已提交的数据丢失，实例恢复中的前滚操作不能成功执行，回滚操作也无法执行，这也会导致部分数据的丢失。处理方法是强制打开数据库或通过备份执行介质不完全恢复。

2.       数据文件脱机与恢复

数据库的脱机包括数据文件的脱机和表空间的脱机，数据文件的脱机和表空间非正常脱机在下一次执行联机命令之前都无需先执行介质恢复操作，介质恢复成功才能联机成功。

数据文件添加到表空间之后不能再被删除，也没有语法支持这么做，如果不想使用该数据文件，唯一的方法是将数据文件设置为OFFLINE状态。执行以下步骤将数据文件设置为OFFLINE状态：

1）  如果是归档模式可以执行如下SQL语句设置数据文件的状态为OFFLINE：

SQL> alter database datafile ‘xxx.dbf’ offline;

2）  如果是非归档模式执行以下SQL语句将数据文件状态设置为OFFLINE：

SQL> alter database datafile ‘xxx.dbf’ offile drop;

即使数据文件脱机，数据文件相关的数据字典信息、元数据信息依然存在，当表空间被删除后，相关数据文件的信息才会被清除。Drop tablespace只是清空Oracle数据字典信息，即使数据文件不存在也可以正常的drop表空间。对于数据文件的脱机，在设置该数据文件OFFLINE的时候都需要对该数据文件执行介质恢复。

如果在非归档模式下使用OFFLINE drop使数据文件脱机，这就意味着该数据文件可能无法再恢复到online状态，原因在于非归档模式下可能没有足够的日志文件在执行online的时候完成介质恢复。如果数据文件脱机之后日志没有发生切换，所有需要的日志还依然存在的话，那么非归档模式下数据文件的脱机也可以再次变成online状态。

3.       表空间脱机与恢复

表空间脱机实际就是表空间对应的所有数据文件脱机。

表空间脱机分为正常脱机、临时脱机和立即脱机，如下：

1）    正常脱机

这是默认的选项，如果表空间正常脱机，当重新执行online的时候，Oracle会用相应的SCN来更新表空间数据文件头SCN即可正常地online表空间，而不需要执行介质恢复。执行以下SQL语句是表空间正常脱机：

SQL> alter tablespace xxx offline;

2）    临时脱机

当执行临时脱机（OFFLINE temporary）语句之前已经有表空间对应的数据文件脱机，那么在是表空间重新online之前需要执行特定数据文件的介质恢复。执行以下的SQL语句是表空间临时脱机：

SQL> alter tablespace xxx offline temporary;

3）    立即脱机

执行这个操作（OFFLINE immediate）表示立即使表空间脱机，在下次使表空间online的时候必须执行介质恢复，介质恢复成功之后表空间才能变成online状态。执行以下的SQL语句是表空间立即脱机：

SQL> alter tablespace xxx offline immediate;

...............................................................................................................................
● 本文来自于itpub转载文章，若有侵权，请联系小麦苗及时删除，非常感谢原创作者fengpinDBA的无私奉献
● 本文在itpub（http://blog.itpub.net/26736162）、博客园(http://www.cnblogs.com/lhrbest)和个人微信公众号（xiaomaimiaolhr）上有同步更新
● QQ群：230161599  微信群：私聊
● 原文地址：http://blog.itpub.net/29339097/viewspace-1062090/
● 小麦苗云盘地址：http://blog.itpub.net/26736162/viewspace-1624453/
● QQ群： 230161599   微信群：私聊
● 联系我请加QQ好友(642808185)，注明添加缘由
●【版权所有，文章允许转载，但须以链接方式注明源地址，否则追究法律责任】
...............................................................................................................................
手机长按下图识别二维码或微信客户端扫描下边的二维码来关注小麦苗的微信公众号：xiaomaimiaolhr,免费学习最实用的数据库技术。