RESTRICT、QUIESCE和SUSPEND

數據庫的這三種狀態有相似之處，這裏簡單總結一下。

RESTRICT狀態
在Oracle中，有時候要執行一些管理性的操作，而這些操作運行的時候不能有其他用戶同時訪問數據庫。對於這種情況可以設置系統進入RESTRICTED SESSION狀態禁止普通用戶登陸數據庫。

數據庫可以在啓動的時候以RESTRICT方式來啓動數據庫：

SQL> conn / as sysdba已連接。
SQL> shutdown immediate數據庫已經關閉。已經卸載數據庫。
ORACLE 例程已經關閉。
SQL> startup restrict
ORACLE 例程已經啓動。

Total System Global Area 5279498240 bytes
Fixed Size 2094528 bytes
Variable Size 3192597056 bytes
Database Buffers 2080374784 bytes
Redo Buffers 4431872 bytes數據庫裝載完畢。數據庫已經打開。
SQL> conn test/test
ERROR:
ORA-01035: ORACLE only available to users with RESTRICTED SESSION privilege

警告: 您不再連接到 ORACLE。
SQL> conn / as sysdba已連接。
SQL> select granted_role from dba_role_privs
2 where grantee = 'TEST';

GRANTED_ROLE
------------------------------------------------------------
CONNECT
RESOURCE

SQL> grant dba to test;

授權成功。

SQL> conn test/test已連接。
SQL> conn / as sysdba已連接。
SQL> revoke dba from test;

撤銷成功。

SQL> grant restricted session to test;

授權成功。

SQL> conn test/test已連接。

可以看到，當數據庫以RESTRICT狀態啓動，或者進入到RESTRICT狀態，則Oracle禁止普通用戶連接數據庫。

而擁有DBA角色的用戶，或者擁有RESTRICTED SESSION權限的用戶可以登陸數據庫。

在Oracle11g的管理員手冊文檔中有一個地方的描述錯誤：

Further, when the instance is in restricted mode, a database administrator cannot access the instance remotely through an Oracle Net listener, but can only access the instance locally from the machine that the instance is running on.

根據文檔的描述，如果數據庫處於RESTRICTED SESSION狀態，則禁止用戶採用NET服務方式登陸，而必須在服務器上直接登陸，但是測試發現，Oracle並沒有這個限制。

SQL> conn / as sysdba已連接。
SQL> alter system disable restricted session;

系統已更改。

SQL> conn test/test@test11g已連接。
SQL> conn / as sysdba已連接。
SQL> alter system enable restricted session;

系統已更改。

SQL> conn test/test@test11g已連接。

無論是在本機通過服務名方式，還是在其他客戶端通過服務名方式都可以連接到RESTRICTED SESSION狀態的數據庫，只要登陸用戶擁有RESTRICTED SESSION權限。

下面再來看看RESTRICTED SESSION狀態，對於已經登陸數據庫的普通用戶有何影響：

SQL> conn / as sysdba已連接。
SQL> revoke restricted session from test;

撤銷成功。

SQL> alter system disable restricted session;

系統已更改。

在會話1，回收TEST用戶的RESTRICTED SESSION權限，使其變爲普通用戶。並將數據庫從RESTRICTED SESSION狀態轉爲正常狀態。

下面在會話2用TEST用戶登陸數據庫：

SQL> CONN TEST/test已連接。
SQL> SET SQLP 'SQL2> '
SQL2> SELECT * FROM SESSION_PRIVS;

PRIVILEGE
--------------------------------------------------------------------------------
CREATE SESSION
CREATE TABLE
CREATE CLUSTER
CREATE SEQUENCE
CREATE DATABASE LINK
CREATE PROCEDURE
CREATE TRIGGER
CREATE TYPE
CREATE OPERATOR
CREATE INDEXTYPE

已選擇10行。

下面回到會話1，將數據庫置於RESTRICT SESSION狀態：

SQL> alter system enable restricted session;

系統已更改。

執行RESTRICTED SESSION命令很快就返回了，說明命令已經執行成功，下面嘗試普通用戶登陸：

SQL> conn test/test
ERROR:
ORA-01035: ORACLE only available to users with RESTRICTED SESSION privilege

警告: 您不再連接到 ORACLE。

登陸報錯，說明RESTRICT狀態已經生效，回到會話2，看看數據庫的RESTRICTED SESSION狀態對已經登陸的普通會話是否有影響：

SQL2> SELECT * FROM DUAL;

DU
--
X

SQL2> CREATE TABLE T1 (ID NUMBER);
CREATE TABLE T1 (ID NUMBER)
*第 1 行出現錯誤:
ORA-01536: 超出表空間 'YANGTK' 的空間限額


SQL2> CREATE OR REPLACE PROCEDURE P AS
2 BEGIN
3 NULL;
4 END;
5 /

過程已創建。

雖然建表語句失敗了，但是這時由於剛纔回收DBA角色，導致UNLIMITED TABLESPACE權限被連帶回收造成的，與RESTRICTED SESSION的狀態無關。

可以看到，雖然數據庫處於RESTRICTED SESSION狀態，但是數據庫中已經登陸的會話可以繼續執行任何操作，直到會話斷開連接。

這個現象說明，如果希望數據庫處於RESTRICTED SESSION狀態，且此時不希望普通用戶登陸數據庫，那麼最好的方法是採用STARTUP RESTRICT的方式來啓動數據庫，這樣可以確保沒有普通用戶登陸。而ALTER SYSTEM ENABLE RESTRICTED SESSION的方式雖然可以使得數據庫進入RESTRICT狀態，但是不能保證現有的連接用戶都是具有RESTRICTED SESSION權限的。即使是在STARTUP之後，馬上發出ENABLE RESTRICTED SESSION命令也是不可靠的，因爲這個時間差可能使得後臺JOB運行了。因此如果是使用ENABLE RESTRINCTED SESSION方式，還需要在後臺通過ALTER SYSTEM KILL SESSION的方式清除掉所有的普通用戶連接。

最後來看看RESTRICTED SESSION狀態和RAC環境的關係。

RESTRICTED命令是在實例上執行的，因此Oracle是否將這個命令應用到整個RAC環境需要通過測試來說明。

爲了更好的說明情況，下面的測試在一個三節點的RAC環境中進行，其中兩個節點處於啓動狀態，另一個節點關閉。

隨後在實例1上發出ALTER SYSTEM ENABLE RESTRICTED SESSION語句，檢查這個操作對實例2是否生效，將實例3啓動，檢查這個限制新啓動的實例3是否有效。

bash-2.03$ srvctl status db -d testrac
Instance testrac1 is running on node racnode1
Instance testrac2 is running on node racnode2
Instance testrac3 is running on node racnode3
bash-2.03$ srvctl stop inst -d testrac -i testrac3
bash-2.03$ srvctl status db -d testrac
Instance testrac1 is running on node racnode1
Instance testrac2 is running on node racnode2
Instance testrac3 is not running on node racnode3
bash-2.03$ sqlplus test/test@testrac1

SQL*Plus: Release 10.2.0.3.0 - Production on 星期四 2月 19 23:09:47 2009

Copyright (c) 1982, 2006, Oracle. All Rights Reserved.

連接到:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP and Data Mining options

SQL> select * from session_privs;

PRIVILEGE
----------------------------------------
CREATE SESSION
UNLIMITED TABLESPACE
CREATE TABLE
CREATE CLUSTER
CREATE SYNONYM
CREATE VIEW
CREATE SEQUENCE
CREATE DATABASE LINK
CREATE PROCEDURE
CREATE TRIGGER
CREATE MATERIALIZED VIEW
CREATE TYPE
CREATE OPERATOR
CREATE INDEXTYPE

已選擇14行。

SQL> select instance_name from v$instance;

INSTANCE_NAME
----------------
testrac1

將實例1變爲RESTRICTED SESSION狀態：

SQL> conn sys@testrac1 as sysdba輸入口令: 已連接。
SQL> alter system enable restricted session;

系統已更改。

SQL> conn test/test@testrac1
ERROR:
ORA-01035: ORACLE only available to users with RESTRICTED SESSION privilege

警告: 您不再連接到 ORACLE。
SQL> conn test/test@testrac2已連接。
SQL> select instance_name from v$instance;

INSTANCE_NAME
----------------
testrac2

顯然實例1上的設置與實例2無關，對於實例3而言其實都不用測試，因爲數據庫啓動的時候沒有指定STARTUP RESTRICT，自然不會啓用RESTRICTED SESSION狀態，不過爲了嚴謹，還是測試一下：

SQL> host
$ srvctl start inst -d testrac -i testrac3
$ exit

SQL> conn test/test@testrac1
ERROR:
ORA-01035: ORACLE only available to users with RESTRICTED SESSION privilege

警告: 您不再連接到 ORACLE。
SQL> conn test/test@testrac3已連接。
SQL> select instance_name from v$instance;

INSTANCE_NAME
----------------
testrac3

SQL> select instance_name, status, logins from gv$instance;

INSTANCE_NAME STATUS LOGINS
---------------- ------------ ----------
testrac3 OPEN ALLOWED
testrac2 OPEN ALLOWED
testrac1 OPEN RESTRICTED

對於RESTRICTED SESSION狀態，RAC環境的各個實例之間是相互獨立的，各自的狀態完全由各自的實例進行設置。


QUIESCE狀態
當數據庫處於QUIESCE狀態時，只有DBA會話可以進行操作，而普通會話會處於等待狀態，只有當數據庫退出QUIESCE狀態，普通會話才能繼續操作。

QUIESCE似乎和RESTRICT很相似，都是修改數據庫的狀態，使得DBA用戶可以進行管理操作，避免非DBA用戶同時訪問。但是二者還是有明顯的區別的。首先RESTRICT是禁止普通用戶登陸，而對已經登陸的用戶無能爲力。如果要徹底禁止普通用戶的訪問，就必須通過重啓或者手工判斷已經連接的普通會話，並執行KILL SESSION的操作。而QUIESCE並不是這樣，通過設置系統的QUIESCE RESTRICTED，使得所有的非DBA用戶處於等待狀態，不管是新登陸的還是已經存在的普通用戶會話，都無法執行新的操作，直到系統退出QUIESCE狀態。

因此QUIESCE狀態對於7*24環境是十分有幫助的，對於其他用戶而言，只是操作的等待時間變得很長，而並不會報錯。當然QUIESCE有RESTRICT所沒有的優點，也必然有一些額外的要求，那就是數據庫必須配置了資源管理Resource Management。

[oracle@bjtest ~]$ sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on 星期三 4月 22 00:25:59 2009

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

連接到:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

SQL> show parameter resource

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
enqueue_resources integer 3144
resource_limit boolean FALSE
resource_manager_plan string
SQL> alter system quiesce restricted;
alter system quiesce restricted
*
ERROR 位於第 1 行:
ORA-25507: 沒有使資源管理器一直處於打開狀態

如果資源管理器沒有打開，在9i中就會出現上面的ORA-25507錯誤。

bash-2.03$ sqlplus "/ as sysdba"

SQL*Plus: Release 10.2.0.3.0 - Production on 星期五 2月 20 00:30:49 2009

Copyright (c) 1982, 2006, Oracle. All Rights Reserved.

連接到:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP and Data Mining options

SQL> show parameter resource

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
resource_limit boolean FALSE
resource_manager_plan string
SQL> alter system quiesce restricted;

系統已更改。

而從10g開始，這個限制已經被取消了。

如果是9i，那麼必須設置resource_limit參數爲true，並設置resource_manager_plan參數指向一個資源計劃：

SQL> alter system set resource_limit = true;

系統已更改。

SQL> select plan from dba_rsrc_plans;

PLAN
------------------------------
SYSTEM_PLAN
INTERNAL_QUIESCE
INTERNAL_PLAN

SQL> alter system set resource_manager_plan = system_plan;

系統已更改。

SQL> alter system quiesce restricted;
alter system quiesce restricted
*
ERROR 位於第 1 行:
ORA-25507: 沒有使資源管理器一直處於打開狀態


SQL> shutdown immediate數據庫已經關閉。已經卸載數據庫。
ORACLE 例程已經關閉。
SQL> startup
ORACLE 例程已經啓動。

Total System Global Area 9432971568 bytes
Fixed Size 756016 bytes
Variable Size 838860800 bytes
Database Buffers 8589934592 bytes
Redo Buffers 3420160 bytes數據庫裝載完畢。數據庫已經打開。
SQL> show parameter resource

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
enqueue_resources integer 3144
resource_limit boolean TRUE
resource_manager_plan string SYSTEM_PLAN
SQL> alter system quiesce restricted;

系統已更改。

雖然修改RESOURCE_LIMIT和RESOURCE_MANAGER_PLAN參數不需要重啓數據庫，但是QUIESCE狀態的修改要求數據庫實例必須自啓動以來資源管理器一直處於打開的狀態，因此必須重啓數據庫。

當數據庫置於QUIESCE狀態下，普通用戶的新連接將處於等待狀態：

SQL> conn test/test

只有當系統撤銷QUIESCE狀態，用戶才能登陸到數據庫：

SQL> alter system unquiesce;

系統已更改。

這時TEST用戶登陸成功：

已連接。
SQL> select * from session_roles;

ROLE
------------------------------
CONNECT
RESOURCE
DBA
SELECT_CATALOG_ROLE
HS_ADMIN_ROLE
EXECUTE_CATALOG_ROLE
DELETE_CATALOG_ROLE
EXP_FULL_DATABASE
IMP_FULL_DATABASE
GATHER_SYSTEM_STATISTICS
WM_ADMIN_ROLE
JAVA_ADMIN
JAVA_DEPLOY
XDBADMIN
OLAP_DBA
PLUSTRACE

已選擇16行。

SQL> show user
USER 爲"TEST"
SQL> SET SQLP 'SQL2> '
SQL2> SELECT * FROM DUAL;

D
-
X

可以看到，和文檔描述的一樣，對於TEST用戶而言，即使擁有了DBA角色，也被QUIESCE狀態所禁止，而只有SYS和SYSTEM用戶可以對數據庫進行管理操作。

下面再次將數據庫置於QUIESCE狀態，看看對QUIESCE對已經登陸的會話是否有效：

SQL> alter system quiesce restricted;

系統已更改。

檢查第2個會話：

SQL2> SELECT * FROM DUAL;

這個會話在執行操作的時候同樣被HANG住，處於等待狀態：

SQL> select sid from v$session
2 where sql_address in
3 (select address from v$sql
4 where sql_text = 'SELECT * FROM DUAL');

SID
----------
17

SQL> select sid, event from v$session_wait
2 where sid = 17;

SID EVENT
---------- ----------------------------------------------------------------
17 resmgr:waiting in run (queued)

可以看到，會話2在等待運行，而這個事件是資源管理器所觸發的。

SQL> alter system unquiesce;

系統已更改。

再次解除QUIESCE狀態，下面看看QUIESCE對運行中操作的影響：


D
-
X

SQL2> begin
2 dbms_lock.sleep(300);
3 end;
4 /

在會話2中執行一個5分鐘長的等待事務，然後在會話1運行ALTER SYSTEM QUIESCE RESTRICTED命令：

SQL> alter system quiesce restricted;

這次QUIESCE命令也進入等待狀態，這說明QUIESCE命令會等待所有的當前操作結束，並禁止所有新的操作運行。

這也是QUIESCE和RESTRICT的差別之一，QUIESCE對所有的會話有效，而RESTRICT只對新連接的會話生效，對已經連接的會話無效。

最後還是看一下QUIESCE在RAC環境中是如何工作的。

仍然是在一個三節點的RAC環境中進行測試，其中兩個節點處於啓動狀態，另一個節點關閉。

隨後在實例1上發出ALTER SYSTEM QUIESCE RESTRICTED語句，檢查這個操作對實例2是否生效，將實例3啓動，檢查這個限制新啓動的實例3是否有效。

bash-2.03$ srvctl status db -d testrac
Instance testrac1 is running on node racnode1
Instance testrac2 is running on node racnode2
Instance testrac3 is running on node racnode3
bash-2.03$ srvctl stop inst -d testrac -i testrac3
bash-2.03$ srvctl status db -d testrac
Instance testrac1 is running on node racnode1
Instance testrac2 is running on node racnode2
Instance testrac3 is not running on node racnode3
bash-2.03$ sqlplus "/ as sysdba"

SQL*Plus: Release 10.2.0.3.0 - Production on 星期五 2月 20 01:28:39 2009

Copyright (c) 1982, 2006, Oracle. All Rights Reserved.

連接到:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP and Data Mining options

SQL> alter system quiesce restricted;

系統已更改。

SQL> select instance_name from v$instance;

INSTANCE_NAME
----------------
testrac1

使用普通用戶連接實例1：

SQL> CONN TEST/TEST@TESTRAC1

連接被掛起，下面連接實例2：

SQL> CONN TEST/TEST@TESTRAC2

實例2的連接也被掛起，看來QUIESCE會傳播到RAC環境的其他實例，那麼對於新啓動的數據庫實例是否有效呢：

SQL> host
$ srvctl start inst -d testrac -i testrac3
PRKP-1001 : Error starting instance testrac3 on node racnode3
CRS-0215: ???????????? 'ora.testrac.testrac3.inst'??

利用SVRCTL命令啓動實例3居然失敗了，下面登陸實例3所在節點，通過SQLPLUS啓動數據庫：

$ sqlplus "/ as sysdba"

SQL*Plus: Release 10.2.0.3.0 - Production on 星期二 4月 21 17:44:33 2009

Copyright (c) 1982, 2006, Oracle. All Rights Reserved.

已連接到空閒例程。

SQL> startup
ORACLE 例程已經啓動。

Total System Global Area 2147483648 bytes
Fixed Size 2031480 bytes
Variable Size 385876104 bytes
Database Buffers 1744830464 bytes
Redo Buffers 14745600 bytes數據庫裝載完畢。
ORA-25503: 無法打開數據庫, 因爲數據庫正在被靜默

錯誤已經很明顯了，雖然執行QUIESCE命令是ALTER SYSTEM語句，但是顯然QUIESCE命令對整個數據庫都是生效的，且RAC的其他實例是無法在QUIESCE狀態下啓動的。

$ exit

SQL> select instance_name, status, active_state from gv$instance;

INSTANCE_NAME STATUS ACTIVE_ST
---------------- ------------ ---------
testrac1 OPEN QUIESCED
testrac3 MOUNTED NORMAL
testrac2 OPEN QUIESCED

可以通過V$INSTANCE的ACTIVE_STATE列查看數據庫的QUIESCE狀態。

SQL> CONN SYS@TESTRAC2 AS SYSDBA輸入口令: 已連接。
SQL> ALTER SYSTEM UNQUIESCE;

系統已更改。

SQL> SELECT INSTANCE_NAME, STATUS, ACTIVE_STATE FROM GV$INSTANCE;

INSTANCE_NAME STATUS ACTIVE_ST
---------------- ------------ ---------
testrac2 OPEN NORMAL
testrac1 OPEN NORMAL
testrac3 MOUNTED NORMAL

SQL> SELECT INSTANCE_NAME FROM V$INSTANCE;

INSTANCE_NAME
----------------
testrac2

既然QUIESCE對於每個實例都生效，那麼UNQUIESCE操作也可以在任意一個實例上運行。


SUSPEND狀態
RESTRICT限制的是沒有RESTRICTED SESSION權限的用戶，使得這些用戶無法登陸數據庫。而QUIESCE針對所有的非SYS、SYSTEM用戶，禁止這個用戶的任何新的操作，包括登陸、查詢、DML等等。和RESTRICT、QUIESCE不同的是，SUSPEND主要是限制數據庫IO操作的。而且SUSPEND限制的不僅僅是普通用戶，而是數據庫中任何的用戶。

SQL> alter system suspend;

系統已更改。

在另一個終端上執行：

SQL> SET SQLP 'SQL2> '
SQL2> conn test/test已連接。
SQL2> conn / as sysdba已連接。
SQL2> select * from dual;

DU
--
X

SQL2> conn test/test已連接。
SQL2> select * from dual;

DU
--
X

SQL2> select count(*) from t;

由於數據庫已經運行了一段時間，很多數據都在緩存之中，因此無論是DBA用戶，還是普通用戶，都可以正常登陸，且都可以執行查詢操作，只要結果可以在CACHE中找到，不引起物理IO，就不會被阻塞，直到查詢引發了物理IO操作，導致會話被掛起。

SQL> alter system resume;

系統已更改。

直到執行了RESUME命令，被掛起的操作恢復執行：


COUNT(*)
----------
54020

SQL2> select * from session_roles;

ROLE
------------------------------------------------------------
CONNECT
RESOURCE

下面再次將數據庫置於SUSPEND狀態：

SQL> alter system suspend;

系統已更改。

執行剛纔被阻塞的SQL：SELECT COUNT(*) FROM T。

SQL2> select count(*) from t;

COUNT(*)
----------
54020

SQL2> delete t;

由於CACHE緩存的作用，這次查詢T表所有的IO都是邏輯IO，不會導致物理IO的產生，因此上一次被阻塞的操作，這次可以順利執行，不過隨後的DELETE操作由於要產生物理IO，因此被阻塞了。

SQL> alter system resume;

系統已更改。

執行RESUME後，DELETE操作完成：

已刪除54020行。

SQL2> select sid from v$mystat where rownum = 1;

SID
----------
155

查詢V$SESSION_WAIT的信息，並將數據庫再次置於SYSPEND狀態：

SQL> select event from v$session_wait where sid = 155;

EVENT
--------------------------------------------------------------------------------
SQL*Net message from client

SQL> alter system suspend;

系統已更改。

在會話2執行ROLLBACK操作：

SQL2> rollback;

由於ROLLBACK會導致物理IO，會話被阻塞，下面回到會話1，檢查會話2的等待事件：

SQL> select event from v$session_wait where sid = 155;

EVENT
--------------------------------------------------------------------------------
writes stopped by instance recovery or database suspension

這是寫操作被阻塞時，會話的等待事件，這個事件的名稱已經很清楚的說明了問題。

最後還是看看RAC環境下SUSPEND對不同實例的影響。

依舊是在一個三節點的RAC環境中進行測試，其中兩個節點處於啓動狀態，另一個節點關閉。

隨後在實例1上發出ALTER SYSTEM SUSPEN語句，檢查這個操作對實例2是否生效，將實例3啓動，檢查這個限制新啓動的實例3是否有效。

bash-2.03$ srvctl status db -d testrac
Instance testrac1 is running on node racnode1
Instance testrac2 is running on node racnode2
Instance testrac3 is running on node racnode3
bash-2.03$ srvctl stop inst -d testrac -i testrac3
bash-2.03$ srvctl status db -d testrac
Instance testrac1 is running on node racnode1
Instance testrac2 is running on node racnode2
Instance testrac3 is not running on node racnode3
bash-2.03$ sqlplus "/ as sysdba"

SQL*Plus: Release 10.2.0.3.0 - Production on 星期五 2月 20 19:17:04 2009

Copyright (c) 1982, 2006, Oracle. All Rights Reserved.

連接到:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP and Data Mining options

SQL> alter system suspend;

系統已更改。

SQL> select instance_name from v$instance;

INSTANCE_NAME
----------------
testrac1

現在檢查實例2上是否也會產生禁止物理IO的產生：

SQL> conn test/test@testrac2已連接。
SQL> select instance_name from v$instance;

INSTANCE_NAME
----------------
testrac2

SQL> select * from tab;

顯然實例2上的操作被阻塞了，現在啓動實例3，看看實例3上是否也會阻塞物理IO操作：

SQL> host
$ srvctl start inst -d testrac -i testrac3

SVRCTL命令居然也被HANG住了，那麼SUSPEND是否和QUIESCE一樣，禁止沒有啓動的實例啓動呢，通過sqlplus直接連接實例3：

$ sqlplus /nolog

SQL*Plus: Release 10.2.0.3.0 - Production on 星期五 2月 20 19:23:02 2009

Copyright (c) 1982, 2006, Oracle. All Rights Reserved.

SQL> conn sys@testrac3 as sysdba輸入口令: 已連接。
SQL> select instance_name from v$instance;

INSTANCE_NAME
----------------
testrac3

SQL> conn test/test@testrac3
ERROR:
ORA-01033: ORACLE initialization or shutdown in progress

警告: 您不再連接到 ORACLE。

可以看到，數據庫還沒有完全被打開，就處於被阻塞狀態了。

登陸實例3：

SQL> conn sys@testrac3 as sysdba輸入口令: 已連接。
SQL> select instance_name, status, database_status from v$instance;

INSTANCE_NAME STATUS DATABASE_STATUS
---------------- ------------ -----------------
testrac3 STARTED ACTIVE

SQL> conn sys@testrac1 as sysdba輸入口令: 已連接。
SQL> select instance_name, status, database_status from v$instance;

INSTANCE_NAME STATUS DATABASE_STATUS
---------------- ------------ -----------------
testrac1 OPEN SUSPENDED

SQL> conn sys@testrac2 as sysdba輸入口令: 已連接。
SQL> select instance_name, status, database_status from v$instance;

INSTANCE_NAME STATUS DATABASE_STATUS
---------------- ------------ -----------------
testrac2 OPEN SUSPENDED

顯然SUSPEND對所有當前運行的RAC實例生效，而新啓動的實例，數據庫狀態並非SUSPEND，而是ACTIVE，但是和文檔描述不同的是，這個實例根本無法成功的啓動，從這一點上將，SUSPEND還是會對整個數據庫起作用的。

同樣在實例1和實例2上，都可以執行RESUME命令，來恢復數據庫狀態：

SQL> conn sys@testrac2 as sysdba輸入口令: 已連接。
SQL> alter system resume;

系統已更改。


轉自：
RESTRICT、QUIESCE和SUSPEND（一）：http://yangtingkun.itpub.net/post/468/483100
RESTRICT、QUIESCE和SUSPEND（二）：http://yangtingkun.itpub.net/post/468/483165
RESTRICT、QUIESCE和SUSPEND（三）：http://yangtingkun.itpub.net/post/468/483281