使用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不必重啟數據庫就可以執行一些特別的維護工作。
