达梦数据库的备份分为两大类物理备份 和 逻辑备份。物理备份直接拷贝数据文件.DBF。逻辑备份将数据转换为SQL语句INSERT/CREATE。物理备份这是保护整个数据库的“重型武器”主要应对硬件故障、系统崩溃、数据文件损坏等让数据库无法启动或数据大面积丢失的灾难性问题。核心场景灾难恢复服务器磁盘损坏导致整个数据库无法使用需要用最近的物理全备和归档日志将数据库恢复到故障前的最后一刻。TB级大库的快速恢复对于数据量巨大的生产库物理备份直接拷贝数据文件恢复速度远快于逐条执行SQL的逻辑备份。精确的时间点恢复 (PITR)如果有人在今天下午3点误操作如DROP了一张核心业务表可以结合物理备份和归档日志将数据库恢复到下午2点59分的状态从而找回数据。数据库“挂了”或“全丢了”找物理备份。逻辑备份它更灵活主要用于处理数据迁移、特定对象恢复、开发测试环境搭建等精细化操作。核心场景跨平台或跨版本迁移例如需要将数据库从Linux服务器迁移到Windows服务器或进行大版本升级。物理备份通常不兼容而逻辑备份导出的SQL脚本则没有这个问题。恢复“只有一张表被误删”的数据生产库中某张配置表或业务表被人误删了。相比用物理备份恢复整个数据库耗时且影响其他业务从逻辑备份中单独dimp这张表进来会快得多影响也小。向测试环境同步部分数据开发或测试人员只需要生产库中的几张表做验证使用逻辑备份可以按需导出指定表或指定模式的数据。只想“捞”某一两个用户或表的数据或要搬到别的平台去找逻辑备份。归档日志和逻辑备份的区别对比维度归档日志 (ARCHIVE LOG)逻辑备份 (dexp/dimp)本质数据库运行过程中产生的物理操作记录数据页的变化将数据转换成的SQL语句CREATE/INSERT格式二进制格式不可读.dmp或.sql格式部分可读用途配合物理备份做时间点恢复、故障恢复数据迁移、跨平台导入导出能否独立恢复不能必须配合物理备份能单独一个.dmp文件就能恢复归档日志是“物理重做日志”记录的是数据文件上每个字节的变化比如“第3号数据文件的第1024号页面第50号偏移量把值从1改成2”。它不是SQL语句也不是逻辑备份。而逻辑备份导出的是可以读懂的sql语句。分类物理备份都是基于数据库的物理文件如数据文件.DBF、控制文件、归档日志进行拷贝和还原的。联机备份和恢复热备脱机备份和恢复冷备完全备份和恢复增量备份和恢复差异备份和恢复表空间级备份和恢复表级备份和恢复这里要特别注意它虽然叫“表级”但底层依然是对包含该表的物理数据文件块进行备份是物理拷贝并行备份多通道并发拷贝物理文件逻辑备份因为它们都是通过达梦的dexp/dimp工具将数据库对象表、视图、存储过程等转换成 SQL 语句或逻辑数据格式进行导出和导入。库级导出导入模式级导出导入用户级导出导入表级导出导入核心区别物理备份直接“搬运”数据库的实体文件数据文件、控制文件、归档日志像把整个文件夹压缩打包。恢复时直接覆盖回去不关心表里具体是什么数据。逻辑备份把数据翻译成SQL语句CREATE建表、INSERT插数据像把内容抄写成一份清单。恢复时重新执行这些SQL不关心文件存在哪里。物理备份核心操作① 备份将数据文件拷贝到指定目录联机库运行时BACKUP DATABASE FULL BACKUPSET /路径;SQL命令脱机库停止后./dmrman中执行BACKUP DATABASE /dm.ini路径 FULL BACKUPSET /路径;② 还原将备份文件覆盖回原数据文件位置必须脱机使用dmrmanRESTORE DATABASE /dm.ini路径 FROM BACKUPSET /备份路径;③ 恢复应用归档日志使数据一致性相当于“重做日志”必须脱机使用dmrmanRECOVER DATABASE /dm.ini路径 FROM BACKUPSET /备份路径;然后RECOVER DATABASE ... UPDATE DB_MAGIC;更新数据库魔数使库可正常启动注意联机备份时归档日志必须开启dmarch.ini和 dm.ini里的ARCH_INI1就是为此准备。注意RESTORE只是把备份文件拷贝回数据目录但此时数据文件可能和当前日志不一致因为备份后可能还有其他操作。必须执行RECOVER应用归档日志才能把数据“推进”到一致状态最后再UPDATE DB_MAGIC才能正常启动。逻辑备份详细操作达梦的逻辑备份使用dexp导出和dimp导入工具不需要关闭数据库也不需要归档日志。操作命令示例在bin目录下执行说明导出整个库./dexp SYSDBA/SYSDBA#123a FILEfull.dmp LOGfull.log FULLY导出所有对象导出指定模式./dexp SYSDBA/SYSDBA#123a FILEschema.dmp LOGschema.log SCHEMASDMHR只导出DMHR模式导出指定表./dexp SYSDBA/SYSDBA#123a FILEtable.dmp LOGtable.log TABLESRCT_BFHF_LJ只导出这一张表导入全库./dimp SYSDBA/SYSDBA#123a FILEfull.dmp LOGimp.log FULLY导入前如果表存在会报错可加IGNOREY跳过导入指定表./dimp SYSDBA/SYSDBA#123a FILEtable.dmp LOGimp.log TABLESRCT_BFHF_LJ只导入这一张表导出的.dmp文件可以在不同操作系统、不同达梦版本之间迁移。恢复时库必须在线不需要停止服务。适合迁移少量数据对于部分问题的理解联机备份和脱机备份最本质的区别是什么联机备份数据库正在读写备份开始时数据文件处于不一致状态必须依赖归档日志把不一致的数据“推”到一致。备份之后进行的数据库操作没有被记录到备份文件里所以需要归档日志配合脱机备份数据库已干净关闭所有数据文件处于一致状态。完全备份、增量备份、差异备份这三者是什么关系完全备份所有数据文件备份文件范围为全库增量备份自上次任何类型备份以来变化的数据页差异备份自上次完全备份以来变化的数据页全量备份 直接把数据文件恢复到某个时刻的快照增量备份 在全量基础上应用这段时间内所有变化包括删除操作如果周一做了一次完全备份周二做增量备份周三做增量备份周四做差异备份周五数据库崩了为了恢复周五的数据我需要用到哪几个备份文件增量备份策略周一完全 周二增量 周三增量 周四增量。一共需要4个备份文件按时间顺序依次恢复。差异备份策略周一完全 周四差异。一共需要2个备份文件先恢复完全再恢复差异即可。为什么会报管道连接错误达梦的备份恢复不是由dmrman或disql直接读写磁盘的而是通过一个叫做DMAP的后台服务进程来做数据搬运。[你的操作命令] ----通过管道(pipe)通信---- [DMAP 搬运工] ----读写---- [磁盘上的数据文件/备份集]当执行dmrman或BACKUP命令时你的操作工具会尝试通过操作系统管道pipe和 DMAP 进程建立连接让 DMAP 去执行真正的读写操作。-7109错误的本质是管道连接失败。失败最主要的原因就是启动命令工具的用户和启动 DMAP 服务的用户不是同一个人。因为 Linux 的进程间通信有权限隔离不同用户的进程无法随意通过管道通信。dmrman工具需要和 DMAP 建立管道通信。如果dmrman是你用dmdba用户执行的但 DMAP 是root用户启动的那么管道两端用户不同Linux 权限机制会直接拒绝连接。案例解析假设你在生产环境遇到了这个故障场景今天是2026年7月31日 上午 10:00你发现数据库里有一张核心业务表EMP在2026年7月30日 下午 15:00左右被误删除了DROP TABLE。数据库当前仍在正常运行没有停库。你的备份情况每周日7月28日凌晨 2:00 做了一次联机完全备份每天凌晨 1:00 做一次增量备份归档日志一直开启完整保留。你的任务要恢复这张被删的EMP表同时尽量减少对其他业务的影响。回答选逻辑备份只误删了一张表库还活着可以从备份中单独抽出这张表导入不影响其他业务。步骤操作说明①搭建一个临时恢复环境另一台机器或另一个实例绝对不能在生产库上直接恢复否则会覆盖当前数据②在临时环境上恢复 7月28日的完全备份用dmrman执行 RESTORE RECOVER③在临时环境上恢复 7月29日的增量备份继续用dmrman应用增量④应用归档日志恢复到 7月30日 14:59DROP之前用RECOVER ... UNTIL TIME指定时间点⑤启动临时环境的数据库此时临时库里的数据是7月30日下午2点59分的状态EMP表还在⑥用dexp从临时库单独导出 EMP 表./dexp ... TABLESEMP FILEemp.dmp⑦用dimp将 emp.dmp导入生产库生产库正常运行只导入这一张表其他业务不受影响⑧验证数据无误后清理临时环境临时库可以删掉注意如果直接在原来的生产库上恢复全量备份那么从7月28日到7月31日这三天的新数据其他表的新增、修改全部会丢失。应用7月29日之后到7月30日14:59之间的归档日志把临时库“推进”到删表前的最后一刻。整个过程中DMAP服务、临时数据库服务、dmrman、dexp/dimp都必须用同一个操作系统用户dmdba执行否则会因管道权限问题报-7109错误。达梦社区地址https://eco.dameng.com