Oracle SQL*Loader and External Tables

This post gives a brief introduction to the two oracle’s technologies for loading external data into a database tables – SQL*Loader (SQLLDR) and External Table and later provides some guidelines on when to chose what.

SQL*Loader (SQLLDR)

SQL*Loader loads data from external files into tables in the Oracle database. SQL*Loader uses two primary files: the datafile, which contains the information to be loaded, and the control file, which contains information on the format of the data, the records and fields within the file, the order in which they are to be loaded, and even, when needed, the names of the multiple files that will be used for data.

Advertisement

Oracle ROWID and its Uniqueness

ROWID Data Type

Oracle Database uses a ROWID datatype to store the address (rowid) of every row in the database.

■ Physical rowids store the addresses of rows in ordinary tables (excluding index-organized tables), clustered tables, table partitions and subpartitions, indexes, and index partitions and subpartitions.
■ Logical rowids store the addresses of rows in index-organized tables.

A single datatype called the universal rowid, or UROWID, supports both logical and physical rowids, as well as rowids of foreign tables such as non-Oracle tables accessed through a gateway.

Uncaught Exception Handling and ThreadDeath

Java uses (or in more specific terms, throws) exceptions to notify exceptional situations in programs. Developers write try-catch blocks to handle these exceptions, or simply propagate the exceptions upwards in the call stack.

An uncaught exception is a Throwable, which is not caught by any part of the application in the call stack where the exception occurred. It has propagated through the call stack, and has arrived at the underlying thread (could be the main thread or a defined thread), without being caught. Java actually handles uncaught exceptions according to the thread in which they occur. When an uncaught exception occurs in a particular thread, Java looks for what is called an uncaught exception handler, actually an implementaiton of the interface UnCaughtExceptionHandler.

The specific procedure is as follows. When an uncaught exception occurs, the JVM does the following:

• it calls a special private method, dispatchUncaughtException(), on the Thread class in which the exception occurs;
• it then terminates the thread in which the exception occurred

The dispatchUncaughtException() method, in turn, calls the thread’s getUncaughtExceptionHandler() method to find out the appropriate uncaught exception handler to use. Normally, this will actually be the thread’s parent ThreadGroup, whose handleException() method by default will print the stack trace.