DM数据库优化

1.参数优化

vim dm.ini
内存参数:

MAX_OS_MEMORY         95     100          
DM 数据库占用的内存占操作系统物理内存和虚拟内存之和百分比,需要设置为 100

BUFFER                100      ***     
用于缓存数据页,一般配置为操作系统物理内存的 60%~80%

MAX_BUFFER            100      ****     
用于控制系统缓冲区的上限,一般配置为和 BUFFER 参数相等

BUFFER_POOLS          1      61   
BUFFER 的分区数,一般配置为质数,取值范围为 1~512,并较大的系统需要配置这个参数;建议BUFFER/BUFFER_POOLS>=500MB ;MAX_BUFFER>BUFFER 时,动态扩展的缓冲区不参与分区

RECYCLE               64    4000       
高并发或大量使用 with、临时表、排序等应该适当调整

RECYCLE_POOLS         1      7         
RECYCLE 的分区数,一般配置为质数,建议                                              RECYCLE/RECYCLE_POOLS>=500MB  

HJ_BUF_GLOBAL_SIZE   500   4000  
HASH 连接操作符的数据总缓存大小(>=HJ_BUF_SIZE),系统级参数,以兆为单位。有效值范围(10~500000)

HJ_BUF_SIZE          50    300     
单个 HASH 连接操作符的数据总缓存大小,以兆为单位。有效值范围。有效值范围(2~100000) 

DICT_BUF_SIZE         5    50     
字典缓冲区大小,以兆为单位当数据库对象较多时建议适当放大

TEMP_SIZE             10   1000  
默认创建的临时表空间大小,以兆为单位。有效值范围(10~1048576 ),不断的扩充临时表空间也会影响性能,生产系统建议改为 1000

VM_POOL_SIZE          64   256     
系统执行时虚拟机内存池大小,在执行过程中用到的内存大部分是从这里申请的。当系统中存储过程、存储函数、包等对象较多时,此参数可以适当放大

SESS_POOL_SIZE        16    256     
会话缓冲区大小,以 KB 为单位,有效值范围(16~1024*1024)。若所申请的内存超过实际能申请的大小,则系统将按 16KB 大小重新申请


CACHE_POOL_SIZE      10     2000    
SQL 缓冲池大小,以兆为单位。有效 值 范 围 : 32 位 平 台 下 为(1~2048);64 位平台下为(1~67108864)。单位:MB

MEMORY_MAGIC_CHECK    2       2        
建议为 2 开启,性能有明显下降的话,可以设置为 1

PK_WITH_CLUSTER       1       0      
在建表语句中指定主关键字时,是否缺省指定 为 CLUSTER,0:不指定;1:指定 注:该参数对列存储表和堆表

CPU参数

WORKER_THREADS      4        16        
工作线程个数,有效值范围 1~64,一般配置为 CPU 核数相等或其 2倍
 
TASK_THREADS            4        16      
任务线程个数,一般配置为与WORKER_THREADS 相等

SESSION相关参数

MAX_SESSION               100    500  
系统允许同时连接的最大数,同时还受到 LICENSE 的限制,取二者中较小的值,有效值范围(1~65000 )

MAX_SESSION_STATEMENT     100    2000              
单个会话上允许同时打开的语句句柄最大数,有的应用忘记关闭语句句柄,导致报错,这个参数可以适当放大

查询相关参数

USE_PLN_POOL         1       1      
是否重用执行计划。0:禁止执行计划的重用;1:启用执行计划的重用功能 ;2:对不包含显式参数的语句进行常量参数化优化;3:即使包含显式参数的语句,也进行常量参数化优化

OLAP_FLAG            0       2        
OLTP 类型的应用建议设置 2,OLAP 类型应用建议设置为 1

OPTIMIZER_MODE       0       1          
OPTIMIZWE_MODE=0,表示使用 老 优 化 器 模 式 ;
OPTIMIZWE_MODE=1,表示使用新优化器模式。新老优化器模式对一些优化的处理方式不同,最主要的不同在于:老优化器采用卡特兰树方式探测最优计划;新优化器模式采用左深二叉树方式探测最优计划,对于CROSS JOIN 尝试采用把左表连接列转为变量 VAR,并下放到右表的处理方式。2016 年以后的 DM7 版本建议使用新优化器,老版本基于老优化器调优好的可以采用老优化器

VIEW_PULLUP_FLAG    0        1     
是否对视图进行上拉优化,把视图转换为其原始定义,消除视图。可取值 0、1、2。0:不进行视图上拉优化;1:对不包含别名和同名列的视图进行上拉优化;2:对包含别名和同名列的视图也进行上拉优化

兼容性参数

COMPATIBLE_MODE        0             2( ORACLE 环境是 2,建 议 根据 源 库类 型 进行设置)
是否兼容其他数据库模式
0:不兼容
1:兼容 SQL92 标准
2:兼容 ORACLE
3:兼容 MS SQL SERVER
4:兼容 MYSQL,
5:兼容 DM6
6:兼容 TERADATA

监控参数

ENABLE_MONITOR      2             1       
启用动态监控功能标记
0:不启用;
1:低级别监控;
2:高级别监控;
3:在高级别监控的基础上增加搜集各操作符的执行时间对性能影响较大,生产环境建议改为 0

日志相关

SVR_LOG        0       0
是否打开 SQL 日志功能,0:表示关闭;1:表 示日志文件非切换模式,但输出的日志格式是 详细模
式;2:表示日志文件为切换模式,输出 的日志也是详细模式;3:表示日志为非切换模 式,但输出日志为简单模式生产环境对性能影响较大,建议改为 0

IO相关

direct_io     0     0或1                      使用 SSD 时推荐为 1

Purge相关

purge_del_opt        0            0             不能修改为 1 或 2

ulimit -a
)1.data seg size
data seg size (kbytes, -d)
建议用户设置为 1048576(即 1GB)以上或 unlimited(无限制),此参数过小
将导致数据库启动失败。

) 2. file size
file size(blocks, -f)
建议用户设置为 unlimited(无限制),此参数过小将导致数据库安装或初始化
失败。

)3. open files
open files(-n)
建议用户设置为 65536 以上或 unlimited(无限制)。
vi /etc/security/limits.conf

 dmdba soft nofile 65536
 dmdba hard nofile 65536

)4.virtual memory
virtual memory (kbytes, -v)
建议用户设置为 1048576(即 1GB)以上或 unlimited(无限制),此参数过小
将导致数据库启动失败。
如 果 用 户 需 要 为 当 前 安 装 用 户 更 改 ulimit 的 资 源 限 制 , 请 修 改 文 件
/etc/security/limits.conf。

)5. max user processes 最大线程数这个参数建议修改为 10240。用 vim
打开配置文件 vi /etc/security/limits.conf 在下面加两行。

dmdba soft nproc 10240
dmdba hard nproc 10240

)6.ls /etc/security/limits.d/ #如果有文件,执行以下操作
vi /etc/security/limits.d/20-nproc.conf 在下面加两行。
(RH6 系统该文件为 90-nproc.conf,RH7 系统该文件为 90-nproc.conf)

dmdba soft nproc 10240
dmdba hard nproc 10240

2.REDO 日志一般应用将两个 REDO 都扩展到 2GB 即可

alter database resize logfile 'DAMENG01.log' to 2048;
alter database resize logfile 'DAMENG02.log' to 2048;
alter database add logfile 'DAMENG03.log' size 2048;
alter database add logfile 'DAMENG04.log' size 2048;

3.LINUX常用性能监控命令
使用top命令查看cpu使用率
使用iostat命令查看磁盘I/O使用情况
使用dstat工具查看磁盘I/O使用情况
使用free命令查看内存使用情况
使用nmon工具监控系统一段时间的整体情况
使用perf top命令查看系统热点情况

4.SQL优化策略

--查询活动会话数
select count(*) from v$sessions where state='ACTIVE';
--已执行超过2秒的活动SQL
select * from (
SELECT sess_id,sql_text,datediff(ss,last_send_time,sysdate) Y_EXETIME,
       SF_GET_SESSION_SQL(SESS_ID) fullsql,clnt_ip
 FROM V$SESSIONS WHERE STATE='ACTIVE')
 where Y_EXETIME>=2;

--锁查询
select o.name,l.* from v$lock l,sysobjects o where l.table_id=o.id and blocked=1

--阻塞查询
with locks as(
  select o.name,l.*,s.sess_id,s.sql_text,s.clnt_ip,s.last_send_time  from v$lock l,sysobjects o,v$sessions s
  where l.table_id=o.id and l.trx_id=s.trx_id ),
 lock_tr as (   select trx_id wt_trxid,row_idx blk_trxid from locks where blocked=1),
 res as(    select sysdate stattime,t1.name,t1.sess_id wt_sessid,s.wt_trxid,
     t2.sess_id blk_sessid,s.blk_trxid,t2.clnt_ip,SF_GET_SESSION_SQL(t1.sess_id) fulsql,
     datediff(ss,t1.last_send_time,sysdate) ss,t1.sql_text wt_sql  from lock_tr s,locks t1,locks t2
    where t1.ltype='OBJECT'  and t1.table_id<>0   and t2.ltype='OBJECT'  and t2.table_id<>0
     and s.wt_trxid=t1.trx_id  and s.blk_trxid=t2.trx_id)
select distinct wt_sql,clnt_ip,ss,wt_trxid,blk_trxid  from res;

生成SQL日志
–设置SQL过滤规则,只记录必要的SQL,生产环境不要设成1
– 2 只记录DML语句 3 只记录DDL语句 22 记录绑定参数的语句
– 25 记录SQL语句和它的执行时间 28 记录SQL语句绑定的参数信息
SELECT SF_SET_SYSTEM_PARA_VALUE(‘SQL_TRACE_MASK’,‘2:3:22:25:28’,0,1);

–同步日志会严重影响系统效率,生产环境必须设置为异步日志
SELECT SF_SET_SYSTEM_PARA_VALUE(‘SVR_LOG_ASYNC_FLUSH’,1,0,1);

–下面这个语句设置只记录执行时间超过200ms的语句
SELECT SF_SET_SYSTEM_PARA_VALUE(‘SVR_LOG_MIN_EXEC_TIME’,200,0,1);

–下面的语句查看设置是否生效
SELECT * FROM V D M I N I w h e r e p a r a n a m e = ′ S V R L O G A S Y N C F L U S H ′ ; S E L E C T ∗ F R O M V DM_INI where para_name='SVR_LOG_ASYNC_FLUSH';SELECT * FROM V DMINIwhereparaname=SVRLOGASYNCFLUSH;SELECTFROMVDM_INI where para_name=‘SQL_TRACE_MASK’;SELECT * FROM V$DM_INI where para_name=‘SVR_LOG_MIN_EXEC_TIME’;

–开启SQL日志:

SP_SET_PARA_VALUE(1, 'SVR_LOG', 1);
--关闭SQL日志:
SP_SET_PARA_VALUE(1, 'SVR_LOG', 0);

SQL日志分析流程
用ETL工程将sql日志入库
在这里插入图片描述
用JAR包分析sql在这里插入图片描述
PS:对于比较大SQL日志(大于10G),建议采用ETL入库,入库较快
SQL日志分析流程
200ms以上的sql汇总在这里插入图片描述
1次以上的sql汇总
在这里插入图片描述
优化目标
并发非常高
SQL特征:数量很少(5%),但是执行频率非常高,甚至达到每秒上百次,只要一慢,系统很可能瘫痪。
优化级别:最优先处理。

并发一般
SQL特征:占大多数(80%),如果有慢的,对系统整体稳定性影响不大,但是会造成局部的某些操作慢。
优化级别:次优先处理。

并发很少特别慢
SQL特征:数量少(15%),往往是很复杂的查询,可能一天就执行几次,对系统整体影响不大,但是优化难度很大。
优化级别:最后处理。

确定目标SQL
如XX项目,入库生产SQL日志,汇总分析,最终找出待优化的3类目标SQL,如下图。接着就去做具体的SQL优化了。
在这里插入图片描述
SQL优化思路
高并发SQL
单个SQL调到最快

  • 普通索引
  • 聚集索引
  • 覆盖索引

优化应用,减少执行次数

  • 应用做结果集缓存
  • 优化应用逻辑,减少无用的执行
  • 将SQL分散其他数据库节点

一般并发SQL
使用索引

  • 单列索引
  • 组合索引

改写SQL

  • left join等价改为inner join
  • 避免隐式转换不走索引
  • 将过滤条件上拉,走索引
  • 用分析函数,减少表扫描

阻塞分析过程
)1、监控阻塞会话,同时保证sql日志已经打开

with locks as(
  select o.name,l.*,s.sess_id,s.sql_text,s.clnt_ip,s.last_send_time  from v$lock l,sysobjects o,v$sessions s
  where l.table_id=o.id and l.trx_id=s.trx_id ),
 lock_tr as (   select trx_id wt_trxid,row_idx blk_trxid from locks where blocked=1),
 res as(    select sysdate stattime,t1.name,t1.sess_id wt_sessid,s.wt_trxid,
     t2.sess_id blk_sessid,s.blk_trxid,t2.clnt_ip,SF_GET_SESSION_SQL(t1.sess_id) fulsql,
     datediff(ss,t1.last_send_time,sysdate) ss,t1.sql_text wt_sql  from lock_tr s,locks t1,locks t2
    where t1.ltype='OBJECT'  and t1.table_id<>0   and t2.ltype='OBJECT'  and t2.table_id<>0
     and s.wt_trxid=t1.trx_id  and s.blk_trxid=t2.trx_id)
select distinct wt_sql,clnt_ip,ss,wt_trxid,blk_trxid  from res;

)2、监控到阻塞信息,并保留数据,供后面分析使用。

在这里插入图片描述
可以看出事务[316624]被事务[316646]所阻塞,后面可以从sql日志中找到完整事务给应用分析。
)3、将SQL日志入库,表名为log_commit,表结构如下:在这里插入图片描述
)4、找出阻塞的两个事务,然后优化慢sql,同时反馈给应用去优化业务

--等待的事务
select trx_id,starttime,sqlstr,exetime from log_commit where trx_id='316624';

--阻塞的源头事务

select trx_id,starttime,sqlstr,exetime 
from log_commit where trx_id='316646';
  • 1
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
dm数据库和MySQL数据库是两种不同的关系型数据库管理系统(RDBMS)。它们在以下几个方面有一些差异: 1. 历史和开发者:DM数据库是由中国科学院计算技术研究所开发的,而MySQL是由瑞典公司MySQL AB开发的。 2. 数据类型:DM数据库支持更多的数据类型,包括位图索引、空间数据类型、JSON数据类型等,而MySQL的数据类型相对较少。 3. 存储引擎:DM数据库使用自家开发的存储引擎,支持事务处理、并发控制和ACID(原子性、一致性、隔离性和持久性)特性。而MySQL具有多个存储引擎可供选择,如InnoDB、MyISAM等。 4. 分区表功能:DM数据库提供了分区表功能,可以将大表分割为更小的片段,以提高查询性能和管理效率。MySQL在某些存储引擎上也支持分区表,但不是所有存储引擎都支持。 5. SQL语法:虽然两者都符合SQL标准,但在某些方面存在细微差异,如DM数据库对日期和时间函数的支持更丰富。 6. 性能和扩展性:DM数据库在处理大规模并发访问时表现较好,并且支持分布式数据库集群。MySQL在小规模应用和简单查询方面表现良好,但在处理大规模数据和高并发负载时可能需要更多的优化和调整。 总的来说,DM数据库和MySQL数据库都是强大的关系型数据库管理系统,适用于不同的应用场景和需求。选择哪个取决于具体的业务需求、性能要求和开发团队的偏好。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值