ITPub博客

首页 > Linux操作系统 > Linux操作系统 > RESTRICT、QUIESCE和SUSPEND(二)

RESTRICT、QUIESCE和SUSPEND(二)

原创 Linux操作系统 作者:yangtingkun 时间:2009-04-23 22:12:51 0 删除 编辑

数据库的这三种状态有相似之处,这里简单总结一下。

这一篇介绍QUIESCE状态。

RESTRICTQUIESCESUSPEND(一):http://yangtingkun.itpub.net/post/468/483100

 

 

当数据库处于QUIESCE状态时,只有DBA会话可以进行操作,而普通会话会处于等待状态,只有当数据库退出QUIESCE状态,普通会话才能继续操作。

QUIESCE似乎和RESTRICT很相似,都是修改数据库的状态,使得DBA用户可以进行管理操作,避免非DBA用户同时访问。但是二者还是有明显的区别的。首先RESTRICT是禁止普通用户登陆,而对已经登陆的用户无能为力。如果要彻底禁止普通用户的访问,就必须通过重启或者手工判断已经连接的普通会话,并执行KILL SESSION的操作。而QUIESCE并不是这样,通过设置系统的QUIESCE RESTRICTED,使得所有的非DBA用户处于等待状态,不管是新登陆的还是已经存在的普通用户会话,都无法执行新的操作,直到系统退出QUIESCE状态。

因此QUIESCE状态对于7*24环境是十分有帮助的,对于其他用户而言,只是操作的等待时间变得很长,而并不会报错。当然QUIESCERESTRICT所没有的优点,也必然有一些额外的要求,那就是数据库必须配置了资源管理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_LIMITRESOURCE_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状态所禁止,而只有SYSSYSTEM用户可以对数据库进行管理操作。

下面再次将数据库置于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命令会等待所有的当前操作结束,并禁止所有新的操作运行。

这也是QUIESCERESTRICT的差别之一,QUIESCE对所有的会话有效,而RESTRICT只对新连接的会话生效,对已经连接的会话无效。

最后还是看一下QUIESCERAC环境中是如何工作的。

仍然是在一个三节点的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$INSTANCEACTIVE_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操作也可以在任意一个实例上运行。

 

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/4227/viewspace-591661/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
暂无介绍

注册时间:2007-12-29

  • 博文量
    1955
  • 访问量
    10437564