装完 DM9 别急着建表：我把它的 387 个动态视图翻了一遍

四条只读 SQL，读出 DM9 的能力边界。 9 月 20 日 16:13，dminit 报出 create dm database success。我没有建业务表，先跑了四条只读查询——387 个动态视图、46 个并行与向量相关参数、1 张授权表，以及一条把执行码身份说清楚的 ID_CODE。这篇文章不是安装教程，是我从这四条查询里读出来的技术判断。 全文没有一个性能数字，因为压测还没跑；编数字这事我不干。

作者：马顺华（江湖人称"数据库界华少"）｜ shunwah 星辰数智社

实验环境：

目录

1. 为什么要翻数据字典
2. 探针翻车现场：WAIT 里含 AI
3. 第一条 SQL：387 个视图，数字本身不是重点
4. 第一条的另一半：分布式随包给，多租户要解锁
5. 第二条 SQL：向量能力，藏在两个参数名里
6. 第二条的另一半：装完默认不开并行
7. 第三条 SQL：一张授权表，写着能力的边界
8. 第四条 SQL：版本号不是一个数，是一个坐标
9. 快问快答
10. 我的四条判断
11. 使用须知（三条边界）
12. 总结与下一步实验计划

一、为什么要翻数据字典

装库这事有个通病：装完立刻 CREATE TABLE，能跑通就收工。我干这行久了，越来越不信"能跑通"这三个字—— 能跑通只说明它的语法认了，不说明它的能力在。

数据库的数据字典，是它身上唯一不会说谎的地方。宣传材料会说"全面支持"，参数表会说"已预留"，而只有 v$ 开头的那些视图和 para_name 那些参数，是它运行时真实的自我描述。

我给自己定了个规矩： 新库落地，先跑四条只读 SQL。

1. 一条问它有多少视图 —— select count(*) from v$dynamic_tables;
2. 一条问它有哪些参数 —— select para_name, para_value from v$dm_ini where ...;
3. 一条问它给了我什么授权 —— select * from v$license;
4. 一条问它是谁 —— SELECT ... FROM (SELECT REGEXP_SUBSTR(ID_CODE,'[^-]+',1,1) AS VER));

四条查完，这台库 能干什么、不能干什么、能不能用、是谁给的，心里就有谱了。而且这几条在任何库上都能跑，你现在就可以打开自己的库试一下。

这篇就按这四条的顺序走。跑完你会发现一件挺有意思的事： 同一台库，四种问法，四个不一样的答案——而且每一个都对。

二、探针翻车现场：WAIT 里含 AI

我想知道"AI 能力在不在"，于是我写了一句：

select name from v$dynamic_tables where name like '%AI%';

结果挺唬人，跳出来一串：

V$TRXWAIT
V$WAIT_CLASS
V$WAIT_HISTORY
V$SESSION_WAIT_HISTORY

我第一反应还挺高兴：你看，DM9 的 AI 能力果然有视图暴露出来。高兴了大概十秒钟。

然后我盯着 V$TRXWAIT 看了半天，反应过来—— 这是 WAIT 里含 AI。事务等待、等待事件分类、会话等待历史，全是锁和等待相关的东西，跟 AI 一个字的关系都没有。

这就是模糊匹配的经典翻车：你搜的不是"AI 能力"，你搜的是"字符串里恰好有 A 和 I"。 造这行的证据，先怀疑是不是巧合，再怀疑是不是自己筛错了。

我的解法很笨： 不看关键词命中，看命名体系。 V$ 视图的命名是有规矩的——前缀决定领域，后缀决定粒度。关键词会骗你，命名体系不会。

三、第一条 SQL：387 个视图，数字本身不是重点

第一条问总数：

SQL> select count(*) as view_cnt from v$dynamic_tables;

真实输出：

行号       VIEW_CNT
---------- --------------------
1          387
已用时间: 3.267(毫秒). 执行号:68705.
SQL>

图 01 · select count(*) from v$dynamic_tables 输出

387 这个数大不大？不知道，我没跟任何一个版本对标过。 没有实测过的对比数字，我不写进文章里。

真正的重点在这 387 个视图的 分布。我把名字里带 VEC / AI / TENANT / DPC / RAG 的全部拉出来，一共 51 行：

SQL> select name from v$dynamic_tables  2   where name like '%VEC%' or name like '%AI%' or name like '%TENANT%'
  3      or name like '%DPC%' or name like '%RAG%';

真实输出（51 行，节选关键分组）：

行号       NAME
---------- ------------------------------
1          V$TRXWAIT
2          V$WAIT_CLASS
3          V$WAIT_HISTORY
14         V$DPC_TENANT_INI_SUPPORT
16         V$DPC_ENET
17         V$DPC_ESITE
34         V$DPC_EDCT_RAFT
39         V$DPC_TS_MOVE
40         V$ASM_FAIL_AU
45         V$REPAIRED_PAGE
51         V$DPC_NSITE
51 rows got
已用时间: 4.421(毫秒). 执行号:68706.

图 02 · 那 51 条命中，一半是假阳性

按前缀分下来，格局很清楚：

我的判断就一句：

视图命名体系，是数据库愿意被运维的程度。

一个只有几十个 v$ 视图的库，不是说它不行，是你出了事只能靠猜。387 个视图意味着你能看见的东西多—— 能看见才能定位，能定位才谈得上自治。

四、第一条的另一半：分布式随包给，多租户要解锁

还是那 51 条命中。带 TENANT 的只有三个，而且 全都带 DPC 前缀：

14         V$DPC_TENANT_INI_SUPPORT
47         V$DPC_EDCT_TENANT_USER
48         V$DPC_TENANT_PARA

图 03 · 30 多个 DPC 视图，3 个带 DPC 前缀的 TENANT（可与图 02 复用同一张截图，或框选放大）

三个，全都是 DPC 前缀。这个细节很关键。

如果多租户是"单机上切几个互相看不见的库"，那视图名应该叫 V$TENANT_* 或者 V$CONTAINER_*，不该挂在 DPC（分布式并行计算）底下。挂在 DPC 底下，说明 DM9 里的租户是 分布式形态下的租户——为了多租户共享一套集群资源而设计的隔离，不是让你在单机上假装同时运维十个库。

这两个诉求长得像，实际完全是两件事。想清楚你要哪种再评估，不然容易买椟还珠。

DPC 那 30 多个视图还告诉我另一件事：

分布式内核是随安装包一起装上的。

ENET、 ESITE、 STASK_THRD、 EDCT_RAFT、 TS_MOVE 全在，不需要你另装一个"分布式版本"。名字里那个 RAFT 也值得记一笔——一致性协议走的是 Raft，这至少说明它不是"共享存储伪分布式"那一路。

⚠️ 一句我必须说清楚的话：视图在，不等于能跑。 单机实例里这些视图是不是空的、分布式语法是不是直接报错，我还没验。这是我下一步第一件要做的事，做完了再下结论。今天我只能说到"随包安装"这一层。

五、第二条 SQL：向量能力，藏在两个参数名里

视图层我先查了： VEC 命中 0 个， RAG 命中 0 个。 按我上面那套标准，看着像"没做向量"。

如果我就此收手，结论会错得离谱。换个地方问——参数层：

SQL> select para_name, para_value from v$dm_ini  2   where para_name like '%VEC%' or para_name like '%AI%'
  3      or para_name like '%TENANT%' or para_name like '%HTAP%'
  4      or para_name like '%PARALLEL%';

真实输出（46 行，节选与向量、并行相关的三行）：

行号       PARA_NAME                          PARA_VALUE
---------- ---------------------------------- ----------
44         HNSW_SHARD_SEARCH_PARALLEL_DEGREE  1
45         PARALLEL_DML                       0
46         VECTOR_INDEX_BUILD_PARALLEL_DEGREE 4
46 rows got
已用时间: 12.582(毫秒). 执行号:68707.

图 04 · 向量和并行能力的证据都在这一屏里

关键不是值，是名字。 HNSW 出现在参数名里。

HNSW 是一种近似最近邻的图索引算法（Hierarchical Navigable Small World）。它出现在数据库内核参数里，说明向量索引是 在内核里实现的一套索引结构——不是一个外挂组件、一张专门表、一个插件。

“装在口袋里"和"长在骨头里”，差别不在今天，在明天。
装在口袋里的东西，优化器不认识它、执行计划看不见它、事务和权限不管它；长在骨头里的东西，才能真正参与查询优化。

顺便解释为什么视图层查不到： 因为它是索引，不是特性。 索引是引擎内部的事，没有理由给你一个 V$VECTOR 视图。视图不露脸，恰恰是它埋得深的证据。

打个比方：装修里有个概念叫"预留专线"。你家电表箱里有没有给空调留的那路线，从电表箱外面是看不出来的——墙上没插座，不代表线没走。等你真要装空调，一个是从电表箱里接线，一个是从客厅砸墙。

六、第二条的另一半：装完默认不开并行

还是那 46 行参数。其中四行让我盯着屏幕坐了一会儿：

行号       PARA_NAME                   PARA_VALUE
---------- --------------------------- ----------
4          MAX_PARALLEL_DEGREE         1
5          PARALLEL_POLICY             0
6          PARALLEL_THRD_NUM           10
7          PARALLEL_MODE_COMMON_DEGREE 1
...
45         PARALLEL_DML                0

图 05 · POLICY=0 / DEGREE=1 / DML=0，8 核在跑单线程（可与图 04 复用同一张截图，框选放大那几行）

翻译一下： 并行策略关闭、最大并行度 1、并行 DML 关闭，但它给你准备了 10 个并行线程。

这意味着我这台 8 核的机器，装完之后所有查询都是单线程跑的。8 个核闲着 7 个—— 不是它不能并行，是它默认不并行。

我第一反应是"太保守了"。但坐下来想了想，改了主意：

对小型 OLTP 来说，默认关闭并行是对的。
一条走索引的十毫秒点查，你要是给它拿去并行调度，调度开销比省下来的时间还多。数据库默认值要照顾的是"大多数人的大多数查询"，不是我的压测场景。

所以我不打算把它写成"达梦有个坑"，我写成**“达梦很克制”**。

但克制有个前提： 你得知道开关在哪。 默认关闭并行这件事，如果没人把它标注成"上车第一件事"，新手就会带着"这库怎么这么慢"的印象用下去，然后得出一个完全错误的结论。

这一篇我不展开它——这个开关到底值多少，我另开一篇实测，把执行计划、加速比，连同代价一起摆出来。这里的任务只是： 把它指出来，告诉你它是默认关的。

这里还藏着一个容易混淆的点：DM 的并行参数分两套。一套给 SQL 执行用（ PARALLEL_POLICY / MAX_PARALLEL_DEGREE），一套给内部任务用（ DPRTSK_PARALLEL_NUM = 32、 RLOG_PARALLEL_NUM = 16、 REDOS_PARALLEL_NUM = 1）。 内部并行度开着，不代表你的查询会并行——这两套别混着看。

七、第三条 SQL：一张授权表，写着能力的边界

第三条 SQL 是问它给了我什么授权。这张表信息密度极高：

SQL> select * from v$license;

真实输出：

行号       LIC_VERSION SERIES_NO SERVER_SERIES SERVER_TYPE SERVER_VER EXPIRED_DATE
---------- ----------- --------- ------------- ----------- ---------- ------------
           AUTHORIZED_CUSTOMER AUTHORIZED_USER_NUMBER CONCURRENCY_USER_NUMBER MAX_CPU_NUM
           ------------------- ---------------------- ----------------------- -----------
           NOACTIVE_DEADLINE HARDWARE_ID CHECK_CODE PRODUCT_TYPE PROJECT_NAME CPU_TYPE
           ----------------- ----------- ---------- ------------ ------------ --------
           OS_TYPE MAX_CORE_NUM HARDWARE_TYPE CLUSTER_TYPE DATE_GEN   SERVER_SERIES_NAME
           ------- ------------ ------------- ------------ ---------- ------------------
1          3.00        dm66n367  D             3           X.X.x.x    2027-04-17
           DEVELOP USER        1                      NULL
           NULL                                     DM V9                     Others
           Others 1111                1900-01-01
已用时间: 2.303(毫秒). 执行号:68708.

图 06 · 那一行 CLUSTER_TYPE = NULL，值不少钱

我从这一行里读出来三件事：

1｜身份　 EXPIRED_DATE = 2027-04-17、 PRODUCT_TYPE = DM V9、 AUTHORIZED_CUSTOMER = DEVELOP USER。试用授权身份坐实，有效期到明年 4 月。

2｜边界　 AUTHORIZED_USER_NUMBER = 1、 CLUSTER_TYPE = NULL。一个授权用户，集群类型空。 这解释了为什么 DPC 视图在、租户视图在，但你可能用不了。

3｜硬件　 HARDWARE_TYPE = Others、 CPU_TYPE = Others。试用授权不识别你的硬件类型。

第 2 条是这轮探针里最有价值的一条：

不是版本阉割，是授权形态。
这两者的区别很大：版本阉割你只能换版本，授权形态你可以谈。

很多人评估一个库，看的是"它有没有这个功能"；而实际决定你能不能用的，往往是授权文件里那一行 CLUSTER_TYPE。所以—— "功能存在"和"能力可用"之间，隔着一张纸。这张纸就是授权。

顺带把字符集也确认了，和安装时 CHARSET=1 对得上：

SQL> select sf_get_unicode_flag() as unicode_flag;

行号       UNICODE_FLAG
---------- ------------
1          1
已用时间: 2.058(毫秒). 执行号:68709.

八、第四条 SQL：版本号不是一个数，是一个坐标

第四条最容易被跳过，也最有意思。先说个前提——上一篇里我写过一句：真正的版本号，要等连库后查 v$version 才拿得到。 这话我说得太满。 连库之后我老老实实查了一遍：

SQL> select * from v$version;

真实输出：

行号       BANNER
---------- ---------------------------------
1          DM Database Server 64 V9
2          DB Version: 0x7000d
3          03151060506-20260417-322930-20218
4          Msg Version: 3
5          Gsu level(5) cnt: 102
已用时间: 0.447(毫秒). 执行号:69002.

图 07 · 第 3 行就是 ID_CODE，它只是不告诉你

五行。它给了我大版本 DM9、内核编码 0x7000d，然后—— 第 3 行那串数字： 03151060506-20260417-322930-20218。

这不是随机码，它就是 ID_CODE。 v$version 其实把它交出来了，只是它 不告诉你"这就是版本号"。

真正把版本号解出来的，是把它拿去过一遍。DM 内置了 ID_CODE，一条 SQL 就能拆开：

SQL> SELECT
  2    ID_CODE ,  3    BUILD_TYPE ,  4     TO_NUMBER(SUBSTR(VER,1,2),'XX')||'.'||
  5     TO_NUMBER(SUBSTR(VER,3,2),'XX')||'.'||
  6     TO_NUMBER(SUBSTR(VER,5,2),'XX')||'.'||
  7     TO_NUMBER(SUBSTR(VER,7,2),'XX') AS INNER_VISION  8   FROM (SELECT
  9                 DECODE(SUBSTR(VER,1,2),'03','企业版','05','安全版','02','标准版','其他') AS BUILD_TYPE, 10                       RAWTOHEX(CAST(SUBSTR(VER,3) AS INT)) AS VER 11            FROM (SELECT REGEXP_SUBSTR(ID_CODE,'[^-]+',1,1) AS VER));

真实输出：

行号       ID_CODE                             BUILD_TYPE INNER_VISION
---------- ----------------------------------- ---------- ------------
1          --03151060506-20260417-322930-20218 企业版     9.1.0.26
已用时间: 5.247(毫秒). 执行号:69003.

图 08 · 一行输出把"我是谁"说完了

一行出结果： 企业版 · 9.1.0.26 · 构建于 2026-04-17。串里还压着两个通常没人提的字段：SVN 代码号 322930、分支号 20218。

那四个数字不是玄学，是十六进制：

'03151060506' → 取第 3 位起 '151060506'
              → 十进制转十六进制 '0901001A'
              → 09 / 01 / 00 / 1A → 9 . 1 . 0 . 26

末字节 1A 是十六进制，等于 26。这一步不用信我，自己拿计算器按两下就行；也可以让数据库替你按：

select rawtohex(cast(substr('03151060506',3) as int));   -- 得到 0901001A

把三把尺子摆在一起，事情就清楚了：

版本号不是一个数，是一个坐标。
所以"企业版"和"试用版"不打架：前者说的是这套执行码，后者说的是那张授权。同一套企业版的安装包，换一张授权文件，就是另一种身份。这也把上一节那句"不是版本阉割，是授权形态"补全了 —— 你手里不是阉割包，是原装包加一把临时钥匙。

一个坑： ID_CODE 串前面有两个横杠（ --）。谁要是用硬切前两位的办法去拿构建类型，会正正切到横杠上，判断落进兜底分支显示成"其他"，然后得出结论：试用版连版本号都是空的。取"第一个非横杠片段"（ [^-]+）那一步，就是为了跳过它。

所以开头那条"装完先跑三条只读 SQL"，现在得改成四条： 视图、参数、授权，再加一条 ID_CODE。 前三条看它有什么，第四条看它是谁。

九、快问快答

Q：DM9 有向量能力吗？
A：参数名里有 HNSW，视图里没有 VEC。我的判断是有，而且在内核里。但索引能不能建、检索时权限怎么走，我还没跑，不吹。

Q：387 个视图算多吗？
A：不知道，我没跟别的版本对齐过。我只知道它把"盘会坏""页会坏"都做成了视图。

Q：为什么不直接建表压测？
A：因为我想先知道它有什么，再决定压什么。顺序错了，压出来的数字也没意义。

Q：装完最该改的一个参数是什么？
A：看你场景。小 OLTP 别动并行，大 AP 第一件事就是把并行开起来。

Q：多租户能用在单机上吗？
A：视图命名告诉我这是分布式形态的能力，我下一步就验它，不猜。

Q：这篇为什么一个性能数字都没有？
A：因为我一个都没跑。编一个数字换来的阅读量，还不起。

十、我的四条判断

十一、使用须知（三条边界）

① 这篇没验分布式。 DPC 视图在，是否可用我没测。单机上的结论不能外推到集群。

② 这条授权只能一个人用（ AUTHORIZED_USER_NUMBER = 1）。拿它测并发，你测的是试用授权的限制，不是 DM9 的能力。

③ 全文没有一个性能数字。 不是不想给，是还没跑——跑完会另开一篇。

这三条不是缺点，是前提。

总结与下一步实验计划

1. 装完新库，先跑四条 SQL： 视图、参数、授权、ID_CODE。
2. 关键词命中不是证据，命名体系才是。
3. 视图里查不到的， 去参数里找。

接下来我要跑四组实验，数字难看也照发：

数据好，我写；数据不好，我也写。 先把现场看清楚，再下结论——这个习惯，不管面对的是 DM9 还是我天天在查的那把锁，都一样。

本文为「达梦同行者」DM9 技术征文投稿。所有终端输出均为 worker3 实机真实记录，未做删改；文中不含任何未实测的性能数字。