问题
Here's a crazy one: the same external table definition works fine in one database, but fails in another. Not schema - database. Two databases, both on the same OS, different servers. In addition, it's failing on the 2nd date field, though both are defined the same. The NLS settings are the same on both servers, thought I thought the date mask should override that anyway. Here's the definition:
-- 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;
Here's sample data:
TOTEA01217611,20121122,TOTE,847759,20121122
And, the log error:
KUP-04021: field formatting error for field FIELD5_DATE
KUP-04026: field too long for datatype
Anyone have an answer for this madness?
回答1:
Apparently, the input file was corrupt in some way, perhaps loaded as binary instead of ASCII.
What we did: - pulled another file from the first server to the second server and tested - this one worked fine! - deleted the contents of this second file, and cut and pasted the exact text from the first file directly into this second file - ran the test again - it worked!
Everything, as far as we could tell, was identical between the two files. To rule out something to do with the filename, we then renamed this file to the original file's name, but it still worked. We then re-FTP'd the original file, and it worked this time as well. So, again, the only thing we can think of is that some non-printing characters were in the file.
We didn't have a hex editor available to check, but for anyone coming across this same thing, viewing the contents as hex would be one way to make sure there was nothing odd in the file.
来源:https://stackoverflow.com/questions/15982842/oracle-external-table-date-field-works-in-one-db-and-not-in-another