企业官网建设流程全解析

做达梦数据库运维的人，迟早会碰上归档配置这件事。特别是数据库要用于备份恢复、要做主备同步，或者你正为恢复过程中的日志断层发愁的时候，开启归档几乎是绕不开的第一步。DM8（达梦8）和常见商业数据库的逻辑类似，但具体操作又有一点小门槛，很多人第一次配置时会栽在“必须先进入MOUNT状态”“配置了dmarch.ini但没生效”“归档目录写满”这类问题上。这篇内容我就把从零配置归档的完整链路讲透，包括命令、参数、坑点，以及在正式环境里我建议你怎么操作。

1. 归档之前的必要认知：先搞清楚 DM8 归档到底在解决什么问题

1.1 从重做日志说起

达梦数据库和大部分关系型数据库一样，在写入数据时，不会立刻把每个变更都刷到数据文件里，而是先记录重做日志（redo log）。这样做的好处是事务提交很快，数据库可以把随机小写入先攒成顺序大写入。但重做日志文件是有固定大小的，比如 128MB 一个，写满一个就切到下一个。如果日志循环覆盖了，而数据文件还没来得及完整写入，这时候系统一旦崩溃，重启恢复时，就有可能出现“日志断档”，丢失一部分本可以恢复的提交记录。

归档日志的作用，就是在重做日志文件写满准备覆盖之前，把它完整复制一份出来，放到一个独立的归档目录里。这个动作不阻塞业务，但会让 MPP 或者主备场景中的日志变更路径变得更可靠。你可以把它理解成“日志的保险箱”：主日志循环删掉不要紧，只要归档里有一份，后续做介质恢复、时间点恢复、备库同步，就有材料可用。

DM8 的归档分为本地归档和远程归档两种。本地归档就是把日志文件保存在本机磁盘上，主要用于配合备份做恢复；远程归档则是把归档日志通过网络发送到另一个节点，是达梦 Data Watch 主备同步、读写分离集群中的基础能力。这篇内容重点讲本地归档，因为多数单机环境、备份环境，先把 local 归档配置好就够用。

1.2 开启归档前必须确认的事项

不管在 Windows 还是 Linux 上，开启归档之前有些事情不提前确认，后面很容易难受。

第一，确认数据库版本。DM8 不同小版本的实例管理界面会有一点差别，但核心 SQL 语法基本一致。如果还在用 DM7，部分视图名和归档参数名会有差异，不能完全照搬，先执行SELECT * FROM V$VERSION;看一眼版本信息。

第二，确认磁盘空间。归档文件不是临时文件，它会持续累积。单机业务如果每天产生 10GB 重做日志，你就得准备至少 30GB~50GB 的独立空间用来保留三天归档。我后面会专门说估算方法，这里先提醒一句：千万不要把归档目录和数据文件放在同一个分区还不做空间限制，否则某一天磁盘满，整个实例都会陷入长时间挂起。

第三，确认数据库的启动状态和连接方式。开启归档的核心命令，必须让实例处于 MOUNT 状态。这个状态很特殊：实例已启动，参数文件已读取，但数据文件尚未开放给业务使用。所以如果你有一个正在跑的 OLTP 库，直接ALTER DATABASE MOUNT;会把当前的业务连接全部断开。生产环境操作前，必须提前停应用或者在维护窗口操作。

第四，最容易被忽略的一点，一定要先做一次完整备份。归档模式是对数据库运行方式的重大改变，万一中途操作失误，一个全备就是你的后悔药。达梦里可以用BACKUP DATABASE BACKUPSET '/dm8/backup/full_bak';快速做物理备份，时间窗口不够就先做增量，但全备更稳妥。

2. 两种主流开启方式：命令行动手与图形化向导

2.1 使用 disql 命令行开启归档（最推荐的方式）

如果是 Linux 服务器，尤其是云服务器没装图形桌面的场景，命令行是你最可靠的方式。而且把命令写进脚本，以后初始化新库、批量环境部署，都能直接复用。

先创建归档目录。这个步骤很多人会忽略权限，建议显式设置文件属主。

mkdir -p /dm8/arch chown -R dmdba:dinstall /dm8/arch

注意：安装达梦时通常会用dmdba用户和dinstall组，如果你不是默认安装，用id dmdba确认一下，别把目录属性弄错。数据库进程要以该用户运行，目录读写权限也必须放开给这个用户。

然后切到 dmdba 用户，登录 disql。

su - dmdba disql SYSDBA/你的密码@localhost:5236

登录成功后，先把实例切换到 MOUNT 状态。

ALTER DATABASE MOUNT;

这一步如果实例原本是 OPEN 状态，会立刻中断所有连接，所以要确保你已经等业务彻底停止后操作。命令执行成功会返回“操作已执行”或类似提示。

接着添加归档配置。这里用的是 DM8 联机配置归档的典型语句：

ALTER DATABASE ADD ARCHIVELOG 'DEST=/dm8/arch, TYPE=local, FILE_SIZE=128, SPACE_LIMIT=10240';

参数分别解释一下：

• DEST 是归档文件存放路径，必须写绝对路径，并且目录已经存在。
• TYPE 当前写 local，表示本地归档。
• FILE_SIZE 是单个归档文件的最大大小，单位 MB，这里设成 128MB，切到下一个文件时会自动生成新文件。
• SPACE_LIMIT 是所有归档文件总的空间上限，单位 MB，这里 10240 表示最多 10GB，超过限制之后达梦会自动清理最旧归档文件。

然后打开归档模式：

ALTER DATABASE ARCHIVELOG;

最后把数据库恢复到 OPEN 状态：

ALTER DATABASE OPEN;

验证是否生效，我用得最多的 SQL 是：

SELECT ARCH_MODE FROM V$DATABASE;

返回 1 表示当前是归档模式，返回 0 是非归档模式。想看得更细，可以查归档配置视图：

SELECT * FROM V$DM_ARCH_INI;

这个视图会显示归档目标、类型、文件大小、空间限制、当前状态（VALID）等信息，是日常排查归档问题的主要入口。

还有一点要提醒：ADD ARCHIVELOG这个语句不是任何时候都能重复执行。如果你已经配置过一个归档目标，想改路径或大小，要用MODIFY ARCHIVELOG，比如：

ALTER DATABASE MODIFY ARCHIVELOG 'DEST=/dm8/arch02, TYPE=local, FILE_SIZE=256, SPACE_LIMIT=20480';

如果在 ADD 时报错“归档配置已存在”，就先用SELECT * FROM V$DM_ARCH_INI;看一下当前配置，再决定是要 MODIFY 还是 DELETE 后重新添加。

2.2 使用 DM 管理工具手动配置（新手更容易上手）

如果你对命令行不熟，或者第一次操作想有一个可视化确认，DM 管理工具（DM Management Tool）会友好很多。

连接数据库实例后，在左侧对象树里找到你的实例，右键选择“管理服务器”或者“实例管理”，在不同版本里菜单名称可能叫“归档管理”“归档配置”，但基本都在管理界面的一个页签里。

进入归档配置页签后，通常会有“归档模式”的勾选项。勾选“归档”，然后填写归档目标路径，也就是你想存放归档日志的目录；再填单个文件大小和空间上限。填完点“应用”或“保存”，工具会把这些配置写入到 dmarch.ini 里，部分版本还会弹出提示，告诉你需要重启数据库实例才能生效。

这时候要注意一个细节：图形化工具和命令行最大的区别是，工具写的是配置文件，有些版本不会自动帮你执行ALTER DATABASE ARCHIVELOG，所以你可能会遇到“配置都填好了，但SELECT ARCH_MODE FROM V$DATABASE;查出来还是 0”的情况。遇到这种问题不要慌，按下面的顺序手动切一次：

ALTER DATABASE MOUNT; ALTER DATABASE ARCHIVELOG; ALTER DATABASE OPEN;

当然，如果你用的是比较新的 DM8 管理工具，它内部会自动处理这些步骤，操作完工具提示你会重启实例，那就不用手动执行。

2.3 两种方式如何选择

我的习惯是：Linux 生产环境一律用命令行，尤其是要批量部署几套环境时，把 SQL 写进 shell 脚本，每套库执行一遍，保证输出一致。图形化工具更适合做“一次性学习验证”，或者给刚接触达梦的同事演示整个配置过程。

不过不管用哪种方式，最终都是改两样东西：一个是 dmarch.ini 里归档目标相关参数，一个是数据库运行参数里必须开启 ARCH_INI 开关。只是命令行在执行ALTER DATABASE ADD ARCHIVELOG时，达梦内部会同步更新归档配置文件和实例内存参数，不用你手工去碰 ini；而图形化工具本质是帮你编辑配置文件。理解了这个底层关系，后面遇到“配置了但没生效”就不会一头雾水。

3. 核心配置参数逐一拆解：改完别急着重启

3.1 dm.ini 与 dmarch.ini 中你真正需要关心的参数

很多运维喜欢直接上手改参数，但改完重启起不来，再回头找问题，效率很低。我建议先搞清楚这几个关键参数，再动手。

先说 dm.ini。这个文件是数据库实例的主参数文件，在数据目录下，比如/dm8/data/DAMENG/dm.ini。归档相关的核心开关就是ARCH_INI，它控制实例启动时是否加载归档配置。用命令行方式开启归档时，这个参数会被自动置为 1；手工改配置文件时，需要自己把这一项设置成 1。

再说 dmarch.ini。这个文件专门保存归档配置，通常也在数据目录下。通过 ALTER DATABASE ADD ARCHIVELOG 配置后，内容会写入这个文件。几个关键参数我整理成了表格：

这里重点说明ARCH_SPACE_LIMIT。我遇到过不少同学图省事，直接设成 0，觉得“不限制最安全”。实际上在持续高并发写入的系统里，归档文件生成速度非常快，一天几十 GB 很常见，如果不限制，磁盘被写满是早晚的事。盘满了之后不只归档写不进去，整个实例的正常 DML 都会受影响。

反过来，设置了空间上限之后，达梦会在总量达到上限时自动清理最旧的归档文件。但注意，这个清理动作不一定能完美跟上写入速度，特别是系统突然出现大量日志切换时，仍然可能触发磁盘告警。所以更稳妥的做法是，把ARCH_SPACE_LIMIT设成一个既能保留足够恢复窗口、又明显低于磁盘容量的值，同时用外部监控盯着。

3.2 归档目录规划与磁盘空间估算

归档目录的规划，我一般会用“业务日变化量 x 保留天数 x 冗余系数”来估算。

比如一个典型的 OLTP 系统，每天新增数据大概 20GB，更新也很多，重做日志日产生量大约在 15GB。如果要求保留最近 7 天的归档，那么至少需要15 * 7 = 105GB。考虑到业务大促、批量任务时日志量可能是平时的 2 到 3 倍，我建议留 200GB 以上，归档空间上限可以设定为SPACE_LIMIT = 204800（即 200GB）。

归档目录最好单独使用一个挂载点，不要和数据库数据文件、系统盘放在一起。原因很简单：如果数据盘满了，数据库本来就会告警；再被归档文件一冲，可能连最基本的备份任务都跑不动。独立挂载点还能避免你删归档时误碰数据文件。权限方面，目录属主必须是 dmdba，不能用 root 创建的目录直接丢给数据库写，否则大概率遇到权限错误。

日常巡检时，我建议至少盯两个指标：

• df -h，看归档目录所在分区剩余空间；
• 归档目录中最近一个文件的时间，比如ls -lt /dm8/arch | head，如果最新文件停止更新超过 30 分钟，而系统又有写入压力，说明归档可能没正常工作。

如果想看得更细，可以连到数据库里查归档视图：

SELECT PATH, START_TIME, END_TIME, SIZE FROM V$ARCHIVED_LOG ORDER BY END_TIME DESC;

这条 SQL 能看到每个归档文件的路径、写入开始结束时间和文件大小，排查“归档有没有断”非常直观。

3.3 开启归档后的性能影响与监控

很多人担心开启归档后业务性能明显下降。说实话，正常配置下影响并不大，因为归档不是每条 SQL 提交时都写归档文件，而是在重做日志文件切换时把整个日志文件复制归档。日志切换本身又是顺序写，比随机写快得多。实测下来，多数环境性能损耗在 5% 左右，如果磁盘足够快，甚至感知不到。

但有两个场景要特别小心。

第一，归档目录和数据文件在同一块机械盘。日志切换时，数据库既要写新的重做日志，又要读旧日志写归档，磁盘寻道压力会瞬间翻倍，这个场景下性能损耗可能到 15% 以上。所以有条件的话，把归档目录放到 SSD 或者独立盘。

第二，开了SPACE_LIMIT自动清理，但归档目录里正好有文件被备份任务占用。清理任务碰到被占用的文件，一般会跳过或者延迟，这时候归档总大小会临时超过限制，短时间磁盘空间告警。这种情况不用太慌，等备份结束，达梦会自动补清理；但如果长期不清理，就需要人为介入，删除一些确定用不上的归档文件。

监控层面，除了上面提到的V$ARCHIVED_LOG之外，还有一个更简单的状态字段。用SELECT ARCH_MODE FROM V$DATABASE;确认是否还在归档模式；用SELECT * FROM V$DM_ARCH_INI;确认每个归档目标状态是不是 VALID。我习惯写一个脚本每小时跑一次，把这两个查询结果输出到日志，再配合df -h检测磁盘，基本能覆盖 90% 的归档故障。

4. 实操过程中常见的卡点与排查方法

4.1 数据库为什么在开启归档后起不来

这个场景我见过太多次了，尤其是在手工编辑 dmarch.ini 的场景。现象就是重启实例时，数据库起不来，查看日志才发现在归档初始化阶段就失败了。

排查步骤其实很固定：

第一步，看实例日志。达梦数据目录下会有类似dm_DAMENG.log的文件，用tail -200翻到最后，重点找 ERROR 和 "arch" 关键字的行。常见提示是归档目录不存在，或者对归档目录没有写权限。

第二步，检查归档目录。ls -ld /dm8/arch看属主和权限。如果属主是 root，用chown -R dmdba:dinstall /dm8/arch修正。

第三步，检查 dmarch.ini 格式。手工编辑这个文件时，最容易出现行尾有隐藏空格、全角字符、参数名拼写错误。直接对比我之前表格里的参数名，逐行检查。还有一点，如果文件里同时存在多个归档目标，别让它们在配置格式上互相冲突。

第四步，确认 dm.ini 中ARCH_INI是否为 1。如果这个开关没打开，即使 dmarch.ini 写得再对，实例启动时也不会去加载归档配置，也就不会进入归档模式。

另外，如果你是在 OPEN 状态下直接执行了ALTER DATABASE ARCHIVELOG;，达梦会明确报错，提示数据库必须处于 MOUNT 状态。这时候不要慌，先执行ALTER DATABASE MOUNT;，再执行 ARCHIVELOG，最后 OPEN。

4.2 归档目录满导致数据库像“卡死”一样

归档目录写满是个经典事故。现象非常吓人：整个数据库的 DML 变慢，应用端报错一大堆，甚至连接到数据库都困难。有人会去查锁、查会话，最后发现是磁盘满了。

如果你是紧急处理，先看df -h确认哪个分区满了。如果满的就是归档目录，用ls -lt /dm8/arch找出那些很早之前、确定已经做完备份的归档文件，可以先手动删除一部分旧的。注意：手动删除只是应急，不要连续删正在被数据库写入的最新文件，否则可能有归档断档的风险。

清理出一点空间后，数据库通常会自行恢复可用。这时候再连进去，把ARCH_SPACE_LIMIT改成合理值，或者把归档目录迁移到更大的分区。

迁移目录的方法不复杂，但也要走标准流程。先把新目录创建好并授权，然后执行：

ALTER DATABASE MOUNT; ALTER DATABASE MODIFY ARCHIVELOG 'DEST=/dm8/arch02, TYPE=local, FILE_SIZE=128, SPACE_LIMIT=20480'; ALTER DATABASE OPEN;

当然，老目录下的历史归档文件需要你自己决定是保留还是迁移，数据库不会自动帮你搬。从这个教训你可以看出来，一开始就设好SPACE_LIMIT和独立分区，比事后救火省太多事。

4.3 日志切换不动、没有新归档文件生成

有时候你开启了归档模式，但等了半天发现归档目录里一个文件都没增加，第一反应就是“配置有问题”。其实这不一定是问题，要结合业务场景判断。

归档文件的生成时机，是重做日志文件从当前日志文件切换到下一个日志文件的那一刻。如果系统极其空闲，长时间没有写入，重做日志里几乎没有变化，那确实可能不产生新归档。这是正常现象，不是故障。

但如果业务明明有写入，归档文件却一直不更新，就要检查下面几点：

1）先确认归档模式还开着，执行SELECT ARCH_MODE FROM V$DATABASE;。

2）查看V$DM_ARCH_INI，确认归档目标的状态是 VALID，DEST 路径正确。

3）手动触发一次日志切换。如果达梦版本支持，可以执行：

ALTER SYSTEM SWITCH LOGFILE;

执行成功后，观察/dm8/arch目录是否出现新文件。如果出现了，说明归档链路本身没问题；如果没出现，再查实例日志。

4）检查实例日志里有没有归档写入失败的信息，比如磁盘满、权限错。有的话按前面说的方法修正。

这个问题的关键是把“业务正常但没归档”和“归档链路断了”区分开来，别一上来就重启数据库。优先用视图和手动日志切换做小范围验证。

4.4 临时关闭归档回到非归档模式

有时候测试环境要做对比验证，或者你想清理掉归档相关配置，临时关闭归档也是常见需求。

关闭归档同样要在 MOUNT 状态下操作。先确保业务已停止，然后：

ALTER DATABASE MOUNT; ALTER DATABASE NOARCHIVELOG; ALTER DATABASE OPEN;

执行完再查SELECT ARCH_MODE FROM V$DATABASE;，如果返回 0，说明已经回到非归档模式。

如果你还想把归档目标从配置里彻底删除，可以在 MOUNT 状态下再执行：

ALTER DATABASE DELETE ARCHIVELOG 'DEST=/dm8/arch, TYPE=local';

注意，这条命令删的是“归档目标配置”，不是归档文件本身。历史归档文件依然会留在 /dm8/arch 目录里。这些文件要不要删、什么时候删，取决于你是否还有未完成任务，比如需要在某个时间点恢复数据。我的建议是，配置删掉可以，文件先保留几天，确认一切正常后，再手动清理。否则你刚关掉归档就把历史文件全部删掉，万一有恢复需求，就真的回不去了。

5. 一点运维经验补充

最后说几个我自己在实际项目里总结出来的细节，不是官方文档里一定会写的”。

第一次在生产环境开启归档前，我强烈建议先做一次全备份，并且把执行前的重做日志序列号记录下来。这样就算操作过程中出了意外，你至少知道自己的数据恢复到哪个位置是安全的。

另外，不要把归档配置过程当成“一次性手工活”。你现在配好了，可能过几个月要新加一套环境，或者灾备演练要再搭一套库，如果每次都打开图形界面点来点去，很容易漏步。不如把整套 SQL 整理成一个脚本，放到统一的自动化发布平台里。我自己的脚本大概长这样：先检查目录，再检查当前模式，然后执行 MOUNT、ADD ARCHIVELOG、ARCHIVELOG、OPEN，最后用 SELECT 断言验证结果。一旦断言失败，脚本直接退出，避免带病状态流入下一步。

还有一个容易踩的坑：远程归档和本地归档不要混用。如果你不是在做达梦 Data Watch 主备同步，只是单机做备份，老老实实只用TYPE=local。我见过有同事只配了远程归档，却没搭配合适的主备环境，结果归档日志发不出去，主库重做日志切换时一等再等，最后业务堵塞。这个问题排查起来很绕，一开始就明确归档用途，能少走很多弯路。

归档配置本身不难，难的是一开始就要想清楚目的：你是为了备份恢复留后路，还是为了做主备同步。明确了目的，再决定用 local 还是 remote，定好 FILE_SIZE 和 SPACE_LIMIT，按上面的步骤操作，基本能一步到位。