Oracle DBA很早就盼望能夠在生產環境中捕獲應用程序的負載，然后通過在測試環境中重放捕獲的負載來判斷數據庫或應用程序的改動對數據庫性能的影響，Oracle 11g數據庫新的數據庫重放特性使DBA可以捕獲，處理負載，然后有選擇性地或跨大范圍的數據庫環境和平臺全部重放，本文為在日益不穩定的數據庫環境中使用Oracle 11g數據庫重放有效地快速預報應用程序的改變對性能的影響提供一個入門。 如果我在IT行業這幾年教會了我一切，那它是繼墨菲定律（凡事只要有可能出錯，那就一定會出錯）之后的又一真理了，過去的幾年里，我認 識到了多個墨菲定律推論的正確性，包括“替代的零件往往不能代用”及特別是“墨菲實際上是一個樂觀主義者”的回答，我希望有一天我自己的推論也能通過長期 的觀察被添加到這些嚴格的定律中，我的推論就是：“沒有東西能夠象在測試環境那樣在生產環境中運轉”。Oracle DBA面臨一個嚴峻的挑戰：如何準確預報下一組對數據庫或應用程序，甚至是硬件配置的改動對整個數據庫環境產生的負面影響。這里所說的整個環境字面上的意思是：任何應用程序運行時執行的每一條SQL語句，不管它僅僅是一個簡單的查詢語句還是包括大量DML語句的批處理作業，都必須捕獲。這個挑戰目前變得更加尖銳，因為當前的應用程序負載大都是跨多個技術產生的：N層應用程序服務器、web farms、甚至傳統的客戶端/服務器模式應用程序。況且，當某個應用程序執行速度慢下來時，要跟蹤追捕檢查性能下降的根本原因幾乎不可能的。它可能是因不正確的網絡配置、不正確的應用程序服務器配置、甚至可能是因為應用程序客戶端環境變量設置不正確引起的。目前實現這個艱巨的目標唯一的選擇是“捕獲/重放”應用程序負載產品套件，這類應用程序是專門設計用于捕獲當前生產環境數據庫已經執行過的完整負載（p+0），然后重放該負載（p+1）。然而，以我多年的經驗看來，這意味著公司要盡早購買第三方較昂貴的解決方案（如HP的LoadRunner工具）。軟件的許可成本和服務器的配置成本需要集中精力考慮，特別是人力資源配置的考慮，可能在捕獲/重放負載開始之前很容易就會達到六位數美金的投入了。這就是為什么許多IT機構放棄了這個想法，因為測試應用程序性能倒退的成本因素使其變得不太可能。性能倒退之外的因素我之前寫的關于Oracle 11g新的SQL語句性能調試特性：SQL性能分析器（SPA）和SQL計劃管理器（SPM）已經討論過Oracle 11g是如何讓DBA定位因應用程序環境改變引起的性能提升、保持原樣、性能倒退的SQL語句的，所有捕獲/重放工具都必須要能捕獲并能比較源（p+0） 和未來（p+1）系統、應用程序、數據庫性能統計，特別是當前性能較低的SQL語句。但這里我還要提出另外兩個需要標記的回歸類型：錯誤回歸：在 重放捕獲的負載時，常常會遇到錯誤，事實上這個錯誤幾乎就是一個想要的結果，例如：我想校驗一個預期中的異常，如違背引用完整性（如主鍵、外鍵、唯一鍵、 CHECK、NOT NULL約束）出現時能被正確地捕獲，同時，我還希望有違背重要的事務規則的情況出現能被捕獲到，如在檢查職員工資單時發現基本工資與總工資扣除所有費用 后不平衡的情況，我希望這種異常能被當作錯誤一樣被捕獲到。因此，任何強大的捕獲/重放工具都必須能夠監視下面三種類型的錯誤回歸：所有預期的錯誤都發生了嗎？有不是預期的錯誤狀態出現嗎？很顯然，這表明嚴格的因系統或應用程序改變的錯誤回歸是可能的。預期的錯誤有沒有出現的嗎？這種情況更復雜了，因為這表明在系統或應用程序內某些不祥的事情已經發送變化了，也可能是重要的事務規則被濫用或沒有應用到所有事務上。數據回歸：所有捕獲/重放工具在重放完成后，如果數據本身出現了差異還必須發出提醒信號，例如，在測試一個關鍵任務的金融系統時，我必須確保相同的 金融業務安裝合理的順序完成，在p+1環境所有帳戶總和都應該象p+0環境中達到平衡，如果結果不一樣，我必須考慮在我的應用程序、數據庫或環境中是什么 改變導致了重放不精確的情況出現。捕獲和重放套件的另一個關鍵特性是：在p+1環境上重放捕獲的負載前，必須確保負載捕獲啟動時P+0環境被復位，否則可能會誤診為數據回歸，而實際上應用程序，數據庫和環境都沒有發送任何改變。從屬的事務需要捕獲并重放，這好比鋼琴家演奏完一段曲子后，磁帶記錄不僅記錄了記錄信息，還記錄了每個按鍵被按下的頻率信息，本質上，它給聽眾提供 了一份藝術大師演奏風格的精確復本，包括所有復雜的演奏停頓（對于小于25歲的年輕讀者而言，可能沒有看到過鋼琴演奏磁帶，可以用mp3或wav文件替 換，或詢問一下年長的同事當年聽磁帶的事情。）數據庫重放：功能摘要感謝Oracle 11g新的數據庫重放（DBR）套件為我們提供了所有討論到的功能，DBR允許允許DBA：捕獲在生產系統上產生的負載，這包括跨多個會話同時收集所有依賴的事務時捕獲并行執行的相同SQL語句的能力。捕獲的數據在測試系統上執行前先要做一些處理，這允許DBA調整負載重放的頻率，以及重新映射到不同用戶會話，不同服務的連接，或-在Oracle 11g RAC測試系統中重放時，是一個或多個數據庫實例。在測試系統上重放捕獲的經過處理過的負載，測試系統的配置符合p+1配置的要求，因此DBA可以準確地判斷任何系統改變（包括應用程序改變，軟件補丁，甚至硬件升級）對負載的影響，測試系統可以是測試或QA數據庫環境，也可以是一個快照備用數據庫（關于備用數據庫后面的文章有更多的說明）。執行回歸分析突出p+0和p+1模擬負載之間的差異，DBR會自動識別和分析錯誤回歸，數據回歸和SQL語句回歸的向量。數據庫重放的美妙之處是它消除了創建執行回歸分析的模擬負載的必要性，相反，DBA可以準確地執行記錄下來的SQL語句，因此這傾向于提供更準確的 系統回歸實況錄像，因為其他外部因素（如網絡等待時間）減少了或沒有了，所有記錄下來的SQL語句組成了重放的負載，實際上看起來幾乎不會出現無用的或很 少執行的代碼，這些代碼可能會被忽略，如果應用程序是在一個RAC集群數據庫環境中的話這是很關鍵的。本文接下來的4小節提供了數據庫重放功能的高級入門指南，實現它們的通用目標：在從p+0到p+1遷移一個生產系統時準確判斷需要回歸到什么程度，本系列后面的文章中，我會介紹如何利用數據庫重放功能捕獲、預處理、重放和分析重放結果。第一步：錄制負載Oracle 11g企業管理數據庫控制臺提供了一個非常直觀的管理數據庫重放功能的接口，如啟用負載捕獲，預處理，回歸分析等，每一步它都提供了良好的狀態反饋信息，圖1顯示了初始的數據庫重放控制臺界面：（點擊查看大圖）圖1：數據庫重放控制臺主界面這一步看到的全部負載就是對生產數據庫捕獲和錄制的內容，DBA只需要保證在生產系統上有足夠的負載，DBR做了其他所有事情（捕獲所有外部客戶端發起執行的SQL語句），這包括：SQL查詢，DML語句和DDL語句。PL/SQL塊和遠程過程調用（RPCs）。對象導航請求和OCI調用。注意DBS捕獲操作執行過程中，Oracle 11g不會停止任何后臺運行中的作業，所有內部客戶端也可以繼續產生請求。DBR通過一系列影子進程記錄負載，這些影子進程過濾出必要的信息準確地復制系統負載，最后將這些元數據寫入一系列XML文件，后面重放時就是使用的這些XML文件，Oracle 11g DBA只需要關心文件系統上是否有足夠的存儲空間來重放這些XML文件。第二步：“整理”負載當DBR負載錄制完畢后，在重放前，總是需要對其進行一些細微的調整。例如：重新映射外部客戶端的連接，以便在p+1環境中能準確地重放，在這一步中，DBR為它最后重放準備具體的元數據，所有影響重放結果的參數也是在這一步進行修改的。在相同數據庫版本上重放時這個預處理過程必須存在，當只要數據庫版本匹配，就可以在一個生產、測試或其他數據庫系統上執行擦除操作，實際上，Oracle強烈建議在一個非生產服務器上執行這個元數據的“整理”操作，以不影響生產服務器的性能或健康為宜。第三步：重放負載負載已經整理好了，可以啟動重放操作了，完成元數據擦除后，選定的DBR重放客戶端就可以隨需重放負載了。復位測試環境：在啟動重放前，DBA首先必須復位用于測試的目標數據庫和主機環境，因為在應用改變前，測試服務器的關鍵部位需要與生產服務器匹配，否則，可能引發非預期的回歸，幸運的是，隨Oracle 10g數 據庫出現的閃回數據庫（FLASHBACK DATABASE）特性幫助我們簡單完成這個任務，其他可選的包括通過RMAN恢復到一個時間點，或使用數據泵導出導入，一旦測試環境正確地復位完畢，接 下來，DBA應用所有的改變到測試服務器上的生產系統，使其現在的狀態變為p+1，然后傳送前面捕獲的負載給這個p+1服務器。通過重放驅動重放負載：當在p+1服務器上最后一次重放前面捕獲的負載時，一個叫做重放驅動的應用程序向目標數據庫系統發送請求，因為重放驅動是客 戶端不可知論的，對Oracle 11g而言最初發送請求的客戶端類型是沒有區別的，重放驅動消滅了錄制的負載和向p+1系統發送請求的過程，就象是外部客戶端發送的請求一樣。因為它將在所有重放客戶端之間分配所有的負載捕獲流，重放驅動可能會考慮網絡帶寬、cpu和內存容量，重放驅動也可能充分利用重新映射連接字串，使它們建立起一對一（如單實例到單實例）或多對一（如單節點到多個RAC節點）的關系，意味著連接負載均衡可能需要考慮，同樣重要的是，重放驅動會忽略最初由外部客戶端產生的活動（如EM數據庫控制），不會重放這種活動，同時，它還會忽略通過數據庫連接連接到外部數據庫或訪問目錄對象的活動記錄。另一個使用數據庫重放吸引人的優點是：可以同步模式或異步模式重放捕獲的負載。在同步模式下，每一個事務都按照錄制時的順序準確地重放，然而， DBR也可以異步重放負載，如不考慮事務的同步性，因此可以產生比錄制時更大的負載，這在試圖執行一個“測試到破壞”新的或修改過的數據庫環境時特別有 用。DBR負載重放的范圍：Oracle 11gR1數據庫重放功能可以準確地評估下面幾類對數據庫環境的改變。數據庫升級數據庫打補丁改變數據庫模式改變初始化參數修改一個或多個RAC節點及其內連配置操作系統平臺的概念，包括從32位轉移到64位改變服務器內存或cpu配置改變數據庫的存儲配置，包括在文件系統（如ext3,ntfs）、ASM存儲、和/或RAW存儲之間遷移數據庫文件DBR負載重放限制：數據庫重放模擬能力有一些顯著的（且合理的）限制：SQL*Loader直接路徑裝入不能重放，常規路徑SQL*Loader操作可以重放導入導出操作，不管是通過傳統的方式還是數據泵的方式，都不能重放Oracle共享服務器會話不能跟蹤閃回數據庫恢復和Flashback查詢操作不能重放Oracle數據流，包括非基于PL/SQL的高級查詢，不能重放分布式事務處理，包括遠程COMMIT操作，只能當作本地事務重放基于Oracle調用接口（OCI）對象導航不能重放對于大多數部分，這些限制有意義，例如：閃回數據庫本質上是一個不完全的數據庫恢復操作，因此它不是正常事務處理的范疇，我也不會考慮它是否會使性能倒退，雖然限制對于共享服務器會話有意義，但仍然有一些數據庫是使用共享服務器作為連接池的，因此這是一個小小的遺憾。第四步：回歸分析負載重放完畢后，數據庫重放將提供多個有關在p+1環境和p+0環境下負載性能不同的分析，正如我在本文最前面提到的，任何好的回歸測試套件都有能力捕獲和分析性能回歸、數據回歸和錯誤回歸，DBR在這些方面沒有讓我們失望。例如：DBR能夠通過它的一套捕獲重放報告立即檢測到任何性能差異，通過這些報告，可以下鉆到存儲在ADDM（自動數據庫診斷監視器）、AWR（自動負載倉庫）和活動會話歷史（ASH）報告中更詳細的分析。無論問題出自哪里，DBR都能識別并處理下列兩種類型的問題：聯機問題象征DBR可能做了一些誤操作，應該先暫停，否則重放的結果變得沒什么意義脫機問題實際上是數據庫重放操作成功的預期結果，這種類型的問題通常是在重放操作結束后被檢測到的下一步理論知識具備了，在本系列的下一篇文章中，我將闡述：在Oracle 11gR1數據庫單實例上捕獲一個簡單的負載預處理捕獲的負載在一個雙節點的Oracle 11gR1 RAC集群數據庫上重放預處理過的負載標識出在轉移到類型目標環境過程中可能出現的問題Oracle 11gR1提供了捕獲生產環境中應用程序的負載，并在測試環境中重放負載的能力，利用這種技術判斷當對系統、數據庫或應用程序修改后在性能方面的影響有多大，在本文中，我將描述Oracle 11g數據庫重放功能如何從當前的生產數據庫中（p+0環境）捕獲和準備負載，以及如何在一個Oracle 11g測試環境（作為下一個p+1數據庫系統）重放相同的負載，這種技術使Oracle DBA有機會分析和隔離對性能有害的改變。 這篇文章主要集中講述如何：從一個Oracle 11g數據庫捕獲一個真實的負載捕獲對應的自動負載倉庫（AWR）數據為最后的負載重放準備測試數據庫環境傳輸生產環境配置到測試環境預處理生產負載在測試系統上重放負載分析發現的任何性能問題和分歧模擬應用程序環境本文中關于我的測試環境有一點需要說明：為了簡化過程，捕獲和重放操作都使用相同的數據庫。我使用的是最基本的Oracle 11g種子數據庫和默認安裝的樣本方案。數據庫將運行在帶閃回日志功能的ARCHIVELOG模式下，以便需要重放時可以快速地利用FLASHBACK DATABASE命令回退到某個初始點。第一階段：錄制負載為了建立一個捕獲/重放情景，我建立了一個新用戶、表、索引和相關的PL/SQL對象：一個新用戶ADMIN，它將被用作存儲所有管理對象的一個倉庫，同時，我還創建了一個表存儲主鍵的值。創建該用戶和表的代碼請參考附件A：ADMINSetup.sql。PL/SQL包ADMIN.PKG_SEQUENCING控制指定新的主鍵值，該包的說明參考附件B：pkg_sequencing.spc，該包最初的版本內容參考附件C：pkg_sequencing_v1.bdy。另一個用戶AP，它將封裝一個帳戶支付系統的方案，包括新的表AP.VENDORS，AP.INVOICES和AP.INVOICE_ITEMS，創建這個方案及其相關的對象腳本參考附件D：APSetup.sql。為了填充AP方案的對象，我創建了一個包AP.PKG_LOAD_GENERATOR，它的說明文件和主體文件分別參考附件E：pkg_load_generator.spc和附件F：pkg_load_generator.bdy。最后，APInitialization.sql中的代碼用幾百行模擬數據填充了表AP.VENDORS，并在表AP.INVOICES中創建了 25條發票記錄，在表AP.INVOICE_ITEMS中創建了與之對應的發票詳細信息條目，收集了ADMIN和AP方案下所有對象的原始統計信息，它還 創建了一個目錄對象DBRControl，用于數據庫重放時存儲結果腳本和捕獲負載期間產生的XML文件。建立一個負載捕獲至此，我們的源數據庫環境初始化好了，我將啟動一個真實的負載捕獲，下面的圖2.1.1顯示了數據庫重放的初始窗口，它是通過訪問EM數據庫控制軟件的【軟件和支持】標簽上的【真正應用程序測試】小節下的【數據庫鏈接】得到的。點擊查看大圖（點擊查看大圖）圖2.1.1：負載捕獲設置：初始化界面如果我選擇了第一個任務，在我的捕獲會話執行前必須先確認所有在檢查列表中列出的先決條件都已具備才行。點擊查看大圖（點擊查看大圖）圖2.1.2：負載捕獲設置：計劃環境檢查列表接下來的界面讓我選擇在正式捕獲負載之前是否重啟數據庫，并過濾不需要的會話活動（如EM本身），注意我會按照Oracle 11g的最佳實踐建議“清除捕獲”：我會接受EM的建議停止并重啟數據庫以建立一個有效的捕獲啟動時間。點擊查看大圖（點擊查看大圖）圖2.1.3：負載捕獲設置：選項接下來的界面顯示的是給捕獲會話命名和指定存儲重放腳本的目錄。點擊查看大圖（點擊查看大圖）圖2.1.4：負載捕獲設置：設置參數接下來要求為任務調度命名，圖2.1.5和圖2.1.6顯示了最終的任務確認設置界面。點擊查看大圖（點擊查看大圖）圖2.1.5：負載捕獲設置：指定EM任務名點擊查看大圖（點擊查看大圖）圖2.1.6：負載捕獲設置：最終的任務視圖最后，Oracle 11g請求最后一次確認。點擊查看大圖（點擊查看大圖）圖2.1.7：負載捕獲設置：任務提交捕獲就啟動了，只要Oracle 11g顯示這個屏幕，它實際上是等我再次在源數據庫上啟動代表性的負載。捕獲一個真實的負載為了通過不同用戶模擬相似代碼的并行執行過程，我準備了一個簡單的shell腳本（參考附錄G：RandomLoadGenerator.sh），它做一些CPU密 集型計算的簡單查詢，在AP方案上產生的查詢，同時在AP方案的表中插入上千行記錄，我已經將我的源數據庫環境配置為使用多個服務名，每一個對應一種用 戶，內容參考附錄H：SI_Services_tnsnames.ora，我將這些服務名添加到我的數據庫配置文件TNSNAMES.ORA中作為可選的 連接別名。我在我的p+0數據庫環境中啟動了這個負載，執行完畢后，我回到EM數據庫控制臺查看執行的結果，如圖2.2.1所示，然后點擊“停止捕獲”按鈕結束負載捕獲。點擊查看大圖（點擊查看大圖）圖2.2.1：負載捕獲：回顧捕獲任務狀態這時，Oracle 11g會要求你確認是否結束捕獲過程，并顯示一個計時表直到捕獲完成。點擊查看大圖（點擊查看大圖）圖2.2.2：負載捕獲：確定終止捕獲點擊查看大圖（點擊查看大圖）圖2.2.3：負載捕獲：結束捕獲當終止捕獲后，Oracle 11g會詢問是否捕獲錄制的負載對應的自動負載倉庫（AWR）數據，如圖2.2.4所示，我選擇了捕獲所有有關的AWR快照，以便于后面進行報告對比。點擊查看大圖（點擊查看大圖）圖2.2.4：負載捕獲：請求生成AWR快照一旦捕獲結束，就可以查看捕獲結果看捕獲是否成功，以及是否包含了足夠的數據，如果發現數據不足，FLASHBACK DATABASE命令允許我回到捕獲開始前的數據庫狀態再重新開始捕獲，我也選擇了“查看負載捕獲報告”按鈕生成一個完整的數據庫捕獲報告（報告鏈接： /img/2008/05/PCW_Report_1.html）。第二階段：準備重放盡管在p+0數據庫環境中成功完成了一個足夠的數據庫負載捕獲，當在p+1環境中重放負載之前還有許多事情要做。復位p+0環境因為我的源和目標環境是同一個數據庫，因此首先我需要將環境復位到捕獲負載之前的狀態，我的數據庫工作在閃回日志模式，因此我只需要使用FLASHBACK DATABASE命令將其回退到初始狀態：$ rman target /RMAN shutdown immediate;RMAN startup mount;RMAN reset database to incarnation 6;RMAN flashback database to scn= 4162947;轉移到p+1環境接下來，我要做的是應用必要的改變，將我的數據庫環境轉到p+1狀態，簡單說明一下，我將做兩個改變，它們對p+1環境的性能有顯著的影響：對存儲過程ADMIN.PKG_SEQUENCING.NEXT_ID做了特殊處理，使用序列代替了表ADMIN.NEXT_IDS來確定 AP方案中表的下一個主鍵值，這應該會顯著提升存儲過程AP.PKG_LOAD_GENERATOR.RANDOMDML的性能，在重放過程中，它在 AP.INVOICES和AP.INVOICE_ITEMS表中創建隨機數據項目。刪除了在AP.INVOICES.CUSTOMER_ID上的索引，并重新計算了AP方案的統計數值，因為存儲過程 AP.PKG_LOAD_GENERATOR.RANDOMQUERY在視圖AP.RV_INVOICE_DETAILS上產生隨機查詢時經常使用這個索 引高效地選擇行，在重放時應該看到性能會如預期那樣顯著回退。“整理”負載至此，我的p+1工作環境搭建好了，可以開始為重放做一下負載預處理了，再說一次，我會使用EM數據庫控制臺啟動預處理序列，圖2.3.1顯示了從“數據庫重放”面板選擇了“預處理負載”后的結果。點擊查看大圖（點擊查看大圖）圖2.3.1：預處理捕獲的負載：選擇一個捕獲的負載當我選擇了想要的負載后，Oracle 11g會提醒我是在同一個數據庫版本上進行數據庫重放.點擊查看大圖（點擊查看大圖）圖2.3.2：預處理捕獲的負載：數據庫版本警告然后啟動一個新的EM調度任務完成預處理。點擊查看大圖（點擊查看大圖）圖2.3.3：預處理捕獲的工作量：調度預處理任務Oracle 11g提示要進行最后的確認，以提交調度任務，然后開始執行。點擊查看大圖（點擊查看大圖）圖2.3.4：預處理捕獲的負載：最后確認第三階段：重放負載因為我的目標數據庫已經復位到捕獲負載之前的狀態了，并且我所有的p+1改動現在已經準備就緒，至少我已經準備好負載重放了，我將使用EM控制臺進行重放，如圖2.4.1所示：點擊查看大圖（點擊查看大圖）圖2.4.1：負載重放：起點我選擇了一個包含有捕獲負載文件的目錄后，Oracle 11g會確認我已經檢查過成功重放所要求的先決條件，包括處理之前需要解決的外部引用（如外部文件和外部目錄），如圖2.4.2和2.4.3所示： 點擊查看大圖（點擊查看大圖）圖2.4.2：負載重放：確認先決條件點擊查看大圖（點擊查看大圖）圖2.4.3：負載重放：確認對外部系統的引用一旦所有的先決條件都得到確認了，可以開始真實地執行重放任務了，圖2.4.4顯示了我設置的關于這個任務的基本信息：點擊查看大圖（點擊查看大圖）圖2.4.4：負載重放：設置重放任務圖2.4.5顯示我重新映射當前的連接以便重放時也可以使用它。點擊查看大圖（點擊查看大圖）圖2.4.5：負載重放：設置連接字符串正如我在數據庫重放入門那篇文章中描述的，Oracle 11g允許我改變重放負載的頻率，為了保持簡潔，我選擇了默認的選項，如圖2.4.6所示：點擊查看大圖（點擊查看大圖）圖2.4.6：負載重放：自定義重放選項現在可以啟動負載重放客戶端（WRC）開始重放之前捕獲的負載了，如圖2.4.7展示的那樣。接下來，我用適當的參數啟動WRC，然后返回這個屏幕選擇“下一步”按鈕開始自動重放負載。點擊查看大圖（點擊查看大圖）圖2.4.7：負載重放：啟動負載重放客戶端我將打開一個終端啟動重放會話，啟動WRC客戶端執行，注意在開始之前，我將當前的工作目錄修改為/home/oracle/DBRControl。$ wrc system/oracleorcl mode=replay replaydir=.Workload Replay Client: Release .0 - Production on Thu May 22 19:28:59 2008Copyright (c) 1982, 2007, Oracle. All rights reserved.Wait for the replay to start (19:28:59).回到EM數據庫控制臺，我只需要點擊“下一步”按鈕，Oracle11g會回答我所有活動的數據庫重放操作都在控制之中。點擊查看大圖（點擊查看大圖）圖2.4.8：負載重放：控制重放操作同時也反應到終端會話本身中了：Wait for the replay to start (19:28:59).Replay started (19:31:17)返回EM數據庫控制臺，數據庫重放操作始終都被監視著。 點擊查看大圖（點擊查看大圖）圖2.4.9：負載重放：監視活動的重放操作直到重放操作完成。 Wait for the replay to start (19:28:59).Replay started (19:31:17)Replay finished (19:37:02)點擊查看大圖（點擊查看大圖）圖2.4.10：負載重放：完成的重放操作第四階段：回歸分析Oracle 11g給我們提供了許多用于對比捕獲的與重放的負載，如圖2.5.1和2.5.2所示，重放操作成功執行完畢后會提供大部分對比結果：點擊查看大圖（點擊查看大圖）圖2.5.1：重放回歸分析（一）點擊查看大圖（點擊查看大圖）圖2.5.2：重放回歸分析（二）正如這些圖示，我對數據庫對象所做的改動產生了正面的影響，因為執行捕獲的負載的時間比重放同一負載的時間要長得多，同時表明對系統的修改明顯增加 了數據庫的吞吐量，最值得注意的是這里沒有產生有害的影響，這從圖2.5.2中很容易看出來，因為在產生的數據之間絕對沒有分歧，也沒有異常錯誤產生。報告分析最后，數據庫重放提供了多個HTML格式的報告用于分析執行完畢的重放操作結果。DB Replay Report這個報告比較捕獲負載和重放負載的執行過程，它查找任何可能的數據或錯誤回歸的源。AWR Report這個報告提供自動工作負載信息庫（AWR）報告，它簡要地分析了在重放操作開始到結束這段時間周期內的數據庫的整體性能。ASH Report它通過查看在重放期間的活動會話歷史記錄（ASH）的內容，找出對性能影響最大的SQL語句和等待事件。Oracle數據庫11gR1新的數據庫重放（DBR）功能允許Oracle DBA從一個Oracle 10gR2環境捕獲負載，然后在Oracle 11gR1環境中重放這個負載，以分析如何將現有數據庫遷移到新版本，并分析對系統整體性能的影響。這是本系列最后一篇文章，將描述如何使用這些特性從現有的Oracle 10gR2單實例數據庫環境捕獲并預處理負載，然后在一個Oracle 11gR1 RAC測試環境中重放同樣的負載。這給Oracle DBA提供了一個史無前例的機會標識出在遷移到RAC環境時任何潛在的性能瓶頸。 前面的文章描寫的是一個相對簡單的場景：如何在當前運行Oracle 11g生產環境中（p+0）捕獲一個模擬的應用程序負載，然后在相同的p+1環境重放，這篇文章處理稍微更有難度一點的任務，因為：從一個單實例Oracle 10gR2數據庫捕獲和記錄應用程序負載，包括對應的自動工作負載信息庫（AWR）數據。將模擬負載轉移到Oracle 11gR1 RAC測試環境。預處理負載，包括重新映射到不同負載均衡服務的連接。在Oracle 11gR1 RAC測試環境中重放負載。標識應用程序性能問題，數據分歧和錯誤分歧。我將使用Oracle 11gR1提供的PL/SQL包DBMS_WORKLOAD_CAPTURE和DBMS_WORKLOAD_REPLAY來完整這些任務。第一階段：錄制一個單實例環境下的負載為了使捕獲和重放情景簡單 - 同時因為我痛恨浪費任何有用的東西 - 我將使用前面文章中使用的PL/SQL對象來完成在單實例Oracle 10gR2上的負載捕獲，因為捕獲負載要求最低的Oracle10gR2版本是，首先我使用數據庫升級助手（DBUA）將現有數據庫（名 叫DB10G）升級到，在我的Oracle 10gR2生產環境中花了30分鐘來升級，中間很順利。然后我執行同樣的腳本和PL/SQL代碼創建并啟動一個合適的環境用于捕獲負載。（具體腳本和代碼請參考本系列前面的文章）準備捕獲負載： 現在我們的源數據庫環境已經就緒了，我將啟動一個真實的負載捕獲，Listing 3.1（見附件）顯示了我如何使用存儲過程DBMS_WORKLOAD_CAPTURE.ADD_FILTER應用一些過濾器來排除那些產生“不感興趣” 活動的用戶會話以及在捕獲過程中可以忽略的會話，在本例中，我比想捕獲EM控制臺自身的活動。開始捕獲：Listing 3.2（見附件）顯示了我是如何使用存儲過程DBMS_WORKLOAD_CAPTURE.START_CAPTURE啟動負載捕獲的，這個存儲過程首先 檢查目標目錄（DBRCONTROL）中是否有以前執行負載捕獲的文件，如果有，它會返回一個錯誤，并且不允許捕獲繼續，然而，只要捕獲啟動成功， DB10G數據庫的警報日志將會識別出一個DBR捕獲操作正在進行：. . .Mon Jun 23 19:40:41 2008ALTER SYSTEM SET pre_11g_enable_capture=TRUE SCOPE=BOTH;Mon Jun 23 19:40:44 2008DBMS_WORKLOAD_CAPTURE.START_CAPTURE(): Starting database capture at 06/23/2008 19:40:44. . . 因為我正在一個Oracle 10gR2數據庫上捕獲，在開始捕獲前，我將動態初始化參數PRE_11G_ENABLE_CAPTURE設置為TRUE。生成負載：為了模擬不同用戶相似代碼的并行執行，我準備一個shell腳本（10gSI_RandomLoadGenerator.sh），它與本系列前面文章中的shell腳本類似，它啟動大約80個用戶會話隨機執行一些簡單的CPU密集型計算的查詢，在AP方案上生成復雜的查詢，執行往AP方案表中插入幾千行數據的DML操作。同時，我將DB10G數據庫配置為 只使用一個服務名（DB10G），不考慮操作的類型，并且在我的TNSNAMES.ORA配置文件中添加了這個服務名。（在后面的步驟中，在Oracle 11gR1 RAC環境中我將描述如何使用DBMS_WORKLOAD_REPLAY.REMAP_CONNECTION重新映射這個連接到不同的服務名）暫停負載捕獲：為了暫停捕獲，我執行存儲過程DBMS_WORKLOAD_CAPTURE.FINISH_CAPTURE停止負載捕獲操作（參考Listing 3.3，見附件），注意DBR捕獲成功的結論也會記錄在數據庫DB10G的警報日志中： . . .Mon Jun 23 19:42:21 2008Thread 1 advanced to log sequence 43 (LGWR switch)Current log# 3 seq# 43 mem# 0: /u01/app/oracle/oradata/db10g/redo03.logMon Jun 23 19:44:35 2008DBMS_WORKLOAD_CAPTURE.FINISH_CAPTURE(): Stopped database capture successfully at 06/23/2008 19:44:32查看捕獲結果：為了查看負載捕獲真實的結果，我執行存儲過程DBMS_WORKLOAD_CAPTURE.REPORT生成一個摘要報告（參考 Listing 3.4，見附件），這個報告的輸出文本格式請查看Report 3.1（見附件）或HTML格式（http: //img/2008/06/DB10G_WorkloadCaptureReport.html）。第二階段：準備重放當我成功地完成從Oracle10gR2單實例數據庫上捕獲負載后，開始準備我的目標環境 - Oracle11gR1 RAC集群數據庫：我配置了一個雙節點RAC（RACNODE1和RACNODE2），使用使用Oracle clusterware .0配置和管理集群環境。我在集群中每個節點上部署了一個Oracle .0 ASM實例，在共享磁盤存儲上為數據庫文件創建了兩個ASM磁盤組+DATA，+FRA。我使用Oracle 11gR1的標準種子數據庫模板創建一個新的RAC數據庫RACDB，部署了兩個RAC實例RACDB1和RACDB2，每個節點上一個，通過一個監聽器提供服務。我部署了一個新的RAC服務TESTLBA作為這兩個節點對外提供的服務，并將連接數調整為最大，使用負載均衡顧問程序（LBA）跨這兩個實例分配連接以模擬一個OLTP環境，Listing 3.5（見附件）顯示了srvctl命令調用DBMS_SERVICE.MODIFY_SERVICE和為TESTLBA服務配置的TNSNAMES.ORA網絡配置項目。最后，我在RACDB集群數據庫嚴格地創建了與之前在DB10G數據庫上創建的一樣的表，索引和PL/SQL包。然后執行APInitialization.sql腳本初始化表AP.VENDORS，AP.INVOICES和AP_INVOICE_DETAILS。準備負載：至此我的數據庫重放目標環境已經就緒了，下面為在RAC環境重放做最后的準備的工作：在節點RACNODE1和RACNODE12上添加新的目錄/home/oracle/DBRControl。在RACDB數據庫中創建一個新的目錄對象DBRCONTROL，同時在每個節點上也在其物理位置創建了響應的目錄，并給這個目錄對象授予了合適的權限。我將在DB10G數據庫上捕獲負載時產生的文件分別復制到這兩個節點的相同目錄下了，注意也可以將這些文件只復制到其中一個節點，因為在RAC集群環境中，任何一個節點都可以管理重放負載。最后，我執行存儲過程DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE為重放對先前捕獲的負載做預處理工作，這個存儲過程解析在DB10G數據庫上的用戶會話操作，為在RACDB上重放做預處理。Listing 3.6（見附件）顯示了我在集群節點上創建物理目錄和在RACDB數據庫中創建對應的目錄對象的命令，以及（在將所有文件復制到合適的物理目錄下后）如何 執行存儲過程DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE進行負載預處理的。第三階段：重放負載現在我的RAC數據庫已經準備好可以接受執行重放先前捕獲的負載了，如前面的文章談到的那樣，使用Oracle 11g EM進行重放時必須按照嚴格的順序執行，調用存儲過程DBMS_WORKLOAD_REPLAY執行重放時這些步驟也必須按步驟執行，重新映射所有的連接，調整所有自定義重放頻率設置，收集重放性能，回歸統計報表收集。 啟動數據庫負載重放：為了啟動數據庫重放，我將使用存儲過程DBMS_WORKLOAD_REPLAY.INITIATE_REPLAY，它將吧 RACDB數據庫置為INIT FOR REPLAY狀態，是通過存儲過程DBMS_WORKLOAD_REPLAY.PREPARE_REPLAY將數據庫置為PREPARE狀態的必要前提條 件。重新映射連接字符串：為了保證將所有參與在DB10G數據庫上生成負載的會話重新映射到RACDB上對應的TESTLBA負載均衡連接上，我將使用存儲過程DBMS_WORKLOAD_REPLAY.REMAP_CONNECTION。參考Listing 3.7（見附件）中關于如何調用這兩個存儲過程以及如何查看重新映射連接的結果的例子。自定義負載重放選項：正如我在數據庫重放入門那篇文章中談到的那樣，Oracle 11g允許DBA自己精細控制重放的頻率，負載重放客戶端可以提供存儲過程DBMS_WORKLOAD_REPLAY.PREPARE_REPLAY設置多個額外的參數被牢牢控制：表3.1重放客戶端選項重放選項描述SYNCHRONIZATION定義生產負載時是否使用SYNCHRONIZATION：l TRUE：這是默認值，在重放過程中捕獲的負載中將被保留的COMMIT的順序，所有重放動作只有當所有依賴的COMMIT動作執行完畢后才能執行。l FALSE：原始的COMMIT順序不會得到遵從，這樣很可能會返回大量的數據分歧，但它在載入或壓力測試時非常有用。THINK_TIME_SCALE定義同一會話兩個連續用戶調用之間說花費的時間，因此由它驅動重放的速度：l 默認值是100，或原始負載產生速度的100%。l 如果設置為0，連續發送到重放數據庫的速度會是盡可能地快。l 如果設置的值大于100%，那速度就響應減低了。THINK_TIME_AUTO_CORRECT基于指定的百分比糾正用戶調用之間的THINK_TIME_SCALE，將這個參數設置為TRUE，重放客戶端將被強制縮短調用之間的“思考時間”，以便讓重放說花費的時間與最初收集的時間相匹配。CONNECT_TIME_SCALE用指定的值標定從負載捕獲開始到會話連接所花費的時間，這應該理解為用戶會話連接保留的時間百分比。注意數據庫重放負載捕獲時間與負載重放時間之間的區別：捕獲負載過程中，所花費的時間是通過用戶時間（中的用戶調用時間）和用戶思考時間（在發出另一個調用是用戶等待的時間）組成的。然而，在負載重放過程中，所花費的時間是由用戶時間，用戶思考時間和同步時間組成的。正如在前面的文章中提到的，我只需要接收默認的選項，通過調用Listing 3.8存儲過程DBMS_WORKLOAD_REPLAY.PREPARE_REPLAY。啟動負載重放客戶端：現在可以啟動負載重放客戶端（WRC）重放前面捕獲的負載了，我將通過打開一個終端會話啟動重放會話，在我集群數據庫中的節點RACNODE2上調用WRC客戶端：$ wrc replaydir=/home/oracle/DBRControlWorkload Replay Client: Release .0 - Production on Mon Jun 23 21:27:47 2008Wait for the replay to start (21:27:48)當WRC在RACNODE2節點上啟動后，我需要告訴Oracle 11g它可以控制所有活動的數據庫重放操作了，如Listing 3.9顯示的，我通過調用存儲過程DBMS_WORKLOAD_REPLAY.START_REPLAY來完成這件事，這個存儲過程執行成功的狀態會在 WRC終端會話輸出中反應出來：Wait for the replay to start (21:27:48)Replay started (21:28:16) 監視活動的重放操作：Listing 3.10顯示了一個簡單的對視圖DBA_WORKLOAD_REPLAY的查詢，它產生一個簡單的關于當前DBR負