【DBA】Oracle Database 11g： 面向 DBA 和開發人員的重要特性 資料庫重放

xysoul_雲龍發表於2016-12-06
OracleDatabase資料庫

資料庫重放

瞭解如何使用資料庫重放（Oracle Database 11g 中一個閃亮登場的全新工具）來捕獲完整的資料庫負載，以便您可以隨意進行“重放”。

參見系列目錄

需要在資料庫中進行更改時 — 無論是進行微小的改動（如變更初始化引數和資料庫屬性）還是進行不可避免的較大改動（如應用補丁集），您最關心什麼？對於到 Oracle Database 11g 的升級，您最關心的是什麼？

對我而言，我最關心的是更改是否會帶來“破壞性”風險。即使微小的改動也有可能引發多米諾骨牌效應，最終導致嚴重後果。

為了將這種風險降至最低，許多廠商在類似於生產環境的控制環境中進行更改，應用類似於生產系統的負載並觀察隨之產生的影響。複製生產系統非常簡單（至少從技術層面上講），但再現負載卻是另一回事。說起來容易做起來難。

多數機構會採用一些可自動執行以模擬真實使用者活動的第三方負載生成工具進行嘗試。大多數情況下，這種方法是可行的，但始終無法真正忠實地再現生產資料庫負載。這些第三方工具只是通過不同引數執行預編寫的查詢若干次；您必須向這些工具提供查詢並給定其可以隨機使用的引數範圍。這並不能代表您的生產系統負載，而僅僅是執行了一小部分執行了若干次的生產負載，因此，這只是對 1% 的應用程式程式碼進行了測試。最糟糕的是，這些工具要求您自己提供所有來自生產負載的查詢，對於小型應用程式而言，這可能需要數週或數月，對於複雜些的應用程式，則可能需要多達一年的時間。

如果可以，在資料庫本身內記錄所有資料庫操作（與 DML 相關的操作及其他操作），而後按這些操作出現的真實順序進行重放，難道不是一種更好的方法嗎？

資料庫重放概述

Oracle Database 11g 將為您帶來諸多好處。新的資料庫重放工具好似資料庫內的 DVR。使用這個獨特的方法，可以如實地以二進位制檔案格式捕獲 SQL 級以下的所有資料庫活動，然後在同一資料庫或不同資料庫內進行重放（這正是在進行資料庫更改之前您希望做的）。您還可以自定義捕獲流程，以包括或排除某些特定型別的活動。

資料庫重放與另一個工具 SQL Performance Analyzer 共同構成了 Oracle Database 11g 的 Real Application Testing 選件。這兩個工具之間的主要不同在於涉及的範圍：資料庫重放適用於捕獲和重放資料庫內的所有（符合某些過濾條件）活動，而 SQL Performance Analyzer 可用於捕獲特定的 SQL 語句並對其進行重放。（在資料庫重放中，您無法檢視或訪問捕獲到的特定 SQL，而在 SQL Performance Analyzer 中則可以）。後者的一個顯著優勢是 SQL 調優，因為您可以調整由應用程式執行的 SQL 語句並評估其影響。（本系列即將推出有關 SQL Performance Analyzer 介紹的文章。）

理論上，資料庫重放的工作順序如下圖所示。

圖 1

啟動一個記錄資料庫活動的捕獲流程。

  • 該流程將活動寫入名為“capture files”的特殊檔案，該檔案位於 /capture directory/ 目錄中。
  • 稍後，停止捕獲流程，將這些捕獲檔案移至 /replay directory/ 目錄中的測試系統。
  • 啟動一個重放流程和若干重放客戶端，以重放這些捕獲檔案。
  • 這些捕獲檔案將在測試資料庫上應用。


那麼，資料庫重放可以提供哪些第三方工具不能提供的優勢？一些工具僅重放若干您提供的複合語句。而資料庫重放不需要您提供 SQL 語句。由於它將捕獲 SQL 之下的所有活動，因此您不會遺漏任何可能導致效能問題的關鍵操作。此外，您可以有選擇地（針對特定使用者、程式等）進行捕獲，還可在捕獲負載時指定時間期限，可以重放導致問題的特定負載，而不是整個資料庫。

例如，您注意到月末利息計算程式導致問題出現，並猜想更改引數將簡化流程。您必須做的是捕獲月末程式執行期間內的負載，在測試系統上對引數進行更改，然後在該測試系統上重放捕獲檔案。如果效能有所提升，則表明此解決方案可行。如果效能沒有提升，這也僅僅是個測試系統而已。您不會妨礙到生產資料庫的執行。

在我看來，單為了使用該工具，也值得升級到 Oracle Database 11g。下面將介紹該工具的工作原理。

捕獲

第一個任務是捕獲資料庫中的負載。所有任務都可通過命令列或 Oracle Enterprise Manager Database Control 完成，但本文將使用後者。

  1. 捕獲到的負載儲存在系統中的檔案上，這些檔案是名副其實的“攝像機”內的“磁帶”。該目錄應當為空。因此，第一個任務是建立目錄（如果還沒有此目錄）。對於本例，建立的目錄名為 /home/oracle/dbcapture。 
      $ cd /home/oracle
  $ mkdir dbcapture
  2. 在資料庫中為該目錄建立一個目錄物件： 
    SQL> create directory dbcapture as '/home/oracle/dbcapture';
      
Directory created.
  3. 現在，可以開始捕獲了。為了演示真實場景，將建立一個簡單的測試工具，該工具將生成許多 INSERT 語句並插入到一個名為 TRANS 的表中。 
    create table trans (
        trans_id        number,
        cust_name       varchar2(20),
        trans_dt        date,
        trans_amt       number(8,2),
        store_id        number(2)
)
/


    下面是一個可完成此任務的小的 PL/SQL 程式碼片斷。該程式碼片斷將生成 1,000 條插入語句並進行執行。（注意，此程式碼片段將生成 1,000 條不同的插入語句，而不是在同樣的語句或程式中執行 1,000 次插入操作。） 

    declare
  l_stmt varchar2(2000);
begin
  for ctr in 1..1000 loop
     l_stmt := 'insert into trans values ('||
        trans_id_seq.nextval||','||
        ''''||dbms_random.string('U',20)||''','||
        'sysdate - '||
        round(dbms_random.value(1,365))||','||
        round(dbms_random.value(1,99999999),2)||','||
        round(dbms_random.value(1,99))||')';
     dbms_output.put_line(l_stmt);
     execute immediate l_stmt;
     commit;
  end loop;
end;
  4. 只建立包含以上內容的檔案；不要執行。將該檔案命名為 add_trans.sql。（以上所有步驟僅對於此課程都是必要的。如果沒有目錄物件，則在生產環境中執行操作時無需這些步驟。）
  5. 在現實情況中，您可能會在不同的資料庫上執行重放。但是，在此處，針對我們的目的，您將只是閃回同一資料庫並重放那裡的活動。您可以通過建立名為 GOLD 的恢復點來標記該場所。 
    SQL> create restore point gold;


    現在，準備開始捕獲。導航到 Oracle Enterprise Manager Database Control 中的 Database Replay 主頁面。在該主頁中，選擇Software and Support（如下圖所示，標記為“1”）

    圖 2
  6. 單擊 Database Replay（在 Real Application Testing 下面）啟動 Database Replay 頁面（如下所示）。 

    圖 3
  7. 在左側窗格中，您將看到一系列活動。選擇第一個活動 (Step 1:Capture Workload)，方式是單擊它旁邊的 Go to Task 圖示。
  8. 下一個螢幕將顯示三個您應在啟動捕獲流程之前仔細檢查並確認的假設： 

    • 當前資料庫可以在重放系統上恢復到負載捕獲開始時的 SCN
    • 有足夠的磁碟空間來儲存捕獲的負載
    • 在負載捕獲開始之前已準備好重啟資料庫（如果您選擇這樣做）
  9. 選中所有核取方塊進行確認。
  10. 單擊 Next。
  11. 下一個螢幕有兩個不同的操作項。在螢幕的上半部分，您將看到兩個單選按鈕，您可通過這兩個按鈕來選擇是否希望在捕獲流程前重啟資料庫。

    啟動捕獲流程後，可能會有一些正處於執行中的事務，其中並非所有都可進行捕獲。重啟資料庫將使這些正處於執行中的事務無效。重啟資料庫可清除這些“干擾”。而且，重啟資料庫可以為您提供一個乾淨備份在測試系統上進行恢復，從而確保您在與生產系統的 SCN 號相同的系統上重放活動。

    出於上述原因，特別是第一個，Oracle 建議在捕獲之前重啟資料庫（該選項為預設設定）。但這不是必須的。如果不希望重啟，請選擇另一個單選按鈕。

  12. 螢幕底部顯示的內容如下所示。

     

    圖 4



    現在，您將記錄捕獲流程在捕獲活動時將考慮的篩選器。預設有兩個篩選器：排除所有來自 Oracle Management Server 的活動和來自 Oracle Management Agent 的活動。


    您也可以新增其他篩選器。例如，要新增排除所有 Perl 程式的篩選器，可單擊 Add Another Row 並在域“Filter Name”和“Value”中分別輸入“perl”和“%perl%”。同樣，糾正預設引數中的小錯誤 — Oracle Management Agent 篩選器的值應為“%emagent%”，而不是“emagent%”。

    或者，假設您希望排除所有 SYS 使用者操作。那麼，您需要從 Session Attribute 下拉框中選擇 USER，並在“Value”列中輸入 SYS。

  13. 單擊 Next。這將顯示一個類似如下所示的螢幕：

     

    圖 5
  14. 在該螢幕中，從下拉框中選擇將在其中儲存捕獲檔案的目錄名。本例中已使用了目錄 DBCAPTURE。如果您沒有在以上步驟中建立該目錄，還可通過單擊 Create Directory Object 進行建立。然後單擊 Next。
  15. 在下一個螢幕中，您將看到 Job Details（作業細節），如作業執行時間等。選擇單選按鈕 Immediate 立即執行作業。
  16. 在該頁面上填寫其他詳細資訊，如 OS 使用者名稱、SYS 口令等，並單擊 Next。
  17. 下一個螢幕標為“Step 5 of 5”，其中將顯示您輸入的所有資訊，如作業名和排除篩選器。如果所有內容都符合您的要求，則單擊Submit。否則，可返回進行修改。
  18. 一旦單擊了 Submit，負載捕獲就將開始。您將看到一個確認螢幕，如下所示。

     

    圖 6



    注意 Status，其顯示為“In Progress”。
  19. 現在，該工具正在捕獲負載，從 SQL*Plus 提示符執行您的模擬負載。當然，在實際的系統中，無需執行任何模擬；只需讓捕獲流程執行一段時間以捕獲所有負載。 
    SQL> connect arup/arup
SQL> @ins_trans

    這將在表 TRANS 中執行 1,000 條插入語句。在負載完成後，單擊 Stop Capture 按鈕，如以上螢幕中所示。將要求您確認。
  20. Oracle 在捕獲負載前後自動獲取自動負載資訊庫 (AWR) 快照。在下一個螢幕中，將詢問您是否要匯出 AWR 資料。如果您在其他系統上重放並且希望將 AWR 資料從當前資料庫匯出到目標資料庫（如以下螢幕中所示），這步操作很重要。單擊 Yes。

     

    圖 7
  21. 這將建立一個匯出 AWR 的排程程式作業。單擊作業名稱並重新整理狀態螢幕，直至您看到作業從 Running 選項卡中消失。

您已將捕獲的負載儲存到 /home/oracle/dbcapture 目錄中的檔案裡。

預處理

現在，負載已捕獲，可進行重放了。通常，您希望在單獨的測試系統中進行重放，因此需要將目錄 /home/oracle/dbcapture 中的檔案複製到一個新的主機。請確保在將檔案複製到該目錄時，該目錄為空。出於教學目的，您將使用同一個資料庫進行重放。

在同一資料庫中進行重放並不常見，但有可能出現。例如，您可能希望在主系統中重放事務，測試完成後閃回至起始點。您可能會中斷一個時段，以在期間測試引數更改（您將在同一資料庫中進行此更改）的效果。

您需要在播放捕獲的負載之前對其進行預處理。預處理可使這些捕獲的檔案為重放做好準備。

  1. 轉至 Database Replay 主頁面。

  2. 選擇 Step 2:Preprocess Workload。

  3. 從下拉選單框中選擇目錄物件。這將顯示捕獲的負載。在本例中，該目錄物件是 DBCAPTURE。如果您還沒有建立目錄物件，單擊相應的按鈕即可輕鬆建立目錄。

  4. 單擊 Preprocess Workload。

  5. 在下一個頁面中，將要求您提供作業名和相關詳細資訊，如主機使用者名稱和口令。如果不想指定作業名，則接受預設值。選擇立即執行該作業。主機使用者 ID 和口令應已填充。如果還沒有，輸入相應的值，單擊 Submit。

  6. 在下一個頁面中，您將看到確認資訊和一個可用於檢視作業狀態的連結。單擊該連結。

  7. 重新整理該螢幕，直至您看到狀態為“Succeeded”。

現在，負載已經過預處理，可用於重放了。

 

重放

捕獲負載並進行預處理後，就可在測試資料庫中進行重放了。出於教學目的，您在同一資料庫中預處理了負載，並將使用同一資料庫重放這些活動。為此，您必須將資料庫重置回起始點。您可以通過將其閃回到在捕獲流程期間建立的還原點 GOLD 來輕鬆實現此目的。

SQL> shutdown immediate;
... database shuts down ...
SQL> startup mount
... instance starts and mounts the database ...
SQL> flashback database to restore point gold;
... database will be flashed back ...
SQL> alter database open resetlogs;
... database is opened ...


現在，您處於負載啟動之前的一個點，可以重放之前捕獲的負載了。按照以下步驟對其進行重放。

  1. 從 Database 主頁轉至 Database Replay 主螢幕，如“Capturing”部分中所示。
  2. 從選單中選擇 Step 3:Replay Workload。這將帶您進入 Replay 主螢幕。
  3. 您將看到一個用於選擇目錄的下拉框。選擇重放檔案所在的目錄。這是目錄物件；不是實際的 UNIX 目錄。在之前的示例中，您使用了目錄物件 DBCAPTURE，因此將其選中。如果您還沒有建立目錄，可單擊 Create Directory 建立一個目錄物件。
  4. 單擊右上角的 Setup Replay。
  5. 下一個螢幕將顯示即將發生的事情的資訊列表。以下為每條資訊項的相關說明。
  6. Restore Database（還原資料庫）— 重放之前捕獲的負載時，可能需要在測試系統上執行此操作。您如何構建測試系統？您可能將生產資料庫還原到測試系統並對其進行還原。最大的可能是，在此活動中，生產資料庫沒有關閉，因此您的恢復可能並不完全。在這種情況下，確認恢復操作已執行至捕獲和預處理階段指定的 SCN 號。


    本例中，您將資料庫閃回至該 SCN 號。因此，您遵循了規定。

  7. Perform System Changes（執行系統更改）— 這是為什麼要首先執行重放的原因：測試系統更改，如引數更改或設定更改。當然，您需要在重放之前進行更改。

  8. Resolve References to External Systems（解決對外部系統的引用）— 假設您已經在生產資料庫中有了一個指向 /home/appman/myfiles 的目錄物件，而測試系統上不存在該目錄。在重放時，對該目錄的引用將失敗。同樣，源系統中的所有資料庫連結也將在測試系統中失敗（如果它們不存在）。因此，您需要通過建立或更改目錄來解決這些問題。可以利用下一個螢幕對其進行更改。
  9. Set Up Replay Clients（設定重放客戶端）— 瞭解如何在後續步驟中執行該操作。
  10. 單擊 Continue，這將顯示如下所示的螢幕： 


    圖 8



    可以通過單擊頁面上顯示的連結更改所有非引用引數。請注意，單擊任何一個連結都將離開 Database Replay 頁面。因此，最好在 SQL*Plus 中對這些連結進行單獨更改。單擊 Continue。
  11. 輸入 Replay Name 或接受預設值。
  12. 下一個螢幕將顯示一些由於未解決的對資料庫連結、目錄等的引用而可能導致的問題。 


    圖 9



    如果願意，可以在螢幕右側更改重放系統。在本例中，由於在同一資料庫上執行，因此本步驟並非必需。
  13. 單擊 Next。這將顯示如下所示的螢幕：

     

    圖 10



    該螢幕將顯示重放流程正在等待重放客戶端。重放客戶端的執行並不在 Database Control 螢幕內進行。這些客戶端程式讀取捕獲的負載並對其進行重放。程式名為 wrc（在 UNIX 和 Windows 系統上均是該名稱）。要啟動重放客戶端，您需要轉至 UNIX 提示符並執行以下命令列： 
    $ wrc userid=system password=* replaydir=/home/oracle/dbcapture
  14. 當然，您需要提供正確的 SYSTEM 口令。如果捕獲檔案儲存在另一個地方，則需更改目錄名。應返回以下訊息： 
    Workload Replay Client: Release 11.1.0.6.0 - Production on Tue Sep 4 19:50:44 2007
 
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
 
Wait for the replay to start (19:50:44)
  15. 此時，重放客戶端僅僅是等待重放管理程式 (Database Control) 告知其啟動。您可以決定是否啟動多個客戶端來並行處理負載。
  16. 立即轉至 Database Control 螢幕。您應當看到該螢幕已更改，其中顯示已連線重放客戶端。該螢幕將顯示客戶端連線的主機名、作業系統程式 ID 等。

     

    圖 11
  17. 單擊 Next，然後單擊 Submit 啟動重放流程。如果現在轉至 UNIX 會話，您會看到另一條訊息：“Replay started (01:49:56)”。該螢幕將通過進度條來顯示目前已處理的資料量。
  18. 一段時間之後，UNIX 會話將顯示“Replay finished (01:50:35)”。此時，如果檢視 Database Control 螢幕，您將看到該螢幕類似如下所示：

     

    圖 12
  19. 其中顯示了重放作業的詳細狀態。左上角的關鍵域“Status”顯示為“Completed”，指示作業已完成。
  20. 現在可以進行執行分析了。該螢幕在下半部分（標題“Comparison”下）顯示了一些指標。在本例中，完成重放所用的時間是捕獲時間的 39.08%。這是個好訊息嗎？您實施的更改有效嗎？

     

    圖 13


    未必。檢視下一個指標 — Database Time — 是捕獲時間的 180%。要檢視更多資訊，可單擊選項卡 Report，這將顯示如下螢幕：

     

    圖 14
  21. 該螢幕顯示報告的各種選項。從最簡單的 Workload Report 開始。該報告沒有比較效能，而是向您顯示“差異”— 重放中有多少資料不同。例如，如果您有一條 ID 為 3 的記錄，對該記錄進行了更新，之後又將其刪除。在重放期間，假定先將其刪除然後再更新；這就屬於差異。差異越少，回放越精確。
  22. 但請勿就此停下。要進行明確分析，可檢查如下所示的 AWR 比較時段報告，看看眾多其他指標（如栓鎖爭用、鎖定、重做產生、一致獲取等）之間的差異，以使您更好、更清晰地瞭解更改所帶來的影響。

     

    圖 15



    該報告顯示捕獲和重放負載之間的差異。在重放期間，與捕獲期間相比，物理讀取和寫入分別增加為 367% 和 111%。其他引數（如排序和邏輯讀取）也呈增長趨勢，雖然增長的不是那麼明顯。因此，您可以得出結論：無論進行何種更改，都會損害效能，而非有助於效能。

 

第 2 版新增特性：

在第 2 版中，將一些新的資訊型別捕獲到 AWR 資訊庫中。這些新資料來源作為檢視公開，檢視名稱中包含 DBA_HIST。

DBA_HIST_DISPATCHER
DBA_HIST_DYN_REMASTER_STATS
DBA_HIST_IOSTAT_DETAIL
DBA_HIST_SHARED_SERVER_SUMMARY
DBA_HIST_SQLCOMMAND_NAME
DBA_HIST_TOPLEVELCALL_NAME


這裡要介紹一個特別重要的檢視。DBA_HIST_IOSTAT_DETAIL 顯示按檔案型別和功能（元件）組合所收集的 I/O 統計資訊。該檢視包含 V$IOSTAT_FILE 和 V$IOSTAT_FUNCTION 的快照。以下是內容的快照：

SNAP_ID DBID INSTANCE_NUMBER FUNCTION_ID FUNCTION_NAME
---------- ---------- --------------- ----------- ------------------------------
FILETYPE_ID FILETYPE_NAME SMALL_READ_MEGABYTES
----------- ------------------------------ --------------------
SMALL_WRITE_MEGABYTES LARGE_READ_MEGABYTES LARGE_WRITE_MEGABYTES SMALL_READ_REQS
--------------------- -------------------- --------------------- ---------------
SMALL_WRITE_REQS LARGE_READ_REQS LARGE_WRITE_REQS NUMBER_OF_WAITS WAIT_TIME
---------------- --------------- ---------------- --------------- ----------
1099 1883196973 1 2 LGWR
1 Control File 4
4 0 0 279
286 0 0 279 985

1099 1883196973 1 2 LGWR
3 Log File 0
586 0 494 52
165586 0 1438 104 457

1099 1883196973 1 5 Streams AQ
1 Control File 13
4 0 0 861
246 0 0 861 1471

1099 1883196973 1 5 Streams AQ
2 Data File 5
0 0 210 569
82 0 210 610 19582

1099 1883196973 1 8 Buffer Cache Reads
2 Data File 664
0 346 0 62272
0 779 0 50136 396220

1099 1883196973 1 9 Direct Reads
2 Data File 62
0 1139 0 761
4 2340 1 0 0

1099 1883196973 1 10 Direct Writes
2 Data File 0
4 0 6 0
316 0 24 0 0

該輸出清楚地顯示了不同型別檔案（如資料檔案、控制檔案、重做日誌檔案和 Data Pump 檔案）上的元件（DBWR、LGWR、Streams、Data Pump 等）發出的不同型別的 IO 呼叫（少量或大量讀取等）。


此外，在 Oracle Database 11g 第 2 版中，資料庫重放有一個被稱作擴充套件倍增器 (scale up multiplier) 的新特性，相比於捕獲期間的負載，該特性在負載重放期間可數倍增加資料庫上的負載。

我們通過一個示例來了解如何使用該特性。我們將從目錄 u01/ratcapture 中捕獲的負載開始。我們還在該 UNIX 目錄上定義了一個名為 RATCAPTURE 的目錄物件。通過該資訊，我們可以重放捕獲的檔案。我通過資料庫負載捕獲 API（而非 Enterprise Manager）來演示該操作。（截至本文撰寫時，Enterprise Manager 尚未放入所需特殊引數的供應方式，因此，無論如何 API 都是唯一選擇。）

以下是具體操作步驟。此時，已經捕獲了負載並且準備在目標系統中處理。

首先，我們將預處理捕獲的檔案。 

begin
  dbms_workload_replay.process_capture (capture_dir => 'RATCAPTURE');
end;
/


我們將需要為重放初始化資料庫。我們必須為重放提供一個名稱；我們選擇 REPLAY1。 

begin
        dbms_workload_replay.initialize_replay (
                replay_name     => 'REPLAY1',
                replay_dir      => 'RATCAPTURE'
);
end;
/


然後，我們將為重放準備資料庫。這就是我們將使用特殊引數來進行擴充套件的地方。該引數（恰當的名稱為 scale_up_multiplier）設定為 10 時，可將負載重放提高到 10 倍於捕獲期間的原始負載。 

begin
   dbms_workload_replay.prepare_replay (
      synchronization              => 'SCN',
      connect_time_scale           => 100, 
      think_time_scale             => 100,
      think_time_auto_correct      => TRUE,
      scale_up_multiplier          => 10
   );
end;
/


在一個單獨的 Unix 會話上，我們將需要啟動 wrc 客戶端。這將等待實際重放啟動。 

# wrc system/oracle REPLAYDIR=/u01/ratcapture

Workload Replay Client: Release 11.2.0.1.0 - Production on Thu Aug 12 17:24:30 2010

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.


Wait for the replay to start (17:24:30)


在第一個 SQL*Plus 會話上，我們將啟動重放。 

begin
  dbms_workload_replay.start_replay;
end;
/


當重放啟動後，wrc 客戶端也將開始處理。它將顯示重放已啟動以及啟動時間。 

Replay started (17:27:04)


在重放了全部捕獲負載後，將顯示重放完成以及完成時間，然後返回 unix 提示符。 

Replay finished (17:29:51)


現在該分析重放期間所發生的事情了，也就是檢視重放報告。為此，我們需要找到本次重放的 ID： 

SQL> select id, name, scale_up_multiplier
  2* from dba_workload_replays;

ID    NAME                           SCALE_UP_MULTIPLIER
---------- ------------------------------                         -------------------
    4 REPLAY-D112D2-20100812170729                     1
    6 REPLAY1                                         10


我們可以看到有兩次重放。一次的 ID 為 4，本次重放未使用任何擴充套件。另一次就是我們剛剛執行的那次，擴充套件了 10 倍。


然後，我們將獲取 ID 為 6 的重放的報告。可以通過從程式包 dbms_workload_replay 中執行函式 REPORT 來獲取該報告。該函式的輸出是 CLOB 資料型別的報告。在進行選擇之前，您需要先設定 LONGSIZE，否則預設情況下，它僅顯示前 80 個位元組。 

SQL> set longsize 999999
SQL> select dbms_workload_replay.report (
  2>   replay_id          => 6,
  3>   format             => 'TEXT'
  4> )
  5> from dual;
輸出如下：

  

DB Replay Report for REPLAY1
------------------------------------------------------------------------

-------------------------------------------------------------------------
| DB Name | DB Id      | Release    | RAC | Replay Name | Replay Status |
-------------------------------------------------------------------------
| D112D2  | 1883196973 | 11.2.0.1.0 | NO  | REPLAY1     | COMPLETED     |
-------------------------------------------------------------------------

Replay Information
------------------------------------------------------------------------
|   Information    | Replay            | Capture                       |
------------------------------------------------------------------------
| Name             | REPLAY1           | CAPTURE-D112D2-20100812162527 |
------------------------------------------------------------------------
| Status           | COMPLETED         | COMPLETED                     |
------------------------------------------------------------------------
| Database Name    | D112D2            | D112D2                        |
------------------------------------------------------------------------
| Database Version | 11.2.0.1.0        | 11.2.0.1.0                    |
------------------------------------------------------------------------
| Start Time       | 12-08-10 21:27:04 | 12-08-10 20:28:47             |
------------------------------------------------------------------------
| End Time         | 12-08-10 21:27:10 | 12-08-10 20:28:59             |
------------------------------------------------------------------------
| Duration         | 6 seconds         | 12 seconds                    |
------------------------------------------------------------------------
| Directory Object | RATCAPTURE        | RATCAPTURE                    |
------------------------------------------------------------------------
| Directory Path   | /u01/ratcapture   | /u01/ratcapture               |
------------------------------------------------------------------------

Replay Options
---------------------------------------------------------
|       Option Name       | Value                       |
---------------------------------------------------------
| Synchronization         | SCN                         |
---------------------------------------------------------
| Connect Time            | 100%                        |
---------------------------------------------------------
| Think Time              | 100%                        |
---------------------------------------------------------
| Think Time Auto Correct | TRUE                        |
---------------------------------------------------------
| Number of WRC Clients   | 1 (1 Completed, 0 Running ) |
---------------------------------------------------------

Replay Statistics
------------------------------------------------------------
|        Statistic        | Replay         | Capture       |
------------------------------------------------------------
| DB Time                 |  5.047 seconds | 0.407 seconds |
------------------------------------------------------------
| Average Active Sessions |            .84 |           .03 |
------------------------------------------------------------
| User calls              |           1120 |           112 |
------------------------------------------------------------
| Network Time            |  3.748 seconds | .             |
------------------------------------------------------------
| Think Time              | 24.591 seconds | .             |
------------------------------------------------------------

Replay Divergence Summary
-------------------------------------------------------------------
|                Divergence Type                | Count | % Total |
-------------------------------------------------------------------
| Session Failures During Replay                |     0 |    0.00 |
-------------------------------------------------------------------
| Errors No Longer Seen During Replay           |     0 |    0.00 |
-------------------------------------------------------------------
| New Errors Seen During Replay                 |     0 |    0.00 |
-------------------------------------------------------------------
| Errors Mutated During Replay                  |     0 |    0.00 |
-------------------------------------------------------------------
| DMLs with Different Number of Rows Modified    |     0 |    0.00 |
-------------------------------------------------------------------
| SELECTs with Different Number of Rows Fetched |     0 |    0.00 |
-------------------------------------------------------------------


現在將此報告與擴充套件倍增器保留為預設值 1 的報告進行比較。下面是 ID 為 4 的重放的報告（來自之前顯示的 DBA_WORKLOAD_REPLAYS 檢視的輸出）。 

DB Replay Report for REPLAY-D112D2-20100812170729
------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------
| DB Name | DB Id      | Release    | RAC | Replay Name                  | Replay Status |
------------------------------------------------------------------------------------------
| D112D2  | 1883196973 | 11.2.0.1.0 | NO  | REPLAY-D112D2-20100812170729 | COMPLETED     |
------------------------------------------------------------------------------------------

Replay Information
-----------------------------------------------------------------------------------
|   Information    | Replay                       | Capture                       |
-----------------------------------------------------------------------------------
| Name             | REPLAY-D112D2-20100812170729 | CAPTURE-D112D2-20100812162527 |
-----------------------------------------------------------------------------------
| Status           | COMPLETED                    | COMPLETED                     |
-----------------------------------------------------------------------------------
| Database Name    | D112D2                       | D112D2                        |
-----------------------------------------------------------------------------------
| Database Version | 11.2.0.1.0                   | 11.2.0.1.0                    |
-----------------------------------------------------------------------------------
| Start Time       | 12-08-10 21:13:17            | 12-08-10 20:28:47             |
-----------------------------------------------------------------------------------
| End Time         | 12-08-10 21:13:22            | 12-08-10 20:28:59             |
-----------------------------------------------------------------------------------
| Duration         | 5 seconds                    | 12 seconds                    |
-----------------------------------------------------------------------------------
| Directory Object | RATCAPTURE                   | RATCAPTURE                    |
-----------------------------------------------------------------------------------
| Directory Path   | /u01/ratcapture              | /u01/ratcapture               |
-----------------------------------------------------------------------------------

Replay Options
---------------------------------------------------------
|       Option Name       | Value                       |
---------------------------------------------------------
| Synchronization         | SCN                         |
---------------------------------------------------------
| Connect Time            | 100%                        |
---------------------------------------------------------
| Think Time              | 100%                        |
---------------------------------------------------------
| Think Time Auto Correct | TRUE                        |
---------------------------------------------------------
| Number of WRC Clients   | 1 (1 Completed, 0 Running ) |
---------------------------------------------------------

Replay Statistics
-----------------------------------------------------------
|        Statistic        | Replay        | Capture       |
-----------------------------------------------------------
| DB Time                 | 1.458 seconds | 0.407 seconds |
-----------------------------------------------------------
| Average Active Sessions |           .29 |           .03 |
-----------------------------------------------------------
| User calls              |           112 |           112 |
-----------------------------------------------------------
| Network Time            | 0.087 seconds | .             |
-----------------------------------------------------------
| Think Time              | 2.786 seconds | .             |
-----------------------------------------------------------

Replay Divergence Summary
-------------------------------------------------------------------
|                Divergence Type                | Count | % Total |
-------------------------------------------------------------------
| Session Failures During Replay                |     0 |    0.00 |
-------------------------------------------------------------------
| Errors No Longer Seen During Replay           |     0 |    0.00 |
-------------------------------------------------------------------
| New Errors Seen During Replay                 |     0 |    0.00 |
-------------------------------------------------------------------
| Errors Mutated During Replay                  |     0 |    0.00 |
-------------------------------------------------------------------
| DMLs with Different Number of Rows Modified    |     0 |    0.00 |
-------------------------------------------------------------------
| SELECTs with Different Number of Rows Fetched |     0 |    0.00 |
-------------------------------------------------------------------


您是否注意到一些重要差異？

  • 在使用了擴充套件的情況下，重放持續時間為 6 秒，與之相比，非擴充套件情況下為 5 秒
  • DB 時間為 5.047，非擴充套件情況下為 1.458 秒
  • 平均活動會話數和使用者呼叫數分別為 0.84 和 1120，而這些數字在非擴充套件情況下為 0.29 和 112。順便說一下，在捕獲期間，使用者呼叫數也是 112，與非擴充套件情況相同。因為擴充套件係數為 10，因此使用者呼叫的數量增加到 10 倍。

您可以清楚地看到，擴充套件倍增器按照倍增係數增加了使用者會話的數量。該測試不僅如實地重放了生產環境中捕獲的活動，而且還增加了這些活動的數量以檢查系統是否能夠處理該測試。

您應牢記一些重要事情：捕獲的負載只是一個 SELECT 查詢。如果已有 DML，那麼僅一組重放發出了這些語句，而其他僅重放 SELECT。5 個不同的重放客戶端執行同一條刪除語句將不會造成 5 次刪除，而 5 條插入語句可能會由於主鍵違規導致四個故障。

此外，還請考慮以下情況：假設從生產系統中捕獲了所有負載，並在測試系統中重放了這些負載。經過幾輪測試和調優後，將測試系統升級為生產系統。假設某個應用程式仍需要進一步的模式更改（如附加索引或不同分割槽），您當然希望確保這些更改會增強效能，更重要的是，不會導致其他問題。在模式更改後再次重放負載是確認您所考慮的問題的最有效方法。

如何確保僅重放特定使用者（例如 SH）的活動？一種方法是從生產環境中重新捕獲負載，具體來說就新增一個僅捕獲 SH 的活動的篩選器，然後在測試系統上重放新捕獲的負載。但是，該方法可能由於以下多種原因而不可行：

  • 截至某個時段（不同於測試系統中的時段）已經捕獲了新負載，從而導致重放效率極低。

  • 由於舊生產環境不再工作，而新生產環境（舊測試環境）沒有與 SH 模式相關的任何活動，甚至可能導致無法捕獲新負載。

  • 即使可以再次捕獲負載，但是為了避免影響生產效能的風險，您可能也不希望這樣做

  • 其他邏輯方面的挑戰（如變更控制限制）

可以做些什麼呢？

在 Oracle Database 11g 第 2 版中，有一個簡單選擇：在重放階段只重放選擇的負載。這樣，不僅可以在捕獲期間應用篩選器，還可以在重放期間應用篩選器。我們來了解一下其工作原理。

在重放期間，您可以建立並使用篩選器。我們來建立一個篩選器以便僅使用 SH 使用者： 

begin
        dbms_workload_replay.add_filter (
                fname      => 'SH_ONLY',
                fattribute => 'USER',
                fvalue     => 'SH'
        );
end;
/


您可以對眾多使用者定義任意數量的篩選器。此外，您還可以對不同屬性（不只是使用者名稱）定義篩選器。在引數 FATTRIBUTE 中可以使用以下值，在 FVALUE 引數中可以使用您感興趣的值。以下是屬性的可能值： 

USER 
 the usernames of the calling users
MODULE 
 the module
ACTION 
 the action
PROGRAM 
 the program
SERVICE 
 service_name of the calling user
CONNECTION_STRING 
 the connect string used (like the one you use in tnsnames.ora file)


新增篩選器之後，建立一個篩選器集： 

begin
        dbms_workload_replay.create_filter_set (
                replay_dir       => 'RATCATURE',
                filter_set       => 'SH_ONLY',
                default_action   => 'INCLUDE'
        );
end;
/


注意，引數 default_action 設定為 INCLUDE，這是預設值。它指定篩選器集的預設操作。在本例中，INCLUDE 意味著包含篩選器，即 SH 使用者包含在重放的負載中。如果您希望相反的結果，即執行除 SH 以外的所有使用者的操作，那麼您應使用 EXCLUDE 作為此引數的值。

建立篩選器集之後，就可在重放中使用它了。資料庫初始化之後（在重放之前）： 

begin
        dbms_workload_replay.initialize_replay (
                replay_name     => 'REPLAY1',
                replay_dir      => 'RATCATURE'
);
end;
/


您可使用篩選器集： 

begin
        dbms_workload_replay.use_filter_set (
                filter_set     => 'SH_ONLY'
        );
end;
/


當您執行選擇性測試（即針對模式、服務名稱等的測試）時，重放負載子集這一功能非常有用。它使您不必多次捕獲負載。理想情況下，您只需要一次捕獲整個生產負載，然後有選擇性地重放，從而單獨測試各種元件。

 

用例

資料庫引數更改 — 假如，您要更改引數 db_file_multiblock_read_count 的預設值，那麼是從 16 改為 256 還是 128？亦或是將其設為 64 或 32？選擇有限，但影響可能無限；更改此值會對優化器帶來極大影響，對某個查詢有益的更改可能會破壞另外 100 個查詢。如何確定該引數的最佳值？

資料庫重放可輕鬆應對這種情況。您可以從生產系統捕獲負載，而後將捕獲的負載移至不同的測試系統中，並將 db_file_multiblock_read_count 設為 32，然後重放負載。之後，您可以將資料庫閃回至初始狀態，將該值設為 64，並重放相同的負載。您可以針對該引數所有可能的值重複執行這一過程：閃回、設定值、重放捕獲的負載。每次重放時，您可執行重放前後的 AWR 報告並進行比較。然後選擇可帶來最佳整體結果的引數值。如果沒有資料庫重放，則根本不可能確定出最佳值。

作業系統升級 — 您計劃升級作業系統或只是應用一個小補丁來修復 I/O 問題，但您如何能確保它不會帶來任何破壞或帶來一些其他問題？很簡單：只要捕獲負載並在應用補丁的測試系統中對其進行重放。該方法同樣也適用於核心引數更改。

應用補丁 — 假設您發現一個錯誤，並且有相應的補丁可用。但您無法確保其會對現有操作產生何種影響，當然，您也可以和企業中 1000 位其他使用者共同找出答案。資料庫重放將為您解決這一難題。

除錯 — 總是會有一些會帶來意外結果的令人討厭的程式。幸運的是，有了資料庫重放，除錯變得前所未有的輕鬆。只需在程式執行期間捕獲負載，並移至一個新系統，更改程式邏輯以加入一些除錯資訊，而後重放負載、分析輸出並解決問題。如果第一次並未奏效，不要失去信心。重複該過程（從重放開始；無需再次捕獲）直至找到解決方案。

物件更改 — 您希望新增索引或將索引從 b 樹轉換為點陣圖。這會對 INSERT 語句產生何種影響？會在何處產生影響？不要猜測；只需捕獲負載並在測試系統中進行重放即可。

資料庫升級 — 這是夢寐以求的更改確保。升級至 Oracle Database 11g 的時代已經到來。最大的問題是：您所有的應用程式都會正常執行甚至是表現更好嗎？無需多慮，只要從 Oracle Database 10g 捕獲負載並在 Oracle Database 11g 中進行重放即可。您不是在新版本上測試一些複合事務，而是在測試應用程式每天都在使用的 SQL。如果有些事情並未按計劃進行，則在新系統中對其進行調整，直至您獲得完全滿意的結果。

平臺更改 — 假設您希望將資料庫平臺從 Solaris 遷移到 HP-UX（其中沒有提供適用於檔案系統的非同步 I/O）。效能是否還會一樣？為什麼要猜測？只要捕獲 Solaris 中的負載並在 HP-UX 中進行重放即可。

轉換到 Oracle Real Application Clusters (RAC) — 這是一個普遍問題：您計劃將資料庫從單一例項轉換為 RAC 例項。應用程式表現是否如初？獲取答案的唯一方法是執行實際的負載，對其進行捕獲，而後在 RAC 資料庫中進行重放。

總結

更改從來都是困難重重，但也不再是無法忍受。您可以通過使用新的資料庫重放工具捕獲終端使用者放入系統中的確切活動，而後在測試系統上進行重放，以精確地衡量更改影響來降低多數風險，而這些都只需幾下滑鼠點選和鍵盤敲擊即可實現。請記住，您還可以測試應用程式的功能，並不僅僅限於效能。

返回系列目錄


原文地址：http://www.oracle.com/technetwork/cn/articles/sql/11g-replay-089222-zhs.html



來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29487349/viewspace-2129900/，如需轉載，請註明出處，否則將追究法律責任。

相關文章