使用Oracle9i的新特征-停顿(QUIESCING)数据库
2024-08-29 13:30:41
供稿：网友
原作者：sameer wadhwa
停顿(quiescing)一个数据库是一个强大的新特征，使得dba可以完成一些数据库处于受限模式(restricted mode)才能完成的一些操作。使用这个特征，当以sys或system帐户登陆后，dba可以执行查询,pl/sql，和进行其它的一些事务。而所有其它用户的会话都将处于暂停(suspended)的状态，一旦dba把数据库置回到正常模式，用户的这些会话又将会自动继续运行了。
图 1a:数据库处于正常状态 .
图 1b: 数据库处于状态.
图1a是数据库处于正常模式的系统状态，在这种模式中dba和用户的事务都是运行着的。一些dba的事务是被限制着的，因为数据库必须处于受限模式时才可以运行这些事务。相反的方面，图1b是数据库处于停顿状态的情况，在图中，所有用户的事务都是被阻塞(blocked)着的，而没有重启数据库到受限模式，dba的事务也毫无问题的运行着。
一旦所有活动的会话都执行了commit或rollback，数据库将会被停顿。
让我们看一下它是如何进行的。停顿数据库所用的主要的命令为alter system quiesce restricted;我将首先使用sqlplus登陆执行这个操作。
c:/> u:/>sqlplus /nolog
sql*plus: release 9.2.0.1.0 - production on wed apr 16 16:08:27 2003
copyright (c) 1982, 2002, oracle corporation. all rights reserved.
sql> connect sys/change_on_install as sysdba
connected.
sql> alter system quiesce restricted;
alter system quiesce restricted
*
error at line 1:
ora-25507: resource manager has not been continuously on
如上的错误表明资源管理器(resource manager)是非活动的，要使它活动你可以这样：
sql> alter system set resource_manager_plan='system_plan' scope=spfile sid='or9i';
system altered.
or9i 是我的sid.
做完这个操作你不得不重启一下数据库了。
sql> show parameter resource_manager_plan
name type value
------------------------------------ ----------- ----------------
resource_manager_plan string system_plan
sql> alter system quiesce restricted;
system altered.
如果有一些未决的事务需要提交或回滚的话，先前的那条命令将会挂起而等待事务的完成。如想确定是哪些用户的会话没提交或回滚，你可以用如下的语句。
select s.sid,s.serial#,s.machine,s.terminal,s.username
from v$session s where s.sid in
(select sid from v$lock where type='tx')
/
查询的结果将会提供充足的信息使你能够要求那些用户提交、回滚或终止他们的事务。更坏一点的情况是你可以杀掉这些会话，会话将被被自动回滚。系统处于停顿状态后，你就可以不受其它用户的干扰进行工作了，完成工作后你可以用如下命令解除这种停顿的状态：
sql> alter system unquiesce;
system altered.
情景1:
事务顺序
用户会话
dba 会话
(1)
connected with scott
sql> update emp3 set
ename='john'
where ename='samir';
connected with sys
(2)
sql> alter system quiesce restricted;
等待用户scott完成事务.
(3)
sql> commit;
commit complete.
(4)
system altered.
第一种情景表明，在所有活动的事物完成前dba是不能停顿数据库的。一旦数据库停顿了，库对其它的用户呈现的是停止(halt)或非活动(inactive)的状态。然后当数据库变为正常状态后，所有的数据块和暂停的事务又继续运行了。
情景 2:
事务顺序
用户 会话
dba 会话
(1)
connected with scott user .
connected with sys.
sql> alter system quiesce restricted;
system altered.
(2)
select * from emp;
wait for result
(3)
sql> alter system unquiesce;
system altered.
empno ename salary
--------- ---------- ----------
1 sasa 1000
2 john 5000
3 hema 7000
user can see the results.
情景2表明它如何影响了用户的会话。简而言之，此时系统对于最终用户是临时的无效。
通常的一些问题:
(q)做为dba的你如何检查你的数据库是什么状态呢？
(a)你可以检查v$instance视图中的active_state这上字段。
sql> select active_state from v$instance;
active_st
---------
normal
active_state有如下几个可能值：
active_state
描述
normal
数据库处于正常状态
quiescing
database wants to quiesced but waiting for active running transactions to finish.
数据库要想停顿，但要等待活动的运行事务完成。
quiesced
数据库处于停顿的状态了.
(q)怎样确定哪些连接着库的会话在等待停顿着的数据库呢?
(a)可以用如下的查询来确定:
select sid,event,total_waits,time_waited "time waited[100 of sec]",
average_wait from v$session_event
where event='wait for possible quiesce finish'
/
sql>
sid event total_waits time waited[100 of sec] average_wait
--- ---------------------------------- ----------- ----------------------- ------------
6 wait for possible quiesce finish 412 126532 307
"wait for possible quiesce finish"这个事件表明会话正等着“正停顿”的数据库以至于它不能进行它的事物。库停顿后这些会话将呈现hung的状态。
(q)在停顿数据库之前,对于资源管理器计划(resource manager plan) 需要做什么设定？
(a) 当你停顿了数据库，internal_quiesce资源计划被激活了。除sys_groups其它所有的资源组中的active_sess_pool_p1应被设置为0。因sys和system用户都属于sys_groups组，所以只有它们可以连接到数据库。
要查看细节的信息可以查询dba_rsrc_plan_directives这个视图。
记着如下几点：
处于停顿状态的数据库只有sys和system是有效的用户来执行维护的工作；其它有dba权限的用户也被视为一般的用户。 在停顿的数据库中备份数据文件(泠备，拷贝数据文件)是无效的。如果库中有“活动”的事务，库是不能被停顿的。.
需要启动数据库以设置资源计划
停顿数据是9i的新特征，因此之前的版本中是不能用的。
结论：
停顿数据库是一个强大的特征使dba不必重启数据库就可以执行一些特别的维护工作。
