系统软件配置不得当”占所有“环境配置不得当”至少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。
一般性能测试都是采用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. 开启/关闭自动扩展
数据文件自动扩展的优势：
- 不会出现因为没有剩余空间可以利用导致数据无法写入；
- 可尽量减少人为的维护；
- 可用于重要级别不是很大的数据库中，如测试数据库等。
数据文件自动扩展的弊端：
-
如果任其扩大，在数据量不断变大的过程中会导致某个数据文件异常的大；
-
针对无人管理的数据库是非常危险的。
测试过程中是否开启自动扩展应与生产尽量保持一致。若测试数据空间特别有限时，首先检查磁盘空间是否充足，若磁盘空间不足，则关闭自动扩展；若磁盘空间充足，则可以打开自动扩展。在打开扩展的条件下，预估场景业务量占用数据库的空间，并预先扩出预估的空间。当业务量很大时，如果在空间不足的情况下打开自动扩展，数据库将容易发生扩充空间的等待事件，进而影响测试结果。
若测试资源与生产资源一致，且生产为不自动扩展，则将测试设置为不自动扩展，利于发现表空间不足的问题。
检查指定的表空间是否为自动扩展：
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个数据块。
因此，大文件表空间只能通过增加数据文件大小的方式来增加表空间。
-
给表空间增加数据文件
ALTER TABLESPACE app_data ADD DATAFILE
'D:ORACLEPRODUCT10.2.0ORADATAEDWTESTAPP03.DBF' SIZE 50M; -
手工改变已存在数据文件的大小
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
检查节点是否处理业务：
- 场景开始后可根据各节点的CPU利用率判断是否处理业务；
- 有多种方法设置哪些实例处理业务、哪些不处理业务。
以下为客户端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
(十五) 存量数据
为保证测试结果的可信度，测试环境的存量数据应尽量与生产环境保持一致，包括数据量以及数据分布。
尤其是有索引的字段，尽量保证其数据分布与生产一致
其他的数据库参数同样会影响测试结果，但由于变量太多，这里只列出了最容易遇到的问题。毕竟环境检查也是要计算投入产出比的。
作者：杨建旭 出处：http://www.talkwithtrend.com/Article/243425 本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接。
