【新炬網路名師大講堂】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調整。