The advent of external tables in Oracle9i is exciting because it allows SQL queries to access any type of flat file, as if the data were stored inside an Oracle table. We’ll examine some caveats to this new approach, specifically:

  • ·        The external file must be comma-delimited and stored on the server as a file with a .csv extension.
  • ·        External spreadsheets are not good for large files because the entire file must be reread into Oracle whenever a change is saved to the spreadsheet.
  • ·        End users must never reformat the data columns inside the spreadsheet environment.

As a review, in the last article we took the following comma-delimited flat file and accessed it in Oracle9i as an external table.

The next code listing shows the syntax used to make the file appear as an Oracle external table.
Create directory testdir as ‘u01/oracke/oradata/testdb’
create table emp_ext (
Organization external
(type oracle_loader
default directory testdir
access parameters (records delimited by newline
fields terminated by ‘,’)
location (‘emp_ext.csv’))
reject limit 1000;

However, when defining the flat file as an external table, the file remains on the operating system as a flat file, where it can be read and updated with a variety of tools, including spreadsheets. Using Microsoft’s Excel spreadsheets, the external table data can be read just as if it were standard spreadsheet data (Figure A).

Figure A
An external table inside an Excel spreadsheet

End users can now manage critical tables inside easy-to-use spreadsheets. Oracle immediately notices whenever a change is made to the spreadsheet. However, there are important limitations to using spreadsheets as Oracle tables, the foremost being excessive disk I/O whenever the spreadsheet has changed. Let’s take a closer look.

Internals of external tables
It’s important to recognize that Oracle data inside spreadsheets will not be accessible as quickly as internal row data. Oracle can’t maintain row-level locking because the operating system, not Oracle, is in command. When a spreadsheet is defined as an external table, Oracle has no way of knowing when individual row data changes. The operating system will only tell Oracle that the entire spreadsheet has changed.

In addition, data blocks that are read from an external table are not placed inside the Oracle9i data buffers. The dictionary query in Listing A demonstrates that Oracle doesn’t read the external table rows into the RAM data cache.

As we see in Listing B, selections from our table don’t reside in the data buffers following a SQL query.

Oracle doesn’t make it clear whether a separate buffering mechanism is used for external tables. With this lack of buffering, Oracle9i must reread the entire spreadsheet for each SQL invocation that accesses the external table.

To maintain data integrity, Oracle must detect when the spreadsheet data has changed, but there is no way to discover when specific spreadsheet values have changed. When Oracle detects that the flat file has been updated, all data in the RAM data buffers becomes invalid, and the entire spreadsheet must be reread. This is the primary reason external tables are not efficient for large volumes of data.

Because Oracle reads operating system files in data blocks, we can compute the amount of disk I/O by determining the number of spreadsheet blocks with a simple shell script. In this script, we know the Oracle database has 8-KB block sizes:
bytes=`ls -al|grep emp_ext.csv|awk ‘{ print $5 }’`
num_bytes=`expr $bytes`
blocks=`expr $num_bytes / 8192`
echo $blocks

This script will tell us exactly how many disk reads are required to access the Oracle external table whenever a change is made.

Security for external table files
Any saved change to the spreadsheet causes the entire spreadsheet to be read again into Oracle from the disk. Spreadsheets can be password-protected at the operating system level, and they can be marked read-only with the following DOS command:
c:\docs\pubsdb\queries> attrib +r emp_ext.csv

In UNIX, we can use this command to make the spreadsheet read-only for everyone except the owner of the spreadsheet:
chmod 744 emp_ext.csv

This ensures the file will not be updated, except by authorized users. It makes sure that Oracle caches the data in an efficient manner. Once defined to Oracle, the spreadsheet will be accessible both through Oracle and the Excel spreadsheet.

Looking for more Oracle information?

Oracle data model extensions
Oracle materialized views
Oracle design tips

Limitations of comma-delimited spreadsheet files
In order for Oracle to successfully read comma-delimited (csv) files, it’s important to avoid making spreadsheet-specific changes because Excel will change the internal storage of the column to accommodate the formatting. For example, let’s assume that a manager reformats the SALARY column for comma display, as in Figure B.

Figure B
Reformatting a comma-delimited (csv) spreadsheet

Once the file has been saved, Oracle can no longer read the SALARY column because the column has been stored in quotes. To Oracle, this defines the column as a character:

The accidental reformatting of the file makes it unreadable by Oracle. You must take special care to instruct end users to never change the formatting.