如何理解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一遍。

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

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。