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

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

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

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

　　(一) 检查内存相关配置

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

　　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（生产环境的配置方式），而不采用文件系统。二者的性能相差至少一倍。

　　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:ORACLEPRODUCT10.2.0ORADATAEDWTESTAPP03.DBF' SIZE 50M;

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

　　ALTER DATABASE DATAFILE 'D:ORACLEPRODUCT10.2.0ORADATAEDWTESTAPP02.DBF'
　　RESIZE 100M;

　　(五) 检查库表结构

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

　　(六) 检查触发器开关

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

　　select trigger_name from all_triggers where table_name='XXX';

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

　　如果有和本次测试无关的数据库session，需将其结束。

　　SELECT l.session_id sid, 
　　s.serial#, 
　　l.locked_mode, 
　　l.oracle_username, 
　　s.user#, 
　　l.os_user_name, 
　　s.machine, 
　　s.terminal, 
　　a.sql_text, 
　　a.action 
　　FROM v$sqlarea a, 
　　v$session s, 
　　v$locked_object l 
　　WHERE l.session_id = s.sid 
　　AND s.prev_sql_addr = a.address 
　　ORDER BY sid, s.serial#;

　　停止占用资源的session_id：

　　SQL> alter system kill session '1181,9081'; ------'SID','SERIAL#'

　　若数据库中未能停止占用资源的session_id，则查询系统中的p.spid

　　SQL>select p.spid from v$session s, v$process p where s.paddr=p.addr and s.sid=76 and s.serial#=0
　　root#ps -ef |grep p.spid
　　root#kill -9 p.spid

　　(八) 检查redo日志相关

　　检查redo日志的大小和个数是否和生产保持一致，或者是否满足需求。

　　select * from v$log;

　　(九) 检查告警信息

　　如果数据库处于异常状态，测试根本得不到真实结果。例如表空间满了，某个实例挂了等等。而测试环境往往由于测试需要，经常做系统、数据的变更，以满足测试需要，再加上测试环境的数据空间较少，经常会出现数据库状态异常的情况。因此，测试之前看看数据库告警信息是一个必选步骤，也是一个良好的习惯。

　　1. 数据库监控工具

　　如果有数据库监控工具（OEM、TOAD等）连接目标数据库，可采用数据库监控工具的界面查看告警信息，直观方便。

　　2. 采用存储过程检查alert日志

　　这里不详细介绍，可自行查找

　　3. trace目录下查看alert日志

　　如果没有数据库监控工具，手头也没有存储过程，可直接检查trace。

　　切换至oracle用户：su - oracle

　　进入sqlplus接口：$sqlplus ‘/as sysdba’

　　查询alert日志目录：show parameter dump

　　进入trace目录，直接查看alert日志。

　　(十) 检查集群资源

　　检查crs资源状态，预期结果均为online状态。

　　示例：

　　(十一) 检查应用连接集群方式

　　Oracle如果采用RAC方式部署，需要检查生产环境的应用连接方式，比如各数据库实例是否运行，以及是否处理业务。

　　检查节点数据库实例是否运行：

　　srvctl status database -d 数据库名
　　Instance A is not running on node sibpsp1dba
　　Instance B is running on node sibpsp1dbb

　　检查节点是否处理业务：

　　1) 场景开始后可根据各节点的CPU利用率判断是否处理业务；

　　2) 有多种方法设置哪些实例处理业务、哪些不处理业务。

　　以下为客户端tnsnames.ora配置的示例，如下配置说明主用为DBA，只有DBA不工作时才切换到DBB：

　　(十二) 收集统计信息

　　若数据表有较多的增删改操作，则在下一次测试前需要收集统计信息，可使数据库能够针对每个sql语句选择更好的执行计划。

　　exec dbms_stats.gather_table_stats(estimate_percent=>0.1,OWNNAME=>'模式名',tabname=>'表名', cascade=>true,no_invalidate=>FALSE,degree=>8);

　　注：estimate_percent：采样百分比，取值范围为[0.000001,100]，此项可以不进行设置，若不设置，系统将自动设置。如果系统自动选择百分比执行时间过长，可手动设置非常低的百分比；

　　cascade=>true：表示收集详细信息（包括对索引统计信息的收集）；

　　no_invalidate=>FALSE：表示统计信息立即生效，此项必须设置，且需立即生效，否则将影响测试结果；

　　degree：表示并发度，不超过服务器CPU数量的前提下并发越多，收集越快。（例如：10个cpu，可设置5-6个并发）。

　　(十三) 检查数据库同步是否开启

　　检查与备库之间的数据同步是否开启

　　由于数据库同步对数据库的性能表现有一定影响，测试场景需考虑是否设置数据库同步，并对其进行检查。

　　(十四) 系统预热

　　1. 现象描述

　　数据库重启之后，同一个查询语句，执行第一次和第二次的时间不同，在统计信息中部分指标的值也将不同（譬如某次实际测试中，第一次执行需要8秒，第二次执行只需要1秒多）。

　　2. 系统是否预热

　　一般交易系统的数据每次测试前都需要预热，而每天仅执行一次的批处理则无需预热，批处理执行前需重启数据库或者刷新缓存。

　　3. 刷新缓存

　　为了最小化cache对测试的影响，需手动刷新buffer cache，以促使oracle重新执行物理访问（physical reads）。

　　下面3条语句，旨在刷新Oracle的缓存：

　　(1) alter system flush global context

　　应用服务器和数据块服务器通过连接池进行通信，连接池的信息将被保留在SGA中，上述语句将清空这些连接信息。

　　(2) alter system flush shared_pool

　　(3) alter system flush buffer_cache

　　(十五) 存量数据

　　为保证测试结果的可信度，测试环境的存量数据应尽量与生产环境保持一致，包括数据量以及数据分布。

　　尤其是有索引的字段，尽量保证其数据分布与生产一致。

　　其他的数据库参数同样会影响测试结果，但由于变量太多，这里只列出了最容易遇到的问题。毕竟环境检查也是要计算投入产出比的。

作者：yangjianxv    

来源：http://www.51testing.com/html/63/n-7793363.html