ITPub博客

首页 > Linux操作系统 > Linux操作系统 > Oracle表空间Offline的三种参数--2

Oracle表空间Offline的三种参数--2

原创 Linux操作系统 作者:zzslinux 时间:2013-10-13 09:50:19 0 删除 编辑

上篇(http://space.itpub.net/17203031/viewspace-773628)中,我们讨论了offline表空间问题、特点和用途,以及第一个offline参数normal。本篇我们继续讨论其他参数情况。

 

4、归档模式下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 testtbsoffline 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 testtbsoffline 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 AVAILABLERECOVER

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更加直接。

 

5、归档模式下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 testtbsoffline 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一遍。

SQL> alter tablespace testtbs online;

alter tablespace testtbs online

*

ERROR at line 1:

ORA-01113: file 7 needs media recovery

ORA-01110: data file 7:

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

 

 

索性直接恢复表空间好了。

 

 

SQL> recover tablespace testtbs

Media recovery complete.

 

--Online动作

SQL> alter tablespace testtbs online;

Tablespace altered.

 

 

Normal、Temporary和Immediate是三个依次使用,严格级别逐层下降的参数方法。


6、非归档情况Offline处理

 

上面的一系列讨论,都是在归档文件模式下进行的实验。如果在非归档情况下,我们面对的问题是不同的。

 

首先,非归档模式下,表空间可以进行normal offline操作。

 

 

SQL> alter database noarchivelog;

Database altered.

 

SQL> archive log list;

Database log mode             No Archive Mode

Automatic archival            Disabled

Archive destination           USE_DB_RECOVERY_FILE_DEST

Oldest online log sequence    22

Current log sequence          24

 

创建表空间,查看文件状态的。

 

 

SQL> create tablespace testtbs datafile size 10m extent management local uniform. size 1m segment space management auto;

 

Tablespace created

 

SQL> alter tablespace testtbs add datafile size 20m autoextend on;

 

Tablespace altered

 

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 AVAILABLEONLINE

11G/datafile/o1_mf_t          

esttbs_94hsw8oo_.dbf          

 

/u01/app/oradata/ORA AVAILABLEONLINE

11G/datafile/o1_mf_t          

esttbs_94hswx27_.dbf          

 

 

正常Offline Tablespace

 

 

SQL> alter tablespace testtbsoffline normal;

 

Tablespace altered

 

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 AVAILABLEOFFLINE

11G/datafile/o1_mf_t          

esttbs_94hsw8oo_.dbf          

 

/u01/app/oradata/ORA AVAILABLEOFFLINE

11G/datafile/o1_mf_t          

esttbs_94hswx27_.dbf          

 

 

SQL> alter tablespace testtbs online;

Tablespace altered

 

 

在非归档模式下,单独对数据文件进行offline是不允许的。

 

 

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

 

alter database datafile '/u01/app/oradata/ORA11G/datafile/o1_mf_testtbs_94hsw8oo_.dbf' offline

 

ORA-01145:除非启用了介质恢复,否则不允许立即脱机

 

 

试想一下,这个过程是可以理解的。Oracle认为:如果你将文件进行offline,与表空间不一致。那么,一旦文件online的时候,一定是需要进行recover来“追”上表空间中其他文件。这个过程就是需要连续的redo log来进行apply动作。

 

在非归档模式下,连续的操作redo log file是不容易拿到的。从Oracle理论上,也就认为说不可能拿到的。所以,这个时候,Oracle索性禁止这种操作行为。

 

那么,是不是非归档模式下,就不允许进行单独文件的offline了呢?不是的,只要你“允诺”说不会再回来。

 

通过后台,我们删除了数据文件。

 

--删除掉数据文件

[oracle@SimpleLinux ~]$ rm /u01/app/oradata/ORA11G/datafile/o1_mf_testtbs_94hswx27_.dbf

[oracle@SimpleLinux ~]$

 

SQL> alter system checkpoint;

alter system checkpoint

 

 

此时,数据库发现故障,实例终止。注意:不同版本Oracle在这个问题上行为有一些差异。CKPT将实例终止。

 

 

Sun Sep 29 16:59:08 2013

Beginning global checkpoint up to RBA [0x18.ad3e.10], SCN: 1062240

Errors in file /u01/app/diag/rdbms/ora11g/ora11g/trace/ora11g_ckpt_27311.trc:

ORA-01242: data file suffered media failure: database in NOARCHIVELOG mode

ORA-01116: error in opening database file 7

ORA-01110: data file 7: '/u01/app/oradata/ORA11G/datafile/o1_mf_testtbs_94hswx27_.dbf'

ORA-27041: unable to open file

Linux Error: 2: No such file or directory

Additional information: 3

Errors in file /u01/app/diag/rdbms/ora11g/ora11g/trace/ora11g_ckpt_27311.trc:

ORA-01242: data file suffered media failure: database in NOARCHIVELOG mode

ORA-01116: error in opening database file 7

ORA-01110: data file 7: '/u01/app/oradata/ORA11G/datafile/o1_mf_testtbs_94hswx27_.dbf'

ORA-27041: unable to open file

Linux Error: 2: No such file or directory

Additional information: 3

Sun Sep 29 16:59:08 2013

System state dump requested by (instance=1, sid=27311 (CKPT)), summary=[abnormal instance termination].

System State dumped to trace file /u01/app/diag/rdbms/ora11g/ora11g/trace/ora11g_diag_27299.trc

CKPT (ospid: 27311): terminating the instance due to error 1242

Dumping diagnostic data in directory=[cdmp_20130929165908], requested by (instance=1, sid=27311 (CKPT)), summary=[abnormal instance termination].

Instance terminated by CKPT, pid = 27311

 

 

--数据库终止

[oracle@SimpleLinux ~]$ ps -ef | grep pmon

oracle  27487 27404 0 17:00 pts/2   00:00:00 grep pmon

[oracle@SimpleLinux ~]$

 

 

我们将数据库启动到mount状态,之后可以offline drop文件。

 

 

--启动到mount状态。

SQL> conn / as sysdba

Connected to an idle instance.

SQL> startup mount

ORACLE instance started.

 

Total System Global Area 376635392 bytes

Fixed Size                 1345072 bytes

Variable Size            306186704 bytes

Database Buffers          62914560 bytes

Redo Buffers               6189056 bytes

Database mounted.

 

 

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

 

    FILE# STATUS RECOVER FUZZY CHECKPOINT_CHANGE#

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

        1 ONLINE NO     YES             1062240

        2 ONLINE NO     YES             1062240

        3 ONLINE NO     YES             1062240

        4 ONLINE NO     YES             1062240

        5 ONLINE NO     YES             1062240

        6 ONLINE NO     YES             1062240

        7 ONLINE                                0

 

7 rows selected

 

--直接offline不允许

SQL> alter database datafile 7 offline;

alter database datafile 7 offline

 

ORA-01145:除非启用了介质恢复,否则不允许立即脱机

 

 

--未打开情况下,表空间状态不明确

SQL> alter tablespace testtbs offline;

 

alter tablespace testtbs offline

 

ORA-01109:数据库未打开

 

--Offline Drop

SQL> alter database datafile 7 offline drop;

 

Database altered

 

SQL> alter database open;

 

Database altered

 

SQL> drop tablespace testtbs;

 

Tablespace dropped

 

 

顾名思义,Offline Drop就是永久性的删除这个对象,也就不需要了。更不要提到重新回归online

 

7、结论

 

最后,我们来总结一下Offline三种参数的情况。

 

offline normal:是最常用的场景,也是最不容易出问题的场景。Offline Normal的时候,Oracle会在表空间内部进行Check Point动作,保证表空间内部各个文件头上面的SCN一致,也就是数据一致。如果存在数据文件不能前推SCN,如已经Offline,的情况,offline normal失效报错。

 

offline temporary:比Normal要求略松的一种关闭模式。Temporary模式下,Oracle依然会去“尝试”统一表空间内部文件头的SCN号。如果数据文件可以统一,就进行Check Point动作,如果文件不能统一,操作也不会报错,只是将其状态标记为不一致。Temporary模式下Offline的表空间Online的时候,那些“有问题”的不一致文件,是需要进行media recovey的。没有问题,打入check point的数据文件,就不需要进行恢复动作。

 

offline immediate:最松的一种offline模式。Immediate模式下,Oracle不会进行check point动作,无论有无问题的Datafile,都会被设置为需要Recover过程。在重新online的时候,表空间就需要进行重新的全表空media recover

 

在日常选择上,我们倾向严格的原则。因为非Normal方式的offline,都需要借助外部的redo log进行media recover动作。选择的顺序是normaltemporaryimmediate

 

Oracle表空间的Offline动作,是我们非常常用的一种日常维护操作手段。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/26853563/viewspace-774271/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2013-07-09

  • 博文量
    6
  • 访问量
    21797