谈如何提高性能测试效率之数据库检查(1)

上一期介绍“被测软件检查”中,提到了“系统软件配置不得当”占所有“环境配置不得当”至少30%,这其中数据库的参数配置对性能的影响最大,需要检查的点也最多,从这一期开始专门介绍数据库的性能测试检查(以Oracle为例,因为Oracle用的最广 ^v^),因为数据库的设计复杂,影响性能测试的点不计其数,预计需要2期写完。

检查的目的是什么呢?如果是测试环境,首先需要检查参数配置是否和生产环境相同或相似,如果是生产环境,需要检查参数配置是否合理。并且,由于数据库的设计逻辑,相同的场景跑几遍,其性能结果也是不同的,所以,环境检查的目的也是要确保测试结果的稳定性、可重复性。

举个例子,第一次跑的时候,数据在磁盘了,跑到过程中调入了内存。第二次跑的时候,数据在内存中,运行明显就快了。第三次跑的时候,Oracle恰好做了自动的统计信息收集,统计信息更准确了,执行计划更新了,这时候,运行的就更快了。检查的过程,需要考虑到数据库的设计逻辑,使测试结果稳定、可重复。

总之,涉及到数据库的场景,尤其是ETL场景与生产结果一致是相当不容易的,我们下面展开来说。

1 检查内存相关配置

为什么首先要检查内存配置呢,因为数据库是内存敏感型的系统,不同的内存配置,性能千差万别。

1. 检查方法

SQL>show parameter

2. 详细解释

Oracle内存参数需检查以下几项:

memory_target

sga_target

pga_aggregate_target

inmemory_size

shared_pool_size

db_cache_size

java_pool_size

db_block_size

注:其中memory包括sga和pga两部分,而inmemory包含在sga中。

性能测试应尽量保证上述参数与生产环境一致。

如果不知道生产环境具体参数,或者系统尚未上线,可以采用Oracle的内存自动管理,即各个参数设置为0,表示系统自动管理。仅设置内存总量memory_target(需小于等于memory_max_target)。

(二) ASM(自动存储管理)检查

1. 检查数据文件和归档文件是否使用ASM

select * from v$datefile;

注:如下图所示,路径以+开头说明使用ASM。

一般性能测试都是采用ASM(生产环境的配置方式),而不采用文件系统。二者的性能相差至少一倍。

2. 查询ASM的利用率,防止测试数据量过大而导致测试失败

select name,total_mb,free_mb from v$asm_diskgroup;

注:一般FRADG存放归档和备份,DATADG存放数据。

(三) 检查归档日志开关

业务数据需要同步到其他数据库时应开启归档日志,反之可以选择关闭(防止空间满)。

同时需计算业务量和归档空间的数量关系,以免空间满造成测试失败。

定时清理归档日志脚本:

http://m.blog.csdn.net/jaune161/article/details/50453868

1. 检查是否启用自动归档

SQL> archive log list;

数据库日志模式 存档模式

自动存档 启用

存档终点 USE_DB_RECOVERY_FILE_DEST

最早的联机日志序列 3322

下一个存档日志序列 3327

当前日志序列 3327

2. 检查归档日志的大小和利用率

SQL> select * from v$flash_recovery_area_usage;

SQL> show parameter db_recovery_file_dest_size;

修改归档日志大小:

SQL> alter system set db_recovery_file_dest_size=30G;

3. 设置非归档

sql> archive log list; #查看是否为归档方式

sql> shutdown immediate;

sql> startup mount; #打开控制文件,不打开数据文件

sql> alter database noarchivelog; #将数据库切换为非归档模式

sql> alter database open; #将数据文件打开

sql> archive log list; #此时便处于非归档模式

注意: 如果是oracle rac,需要所有instance都关了,才可以改。

(四) 表空间相关

1. 根据表名查表空间

select * from dba_tables where table_name='IBPSZDT0101';

2. 查询表空间对应的数据文件

select * from dba_data_files where tablespace_name='名称';

3. 检查表或索引占用空间

利用数据库对象占用空间脚本(show_sapce),检查表或索引占用空间,并根据占用量推算测试需要占用的表空间大小。

4. 开启/关闭自动扩展

数据文件自动扩展的优势:

1) 不会出现因为没有剩余空间可以利用导致数据无法写入;

2) 可尽量减少人为的维护;

3) 可用于重要级别不是很大的数据库中,如测试数据库等。

数据文件自动扩展的弊端:

1) 如果任其扩大,在数据量不断变大的过程中会导致某个数据文件异常的大;

2) 针对无人管理的数据库是非常危险的。

测试过程中是否开启自动扩展应与生产尽量保持一致。若测试数据空间特别有限时,首先检查磁盘空间是否充足,若磁盘空间不足,则关闭自动扩展;若磁盘空间充足,则可以打开自动扩展。在打开扩展的条件下,预估场景业务量占用数据库的空间,并预先扩出预估的空间。当业务量很大时,如果在空间不足的情况下打开自动扩展,数据库将容易发生扩充空间的等待事件,进而影响测试结果。

若测试资源与生产资源一致,且生产为不自动扩展,则将测试设置为不自动扩展,利于发现表空间不足的问题。

检查指定的表空间是否为自动扩展:

SQL> select file_name,autoextensible,increment_by from dba_data_files where tablespace_name = '表空间名';

开启表空间自动扩展功能:

alter database datafile '对应的数据文件路径信息' autoextend on;

关闭表空间自动扩展功能:

alter database datafile '对应的数据文件路径信息' autoextend off;

修改表空间自动增长为每次增长20M,最大空间100M:

alter database datafile '对应的数据文件路径信息' autoextend on next 20m maxsize 100m;

5. 查看表空间的使用率

命令太长,请自行查询。

6. 增加表空间的两种方法

大文件表空间只能对应惟一一个数据文件或临时文件,但其对应的文件大小可达到4G个数据块;而普通表空间最多可以对应1022个数据文件或临时文件,每个文件大小最大可达4M个数据块。

因此,大文件表空间只能通过增加数据文件大小的方式来增加表空间。

1) 给表空间增加数据文件

ALTER TABLESPACE app_data ADD DATAFILE

'D:\ORACLE\PRODUCT\10.2.0\ORADATA\EDWTEST\APP03.DBF' SIZE 50M;

2) 手工改变已存在数据文件的大小

ALTER DATABASE DATAFILE 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\EDWTEST\APP02.DBF'

RESIZE 100M;

(五) 检查库表结构

测试环境的库表结构应与预期库表结构一致,包括索引及触发器。其中,表对应的索引可以通过SQL Developer或PLsql查询、更改。

库表结构不一致,例如,生产环境的索引和测试环境的索引不一样,最后的测试结果害死人呀。

(六) 检查触发器开关

触发器开关需与生产一致。

select trigger_name from all_triggers where table_name='XXX';

在触发器开启和关闭的情况下,系统资源、响应时间相差个百分之二三十是很正常的。

(七) 检查数据库中正在占用资源的session_id

数据库后台执行某些操作时如果报“资源忙、无法执行”(例如执行插入数据的脚本,若前一次执行没有正常结束,再次执行时可能会报此错),则需要找到对应session的id,然后手动将其结束。否则会严重影响本次测试的结果。

(八) 检查redo日志大小和组数

检查redo日志的大小和个数是否和生产保持一致,或者是否满足需求。例如,场景是个大量insert操作的场景,数据库狂写redo日志,那么redo日志的大小和组数对性能产生几倍的影响是很正常的,redo日志切换的时间等待对于insert操作来说是漫长的。

select * from v$log;

这一期先写到这里

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180330G1E41500?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券