数据库的三种状态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状态时，只有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操作也可以在任意一个实例上运行。

 

---

---

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;

系统已更改。