1. 先弄明白达梦数据库的备份到底和MySQL/Oracle差在哪先说个背景。国产数据库这两年落地越来越多达梦DM是其中比较有代表性的一款。很多团队是从MySQL或者Oracle迁过来的第一反应是“备份不就是mysqldump或者exp/imp嘛”结果上手一查文档才发现达梦的备份还原体系其实更贴近Oracle那一套——物理备份、逻辑备份、归档模式、恢复管理器概念一堆命令也不少。我最早接触达梦的时候也在这上面踩了不少坑所以打算把常用的三种备份还原方法一次讲清楚。这篇文章适合谁看一类是刚接手达梦数据库的DBA另一类是做国产化迁移的开发、运维同学还有一类是公司内部要搭建达梦备份方案但还没定方案的人。看完之后你至少能搞清楚三种方法各自管什么场景、关键参数怎么填、报错怎么排查不用再翻着文档一个一个试。先说结论达梦数据库最常见的备份还原方式有三种——DMRMAN物理冷备份还原、联机热备备份还原、dexp/dimp逻辑备份还原。它们不是互相替代的关系而是对应不同的容灾级别和恢复目标。下面我把每种方法的原理、实操步骤、适用场景和踩坑点都拆开讲。2. 三种备份还原方法的核心区别与选型思路2.1 三套方案本质上在做不同层级的事我第一次用达梦的时候想当然地以为备份就是导出一个文件结果发现这个理解太片面。在达梦里备份还原大致可以分成“物理层”和“逻辑层”两条路线。物理备份是把数据库的数据文件、控制文件、日志这些底层文件整体打包备份。它的特点是恢复出来的是一个完整的数据库实例数据状态和备份时间点一致恢复速度也快。物理备份里又分冷备和热备冷备要求数据库停止服务热备则允许数据库在线运行。逻辑备份是通过工具把库里的对象和数据导出成SQL脚本或dmp格式文件。它不关心底层文件长什么样只关心“逻辑上的数据内容”。逻辑备份的恢复比较灵活可以只恢复某张表、某个模式但它恢复出来的不是完整的物理数据库环境需要先有一个能跑的库再把数据导进去。所以三种方法本质上的区别是方法层级是否要求停机恢复粒度恢复目标DMRMAN冷备物理层必须停机整个数据库快速恢复完整实例联机热备物理层在线执行整个库/表空间/归档高可用场景下的日常备份dexp/dimp逻辑备份逻辑层在线执行库/模式/表/数据数据迁移、指定对象恢复这里有个容易混淆的点联机热备虽然也是物理备份但它必须在归档模式下才能执行。原因后面细讲。2.2 选型看什么业务容忍度、恢复时间目标和迁移场景我的建议是选方案前先回答三个问题数据库能不能停数据丢了能容忍丢多少恢复的时候是想要“整个库活过来”还是“只要某张表的数据”如果业务允许夜间停机窗口那DMRMAN冷备最简单可靠命令少、依赖少新手也不容易出错。如果业务要求7x24在线那就必须用联机热备但代价是要提前把归档模式开好备份策略也要更精细。如果只是做数据迁移、开发环境同步、或者误删了一张表需要单独恢复那dexp/dimp是最合适的因为它的恢复粒度细不必动整个实例。实操中很多团队是混合用的每周日凌晨做一次DMRMAN冷备保底每天做一次联机热备加归档日志需要抽数或迁移时再单独用dexp导出。这样既保证了恢复能力又不至于把所有鸡蛋放一个篮子里。3. 方法一DMRMAN物理冷备份与还原全流程3.1 DMRMAN是什么为什么冷备要选它DMRMAN是达梦自带的恢复管理器功能定位很像Oracle的RMAN。它提供了一组命令行工具在数据库关闭的情况下备份和还原物理文件保证了备份集的一致性。为什么强调“一致性”因为数据库在运行的时候内存里有大量脏数据还没写回数据文件物理层面的文件之间也未必处于一致状态。如果你在数据库跑着的时候直接拷贝数据文件恢复出来的库大概率是损坏的。DMRMAN冷备思路很简单先把数据库干净地停掉内存数据全部落盘这时候文件状态是一致的再打包备份文件恢复时才能保证数据完整可用。我最早用DMRMAN的时候还犯过一个错误以为只要关闭数据库就能直接cp数据文件结果恢复后实例起不来后来才知道达梦的物理备份要用DMRMAN做而非直接拷文件文件名、文件路径、页大小这些元数据都要在备份集里记录下来。3.2 冷备操作步骤从停库到备份集生成DMRMAN的冷备流程我整理成五步每一步都不能跳第一步确认要备份的数据库实例是否干净关闭。用dmserver启动的服务先通过disql登录执行SHUTDOWN IMMEDIATE;或者直接停掉系统服务systemctl stop DmServiceDMSERVER这里要注意停库前最好确认没有未提交的事务SHUTDOWN IMMEDIATE会回滚未完成事务数据不会丢但如果库特别大回滚时间会比较长建议业务低峰期操作。第二步进入DMRMAN工具。/opt/dmdbms/bin/dmrman看到RMAN提示符就对了。DMRMAN默认不带参数进入也可以用CTLFILE参数指定控制文件。第三步执行备份命令。RMAN BACKUP DATABASE /opt/dmdbms/data/DAMENG/dm.ini FULL BACKUPSET /backup/dm_full_bak_20250101;这里路径先说清楚/opt/dmdbms/data/DAMENG/dm.ini是你数据库实例的初始化参数文件不同环境路径不一样可以用ps -ef | grep dmserver查到实际路径。FULL表示全量备份。BACKUPSET后面跟的是备份集存放目录建议目录名带上日期方便后面管理。备份过程中可以观察输出日志正常会显示备份文件的页数、大小、耗时。备份完成后在目标目录会生成一个以备份集命名的目录里面有.bak格式的备份文件。第四步验证备份集是否可用。这一步很多人忽略但我强烈建议养成习惯。在DMRMAN里执行RMAN RESTORE DATABASE /opt/dmdbms/data/DAMENG/dm.ini VALIDATE BACKUPSET /backup/dm_full_bak_20250101;VALIDATE会检查备份集的完整性和一致性如果输出“Validate OK”之类的信息说明这个备份集能用于还原。我有一次就是备份完成后没验证等到要恢复的时候发现备份文件已经损坏了白白浪费了时间。第五步确认备份集信息。RMAN LIST BACKUPSET;这个命令会列出当前登记的备份集方便后续找到要还原的目标。3.3 还原流程先RESTORE再RECOVER顺序不能反还原分两步走理解它们的区别很重要RESTORE是把备份集里的数据文件拷贝回数据目录相当于“搬砖”。RECOVER是用归档日志或备份集里的日志把数据库恢复到一致状态相当于“补数据”。实际操作命令如下# 1. 恢复到备份时的状态 RMAN RESTORE DATABASE /opt/dmdbms/data/DAMENG/dm.ini FROM BACKUPSET /backup/dm_full_bak_20250101; # 2. 应用日志恢复一致性 RMAN RECOVER DATABASE /opt/dmdbms/data/DAMENG/dm.ini FROM BACKUPSET /backup/dm_full_bak_20250101;:wq还原完成后启动数据库systemctl start DmServiceDMSERVER然后登录disql验证数据SELECT COUNT(*) FROM SYSDBA.EMP;冷备最适合的场景是“灾后重建”比如服务器宕机、数据目录损坏、要迁移整库。它的优点简单直接缺点也明确停机窗口内业务不可用而且全量备份的耗时和数据量成正比数据量大到几个TB时备份窗口可能要按小时算。3.4 冷备的局限增量、差异和归档策略怎么补冷备全量为主但实际生产环境不太可能每天做一次全量冷备。达梦DMRMAN也支持增量备份命令格式RMAN BACKUP DATABASE /opt/dmdbms/data/DAMENG/dm.ini INCREMENT WITH BASE BACKUPSET /backup/dm_full_bak_20250101 BACKUPSET /backup/dm_inc_bak_20250102;参数说明INCREMENT表示增量备份WITH BASE BACKUPSET指定上一次的全量备份集作为基线。恢复的时候需要把全量备份集和后续所有增量备份集按顺序恢复顺序一旦搞错就会报错。不过我的经验是如果已经决定用DMRMAN做冷备优先保证“全量冷备归档日志保留”的组合。增量备份虽然节省空间但恢复链变长任何一环坏了都会麻烦。冷备冷备备的就是一份确定性很高的底稿。4. 方法二联机热备SQL方式实现不停机备份还原4.1 为什么必须有归档模式它解决什么问题联机热备听起来很美好数据库不停机就能做物理备份但它有一个硬前提数据库必须开启归档模式。原因不复杂。热备的瞬间数据库还在持续写入备份出来的数据文件可能处于“中间状态”——有的文件包含了备份之后的新数据有的文件还没写到。这样还原出来肯定不一致。归档日志的作用就是记录从备份开始到备份结束期间的每一次数据变更。还原时先还原备份集再应用这段时间的归档日志就能把数据库推到一致状态。打个比方备份相当于给一本书拍照拍的时候有人还在翻页照片里那一页可能没拍全。归档日志就是翻页过程的录像把录像补上整本书的内容就完整了。所以不开启归档联机热备就是空中楼阁。4.2 开启归档模式的具体操作第一次开归档的时候我也折腾了一阵因为达梦默认不开启归档需要手动配置。步骤如下第一步查看当前归档状态。SELECT ARCH_MODE FROM V$DATABASE;如果返回NO说明没开归档。第二步设置归档目录。编辑dm.ini文件中和归档相关参数或者直接用SQL动态配置。我推荐用SQL方式不用重启即可生效ALTER DATABASE ADD ARCHIVELOG DEST/opt/dmdbms/arch, TYPELOCAL, FILE_SIZE128, SPACE_LIMIT5120;参数说明DEST是归档日志存放目录TYPELOCAL表示本地归档FILE_SIZE是单个归档文件大小MBSPACE_LIMIT是整个归档目录上限MB超过上限后达梦会自动清理最老的归档文件。生产环境建议SPACE_LIMIT设大一些至少能容纳两到三个备份周期的归档量。第三步修改数据库为归档模式。ALTER DATABASE SET ARCHIVELOG;注意有些版本执行这条命令也要求数据库处于mount状态会短暂中断业务。如果是生产库最好在维护窗口操作。操作完再查一次ARCH_MODE变成YES就说明归档已经开启。4.3 联机备份的SQL命令与常用参数开启归档后就可以在disql里执行备份命令了。最基础的全库备份BACKUP DATABASE FULL BACKUPSET /backup/dm_onl_bak_20250101;如果想备份到指定目录并带说明可以加BACKUPINFO参数BACKUP DATABASE FULL BACKUPSET /backup/dm_onl_bak_20250101 BACKUPINFO 全量备份-20250101;除了整库备份联机备份还支持更细粒度的对象-- 备份指定表空间 BACKUP TABLESPACE MAIN FULL BACKUPSET /backup/dm_tbs_main_bak_20250101; -- 备份归档日志 BACKUP ARCHIVELOG ALL BACKUPSET /backup/dm_arch_bak_20250101;表空间级备份的用处在于如果某个核心业务表空间比较大可以单独给它做高频备份不用每次全库跑一遍。归档日志备份则是为了配合还原时把数据库恢复到更精确的时间点。联机备份的时候数据库会有额外IO开销建议不要在业务高峰期跑尤其是大库全量备份磁盘带宽可能被占满。我一般安排在凌晨两点到五点之间配合crontab定时任务执行。4.4 联机还原整库恢复和时间点恢复联机备份的还原过程和DMRMAN类似也是RESTORERECOVER两步但是可以在数据库在线的情况下执行部分操作。整库还原的SQLRESTORE DATABASE FROM BACKUPSET /backup/dm_onl_bak_20250101; RECOVER DATABASE FROM BACKUPSET /backup/dm_onl_bak_20250101;如果要做时间点恢复比如只想恢复到当天上午10点的状态可以这样RECOVER DATABASE WITH ARCHIVELOG UNTIL TIME 2025-01-01 10:00:00;这里要提前把归档日志备份好否则无法向前推进到这个时间点。时间点恢复在误删数据、误执行未带条件的UPDATE/DELETE这类事故里特别有用。联机热备和DMRMAN冷备的建议组合是这样的日常备份用联机热备每周挑一个低峰窗口做一次DMRMAN冷备。热备负责“天天有备份”冷备负责“兜底”。4.5 联机热备的注意事项联机热备容易踩的坑我列一下归档目录满了会导致数据库写入阻塞。这是个很隐蔽的问题数据库突然卡住一看归档日志目录满了。所以归档目录必须有监控告警空间上限根据业务写入量动态调整。备份过程中不要执行DDL操作。联机备份虽然不影响DML但备份期间如果有DDL变更加字段、建索引备份集可能不一致还原时会报错。备份路径不能用相对路径要用绝对路径。用相对路径生成的备份集在还原时会因为找不到目录而失败。定期做RESTORE ... VALIDATE验证备份集的可用性这个习惯比多做一次备份更重要。5. 方法三dexp/dimp逻辑备份还原灵活但要知道边界5.1 逻辑备份的定位导出和导入的是“数据”不是“数据库”dexp和dimp是达梦自带的逻辑导出导入工具对应Oracle的exp/imp。它们不涉及底层数据文件而是把数据库里的对象定义、数据内容读取出来写成二进制的dmp文件。dimp再把dmp文件里的内容导进目标库。因为这个特点逻辑备份还原解决了物理备份解决不了的两个问题一是跨平台迁移比如从x86的达梦导出的数据可以导入到ARM架构的达梦库二是恢复粒度细可以只导一张表、一个模式不惊动整库。但它也有明显的边界逻辑备份不包含数据库配置参数、用户权限、存储过程依赖关系等全部物理信息。换句话说它恢复的是“数据内容”不等于“数据库本身”。如果你把数据误删了想用dmp恢复前提是目标库结构还在如果你连整个库都坏了逻辑备份帮不上忙还得靠物理备份。5.2 dexp导出的命令格式与参数说明dexp工具在达梦安装目录的bin下面命令行写法如下/opt/dmdbms/bin/dexp SYSDBA/SYSDBAlocalhost:5236 FILE/backup/dm_logic_bak_20250101.dmp LOG/backup/dm_logic_bak_20250101.log FULLY参数一点点拆开讲SYSDBA/SYSDBAlocalhost:5236连接信息格式是用户名/密码IP:端口。生产环境不建议用SYSDBA可以创建一个专门用于备份的账号授权对应权限。FILE导出文件的路径和名称。LOG日志文件路径日志里会记录导出的每张表、每个对象排查问题基本靠它。FULLY全库导出。如果只想导出某个模式改成SCHEMAS用户名只想导出某几张表用TABLES表名1,表名2。常用参数组合# 导出指定模式下的所有对象和数据 dexp backup_user/backup_userlocalhost:5236 FILE/backup/dm_schema_bak.dmp SCHEMASBUSINESS # 只导出两张表不带索引和触发器 dexp backup_user/backup_userlocalhost:5236 FILE/backup/dm_tables.dmp TABLESEMP,DEPT INDEXESN TRIGGERSN有个细节要注意TABLES参数导出的表数据比较大时建议加PARALLEL4之类的并行度参数速度提升明显但会占用更多内存和CPU。5.3 dimp导入的命令格式与常见处理逻辑dimp的参数和dexp基本对称导入命令示例如下/opt/dmdbms/bin/dimp SYSDBA/SYSDBAlocalhost:5236 FILE/backup/dm_logic_bak_20250101.dmp LOG/backup/dm_imp_20250101.log FULLY如果是把导出的数据导入到另一个模式用REMAP_SCHEMA参数dimp SYSDBA/SYSDBAlocalhost:5236 FILE/backup/dm_schema_bak.dmp REMAP_SCHEMABUSINESS:BUSINESS_NEW这个参数在开发环境同步时特别常用比如把生产库某个模式的数据同步到测试库同时不想覆盖测试库现有结构。导入过程中最常见的问题是“对象已存在”因为目标库里可能已经建了部分表。可以用TABLE_EXISTS_ACTION参数控制dimp SYSDBA/SYSDBAlocalhost:5236 FILE/backup/dm_table.dmp TABLESEMP TABLE_EXISTS_ACTIONREPLACETABLE_EXISTS_ACTION的常用值有SKIP跳过已存在的表、APPEND追加数据、REPLACE先删掉再建。我的建议是默认用SKIP确定要覆盖数据时才用REPLACE不然容易把目标库的已有数据搞丢。5.4 逻辑备份的典型场景迁移、同步和误删恢复我在实际工作里逻辑备份用得最多的场景有三个第一个是国产化迁移。比如从其他数据库迁到达梦或者达梦不同版本之间升级迁移dexp导出、dimp导入是最常见的操作路径。注意源库和目标库的字符集要一致否则中文会变成乱码别问我怎么知道的。第二个是环境间数据同步。开发环境、测试环境需要拿生产环境的脱敏数据来用全量物理备份恢复太重dexp导出指定模式的dmp再导入目标环境又快又灵活。第三个是误删单表数据。如果只是某张表的数据被误删了用dimp单独导入这张表的dmp文件比从物理备份里恢复整库要快得多。前提是你有这张表的逻辑备份。6. 三种备份方案的对比与日常运维建议6.1 对比总结一张表看清差异三种方法都能实现备份还原但粒度、窗口、适用场景完全不同。对比维度DMRMAN冷备联机热备dexp/dimp逻辑备份是否需要停机需要不需要不需要备份内容物理数据文件控制信息物理数据文件归档日志SQL逻辑对象和数据恢复单位整库整库/表空间/时间点库/模式/表恢复速度最快快慢逐条执行SQL是否依赖归档不依赖必须开启归档不依赖典型场景灾难恢复、整库迁移日常在线备份数据抽取、表级恢复有一类场景值得拿出来特别说如果你只是想“把库从A服务器搬到B服务器”物理备份DMRMAN冷备是最优解因为它把文件搬过去就能用速度远快于dexp导出再dimp导入。但如果是“把生产数据抽几张表给开发用”物理备份就杀鸡用牛刀了逻辑备份才是正解。方案没有好坏只有合不合适。6.2 建一套靠谱的备份策略比会敲命令更重要命令好学策略难定。我建议最小化备份策略至少包含三样东西周期性的全量物理备份可以用DMRMAN冷备或联机热备。归档日志的持续保留至少保留一个完整备份周期。定期的逻辑备份覆盖重要业务表和关键配置表。然后强烈建议做备份恢复演练。我见过不止一家公司备份任务天天成功但从来没真正还原过等到灾难发生才发现备份集坏了、归档日志断了、或者还原步骤早就忘了。备份的价值只有在“能恢复”时才体现。还原演练的频率不用太高每季度做一次完整的恢复演练就行挑一个测试环境把最近的备份集还原起来验证数据一致性和关键表数据量。6.3 达梦备份的常见报错与排查速查表备份还原过程中容易出问题的地方我总结了一份速查表。报错或异常现象可能原因排查与解决思路还原时提示备份集无效或损坏备份文件损坏、路径不对用VALIDATE检查备份集完整性确认路径无权限问题联机备份报“非归档模式”数据库未开启归档检查V$DATABASE.ARCH_MODE开启归档后重试备份过程中数据库卡住归档目录满了检查归档目录空间清理或扩容归档空间dexp导出中文乱码源库和目标库字符集不一致统一字符集导出时指定CHARSET参数dimp导入报“对象已存在”目标库已有同名对象用TABLE_EXISTS_ACTIONSKIP跳过或REPLACE覆盖还原后实例起不来RESTORE和RECOVER顺序错误或者缺少归档日志确认先RESTORE再RECOVER补全归档日志后再启动DMRMAN找不到配置文件dm.ini路径写错用ps -ef这里额外强调一下归档日志的坑。归档满了达梦会挂起写入操作表现就是业务突然变慢、SQL堆积但数据库进程还在。很多时候第一反应是查锁、查会话忽略了归档目录。所以监控系统里一定要加上归档目录使用率阈值设到80%就告警别等写满了再处理。6.4 命令不是唯一的路管理工具也能做备份还原除了命令行达梦自带的图形化管理工具也支持备份还原操作。工具名叫manager一般在安装目录的tool下/opt/dmdbms/tool/manager用图形界面做备份的好处是直观点击按钮就能配置备份目录、选择备份类型适合不熟悉命令行的同事。但它本质上生成的还是前面讲的这三类备份。我的建议是日常维护用命令行教学演示和应急操作可以用图形界面因为图形界面能减少手误但自动化脚本和定时任务最终还是落到命令行上。7. 我踩过的几个备份还原的坑提前帮你避开第一个坑是备份目录和数据库放在同一块磁盘上。我刚开始接手达梦的时候图省事把备份目录放在了数据盘下结果磁盘满了之后数据库直接停止写入。备份的意义是什么是数据坏了还能恢复。备份目录和数据文件同盘等于保险柜和现金放在同一间屋子里火灾一来全没了。备份目录一定要独立磁盘最好是单独的挂载点有条件的话再考虑异地备份。第二个坑是还原的时候没注意备份集的生成时间。我干过一次特别蠢的事数据库有两天的备份集要恢复的是前一天的数据结果我一着急拿了两天前的备份集还原恢复完成后才发现数据少了一天。所以执行还原之前先LIST BACKUPSET看清楚每个备份集的时间和类型确认无误后再操作。灾难恢复的时候人容易紧张越紧张越容易出错提前把流程写下来、把命令准备好能避免很多低级失误。第三个坑是逻辑备份的权限问题。用dexp导出时如果账号权限不够导出的dmp文件可能缺表缺数据但日志里只显示“对象不存在”之类的模糊信息。建议导出前确认账号有没有对应模式的SELECT权限导出后用grep -i error 日志文件过滤一下日志确认没有大量报错再结束任务。第四个坑是裸拷贝数据文件代替DMRMAN备份。这个我前面提到过但还是想单独强调。数据库运行期间那些数据文件一直在动直接拷贝出来的文件时间点完全不一致恢复后大概率报文件损坏或者实例无法启动。备份就用官方工具做别图省事用cp或者rsync。最后一个建议备份脚本写好之后一定要加日志轮转和失败告警。备完只是第一步备得成不成、日志有没有异常这些信息要能自动送到运维手里。我自己常用的做法是把备份日志输出到固定目录然后定时任务里加一个tail检测发现包含“ERROR”或者“FAIL”就触发告警通知。看似简陋但非常有效。 
长河君 · 2026/9/18 3:01:25 · 阅读 1.2k 达梦数据库备份还原全攻略：DMRMAN冷备、联机热备与逻辑备份详解
1. 先弄明白达梦数据库的备份到底和MySQL/Oracle差在哪先说个背景。国产数据库这两年落地越来越多达梦DM是其中比较有代表性的一款。很多团队是从MySQL或者Oracle迁过来的第一反应是“备份不就是mysqldump或者exp/imp嘛”结果上手一查文档才发现达梦的备份还原体系其实更贴近Oracle那一套——物理备份、逻辑备份、归档模式、恢复管理器概念一堆命令也不少。我最早接触达梦的时候也在这上面踩了不少坑所以打算把常用的三种备份还原方法一次讲清楚。这篇文章适合谁看一类是刚接手达梦数据库的DBA另一类是做国产化迁移的开发、运维同学还有一类是公司内部要搭建达梦备份方案但还没定方案的人。看完之后你至少能搞清楚三种方法各自管什么场景、关键参数怎么填、报错怎么排查不用再翻着文档一个一个试。先说结论达梦数据库最常见的备份还原方式有三种——DMRMAN物理冷备份还原、联机热备备份还原、dexp/dimp逻辑备份还原。它们不是互相替代的关系而是对应不同的容灾级别和恢复目标。下面我把每种方法的原理、实操步骤、适用场景和踩坑点都拆开讲。2. 三种备份还原方法的核心区别与选型思路2.1 三套方案本质上在做不同层级的事我第一次用达梦的时候想当然地以为备份就是导出一个文件结果发现这个理解太片面。在达梦里备份还原大致可以分成“物理层”和“逻辑层”两条路线。物理备份是把数据库的数据文件、控制文件、日志这些底层文件整体打包备份。它的特点是恢复出来的是一个完整的数据库实例数据状态和备份时间点一致恢复速度也快。物理备份里又分冷备和热备冷备要求数据库停止服务热备则允许数据库在线运行。逻辑备份是通过工具把库里的对象和数据导出成SQL脚本或dmp格式文件。它不关心底层文件长什么样只关心“逻辑上的数据内容”。逻辑备份的恢复比较灵活可以只恢复某张表、某个模式但它恢复出来的不是完整的物理数据库环境需要先有一个能跑的库再把数据导进去。所以三种方法本质上的区别是方法层级是否要求停机恢复粒度恢复目标DMRMAN冷备物理层必须停机整个数据库快速恢复完整实例联机热备物理层在线执行整个库/表空间/归档高可用场景下的日常备份dexp/dimp逻辑备份逻辑层在线执行库/模式/表/数据数据迁移、指定对象恢复这里有个容易混淆的点联机热备虽然也是物理备份但它必须在归档模式下才能执行。原因后面细讲。2.2 选型看什么业务容忍度、恢复时间目标和迁移场景我的建议是选方案前先回答三个问题数据库能不能停数据丢了能容忍丢多少恢复的时候是想要“整个库活过来”还是“只要某张表的数据”如果业务允许夜间停机窗口那DMRMAN冷备最简单可靠命令少、依赖少新手也不容易出错。如果业务要求7x24在线那就必须用联机热备但代价是要提前把归档模式开好备份策略也要更精细。如果只是做数据迁移、开发环境同步、或者误删了一张表需要单独恢复那dexp/dimp是最合适的因为它的恢复粒度细不必动整个实例。实操中很多团队是混合用的每周日凌晨做一次DMRMAN冷备保底每天做一次联机热备加归档日志需要抽数或迁移时再单独用dexp导出。这样既保证了恢复能力又不至于把所有鸡蛋放一个篮子里。3. 方法一DMRMAN物理冷备份与还原全流程3.1 DMRMAN是什么为什么冷备要选它DMRMAN是达梦自带的恢复管理器功能定位很像Oracle的RMAN。它提供了一组命令行工具在数据库关闭的情况下备份和还原物理文件保证了备份集的一致性。为什么强调“一致性”因为数据库在运行的时候内存里有大量脏数据还没写回数据文件物理层面的文件之间也未必处于一致状态。如果你在数据库跑着的时候直接拷贝数据文件恢复出来的库大概率是损坏的。DMRMAN冷备思路很简单先把数据库干净地停掉内存数据全部落盘这时候文件状态是一致的再打包备份文件恢复时才能保证数据完整可用。我最早用DMRMAN的时候还犯过一个错误以为只要关闭数据库就能直接cp数据文件结果恢复后实例起不来后来才知道达梦的物理备份要用DMRMAN做而非直接拷文件文件名、文件路径、页大小这些元数据都要在备份集里记录下来。3.2 冷备操作步骤从停库到备份集生成DMRMAN的冷备流程我整理成五步每一步都不能跳第一步确认要备份的数据库实例是否干净关闭。用dmserver启动的服务先通过disql登录执行SHUTDOWN IMMEDIATE;或者直接停掉系统服务systemctl stop DmServiceDMSERVER这里要注意停库前最好确认没有未提交的事务SHUTDOWN IMMEDIATE会回滚未完成事务数据不会丢但如果库特别大回滚时间会比较长建议业务低峰期操作。第二步进入DMRMAN工具。/opt/dmdbms/bin/dmrman看到RMAN提示符就对了。DMRMAN默认不带参数进入也可以用CTLFILE参数指定控制文件。第三步执行备份命令。RMAN BACKUP DATABASE /opt/dmdbms/data/DAMENG/dm.ini FULL BACKUPSET /backup/dm_full_bak_20250101;这里路径先说清楚/opt/dmdbms/data/DAMENG/dm.ini是你数据库实例的初始化参数文件不同环境路径不一样可以用ps -ef | grep dmserver查到实际路径。FULL表示全量备份。BACKUPSET后面跟的是备份集存放目录建议目录名带上日期方便后面管理。备份过程中可以观察输出日志正常会显示备份文件的页数、大小、耗时。备份完成后在目标目录会生成一个以备份集命名的目录里面有.bak格式的备份文件。第四步验证备份集是否可用。这一步很多人忽略但我强烈建议养成习惯。在DMRMAN里执行RMAN RESTORE DATABASE /opt/dmdbms/data/DAMENG/dm.ini VALIDATE BACKUPSET /backup/dm_full_bak_20250101;VALIDATE会检查备份集的完整性和一致性如果输出“Validate OK”之类的信息说明这个备份集能用于还原。我有一次就是备份完成后没验证等到要恢复的时候发现备份文件已经损坏了白白浪费了时间。第五步确认备份集信息。RMAN LIST BACKUPSET;这个命令会列出当前登记的备份集方便后续找到要还原的目标。3.3 还原流程先RESTORE再RECOVER顺序不能反还原分两步走理解它们的区别很重要RESTORE是把备份集里的数据文件拷贝回数据目录相当于“搬砖”。RECOVER是用归档日志或备份集里的日志把数据库恢复到一致状态相当于“补数据”。实际操作命令如下# 1. 恢复到备份时的状态 RMAN RESTORE DATABASE /opt/dmdbms/data/DAMENG/dm.ini FROM BACKUPSET /backup/dm_full_bak_20250101; # 2. 应用日志恢复一致性 RMAN RECOVER DATABASE /opt/dmdbms/data/DAMENG/dm.ini FROM BACKUPSET /backup/dm_full_bak_20250101;:wq还原完成后启动数据库systemctl start DmServiceDMSERVER然后登录disql验证数据SELECT COUNT(*) FROM SYSDBA.EMP;冷备最适合的场景是“灾后重建”比如服务器宕机、数据目录损坏、要迁移整库。它的优点简单直接缺点也明确停机窗口内业务不可用而且全量备份的耗时和数据量成正比数据量大到几个TB时备份窗口可能要按小时算。3.4 冷备的局限增量、差异和归档策略怎么补冷备全量为主但实际生产环境不太可能每天做一次全量冷备。达梦DMRMAN也支持增量备份命令格式RMAN BACKUP DATABASE /opt/dmdbms/data/DAMENG/dm.ini INCREMENT WITH BASE BACKUPSET /backup/dm_full_bak_20250101 BACKUPSET /backup/dm_inc_bak_20250102;参数说明INCREMENT表示增量备份WITH BASE BACKUPSET指定上一次的全量备份集作为基线。恢复的时候需要把全量备份集和后续所有增量备份集按顺序恢复顺序一旦搞错就会报错。不过我的经验是如果已经决定用DMRMAN做冷备优先保证“全量冷备归档日志保留”的组合。增量备份虽然节省空间但恢复链变长任何一环坏了都会麻烦。冷备冷备备的就是一份确定性很高的底稿。4. 方法二联机热备SQL方式实现不停机备份还原4.1 为什么必须有归档模式它解决什么问题联机热备听起来很美好数据库不停机就能做物理备份但它有一个硬前提数据库必须开启归档模式。原因不复杂。热备的瞬间数据库还在持续写入备份出来的数据文件可能处于“中间状态”——有的文件包含了备份之后的新数据有的文件还没写到。这样还原出来肯定不一致。归档日志的作用就是记录从备份开始到备份结束期间的每一次数据变更。还原时先还原备份集再应用这段时间的归档日志就能把数据库推到一致状态。打个比方备份相当于给一本书拍照拍的时候有人还在翻页照片里那一页可能没拍全。归档日志就是翻页过程的录像把录像补上整本书的内容就完整了。所以不开启归档联机热备就是空中楼阁。4.2 开启归档模式的具体操作第一次开归档的时候我也折腾了一阵因为达梦默认不开启归档需要手动配置。步骤如下第一步查看当前归档状态。SELECT ARCH_MODE FROM V$DATABASE;如果返回NO说明没开归档。第二步设置归档目录。编辑dm.ini文件中和归档相关参数或者直接用SQL动态配置。我推荐用SQL方式不用重启即可生效ALTER DATABASE ADD ARCHIVELOG DEST/opt/dmdbms/arch, TYPELOCAL, FILE_SIZE128, SPACE_LIMIT5120;参数说明DEST是归档日志存放目录TYPELOCAL表示本地归档FILE_SIZE是单个归档文件大小MBSPACE_LIMIT是整个归档目录上限MB超过上限后达梦会自动清理最老的归档文件。生产环境建议SPACE_LIMIT设大一些至少能容纳两到三个备份周期的归档量。第三步修改数据库为归档模式。ALTER DATABASE SET ARCHIVELOG;注意有些版本执行这条命令也要求数据库处于mount状态会短暂中断业务。如果是生产库最好在维护窗口操作。操作完再查一次ARCH_MODE变成YES就说明归档已经开启。4.3 联机备份的SQL命令与常用参数开启归档后就可以在disql里执行备份命令了。最基础的全库备份BACKUP DATABASE FULL BACKUPSET /backup/dm_onl_bak_20250101;如果想备份到指定目录并带说明可以加BACKUPINFO参数BACKUP DATABASE FULL BACKUPSET /backup/dm_onl_bak_20250101 BACKUPINFO 全量备份-20250101;除了整库备份联机备份还支持更细粒度的对象-- 备份指定表空间 BACKUP TABLESPACE MAIN FULL BACKUPSET /backup/dm_tbs_main_bak_20250101; -- 备份归档日志 BACKUP ARCHIVELOG ALL BACKUPSET /backup/dm_arch_bak_20250101;表空间级备份的用处在于如果某个核心业务表空间比较大可以单独给它做高频备份不用每次全库跑一遍。归档日志备份则是为了配合还原时把数据库恢复到更精确的时间点。联机备份的时候数据库会有额外IO开销建议不要在业务高峰期跑尤其是大库全量备份磁盘带宽可能被占满。我一般安排在凌晨两点到五点之间配合crontab定时任务执行。4.4 联机还原整库恢复和时间点恢复联机备份的还原过程和DMRMAN类似也是RESTORERECOVER两步但是可以在数据库在线的情况下执行部分操作。整库还原的SQLRESTORE DATABASE FROM BACKUPSET /backup/dm_onl_bak_20250101; RECOVER DATABASE FROM BACKUPSET /backup/dm_onl_bak_20250101;如果要做时间点恢复比如只想恢复到当天上午10点的状态可以这样RECOVER DATABASE WITH ARCHIVELOG UNTIL TIME 2025-01-01 10:00:00;这里要提前把归档日志备份好否则无法向前推进到这个时间点。时间点恢复在误删数据、误执行未带条件的UPDATE/DELETE这类事故里特别有用。联机热备和DMRMAN冷备的建议组合是这样的日常备份用联机热备每周挑一个低峰窗口做一次DMRMAN冷备。热备负责“天天有备份”冷备负责“兜底”。4.5 联机热备的注意事项联机热备容易踩的坑我列一下归档目录满了会导致数据库写入阻塞。这是个很隐蔽的问题数据库突然卡住一看归档日志目录满了。所以归档目录必须有监控告警空间上限根据业务写入量动态调整。备份过程中不要执行DDL操作。联机备份虽然不影响DML但备份期间如果有DDL变更加字段、建索引备份集可能不一致还原时会报错。备份路径不能用相对路径要用绝对路径。用相对路径生成的备份集在还原时会因为找不到目录而失败。定期做RESTORE ... VALIDATE验证备份集的可用性这个习惯比多做一次备份更重要。5. 方法三dexp/dimp逻辑备份还原灵活但要知道边界5.1 逻辑备份的定位导出和导入的是“数据”不是“数据库”dexp和dimp是达梦自带的逻辑导出导入工具对应Oracle的exp/imp。它们不涉及底层数据文件而是把数据库里的对象定义、数据内容读取出来写成二进制的dmp文件。dimp再把dmp文件里的内容导进目标库。因为这个特点逻辑备份还原解决了物理备份解决不了的两个问题一是跨平台迁移比如从x86的达梦导出的数据可以导入到ARM架构的达梦库二是恢复粒度细可以只导一张表、一个模式不惊动整库。但它也有明显的边界逻辑备份不包含数据库配置参数、用户权限、存储过程依赖关系等全部物理信息。换句话说它恢复的是“数据内容”不等于“数据库本身”。如果你把数据误删了想用dmp恢复前提是目标库结构还在如果你连整个库都坏了逻辑备份帮不上忙还得靠物理备份。5.2 dexp导出的命令格式与参数说明dexp工具在达梦安装目录的bin下面命令行写法如下/opt/dmdbms/bin/dexp SYSDBA/SYSDBAlocalhost:5236 FILE/backup/dm_logic_bak_20250101.dmp LOG/backup/dm_logic_bak_20250101.log FULLY参数一点点拆开讲SYSDBA/SYSDBAlocalhost:5236连接信息格式是用户名/密码IP:端口。生产环境不建议用SYSDBA可以创建一个专门用于备份的账号授权对应权限。FILE导出文件的路径和名称。LOG日志文件路径日志里会记录导出的每张表、每个对象排查问题基本靠它。FULLY全库导出。如果只想导出某个模式改成SCHEMAS用户名只想导出某几张表用TABLES表名1,表名2。常用参数组合# 导出指定模式下的所有对象和数据 dexp backup_user/backup_userlocalhost:5236 FILE/backup/dm_schema_bak.dmp SCHEMASBUSINESS # 只导出两张表不带索引和触发器 dexp backup_user/backup_userlocalhost:5236 FILE/backup/dm_tables.dmp TABLESEMP,DEPT INDEXESN TRIGGERSN有个细节要注意TABLES参数导出的表数据比较大时建议加PARALLEL4之类的并行度参数速度提升明显但会占用更多内存和CPU。5.3 dimp导入的命令格式与常见处理逻辑dimp的参数和dexp基本对称导入命令示例如下/opt/dmdbms/bin/dimp SYSDBA/SYSDBAlocalhost:5236 FILE/backup/dm_logic_bak_20250101.dmp LOG/backup/dm_imp_20250101.log FULLY如果是把导出的数据导入到另一个模式用REMAP_SCHEMA参数dimp SYSDBA/SYSDBAlocalhost:5236 FILE/backup/dm_schema_bak.dmp REMAP_SCHEMABUSINESS:BUSINESS_NEW这个参数在开发环境同步时特别常用比如把生产库某个模式的数据同步到测试库同时不想覆盖测试库现有结构。导入过程中最常见的问题是“对象已存在”因为目标库里可能已经建了部分表。可以用TABLE_EXISTS_ACTION参数控制dimp SYSDBA/SYSDBAlocalhost:5236 FILE/backup/dm_table.dmp TABLESEMP TABLE_EXISTS_ACTIONREPLACETABLE_EXISTS_ACTION的常用值有SKIP跳过已存在的表、APPEND追加数据、REPLACE先删掉再建。我的建议是默认用SKIP确定要覆盖数据时才用REPLACE不然容易把目标库的已有数据搞丢。5.4 逻辑备份的典型场景迁移、同步和误删恢复我在实际工作里逻辑备份用得最多的场景有三个第一个是国产化迁移。比如从其他数据库迁到达梦或者达梦不同版本之间升级迁移dexp导出、dimp导入是最常见的操作路径。注意源库和目标库的字符集要一致否则中文会变成乱码别问我怎么知道的。第二个是环境间数据同步。开发环境、测试环境需要拿生产环境的脱敏数据来用全量物理备份恢复太重dexp导出指定模式的dmp再导入目标环境又快又灵活。第三个是误删单表数据。如果只是某张表的数据被误删了用dimp单独导入这张表的dmp文件比从物理备份里恢复整库要快得多。前提是你有这张表的逻辑备份。6. 三种备份方案的对比与日常运维建议6.1 对比总结一张表看清差异三种方法都能实现备份还原但粒度、窗口、适用场景完全不同。对比维度DMRMAN冷备联机热备dexp/dimp逻辑备份是否需要停机需要不需要不需要备份内容物理数据文件控制信息物理数据文件归档日志SQL逻辑对象和数据恢复单位整库整库/表空间/时间点库/模式/表恢复速度最快快慢逐条执行SQL是否依赖归档不依赖必须开启归档不依赖典型场景灾难恢复、整库迁移日常在线备份数据抽取、表级恢复有一类场景值得拿出来特别说如果你只是想“把库从A服务器搬到B服务器”物理备份DMRMAN冷备是最优解因为它把文件搬过去就能用速度远快于dexp导出再dimp导入。但如果是“把生产数据抽几张表给开发用”物理备份就杀鸡用牛刀了逻辑备份才是正解。方案没有好坏只有合不合适。6.2 建一套靠谱的备份策略比会敲命令更重要命令好学策略难定。我建议最小化备份策略至少包含三样东西周期性的全量物理备份可以用DMRMAN冷备或联机热备。归档日志的持续保留至少保留一个完整备份周期。定期的逻辑备份覆盖重要业务表和关键配置表。然后强烈建议做备份恢复演练。我见过不止一家公司备份任务天天成功但从来没真正还原过等到灾难发生才发现备份集坏了、归档日志断了、或者还原步骤早就忘了。备份的价值只有在“能恢复”时才体现。还原演练的频率不用太高每季度做一次完整的恢复演练就行挑一个测试环境把最近的备份集还原起来验证数据一致性和关键表数据量。6.3 达梦备份的常见报错与排查速查表备份还原过程中容易出问题的地方我总结了一份速查表。报错或异常现象可能原因排查与解决思路还原时提示备份集无效或损坏备份文件损坏、路径不对用VALIDATE检查备份集完整性确认路径无权限问题联机备份报“非归档模式”数据库未开启归档检查V$DATABASE.ARCH_MODE开启归档后重试备份过程中数据库卡住归档目录满了检查归档目录空间清理或扩容归档空间dexp导出中文乱码源库和目标库字符集不一致统一字符集导出时指定CHARSET参数dimp导入报“对象已存在”目标库已有同名对象用TABLE_EXISTS_ACTIONSKIP跳过或REPLACE覆盖还原后实例起不来RESTORE和RECOVER顺序错误或者缺少归档日志确认先RESTORE再RECOVER补全归档日志后再启动DMRMAN找不到配置文件dm.ini路径写错用ps -ef这里额外强调一下归档日志的坑。归档满了达梦会挂起写入操作表现就是业务突然变慢、SQL堆积但数据库进程还在。很多时候第一反应是查锁、查会话忽略了归档目录。所以监控系统里一定要加上归档目录使用率阈值设到80%就告警别等写满了再处理。6.4 命令不是唯一的路管理工具也能做备份还原除了命令行达梦自带的图形化管理工具也支持备份还原操作。工具名叫manager一般在安装目录的tool下/opt/dmdbms/tool/manager用图形界面做备份的好处是直观点击按钮就能配置备份目录、选择备份类型适合不熟悉命令行的同事。但它本质上生成的还是前面讲的这三类备份。我的建议是日常维护用命令行教学演示和应急操作可以用图形界面因为图形界面能减少手误但自动化脚本和定时任务最终还是落到命令行上。7. 我踩过的几个备份还原的坑提前帮你避开第一个坑是备份目录和数据库放在同一块磁盘上。我刚开始接手达梦的时候图省事把备份目录放在了数据盘下结果磁盘满了之后数据库直接停止写入。备份的意义是什么是数据坏了还能恢复。备份目录和数据文件同盘等于保险柜和现金放在同一间屋子里火灾一来全没了。备份目录一定要独立磁盘最好是单独的挂载点有条件的话再考虑异地备份。第二个坑是还原的时候没注意备份集的生成时间。我干过一次特别蠢的事数据库有两天的备份集要恢复的是前一天的数据结果我一着急拿了两天前的备份集还原恢复完成后才发现数据少了一天。所以执行还原之前先LIST BACKUPSET看清楚每个备份集的时间和类型确认无误后再操作。灾难恢复的时候人容易紧张越紧张越容易出错提前把流程写下来、把命令准备好能避免很多低级失误。第三个坑是逻辑备份的权限问题。用dexp导出时如果账号权限不够导出的dmp文件可能缺表缺数据但日志里只显示“对象不存在”之类的模糊信息。建议导出前确认账号有没有对应模式的SELECT权限导出后用grep -i error 日志文件过滤一下日志确认没有大量报错再结束任务。第四个坑是裸拷贝数据文件代替DMRMAN备份。这个我前面提到过但还是想单独强调。数据库运行期间那些数据文件一直在动直接拷贝出来的文件时间点完全不一致恢复后大概率报文件损坏或者实例无法启动。备份就用官方工具做别图省事用cp或者rsync。最后一个建议备份脚本写好之后一定要加日志轮转和失败告警。备完只是第一步备得成不成、日志有没有异常这些信息要能自动送到运维手里。我自己常用的做法是把备份日志输出到固定目录然后定时任务里加一个tail检测发现包含“ERROR”或者“FAIL”就触发告警通知。看似简陋但非常有效。