达梦DM8数据库TPCC压测实战

虚拟机版本	VMwareWorkstation15
CPU	1核
内存	3G
操作系统版本	Kylin-V10-SP2
数据库版本	DM8_20231109_x86_kylin10
BenchmarkSQL	V4.1.1

目录

前言

1.测试步骤

1.1准备BenchmarkSQL

1.2初始化数据库

1.3配置参数

1.4准备测试数据

1.5执行测试

1.6查看测试报告

2.数据库性能优化

2.1性能分析

2.2优化方案

2.3优化结果

3.其他报错及解决方法

---

前言

        本文使用的测试工具是BenchmarkSQL。BenchmarkSQL 是一个支持众多关系型数据库的基准测试工具，通过使用 BenchmarkSQL 对数据库进行 TPC-C 标准测试，即模拟多种事务处理：新订单、支付操作、订单状态查询、发货、库存状态查询等，从而获得最终的压测值。

        本文第1部分介绍达梦DM8数据库使用BenchmarkSQL测试的步骤；第2部分尝试优化DM8数据库，提高测试评分；第3部分记录了测试过程中遇到的问题及解决方法。

1.测试步骤

1.1准备BenchmarkSQL

（1）安装JDK

本文使用的是BenchmarkSql V4.1.1，需要安装V1.7以上的JDK。

（2）解压

unzip benchmarksql-4.1.1.zip

（3）配置驱动

将dm8的jdbc驱动放到lib目录下。

1.2初始化数据库

（1）建库

可以使用现有的数据库，也可以单独创建一个库用于测试。

./dminit path=/dm8/data PORT_NUM=5238

（2）新建用户

BENCHMARKSQL是测试专用用户，必须创建。

SQL> CREATE TABLESPACE TB_BENCHMARKSQL DATAFILE 'TB_BENCHMARKSQL01.dbf' SIZE 1024;
SQL> CREATE USER "BENCHMARKSQL" 	IDENTIFIED BY "123456789" DEFAULT TABLESPACE "TB_BENCHMARKSQL";
SQL> GRANT DBA TO BENCHMARKSQL;

1.3配置参数

配置文件props.dm，文件中必须配置的是：

1）数据库连接信息；

2）压测参数：warehouses、terminals、runMins。

cd ./benchmarksql-4.1.1/run
vi props.dm

参数说明：

warehouses： 被测仓库数（数据规模）

terminals：  并发数（最大仓库数10倍）

runMins：    测试时间（分钟）

这3个参数可按照测试用例的要求配置，例如仓库数100，并发100，测试时间20分钟。

配置文件中下面有5个参数建议不要修改。

1.4准备测试数据

（1）建表

cd ./benchmarksql-4.1.1/run
chmod u+x *.sh
./runSQL.sh props.dm sqlTableCreates

（2）数据装载

注意：这里的仓库数与配置文件对应的参数值要一致

./runLoader.sh props.dm numWarehouses 1

（3）建索引

/runSQL.sh props.dm sqlIndexCreates

（4）收集统计信息

SQL> CALL SYS.DBMS_STATS.GATHER_SCHEMA_STATS('BENCHMARKSQL',100);

1.5执行测试

./runBenchmark.sh props.dm

1.6查看测试报告

前台执行的测试命令，可以直接看到测试结果，如1.5节截图。

还可以通过日志文件查看测试报告：

more ./log/benchmarksql.log

测试报告解读：

tpmC=7479（本次测试得分）

tpmTOTAL=16694.04

tpmC：代表每分钟内系统处理的新订单个数

tpmTOTAL(TPS)：代表每分钟内系统处理的事务总数

Transaction Count：事务总数

参数关系如下：

tpmC = tpmTOTAL * newOrderWeight%

Transaction Count = tpmTOTAL * runMins

2.数据库性能优化

2.1性能分析

（1）查看缓冲池命中率

排查结果：命中率合理，不需要调整。

（2）查看文件分布

SQL> SELECT file_name from SYS.DBA_DATA_FILES ;
SQL> select path from SYS.V$RLOGFILE;

排查结果：数据文件与重做日志文件在同一磁盘，有优化空间

（3）排查慢SQL

SQL> SELECT * FROM   V$LONG_EXEC_SQLS t;
SQL> SELECT * FROM  V$SYSTEM_LONG_EXEC_SQLS  t;

排查结果：没有慢SQL

（4）按累计耗时排查SQL

累计耗时SQL排名

SELECT T.SQL_ID,sql_txt,sum(exec_time) exec_time_sum,avg(exec_time),count(*)
 FROM V$SQL_STAT_HISTORY  t
group by T.SQL_ID,sql_txt
order by exec_time_sum desc;

注：视图V$SQL_STAT_HISTORY中的exec_time之和要小于等于实际执行时间，原因是V$SQL_STAT_HISTORY只保留10000条记录。

上图中前2条是系统SQL，可以忽略。后面是累计用时最多的7个SQL，我们分析下是否有优化空间：

查看SQL_ID=342执行计划

SELECT * from SYS.V$PLN_HISTORY t where t.SQL_ID=342;

SQL:

UPDATE benchmarksql.warehouse SET w_ytd = w_ytd + ?  WHERE w_id = ?

执行计划：

分析：在执行计划中，SSEK2代表二级索引扫描、BLKUP2表示索引的二次扫描。如果将二级索引改为聚集索引，可以提高SQL的检索速度。

查看SQL_ID=347执行计划

SELECT * from SYS.V$PLN_HISTORY t where t.SQL_ID=347;

SQL:

SELECT d_next_o_id, d_tax FROM benchmarksql.district WHERE d_id = ? AND d_w_id = ? FOR UPDATE

执行计划：

分析同上例，如果将二级索引改为聚集索引，可以提高SQL的检索速度。

用同样的方法，查看了累计耗时最多的7个SQL，都存在2级索引扫描的问题。

小结：

（1）缓冲区命中率不需要优化

（2）磁盘IO性能有优化空间，考虑将日志文件、数据文件放到不同的磁盘

（3）没有执行时间超过1000ms的慢SQL

（4）频繁执行的SQL有优化空间

2.2优化方案

（1）磁盘性能优化

新建一块磁盘，挂载到/dmlog目录。

迁移重做日志文件到新的磁盘：

SQL> ALTER DATABAE MOUNT;
SQL> ALTER DATABASE RENAME LOGFILE '/dm/data/DMDB/DMDB02.log' to '/dmlog/DMDB02.log';
SQL> ALTER DATABASE RENAME LOGFILE '/dm/data/DMDB/DMDB01.log' to '/dmlog/DMDB01.log';
SQL> ALTER DATABASE OPEN;

（2）SQL优化方案

编辑创建索引的文件sqlIndexCreates，将主键改为聚集索引主键。

cp sqlIndexCreates sqlIndexCreates2
vi  sqlIndexCreates2

2.3优化结果

删除测试表：

./runSQL.sh props.dm sqlTableDrops

重新测试：

执行1.4节、1.5节的命令，其中创建索引使用sqlIndexCreates2

优化后，tpmC由7479提高到了9354.82，性能提高25%。

3.其他报错及解决方法

以下是测试时遇到的2个报错。

（1）报错：多版本操作冲突

如下图

解决方法：多版本是对一张表修改时，并发量较大导致的。修改 dm.ini 文件里的参数：MVCC_RETRY_TIMES 数据调大，然后重启数据库。

（2）报错：当前光标不在结果集上

如下图：

解决方法：这个问题是props.dm文件中的warehouses值大于装载数据时的numWarehouses导致的。保证这两个值一致就可以了。

本文结束！

20240905