大批量测试数据的产生

本文围绕性能测试中大批量测试数据的产生问题展开。介绍了公司标准三层软件架构,阐述了业务数据单项生成的逻辑与步骤,包括业务操作顺序提取、验证方法设计、生成程序编写及数据验证,还给出了ORACLE的PL - SQL脚本示例,最后提及性能测试工具的数据处理。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

我记得前段时间有论坛兄弟问我,性能测试中关于大测试数据产生的问题,因为前段时间比较忙,所以也没有功夫回答,现在不忙了,可以跟大家讨论讨论这个问题。

相比之下,大批量测试数据是针对系统设计的,目前我们公司的软件架构是标准的三层,前台业务操作后,通过CORBA,将数据交给DB处理,我相信国内目前很多的软件都是这样的,或者少了CORBA这一层。

在大批量测试数据产生的操作方面有一个逻辑,就是测试针对业务,我感觉有些朋友在这种测试设计上偏向了硬件方面的性能,对于业务的数据单项生称我可以举个例子:

1.某种业务,通过某种业务规则的数字输入,通过验证后,请再次输入某种认证数字,最终提交。
2.分析该业务操作顺序,如果有ROSE的顺序图或者时序图那是最好了,如果没有那就只能看CODE了,看CODE最关键的是要知道前台取值、两组验证方法和最终数据插入DB顺序动作。
3.设计单项业务数据生成程序
4.验证生成程序的数据是否可以被业务正确操作

第一步是个业务操作的顺序,很简单,我相信大家手头都有一堆的功能测试用例,根据这个提取就可以了。
第二步两组验证方法可能是个关键设计点,这将最终影响你的后续生成数据脚本是否正确,比如第一组验证,首先是在前台做规则验证,然后到Table_res01中取数据进行数据是否存在验证,第二组验证先到Tabl
e_res02中取数据进行数据是否存在验证,然后做该数据的状态位验证,我相信任何系统对输入数据的验证都要比我举的例子复杂。
第三步可以写程序或者使用数据库提供的Script,我门这里ORACLE,所以使用ORACLE的PL-SQL就很明朗了,我提供一个通用的脚本,很简单的:
procedure proc_new_create
is
v_number_status Table_res01.v_number_status % type;--状态位描述01
v_status01 Table_res01.v_number_status % type;--状态位描述02
v_status02 Table_res01.v_number_status % type;--状态位描述03
v_status03 Table_res01.v_number_status % type;--状态位描述04
v_begin_id number;--起始位
v_loop_number number;--生成序列
v_loop_index number;
v_region_code Table_res01.region_code % type;--地区标示

begin

v_begin_id := 0;//起始位0
v_loop_number := 10000;//生成10001个数据
v_region_code := '570';//地区编码
v_number_status:= '#2305';//前置标准码,固定

v_loop_index := 0;

delete from Table_res01 where res_number_status = v_number_status and region_code = v_region_code;
commit;--事先删除旧数据是个好的习惯

while v_loop_index < v_loop_number
loop
v_status01 := v_loop_index + v_begin_id;
v_status02 := '#' || v_status01;
v_status03 := '#' || v_status02 || lpad( to_char( v_loop_index ), 4, '0' );

insert into Table_res01 (status01, status02, status03,number_status)
values(v_status01, v_status02, v_status03,v_number_status);

insert into Table_res02 (status01, status02, status03,number_status)
values(v_status01, v_status02, v_status03,v_number_status);

v_loop_index := v_loop_index + 1;

if mod(v_loop_index, 1000) = 0 then
commit;
end if;

end loop;

v_loop_index := 0;
commit;
end;

这种程序是很简单的,我相信很多人轻易的就可以写出来,实际上业务数据是很复杂的,所以不断的DEBUG是必需的,值得注意的是,不要在正式的数据库中进行调试,如果必须请记录表的SEQUENCES,便于数据的
清除,当然写个配对的删除脚本也是必需的,这种脚本的编写也是巨大的,因为业务数据的受理成功后会给多个表插值,其中涉及大量的数据交叉,写的时候务必小心。

第四步实际上是一个业务验证,严正你写出的脚本产生的数据能被你的业务正确的接受,正确的执行,很简单,做一遍。

如果是性能测试,就要涉及性能测试工具,如果是LR就把数据到出到TXT,然后加入LR测试数据池。如果是自写程序执行验证,可以直接到数据库取值操作,不过这样跟严整的业务没什么两样,就是多了循环次数控制和结
果搜集,很少有人这么做,不过我倒是很希望大家能这样做做,呵呵。

写了这么多,请大家再看后给点自己工作中大数据的生成思路和范例脚本,个人提高困难,大家提高容易!

原文:http://blog.51testing.com/index.php?op=Default&postCategoryId=256&blogId=130

<think>好的,用户问的是DB2中如何实现大批量DELETE操作而不产生事务日志的问题。首先,我需要确认用户的需求场景。通常,大批量删除数据会导致事务日志快速增长,可能影响性能甚至填满日志空间。用户可能遇到了这样的问题,或者想优化删除操作的效率。 接下来,我需要回忆DB2的相关机制。DB2中常规的DELETE语句会记录完整的事务日志,包括每一行的删除操作,这对于大规模数据删除来说确实不高效。用户需要的是减少日志产生的方法。 想到DB2有一个特性叫“不记录日志的操作”,比如使用NOT LOGGED INITIALLY(NLI)的表。在创建表时指定NOT LOGGED INITIALLY,或者临时更改表的属性,可以在特定情况下减少日志记录。但需要用户有权限,并且了解NLI的使用限制,比如表在操作期间不能有备份等。 另外,分区表可能也是一个解决方案。如果表按范围分区,可以直接DROP分区,这属于DDL操作,速度更快且日志量少。但用户可能需要数据是按特定分区键组织的,否则这种方法不适用。 还有,使用LOAD命令替换DELETE操作。LOAD有REPLACE选项,可以快速清空表,并且如果表设置为NOT LOGGED INITIALLY,LOAD操作不会生成大量日志。不过LOAD通常用于导入数据,这里用来删除可能有点取巧,但确实有效。 然后,需要考虑这些方法的风险。比如NLI模式下如果发生故障,数据可能无法恢复,需要用户权衡数据安全性和性能。分区表需要预先设计,可能不适合现有结构未分区的表。 用户可能没有提到表是否分区,或者是否有权限修改表结构,所以需要给出多种方法,让用户根据实际情况选择。同时,提醒用户备份数据,避免误操作。 最后,总结这些方法的适用场景和注意事项,确保用户理解每种方法的优缺点,能够安全有效地实施。</think>在DB2中进行大批量数据删除时,若希望减少事务日志生成量,可通过以下方法实现: 一、常规DELETE的日志痛点 1. 标准DELETE语句会逐行记录事务日志 2. 每删除一条记录都会产生UNDO/REDO日志 3. 大数据量删除时易导致日志空间爆满 二、优化方案(不推荐用于生产关键数据) 1. 使用NOT LOGGED INITIALLY表 ```sql ALTER TABLE your_table ACTIVATE NOT LOGGED INITIALLY; DELETE FROM your_table WHERE condition; COMMIT; ALTER TABLE your_table DEACTIVATE NOT LOGGED INITIALLY; ``` - 特点:批量操作期间不记录UNDO日志 - 限制:操作期间表不能进行备份/恢复 2. 分区表直接DROP(需预先规划) ```sql ALTER TABLE partitioned_table DROP PARTITION partition_name; ``` - 特点:DDL操作,日志量极小 - 要求:表必须按分区键组织数据 3. LOAD替代DELETE(最快方式) ```sql LOAD FROM /dev/null OF DEL REPLACE INTO your_table NONRECOVERABLE; ``` - 效果:直接清空整表 - 日志量:仅记录元数据变更 三、注意事项 1. 非日志操作风险: - 操作中断可能导致数据不一致 - 无法通过事务回滚恢复 2. 必须配套措施: - 操作前执行全量备份 - 确保有容灾恢复方案 - 使用`FORCE APPLICATION ALL`断开连接 四、生产环境建议方案 1. 分批次删除(带提交) ```sql DELETE FROM (SELECT * FROM your_table WHERE condition FETCH FIRST 10000 ROWS ONLY) COMMIT; ``` 2. 使用ADMIN_MOVE_TABLE工具 ```sql CALL SYSPROC.ADMIN_MOVE_TABLE( 'schema', 'source_table', 'target_table', 'DATA ONLY' ); ``` - 特点:在线重组时跳过日志记录 五、验证方法 检查日志使用量: ```sql SELECT APPLID, LOG_READS, LOG_WRITES FROM TABLE(MON_GET_UNIT_OF_WORK(NULL,-1)) WHERE MEMBER = 0; ``` 建议根据实际数据量、恢复需求选择方案,关键业务系统慎用非日志操作。操作前务必进行完整测试环境验证。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值