DATABASE REPLAY加壓播放引數之SCALE_UP_MULTIPLIER

      當我們要遷移到新的環境之前，我們都想測試下我們新的環境是否能負荷生產的負載。同時，對於一些特殊的應用場景，我們還需要考慮模擬更大的併發量來測試是否能頂住未來的壓力。舉個簡單的例子，我搞個電子商務的網站，我現在每秒能支援1000個人同時線上做查詢，購買等等操作。那麼未來我們的網站影響力得到了擴大，可能有更多的人進行訪問，比如1萬人、10萬人，這個壓力下我的資料庫伺服器能頂住嗎？在這裡不得不吐槽一下我們的某(tie)車(dao)票(bu)的網站，真是爛的要死，一到過年的時候，就卡個不行。他們真應該多做做這種加壓測試。上一篇我們主要介紹了Database Replay基本使用，我們捕獲了現有的壓力，然後拿到新的環境上去播放，基本上是1比1的。這一篇我們要進行一個加壓的播放，這主要取決於我們的引數SCALE_UP_MULTIPLIER。這個引數可以幫助我們把只讀的操作按照比例進行擴大。對於DML、DDL，或者是修改資料庫的PL/SQL程式碼以及SELECT FOR UPDATE都將被忽略掉。這個也比較容易理解，畢竟修改操作是獨佔不能共享的。

     上一篇我們捕獲的一個環境的資料如下,這裡可以看到USER_CALLS為56次，那麼我們加速10倍播放，一定會達到5600次。我們來實驗一下。
SQL> select name, directory, status, start_time, end_time, USER_CALLS,TRANSACTIONS from dba_workload_captures; NAME DIRECTORY STATUS START_TIM END_TIME USER_CALLS TRANSACTIONS -------------------- --------------- --------------- --------- --------- ---------- ------------ test_capture_1 DATA_PUMP_DIR COMPLETED 20-APR-14 20-APR-14
56
10

     1.預處理資料
      SQL> exec dbms_workload_replay.process_capture('DATA_PUMP_DIR'); PL/SQL procedure successfully completed

     2.執行重放
      SQL> exec dbms_workload_replay.initialize_replay (replay_name => 'test_replay_1', replay_dir => 'DATA_PUMP_DIR'); PL/SQL procedure successfully completed. SQL> select id,name,PARALLEL,CAPTURE_ID,STATUS,USER_CALLS from DBA_WORKLOAD_REPLAYS; ID NAME PAR CAPTURE_ID STATUS USER_CALLS ---------- ------------------------------ --- ---------- ---------------------------------------- ---------- 61 test_replay_1 NO 65 INITIALIZED SQL> exec DBMS_WORKLOAD_REPLAY.prepare_replay (synchronization => TRUE,SCALE_UP_MULTIPLIER=>100); PL/SQL procedure successfully completed.

     新開一個終端，在終端上的datadump目錄下執行:
      [oracle@11g dpdump]$ wrc system/oracle mode=replay replaydir=/oracle/app/oracle/admin/ora11/dpdump Workload Replay Client: Release 11.2.0.4.0 - Production on Mon Apr 21 20:57:38 2014 Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved. Wait for the replay to start (20:57:38)

     切換回剛才的SQLPLUS視窗，開始執行Replay操作。
      SQL> exec DBMS_WORKLOAD_REPLAY.START_REPLAY(); PL/SQL procedure successfully completed.

     再看終端視窗的顯示。
      Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options [oracle@11g dpdump]$ wrc system/oracle mode=replay replaydir=/oracle/app/oracle/admin/ora11/dpdump Workload Replay Client: Release 11.2.0.4.0 - Production on Mon Apr 21 20:57:38 2014 Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved. Wait for the replay to start (20:57:38) Replay started (20:57:44) Replay finished (20:58:58)

     完成後切換回SQLPLUS下執行查詢。可以看到USER_CALLS是之前的10倍。
      SQL> select id,name,PARALLEL,CAPTURE_ID,STATUS,USER_CALLS from DBA_WORKLOAD_REPLAYS; ID NAME PAR CAPTURE_ID STATUS USER_CALLS ---------- ------------------------------ --- ---------- ---------------------------------------- ---------- 61 test_replay_1 NO 65 COMPLETED 5600

     再看看我們的事務，沒有變化，發現還是10次。
      SQL> connect test/test Connected. SQL> select count(1) from tt;   COUNT(1) ----------         10

     透過這個引數，我們可以模擬更高的查詢併發，預測生成環境未來的負載能力。同時，我們還可以生成更多的報告來進行對比。如果發現某些語句查詢在1000個人下面正常，在1萬、10萬下就變得緩慢，那就需要去整改。比如邏輯讀高的，一點點會話看不出什麼問題的。一大堆會話就容易出現latch:cache buffer chains的等待。這能指導我們進行SQL調整。