2

一些背景：

在大约十年前的 Oracle 10 左右（给予或接受），甲骨文添加了一种导出和导入数据库的新方法，称为Oracle 数据泵。除了愚蠢的名称外，该功能的工作原理与原始导出和导入实用程序基本相同。

原始实用程序的链接包含以下警告文本，这似乎至少有些自相矛盾：

从 Oracle 数据库 11g 开始，不支持原始导出以供一般使用。11g 中唯一支持的原始导出使用是将 XMLType 数据向后迁移到数据库版本 10g 第 2 版 (10.2) 或更早版本。因此，Oracle 建议您使用新的数据泵导出和导入实用程序，除非在以下需要原始导出和导入的情况下：

  • 您想要导入使用原始导出实用程序 (exp) 创建的文件。

  • 您想要导出将使用原始导入实用程序 (imp) 导入的文件。例如，如果您想从 Oracle 数据库 10g 中导出数据，然后将其导入到较早的数据库版本中。

据我所知，无法正常运行的唯一原因Exp是Imp数据库是否使用了 11g 以后引入的功能。否则，看起来旧的Exp和Imp命令应该可以正常工作，并且从上面看，它们似乎得到了官方的支持。

“数据泵”与“原始”导出的主要区别之一 - 这对我的应用程序很重要 - 数据泵仅在服务器端运行，这意味着用户至少需要一定程度的权限服务器访问导出生成的文件。最好的情况是不方便，最坏的情况是，这会导致文件不能被 dba 以外的任何人访问。

问题：

当我们从 11g 升级到 12c 时，我们在使用原始导出实用程序时遇到了问题。它会成功运行到导出触发器，然后产生如下错误：

EXP:00056 ORACLE error 4063 encountered
ORA-06508: package body XDB.DBMS_XDBUTIL_INT has errors
ORA-06508: PL/SQL: could not find program unit being called:
"XDB.DBMS_XDBUTIL_INT"

问题：

这个问题在不同的情况下至少出现了十几次，我们有点像是在玩打地鼠。解决它的最新尝试涉及重新编译服务器上的每个包，这大约需要半小时。

  1. 为什么这个出口问题不断出现？
  2. Exp实际上，正式地被Imp弃用了，以至于我们不再能够可靠地使用它们吗？
  3. 还有其他直接的方法来获取数据库的客户端导出吗？
4

1 回答 1

1

  1. 为什么这个出口问题不断出现？

    由于问题是间歇性的，我猜它是由延迟段创建引起的。从 11g 开始，可以将表和分区配置为在有一些数据之前不分配任何空间。（这可以为具有许多空分区的表节省大量空间。）但是 Exp 不理解这一点，并假设每个表都必须有一个段。这意味着某些表和相关功能可能会出现“随机”导致问题，具体取决于它们最近是否被填充或截断。

    您可以使用以下查询找到这些表：

    select * from dba_tables where segment_created = 'NO';

    然后强迫他们有这样一段话：

    alter table table_name allocate extent;

  2. Exp 和 Imp 实际上是否正式被弃用，以至于我们不再能够可靠地使用它们？

    这是有争议的，但我会说是的，原来的 Exp 和 Imp 现在真的被“弃用”了。确实感觉甲骨文玩了很多不推荐使用的软件。例如，弃用超级昂贵的 Goldengate 的免费变更数据捕获，或者在几乎没有人想要使用其昂贵的容器时弃用非容器架构。但是已经很久了，Exp和Imp不再削减它了。

  3. 还有其他直接的方法来获取数据库的客户端导出吗？

    尝试OCP、Oracle CoPy。您仍然需要在服务器上生成导出。但是 OCP 允许您将文件从服务器文件系统下载到客户端文件系统，而无需任何服务器文件系统权限。它仍然没有应有的直接，但至少您不必授予每个人对服务器文件系统的权限。

于 2018-01-27T05:54:36.273 回答