-
达梦数据库的性能优化
“棱镜门”
、
“微软
XP
系统停摆”
的接踵而至给我国信息安全敲响了警钟，
也
加速了国内“去
IOE
”运动的
进程。达梦数据库作为连续
5
年国产数据库市场占
有率第一的高性能、
高可靠性、
高安全性、
高兼容性大型关系型数据库管理系统，
已成功替代了
Oracle
，在电力、金融、电子政务、教育等行业领域得到了广泛
的应用，逐渐成为国家信息化建设的重要基础平台。为了更好地支撑业务应用，
有效管理和利用信息时代不断产生并急剧膨胀的数据，
对达梦数据库的优化显得
尤为重要。
一、
数据库参数优化
1.
优化内存
?
公共内存池
公共内存池提供了一组内
存申请
/
释放接口，为系统中需要动态分配内存的
模块提供服务。
SQL>select *
from v$$dm_ini where para_name like '%MEM%POOL%';
行号
PARA_NAME
PARA_VALUE
---------- ---------------
----------
1 MEMORY_POOL
40
2 MEMORY_BAK_POOL 4
3 N_MEM_POOLS 4
MEMORY_POOL
决定了以
M
为单位的公共内存池的大小，上例中
40M
；
< br>
N_MEM_POOLS
决定把内存池划分为几个独
立的单元，以减少并发访问的冲突，提
升并发效率；
MEMOR
Y_BAK_POOL
表示系统保留的备用内存量，当常规的内存申请
< br>都失败时，从这个备用内存里分配，然后在上层模块中进行必要的容错处理。
<
/p>
可以在
v$$sysstat
中查看当前公
用内存池的使用情况：
SQL>select * from
v$$sysstat where name like '%MEM%';
行号
ID CLASSID
NAME STAT_VAL
--------
-------- ----------- ---------------
--------------------
1 26
3 MEMORY USED BYTES 25831296
这里
的
STAT_VAL
给出的是已经使用的字节数。正常情况下，
应该小于配置
的池大小，否则系统不得不从池外向操作系统申请
/
释放内存，造成效率低下，
并可能把操作系统的内存搞得很零
碎。
?
系统缓冲区
BUFFER
为了加速数
据访问，
系统开辟了一个缓冲区，
使用
LRU
算法存放经常访问的
数据页，逐步淘汰不用的数据页。<
/p>
使用下列参数，可配置基本的系统缓冲区的大小：
SQL>select * from v$$dm_ini where
para_name like '%BUFFER%';
行号
PARA_NAME
PARA_VALUE
---------- ------------
----------
1 HUGE_BUFFER
8
2 BUFFER
4000
3 MAX_BUFFER 8000
4 BUFFER_POOLS
1
其中
HUGE_BUFFER
是专门
用于列存表的缓存区，
BUFFER
是用户行存表的系
统缓冲区。
BUFFER
表示初始的系统缓冲区
大小，单位为
M
。通常情况下，如果物
理数据量大于物理内存，则应该把
BUFFER
调到物理内存的
三分之二比较合适。
当
BUFFER_POOLS = 1
时，系统支持缓冲区的自动扩展。
MAX_BUFFER
表示最
多能扩到多大。
在自动扩展后，
如果系
统的压力在一段时间内比较低，
系统又会
自动收缩缓冲区。
系统缓冲区是一个共享资源，
受一个
mutex
保护，
在一个时间点，
只允许一
个线程可以持有这个资源。
在高并发情
况下，
这个限制将极大降低并发效率，
因
此，可以配置
BUFFER_POOLS
把一个大的系统缓冲
区分割为多个小的部分，每一
个小的部分作为临界资源，
这样只
要所访问的数据页不在同一个子池里，
就不会
发生冲突，从而提
升并发性能。注意，如果配置了
BUFFER_POOLS > 1,
则
MAX_BUFFER
参数就失效了，最大可用的缓
冲区由
BUFFER
参数决定。
?
系统缓冲区
RECYCLE
这是
DM
新引入的缓冲区，
< br>专门用于缓冲临时表空间。
RECYCLE
的淘汰算法与
BUFFER
完全一样，但是它有独立的
HASH
表，
LRU
和更新链。
引入
RECYCLE
的
目的是防止某些复杂查询的中间结果挤占大量的
BUFFER
空间
,
降低
BUFFER
的命
中率，从而增加额外的
IO
操作。
使用
RECYCLE
的场景主要有：
?
大表的散列连接，在内存达到
HJ_BUF_SIZE
时使用
?
排序，大数据量的排序操作，
?
蓄水池操作符，如
:NTTS, SPL, HTAB
等，这些操作符需要把数据收集在
一起
?
临时表数据
?
MAL
系统中，堆积的邮件
?
并行查询中，堆积的消息
?
大字段的临时数据
RECYCLE<
/p>
的配置可以从
V$$DM_INI
查到，单
位
M
SQL>select *
from v$$dm_ini where para_name = 'RECYCLE';
行号
PARA_NAME
PARA_VALUE
---------- ---------
----------
1 RECYCLE 64
2.
利用缓存
DM
的缓存机制，可以避免系统重复的
SQL
解析工作，比如对于
非常耗时的
SQL
语句解析，极大提升系统性能。
SQL
缓存池的大小用
CACHE_POOL_SI
ZE
来设
置，
缺省为
10M
。
< br>如果应用程序对
SQL
语句都是先准备，再绑定参数，然
后反复执行，那么就
不需要计划缓存了。
在这样理想的模式下，
每一种
SQL
语句都使用不同的语句句
柄，
并在应用程序启动之后不久就进行了准备，
执行时使用相应的语句句柄，
并
给定不同的参数。但是
这个理想模式要求有良好的应用设计，有限或很少的
SQL
语句
形式，限制太多。因此
DM
数据库系统提供了计划缓存机制。<
/p>
计划缓存由
USE_PLN_POOL
参数控制，
当
USE_PLN_POOL
=
0
，
禁止计划缓存；
当
USE_PLN_
POOL =
1,SQL
语句需要完全匹配，才能使用计划。比如
:
Selct * from t1
where id = 1;
Select * from
t1 where id = 2;
虽然这两个语句很相似，
计划也基本上一样，
但是因为常量不同，
不能重用
计划。
因此使用精确匹配，
会造成大量类似重复的计
划。
精确匹配一般应该使用
在语句非常复杂，
< br>查询很耗时的分析型场景。
这类场景语句中，
常量取值的
不同
对计划的影响很大。
当
USE_PLN_POOL = 2
时，使用模糊匹配模式。系统首先试图做精确匹配，
如果没有找到合适的计划，
则需要做语法分析，
把常量提取出来，
把语句转
换为
参数的形式，再从计划缓存中查找合适的计划。如果找到，则提取该计划运行，
否则就需要做关系变换和代价分析，并把新生成的计划放入缓存中。
模糊匹配适用于大部分
OLTP
应用，
但是系统还是需要做一遍语法分析
,
需
要
把常量分解出来
,
并重新把语法树反
拼成一个字符串
,
这个过程还把多余空格
,
注
释去掉
,
因此
,
下列两个语句都匹配成同一个计划
:
Select * from t1 where
id = 1;
Select /* this is a test */ *
from t1 where id = 2;
二、
SQL
优化
1.
定位慢的
SQL
要分析性能瓶颈，<
/p>
首先得把执行的又慢、
又多的
SQL
语句找出来，
DM
提供了
< br>SQL
日志的功能，可以将系统中运行的
SQL
语句、语句绑定的参数、
SQL
执行时
间记录到
SQL
日志文件中，并提供参数来进行
过滤，比如只更新
select
语句、
DELETE
语句、
update
语句
、报错的语句等等。
1)
修改
文件
SVR_LOG = 1
SVR_LOG_FILE_NUM =2
SQL_TRACE_MASK =1
SVR_LOG_SWITCH_COUNT =
1000000
#SVR_LOG
：
1
表示开启
SQL
日志功能，
0
表示关闭
#SVR_LOG_FILE_NUM
：
1
表示不切换，
2
表示记录两个日志文件，<
/p>
互相切换
#SQL_LOG_MASK
：要记录的语句类型掩码，
1
表示全部
记录
4:7
表示记录
update
和
se
lect
语句
#SVR_LOG_S
WITCH_COUN:
每个
SQL
日
志文件中记录的消息条数
#
修改完成后需要重启数据库服务
2)
执行系统存储过程开启
--
开启
SQL
日志，记录所有的
< br>SQL
语句，两个文件互相切换
--
每个文件记录
100
万行
--
动态修改
IN
I
参数，无需重启服务
call
sp_set_para_value(1,'SVR_LOG',1);
call
sp_set_para_value(1,'SVR_LOG_FILE_NUM',2);
call
sp_set_para_value(1,'SQL_LOG_MASK',1);
call sp_set_para_value(1,'SVR_LOG_SWITC
H_COUNT',1000000);
通过上面两种方法，
我们成功开启了
SQL
日志功能，那么如何从这些日
志文件中找到性能瓶颈呢？给大家提供一个
SQL
日志分析小工具
（
/?mod=viewthread&tid
=44187&extra=
page%3D1
）
Dmlog_DM7_
该工具运行效果图如下：
分析完成后，会在分析程序所在目录生成一个文件夹，保存分
析结果：
详细的分析
结果保存到一个
excel
文件中
2.
优化慢的
SQL
既然我们已经把执行
的又慢又多的
SQL
语句找到了
,
就马上开始
SQL
优化之
< br>旅吧。