資料庫的三種狀態RESTRICT、QUIESCE和SUSPEND

在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環境的各個例項之間是相互獨立的，各自的狀態完全由各自的例項進行設定。

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;

系統已更改。