欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  数据库

Database Replay加压播放参数之SCALE_UP_MULTIPLIER

程序员文章站 2022-06-17 18:08:14
...

当我们要迁移到新的环境之前,我们都想测试下我们新的环境是否能负荷生产的负载。同时,对于一些特殊的应用场景,我们还需要考虑模拟更大的并发量来测试是否能顶住未来的压力。举个简单的例子,我搞个电子商务的网站,我现在每秒能支持1000个人同时在线做查

当我们要迁移到新的环境之前,我们都想测试下我们新的环境是否能负荷生产的负载。同时,对于一些特殊的应用场景,我们还需要考虑模拟更大的并发量来测试是否能顶住未来的压力。举个简单的例子,我搞个电子商务的网站,我现在每秒能支持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调整。