Database Reference
In-Depth Information
11 FROM "SYS_SQLLDR_X_EXT_DEPT"
12 /
INSERT /*+ append */ INTO DEPT
*
ERROR at line 1:
ORA-29913: error in executing ODCIEXTTABLEOPEN callout
ORA-29400: data cartridge error
KUP-04063: unable to open log file demo1.log_xt
OS error Permission denied
ORA-06512: at "SYS.ORACLE_LOADER", line 19
ORA-06512: at line 1
Well, that doesn't seem right at first. I'm logged into the operating system as
TKYTE
, the directory I'm logging in
to is
/home/tkyte
, and I own that directory, so I can certainly write to it (I created the SQLLDR log file there, after all).
What happened? The fact is that the external table code is running in the Oracle server software in my dedicated or
shared server. The process trying to read the input data file is the Oracle software owner, not my account. The process
trying to create the log file is the Oracle software owner, not my account. Apparently, Oracle did not have the privilege
required to write into my directory, and hence the attempted access of the external table failed. This is an important
point. To read a table, the account under which the database is running (the Oracle software owner) must be able to
•
Read
the file we are pointing to. In UNIX/Linux, that means the Oracle software owner must
have read and execute permissions on all directory paths leading to the file. In Windows, the
Oracle software owner must be able to read that file.
•
Write
to the directories where the log file will be written to (or bypass the generation of the log
file altogether, but this is not generally recommended). In fact, if the log file already exists, the
Oracle software owner must be able to write to the existing file.
•
Write
to any of the bad files we have specified, just like the log file.
Returning to the example, the following command gives Oracle the ability to write into my directory:
EODA@ORA12CR1> host chmod a+rw.
■
this command actually gives everyone the ability to write into our directory! this is just a demonstration;
normally, we would use a special directory—perhaps owned by the oracle software owner itself—to do this.
Caution
