杨建旭
作者杨建旭4天前
技术经理, 中国人民银行清算总中心

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

字数 6195阅读 3308评论 3赞 6

“系统软件配置不得当”占所有“环境配置不得当”至少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;

nw7c7f3jpf
注:一般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

如果有和本次测试无关的数据库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;

eyd6pied1ho

(九) 检查告警信息

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

1. 数据库监控工具

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

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

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

3. trace目录下查看alert日志

如果没有数据库监控工具,手头也没有存储过程,可直接检查trace。
切换至oracle用户:su - oracle
进入sqlplus接口:$sqlplus ‘/as sysdba’
查询alert日志目录:show parameter dump
进入trace目录,直接查看alert日志。

(十) 检查集群资源

检查crs资源状态,预期结果均为online状态。
示例

uthz5k4vqp

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

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:

hkjx1tlysp8

(十二) 收集统计信息

若数据表有较多的增删改操作,则在下一次测试前需要收集统计信息,可使数据库能够针对每个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

(十五) 存量数据

为保证测试结果的可信度,测试环境的存量数据应尽量与生产环境保持一致,包括数据量以及数据分布。
尤其是有索引的字段,尽量保证其数据分布与生产一致

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

作者微信公众号:性能测试与调优

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

6
{}

添加新评论3 条评论

#TiuTiu系统运维工程师, 某软件公司
1天前
非常有用,都是实战经验
#a59011572存储工程师, 广州
3天前
有用,写得挺详细
#michael1983技术经理, 某证券
4天前
非常有用,都是实战经验
Ctrl+Enter 发表

本文隶属于专栏

系统性能测试
49 文章

关于TWT  使用指南  社区专家合作  厂商入驻社区  企业招聘  投诉建议  版权与免责声明  联系我们
© 2019  talkwithtrend — talk with trend,talk with technologist 京ICP备09031017号-30