0

这是一个疯狂的例子：相同的外部表定义在一个数据库中工作正常，但在另一个数据库中失败。不是架构 - 数据库。两个数据库，都在同一个操作系统，不同的服务器上。此外，它在第二个日期字段上失败，尽管两者的定义相同。两台服务器上的 NLS 设置相同，我认为无论如何日期掩码都应该覆盖它。这是定义：

-- access parameters
-- http://docs.oracle.com/cd/E11882_01/server.112/e16536/et_params.htm

CREATE TABLE ext_tab (
  FIELD1                  VARCHAR2(30),
  FIELD2_DATE             DATE,
  FIELD3                  VARCHAR2(4),
  FIELD4                  VARCHAR2(6),
  FIELD5_DATE             DATE
)
ORGANIZATION EXTERNAL
  ( TYPE ORACLE_LOADER
    DEFAULT DIRECTORY DIR_DATADIR
    ACCESS PARAMETERS
      ( RECORDS DELIMITED BY NEWLINE
        NOBADFILE
        NODISCARDFILE
        LOGFILE 'LOGFILE_LOG'
        FIELDS
          TERMINATED BY ','
          OPTIONALLY ENCLOSED BY '"' and '"'
          LRTRIM
          MISSING FIELD VALUES ARE NULL
          REJECT ROWS WITH ALL NULL FIELDS
          (
  FIELD1                  CHAR(30),
  FIELD2_DATE             CHAR(8)   date_format DATE mask  'YYYYMMDD',
  FIELD3                  CHAR(4),
  FIELD4                  CHAR(6),
  FIELD5_DATE             CHAR(8)   date_format DATE mask  'YYYYMMDD'
          )
      )
    LOCATION ('Sample_Input_csv.csv')
  )
REJECT LIMIT UNLIMITED
NOPARALLEL;

这是示例数据：

TOTEA01217611,20121122,TOTE,847759,20121122

并且，日志错误：

KUP-04021: field formatting error for field FIELD5_DATE

KUP-04026：数据类型的字段太长

有人对这种疯狂有答案吗？

4

1 回答 1

0

显然，输入文件以某种方式损坏，可能以二进制而不是 ASCII 加载。

我们所做的： - 将另一个文件从第一台服务器拉到第二台服务器并进行测试 - 这个工作正常！- 删除第二个文件的内容，并将第一个文件中的确切文本直接剪切并粘贴到第二个文件中 - 再次运行测试 - 成功了！

据我们所知，这两个文件之间的一切都是相同的。为了排除与文件名有关的情况，我们将该文件重命名为原始文件名，但它仍然有效。然后我们重新对原始文件进行了 FTP 处理，这次它也能正常工作。所以，再一次，我们唯一能想到的是文件中有一些非打印字符。

我们没有可供检查的十六进制编辑器，但对于遇到同样情况的任何人，以十六进制格式查看内容将是确保文件中没有异常的一种方法。

于 2013-04-14T15:47:36.293 回答