随着信创国产化替代深入越来越多业务从 Oracle 迁移到达梦DM数据库。很多 DBA 刚上手时会习惯性沿用 Oracle 运维思路结果在内存管理、故障排查、性能调优上频频踩坑。本质原因只有一个 两者内存结构看似相似底层模型完全不同直接决定了运维方式天差地别。01先搞懂底层为什么运维会不一样1. Oracle多进程架构一块全局共享内存 SGA每个连接独立私有内存 PGA进程之间内存隔离互不干扰2. 达梦 DM单进程多线程架构整个数据库只有一个主进程dmserver所有线程共用同一块共享内存地址空间没有真正意义上的 PGA私有内存从共享池申请一句话结论 Oracle 是 “分灶吃饭”DM 是 “大锅饭”。Oracle 一个会话崩了不影响全局DM 一个线程失控可能拖垮整个库。02日常运维中的真实差异1.内存查看与监控思路不同Oracle 重点看两块SGA 共享内存数据缓存、SQL 缓存、日志缓冲PGA 私有内存排序、哈希、会话私有show sga;select * from v$pgastat;DM 只盯一块核心共享内存池数据缓冲区 BUFFERSQL 缓存、字典缓存会话私有内存、排序哈希内存均来自这里select * from v$mem_pool;select * from v$bufferpool;运维差异Oracle看命中率、看自动扩展是否正常DM必须盯内存剩余空间光看命中率会误判2.大SQL、排序、哈希连接风险不同Oracle排序、哈希内存来自 PGA进程隔离单个会话内存爆了只会报错退出不影响其他业务DMSORT_BUF_SIZE、HJ_BUF_SIZE 全部来自共享内存池高并发大排序、大表关联极易瞬间吃满内存轻则全库卡顿重则 dmserver 异常退出运维差异Oracle慢SQL影响自身DM慢SQL可能“一颗老鼠屎坏一锅汤”3. 内存溢出OOM后果完全不同OraclePGA 溢出单个进程报错SGA 溢出数据库异常但一般不会整机宕机DM单进程模型任何线程内存越界直接导致 整个数据库进程崩溃日志可能只残留碎片信息定位难度更高运维差异DM 必须严格限制大 SQL 并发、不合理排序与关联、过度连接4. 参数调整Oracle 灵活DM 偏刚性Oracle支持 AMM / ASMM 自动内存管理SGA 组件可在线伸缩大部分参数可动态调整DM核心内存参数多为 静态参数 修改必须重启BUFFER 数据缓冲区MEMORY_POOL 共享内存池RLOG_BUF_SIZE 日志缓冲区运维差异 Oracle 可在线救火调优DM 更依赖前期规划出问题后只能 “事后优化”5. 连接数与高并发风险不同Oracle 每个连接有独立 PGA连接增多内存增长平缓DM 所有会话线程共享一块地址空间连接数暴涨 → 会话上下文内存激增 → 共享池吃紧 → 库夯住运维差异 DM 必须严格控制 MAX_SESSIONS不能盲目扩容连接6. 内存碎片问题DM 更敏感Oracle PGA 独立分配释放碎片影响小DM 多线程频繁申请 / 释放内存易产生 共享内存碎片 表现内存总量充足但提示 “无法分配内存”业务时快时慢重启后明显恢复运维差异 Oracle 基本不用关心碎片DM 需要定期观察内存碎片高发场景需规划周期性重启03一张表看懂核心运维差异04迁移运维建议√ 不要把 DM 当 Oracle 运维 别再用 PGA 思路去理解 DM 的私有内存。√ DM 优先控制大 SQL 全表扫描、大排序、大哈希连接必须提前优化。√ 连接池必须规范 禁止短连接风暴严控最大连接数。√ 内存参数提前规划 不追求极端大内存预留安全余量避免撑满。√ 出现莫名卡顿优先查内存 内存碎片、共享池耗尽是 DM 高频故障点。√ 高并发业务务必压测 尤其排序、统计类报表极易触发内存风险。05 结 语Oracle 与 DM 看似都是关系型数据库内存结构名词也高度相似但底层模型决定了运维逻辑完全不同。从 Oracle 迁移到达梦最危险的不是语法不兼容而是用旧经验运维新架构。理解内存差异才能真正做到平稳迁移、稳定运行。附录1会话内存异常排查1.登录数据库[root ]# /home/dmdba/dmdbms/bin/disql SYSDBA/SYSDBA服务器[LOCALHOST:5236]:处于主库打开状态2.内存使用情况操作系统级别的命令判断TOP、WINDOWS 资源管理器等查看数据占用多少内存。数据库级别的判断数据库使用的内存大致等于 BUFFER_SIZE POOL_SIZE对应的 SQL 语句如下select(select sum(n_pages) * page()/1024/1024 from v$bufferpool)||MB as BUFFER_SIZE,(select sum(total_size)/1024/1024 from v$mem_pool)||MB as mem_pool,(select sum(n_pages) * page()/1024/1024 from v$bufferpool)(select sum(total_size)/1024/1024 from v$mem_pool)||MB as TOTAL_SIZEfrom dual;行号 BUFFER_SIZE mem_pool TOTAL_SIZE---------- ----------- -------- ----------1 1308MB 1780MB 3088MB说明① BUFFER_SIZE系统缓冲区大小以 M 为单位。推荐值系统缓冲区大小为可用物理内存的 60%80%。有效值范围8~1048576。② MEM_POOL共享内存池大小以 M 为单位。共享内存池是由 DM 管理的内存。有效值范围32 位平台为64200064 位平台为6467108864。③ TOTAL_SIZEBUFFER_SIZE 和 MEM_POOL 的总和。3.查看sql占用内存情况内存不足常见原因有如下两种情况① memory_target 设置为 0导致会话使用的内存未释放可以考虑修改 memory_target 参数。② 会话执行的 sql 消耗大量的内存。如下sql查询内存使用较多的语句SELECT SESSID, MAX_MEM_USED||KB,SQL_TXT FROM V$SQL_STATorder by MAX_MEM_USED DESC;行号 SESSID MAX_MEM_USED||KB---------- -------------------- ------------------SQL_TXT------------------------------------------------------------------------------------------------------------------------------------------4 139672852769784 127090624KBselect f_getsequence(?) from dual5 139672684044120 31416064KBUPDATE stat_service_request_trend SET request_sum request_sum 1,success_sum success_sum 1,error_sum error_sum 1 - 1,gtw_error_sum gtw_error_sum 1 - 1,gtw_avg_time (gtw_avg_time * request_sum 232) / (request_sum 1),gtw_total_time gtw_total_time 232,biz_error_sum biz_error_sum 1 -1,biz_avg_time (biz_avg_time * request_sum 209) / (request_sum 1),biz_total_time biz_total_time 209 WHERE (stat_id ?)注意V$SQL_STAT视图需要开启监控功能才能收集数据需设置以下参数ENABLE_MONITOR1MONITOR_SQL_EXEC1ENABLE_MONITOR_DMSQL14.查看内存池使用信息查询内存池使用信息的 sql 语句如下所示单位是 M。select name,is_shared,is_overflow,org_size/1024/1024,TOTAL_size/1024/1024,RESERVED_SIZE/1024/1024,DATA_SIZE/1024/1024,EXTEND_SIZE,TARGET_SIZE,N_EXTEND_NORMAL,N_EXTEND_EXCLUSIVE from v$mem_pool where rownum20 order by TOTAL_size desc;行号 name is_shared is_overflow org_size/1024/1024 TOTAL_size/1024/1024 RESERVED_SIZE/1024/1024 DATA_SIZE/1024/1024---------- --------------- --------- ----------- -------------------- -------------------- ----------------------- --------------------EXTEND_SIZE TARGET_SIZE N_EXTEND_NORMAL N_EXTEND_EXCLUSIVE-------------------- -------------------- --------------- ------------------1 SHARE POOL 000 Y N 500 500 236 14533554432 15728640000 0 02 MON ITEM ARR Y N 9 169 160 1178388608 0 3 03 BACKUP POOL Y N 4 4 0 033554432 4194304 0 04 RT_MEMOBJ_VPOOL Y N 1 1 0 01048576 33554432 0 0说明① N_EXTEND_EXCLUSIVE 如果长期大于 0说明长期从池外扩展可能存在内存泄露需要重点关注。② 若使用到备份池则需要保持高度关注。③ 内存池创建的线程号 creator 可以与 session 的 thrd_id 关联查看对应的某个会话的内存使用情况查看方法可以参考 单个会话内存使用情况。④ 若 RESERVED_SIZE 比 org_size 小说明内存池非常空闲可以减小对应的初始内存避免浪费。⑤ 若 TOTAL_size 比 TARGET_SIZE 大说明内存池不够经常向池外申请需要把对应参数调大。可以通过 v$sysstat 视图监控内存的使用情况select name ,stat_val/1024/1024 from v$sysstat where CLASSID11 ;SQL select name ,stat_val/1024/1024 from v$sysstat where CLASSID11 ;行号 name stat_val/1024./1024.---------- -------------------------------- --------------------1 bytes allocated from os 02 memory pool size in bytes 1773.37487792968753 memory used bytes 1057.37097167968754 memory used bytes from os 9025 hj buffer total used in M 06 hj buffer merge used in M 07 hagr buffer used in M 08 package info cache used in bytes 09 huge buffer total pages 0.0195312510 huge buffer free pages 0.04882812511 huge buffer mem use pages 012 huge buffer mem alloc count 013 huge buffer mem free count 014 huge buffer reserve count 015 sort buf global total size(MB) 0.0009536743164062516 sort buf global used size(MB) 0memory pool size in bytes内存池总的大小。memory used bytes内存池使用的内存大小。memory used bytes from os内存池从操作系统分配的大小5.单个会话内存使用情况SELECT A.CREATOR,B.SQL_TEXT,SUM(A.TOTAL_SIZE)/1024.0/1024.0TOTAL_M,SUM(A.DATA_SIZE) /1024.0/1024.0 DATA_SIZE_MFROM V$MEM_POOL A,V$SESSIONS BWHERE A.CREATOR B.THRD_IDGROUP BY A.CREATOR, B.SQL_TEXTORDER BY TOTAL_M DESC;行号 CREATOR---------- -----------SQL_TEXT------------------------------------------------------------------------------------------------------------------------------------------TOTAL_M DATA_SIZE_M------- -------------------1 3725701 SELECT A.CREATOR , B.SQL_TEXT , SUM(A.TOTAL_SIZE)/1024.0/1024.0 TOT AL_M, SUM(A.DATA_SIZE) /1024.0/1024.0 DATA_SIZE_M FROM V$MEM_POOL A, V$SESSIONS B WHERE A.CREATOR B.THRD_ID GRO UP BY A.CREATOR, B.SQL_TEXT ORDER BY TOTAL_M DESC;27.25 20.63139343261718752 642185select f_getsequence(?) from dual10.1875 2.19039154052734375
Oracle vs DM 内存结构差异：运维必须知道的坑
发布时间：2026/6/5 23:26:46
随着信创国产化替代深入越来越多业务从 Oracle 迁移到达梦DM数据库。很多 DBA 刚上手时会习惯性沿用 Oracle 运维思路结果在内存管理、故障排查、性能调优上频频踩坑。本质原因只有一个 两者内存结构看似相似底层模型完全不同直接决定了运维方式天差地别。01先搞懂底层为什么运维会不一样1. Oracle多进程架构一块全局共享内存 SGA每个连接独立私有内存 PGA进程之间内存隔离互不干扰2. 达梦 DM单进程多线程架构整个数据库只有一个主进程dmserver所有线程共用同一块共享内存地址空间没有真正意义上的 PGA私有内存从共享池申请一句话结论 Oracle 是 “分灶吃饭”DM 是 “大锅饭”。Oracle 一个会话崩了不影响全局DM 一个线程失控可能拖垮整个库。02日常运维中的真实差异1.内存查看与监控思路不同Oracle 重点看两块SGA 共享内存数据缓存、SQL 缓存、日志缓冲PGA 私有内存排序、哈希、会话私有show sga;select * from v$pgastat;DM 只盯一块核心共享内存池数据缓冲区 BUFFERSQL 缓存、字典缓存会话私有内存、排序哈希内存均来自这里select * from v$mem_pool;select * from v$bufferpool;运维差异Oracle看命中率、看自动扩展是否正常DM必须盯内存剩余空间光看命中率会误判2.大SQL、排序、哈希连接风险不同Oracle排序、哈希内存来自 PGA进程隔离单个会话内存爆了只会报错退出不影响其他业务DMSORT_BUF_SIZE、HJ_BUF_SIZE 全部来自共享内存池高并发大排序、大表关联极易瞬间吃满内存轻则全库卡顿重则 dmserver 异常退出运维差异Oracle慢SQL影响自身DM慢SQL可能“一颗老鼠屎坏一锅汤”3. 内存溢出OOM后果完全不同OraclePGA 溢出单个进程报错SGA 溢出数据库异常但一般不会整机宕机DM单进程模型任何线程内存越界直接导致 整个数据库进程崩溃日志可能只残留碎片信息定位难度更高运维差异DM 必须严格限制大 SQL 并发、不合理排序与关联、过度连接4. 参数调整Oracle 灵活DM 偏刚性Oracle支持 AMM / ASMM 自动内存管理SGA 组件可在线伸缩大部分参数可动态调整DM核心内存参数多为 静态参数 修改必须重启BUFFER 数据缓冲区MEMORY_POOL 共享内存池RLOG_BUF_SIZE 日志缓冲区运维差异 Oracle 可在线救火调优DM 更依赖前期规划出问题后只能 “事后优化”5. 连接数与高并发风险不同Oracle 每个连接有独立 PGA连接增多内存增长平缓DM 所有会话线程共享一块地址空间连接数暴涨 → 会话上下文内存激增 → 共享池吃紧 → 库夯住运维差异 DM 必须严格控制 MAX_SESSIONS不能盲目扩容连接6. 内存碎片问题DM 更敏感Oracle PGA 独立分配释放碎片影响小DM 多线程频繁申请 / 释放内存易产生 共享内存碎片 表现内存总量充足但提示 “无法分配内存”业务时快时慢重启后明显恢复运维差异 Oracle 基本不用关心碎片DM 需要定期观察内存碎片高发场景需规划周期性重启03一张表看懂核心运维差异04迁移运维建议√ 不要把 DM 当 Oracle 运维 别再用 PGA 思路去理解 DM 的私有内存。√ DM 优先控制大 SQL 全表扫描、大排序、大哈希连接必须提前优化。√ 连接池必须规范 禁止短连接风暴严控最大连接数。√ 内存参数提前规划 不追求极端大内存预留安全余量避免撑满。√ 出现莫名卡顿优先查内存 内存碎片、共享池耗尽是 DM 高频故障点。√ 高并发业务务必压测 尤其排序、统计类报表极易触发内存风险。05 结 语Oracle 与 DM 看似都是关系型数据库内存结构名词也高度相似但底层模型决定了运维逻辑完全不同。从 Oracle 迁移到达梦最危险的不是语法不兼容而是用旧经验运维新架构。理解内存差异才能真正做到平稳迁移、稳定运行。附录1会话内存异常排查1.登录数据库[root ]# /home/dmdba/dmdbms/bin/disql SYSDBA/SYSDBA服务器[LOCALHOST:5236]:处于主库打开状态2.内存使用情况操作系统级别的命令判断TOP、WINDOWS 资源管理器等查看数据占用多少内存。数据库级别的判断数据库使用的内存大致等于 BUFFER_SIZE POOL_SIZE对应的 SQL 语句如下select(select sum(n_pages) * page()/1024/1024 from v$bufferpool)||MB as BUFFER_SIZE,(select sum(total_size)/1024/1024 from v$mem_pool)||MB as mem_pool,(select sum(n_pages) * page()/1024/1024 from v$bufferpool)(select sum(total_size)/1024/1024 from v$mem_pool)||MB as TOTAL_SIZEfrom dual;行号 BUFFER_SIZE mem_pool TOTAL_SIZE---------- ----------- -------- ----------1 1308MB 1780MB 3088MB说明① BUFFER_SIZE系统缓冲区大小以 M 为单位。推荐值系统缓冲区大小为可用物理内存的 60%80%。有效值范围8~1048576。② MEM_POOL共享内存池大小以 M 为单位。共享内存池是由 DM 管理的内存。有效值范围32 位平台为64200064 位平台为6467108864。③ TOTAL_SIZEBUFFER_SIZE 和 MEM_POOL 的总和。3.查看sql占用内存情况内存不足常见原因有如下两种情况① memory_target 设置为 0导致会话使用的内存未释放可以考虑修改 memory_target 参数。② 会话执行的 sql 消耗大量的内存。如下sql查询内存使用较多的语句SELECT SESSID, MAX_MEM_USED||KB,SQL_TXT FROM V$SQL_STATorder by MAX_MEM_USED DESC;行号 SESSID MAX_MEM_USED||KB---------- -------------------- ------------------SQL_TXT------------------------------------------------------------------------------------------------------------------------------------------4 139672852769784 127090624KBselect f_getsequence(?) from dual5 139672684044120 31416064KBUPDATE stat_service_request_trend SET request_sum request_sum 1,success_sum success_sum 1,error_sum error_sum 1 - 1,gtw_error_sum gtw_error_sum 1 - 1,gtw_avg_time (gtw_avg_time * request_sum 232) / (request_sum 1),gtw_total_time gtw_total_time 232,biz_error_sum biz_error_sum 1 -1,biz_avg_time (biz_avg_time * request_sum 209) / (request_sum 1),biz_total_time biz_total_time 209 WHERE (stat_id ?)注意V$SQL_STAT视图需要开启监控功能才能收集数据需设置以下参数ENABLE_MONITOR1MONITOR_SQL_EXEC1ENABLE_MONITOR_DMSQL14.查看内存池使用信息查询内存池使用信息的 sql 语句如下所示单位是 M。select name,is_shared,is_overflow,org_size/1024/1024,TOTAL_size/1024/1024,RESERVED_SIZE/1024/1024,DATA_SIZE/1024/1024,EXTEND_SIZE,TARGET_SIZE,N_EXTEND_NORMAL,N_EXTEND_EXCLUSIVE from v$mem_pool where rownum20 order by TOTAL_size desc;行号 name is_shared is_overflow org_size/1024/1024 TOTAL_size/1024/1024 RESERVED_SIZE/1024/1024 DATA_SIZE/1024/1024---------- --------------- --------- ----------- -------------------- -------------------- ----------------------- --------------------EXTEND_SIZE TARGET_SIZE N_EXTEND_NORMAL N_EXTEND_EXCLUSIVE-------------------- -------------------- --------------- ------------------1 SHARE POOL 000 Y N 500 500 236 14533554432 15728640000 0 02 MON ITEM ARR Y N 9 169 160 1178388608 0 3 03 BACKUP POOL Y N 4 4 0 033554432 4194304 0 04 RT_MEMOBJ_VPOOL Y N 1 1 0 01048576 33554432 0 0说明① N_EXTEND_EXCLUSIVE 如果长期大于 0说明长期从池外扩展可能存在内存泄露需要重点关注。② 若使用到备份池则需要保持高度关注。③ 内存池创建的线程号 creator 可以与 session 的 thrd_id 关联查看对应的某个会话的内存使用情况查看方法可以参考 单个会话内存使用情况。④ 若 RESERVED_SIZE 比 org_size 小说明内存池非常空闲可以减小对应的初始内存避免浪费。⑤ 若 TOTAL_size 比 TARGET_SIZE 大说明内存池不够经常向池外申请需要把对应参数调大。可以通过 v$sysstat 视图监控内存的使用情况select name ,stat_val/1024/1024 from v$sysstat where CLASSID11 ;SQL select name ,stat_val/1024/1024 from v$sysstat where CLASSID11 ;行号 name stat_val/1024./1024.---------- -------------------------------- --------------------1 bytes allocated from os 02 memory pool size in bytes 1773.37487792968753 memory used bytes 1057.37097167968754 memory used bytes from os 9025 hj buffer total used in M 06 hj buffer merge used in M 07 hagr buffer used in M 08 package info cache used in bytes 09 huge buffer total pages 0.0195312510 huge buffer free pages 0.04882812511 huge buffer mem use pages 012 huge buffer mem alloc count 013 huge buffer mem free count 014 huge buffer reserve count 015 sort buf global total size(MB) 0.0009536743164062516 sort buf global used size(MB) 0memory pool size in bytes内存池总的大小。memory used bytes内存池使用的内存大小。memory used bytes from os内存池从操作系统分配的大小5.单个会话内存使用情况SELECT A.CREATOR,B.SQL_TEXT,SUM(A.TOTAL_SIZE)/1024.0/1024.0TOTAL_M,SUM(A.DATA_SIZE) /1024.0/1024.0 DATA_SIZE_MFROM V$MEM_POOL A,V$SESSIONS BWHERE A.CREATOR B.THRD_IDGROUP BY A.CREATOR, B.SQL_TEXTORDER BY TOTAL_M DESC;行号 CREATOR---------- -----------SQL_TEXT------------------------------------------------------------------------------------------------------------------------------------------TOTAL_M DATA_SIZE_M------- -------------------1 3725701 SELECT A.CREATOR , B.SQL_TEXT , SUM(A.TOTAL_SIZE)/1024.0/1024.0 TOT AL_M, SUM(A.DATA_SIZE) /1024.0/1024.0 DATA_SIZE_M FROM V$MEM_POOL A, V$SESSIONS B WHERE A.CREATOR B.THRD_ID GRO UP BY A.CREATOR, B.SQL_TEXT ORDER BY TOTAL_M DESC;27.25 20.63139343261718752 642185select f_getsequence(?) from dual10.1875 2.19039154052734375
