谈如何提高性能测试效率之数据库检查（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;

这一期先写到这里