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

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 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一遍。

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是三個依次使用，嚴格級別逐層下降的引數方法。

聊聊Oracle表空間Offline的三種引數（中）

相關文章