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调整。

分享到: 更多