【新炬网络名师大讲堂】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调整。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29960155/viewspace-1371326/，如需转载，请注明出处，否则将追究法律责任。