达梦数据库Windows创建实例：图形化助手与dminit命令行详解

达梦数据库在 Windows 上创建数据库实例这件事，说简单是真简单，向导点几下就出来了；说麻烦也真麻烦，参数里随便选错一个，后面数据迁移、备份策略、性能调优全得推倒重来。我在国产化替换项目里陆陆续续初始化过几十个达梦实例，从测试机上随手一建的玩具库，到生产上跑核心业务、还要做读写分离的正式实例，踩过的坑基本能凑成一本小册子。这篇就专门聊 Windows 环境下创建数据库实例的完整流程，包含图形化配置助手和 dminit 命令行两条路，参数怎么选、服务怎么注册、建完怎么验，都会给到可以直接复制的方案。不管你是第一次接触达梦数据库的新手，还是从其他数据库转过来想快速上手的老手，看完应该都能在自己的机器上把实例稳稳跑起来。

1. 动手之前，先把实例这件事想清楚

1.1 实例和数据库，到底差在哪

达梦的文档里，数据库和实例是两个被反复强调的概念，但很多人第一次看会直接略过。我用自己的话翻译一遍：数据库是躺在磁盘上的那一堆文件——数据文件、控制文件、重做日志、参数文件 dm.ini；实例是内存里的那套运行时结构——数据缓冲区、SQL 缓存、后台线程、会话管理。启动一次 dmserver 进程，本质就是拿 dm.ini 里的参数，把磁盘上的数据库文件挂载进内存，形成一个能接受客户端连接的实例。

这个区分在实操里非常关键。你在 Windows 上做的“创建数据库实例”这个动作，实际上是 dminit 帮你一次性完成两件事：按参数在指定路径铺一套初始数据文件、控制文件和日志文件，同时把参数固化进 dm.ini。以后每次启动服务，dmserver 读的都是这份 dm.ini。所以数据库名、实例名、端口、页大小、字符集这些东西，在建库那一秒就写死了，事后想改就得重建实例再导数据。

我见过最常见的错误，是有人把“实例”当成可以随便改名字的东西。实例名 INSTANCE_NAME 一旦确定，服务名、监听配置、工具里的连接标识都会跟着它走，改名之后各种配置文件对不上，排查起来非常折磨。所以我的建议永远是：动手之前先在纸上把库名、实例名、端口、路径四项定下来，后面照着填，别中途改主意。

1.2 Windows 上的目录规划，别图省事

Windows 环境跑达梦，目录规划是最容易被忽略、又最容易埋雷的一环。官方安装包默认会把程序装在类似D:\dmdbms这样的路径下，实例数据默认落在D:\dmdbms\data\DAMENG。测试环境这么放没问题，生产环境我建议至少拆成三块：程序目录、数据目录、备份目录，分别放在不同的物理盘或者不同的卷上。

理由很直接。数据目录是随机读写最密集的地方，备份目录是顺序写大文件，程序目录基本只读。三者混在一个盘上，备份一跑起来磁盘 IO 就被打满，业务查询跟着变慢。另外 Windows 上还有一个要命的坑：如果路径里带空格，或者带中文，某些脚本、服务注册、第三方工具解析路径时就会出问题。我现在的习惯是全程用英文短路径，比如D:\dmdbms、D:\dmdata\DAMENG、D:\dmbak，一个空格都不给。

权限方面也得注意。达梦服务默认以本地系统账户或者你指定的账户运行，如果数据目录的 NTFS 权限没给足，服务启动时会报“无法打开数据文件”之类的错误，而且报错信息往往很含糊。稳妥做法是给运行服务的账户对数据目录和备份目录授予完全控制权限，别指望它自己继承。

1.3 安装包和版本，先确认再动手

创建实例之前，先确认你手上这套达梦是什么版本、什么架构。DM8 是当前主流，安装包分 Windows x64 等不同架构，官网下载页面上型号挺多，拿错了装完跑不起来。安装完成后，D:\dmdbms\bin目录下应该有dminit.exe、dmserver.exe、disql.exe、dminit的图形化封装工具等一堆可执行文件，目录里还有tool子目录放管理工具。

版本确认还有个实际用途：不同小版本的 dminit 参数会有细微差异，比如某些版本新增了页校验参数、时区参数。你先用dminit help看一眼当前版本支持哪些参数，比你翻半天旧文档靠谱得多。我就吃过这个亏，照着一份两年前的博客写命令，结果参数名对不上，白白折腾半小时。

注意：同一个 Windows 机器上可以存在多套达梦程序目录，但注册成 Windows 服务时服务名必须唯一，否则后注册的会失败或者覆盖前面的。多实例场景建议在服务名里带上实例名和端口。

2. 用图形化配置助手创建第一个实例

2.1 从开始菜单找到配置助手

装完达梦，开始菜单里会出现一个达梦的程序组，里面有“DM数据库配置助手”这一项，有些版本叫“数据库配置工具”。点开之后是一个向导式的界面，整体交互和其他数据库的建库向导很像：先选操作类型（创建数据库实例 / 删除实例 / 注册服务），再一路往下填参数。

向导第一屏通常让你选“创建数据库实例”，然后指定数据库目录。这里填的就是你要铺数据文件的那个空目录，注意是空目录，如果目录里已经有 dm.ini 或者数据文件，向导会提示冲突。下一页是数据库标识：数据库名、实例名、端口号。数据库名建议用大写英文，实例名同样，端口默认 5236，如果机器上已经有别的实例在跑，这里必须换一个没被占用的端口。

再往后就是参数页，也是整个向导里最需要动脑的一屏。向导会把页大小、簇大小、字符集、大小写敏感、varchar 长度单位、空格填充模式、日志文件大小这些东西全列出来，每一项都有默认值。新手最常见的做法是无脑下一步，这在纯测试环境没问题，但只要你后面要接生产数据，就必须在这一屏停下来，认真选。

2.2 参数页每一项，到底该怎么选

页大小（PAGE_SIZE）是第一个要决策的。达梦支持 4K、8K、16K、32K 四档，默认 8K。这个值决定了数据块的大小，一旦建库就不能改。我的经验是：纯 OLTP 的交易类系统选 8K，跟主流数据库对齐，兼容性最好；如果是分析型、批处理为主、单行数据比较宽的库，可以上 16K 甚至 32K，减少行溢出。但页越大，单次 IO 的粒度越大，小随机读多的场景反而不划算。别为了“看起来大”就选 32K，那是给自己找麻烦。

簇大小（EXTENT_SIZE）默认 16K，可选 16K、32K、64K。簇是分配空间的最小单位，簇越大，大表顺序写的效率越高，但小表会浪费空间。绝大多数场景保持默认 16K 就够了，除非你明确知道这个库里全是大宽表，可以考虑 32K。

字符集（CHARSET）是重中之重。达梦默认是 GB18030，编码值 0；UTF-8 是 1。这里的选择取决于你的业务数据里有没有生僻字、多语言文本。如果系统后续要对接 Java 应用、要存 emoji 或者其它语言字符，直接选 UTF-8。如果全是中文、且历史系统就是 GBK 体系，选 GB18030 也能省一些存储空间。但要注意，字符集建库后不可更改，选错了只能重建实例再迁移。

大小写敏感（CASE_SENSITIVE）默认是敏感。这个参数影响对象名和字符串比较。如果你的应用是从大小写不敏感的数据库迁过来的，代码里表名大小写混着写，那建库时就要考虑关掉大小写敏感，或者干脆统一改代码。我一般倾向保持默认敏感，然后在应用层规范命名，因为不敏感模式下索引行为、字符串比较会有一些反直觉的地方。

还有两个容易被忽略的：varchar 长度单位（按字符还是按字节）和空格填充模式。前者影响你定义VARCHAR(20)到底是 20 个字符还是 20 个字节，如果业务里有中文，按字节算的时候一个汉字占 3 字节，实际能存的字就少了。后者影响字符串比较时尾部空格的行为，从 Oracle 风格系统迁移过来的，通常要保持兼容。

2.3 口令和路径这两处，新手最容易翻车

向导走到后面会让你设置 SYSDBA 的口令，有些版本还会让你一并设置 SYSAUDITOR 的口令。达梦对口令复杂度是有要求的，默认策略下至少 8 位，且要包含大小写字母、数字、特殊字符中的若干类。测试环境图省事用SYSDBA当密码，向导大概率直接拒绝，提示口令不满足复杂度要求。

这里有个实操心得：如果确实是本地测试库，可以在建库参数里指定口令策略，或者建完之后用 SYSDBA 登录去调整口令策略参数。但生产环境请老老实实设强口令，并且把口令交给专门的凭据管理，别写在脚本里。

路径这处我要再强调一次。向导里如果让你填多个路径（数据文件路径、日志文件路径、备份路径），务必确认每个目录都存在且有写权限。Windows 上有个很隐蔽的问题：你用管理员账户登录图形界面操作，向导创建的文件属主是管理员；但服务实际是以另一个账户启动的，结果服务一启动就报权限错误。解决办法是注册服务时显式指定运行账户，并且保证这个账户对目录有完全控制权限。

提示：向导创建完成后，建议不要立刻点“完成”就关掉，它会弹出一步询问是否“注册数据库服务”。这一步勾上，能省掉后面手动注册的麻烦。

3. 命令行 dminit 建库：可复制的参数模板

3.1 dminit 的基本用法和参数速查

图形向导适合第一次接触达梦的人建立直观印象，但真到了批量部署、自动化脚本、或者要精确控制每一个参数的时候，dminit 命令行才是主力。它的位置在D:\dmdbms\bin\dminit.exe，基本语法是：

dminit.exe PATH=数据库路径 [参数=值 ...]

其中 PATH 是必填项，其余参数不填就走默认值。想快速看当前版本支持哪些参数，直接执行：

dminit.exe help

这条命令会打印出完整的参数列表和取值范围，比翻文档快。我整理了一份最常用的参数对照表，可以直接当备忘录用：

3.2 一套可以直接抄的初始化命令

下面是我在 Windows 上初始化生产前测试实例时，最常用的一套命令，参数注释都写在后面：

D:\dmdbms\bin\dminit.exe ^ PATH=D:\dmdata\DAMENG ^ DB_NAME=DAMENG ^ INSTANCE_NAME=DMSERVER ^ PORT_NUM=5236 ^ PAGE_SIZE=8 ^ EXTENT_SIZE=16 ^ CHARSET=1 ^ CASE_SENSITIVE=Y ^ LENGTH_IN_CHAR=Y ^ LOG_SIZE=1024 ^ SYSDBA_PWD=Dm@12345678 ^ TIME_ZONE=+08:00

注意 Windows 命令行的换行符是^，不是 Linux 的\，这是很多人从 Linux 迁移过来第一个撞的墙。执行成功后，终端会打印一串初始化进度，最终提示“init database success”之类的字样。这时候你去D:\dmdata\DAMENG目录下看，应该能看到dm.ini、dm.ctl、SYSTEM.DBF、若干DAMENG01.LOG文件。

这套参数的选择逻辑说清楚：页大小选 8K 是为了兼容主流 OLTP 负载；字符集选 UTF-8 是因为这个库后面要跟 Java 应用对接，避免中文和特殊符号出问题；varchar 按字符计，是为了让应用侧定义字段长度时不用做字节换算；日志单份 1G，是因为这个库有批量写入场景，日志太小会频繁切换，影响性能。每一项目标都对应一个具体的业务特征，别照抄参数却不理解原因。

3.3 页大小和日志大小怎么算才合理

参数里最需要算一算的是日志大小。达梦的重做日志通常是两份或多份，每份大小由 LOG_SIZE 决定，取值范围一般在 64MB 到 2048MB。日志用来做实例恢复和主备同步，太小会导致频繁的日志切换，切换瞬间有性能抖动；太大会拉长恢复时间，一旦实例异常重启，重放日志要很久。

一个粗略的估算办法：看你的业务峰值写入速率。假设高峰期每秒产生 20MB 的重做日志，你希望日志切换不要太频繁，让单份日志能撑 1 到 2 分钟，那么单份日志大小取 1200MB 到 2400MB 之间，结合上限取 1024MB 或 2048MB。这只是一个起点，真正上线前还是要压测看日志切换频率。

页大小虽然没有“算”的余地，但它的选择会间接影响单行最大长度和行内存储效率。达梦单行数据不能跨页存储，如果一行超过了页大小能容纳的极限，就会触发行溢出。所以当你的表里有很多很宽的 VARCHAR 字段时，选 16K 页会比 8K 页少很多溢出，全表扫描时效率差别明显。这就是为什么参数选择要和业务表结构一起看，而不是孤立地拍脑袋。

注意：dminit 执行过程中不要中途 Ctrl+C 打断，否则会留下半成品目录。如果确实需要重来，先把目录整个删干净再重新执行，不要试图在残留目录上继续初始化。

4. 注册 Windows 服务与日常启停

4.1 两种注册方式，各有适用场景

实例创建出来之后，还是不能算完事。dminit 只是把磁盘文件铺好了，要让实例开机自动运行、能被 Windows 服务管理器统一管理，还得注册成服务。达梦在 Windows 上提供了两种注册途径。

第一种是图形化方式，用“DM服务查看器”，在开始菜单的达梦程序组里能找到。打开之后界面很简单，右键空白区域或者点工具栏，选择“注册服务”，然后浏览到你的dm.ini文件，服务名会自动带出来，通常形如DmServiceDMSERVER。确认之后服务就注册好了，可以在 Windows 服务管理器里看到它。

第二种是命令行方式，一般用bin目录下的相关工具，指定实例名、dm.ini 路径、服务名等参数完成注册。这种方式适合写进自动化脚本，批量部署时特别省事。但要注意不同小版本的工具名和参数可能有差异，执行前先用 help 看一眼，别硬套。

我更推荐生产环境用图形化方式注册，然后把注册结果记录下来。原因很简单，图形化界面会帮你处理掉一些路径转义和权限继承的问题，命令行参数写错一个字符，服务注册成功了但启动失败，排查成本反而更高。

4.2 多实例场景的服务命名规范

一台服务器上跑多个达梦实例是常态，比如一个主库实例加一个测试实例，或者主备两个实例。这时候服务命名就很重要了。默认命名是DmService加实例名，如果两个实例的实例名都是 DMSERVER，服务名就撞了。

我现在的命名习惯是DmService+ 业务代号 + 端口，例如DmServiceOrder5236、DmServiceTest5237。这样在服务管理器里一眼就能看出来这个服务对应哪个库、哪个端口，出问题的时候不需要再去翻配置。同时每个实例的 dm.ini 里端口必须和实际监听一致，服务名里的端口只是给人看的标识，真正生效的是 dm.ini 里的 PORT_NUM。

还有一个容易忽略的点：多实例环境下，每个实例的服务账户最好保持一致，目录权限也按同一套规则配。混用账户容易出现“A 实例能启动、B 实例报权限错误”这种诡异现象，排查起来很费时间。

4.3 启停顺序和开机自启的取舍

Windows 服务默认可以设置自动启动、手动启动、延迟启动。达梦实例我一般建议设成“自动（延迟启动）”。原因是服务器开机时，网络、磁盘、依赖服务都在初始化，如果达梦服务启动太早，可能因为磁盘还没就绪导致挂载数据文件失败。延迟启动能把这个风险降到很低。

停止服务的时候也有讲究。生产实例不要直接点 Windows 服务管理器里的“停止”，因为那是强制终止进程，可能让实例处于异常关闭状态。正确做法是先用 disql 连上去执行正常关闭命令，或者用达梦自己的服务管理工具发出停止指令，让数据库把脏页刷盘、做一次干净的检查点。只有在实例已经卡死、无法正常关闭的情况下，才动用服务管理器的强制停止。

提示：实例首次注册服务之后，建议手动启动一次并观察服务日志，确认没有报错，再把它设置为自动启动。别注册完就直接重启服务器去验证，那样一旦起不来，排查环境更复杂。

5. 实例连通性验证与首轮体检

5.1 用 disql 做本地登录验证

服务跑起来之后，第一件事是验证本地能不能连上。达梦自带的命令行客户端是disql.exe，在bin目录下。最简单的登录方式：

disql.exe SYSDBA/Dm@12345678@localhost:5236

密码里有特殊字符的时候，Windows 命令行下要注意转义，必要时用引号把整段包起来。登录成功会进入SQL>提示符，这时候可以先跑几条命令看看：

SELECT * FROM V$INSTANCE; SELECT NAME, STATUS$ FROM V$DATABASE; SELECT * FROM V$VERSION;

第一条看实例状态和启动时间，第二条看数据库挂载状态，第三条看版本号。这几条都正常返回，说明实例本身没有问题。如果连不上，先检查服务是否真的在运行、端口是否被防火墙拦了、监听地址是否是0.0.0.0还是只绑了本地。

5.2 用管理工具和客户端连接

本地验证通过之后，下一步是图形化工具连接。达梦自带的“DM管理工具”在tool目录下，打开之后新建连接，填主机、端口、用户名、密码即可。它能连上，说明实例的网络监听和认证都没问题。

如果是外部应用连接，比如 Java 应用、报表工具、其他数据库客户端，常见的连接失败原因有几类：端口没放开、实例的监听配置只允许本地、连接串里的服务名或实例名写错、驱动版本与数据库版本不匹配。达梦的 JDBC 连接串格式大致是jdbc:dm://host:5236，具体写法以后续章节再细说，这里先记住一点：连接问题永远先分层排查，从网络到服务再到认证，一层层往下看，不要一上来就怀疑数据库本身。

5.3 建库之后必须做的几项检查

实例刚建好，我通常会做一轮“体检”，把几项关键配置确认一遍，避免后面踩坑。检查清单如下：

其中归档这一项要特别说。刚建好的实例默认可能没有开归档，如果你后面要做热备、主备同步、增量备份，归档是前提。开归档需要把实例切到配置状态，修改参数后重启，步骤本身不复杂，但一定要在建库初期就规划好，别等数据量大了再折腾。

6. 创建实例常见报错与排查实录

6.1 报错速查表

建实例这个阶段，报错类型其实就那么几种，我按遇到频率排了个序，做成速查表：

这张表能覆盖八成以上的问题。真正难缠的是那些不报错但行为不对的情况，比如实例能启动、能连上，但查询结果中文是问号，那基本就是字符集或客户端编码的问题，需要从客户端环境变量和应用连接参数两头查。

6.2 端口占用和服务启动失败

端口占用在建多实例的时候特别常见。默认端口 5236 一旦被第一个实例占了，第二个实例如果不改端口，启动时就会失败。表现是服务启动后很快又停了，日志里能看到监听失败的记录。处理方法很简单，打开 dm.ini 把 PORT_NUM 改成别的值，比如 5237，重启服务即可。

服务启动失败的另一个高频原因是权限。Windows 服务默认以本地系统账户运行，如果你的数据目录是某个普通用户创建的，系统账户可能没有完全控制权限。解决办法是在服务属性里把登录账户改成创建目录的那个账户，或者干脆给系统账户补齐目录权限。我一般选后者，权限模型更清晰。

还有一种情况是 dm.ini 路径写错了。服务注册的时候指向了旧路径，你把数据目录挪了位置，服务启动就会找不到配置文件。这种问题排查方法是看 Windows 事件查看器里的服务日志，或者直接手动执行dmserver.exe dm.ini路径前台启动，报错信息会直接打在屏幕上，比看服务日志快得多。

6.3 字符集选错之后怎么办

字符集是建库时定死、后期最难处理的参数之一。如果发现选错了，比如应用需要 UTF-8 但你建成了 GB18030，不要指望改参数能解决，唯一可靠的路子是重建实例，然后用逻辑导出导入的方式把数据迁过去。

这个教训可以避免：建库前把应用侧的编码要求问清楚，特别是要跨系统对接的库。还有一个细节是客户端编码，即使数据库是 UTF-8，如果 disql 或者管理工具的客户端编码设成 GBK，查出来的中文照样乱码。所以乱码问题要从“库端字符集”和“客户端编码”两个方向同时确认，只改一头是没用的。

提示：如果只是测试库、数据可以丢，那最快的办法就是删掉目录重建实例，别浪费时间研究字符集转换。

6.4 几个我踩过的实操心得

第一，dminit 建库时把参数完整记录下来，包括每一个值和选择理由，存在项目文档里。半年后你回头看，能省掉大量猜测时间。我现在的习惯是建完库就把完整的 dminit 命令存成一个.sh或者.bat文件，放在数据目录旁边。

第二，第一次建库别用生产目录练手，找一个临时目录先跑一遍完整流程，包括注册服务、连接验证、启停测试，确认所有环节都通了，再在正式目录上重做。这个习惯帮我避免过好几次“把正式环境当试验田”的尴尬。

第三，实例建完之后立刻做一次干净的全量备份。刚建好的库很小，备份几秒钟就完事，但它是你的基线。后面万一配置改崩了，回滚到这个基线比重装一遍快得多。

第四，Windows 上路径里的空格和中文一定要避开。我见过因为程序目录带中文导致服务注册工具解析失败的案例，排查了一下午，最后发现就败在一个中文字符上。

我个人在 Windows 环境里建达梦实例的体会是，图形向导和 dminit 两条路都要会，前者用来快速建立理解和处理单实例，后者用来做批量部署和参数精确控制。参数里真正不能拍脑袋的只有页大小、字符集、大小写敏感这三个，其它的都有比较宽的容错空间，而这三个恰恰是最容易被无脑下一步带过去的。养成建库前先列参数清单的习惯，比事后补救划算得多。后续如果要做主备同步或者读写分离，这些建库参数还得保持主备两端完全一致，到时候你会感谢现在认真填参数的自己。