DCA中的表空间、用户、权限、导出和导入，经常被拆成多个零散知识点。单独看每一项都不难，真正到了排错时，却容易分不清是对象没建成功、用户没有权限，还是备份文件根本没有导入目标模式。本文用一条订单数据链把这几个知识点串起来：创建独立表空间，建立业务用户，写入数据，按模式导出，再映射导入到恢复用户，最后核对行数与金额。

一、实验目标和边界

实验在一套可重建的DM8测试库中完成，全部动作均在测试环境执行。创建的资源如下：

表空间：TS_DCA
业务用户及模式：DCA_USER
恢复用户及模式：DCA_RESTORE
测试表：T_ORDER
导出文件：DCA_USER.dmp

本文验证的是dexp/dimp的对象级逻辑迁移，不等同于完整数据库物理备份。逻辑导出适合把用户、模式或表迁移到另一个环境；整库灾难恢复、时间点恢复和损坏修复仍需要配套的物理备份与恢复方案。

二、创建独立表空间

以SYSDBA登录后，先创建业务表空间：

CREATE TABLESPACE TS_DCA
DATAFILE 'TS_DCA01.DBF'
SIZE 64
AUTOEXTEND ON NEXT 16 MAXSIZE 512;

示例使用相对数据文件名，文件会落在当前数据库的数据目录中，便于初学者减少路径与环境差异。生产环境应根据存储规划填写完整路径，并提前确认目录存在、达梦运行账号具有读写权限、容量上限符合要求。

这里不建议机械复制网上的“64M”写法。DM8表空间语句中的SIZE、NEXT和MAXSIZE使用数据库规定的容量表达方式，具体默认值与单位应以当前版本产品手册为准。本文参数已在测试版本中执行验证，建表后数据确实落在TS_DCA中。

三、用户、模式与权限不是同一个概念

创建业务用户，并指定默认表空间：

CREATE USER DCA_USER IDENTIFIED BY "DcaUser2026"
DEFAULT TABLESPACE TS_DCA;

随后授予完成实验所需的权限：

GRANT CREATE SESSION TO DCA_USER;
GRANT CREATE TABLE TO DCA_USER;
GRANT CREATE VIEW TO DCA_USER;

DM8中，用户登录身份、同名模式和对象存储位置具有关联，但观察问题时仍应区分三者。用户存在，不代表模式中的对象一定完整；对象已经存在，也不代表当前用户拥有查询或修改权限。

可以用以下语句复核用户的默认表空间：

SELECT USERNAME, DEFAULT_TABLESPACE
FROM DBA_USERS
WHERE USERNAME IN ('DCA_USER', 'DCA_RESTORE');

在本次验证中，两个用户都返回默认表空间TS_DCA。若前一步创建表空间失败，应优先修复表空间错误，不要继续执行创建用户；否则用户可能因默认表空间不存在而创建失败。

四、建立可核对的数据基线

使用DCA_USER登录后创建订单表：

CREATE TABLE T_ORDER (
ORDER_ID BIGINT PRIMARY KEY,
CUSTOMER_NAME VARCHAR(50) NOT NULL,
AMOUNT DECIMAL(10,2) NOT NULL,
CREATED_AT TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

插入三条测试数据并提交事务：

INSERT INTO T_ORDER (ORDER_ID, CUSTOMER_NAME, AMOUNT)
VALUES (1001, 'East', 99.50);

INSERT INTO T_ORDER (ORDER_ID, CUSTOMER_NAME, AMOUNT)
VALUES (1002, 'South', 350.00);

INSERT INTO T_ORDER (ORDER_ID, CUSTOMER_NAME, AMOUNT)
VALUES (1003, 'Northwest', 1699.30);

COMMIT;

计算基线结果：

SELECT COUNT(*) AS ORDER_COUNT, SUM(AMOUNT) AS TOTAL_AMOUNT
FROM T_ORDER;

预期结果为3行、金额合计2148.80。接下来还可以查询DBA_TABLES，确认DCA_USER.T_ORDER使用了TS_DCA表空间。建立基线值很重要，因为恢复是否成功不能只看“导入过程没有报错”，还必须核对恢复端的数据。

五、按用户模式导出

进入达梦bin目录，执行dexp：

dexp.exe USERID=SYSDBA/Your_StrongPwd1@127.0.0.1:5236 FILE=DCA_USER.dmp LOG=DCA_USER.log OWNER=DCA_USER

本次实际导出的DMP中只有一个模式DCA_USER和一张表T_ORDER，表数据为3行。导出完成后应同时检查DMP文件、日志文件以及日志末尾的状态信息。只看到命令行返回，不代表导出内容完整。

需要特别说明的是，部分旧资料会在dexp命令后加入DIRECT=Y。我在当前测试安装包中执行时，工具明确给出了“无法识别参数DIRECT”的警告，随后停止导出。这说明数据库命令也存在版本差异，不能把旧脚本原样复制到新环境。使用前可先查看当前工具帮助，再决定参数。

六、映射导入到恢复用户

先创建恢复用户：

CREATE USER DCA_RESTORE IDENTIFIED BY "DcaRestore2026"
DEFAULT TABLESPACE TS_DCA;

GRANT CREATE SESSION TO DCA_RESTORE;
GRANT RESOURCE TO DCA_RESTORE;

使用dimp将原模式映射到恢复模式：

dimp.exe USERID=SYSDBA/Your_StrongPwd1@127.0.0.1:5236 FILE=DCA_USER.dmp LOG=DCA_IMPORT.log OWNER=DCA_USER REMAP_SCHEMA=(DCA_USER:DCA_RESTORE) IGNORE=Y

本次导入日志显示：先在DCA_RESTORE中创建T_ORDER，随后成功导入3行数据，最终提示“成功导入，没有出现警告”。REMAP_SCHEMA解决的是模式名冲突问题，但目标用户必须先存在。把用户名、密码和权限一起导出并不意味着目标用户可以直接用原密码登录，账号安全策略仍应在目标环境重新核对。

七、用查询结果完成闭环

使用恢复用户登录并执行同一条聚合查询：

SELECT COUNT(*) AS ORDER_COUNT, SUM(AMOUNT) AS TOTAL_AMOUNT
FROM T_ORDER;

恢复端同样返回3行、2148.80。进一步查询DBA_TABLES后，可以看到DCA_USER.T_ORDER与DCA_RESTORE.T_ORDER都位于TS_DCA表空间。源端与目标端的行数、金额汇总和对象位置一致，才构成一次完整的恢复验证。

如果结果不一致，排查顺序如下：

1. 先看导出日志是否完整导出目标模式与数据行。
2. 再看导入日志是否创建了表、约束和索引，是否出现交互式确认。
3. 检查源端是否在导出前提交了全部事务。
4. 检查目标用户是否存在、默认表空间是否正确。
5. 最后才比较数据。不要用IGNORE=Y掩盖所有错误；它适合明确知道要忽略哪类创建冲突的场景，不应成为固定参数。

八、从命令走向DCA能力

这条实验链覆盖了DCA常见的数据库对象生命周期：表空间决定数据存放位置，用户决定登录身份，模式决定对象命名空间，权限决定能够执行哪些操作，dexp/dimp负责对象级迁移，查询负责最终验收。

复审时，可以故意制造几个受控错误，例如使用已存在的数据文件名、遗漏目标用户、导出前后少提交一次事务，再根据日志定位原因。这样的练习比单纯背命令更接近实际运维。

最后要记住备份恢复的基本纪律：先看日志，再做复核；先在测试环境验证，再考虑生产变更；逻辑备份能迁移对象，但不能替代完整的物理备份体系。把这条原则落实到每一次实验，才是DCA博文希望呈现的实战价值。

参考平台：达梦数据在线服务平台【培训园地】
https://eco.dameng.com/community/training

参考说明：本文实验在DM8测试环境中完成，内容为原创整理；未引用外部文章原文。当前测试环境执行窗口中的部分提示使用英文或格式略有差异，实际输出以所用DM8版本为准。