Oracle8(TM) Server Utilities
Release 8.0

A54652-01

Library

Product

Contents

Index

Prev Next

6
SQL*Loader Command-Line Reference

This chapter shows you how to run SQL*Loader with command-line keywords.

This chapter covers the following subjects:

SQL*Loader Command Line

You can invoke SQL*Loader from the command line using certain keywords.

Additional Information: The command to invoke SQL*Loader is operating system-dependent. The following examples use the UNIX-based name, "sqlldr". See your Oracle operating system-specific documentation for the correct command for your system.

If you invoke SQL*Loader with no keywords, SQL*Loader displays a help screen with the available keywords and default values. The following example shows default values that are the same on all operating systems.

sqlldr
...
Valid Keywords:
userid - Oracle username/password
control - Control file name
log - Log file name
bad - Bad file name
data - Data file name
discard - Discard file name
discardmax - Number of discards to allow
(Default all)
skip - Number of logical records to skip
(Default 0)
load - Number of logical records to load
(Default all)
errors - Number of errors to allow
(Default 50)
rows - Number of rows in conventional path bind array
or between direct path data saves
(Default: Conventional Path 64, Direct path all)
bindsize - Size of conventional path bind array in bytes
(System-dependent default)
silent - Suppress messages during run
(header, feedback, errors, discards, partitions, all)
direct - Use direct path
(Default FALSE)
parfile - Parameter file: name of file that contains
parameter specifications
parallel - Perform parallel load
(Default FALSE)
file - File to allocate extents from

Using Command-Line Keywords

Keywords are optionally separated by commas. They are entered in any order. Keywords are followed by valid arguments.

For example:

SQLLDR CONTROL=foo.ctl, LOG=bar.log, BAD=baz.bad, DATA=etc.dat 
USERID=scott/tiger, ERRORS=999, LOAD=2000, DISCARD=toss.dis,
DISCARDMAX=5

Specifying Keywords in the Control File

If the command line's length exceeds the size of the maximum command line on your system, you can put some of the command-line keywords in the control file, using the control file keyword OPTIONS. See page 5-12.

They can also be specified in a separate file specified by the keyword PARFILE (see page 6-6). These alternative methods are useful for keyword entries that seldom change. Keywords specified in this manner can still be overridden from the command line.

Command-Line Keywords

This section describes each available SQL*Loader command-line keyword.

BAD (bad file)

BAD specifies the name of the bad file created by SQL*Loader to store records that cause errors during insert or that are improperly formatted. If a filename is not specified, the name of the control file is used by default with the .BAD extension. This file has the same format as the input datafile, so it can be loaded by the same control file after updates or corrections are made.

A bad file filename specified on the command line becomes the bad file associated with the first INFILE statement in the control file. If the bad file filename was also specified in the control file, the command-line value overrides it.

BINDSIZE (maximum size)

BINDSIZE specifies the maximum size (bytes) of the bind array. The size of the bind array given by BINDSIZE overrides the default size (which is system dependent) and any size determined by ROWS. The bind array is discussed on page 5-69.

CONTROL (control file)

CONTROL specifies the name of the control file that describes how to load data. If a file extension or file type is not specified, it defaults to CTL. If omitted, you are prompted for it.

DATA (data file)

DATA specifies the name of the data file containing the data to be loaded. If a filename is not specified, the name of the control file is used by default. If a file extension or file type is not specified, it defaults to DAT.

DIRECT (data path)

DIRECT specifies the data path, that is, the load method to use-conventional path or direct path. TRUE specifies a direct path load. FALSE specifies a conventional path load. FALSE is the default. Load methods are explained in Chapter 8, "SQL*Loader: Conventional and Direct Path Loads".

DISCARD (discard file)

DISCARD specifies a discard file (optional) to be created by SQL*Loader to store records that are neither inserted into a table nor rejected. If a filename is not specified, it defaults to DSC. This file has the same format as the input datafile. So it can be loaded by the same control file after appropriate updates or corrections are made.

A discard file filename specified on the command line becomes the discard file associated with the first INFILE statement in the control file. If the discard file filename is specified also in the control file, the command-line value overrides it.

DISCARDMAX (discards to disallow)

DISCARDMAX specifies the number of discard records that will terminate the load. The default value is all discards are allowed. To stop on the first discarded record, specify one (1).

ERRORS (errors to allow)

ERRORS specifies the maximum number of insert errors to allow. If the number of errors exceeds the value of ERRORS parameter, SQL*Loader terminates the load. The default is 50. To permit no errors at all, set ERRORS=0. To specify that all errors be allowed, use a very high number.

On a single table load, SQL*Loader terminates the load when errors exceed this error limit. Any data inserted up that point, however, is committed.

SQL*Loader maintains the consistency of records across all tables. Therefore, multi-table loads do not terminate immediately if errors exceed the error limit. Before terminating the load, SQL*Loader completely processes the current bind array to filter out the bad rows contained in the bind array.

In all cases, SQL*Loader writes erroneous records to the bad file.

FILE (file to load into)

FILE specifies the database file to allocate extents from. It is used only for parallel loads. By varying the value of the FILE parameter for different SQL*Loader processes, data can be loaded onto a system with minimal disk contention. For more information, see "Parallel Data Loading Models" on page 8-26.

LOAD (records to load)

LOAD specifies the maximum number of logical records to load (after skipping the specified number of records). By default all records are loaded. No error occurs if fewer than the maximum number of records are found.

LOG (log file)

LOG specifies the log file which SQL*Loader will create to store logging information about the loading process. If a filename is not specified, the name of the control file is used by default with the default extension (LOG).

PARFILE (parameter file)

PARFILE specifies the name of a file that contains commonly-used command-line parameters. For example, the command line could read:

SQLLDR PARFILE=example.par

and the parameter file could have the following contents:

userid=scott/tiger
ontrol=example.ctl
errors=9999
log=example.log
Note: Although it is not usually important, on some systems it may be necessary to have no spaces around the equal sign ("=") in the parameter specifications.

PARALLEL (parallel load)

PARALLEL specifies whether direct loads can operate in multiple concurrent sessions to load data into the same table. For more information on PARALLEL loads, see "Parallel Data Loading Models" on page 8-26.

ROWS (rows per commit)

Conventional path loads only: ROWS specifies the number of rows in the bind array. The default is 64. (The bind array is discussed on "Determining the Size of the Bind Array" on page 5-69.)

Direct path, loads only: ROWS identifies the number of rows you want to read from the data file before a data save. The default is to save data once at the end of the load. For more information, see "Data Saves" on page 8-12.

Because the direct load is optimized for performance, it uses buffers that are the same size and format as the system's I/O blocks. Only full buffers are written to the database, so the value of ROWS is approximate.

SILENT (feedback mode)

When SQL*Loader begins, a header message like the following appears on the screen and is placed in the log file:

SQL*Loader:   Production on Wed Feb 24 15:07:23... 
Copyright (c) Oracle Corporation...

As SQL*Loader executes, you also see feedback messages on the screen, for example:

Commit point reached - logical record count 20

SQL*Loader may also display data error messages like the following:

Record 4: Rejected - Error on table EMP
ORA-00001: unique constraint <name> violated

You can suppress these messages by specifying SILENT with an argument. For example, you can suppress the header and feedback messages that normally appear on the screen with the following command-line argument:

SILENT=(HEADER, FEEDBACK)

Use the appropriate keyword(s) to suppress one or more of the following:

HEADER  

Suppresses the SQL*Loader header messages that normally appear on the screen. Header messages still appear in the log file.  

FEEDBACK  

Suppresses the "commit point reached" feedback messages that normally appear on the screen.  

ERRORS  

Suppresses the data error messages in the log file that occur when a record generates an Oracle error that causes it to be written to the bad file. A count of rejected records still appears.  

DISCARDS  

Suppresses the messages in the log file for each record written to the discard file.  

PARTITIONS  

This new Oracle8 option for a direct load of a partitioned table disables writing the per-partition statistics to the log file  

ALL  

Implements all of the keywords.  


SKIP (records to skip)

SKIP specifies the number of logical records from the beginning of the file that should not be loaded. By default, no records are skipped.

This parameter continues loads that have been interrupted for some reason. It is used for all conventional loads, for single-table direct loads, and for multiple-table direct loads when the same number of records were loaded into each table. It is not used for multiple table direct loads when a different number of records were loaded into each table. See "Continuing Multiple Table Conventional Loads" on page 5-31 for more information.

USERID (username/password)

USERID is used to provide your Oracle username/password. If omitted, you are prompted for it. If just a slash is used, USERID defaults to your operating system logon. A SQL*Net database specification string can be used for a conventional path load into a remote database. For more information on SQL*Net, see your SQL*Net documentation.

Index Maintenance Options

Two new, Oracle8 index maintenance options are available (default FALSE):

SKIP_UNUSABLE_INDEXES

The SKIP_UNUSABLE_INDEXES option applies to both conventional and direct path loads.

The SKIP_UNUSABLE_INDEXES=TRUE option allows SQL*Loader to load a table with indexes that are in Index Unusable (IU) state prior to the beginning of the load. Indexes that are not in IU state at load time will be maintained by SQL*Loader. Indexes that are in IU state at load time will not be maintained but will remain in IU state at load completion.

However, indexes that are UNIQUE and marked IU are not allowed to skip index maintenance. This rule is enforced by DML operations, and enforced by the direct path load to be consistent with DML.

Load behavior with SKIP_UNUSABLE_INDEXES=FALSE differs slightly between conventional path loads and direct path loads:

SKIP_INDEX_MAINTENANCE

SKIP_INDEX_MAINTENANCE={TRUE | FALSE} stops index maintenance for direct path loads but does not apply to conventional path loads. It causes the index partitions that would have had index keys added to them instead to be marked Index Unusable because the index segment is inconsistent with respect to the data it indexes. Index segments that are not affected by the load retain the Index Unusable state they had prior to the load.

The SKIP_INDEX_MAINTENANCE option:

Exit Codes for Inspection and Display

The Oracle8 SQL*Loader provides the results of a SQL*Loader run immediately upon completion. Depending on the platform, as well as recording the results in the log file, the SQL*Loader may report the outcome also in a process exit code. This Oracle8 SQL*Loader functionality allows for checking the outcome of a SQL*Loader invocation from the command line or script. The following load results return the indicated exit codes:

Result   Exit Code  

All rows loaded successfully  

EX_SUCC  

All/some rows rejected  

EX_WARN  

All/some rows discarded  

EX_WARN  

Discontinued load  

EX_WARN  

Command line/syntax errors  

EX_FAIL  

Oracle errors fatal to SQL*Loader  

EX_FAIL  

OS related errors (like file open/close, malloc, etc.)  

EX_FTL  

For UNIX the exit codes are as follows:

EX_SUCC 0
EX_FAIL 1
EX_WARN 2
EX_FTL 3

You can check the exit code from the shell to determine the outcome of a load. For example, you could place the SQL*Loader command in a script and check the exit code within the script:

#!/bin/sh 
sqlldr scott/tiger control=ulcase1.ctl log=ulcase1.log 
retcode=\Qecho $?\Q 
case "$retcode" in 
0) echo "SQL*Loader execution successful" ;; 
1) echo "SQL*Loader execution exited with EX_FAIL, see logfile" ;; 
2) echo "SQL*Loader exectuion exited with EX_WARN, see logfile" ;; 
3) echo "SQL*Loader execution encountered a fatal error" ;; 
*) echo "unknown return code";; 
esac 




Prev

Next
Oracle
Copyright © 1997 Oracle Corporation.

All Rights Reserved.

Library

Product

Contents

Index