很多PL/SQL Developer用户都会卡在“导出表”这一步。明明菜单里有个Export Tables可真点进去又不知道该勾哪些选项导出来的SQL文件拿去别的库一执行就报错或者数据缺了一半。这问题特别常见尤其在Oracle DBA和开发人员之间来回切换的时候几乎每个月都会有人在群里问一次。今天这篇就基于“PL/SQL Developer工具如何导出表”这个最常见的需求把整个导出流程拆开讲透。我会从工具的导出机制讲起把Export Tables窗口里的每一个选项背后的作用说清楚再给出一套标准操作步骤最后附上我踩过的坑和排查思路。无论你是刚接触Oracle的测试开发还是临时要帮业务导出数据的老手这篇文章都能直接照着抄。1. 别搞混了PL/SQL Developer里“导出表”的四种操作场景很多人一上来就在找“导出表”按钮但其实PL/SQL Developer里面至少有四种跟“导出”相关的操作它们走的是完全不同的菜单路径产出的文件格式也完全不同。第一件事就是确认用户到底想要哪种结果。最核心的一种是把整张表的结构和数据打包生成一份SQL脚本用于在另一个数据库里重建这张表。这个操作对应Tools菜单下的Export Tables也就是本文主角。它可以把表结构(DDL)和表数据(DML)一起导出成一个.sql文件也可以同时导出触发器、存储过程、序列、授权、外键等附属对象。这是最接近“导出表”这个词本意的功能。第二种是从查询结果里导出数据比如SELECT * FROM 某表之后把结果集右键另存为Excel或CSV。这个场景一般是给业务同事或者做数据分析用它不关心表怎么建只关心数据长什么样。对应操作是Query Result窗口右键选择Export Results。第三种是只导出表结构不考虑数据。这种需求在做环境迁移、比对表结构的时候特别常见。仍然是用Export Tables但把Data部分的选项全部去掉只保留Create tables生成的就是纯DDL脚本。第四种是PL/SQL Developer自己的专用格式后缀是.pde。它只能被PL/SQL Developer识别跨工具用不了但好处是回导速度快适合自己电脑上的临时备份。这四种操作我整理成一张表方便你在动手之前先对号入座操作路径产物格式典型使用场景能否跨数据库平台Tools - Export Tables.sql / .pde表结构数据迁移、环境重建SQL可跨PDE不可Query Result右键 - Export Results.csv / .xlsx / .html给数据分析、业务盘点数据是Tools - Export User Objects.sql导出整个对象集常用于版本管理是Tools - Export Tables仅DDL.sql结构同步、建表语句备份是我见过最多的场景是同事说要“把这两张表导出来给我”实际需求是把表结构、数据、触发器全带过去让他在另一台测试库里原地重建。这种需求用第一种就能解决。但如果对方说“给我一份Excel”那就是第二种。所以在进入操作细节之前先花十秒钟确认清楚需求这是帮自己少走弯路最重要的一步。2. Export Tables界面逐项拆解每个选项都在干什么选Tools - Export Tables打开窗口之后第一眼看上去好像只是勾勾选选但真正影响导出结果的就是这满屏选项。我按区域逐个说。2.1 表和对象类型的选择逻辑左上角的Tables区域是本次导出要处理的表清单。它默认列出来的是当前登录用户下的所有表也可以切换Users下拉框选择别的用户或者在输入框里直接按前缀过滤。真正容易忽略的是旁边的Table、View、Synonym、Sequence等对象类型勾选项。如果只勾了Table那视图、同义词、序列这些相关对象就算表里面引用了也不会一起导出。比如某张表上有一个自增字段依赖Sequence只导Table会导致新的环境里Sequence缺失插入数据时只能手写ID。我自己一般会默认把Table、Sequence、Trigger勾上View和Synonym根据实际需求决定。Objects区域还有一个Name / Objects / Include Dependencies的分组逻辑。Include Dependencies的作用是自动寻找这张表依赖的其他对象比如外键关联的父表、同义词指向的底层对象把它们一并纳入导出范围。这个选项非常有用尤其是在导出多表的时候能避免“子表导出来了父表没导回放时外键报错”的尴尬。2.2 Output file与文件类型选择窗口中间偏右是Output file区域。这里有三个关键选项文件路径、文件格式、以及Single file还是Per table multiple files。文件格式就是前文提到的SQL和PDE两种。选SQL就是标准脚本任何工具都能读选PDE就是工具私有格式。如果你不确定选SQL永远没错。Single file会把你勾选的所有表都输出到一个.sql文件里顺序按照列表排列适合小批量导出。Per table multiple files则会在你指定的目录里为每一张表生成一个单独的SQL文件文件名就是表名。我强烈建议表数量超过十张时改用多个文件因为单个大文件一旦中途出错整个回放都会变得很麻烦而分文件可以逐张独立处理。另外那个Overwrite existing files选项默认是勾上的。如果不勾当目标路径已经存在同名文件时工具会逐个弹窗确认非常烦人。所以导出前自己心里要有数别让工具把上次的文件覆盖掉了。2.3 DDL区域结构导出的精细控制Default values、Storage、Privileges、Synonyms、Procedures、Triggers、Referential integrity……这一排勾选项几乎决定了你导出的建表语句到底完整到什么程度。这些选项字面上看得很清楚但有几个是必须联动考虑的Include Storage控制是否导出表的存储参数比如INITIAL、NEXT、PCTFREE这些。存储参数在测试环境往往没有意义新库的存储路径都不一样。我通常不勾除非是要做生产环境的空间评估。Include Privileges负责导出表上的授权语句(GRANT)。如果不勾在新环境里这张表就只有建表用户自己能访问。这个问题经常在导完之后才发现业务账号一连接就报ORA-00942。Include Synonyms是把表相关的公共同义词、私有同义词一起创建出来。如果应用是拿着同义词去访问表的没这个选项应用就得改代码。Include Referential Integrity是外键约束。导出大表时外键是数据装载的大障碍。新手最常见的坑就是有外键的表在导入时报ORA-02291。所以大多数做数据迁移的人会刻意不勾这一项数据导入完成后再手动重建外键。从使用习惯来讲日常导出“给别人用”最少要勾上Privileges、Triggers和Referential integrity这三项。Storage和Synonyms这两个根据环境不同再权衡没有绝对标准。2.4 Data区域数据导出的三个思路Data区域是整个窗口里对导出结果影响最大的地方。有几个选项需要专门展开讲第一个是Limit rows下拉框。它默认显示Not limited也就是全量导出。有时候排查线上数据问题只需要看表里某一个SQL查出来的50行那就在WHERE clause里写条件或者在下拉框里选50。这个功能很像查询结果导出但走的是Export Tables路径。第二个是Export as INSERT statements。这是最主流的数据导出方式。它把每一条记录都生成一条INSERT INTO 表名(...) VALUES(...)的SQL语句。优点是通用性好在目标库回放时不需要额外的工具缺点是数据量大时脚本体积大逐行插入速度慢。为了避免回放在中间失败向导最后会让你选择在每行后加COMMIT还是在最后统一COMMIT。第三组是Use SQLLoader / Use External table。这两个选项是把表数据单独导出成CSV数据文件同时生成一个控制文件(.ctl)然后用Oracle的SQLLoader工具或者外部表方式装载数据。这个思路通常都是为了大数据量导入因为INSERT语句的行式插入在百万级数据面前是灾难性的。我在这篇文章后面会专门给出选择建议。还有两个需要提名的选项Create tables when data doesnt exist和Append data to existing tables。前者用于目标库还没有这张表时自动先建表再插入数据后者用于目标库里已经有表、只想追加数据。这两个默认都会勾上一般不用动但你要理解它们的存在意义——它们决定了你的数据脚本在目标库回放时的行为。3. 实操全流程从选定目标表到生成一份能直接在目标库回放的SQL脚本这一部分直接把完整流程走一遍每一步都给出我自己的操作习惯。不需要太华丽照着做就能拿到一份正经的导出脚本。3.1 单表导出的完整步骤假设现在要把某张订单表连同数据和触发器导出目标是之后在原样建到另一套测试库里。操作如下打开PL/SQL Developer用它登录目标数据库确保当前用户有那张订单表的SELECT权限。点击Tools菜单选择Export Tables。在Tables列表里找到那张表并勾选左侧Objects类型默认勾选Table就行我一般也顺手勾上Sequence、Trigger。在Output file区域的Output file输入框里填导出路径比如D:\export\order_tab.sql格式选SQL文件。不勾Include Storage勾上Include Privileges、Include Synonyms、Include Procedures、Include Triggers、Include Referential integrity。在Data区域把Limit rows设为Not limited选择Export as INSERT statements同时选择在文件末尾统一添加COMMIT。点击Export按钮等导出日志窗口显示完成。这个过程实际上是几分钟之内就能完成的事情。导出的结果文件里前半部分是CREATE TABLE、CREATE OR REPLACE TRIGGER之类的DDL脚本后半部分是一大串INSERT语句。如果你设置的是每一行后COMMIT那每个INSERT后面都会跟一个COMMIT脚本会大很多但回放更安全。3.2 多表导出与依赖顺序的控制单表导出比较简单一旦变成多表就需要考虑表和表之间的依赖关系。比如父表、子表之间的外键视图依赖的表触发器依赖的函数和包。如果不处理顺序导入时外键会先建子表结果找不到对应的父表直接报ORA-00942。我一般用三种方式控制依赖顺序在表列表中手动调整顺序把父表放在子表前面。这个方式适合几张表的情况简单直接。勾选Include Dependencies让PL/SQL Developer自动把被依赖的对象也放进来。这个选项会自动排序把父表排到子表之前。导出时不勾Include Referential integrity也就是放弃外键。这是做数据迁移的人最常用的方式先导数据最后统一补外键约束。实际操作中我很少单靠其中一个。通常是先勾上Include Dependencies自动把依赖相关的表带出来然后把外键约束导出的选项留着但回放时留意顺序。真出现ORA-02291或ORA-00942就单独处理那几张表不用整包重来。3.3 在目标环境回放脚本的规范姿势拿到了.sql文件到目标库执行这里有个经常被忽视的问题应该在哪里执行这些脚本很多人直接在PL/SQL Developer的SQL Window里把整个文件拖进去然后按F8执行。这个做法对几十条INSERT的小文件没问题一旦文件达到几万条或者包含大量DDLSQL Window的执行机制会出现中断、卡死、无法定位哪一行报错的情况。我的习惯是使用Command Window执行方式如下SET ECHO ON SET FEEDBACK ON WHENEVER SQLERROR EXIT FAILURE D:\export\order_tab.sql符号可以直接在命令窗口里执行脚本文件命令窗口会逐行输出执行情况哪一行报错一目了然。加上WHENEVER SQLERROR EXIT FAILURE碰到第一条错误就停止执行避免后续脚本在错误环境里继续跑出一堆无效操作。如果目标库的表结构跟脚本里的DDL有冲突也不要直接删表。先把脚本里的表名都改成临时表名试跑确认结构正确后再正式执行。这个步骤看起来多此一举但能让你避开“执行到一半发现列类型对不上把一整张正式表毁掉”这种灾难。4. 导出文件的格式差异、字符集乱码与写入失败排查这个章节里要讲的几个问题都属于那种“平时不出事出事都是大事”的类型。尤其是乱码和写入失败几乎每个人都遇到过。4.1 SQL和PDE格式怎么选前面已经简单提过这里放一个更细的对比对比项SQLPDE通用性可在SQL*Plus、SQL Developer等任意Oracle工具执行只能在PL/SQL Developer使用可读性明文可用文本编辑器查看修改二进制结构无法直接阅读执行速度依赖SQL引擎逐行解析工具内部批量装载速度快很多适用场景交付给他人、跨工具迁移本机临时备份、快速回导一句话如果你只是想保存一份结构或者要发给同事选SQL。如果只是自己电脑上整库备份图快选PDE。不要觉得PDE速度快就到处推荐换个工具它就废了。4.2 字符集问题打开文件全是乱码的真相PL/SQL Developer在导出SQL文件时会在Output file区域下方或者导出配置里提供文件编码选项。常见的选项有ANSI、UTF-8等。乱码的本质是导出端Oracle会话的字符集和保存文件时选择的文件编码不一致或者目标库环境与源库环境字符集差异太大。如果是中文字段比较多、数据量也比较大的表保存文件时直接选择UTF-8是唯一的稳妥选择。ANSI在老Windows环境下有兼容性优势但如今绝大多数工具已经支持UTF-8没必要再为那点体积走回头路。这里要特别提醒一点如果PL/SQL Developer的界面本身显示正常导出的SQL文件用Notepad打开是好的但拿到另一台机器上打开变成乱码多半是另一台机器的文本编辑器默认读取的是系统本地编码跟文件实际保存编码对不上。此时手动把编辑器编码切到对应编码或者统一在导出时选择带BOM的UTF-8格式基本能解决。还有一类乱码是执行结果乱码而不是文件乱码。目标库执行INSERT语句后查询出来的中文字段是问号这通常不是导出文件的问题而是目标库的客户端字符集NLS_LANG设置不正确。这个要单独用SELECT * FROM V$NLS_PARAMETERS排查跟导出步骤关系不大。4.3 Error writing file报错的常见原因PL/SQL Developer导出过程中偶尔会出现Error writing file的红色报错信息。这个问题绝大多数情况下是权限问题或者路径问题。目标路径不存在或没有写权限。比如导出到C盘Program Files目录下普通账户根本没有写权限。文件名里含有特殊字符比如中英文混合、空格。PL/SQL Developer对特殊路径的处理有时候会出现兼容性问题。导出文件正在被另一个进程占用。比如你已经在文本编辑器里打开着同一个路径的SQL文件导出时工具就无法覆写。我自己的习惯是导出路径一律放在类似D:\export\这样的独立目录文件名只用字母、数字和下划线。路径越简单出问题的概率越低。5. 生产级经验让导出结果更可靠的一些习惯最后这几个经验是我在多次“导完发现少东西”之后总结出来的。前面讲的是操作怎么做这一部分讲的是怎么保证结果是对的。5.1 导出前先做三个前置检查第一个检查数据量。在全量导出之前先用SELECT COUNT(*) FROM 表名看一眼数据量级。百万行级别的表用INSERT语句方式导出会生成几百MB甚至几个GB的SQL文件回放基本会把目标库搞到严重卡顿。这时候就应该考虑换成SQL*Loader或者外部表方案。第二个检查权限。查看当前用户是否有这张表的SELECT权限以及是否还有其他用户的同义词指向同一张表。如果是为了迁移而导出但当前用户连SELECT权限都不完整导出来的数据本身就是缺的排查起来极其费劲。第三个检查表数量。如果目标是“整个用户下的所有表”打开Export Tables后直接CtrlA全选很容易把一些系统生成的临时表、废弃历史表全都带出来。导出去几百张表回放时建了一堆没用的东西。我会先按最后DDL时间排序只选那些业务上真正需要的表。5.2 如何验证导出文件完整性导出结束之后不要直接关窗口先做两件事第一启动系统的文件管理器查看文件大小。如果表数量很多但文件大小只有几KB肯定有问题。第二看导出日志窗口的统计信息。正常导出的日志会一行一行告诉你Table 某表 exported如果你勾选了12张表日志里就应该出现12次类似提示。缺一张就是一个潜在事故。第三抽查文件内容。用文本编辑器打开SQL文件检索最后一个INSERT INTO表名的位置确认它排在文件末尾而不是中间。如果脚本在中间位置就结束了后半段可能被截断。我还有一个更严谨的验证方式导出前统计每张表的行数总和导出后用脚本统计文件里INSERT INTO语句的行数两个数字对得上才敢把文件交付出去。5.3 什么时候别用PL/SQL Developer导出改用其他工具PL/SQL Developer的导出功能很顺手但它不是万能的。有两个场景我强烈建议换工具。第一个是超大数据量的全表迁移。比如统计库里一张十几亿行的日志表导出成INSERT脚本是完全不现实的。这种情况应该使用Oracle自带的expdp、data pump或者直接用SQLcl生成SQL*Loader方案。数据泵走的是二进制导出速度和压缩比都远胜文本脚本。第二个是整库级别的结构迁移。几十个用户、几百张表、各种包体、物化视图这种需求应该用expdp的FULLY或者用专门的Schema Compare工具。PL/SQL Developer的Export Tables更适合处理“几十张熟知的表”这种中量级任务。我在实际项目里的分工是明细级的、业务相关的表用PL/SQL Developer导出然后人工审阅SQL脚本批量的、海量的、整个用户级别的东西交给expdp。工具没有高低之分用对场景才是关键。另外还有一个容易被忽略的点导出的SQL脚本在目标库执行之后一定要快速跑一遍数据抽样比对比如找出主键相同但某几个关键字段不一致的记录。实测中在字符集不一致、默认值设置不同、触发器重复执行的情况下导入后的数据可能表面上是完整的但细节已经变了。只有抽样比对过才算真正完成了一次导出到导入的闭环。最后分享一个小习惯。导完表之后我总会顺手在那个SQL文件的最顶部加一行注释写明源库连接信息、导出时间、当前表的行数以及导出人。别小看这一行过了三个月再有人拿着这个文件问你“这是哪来的数据”这行注释能省掉一次全库排查的功夫。操作久了你会发现导出表的技术难度并不高真正会坑人的永远是那些没有记录的习惯和临门一脚的细节。 
长河君 · 2026/10/18 21:47:12 · 阅读 1.2k PL/SQL Developer导出表全攻略：从选项拆解到踩坑排查
很多PL/SQL Developer用户都会卡在“导出表”这一步。明明菜单里有个Export Tables可真点进去又不知道该勾哪些选项导出来的SQL文件拿去别的库一执行就报错或者数据缺了一半。这问题特别常见尤其在Oracle DBA和开发人员之间来回切换的时候几乎每个月都会有人在群里问一次。今天这篇就基于“PL/SQL Developer工具如何导出表”这个最常见的需求把整个导出流程拆开讲透。我会从工具的导出机制讲起把Export Tables窗口里的每一个选项背后的作用说清楚再给出一套标准操作步骤最后附上我踩过的坑和排查思路。无论你是刚接触Oracle的测试开发还是临时要帮业务导出数据的老手这篇文章都能直接照着抄。1. 别搞混了PL/SQL Developer里“导出表”的四种操作场景很多人一上来就在找“导出表”按钮但其实PL/SQL Developer里面至少有四种跟“导出”相关的操作它们走的是完全不同的菜单路径产出的文件格式也完全不同。第一件事就是确认用户到底想要哪种结果。最核心的一种是把整张表的结构和数据打包生成一份SQL脚本用于在另一个数据库里重建这张表。这个操作对应Tools菜单下的Export Tables也就是本文主角。它可以把表结构(DDL)和表数据(DML)一起导出成一个.sql文件也可以同时导出触发器、存储过程、序列、授权、外键等附属对象。这是最接近“导出表”这个词本意的功能。第二种是从查询结果里导出数据比如SELECT * FROM 某表之后把结果集右键另存为Excel或CSV。这个场景一般是给业务同事或者做数据分析用它不关心表怎么建只关心数据长什么样。对应操作是Query Result窗口右键选择Export Results。第三种是只导出表结构不考虑数据。这种需求在做环境迁移、比对表结构的时候特别常见。仍然是用Export Tables但把Data部分的选项全部去掉只保留Create tables生成的就是纯DDL脚本。第四种是PL/SQL Developer自己的专用格式后缀是.pde。它只能被PL/SQL Developer识别跨工具用不了但好处是回导速度快适合自己电脑上的临时备份。这四种操作我整理成一张表方便你在动手之前先对号入座操作路径产物格式典型使用场景能否跨数据库平台Tools - Export Tables.sql / .pde表结构数据迁移、环境重建SQL可跨PDE不可Query Result右键 - Export Results.csv / .xlsx / .html给数据分析、业务盘点数据是Tools - Export User Objects.sql导出整个对象集常用于版本管理是Tools - Export Tables仅DDL.sql结构同步、建表语句备份是我见过最多的场景是同事说要“把这两张表导出来给我”实际需求是把表结构、数据、触发器全带过去让他在另一台测试库里原地重建。这种需求用第一种就能解决。但如果对方说“给我一份Excel”那就是第二种。所以在进入操作细节之前先花十秒钟确认清楚需求这是帮自己少走弯路最重要的一步。2. Export Tables界面逐项拆解每个选项都在干什么选Tools - Export Tables打开窗口之后第一眼看上去好像只是勾勾选选但真正影响导出结果的就是这满屏选项。我按区域逐个说。2.1 表和对象类型的选择逻辑左上角的Tables区域是本次导出要处理的表清单。它默认列出来的是当前登录用户下的所有表也可以切换Users下拉框选择别的用户或者在输入框里直接按前缀过滤。真正容易忽略的是旁边的Table、View、Synonym、Sequence等对象类型勾选项。如果只勾了Table那视图、同义词、序列这些相关对象就算表里面引用了也不会一起导出。比如某张表上有一个自增字段依赖Sequence只导Table会导致新的环境里Sequence缺失插入数据时只能手写ID。我自己一般会默认把Table、Sequence、Trigger勾上View和Synonym根据实际需求决定。Objects区域还有一个Name / Objects / Include Dependencies的分组逻辑。Include Dependencies的作用是自动寻找这张表依赖的其他对象比如外键关联的父表、同义词指向的底层对象把它们一并纳入导出范围。这个选项非常有用尤其是在导出多表的时候能避免“子表导出来了父表没导回放时外键报错”的尴尬。2.2 Output file与文件类型选择窗口中间偏右是Output file区域。这里有三个关键选项文件路径、文件格式、以及Single file还是Per table multiple files。文件格式就是前文提到的SQL和PDE两种。选SQL就是标准脚本任何工具都能读选PDE就是工具私有格式。如果你不确定选SQL永远没错。Single file会把你勾选的所有表都输出到一个.sql文件里顺序按照列表排列适合小批量导出。Per table multiple files则会在你指定的目录里为每一张表生成一个单独的SQL文件文件名就是表名。我强烈建议表数量超过十张时改用多个文件因为单个大文件一旦中途出错整个回放都会变得很麻烦而分文件可以逐张独立处理。另外那个Overwrite existing files选项默认是勾上的。如果不勾当目标路径已经存在同名文件时工具会逐个弹窗确认非常烦人。所以导出前自己心里要有数别让工具把上次的文件覆盖掉了。2.3 DDL区域结构导出的精细控制Default values、Storage、Privileges、Synonyms、Procedures、Triggers、Referential integrity……这一排勾选项几乎决定了你导出的建表语句到底完整到什么程度。这些选项字面上看得很清楚但有几个是必须联动考虑的Include Storage控制是否导出表的存储参数比如INITIAL、NEXT、PCTFREE这些。存储参数在测试环境往往没有意义新库的存储路径都不一样。我通常不勾除非是要做生产环境的空间评估。Include Privileges负责导出表上的授权语句(GRANT)。如果不勾在新环境里这张表就只有建表用户自己能访问。这个问题经常在导完之后才发现业务账号一连接就报ORA-00942。Include Synonyms是把表相关的公共同义词、私有同义词一起创建出来。如果应用是拿着同义词去访问表的没这个选项应用就得改代码。Include Referential Integrity是外键约束。导出大表时外键是数据装载的大障碍。新手最常见的坑就是有外键的表在导入时报ORA-02291。所以大多数做数据迁移的人会刻意不勾这一项数据导入完成后再手动重建外键。从使用习惯来讲日常导出“给别人用”最少要勾上Privileges、Triggers和Referential integrity这三项。Storage和Synonyms这两个根据环境不同再权衡没有绝对标准。2.4 Data区域数据导出的三个思路Data区域是整个窗口里对导出结果影响最大的地方。有几个选项需要专门展开讲第一个是Limit rows下拉框。它默认显示Not limited也就是全量导出。有时候排查线上数据问题只需要看表里某一个SQL查出来的50行那就在WHERE clause里写条件或者在下拉框里选50。这个功能很像查询结果导出但走的是Export Tables路径。第二个是Export as INSERT statements。这是最主流的数据导出方式。它把每一条记录都生成一条INSERT INTO 表名(...) VALUES(...)的SQL语句。优点是通用性好在目标库回放时不需要额外的工具缺点是数据量大时脚本体积大逐行插入速度慢。为了避免回放在中间失败向导最后会让你选择在每行后加COMMIT还是在最后统一COMMIT。第三组是Use SQLLoader / Use External table。这两个选项是把表数据单独导出成CSV数据文件同时生成一个控制文件(.ctl)然后用Oracle的SQLLoader工具或者外部表方式装载数据。这个思路通常都是为了大数据量导入因为INSERT语句的行式插入在百万级数据面前是灾难性的。我在这篇文章后面会专门给出选择建议。还有两个需要提名的选项Create tables when data doesnt exist和Append data to existing tables。前者用于目标库还没有这张表时自动先建表再插入数据后者用于目标库里已经有表、只想追加数据。这两个默认都会勾上一般不用动但你要理解它们的存在意义——它们决定了你的数据脚本在目标库回放时的行为。3. 实操全流程从选定目标表到生成一份能直接在目标库回放的SQL脚本这一部分直接把完整流程走一遍每一步都给出我自己的操作习惯。不需要太华丽照着做就能拿到一份正经的导出脚本。3.1 单表导出的完整步骤假设现在要把某张订单表连同数据和触发器导出目标是之后在原样建到另一套测试库里。操作如下打开PL/SQL Developer用它登录目标数据库确保当前用户有那张订单表的SELECT权限。点击Tools菜单选择Export Tables。在Tables列表里找到那张表并勾选左侧Objects类型默认勾选Table就行我一般也顺手勾上Sequence、Trigger。在Output file区域的Output file输入框里填导出路径比如D:\export\order_tab.sql格式选SQL文件。不勾Include Storage勾上Include Privileges、Include Synonyms、Include Procedures、Include Triggers、Include Referential integrity。在Data区域把Limit rows设为Not limited选择Export as INSERT statements同时选择在文件末尾统一添加COMMIT。点击Export按钮等导出日志窗口显示完成。这个过程实际上是几分钟之内就能完成的事情。导出的结果文件里前半部分是CREATE TABLE、CREATE OR REPLACE TRIGGER之类的DDL脚本后半部分是一大串INSERT语句。如果你设置的是每一行后COMMIT那每个INSERT后面都会跟一个COMMIT脚本会大很多但回放更安全。3.2 多表导出与依赖顺序的控制单表导出比较简单一旦变成多表就需要考虑表和表之间的依赖关系。比如父表、子表之间的外键视图依赖的表触发器依赖的函数和包。如果不处理顺序导入时外键会先建子表结果找不到对应的父表直接报ORA-00942。我一般用三种方式控制依赖顺序在表列表中手动调整顺序把父表放在子表前面。这个方式适合几张表的情况简单直接。勾选Include Dependencies让PL/SQL Developer自动把被依赖的对象也放进来。这个选项会自动排序把父表排到子表之前。导出时不勾Include Referential integrity也就是放弃外键。这是做数据迁移的人最常用的方式先导数据最后统一补外键约束。实际操作中我很少单靠其中一个。通常是先勾上Include Dependencies自动把依赖相关的表带出来然后把外键约束导出的选项留着但回放时留意顺序。真出现ORA-02291或ORA-00942就单独处理那几张表不用整包重来。3.3 在目标环境回放脚本的规范姿势拿到了.sql文件到目标库执行这里有个经常被忽视的问题应该在哪里执行这些脚本很多人直接在PL/SQL Developer的SQL Window里把整个文件拖进去然后按F8执行。这个做法对几十条INSERT的小文件没问题一旦文件达到几万条或者包含大量DDLSQL Window的执行机制会出现中断、卡死、无法定位哪一行报错的情况。我的习惯是使用Command Window执行方式如下SET ECHO ON SET FEEDBACK ON WHENEVER SQLERROR EXIT FAILURE D:\export\order_tab.sql符号可以直接在命令窗口里执行脚本文件命令窗口会逐行输出执行情况哪一行报错一目了然。加上WHENEVER SQLERROR EXIT FAILURE碰到第一条错误就停止执行避免后续脚本在错误环境里继续跑出一堆无效操作。如果目标库的表结构跟脚本里的DDL有冲突也不要直接删表。先把脚本里的表名都改成临时表名试跑确认结构正确后再正式执行。这个步骤看起来多此一举但能让你避开“执行到一半发现列类型对不上把一整张正式表毁掉”这种灾难。4. 导出文件的格式差异、字符集乱码与写入失败排查这个章节里要讲的几个问题都属于那种“平时不出事出事都是大事”的类型。尤其是乱码和写入失败几乎每个人都遇到过。4.1 SQL和PDE格式怎么选前面已经简单提过这里放一个更细的对比对比项SQLPDE通用性可在SQL*Plus、SQL Developer等任意Oracle工具执行只能在PL/SQL Developer使用可读性明文可用文本编辑器查看修改二进制结构无法直接阅读执行速度依赖SQL引擎逐行解析工具内部批量装载速度快很多适用场景交付给他人、跨工具迁移本机临时备份、快速回导一句话如果你只是想保存一份结构或者要发给同事选SQL。如果只是自己电脑上整库备份图快选PDE。不要觉得PDE速度快就到处推荐换个工具它就废了。4.2 字符集问题打开文件全是乱码的真相PL/SQL Developer在导出SQL文件时会在Output file区域下方或者导出配置里提供文件编码选项。常见的选项有ANSI、UTF-8等。乱码的本质是导出端Oracle会话的字符集和保存文件时选择的文件编码不一致或者目标库环境与源库环境字符集差异太大。如果是中文字段比较多、数据量也比较大的表保存文件时直接选择UTF-8是唯一的稳妥选择。ANSI在老Windows环境下有兼容性优势但如今绝大多数工具已经支持UTF-8没必要再为那点体积走回头路。这里要特别提醒一点如果PL/SQL Developer的界面本身显示正常导出的SQL文件用Notepad打开是好的但拿到另一台机器上打开变成乱码多半是另一台机器的文本编辑器默认读取的是系统本地编码跟文件实际保存编码对不上。此时手动把编辑器编码切到对应编码或者统一在导出时选择带BOM的UTF-8格式基本能解决。还有一类乱码是执行结果乱码而不是文件乱码。目标库执行INSERT语句后查询出来的中文字段是问号这通常不是导出文件的问题而是目标库的客户端字符集NLS_LANG设置不正确。这个要单独用SELECT * FROM V$NLS_PARAMETERS排查跟导出步骤关系不大。4.3 Error writing file报错的常见原因PL/SQL Developer导出过程中偶尔会出现Error writing file的红色报错信息。这个问题绝大多数情况下是权限问题或者路径问题。目标路径不存在或没有写权限。比如导出到C盘Program Files目录下普通账户根本没有写权限。文件名里含有特殊字符比如中英文混合、空格。PL/SQL Developer对特殊路径的处理有时候会出现兼容性问题。导出文件正在被另一个进程占用。比如你已经在文本编辑器里打开着同一个路径的SQL文件导出时工具就无法覆写。我自己的习惯是导出路径一律放在类似D:\export\这样的独立目录文件名只用字母、数字和下划线。路径越简单出问题的概率越低。5. 生产级经验让导出结果更可靠的一些习惯最后这几个经验是我在多次“导完发现少东西”之后总结出来的。前面讲的是操作怎么做这一部分讲的是怎么保证结果是对的。5.1 导出前先做三个前置检查第一个检查数据量。在全量导出之前先用SELECT COUNT(*) FROM 表名看一眼数据量级。百万行级别的表用INSERT语句方式导出会生成几百MB甚至几个GB的SQL文件回放基本会把目标库搞到严重卡顿。这时候就应该考虑换成SQL*Loader或者外部表方案。第二个检查权限。查看当前用户是否有这张表的SELECT权限以及是否还有其他用户的同义词指向同一张表。如果是为了迁移而导出但当前用户连SELECT权限都不完整导出来的数据本身就是缺的排查起来极其费劲。第三个检查表数量。如果目标是“整个用户下的所有表”打开Export Tables后直接CtrlA全选很容易把一些系统生成的临时表、废弃历史表全都带出来。导出去几百张表回放时建了一堆没用的东西。我会先按最后DDL时间排序只选那些业务上真正需要的表。5.2 如何验证导出文件完整性导出结束之后不要直接关窗口先做两件事第一启动系统的文件管理器查看文件大小。如果表数量很多但文件大小只有几KB肯定有问题。第二看导出日志窗口的统计信息。正常导出的日志会一行一行告诉你Table 某表 exported如果你勾选了12张表日志里就应该出现12次类似提示。缺一张就是一个潜在事故。第三抽查文件内容。用文本编辑器打开SQL文件检索最后一个INSERT INTO表名的位置确认它排在文件末尾而不是中间。如果脚本在中间位置就结束了后半段可能被截断。我还有一个更严谨的验证方式导出前统计每张表的行数总和导出后用脚本统计文件里INSERT INTO语句的行数两个数字对得上才敢把文件交付出去。5.3 什么时候别用PL/SQL Developer导出改用其他工具PL/SQL Developer的导出功能很顺手但它不是万能的。有两个场景我强烈建议换工具。第一个是超大数据量的全表迁移。比如统计库里一张十几亿行的日志表导出成INSERT脚本是完全不现实的。这种情况应该使用Oracle自带的expdp、data pump或者直接用SQLcl生成SQL*Loader方案。数据泵走的是二进制导出速度和压缩比都远胜文本脚本。第二个是整库级别的结构迁移。几十个用户、几百张表、各种包体、物化视图这种需求应该用expdp的FULLY或者用专门的Schema Compare工具。PL/SQL Developer的Export Tables更适合处理“几十张熟知的表”这种中量级任务。我在实际项目里的分工是明细级的、业务相关的表用PL/SQL Developer导出然后人工审阅SQL脚本批量的、海量的、整个用户级别的东西交给expdp。工具没有高低之分用对场景才是关键。另外还有一个容易被忽略的点导出的SQL脚本在目标库执行之后一定要快速跑一遍数据抽样比对比如找出主键相同但某几个关键字段不一致的记录。实测中在字符集不一致、默认值设置不同、触发器重复执行的情况下导入后的数据可能表面上是完整的但细节已经变了。只有抽样比对过才算真正完成了一次导出到导入的闭环。最后分享一个小习惯。导完表之后我总会顺手在那个SQL文件的最顶部加一行注释写明源库连接信息、导出时间、当前表的行数以及导出人。别小看这一行过了三个月再有人拿着这个文件问你“这是哪来的数据”这行注释能省掉一次全库排查的功夫。操作久了你会发现导出表的技术难度并不高真正会坑人的永远是那些没有记录的习惯和临门一脚的细节。