达梦命令行交付实操：登录、表空间、授权与建表 · 交互版

交付现场照抄的五条命令 —— 能登录、有地方存、有人能用、能建出表。每条都是代入真实值的样子，点开能看到执行完屏幕上长什么样。顺利的话五分钟跑完，下面的问题区根本不用看。

实例实测 DM8 2026-08-03 5 步全程可复制

disql CREATE TABLESPACE CREATE USER GRANT CREATE TABLE

五条命令，照抄就能跑通

命令里的值（口令、IP、表空间名）换成你现场自己的，其余一个字都不用改。点左侧任一步，右侧就是命令和执行完的屏幕输出。

1登录

看到 SQL> 就成了

点击查看 →

2建表空间

给业务数据一个存放区

点击查看 →

3建用户

交付给客户的业务账号

点击查看 →

4授权

一条 GRANT 完事

点击查看 →

5建表

插两行数据，看到它们回来就收工

点击查看 →

步骤明细已固定

左侧点一步，这里显示该步的命令和执行完的输出。点同一块可取消固定，按 Esc 也可取消。

输出来源：DM Database Server 64 V8（03134284172-20260803），下面所有输出都是从这个环境里原样取的，没有改写。

先找到 disql —— 它就在数据库安装目录的 bin 里：

cd /opt/dmdbms/bin

Linux 默认装在 /opt/dmdbms，Windows 默认在 D:\dmdbms\bin。不在这也没事，一条命令搜出来：

find / -name disql 2>/dev/null

看到它了，把 IP 换成客户库的，口令换成现场 SYSDBA 的：

./disql SYSDBA/'"Dameng123"'@127.0.0.1:5236

执行完屏幕上长这样：

Server[127.0.0.1:5236]:mode is normal, state is open
login used time : 2.762(ms)
disql V8
SQL>

看到 SQL> 提示符就是登录成功，直接进下一步。

一条建完。尺寸不用纠结，这套数（初始 10G、一次扩 2G、上限 200G）就是交付默认值：

CREATE TABLESPACE TS_TEST
  DATAFILE 'TS_TEST.DBF'
  SIZE 10240
  AUTOEXTEND ON NEXT 2048 MAXSIZE 204800;

执行完屏幕上长这样：

executed successfully
used time: 00:00:11. Executed id is 53300.

看到成功就继续。表空间长什么样，交付验收时在管理工具里点开「表空间」就能看到，不用写 SQL 查。

建业务账号，钉死它默认往哪个表空间里放数据：

CREATE USER TEST
  IDENTIFIED BY "Deliv_2026"
  DEFAULT TABLESPACE TS_TEST;

执行完屏幕上长这样：

executed successfully
used time: 3.872(ms). Executed id is 53301.

继续。口令后面客户要改，一条 ALTER USER TEST IDENTIFIED BY "新口令"; 就行（见问题区）。

一条授权，建表和查字典的权限都在里面：

GRANT RESOURCE, VTI, SOI TO TEST;

执行完屏幕上长这样：

executed successfully
used time: 2.104(ms). Executed id is 53302.

继续。这三个角色各自给什么、为什么这么授，问题区里有拆解 —— 顺利跑通的话不用看。

用刚建的业务账号重新登录（把 SYSDBA 换成 TEST），然后建表、插两行、查回来：

CREATE TABLE T_ORDER (
  order_id   BIGINT IDENTITY(1,1) PRIMARY KEY,
  order_no   VARCHAR(32) NOT NULL,
  amount     DECIMAL(12,2) DEFAULT 0,
  status     TINYINT DEFAULT 0,
  created_at TIMESTAMP DEFAULT SYSDATE
);

INSERT INTO T_ORDER(order_no, amount, status)
  VALUES ('SO20261029001', 1280.00, 0);
COMMIT;

SELECT order_id, order_no, amount, status, created_at FROM T_ORDER;

执行完屏幕上长这样：

SQL> 2   3   4   5   6   7   executed successfully
used time: 28.171(ms). Execute id is 12584813.
SQL> affect rows 1
SQL> executed successfully

SQL> select order_id, order_no, amount, status, created_at from T_ORDER;
LINEID  ORDER_ID  ORDER_NO       AMOUNT  STATUS  CREATED_AT
------  --------  -------------  ------  ------  --------------------------
1       1         SO20261029001  1280    0       2026-10-29 23:32:06.000000
2       2         SO20261029002  3560.5  1       2026-10-29 23:32:06.000000

数据查得回来，交付完成。表在哪个表空间、权限够不够，验收时管理工具里一眼能看。

常见问题：只有报错了才需要往下看

数据库本身允许，但 disql 命令行传参时会出问题：# 在登录串里是扩展选项分隔符（#{MPP_TYPE=GLOBAL,...}），用户/口令#xxx@IP:端口 会被解析成一个坏掉的扩展选项：

$ ./disql TEST/"Deliv_2026#01"@127.0.0.1:5236
 USAGE:CONN[ECT] <logon>
 ...

这不是口令错，但长得像语法错误，很多人在这里查半天。处理：给业务用户设口令避开 #；已经设了就用 ./disql /nolog 连上后再 conn 用户/口令@IP:端口 交互输入。

$ ./disql SYSDBA/WrongPwd@127.0.0.1:5236
[-2501]:Invalid username or password.
disql V8
username:

口令错时 disql 不退出，而是掉回交互输入等你再输。手工敲没关系；写脚本会挂死，脚本里加 -L（只试一次，失败即退）：

./disql -L SYSDBA/'"Dameng123"'@127.0.0.1:5236 -e "select 1"

本文的 SYSDBA/'"Dameng123"' 是 Linux shell 写法：双引号包住口令防特殊字符，外面再套一层单引号防止 shell 把双引号吃掉。

Windows cmd 里单引号是普通字符，去掉外层单引号就行：

disql SYSDBA/"Dameng123"@127.0.0.1:5236

这是交付默认值，不用现场纠结：初始 10G 对绝大多数业务库起步足够，就算业务量小也只是占了个上限额度不占实盘；每次扩 2G 是为了批量导入时少触发扩展次数（扩展次数越多，导入越慢、文件碎片越多）；上限 200G 是防爆盘的保险丝，真不够再改就是一条 ALTER TABLESPACE 的事。

唯一要改的场景：客户磁盘本身小于 200G —— 那就把 MAXSIZE 降到磁盘能承受的值。

在实例的数据目录里（dm.ini 中 path 参数指向的那个目录）。不用翻配置文件：管理工具里点开「表空间」选中它，文件路径直接就能看到；写巡检脚本就用 DBA_DATA_FILES.FILE_NAME 现查。

别把文件路径写死进脚本或文档——环境一换路径就变了，一律现查最稳。

实测（03134284172-20260803 版本）逐项查过字典：

RESOURCE（63 条系统权限）：建表、建索引、建视图、建存储过程这些「干活」的权限，都在这。

SOI（78 个字典表的 SELECT）：SYSCOLUMNS、SYSOBJECTS 这些系统字典能查到了 —— 没有 SOI，很多元数据查询会报「表不存在」。

VTI：按官方文档，本版本里是空角色。授予不报错、不挡事，照常授没毛病；只是别指望它解决「看不到视图」的问题——那要单独授 GRANT SELECT ON 视图名 TO 用户。另外各版本角色内容可能不同，你的版本自己查一遍 dba_sys_privs / dba_tab_privs 比记结论可靠。

SQL> select count(*) from dba_users;         -- [-5504]:No select privilege on object [SYS.DBA_USERS]
SQL> select count(*) from SYSDBA.T_ORDER;    -- [-2106]:Invalid table or view name [T_ORDER]

越权查别人 schema 的表时，DM 报的是「不存在」而不是「权限不足」——有意为之，不泄露对象是否存在。但排查时极易被读成「表被删了」。看到 -2106 先想权限，别急着找备份。

管理工具（或达梦管理器）里点三下就够了：① 用 TEST 登录一次（能登上、改过口令的用新口令）； ② 表空间页看 TS_TEST 存在、大小对；③ 用 TEST 看到自己的 T_ORDER 有数据。不用写 SQL 回查 —— 字典里的东西图形界面都有，界面看不到的才值得写 SQL。

能收，但没什么理由收：它给的是「对自己 schema 里对象」的基础 DML 和执行权限（实测 45 条），本来就是这个用户该有的。真回收了，用户连自己的表都操作不了。要收紧权限，正确方向是别多授系统权限和角色（尤其是 DBA），而不是去动 PUBLIC。

卡在某一步了？

把报错原文贴出来，比描述现象有用得多。

要我微信？点开看二维码（不点也行）

扫了备注「达梦」
不备注我也加

贴什么最有帮助

① 完整报错行（含 [-NNNN] 错误码，DM 的错误码是排查入口）；
② 你执行的那条语句原文（口令打码）；
③ select banner from v$version; 的输出 —— 版本不同，行为可能不同。

不要贴什么

生产库的连接串、真实口令、客户业务表的表结构。定位问题不需要这些。

邮件：jiang-chuang@qq.com

想让答案别人也能查到？在 Gitee 仓库提 issue，回复公开可查。

← 返回指南索引