导航：首页 > 服务器 >

如何理解Oracle表空间Offline的三种参数

发表于：2026-10-31 作者：千家信息网编辑

千家信息网最后更新 2026年10月31日，如何理解Oracle表空间Offline的三种参数，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。归档模式下Tempora

千家信息网最后更新 2026年10月31日如何理解Oracle表空间Offline的三种参数

如何理解Oracle表空间Offline的三种参数，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。

归档模式下Temporary Offline操作

Offline Normal是一种比较理想的情况。在很多时候，Offline一个Tablespace的时候，有其他因素需要考虑。比如，在offline操作的时候，此时如果有正在进行的对表空间对象的DDL和DML操作，offline可能是会受到影响。

此外，如果一个表空间中有数据文件已经被Offline过了，我们正常是不能够进行offline normal的。此时，我们就需要使用temporary。

我们首先将表空间online处理，之后将其中一个数据文件offline。注意：这个操作是在Archivelog模式下才能进行。

SQL> alter tablespace testtbs online;

Tablespace altered

SQL> alter database datafile '/u01/app/oradata/ORA11G/datafile/o1_mf_testtbs_94hpygrx_.dbf' offline;

Database altered

之后，观察表空间和文件状态。我们发现被offline的数据文件状态为Recover。

SQL> select tablespace_name, status from dba_tablespaces where tablespace_name='TESTTBS';

TABLESPACE_NAME STATUS

------------------------------ ---------

TESTTBS ONLINE

SQL> select file_name, status, online_status from dba_data_files where tablespace_name='TESTTBS';

FILE_NAME STATUS ONLINE_STATUS

-------------------- --------- -------------

/u01/app/oradata/ORA AVAILABLE RECOVER

11G/datafile/o1_mf_t

esttbs_94hpygrx_.dbf

/u01/app/oradata/ORA AVAILABLE ONLINE

11G/datafile/o1_mf_t

esttbs_94hq0dgm_.dbf

注意，Oracle维持数据文件一致性，是一个动态一致性的过程。如果某一个文件或者对象临时性的退出了这个一致性机制，就表示这个文件或者对象已经不一致。经过时间不论长短，如果该对象希望回归到原有的一致性体系里面，就需要进行Recover。Oracle进行Recover手段就是连续的redo log文件列。

这里，我们看到的文件recover状态，就表明如果需要这个文件回到Online状态，需要进行Recover。

回到我们的Offline主题。此时，Online状态表空间下的几个文件状态是不一致的。

SQL> alter tablespace testtbs offline normal;

alter tablespace testtbs offline normal

ORA-01191: 文件 6 已脱机 - 无法进行正常脱机

ORA-01110: 数据文件 6: '/u01/app/oradata/ORA11G/datafile/o1_mf_testtbs_94hpygrx_.dbf'

SQL> create table mm tablespace testtbs as select * from dba_objects where 1=0;

Table created

正常normal offline已经不能成功了。我们此时可以使用temporary参数。

SQL> alter tablespace testtbs offline temporary;

Tablespace altered

--Alert Log中的日志信息

Sun Sep 29 16:02:34 2013

alter tablespace testtbs offline temporary

Completed: alter tablespace testtbs offline temporary

SQL> select tablespace_name, status from dba_tablespaces where tablespace_name='TESTTBS';

TABLESPACE_NAME STATUS

------------------------------ ---------

TESTTBS OFFLINE

SQL> select file_name, status, online_status from dba_data_files where tablespace_name='TESTTBS';

FILE_NAME STATUS ONLINE_STATUS

-------------------- --------- -------------

/u01/app/oradata/ORA AVAILABLE RECOVER

11G/datafile/o1_mf_t

esttbs_94hpygrx_.dbf

/u01/app/oradata/ORA AVAILABLE OFFLINE

11G/datafile/o1_mf_t

esttbs_94hq0dgm_.dbf

我们使用temporary参数，实现了Offline。但是对于那个提前进行offline的数据文件，状态依然是recover。猜想，Temporary Offline的过程是一种不一致的关闭。

试图v$datafile和v$datafile_header分别反映了控制文件和数据文件头中文件SCN号的记录。在offline normal的时候，我们看到了各个文件的一致性。在进行offline normal的时候，Oracle是打入了一个check point（内部），来同步各个文件的文件头SCN。

在使用Temporary的时候，视图状态如何呢？

SQL> select file#, status, recover, fuzzy, CHECKPOINT_CHANGE# from v$datafile_header;

FILE# STATUS RECOVER FUZZY CHECKPOINT_CHANGE#

---------- ------- ------- ----- ------------------

1 ONLINE NO YES 1054312

2 ONLINE NO YES 1054312

3 ONLINE NO YES 1054312

4 ONLINE NO YES 1054312

5 ONLINE NO YES 1054312

6 OFFLINE YES YES 1058660

7 OFFLINE NO NO 1058696

7 rows selected

SQL> select file#, CHECKPOINT_CHANGE#, OFFLINE_CHANGE# from v$datafile;

FILE# CHECKPOINT_CHANGE# OFFLINE_CHANGE#

---------- ------------------ ---------------

1 1054312 787896

2 1054312 787896

3 1054312 787896

4 1054312 787896

5 1054312 819012

6 1058660 1058506

7 1058696 1058506

7 rows selected

控制文件和文件头上面两个文件的SCN编号不相同，说明在一个表空间内部文件的SCN号是不一致的。

说明：在Temporary Offline的时候，一些"有问题"的数据文件和"没问题"的数据文件状态是可以不一样的。"没问题"的数据文件之间SCN号是一致。

如果此时要求Online表空间，会报错。

SQL> alter tablespace testtbs online;

alter tablespace testtbs online

ORA-01113: 文件 6 需要介质恢复

ORA-01110: 数据文件 6: '/u01/app/oradata/ORA11G/datafile/o1_mf_testtbs_94hpygrx_.dbf'

在online的时候，Oracle一定会去online一个"一致"的表空间。此时，它会发现表空间内部SCN的不一致。根据提示，我们需要手工进行文件恢复。

--进行media recovery过程

SQL> recover datafile 6;

Media recovery complete.

SQL> alter tablespace testtbs online;

Tablespace altered

online成功了。在alert log中，我们看到了进行media recovery中使用的redo log apply乃至archived redo log apply过程。注意一点：此时我们只恢复了datafile 6。

Sun Sep 29 16:07:22 2013

ALTER DATABASE RECOVER datafile 6

Media Recovery Start

Serial Media Recovery started

Recovery of Online Redo Log: Thread 1 Group 3 Seq 24 Reading mem 0

Mem# 0: /u01/app/oradata/ORA11G/onlinelog/o1_mf_3_92t73782_.log

Mem# 1: /u01/app/fast_recovery_area/ORA11G/onlinelog/o1_mf_3_92t737fj_.log

Media Recovery Complete (ora11g)

Completed: ALTER DATABASE RECOVER datafile 6

Sun Sep 29 16:07:36 2013

alter tablespace testtbs online

Completed: alter tablespace testtbs online

Temporary Offline的特点是：在进行Offline的时候，依然会对表空间内文件进行同步Check Point打入动作。与Normal不同的是，如果某个或者某些文件因为种种原因，不能打入check point来同步SCN，Offline动作时可以继续的。Temporary只保证一部分文件一致即可。

在Temporary Offline表空间进行Online的时候，Oracle会检查表空间内文件的SCN一致性。注意：这个时候，Oracle只认可表空间一个SCN号加入到现有数据库中，如果内部不一致，会拒绝online操作。

如果被拒绝online，我们只需要（注意是只需要）将原来那些问题文件进行recover就可以了。recover中使用Redo Log进行前推动作，将问题文件推到和表空间其他文件一致就可以了。

最后在online，就没有问题了。

注意：即使是使用Temporary Offline，但是check point动作依然是存在，只是变成非强制性动作了。如果表空间文件中没有"问题儿童"，即使使用了Temporary Offline命令，效果和Normal没有区别。而且，在online的时候，也不需要进行recover过程。

下面我们讨论Immediate参数方法，它较Temporary更加直接。

归档模式下Immediate参数

我们先还原现场为Online，依然是将数据文件6进行offline动作。

SQL> alter tablespace testtbs online;

Tablespace altered

SQL> alter database datafile '/u01/app/oradata/ORA11G/datafile/o1_mf_testtbs_94hpygrx_.dbf' offline;

Database altered

--尝试正常关闭失败

SQL> alter tablespace testtbs offline normal;

alter tablespace testtbs offline normal

ORA-01191: 文件 6 已脱机 - 无法进行正常脱机

ORA-01110: 数据文件 6: '/u01/app/oradata/ORA11G/datafile/o1_mf_testtbs_94hpygrx_.dbf'

我们此处使用offline immediate操作。

--立即offline

SQL> alter tablespace testtbs offline immediate;

Tablespace altered

SQL> select file#, CHECKPOINT_CHANGE#, OFFLINE_CHANGE# from v$datafile;

FILE# CHECKPOINT_CHANGE# OFFLINE_CHANGE#

---------- ------------------ ---------------

1 1059725 787896

2 1059725 787896

3 1059725 787896

4 1059725 787896

5 1059725 819012

6 1059634 1059175

7 1059725 1059175

7 rows selected

SQL> select file#, status, recover, fuzzy, CHECKPOINT_CHANGE# from v$datafile_header;

FILE# STATUS RECOVER FUZZY CHECKPOINT_CHANGE#

---------- ------- ------- ----- ------------------

1 ONLINE NO YES 1059725

2 ONLINE NO YES 1059725

3 ONLINE NO YES 1059725

4 ONLINE NO YES 1059725

5 ONLINE NO YES 1059725

6 OFFLINE YES YES 1059634

7 OFFLINE YES YES 1059725

7 rows selected

和Temporary相似的内容方面是，问题数据文件存在的情况下，表空间依然可以进行Offline操作。但是区别是，Oracle在immediate参数情况下，就不会给任何数据文件进行check point统一SCN动作了。

这种方法类似于shutdown abort。无论文件是不是有问题，Oracle都不进行检查和统一动作。

还有个细节需要全局注意，就是v$datafile_header中的recover列。在normal参数的时候，这个列是不显示的，也就是表示这个问题不需要关注和理睬。在Tempory模式下，只有那些"问题"文件才会被标注为YES，也就是需要进行Recover。其他没问题的文件状态为NO，也就是不需要进行recover。上面的实验也证明了这点。

而immediate参数情况下，所有文件状态都是YES，表示无论好坏，都要进行recover。

下面尝试online动作。

SQL> alter tablespace testtbs online;

alter tablespace testtbs online

ERROR at line 1:

ORA-01113: file 6 needs media recovery

ORA-01110: data file 6:

'/u01/app/oradata/ORA11G/datafile/o1_mf_testtbs_94hpygrx_.dbf'

Online动作失败，需要进行恢复。

SQL> recover datafile 6;

Media recovery complete.

--依然不行，需要将所有的文件都recover一遍。