前几天有个做迁移的同行问我达梦数据库dm8怎么把数据导成 SQL 文件说他用 dexp 导出来的文件打开全是乱码。我一看后缀就明白了——那是二进制的 dmp本来就不是给人看的文本。这个误会太常见了达梦数据库dm8导出 SQL 文件这件事卡人的地方往往不是命令多难而是没分清“导出”这两个字在不同的工具里到底指什么。DM8 里能产出脚本的路径至少有四五条每条路的适用边界、字符集处理、大字段表现都不一样选错了轻则返工重则导出来的脚本一执行就报错。这篇内容我按自己踩过的坑重新捋一遍把 dexp 逻辑导出、disql 加 spool 手工拼 SQL、图形化工具的导出向导、以及批量调度这几种方式拆开讲重点放在参数为什么这么配、哪些默认值会坑人、导完怎么验。刚接触 DM8 的运维同学可以照着抄命令已经用过一段时间但总在细节上翻车的可以重点看参数拆解和问题排查那两节。全文基于我在实际环境中的操作记录整理涉及的系统信息都做了脱敏处理。1. 先把“导出SQL文件”这件事掰开揉碎1.1 三种导出结果物用途完全不同DM8 里的“导出”至少产出三类东西混着叫会导致后面所有操作都拧巴。第一类是 dexp 产出的.dmp这是达梦私有的二进制格式只能通过 dimp 再导回 DM 库跨版本、跨平台都有约束好处是快、完整、能带索引约束触发器坏处是完全不可读拿文本编辑器打开就是一屏乱码。第二类是纯文本.sql脚本通常由 SQL 查询拼接生成或者由管理工具、数据迁移工具生成内容是CREATE TABLE、INSERT INTO这类可执行语句能直接扔给 disql 跑也能给别人看、做 Code Review。第三类是 CSV、TXT 这类分隔符文本靠 dmfldr 快速装载回库适合超大表的数据搬运但它不是 SQL没有表结构信息。很多人说的“导个 SQL 文件出来给我看看”实际想要的是第二类也就是能读、能改、能给别人执行的那种。如果你手里有个 dmp 却想转成 SQL 文本正经做法是用 dimp 先导进一个临时库再用管理工具或 disql 把数据抽成脚本而不是指望换个命令就能直接转换。这一点在需求沟通阶段就要问清楚不然做完了对方来一句“我要的是能打开看的”进度就白烧了。我一般会在动手前问三个问题这份文件最终给谁用、要不要带建表语句、数据量大概多少行。给开发做本地调试的通常要建表加数据几万行以内disql 拼脚本最省事给归档做冷备的dexp 一把梭更稳要往别的数据库搬的得走数据迁移工具做类型映射。三个问题问完工具基本就定了。1.2 场景对照什么情况下该选哪条路选型不是看哪个命令熟而是看约束条件。我把常见的几种场景整理成下面这张表判断的时候对着看就行能省掉大量试错。使用场景推荐方式关键理由需要留意的点整库/整模式冷备归档dexp 逻辑导出完整保留对象依赖速度快输出是二进制不能直接执行给开发一份能跑的初始化脚本DM 管理工具导出向导自动生成 DDL 加 INSERT格式规整大字段和特殊类型要单独验单表数据抽样、按条件导disql spool 拼接查询灵活控制 WHERE 条件与字段字符串转义、日期格式要处理上百张表批量出脚本参数文件 脚本调度可复用、可加日志、可定时失败重试与日志解析要设计跨库迁移到异构数据库数据迁移工具支持类型映射与字段裁剪索引、约束往往要人工补这张表里最容易踩的坑是最后一行。迁移工具生成的脚本看着漂亮但 DM 的某些类型映射过去会丢精度比如NUMBER不带精度会按最大精度处理CLOB到目标端可能被截成短文本TIMESTAMP的微秒部分经常被四舍五入掉。导完之后必须抽几张核心表做行数和关键字段的比对不能只看工具提示“迁移成功”。还有一类场景容易被忽略只需要表结构不要数据。这种情况用 dexp 加ROWSN参数能拿到纯 DDL 的 dmp再导进临时库用管理工具反导出成 SQL也可以直接用管理工具右键“生成 SQL”取建表语句。前者适合几十上百张表批量处理后者适合临时看一两张表按数量级选就行。2. dexp 逻辑导出最常用也最容易踩坑的一条路2.1 核心参数逐个拆解dexp 的参数不算多但每个都有默认行为不理解默认值就容易出意外。USERID是连接串格式为用户名/密码主机:端口密码里带、/、#这类字符时要特别注意建议用参数文件而不是命令行直接写避免被 shell 或 cmd 解析掉。FILE是导出文件名DIRECTORY是文件所在目录这两个是分开的FILE里不要带路径路径统一交给DIRECTORY。这个设计跟很多人的直觉相反我第一次用的时候在FILE里写了绝对路径命令直接报错。SCHEMAS指定模式可以写多个用逗号隔开TABLES指定表格式是模式名.表名多张表同样逗号分隔。这两个参数互斥同时写会以其中一个为准或者直接报错具体行为跟版本有关保险做法是只用其一。FULLY表示整库导出需要 DBA 权限日常用得少除非真要做全库归档。ROWS控制是否导数据默认Y。INDEXES、CONSTRAINTS、TRIGGERS分别控制索引、约束、触发器的导出默认都是Y。这里有个细节如果目标环境打算重建索引导出时关掉INDEXES能明显减少 dmp 体积和导入时间索引后建往往比随数据一起建更快。COMPRESS控制是否压缩网络传输或长期归档时开上能省不少空间代价是导出和导入时多消耗一点 CPU。PARALLEL是并行度整库或大模式导出时调成 4 或 8 有明显提速但并行度过高会把 IO 打满反而拖慢同机器上的其他业务。我的经验是在独立备机上开到 CPU 核数的一半在生产库上尽量不开或者压到 2。FEEDBACK控制进度打印的行数间隔默认值比较大导出大表时看起来像卡死调成 10000 或 50000 能让日志更有观感也方便判断是不是真的卡住了。LOG指定日志文件名一定要写出了问题全靠它定位。注意dexp 的 dmp 文件不能跨大版本随意导入。DM7 导出的 dmp 往 DM8 导或者反过来都可能失败。跨版本场景要加版本兼容参数或者干脆走 SQL 脚本中转别在这上面赌运气。2.2 一次完整的导出命令与执行记录拿一个订单模式举例需求是把ORDER模式完整导出来做归档。先确认目录存在并且运行用户有写权限用mkdir -p /home/dm/dump建好chown给达梦的运行用户。然后执行dexp USERIDSYSDBA/SYSDBA123127.0.0.1:5236 \ FILEorder_20250115.dmp \ DIRECTORY/home/dm/dump \ LOGorder_20250115.log \ SCHEMASORDER \ ROWSY \ INDEXESY \ CONSTRAINTSY \ COMPRESSY \ FEEDBACK10000Linux 下反斜杠换行是为了命令可读实际执行时整个写成一行也行。Windows 的 cmd 里换行符是^而且DIRECTORY的反斜杠要写成双反斜杠或者正斜杠这一点经常有人栽跟头——DIRECTORYD:\dump会被当成转义序列改成DIRECTORYD:/dump就没事了。执行过程中终端会滚动打印类似“导出表 ORDER.T_ORDER 完成共 125000 行”的信息日志文件里记录得更细包含每个对象的开始结束时间和总耗时。导完之后先看日志末尾有没有导出成功字样再核对文件大小最后做一次导入验证。验证不要在生产库上做找个测试实例用 dimp 导进去比对表数量、索引数量、关键表行数这三项基本能覆盖大部分问题。参数文件的方式更适合批量场景。把上面那堆参数写进order.exp里一行一个KEYVALUE然后执行dexp PARAMETERFILE/home/dm/dump/order.exp。好处是参数不会因为 shell 转义出错也方便版本管理和复用。参数文件里不要写注释行某些版本的解析器对#开头的行处理不一致容易出怪问题。2.3 只导结构、只导数据、按条件导ROWSN是只导结构的开关配合INDEXESN、CONSTRAINTSN能得到一份极简的 DDL 集合适合快速在测试环境搭空壳。反过来如果只想导数据不要结构ROWSY加INDEXESN、CONSTRAINTSN、TRIGGERSN能减少不少冗余但表结构还是会带一部分因为 dimp 导入时需要它来定位。真正“只要数据”的场景dexp 不是最优解用 dmfldr 导成文本更合适。按条件导出靠QUERY参数这个参数只能跟TABLES配合使用不能跟SCHEMAS一起。写法上Windows 用双引号包住整个查询Linux 用单引号查询里的表名要用实际表名不能带模式前缀dexp USERIDSYSDBA/SYSDBA123127.0.0.1:5236 \ FILEorder_2024.dmp \ DIRECTORY/home/dm/dump \ TABLESORDER.T_ORDER \ QUERYWHERE CREATE_TIME TO_DATE(2024-01-01,YYYY-MM-DD)这里有个限制QUERY对整个导出任务只生效一次如果TABLES里写了多张表这个条件会套用到所有表上字段名对不上的表直接报错。所以按条件导出一次只导一张表多表就多跑几次用脚本循环。我见过有人图省事把五张表塞进TABLES再配一个QUERY结果四张表报“列不存在”排查半天才发现是这个机制。FLASHBACK_SCN是一致性导出的关键参数。业务不停机的情况下导出不同表可能落在不同时间点导致外键关系对不上。DM8 支持闪回查询指定一个 SCN 就能让所有表都读那个时间点的数据。用法是先查当前 SCN导出时带上SELECT DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER FROM DUAL;拿到值之后再加FLASHBACK_SCN12345678。注意这个功能依赖闪回区配置和 UNDO 保留时间如果导出耗时超过 UNDO 保留窗口中途会报快照太旧。所以大库导出前先评估耗时必要时调大 UNDO 保留时间或者干脆安排在业务低峰做。3. disql spool手工产出可读SQL脚本3.1 连接与 spool 基础用法disql 是达梦的命令行客户端交互式用起来跟别的数据库客户端差不多但它的spool能把查询结果整段写到文件里这是生成 SQL 脚本最直接的手段。连接命令是disql 用户名/密码主机:端口如果密码里有特殊字符用引号包起来或者改用连接串文件。进入交互界面后先用spool打开输出文件中间执行查询最后spool off关闭。路径要给绝对路径相对路径在不同版本下解析基准不一样容易写到你没预期的目录里去。文件已存在时默认追加还是覆盖跟set参数有关保险做法是每次导出前先删掉旧文件或者用带时间戳的文件名。spool /home/dm/out/t_order.sql SELECT -- test FROM DUAL; spool off这段跑完t_order.sql里就会有一行-- test。看起来简单但真正要生成可执行的 INSERT还得把查询结果拼成完整语句这就涉及字符串拼接和转义是这一节的核心。有个容易忽略的点disql 的 spool 输出默认会带上执行过程中的提示信息比如“已选择 1 行”之类这些内容混进 SQL 文件后脚本执行时会报语法错误。所以必须在 spool 之前用set命令把这些噪音关掉这也是下一小节要讲的重点。3.2 set 命令决定脚本的“卖相”set系列命令看着琐碎但它直接决定导出的脚本能不能直接执行。下面这组是我常用的配置基本能覆盖大部分场景set echo off set heading off set feedback off set pagesize 0 set linesize 30000 set long 1000000 set trimspool on set timing off逐条说为什么。echo off关掉命令回显不然脚本里会混进你敲的每条 SQL。heading off关掉列标题INSERT 语句里出现一行字段名就是灾难。feedback off关掉“已选择 N 行”的提示。pagesize 0让结果不分页避免中间插入空行和重复表头。linesize决定单行最大宽度拼出来的 INSERT 很容易超过默认值被强制换行后语句就断了设到 30000 基本够用但要注意终端本身也有宽度限制太宽在屏幕上看会折行不影响文件内容。long控制大字段显示长度LOB 列不调大只会输出前一小段这是后面问题排查里要展开的坑。trimspool on去掉行尾多余空格能让文件体积小一截。timing off关掉耗时统计。这几个参数里linesize和long是最容易出问题的两个。前者不够大长 VARCHAR 拼出来的语句会被硬切断后者不够大CLOB 只导出一部分而且不报错等到目标端发现数据不全已经过去很久了。我的习惯是把long设成 1000000 起步遇到特别大的文本再往上调同时用LENGTH()函数抽查一下最长的那几行确认没被截断。3.3 大表分批导出与拼接 INSERT 的写法真正干活的是拼接查询。假设要导ORDER.T_ORDER表字段有ORDER_ID数字、CUST_NAME字符串、AMT数字、CREATE_TIME日期写法如下spool /home/dm/out/t_order.sql SELECT INSERT INTO ORDER.T_ORDER(ORDER_ID,CUST_NAME,AMT,CREATE_TIME) VALUES( || ORDER_ID || , || || REPLACE(CUST_NAME, , ) || , || TO_CHAR(AMT, FM9999999990.99) || , || TO_DATE( || TO_CHAR(CREATE_TIME, YYYY-MM-DD HH24:MI:SS) || ,YYYY-MM-DD HH24:MI:SS) || ); FROM ORDER.T_ORDER WHERE CREATE_TIME TO_DATE(2024-01-01,YYYY-MM-DD); spool off这里三处处理必须做对。字符串字段要用四个单引号包起来——外层两个是 SQL 的字符串定界里面两个是输出到文件里的单引号内容里的单引号用REPLACE翻倍否则碰到“OBrien”这种名字就会把语句截断。数字字段建议用TO_CHAR显式控制格式直接||拼接虽然也能转但小数位和科学计数法的表现跟会话参数有关显式格式化更稳。日期字段必须拼成TO_DATE(...)的形式因为目标库的日期格式参数未必跟你一样直接拼字符串在别人机器上大概率报错。NULL 值是个隐性坑。NULL || x的结果还是 NULL整个表达式变成 NULL那一行就直接从结果集里消失了——不报错但数据少了。处理办法是用NVL或者CASE WHEN把 NULL 显式转成字符串NULL|| CASE WHEN CUST_NAME IS NULL THEN NULL ELSE || REPLACE(CUST_NAME,,) || END || ,大表分批是为了避免单条查询撑爆临时表空间和客户端内存。按主键区间切是最稳的比如每 10 万行一批用WHERE ORDER_ID BETWEEN x AND y循环。也可以用ROWNUM限制但ROWNUM在没排序的情况下每次取到的行集不保证稳定容易重复或漏行只在确定不需要精确分批时用。分批之后每批单独 spool 成一个文件最后按顺序cat合并或者让脚本按序号执行出问题也好回滚。提示拼出来的脚本体积可能远大于原始数据。一条 INSERT 平均两百字节一千万行就是两个 G传输和执行的耗时都要提前估算。行数上到千万级别再走 SQL 脚本这条路换 dmfldr 或者 dexp 更现实。4. 图形化工具与批量调度方案4.1 DM管理工具的导出向导不想写 SQL 的话图形化的管理工具能直接导出脚本。操作路径大致是连上实例展开模式右键目标表或整个模式选“导出”在向导里把输出格式选成 SQL勾上“生成数据”然后指定输出文件和字符集。导出前它会让你预览一部分内容这个预览很有用能提前发现中文乱码或字段截断。字符集选项要特别注意。工具的界面语言、客户端编码、目标文件的编码是三件不同的事。导出文件建议统一用 UTF-8即便源库是 GB18030 编码转成 UTF-8 后交给别人执行兼容性更好。反过来如果目标环境明确要求 GB18030就得在导出时选对事后用文本编辑器另存为另一种编码很容易把中文转成问号且不可逆。导出范围的选择也有讲究。向导里一般提供“仅结构”“仅数据”“结构和数据”三个选项还有是否包含索引、约束、注释的勾选。给开发做初始化脚本时注释一定要带上不然几百张表过去没人看得懂字段含义做数据比对时索引和约束反而要关掉否则导入顺序不对会报外键冲突。批量处理时图形工具的短板就暴露了——一次只能导一个模式几十个模式要重复点几十次向导。这时候要么用工具自带的批量任务功能版本不同支持程度不一样要么老老实实回到脚本化方案。我的做法是先用图形工具导出一两个模式把生成的 SQL 打开看看格式确认没问题后再写脚本批量跑其余部分人工只做抽查。4.2 多表批量导出脚本化批量场景的核心是把“每张表的导出”抽象成一个可循环的单元。简单的做法是维护一个表清单文件每行一个模式名.表名然后 shell 循环调用 disql#!/bin/bash OUT_DIR/home/dm/out TABLE_LIST/home/dm/conf/tables.txt while read -r tbl; do schema${tbl%%.*} name${tbl##*.} file${OUT_DIR}/${schema}_${name}.sql disql SYSDBA/SYSDBA123127.0.0.1:5236 EOF set echo off set heading off set feedback off set pagesize 0 set linesize 30000 set long 1000000 set trimspool on spool ${file} SELECT -- export table ${tbl} FROM DUAL; spool off exit EOF done ${TABLE_LIST}实际使用时把中间那条SELECT换成上一节的拼接查询字段列表要么从数据字典动态生成要么按表写死。动态生成听起来更省事但字段类型映射的规则很麻烦数字、日期、字符串、LOB 要分别处理代码量比想象中大。表数量在几十张以内、结构相对稳定的话按表写死模板反而更快、更不容易出错。脚本化之后必须加两样东西日志和失败标记。每张表导出前后各打一行带时间戳的日志处理完检查输出文件是否存在且大小大于零不满足就记进失败清单最后汇总输出。别指望人盯着屏幕看几十张表滚过去根本看不清哪张失败。调度上常规做法是配到计划任务里避开业务高峰执行。注意 disql 的执行用户和文件权限脚本用哪个用户跑输出目录就得让那个用户有写权限否则会出现“命令成功但文件为空”的诡异现象——标准错误被重定向吞掉之后你只能看到一个空文件。5. 常见问题排查实录5.1 中文乱码与字符集乱码是这条路上出现频率最高的问题但成因分好几种得分开治。第一种是拿文本编辑器打开 dmp 文件这属于认知错误dmp 是二进制无论怎么调编码都读不出内容解决办法只有换成 dimp 导入或者改用导出 SQL 的方式。第二种是 spool 出来的 SQL 文件里中文变成问号这通常是客户端编码和数据库编码不一致或者终端本身的编码设置不对。查一下SELECT * FROM V$INSTANCE里的字符集信息再确认 disql 所在环境的编码设置两边对齐再重新导。第三种情况更隐蔽导出的文件在服务器上用cat看是正常的传到本地 Windows 打开就乱码。这是文件本身编码和目标打开工具的默认编码不一致。UTF-8 文件在中文 Windows 上用记事本打开某些老版本会按 GBK 解析中文就花了。解决办法是明确约定文件编码或者导出时直接用目标环境要求的编码别让人事后用编辑器转转错了不可逆。还有一种乱码发生在导入阶段。脚本本身没问题执行后数据里的中文变成了问号这往往是导入时会话的字符集设置和脚本文件编码不匹配。用 disql 执行脚本前先确认NLS相关的会话参数必要时在脚本开头显式设置。这个坑我踩过一次导出了几十个脚本导入后字段全是问号排查了两个小时才发现是执行环境的编码问题跟导出环节一点关系都没有。5.2 大字段截断与特殊类型CLOB 和长 VARCHAR 被截断是第二高频问题。disql 的set long控制显示长度默认值不大超过部分直接不显示而且没有任何提示。表现就是导出的脚本里文本字段突然变短或者明显缺了一截。处理办法是把long调到足够大再用LENGTH()抽查最长的那几行确认。但long也不是万能的。文本特别大时linesize也得同步调大否则拼出来的语句会被硬换行切断。两个参数要配套调只调一个等于没调。更极端的情况是单个 CLOB 超过几十兆这种数据用 SQL 脚本承载本身就不合适建议单独抽出来做附件或走二进制方式迁移。特殊类型还有几个要注意的。BLOB无法用字符串拼接的方式输出脚本里最多写个占位符实际数据得靠别的手段搬。TIMESTAMP带微秒精度TO_CHAR的格式串如果不带FF6微秒部分直接丢。NUMBER不带精度时拼接出来可能是科学计数法得用TO_CHAR加格式化串压住。BOOLEAN类型在 DM 里的表现和其他库不同拼接时要转成1/0或者TRUE/FALSE看目标端的接受方式。5.3 权限、路径与锁表权限问题的表现很直接命令执行了报“对象不存在”或者“权限不足”。dexp 导出需要对应对象的查询权限导出 DDL 部分还要更细的权限。用普通业务账号导整个模式基本会失败得用有权限的账号或者在导出前把需要的权限授上用完再回收。别图省事直接用最高权限账号跑脚本一旦泄露风险不小。路径问题集中在两点。DIRECTORY必须是已经存在的绝对路径dexp 不会自动创建目录写成不存在的路径会报错但报错信息有时候不够明确让人以为是参数格式问题。前面提过 Windows 的反斜杠转义也是一坑。另外运行用户对目录必须有写权限用 root 建了目录但没改属主用达梦用户跑导出就会失败这个问题在容器环境里尤其常见。锁表问题在业务高峰导出时容易出现。dexp 读取数据时会加锁遇到长事务或者行锁冲突就可能卡住日志里停在某张表不动。排查办法是查V$LOCK和V$SESSIONS看有没有阻塞会话。规避手段是安排在低峰执行或者用FLASHBACK_SCN做一致性读减少锁竞争。真卡住了别硬杀先看清楚是在等锁还是在做大量 IO误杀导出的进程可能留下不完整的 dmp 文件。5.4 问题速查表把上面这些整理成一张表出问题时对着找能省不少时间。现象大概率原因处理动作dmp 文件打开是乱码二进制格式被当文本打开改用 dimp 导入或换工具导出 SQLSQL 文件中文变问号客户端与库编码不一致对齐 disql 环境编码后重导脚本里文本字段明显变短set long太小调大long与linesize后重导拼接的语句被断成两行linesize不足调到 30000 以上数据行数比源表少NULL 参与拼接导致整行丢失用NVL或CASE处理空值字符串含单引号导致语法错误未做转义用REPLACE把单引号翻倍dexp 报目录错误路径不存在或用了相对路径建目录并给写权限改绝对路径导出中途卡住不动锁等待或长事务查锁视图改低峰或用闪回导出导入报外键冲突表顺序不对或约束未关先导数据后建约束或按依赖排序日期字段导入报格式错目标端会话格式不同脚本里统一用TO_DATE显式转换这张表里最值得记住的是“行数变少”和“文本变短”两条因为它们不报错。报错的问题反而好查静默丢数据才要命。每次导完做一次行数比对成本很低能挡掉大部分事故。6. 实战经验与参数调优的几个心得6.1 导出窗口与业务低峰导出对生产库的压力主要来自 IO 和锁跟导出方式关系不大。dexp 直连读数据大表扫一遍能把磁盘带宽吃满disql 拼脚本走的是同样的路径还多了一层字符串处理CPU 开销更高一些。所以时间窗口的选择比参数调优更重要业务低峰期跑怎么都好说。实在避不开高峰就把大表拆开跑一次导几张中间留间隔别让 IO 持续打满。PARALLEL参数在高峰时段一定要压到 1 或者 2开高了就是自己给自己找事。另外可以观察一下数据库的 IO 等待指标导出过程中如果等待明显上升说明已经影响到正常业务了该停就停。还有一个容易被忽略的点导出会占用连接数。批量脚本如果并发跑几十个连接同时连上去可能把连接池占满业务那边就报连接失败了。脚本里加个并发控制一次最多跑三五个比什么参数优化都管用。6.2 校验导出结果的三个动作导完不验等于没导。我固定做三个动作花不了几分钟但能挡住绝大多数问题。第一个是行数比对源表COUNT(*)和脚本里INSERT的条数对一下注意脚本里的注释行和空行要排除用grep -c ^INSERT统计就行。行数对不上先查 NULL 处理十有八九是那里漏了。第二个是抽样比对随机挑几行把源表的值和脚本里的值逐字段核对重点看中文、单引号、日期、小数这四类。中文看编码单引号看转义日期看格式小数看精度。这四类过了基本就没大问题。第三个是试执行把脚本导进一个测试库看能不能跑通、跑完数据对不对。这一步最费时间但最有效。我习惯在小表上先跑一遍全流程确认脚本格式没问题再对大数据量正式执行。注意试执行用的目标库要跟正式目标环境尽量一致版本、字符集、参数配置都对齐。在 UTF-8 环境测通了拿到 GBK 环境跑中文照样可能出问题。最后分享一个参数文件的小技巧。批量导出时给每个任务单独写一个参数文件文件名带上模式和日期日志也按同样的规则命名出问题时能直接定位到具体任务。参数文件放在版本管理里谁改了参数、什么时候改的都有记录比在命令行里临时拼参数靠谱得多。这套做法用久了会发现真正的效率提升不在命令本身而在于出问题时能快速回溯。