【摘要】系統管理者是否遇到過執行某個大資料量統計報表查詢或者進行全庫RMAN備份的時候，導緻整個HIS系統的操作變慢甚至影響正常業務使用的情況，其實這是典型的伺服器資源争用和等待的案例，如何合理的配置設定和管理有限的伺服器資源，讓更重要的業務更充分的利用資源，這是本文Oracle資源管理所實作的功能。
關鍵詞：Oracle，資源管理
1. 前言
衆所周知，業務系統的任何操作都需要消耗伺服器資源，當一個伺服器部署完成後，其總的可利用資源是一個有限值，所有的業務操作資源消耗都需要在這個範圍内進行配置設定，如果同一時間業務對資源的消耗超過了伺服器資源供給，勢必會出現資源争用和等待，更為嚴重的時候，這個時候前台應用最直覺的表現就是’慢’，更嚴重的後果這種争用和等待可能導緻整個伺服器性能急劇下降，出現性能問題，甚至導緻伺服器當機。
最近幾年，中聯使用者随着業務量增大和資訊系統應用深入，對伺服器的資源需求也越來越大，醫院除了加大硬體投入逐漸提高伺服器的性能，增加伺服器資源外，對資源的管理和配置設定完全依賴于作業系統的動态适應，這勢必帶來一些不合理的情況，如果讓這些資源的管理和配置設定更加合理，這也是資訊系統管理值得思考的問題。
1.1. 影響HIS系統的資源
資源是一個比較籠統的概念，它指可進行處理以更改應用程式行為的計算系統的任何方面。是以可以說資源就是應用程式隐式或顯式請求的功能，如果拒絕或限制了此類功能，則應用程式就會無法執行或者變慢，例如是當伺服器程序數很多時，作業系統程序和資料庫服務程序間的來回切換會導緻CPU占用率或記憶體使用率高，這時候整個伺服器反應就會變慢，這就是我們常說的資源消耗。
ZLHIS系統是一個複雜的業務應用系統，其依托于Oracle資料庫部署在伺服器上，是以伺服器上任何一個對HIS系統的運作起到至關重要的影響都可以說是HIS系統的資源，這類資源可以簡單的分為硬體和非硬體兩類，我們這裡說得資源特别指非硬體類，比較常見有CPU使用率、記憶體消耗、IO操作以及網絡等等。這些資源相對獨立又互相關聯，任何一點出現瓶頸都可能影響整個HIS系統業務的運作。
HIS系統的每個會話操作可以定義為一個‘業務’，整個HIS系統是一個業務系統的集合，其中的每個業務生命周期内會對資源的總體需求是不同的，而且這種需求也不是平均，可能某個時間點特别需要資源，其它時間又相對資源的需求不是很強烈，如下圖是某三甲醫院整點CPU使用率的采樣，從中可以大緻看出一天内（24小時）HIS系統對CPU資源的需求概況。
圖1：某醫院一天CPU使用率采樣
從上圖可以看到HIS系統對CPU資源的需求是波動的，同樣的道理對其它資源如記憶體、IO操作需求也是一樣，都不會是平穩不變，而是根據業務操作的不同進行波動，這些業務的重要程度各不相同，比如我們最看重的是視窗業務，如門診收費、住院結賬、記賬、醫囑發送等，這些業務直接影響醫院醫療效率和收入，應該保證有最充足的資源擷取，而另外一些業務，如資料統計、資料備份、後勤業務等重要程度相對偏低，但是往往其對資源的消耗又比較大，這樣就産生了一些沖突，如果這些業務同時進行，勢必會影響重要業務對資源的擷取，如何讓最重要的業務有充足的資源使用、其它業務的運作不對其資源造成影響，讓資源的利用盡可能的平穩，合理有效的配置設定和利用資源，就是資源管理所要達到的目的。
1.2. 常用的資源管理方法
作業系統對資源的配置設定和回收是完全動态的，取決于業務請求的先後順序，作業系統會盡可能的滿足請求的資源，一旦資源被先請求的業務占用，後面的業務在擷取資源不充足的情況下，隻有等待之前的業務釋放資源。這就會出現兩個問題：1.業務請求的資源過多，将資源耗盡；2.資源被占用，重要業務無法擷取資源，隻有等待；以上兩種情況都是我們不想看到的，但是作業系統又無法避免，這就需要管理者對資源進行管理，目前醫院常見的管理方式有以下幾種：
l 人為計劃管理
這是最簡單、最直覺的一種管理方式，把對資源消耗多、重要性偏低的業務放在相對空閑的時間段進行，如系統備份、費用彙總表、資料采樣等，這些操作對資源的需求高、但是時效性要求相對低，一般情況下醫院都把這些操作放在晚上通過計劃任務進行，因為對醫院來說晚上正常業務如收費、記賬、醫囑等業務量比較小，這時候空閑資源相對較多，能夠滿足備份操作都業務的資源需求，同時這些操作對正常業務的影響在這個時間段也相對較少。
l 第三方軟體管理
現在虛拟化技術越來越多的得到應用，通過虛拟化軟體，能夠把多台伺服器資源進行整合，達到資源共享的目的，類似的軟體比較多，比較常見的如VMware vSphere虛拟化管理軟體，其就是通過虛拟化技術，把多個伺服器的資源整合為一個資源池，所有的業務操作所需的資源都是通過資源池進行管理和配置設定，其能夠根據業務劃分和資源的排程對資源進行合理的配置設定，達到合理利用，這也是現在比較推崇的一種管理模式。
l 概要檔案資源限制
除了上面的兩種方式，Oracle還有個概要檔案，其可以對指定的使用者連接配接操作的資源進行限制，如下圖：
通過概要檔案，限制非重點業務使用者對資源的使用，也就間接控制了資源的配置設定，進而讓更重要的業務優先和最大程度的使用資源。
1.3. 存在那些問題
這些常見的資源管理方式其都能對伺服器資源進行一定的管理和配置設定，但是針對HIS伺服器特有的業務環境，其也存在一些顯而易見的問題，主要表現在以下幾點：
l 管理局限
雖然有些業務可以通過人為的計劃調動進行時段的配置設定，但是另外一些業務如報表查詢統計、瞬時的大資料過濾、頻繁的輪詢查詢等，這些沒有特定的操作規律，根本無法通過使用者方式進行控制，還有就是針對一些Oracle資料庫的特有資源，例如：并行執行的服務數和活動的會話數等，這些管理都無法實作。
l 低效管理
利用作業系統管理排程資料庫服務本身就占用一定的資源，最直接的其會占用CPU資源，而這些個資源是非常有限，而且效率還非常的低，當出現資源瓶頸後進而導緻保持闩鎖的資料庫伺服器程序會暫停，而且其從發現資源出現瓶頸到進行管理重新配置設定，這個時間過程也會比較長，在三甲醫院高峰期視窗關鍵業務中，這樣的業務暫停和等待是不可接受的。
l 成本過高
虛拟化雖然能夠對業務的動态操作進行管理，但是其高昂軟體的價格和部署成本對醫院來說确實接受起來非常困難，另外虛拟化資源間互相的影響也非常大，常常出現‘木桶效應’，這也是為什麼很多Oltp系統不願意建構在虛拟化環境中的原因。
Oracle 資源管理（Oracle DatabaseResource Manager，簡稱DBRM）通過它的管理把硬體等資源的配置設定交給資料庫伺服器本身來解決以上問題，在某個資料庫環境中，可能同時存在着多個使用者請求資料庫服務，并且他們所要完成的任務優先級不同，那麼我們就應該差別對待這些會話請求。Oracle RMDB能讓你根據各個會話的應用屬性，将它們分組，然後為每組配置設定不同的資料庫資源，最大化提高你的資料庫應用性能。
2. oracle資源管理（RMDB）
2.1. 概述和特點
Oracle 資源管理用于管理混合的工作量，控制系統的性能，與通常隻通過作業系統管理資源相比，可以對計算機資源的配置設定進行更多的控制，其最大的特點就是通過分組模式，把會話按照一定優先級進行分組，分成若幹的使用者組，再以組為機關對其進行資源的配置設定和限制，例如下圖把HIS使用者根據操作的業務屬性的不同分為視窗使用者組、醫技使用者組、後勤使用者組，再結合其業務特點和重要性按優先級和份額對資源進行配置設定，如下圖：
當然這樣的組配置設定資源的規則也不會一成不變，通過控制資料庫内部的執行排程，達到控制資源在各個會話之間的動态分布，確定資源分布與業務的實際需求相比對。是以利用資料庫資料總管，無論系統的負載和使用者的數量如何，都可以保證使用者組的處理資源達到要求，滿足業務的需求，資源管理是怎麼實作這種動态的配置設定的呢？其主要通過資源計劃和資源計劃指令實作，通過其同資源使用者組的配合，達到靈活的動态管理資源的目的，這三者的關系如下：
“資源使用者組”：定義了具有相似的系統或資料庫資源使用需求的一組使用者或會話。
“資源計劃指令”：指定如何在使用者組或子計劃之間共享某個特定資源。通過計劃指令，可以将資源使用者組及子計劃與特定的資源計劃關聯起來。
“資源計劃”：指定如何在各個資源使用者組之間配置設定資源。使用資料庫資料總管還可以在計劃中建立計劃，這稱為“子計劃”。
其中資源計劃指令和資源計劃共同組成了對資源使用者組的“資源配置設定方法”，确定配置設定任何特定資源時使用的政策。
2.2. 資源管理的内容
Oracle資料總管相對于其它方式的資源管理，除了管理伺服器資源外，還能夠對資料庫内部的資源進行管理，這一點就大大增強了其管理能力,總結下來其可以管理資料庫和作業系統資源主要包括如下：
1. 作業系統資源：
• CPU 使用率：可以指定在使用者組和子計劃之間如何配置設定CPU 資源。
•I/O限制: Oracle資料總管通過執行一個I/O密集的隻讀工作量來評估資料庫伺服器的存儲系統的I/O性能，這個評估操作應該在非業務高峰期間執行，以確定校準不影響生産的工作量，以及生産的工作量對校準結果的影響，使用者組可以基于I/O閥值(最大請求數或M位元組)進行資源組自動切換。
• 活動會話數限制：可以限制使用者組或子計劃的并發活動會話數。如果某個組的會話數超過了允許的最大值，則新的會話将放在隊列中，等待某個活動會話完成。
2. 資料庫資源：
• 并行度限制：Oracle的并行機制可以把一個大操作分割成若幹小操作進行，進而提升運作速度，但是并行本身也是一種資源消耗， Oracle資源管理可以控制使用者組中任何操作的最大并行度，對這種資源消耗進行限制。
• 還原池：可以控制使用者組或子計劃能夠生成的還原操作的總數。當還原空間的總數超過UNDO_POOL指定的數量時，在同一組中其它會話釋放還原空間或者增大使用者組的還原池之前，不允許執行任何新的INSERT、UPDATE或DELETE指令。如果使用者組在執行DML 語句時超過了限額，則中止操作并傳回錯誤。此時仍可進行查詢，即便使用者組已經超出其還原門檻值。
3. 時間資源：
• 執行時間限制：可以指定操作所允許的最大執行時間。Oracle DB 使用基于成本的優化程式統計資訊來估計操作所需的時間。如果耗時超過了所允許的最大時間(MAX_EST_EXEC_TIME)，則操作傳回錯誤并且不會啟動。如果資源使用者組有多個指定了MAX_EST_EXEC_TIME的計劃指令，則資料總管将選擇所有傳入值中限制性最強的那個值。
• 空閑時間限制：可以指定會話的空閑時間，超過該時間後将終止會話(MAX_IDLE_TIME)。你可以進一步限制資料總管，使其隻終止阻止其它會話的會話(MAX_IDLE_TIME_BLOCKER)。
4. 使用者組資源：
• 使用者組切換：初始使用者組是在會話剛登入時所屬的組。頂層調用被定義為将整個PL/SQL 塊視為一個調用，或類似地，将客戶機單獨發出的SQL 語句視為單獨調用。在中間層伺服器實施會話共享的三層應用模型中，此功能的優勢是最顯而易見的。在這種情況下，中間層在為某個最終使用者執行一個調用後，可使用相同的會話為另一個最終使用者執行調用。是以，工作的分界線實際上為調用，并且上一個最終使用者的操作不會影響下一個最終使用者。可以建立一個計劃指令，使資料總管在頂層調用結束時将使用者自動切換回初始使用者組。
要想對應用的資源合理的配置設定和控制，以上的資源管理都不能單一的進行，隻有通過合理的搭配，資源間互相配合，才能達到真正的有效管理的目的，而這些組合和配合則需要通過‘資源計劃指令’和‘資源計劃’實作。
2.3. 資源管理的具體功能
Oracle資料總管就是為Oracle使用者配置設定使用者組，然後通過該使用者組設定對應的‘資源計劃’和‘資源計劃指令’，通過其合理的組合，可以實作對資源的靈活控制和管理，結合上面資源管理可以管理的資源，我們來看下Oracle資源管理具體可以實作那些功能：
1. 資源限制功能：
可以在系統啟動時，限制某些會話請求隻配置設定到最少的程序資源和使用者使用上限。
限制同一組内使用者對資料庫操作的并行度。
建立一個活動的會話池。會話池由一組使用者活動會話組成，對某一組使用者來說，同一時間活動的會話數有特别的數量上限。如果會話池滿了，新的會話請求會被放入等待隊列，而且你還可以設定一個時間上限，超過這個上限，等待隊列會被停止。會話池限制了同一時間活動的會話請求數量，保證了活動的會話請求更快的完成任務。
限制一個會話的空閑等待時間。
2. 資源配置設定功能：
為不同的使用者或應用配置設定不同的CPU時間。在HIS應用中，門診業務的CPU使用率的優先級應該最高，任何操作如報表查詢、備份等都不能影響門診業務的使用。
管理長時間未響應的會話或請求，這些會話或請求往往占用了很多的CPU或I/O資源。這些會話能被自動的結束掉，或者将它們換到其他低級的組去。
根據不同的資源配置設定需求，配置不同的模式。你可以動态的改變這些模式，例如，從白天運作模式變到夜間運作模式，而不用重新開機資料庫服務。你還可以通過Oracle排程器來管理模式的改變。
3. 資源消耗估算：
Oracle資源控制器還有一個最大的功能就是可以對一些資源消耗進行估算，根據估算結果對使用者進行一些控制，進而不必真正在運作過程中發現資源瓶頸，如通過優化器估算請求的運作時間，如果超出了某個限制，Oracle資料總管會阻止它的請求。
以上就是Oracle資料總管能夠實作的幾大功能，不過要想在實際過程中對HIS應用資源進行合理的管理，我們還要了解這些功能實作的具體細節和方式，以及對它們合理的運用群組合，才能實作真正的有效管理的目的。
2.4. 資料總管的組成元素
我們前面介紹了，Oracle資源管理主要由資源使用組，資源計劃和資源計劃指令三個部分構成，這也是資源管理構成的三個主要的元素，接下來我們就分别對這三個元素進行介紹。
l 資源使用組（Resource Consumer Groups）
資源使用組是由許多使用者會話組成，這些會話有相同的資源使用請求。新建立一個會話時，資料總管會自動或者根據你的指定把它配置設定到某個組，你可以對這個組進行資源限制和配置設定，進而對該組的所有會話進行配置，一個使用者可以隸屬于多個組，但一個會話同一時間隻能隸屬于一個組，Oracle資管理器中預設有三類特别的組是系統組，它們不能被修改或删除，它們的名稱和所起的作用如下表：
| 組名稱 | 作用 |
| SYS_GROUP | 所有通過SYS和SYSTEM使用者建立的會話的預設組，它可以設定會話資源使用規則。 |
| DEFAULT_CONSUMER_GROUP | 所有非SYS和SYSTEM使用者建立會話的預設組，它可以設定會話資源使用規則，但是不能設定命名資源計劃指令。 |
| OTHER_GROUP | OTHER_GROUP不能算是一個獨立的資源使用者組，準确的說應該算是資源使用組其它原則，目前非活動資源計劃的會話都屬于該資源使用組，它必須有一個資源計劃指令中指定每一個計劃。 |
除了以上三個系統預設的資源使用組，使用者可以根據自己的需要，建立其它符合業務會話需求的資源使用組，這些組可以單獨的命名，然後将相關的會話配置設定到該組中即可。
l 資源計劃指令（Resource Plan Directives）
資源計劃指令指定了資源計劃和使用組之間的映射關系。同時通過存儲過程來實作對資源的配置設定和限制的功能，如可以通過指令給對應的資源使用組配置設定一定百分比的總的CPU時間，或者限制一個組内最大活動的會話數等，資源計劃和資源計劃指令間有着一對多的關系，當然為了避免沖突資源計劃中不能包含兩條相同的資源計劃指令，但是它可以包含多個不同資源的配置設定指令。
l 資源計劃（Resource Plan）
包含一系列指令，這些指令決定了每個使用者組的資源使用配置設定，在一個資料庫中，同一段時間内隻能啟用一個資源計劃，但一個資源計劃裡面可以包含多個子資源計劃，每個資源計劃都必須包含給OTHER_GROUP配置設定的指令，如下圖就是一個包含子計劃的CPU使用率限制資源計劃的例子。
可以看到，‘SALES_TEAM plan’是‘GREAT BREAD plan’子計劃，其對應的是‘WHLESALE group’使用組，它的50%CPU的使用率限制是整個資源計劃60%的使用限制而定，也就是這裡的50%CPU其實最多也就是整個伺服器30%CPU的使用率。
3. 典型的資源管理建立
那麼說了這麼多，如何來建立一個人資源管理模型呢？Oracle提供了兩種方式，一種是通過EM建立，圖形界面，操作直覺而且簡單，另外就是通過DBMS包建立，這個相對比較麻煩，要對一些參數有所了解才行，下面我們就示範下2種方式建立資源管理的過程。
3.1. 通過EM建立
以SYS使用者登入資料庫的EM，确認連接配接執行個體，點選【伺服器】，就可以看到資源管理操作選項，如下圖
這裡有【入門】、【使用者組】、【使用者組映射】、【計劃】、【設定】、【統計資訊】6個選項，我們首先點選【入門】選項，這裡面對資料總管的作用和其它5個選擇的作用作了簡單的說明，如下：
通過這裡的介紹，我們大緻知道每個選項的功能，接下來我們就點選【使用者組】開始建立使用者組，點選進去後進入如下主界面，這裡面已經有了很多系統初始化建立的使用者組，如AUTO_TASK_CONSUMER_GROUP、BATCH_GROUP等等，這些使用者組的作用在‘說明’列中有簡單的介紹，不過我們從中可以看出，資源管理其實預設在資料庫建立後就已經在使用，如晚上的統計資訊收集、SQL自動調優等，都是建立了資源使用者使用組，隻是我們日常管理中沒有留意而已。
這裡我們點選<建立>按鈕，進入資源使用者組建立界面，如下圖，當然這裡可以選擇類似建立或者生成DDL語句建立，這個根據使用者自己的需求選擇，在使用者組輸入建立組的名稱，說明那裡對組進行簡單的說明，可以把角色添加到該組中，也可以通過把使用者添加到該組中，如下
在允許在該使用者組中運作的使用者那裡點選<添加>，為該組添加使用者，如下
當然也可以按角色添加，如下
除了上面在建立使用者組的時候，就通過使用者和角色指定那些對象屬于這個使用者組之外，還可以通過會話的方式來指定，需要在【使用者組映射】中設定，這裡提供了6種映射資源使用者的方法。這6種映射方法分别是：
oracle使用者：指定通過某個特定作業系統使用者登入到資料庫所産生的session屬于某個使用者組；
客戶機作業系統使用者：指定某個特定的用戶端計算機名稱登入的資料庫所産生的session屬于某個使用者組；
客戶機程式：指定某個應用程式登入到資料庫所産生的session屬于某個使用者組。
服務：指定通過某個服務名登入到資料庫所産生的session屬于某個使用者組；
子產品：指定通過特定子產品登入到資料庫所産生的session屬于某個使用者組；
子產品和操作：指定通過特定子產品并執行特定動作登入到資料庫所産生的session屬于某個使用者組。
我們可以在這裡按照HIS系統運作的一定的規則，把對應的會話指定到不同的使用者組中，你可以通過使用者，也可以通過機器名稱還可以通過子產品和操作等等，注意到這裡有個【優先級】，就是有可能你設定的條件有沖突的情況，比如U00001使用者在住院的機器上登入，如果你通過使用者名映射的門診視窗使用組，通過計算機機器名映射的住院使用者組，那這時候就要根據優先級來判斷該會話到底是屬于那個資源組，預設情況下，使用者的優先級是6，客戶機的優先級是9，這個時候就要以優先級更高的使用者為準。
對會話進行了資源組的配置設定，接下來就是要對資源組的資源進行管理，這就需要設定資源計劃，我們進入【資源計劃】界面，如下：
點選【建立】，進入資源計劃建立界面，添加你想建立的計劃的名稱和說明，然後就是對資源進行配置設定，當然首先要對應資源使用者組，預設情況下隻有一個系統必須的OTHER_GROUPS,點選【修改】按鈕，添加上對應你的資源組，如這裡添加我們之前建立的視窗使用者組，然後就需要對資源進行配置設定，【一般資訊】這裡是對CPU的配置設定，有2種模式百分比和進階，如下：
百分比這個比較簡單，我們重點講下進階，如果選擇進階，在資源計劃中我們一共可以設定8個CPU使用的優先級，級别1為最高，級别8為最低，如下
注意，在不同級别中CPU的總額不能超過100%。同時，隻有在CPU使用率達到100%的時候，這裡指定的不同級别所使用的CPU百分值才會生效。也就是說，即使系統完全空閑時，那麼Other_Groups的使用者登入系統一樣也可以使用100%的CPU。而如果當Other_Groups使用者在執行操作過程中‘視窗使用者組’使用者登入資料庫，造成系統CPU滿負荷運轉。那麼Oracle會優先為‘視窗使用者組’配置設定CPU，隻有當‘視窗使用者組’執行完畢後才會為other_group組成員配置設定CPU。
拿上面的例子來說，假設‘視窗使用者組’消耗了系統的50%，那麼‘住院使用者組’和‘後勤使用者組’就隻能使用剩下的50%的資源，然後在這個50%的基礎上，再進行配置設定，也就是配置設定能使用 40%和10%的CPU資源，如果‘住院使用者組’和‘後勤使用者組’已經完全使用了這些資源，那麼作為下一級LEVEL 3的OTHER_GROUPS将不會獲得任何CPU的資源。當‘視窗使用者組’、‘住院使用者組’和‘後勤使用者組’總過隻消耗了5%的CPU資源，那麼作為下一級LEVEL 2的OTHER_GROUPS将會可以消耗95%的CPU資源。
換句話說，LEVEL 2所能獲得的全部資源就是LEVEL 1所未能使用的那部分資源。
優先級：LEVEL1 > LEVEL 2 > LEVEL 3……LEVEL N-1>LEVELN
需要強調的一點是OTHER_GROUPS這個資源使用者組。任何一個資源計劃必須要包括這個OTHER_GROUPS使用者組，如果你的資源計劃沒有包括這個使用者組，那麼将會得到一個ORA-07453的錯誤，要求你必須添加此使用者組。這個使用者組的作用就是作為一個候選項，當一個沒有比對到任何資源使用者組的SESSION連接配接到資料庫的時候會自動的比對到OTHER_GROUPS下面，按照OTHER_GROUPS的資源限定執行SQL。
另外一個需要強調的是使用者資源限定的生效條件。拿上面的例子來說，當系統的CPU使用率沒有達到100%的時候，‘視窗部門資源計劃’這個資源計劃并不會生效，各個資源使用者也不會按照限定來配置設定CPU的使用。僅僅當CPU的使用率為100%的時候，資源計劃才可以發揮功效，來限制各個資源使用者組的CPU配置設定。這點是常常被大家忽略的，一定特别注意下。
除了CPU的資源配置設定，還有【并行度】、【會話池】、【還原池】、【門檻值】和【空閑時間】的設定，如下為我對‘視窗部門資源計劃’的案例資源配置設定設定情況，整體預覽如下：
在日常管理過程中，如果有EM的話，肯定可以非常直覺的看到我們資源管理計劃的詳細情況，如果沒有EM方式，建議大家制作一個如下的表格，可以一目了然的展示目前資源管理的設定情況，如下：
| 組或子計劃 | CPU資源 | |||||
| Level 1 | Level 2 | Level 3 | 組切換 | 最大并行度 | 最大會話數 | 最大空閑時間 |
| 視窗使用者組 | 100 | 終止會話 | 1 | 100 | 600 | |
| 住院使用者組 | 80% | 終止會話 | 1 | 100 | 3600 | |
| 後勤使用者組 | 20% | 切換到：OTHER_GROUPS | 1 | 400 | 3600 | |
| OTHER_GROUPS | 100 | 無限制 | 無限制 | 無限制 |
最後就是把該計劃激活，這裡已啟用自動計劃切換，是指可以通過oracle内部的作業調動，使資料庫在多個資源計劃中進行切換，這裡要注意，一個時間段oracle隻能有一個資源計劃為激活狀态，當然，該資源計劃可以包含若幹子計劃，這裡我們就不再示範，計劃的操作非常簡單，如下
一個典型的資源管理建立就完成了，我們可以通過查詢v$session會話視圖，來觀察下目前資料庫會話屬于那個資源組，可以看到U000001按照我們之前的映射，屬于視窗使用者組，而且其它沒有映射的使用者，預設會屬于OTHER_GROUPS組，如下：
3.2. 通過DBMS包建立
除了通過EM建立資源管理以外，還可以通過DBMS_RESOURCE_MANAGER包在指令模式下進行建立，執行這個包的使用者必須要有ADMINISTER_RESOURCE_MANAGER權限，這個包常用的功能介紹如下：
| Procedure | Description |
| CREATE_SIMPLE_PLAN | 建立一個簡單的資源計劃,包含8個使用者組,在一個步驟中完成。這是開始使用Oracle資料庫資料總管最快的方式。 |
| CREATE_PLAN | 建立一個資源計劃,并指定它的配置設定方法。 |
| UPDATE_PLAN | 修改一個資源計劃 |
| DELETE_PLAN | 删除資源計劃和指令。 |
| DELETE_PLAN_CASCADE | 删除資源計劃和及其它的子計劃。 |
| CREATE_CONSUMER_GROUP | 建立一個使用者使用組 |
| UPDATE_CONSUMER_GROUP | 修改使用者使用組 |
| DELETE_CONSUMER_GROUP | 删除使用者使用組 |
| CREATE_PLAN_DIRECTIVE | 指定資源計劃指令,配置設定資源資源消費者團體或一個計劃的子計劃。 |
| UPDATE_PLAN_DIRECTIVE | 修改計劃指令 |
| DELETE_PLAN_DIRECTIVE | 删除計劃指令 |
| CREATE_PENDING_AREA | 建立一個等待區，還可以更改計劃模式 |
| VALIDATE_PENDING_AREA | 驗證變更等待區計劃模式 |
| CLEAR_PENDING_AREA | 清除所有未決變更等待區 |
| SUBMIT_PENDING_AREA | 送出所有更改計劃模式 |
| SWITCH_CONSUMER_GROUP_FOR_SESS | 切換的使用者組特定的會話 |
| SWITCH_PLAN | 設定目前的資料總管的計劃 |
| SET_CONSUMER_GROUP_MAPPING | 會話映射到使用者組 |
| SET_CONSUMER_GROUP_MAPPING_PRI | 建立會話屬性映射的優先事項 |
從上面的介紹可以看到，如果我們是要建一個最簡單的資源管理計劃，使用一個CREATE_SIMPLE_PLAN就可以實作，但是這個簡單的計劃隻限制CPU的使用，顯然很多時候我們不光要限制CPU還需要限制其它的資源，下面我們就利用包來進建立一個典型的資源管理計劃，要想建立資源管理計劃，至少要經過下面幾個步驟：
Step 1: 建立一個等待區（pendingarea）.
Step 2: 建立、修改或者删除一個使用者使用組
Step 3: 建立一個資源計劃
Step 4: 建立資源計劃指令
Step 5: 驗證等待區（pendingarea）
Step 6: 送出等待區（pendingarea）
這裡我們看到有所差別，第一步就是要建立一個等待區（pending area）,什麼是等待區？等待區是一個暫存區域,您可以建立一個新的資源計劃,更新現有計劃,或删除一個計劃不影響目前正在運作的應用程式。當您建立一個等待區、資料庫初始化,然後把現有計劃複制到等待區,這樣現有計劃就可以更新。等待地區做出更改後,您驗證等待區域,然後送出。送出後,所有未決變更應用到資料字典,和等待區域清理幹淨并停用。
如果您嘗試建立、更新或删除一個計劃(或建立、更新或删除使用者組或資源計劃指令)沒有首先建立等待區,就會收到一條錯誤消息。
送出等待區域并不激活您所建立的任何新計劃;它隻是存儲新的或更新的計劃資訊資料字典。另外同一時間您隻能建立一個等待區域 ,直到你送出或清除懸而未決的區域或登出。
第一步：建立一個等待區
使用CREATE_PENDING_AREA包建立等待區，在plsql執行的指令如下：
BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
END;
第二步：建立使用者組
使用CREATE_CONSUMER_GROUP包建立使用者組，在plsql執行下面的指令，建立一個預設的使用者組（備份使用者組），如下：
BEGIN DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP ( CONSUMER_GROUP => '備份使用者組', COMMENT => '該組使用者備份時使用'); END; 同樣的方法可以建立其它如‘視窗使用者組’、‘住院使用者組’等，如果要修改或者删除使用者組，就需要用到UPDATE_CONSUMER_GROUP和DELETE_CONSUMER_GROUP包，這裡就不再單獨介紹。
第三步：建立個資源計劃
使用CREATE_PLAN包建立資源計劃，在plsql執行如下指令建立一個‘中聯資源管理計劃’的資源計劃，之前我們用EM建立計劃的時候CPU使用率用的是分級法，這裡我們用比例法（RATIO），如下：
BEGIN DBMS_RESOURCE_MANAGER.CREATE_PLAN (PLAN => '中聯資源管理計劃', MGMT_MTH => 'RATIO', COMMENT => 'HIS系統使用者資源管理'); END; 同樣的如果要修改或者删除資源計劃，需要用到UPDATE_PLAN和DELETE_PLAN包，這裡也不再單獨介紹。
第四步：建立資源計劃指令
使用CREATE_PLAN_DIRECTIVE程式建立資源計劃訓示，這個包的參數比較多，這裡不多作介紹，有興趣的可以下來單獨研，使用者組還是用我們之前建立的使用者組，舉個簡單的例子：
BEGIN DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (PLAN => '中聯資源管理計劃', GROUP_OR_SUBPLAN => '視窗使用者組', COMMENT => '視窗使用者使用者', MGMT_P1 => 50); DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (PLAN => '中聯資源管理計劃', GROUP_OR_SUBPLAN => '住院使用者組', COMMENT => '住院使用者使用者', MGMT_P1 => 20); DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (PLAN => '中聯資源管理計劃', GROUP_OR_SUBPLAN => '後勤使用者組', COMMENT => '後勤使用者使用者', MGMT_P1 => 10); DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (PLAN => '中聯資源管理計劃', GROUP_OR_SUBPLAN => '備份使用者組', COMMENT => '為備份專門提供的資源', MGMT_P1 => 10); DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (PLAN => '中聯資源管理計劃', GROUP_OR_SUBPLAN => 'OTHER_GROUPS', COMMENT => '其它使用者', MGMT_P1 => 10); END; 這裡隻對CPU的比例進行了配置設定，視窗使用者組，住院使用者組，後勤使用者組, 備份使用者組,和OTHER_GROUPS分别配置設定為50:20:10:10:10，如果會話隻存在于視窗使用者組和住院使用者組,CPU配置設定的比例就是50：20，這隻是最簡單的配置設定，如果涉及到其它資源，比如IO、空閑時間這些，就會要求一旦達到門檻值資源組切換方式，這裡的切換有SWITCH_TIME, SWITCH_IO_MEGABYTES和SWITCH_IO_REQS等一些參數控制，這些比較設定相對比較複雜，這裡就不再舉例。
第五步：驗證等待區
通過前面的操作我們就完成了資源管理的建立，之後我們就是要驗證建立的資源管理是夠有效，這就需要我們進行驗證，驗證的方法就是在VALIDATE_PENDING_AREA看其是否有效，當然驗證也必須遵守以下規則，否則會提示錯誤:
l 不包含任何循環的計劃。一個循環發生在輔助方案包含一個指令,引用一個計劃,計劃層次的輔助方案。例如,一個輔助方案不能參考計劃。
l 所有被計劃指定的子計劃和使用者組必須存在。
l 所有的計劃都必須有計劃訓示,指出計劃或使用者組。
l CPU所有的百分比不得超過100。
l 如果一個計劃,目前被用作一個活動執行個體的進階計劃不能被删除。
除了這些還有一些參數隻能出現在使用者組的計劃訓示中，不能出現在其它資源計劃中如：PARALLEL_DEGREE_LIMIT_P1，ACTIVE_SESS_POOL_P1，SWITCH_GROUP等等，具體可以參見Oracle® DatabaseAdministrator's Guide11g Release 1 (11.1) Creating a Complex Resource Plan，驗證的方法很簡單，就是執行下面一條指令,如下：
BEGIN DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA(); END 驗證完了并沒有生效，如果要生效需要送出等待區，然後切換到所建立的資源管理，也是一個包執行以下：
-----送出等待區 BEGIN DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA(); END; ----切換資源管理 BEGIN dbms_resource_manager.switch_plan( plan_name => '中聯資源管理計劃', sid => 'orcl' ) END; 最後就是清除等待區，完成整個資源管理的建立。
BEGIN DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA(); END; 這樣一個最簡單的通過DBMS包的方式建立資源管理的案例就完成了，如果清除了等待區，要對現有的計劃進行調整，還需要重新建立等待區。當然真實環境下這樣簡單的資源管理肯定會有很多問題，我們需要根據具體的業務特性進行分析後進行設定才是真正有效的資源管理。
4. 資源管理效果案例測試
前面我們對資源管理的理論知識和建立過程進行了介紹，我們來做幾個相對簡單的資源（空閑時間、執行時間和并行度）管理測試，展示下資源管理的效果。
4.1. 空閑時間和執行時間限制
思路，我們就利用之前建立的使用者組，然後配置設定使用者到對用的使用者組中，對該組進行空閑時間和執行時間的限制（60秒），讓其中一個使用者連接配接不做任何操作，另外1個使用者運作loop.sql腳本，該腳本為死循環腳本，可保持該會話一直處于執行狀态，腳本内容如下：
loop.sql腳本如下:
declare
i number;
j number;
begin
i:=0;
loop
j :=sqrt(i);
i :=i+1;
end loop;
end;
/ 腳本準備好後，接着我們來看下目前激活的資源計劃的管理計劃情況，我們這裡隻關注準備做實驗的使用組‘視窗使用者組’，資源限制如下：
重點關注紅色的幾個部分，其中執行時間如果超過60秒，目前會話的使用者組就轉到‘備份使用者組’，設定完成後我們以U000001使用者登入資料庫，檢視下登入會話所屬的使用使用者組，确認為我們需要的使用者組，如下：
可以看到，接着我們一個不做操作，另外一個執行剛才的死循環腳本，等待60秒後，再次查詢這個會話，結果如下：
我們可以看到60秒後，執行死循環的會話使用者組已經切換到‘備份使用者組’上，這個切換不會永久性的，當執行完成後，對資源進行了釋放，該會話再次執行其它操作，會切換回原來的使用者組，而另外一個沒做任何操作的空閑會話貌似沒有什麼變化，其實不然，我們到這個會話上去操作會提示ORA-02396: 超出最大空閑時間, 請重新連接配接，如下：
4.2. 并行度實驗
并行度（parallel）是Oracle資料庫的一個特有屬性，通過合理的運用可以加快查詢、備份、建立對象的效率，當然同時付出消耗資源的代價，如果過分的設定并行度可能會導緻資源消耗過多，是以我們又是會對并行度進行限制，如下，我們這裡對視窗使用者組的并行度就進行了限制，最多隻能3個并行：
以U000001（視窗使用者組）使用者登入一個會話1執行下列指令，進行并行度為5的查詢
SQL>select * from 住院費用記錄;
在會話2中執行下列指令
SQL> selectsid,qcsid,degree from v$px_session；
其中sid為從屬程序所對應的SID，QCSID為這些從屬程序所對應的父SID，DEGREE表示并行度，如果我們以另外一個使用者U000002（非視窗使用者組），執行同樣的查詢語句，得到的結果就不一樣，如下：
通過上面的對比我們可以看到，同樣是在hints裡面指定了5個并行度，但是由于資源管理的限制，前面的在實際執行過程中隻能最多3并發度的查詢，而後面這個由于不受限制，是以可以按照設定的要求，實作了5個并行度的查詢，通過這個事實證明資源管理确實生效。
5. 可應用于HIS系統的資源管理計劃
通過上面的案例講解，其實都是以我們ZLHIS系統為基礎的資源管理計劃設定，當然真實環境不可能這麼簡單，如果資源管理計劃設定不合理，不但不能起到應有的作用，反而會對實際應用造成一定的影響，如何針對我們的HIS系統進行資源管理，那些情況适合資源管理，我們這裡也作一定的分析，希望能夠大家一些參考。
5.1. 現有資源和應用評估
如果一個使用者伺服器資源非常豐富，應用又非常簡單，這時候再用資源管理就是多此一舉，如果确實資源有限，并且在某些時候出現了資源瓶頸，這時候就要對資源進行管理，但也要根據資源管理的類型，認真評估下目前伺服器在運作環境，做到有的放矢，可以簡單的列一個表格進行分析。
| 項目 | 評估方法 | ZLHIS一般情況 |
| 伺服器資源瓶頸 | 通過AWR性能報告擷取 | 根據伺服器配置（記憶體、IO） |
| 應用分類 | 業務分類 | 門診、住院、備份、後勤 |
| 資源消耗大的操作 | 業務分析 | 統計、備份等 |
| 資源消耗大的時間段 | 通過AWR性能報告擷取 | 上午、月末 |
當然這裡隻是進行了簡單的列舉，如果要真正、有效和合理的對資源進行控制，使其發揮最佳的效果，還要作更多的分析才行。
5.2. 典型的HIS資源管理思路
ZLHIS的應用對資源的消耗還是比較有規律，大部分屬于OLTP操作，是以除非設計問題，單個操作對性能的瞬時消耗并不大，但是另一部分操作如查詢、過濾等會根據條件的差異對性能的消耗有所需求，這部分就是我們重點關注，一般采用2種方式進行管理：
Ø 業務劃分法：
這種方式就是我們前面案例采用的方式，根據業務對資源的消耗和需求進行分類，然後根據類别對資源進行管理。
Ø 時間劃分法：
如果大家仔細觀察資料庫alert日志記錄可以發現，其實11g開始，oracle預設就是啟用了資源管理，采用排程的方式，在晚上啟用了，如下日志記錄的摘要：
這個自帶的資源計劃的目的是對背景的一些作業如：統計資訊收集、SQL自動優化等資源消耗過大的操作進行管理，其實對于我們ZLHIS系統，道理是一樣的，在業務高峰期對一些操作進行管理，避免其對正常業務的影響，這也是一種有效的資源管理方式。
當然建立資源管理計劃以上兩種方式都不是孤立的，我們需要有效的組合才能做到最佳的應用效果，下面就以一個典型案例來了解如何合理的建構符合使用者需求的資源管理方案。
案例是這樣去年某市級醫院進行三甲資格評審，需要收集大量的資訊，為此技術人員為使用者訂制了非常多的統計報表，這些報表都是大範圍的資料統計，由于使用者存儲IO性能一般，在收集過程中，醫院回報HIS程式操作經常卡頓，通過性能報告發現出現大量IO等待，但是這些統計操作一段時間内又無法限制，為了不影響醫院正常業務的使用，需要通過資源管理來限制業務高峰期這些資源消耗性統計操作。
第一步：明确目标
首先我們要明确我們本次資源管理所要達到的目标，控制資源消耗性報表統計在業務高峰期對HIS系統的影響，這點我們首先就要進行分類，HIS業務操作的優先級肯定是最高、其次我們這裡隻需要對資源消耗性報表統計這類業務進行控制，首先要明确使用者，然後明确控制的範圍，才能使得資源管理真正起到效果，同時對其它業務不産生影響。
第二步：确定使用者
前面說了，我們要确定使用者的範圍，範圍越小，資源管理越有效，同時對其它業務的影響也越小，分析下這次要控制的操作，資源消耗性報表的統計，這些操作肯定隻有某些特定使用者或者角色才能使用，而且如果能夠進一步控制，隻有這些特定使用者在一些特定的用戶端的操作，才可能會執行資源消耗性報表，确定範圍後就可以建立資源使用者，然後在資源使用者組和資源使用者組映射中進行設定。
| 資源消耗性統計使用者組 | 使用者 | 角色 | 特定用戶端 |
| U00001 ~ U00002 | Zl_評審報表 | 192.168.4.21 192.168.4.20 |
第三步：控制範圍
這一步就是資源計劃的範圍，根據資源計劃控制的範疇，确定如何對資源進行控制，也就是對資源消耗性報表的特點進行分析，确定門檻值名額，同時在确定門檻值的過程中确定控制的方式和時間。
| 時間範圍 | 名額 | 控制方式 |
| 早上：8~12點 | 執行時間：30分鐘（估算） | SQL取消 |
| IO限制（MB）（實體讀*塊） | ||
| 限制登入會話數：5 sessions | ||
| 下午：12點~18點 | 執行時間：30分鐘（估算） | 切換到OTHER資源使用者組，隻限制CPU的使用率 |
| IO限制（MB）（實體讀*塊） | ||
| 其它時間段 | 不限制 | 不限制 |
這裡我們特别講下時間範圍:資源管理計劃可以通過oracle的内部排程作業視窗進行控制，确定什麼時間段激活，激活持續時間等，通過合理的設定排程，可以讓資源管理計劃按照設定的要求生效和持續時間，如下：
通過這樣的設定，就可以按時間控制資源管理，使得管理次元更加精細，也更符合實際業務的應用，滿足我們控制業務高峰期資源消耗性報表的使用。
6. 維護視圖
資源建立後，肯定随着業務的應用和環境的變更，需要對資源管理計劃進行維護和調整，大部分情況都是通過包和EM進行操作，也比較簡單，我們這裡就不再進行示範，這裡介紹下一些常用的檢視資源管理計劃的視圖，這些視圖友善大家對資源管理進行管理。
| 視圖 | 描述 |
| DBA_RSRC_CONSUMER_GROUPS | 列出存在在資料庫中所有資源使用者組 |
| DBA_RSRC_PLAN_DIRECTIVES | 列出存在在資料庫中所有資源計劃訓示。 |
| DBA_RSRC_PLANS | 列出存在在資料庫中所有資源計劃。 |
| DBA_RSRC_GROUP_MAPPINGS | 列出所有的會話的各種映射屬性。 |
| DBA_RSRC_MAPPING_PRIORITY | 列出了每個屬性的目前優先級映射. |
| V$PARALLEL_DEGREE_LIMIT_MTH | 顯示所有可用的并行度限制資源配置設定方法 |
| V$RSRC_CONSUMER_GROUP_CPU_MTH | 顯示所有可用的CPU資源配置設定方法資源使用者組。 |
| V$RSRC_SESSION_INFO | 顯示為每個會話資料資源情況，可用于調優和設定資源計劃映射用 |
| V$SESSION | 列出每個目前會話的會話資訊。具體來說,列出了每個目前會話的資源消費者團體的名稱。 |
當然不止這些視圖，還有一些不常用的視圖如檢視資源使用者組曆史的V$RSRC_CONS_GROUP_HISTORY、資源計劃曆史的V$RSRC_PLAN_HISTORY等等，這些就需要各位在實際運用過程中去嘗試了解。
7. 存在的不足
當然我們在看到在資源管理的優點的同時，在進行案例建構的時候，也看到了一些不足之處，主要表現在以下幾點：
7.1. HIS程式提示視窗不明顯
由于資源管理的限制，根據我們的控制方式（特别是SQL取消和會話終止），我們的ZLHIS程式在執行過程中肯定會異常終止，前台表現會彈出錯誤提示，如下對資源消耗性報表進行控制後，執行報表SQL會提示如下視窗：
這樣的提示給操作端人員的感覺就是程式出現了未知錯誤，如果在管理之前沒有進行必要的告知，勢必會增加管理者的解釋工作量。
7.2. 管理方式的局限
在實際應用過程中，還是會感受到資源管理的一些局限，特别是資源管理的方式上，除了CPU的配置設定方式外，大部分還是以簡單的門檻值限制為主，如最簡單的IO操作，目前看隻能達到門檻值就取消操作或者切換到其它會話使用者組，無法保持會話IO在一定限制範圍内持續執行，另外目前的分組隻能通過會話區分，沒有對具體的操作模式進行區分，應該進一步的對DDL操作進行劃分，是以現在的資源管理方式對于精細化管理的需求還無法滿足。
7.3. 額外的消耗
在啟用了資源管理後，資源管理本身會有一定的消耗，如果設定不合理可能會導緻額外的性能問題，這在AWR報告中會有顯示如下：
可以看到，這些以resmgr：*開頭的事件就是資源管理特有的等待事件，如果這些等待事件占據了TOP5，那就證明資源管理設定可能存在問題或者遇到BUG，這樣勢必導緻額外的消耗。
不過綜合來說，Oracle資料總管如果合理的利用确實能夠解決HIS業務的一些實際問題，特别是針對一些整體資源本身有限，有啟用了大量應用模式的醫院，其不失為一種解決問題的措施和方法。
1. 編寫參考文獻
官方文檔：ManagingResource Allocation with Oracle Database Resource Manager
網絡部落格：http://czmmiao.diandian.com/post/2011-04-18/17026473