Tài liệu Oracle Unleashed- P5 pdf

Basic SQL*Loader Components SQL*Loader requires two types of input: the external data, which can reside on disk or tape, and control information contained in the control file, which de

CONNECT INTERNAL;

CONNECT SYSTEM/MANAGER;

CONNECT SCOTT/TIGER;

DISCONNECT

Description: You use the DISCONNECT command to disconnect from the current instance without exiting SQL*DBA

It has no additional parameters You can use this command in conjunction with SET INSTANCE to access multiple instances at your site without exiting and reentering SQL*DBA

operating system until you type EXIT to return to SQL*DBA

Description: The MONITOR command enables you to monitor various statistics and attributes of the database,

processes, or users This command is extremely helpful in analyzing and resolving database problems You can specify any parameters that the menu requests in order on the command line

SYSTEMIO

SYSTEMSTATISTIC

TABLE

Keywords:

CIRCUIT Displays current information on the virtual circuits owned by each shared server in a

Multi-Threaded Server environment

DISPATCHER Displays current information about a shared server's dispatcher processes in a Multi-Threaded

Server environment

FILEIO Displays read/write information for every database file associated with the current instance

LATCH Displays information on all current latches

LCACHE Displays current information on the library cache

LOCK Lists the current processes and the locks they are waiting on Using ALL lists all locks being

held by current processes

PROCESS Monitors summary information for every process connected to the current instance

QUEUE Lists information on each shared server's message queues

ROLLBACK Shows activity on every active rollback segment in the instance

SESSION Displays active process information

SESSIONSTATISTIC Shows user session statistics for current user processes

SHARED Monitors shared server activity

SQLAREA Gives various statistics on the shared SQL area

SYSTEMIO Summarizes the read/write statistics for each Oracle process This information is not precise

but instead is representative of relative distribution of I/O

SYSTEMSTATISTIC Shows system statistics for the current database

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

TABLE Displays table names of tables referenced in SQL statements that have been recently parsed

and reside in the shared SQL area

Description: You use the RECOVER command to perform media recovery on data files, tablespaces, or entire databases

as required You must be connected as INTERNAL to use this command, and you must have a dedicated process You cannot be connected through Oracle's Multi-Threaded Server

RECOVER TABLESPACE tablespace

RECOVER DATAFILE filename

Keywords:

DATABASE Requests the recovery of an entire database Will apply redo log files to all

tablespaces needing media recovery

UNTIL TIME date Used to specify an incomplete RECOVER to a specific time You must specify

the date in the following format:

UNTIL CHANGE integer

Used to recover until a specific change number This is very useful in restoring a

tablespace where a table was accidentally dropped integer must be a valid

change number, and the redo logs must be available to Oracle

UNTIL CANCEL Specifies recovery should continue applying redo logs until the operator cancels

the operation Recovery continues redo log by redo log until canceled

USING BACKUP CONTROLFILE

Tells the database to use a backup version of the control file instead of the primary one This control file must be available to Oracle, or the command will fail

TABLESPACE tablespace Recovers the specified tablespace, or tablespaces You can recover up to 16 of

them in a single statement

DATAFILE filename Specifies a particular data file belonging to a tablespace that you want to restore

There is no limit to the number of data files you can recover in a given statement

Examples:

RECOVER TABLESPACE tools;

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

RECOVER DATABASE;

RECOVER DATAFILE 'users_01.dbf';

RECOVER DATABASE UNTIL '1994-10-11:15:01:00';

RECOVER TABLESPACE tools, users;

Tells the database to automatically apply all redo logs necessary to bring the database, tablespace, or data file to a usable state When this is ON, the database begins recovery without requesting input from the operator Log filenames are derived from the database parameters

LOG_ARCHIVE_DEST and LOG_ARCHIVE_FORMAT If the files cannot be located, operator input is requested

CHARWIDTH integer Defines the column width displayed for columns of type CHAR The

default is 80, and if no integer is specified, the parameter is reset to 80

COMPATIBILITY V6/V7

Sets the SQL*DBA compatibility mode to either Version 6 or Version 7 This parameter affects how you specify columns of type CHAR, integrity constraint definitions, and the storage parameters for rollback segments

CYCLE integer

Used for the MONITOR command, sets the time that the monitor screens cycle in gathering statistics The default is 5 seconds The minimum is 1 second; maximum is 3600 seconds The smaller the number, the higher the impact on the database

DATEWIDTH integer

Sets the width for DATE data to be displayed The default is 9, and if entered with no integer, it is reset to 9 The range of values for this parameter is operating-system specific

ECHO ON/OFF Enables echoing of commands that are executed from command files The

default is OFF In this mode, only the output is displayed

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

INSTANCE instance-path/LOCAL

Sets the instance name to where all SQL*DBA commands are applied

The instance-path is defined by a system node name and database name

separated with a hyphen A sample connect string is my_database Issuing the command with no database definition resets the instance back to the local default instance

my_host-LABWIDTH Used strictly with Oracle's Trusted Server package

LINES integer

Limits the number of lines the output window of SQL*DBA can store and recall After reaching the limit, the lines at the beginning of the buffer are erased The default value is 1000

LOGSOURCE pathname/DEFAULT

Tells Oracle where to find archived redo logs to be used during a recovery session Use this to set the location to a temporary location where redo logs have been restored

LONGWIDTH integer

Tells SQL*DBA how to display LONG data By default, the display is 80 characters only Once again, the operating system defines the range of values for this parameter

MAXDATA integer

Sets the maximum number of bytes that you can fetch from the database

in a single SELECT statement The default is 20,480 bytes (20K) Your operating system defines the maximum number for this parameter

NUMWIDTH integer

Defines the length in characters that data types of NUMBER are displayed in The default is 10, and the minimum and maximum values are operating-system dependent

RETRIES integer/INFINITE

Used with the STARTUP command, this specifies how many times the startup command attempts to start the database INFINITE means it tries until it succeeds or is canceled

SERVER OUTPUT OFF/ON SIZE integer

Specifies the size of the message buffer, in bytes, that can accumulate at

one time This message buffer is used by the PUT() and PUT_LINE()

commands

SPOOL filename/OFF Captures commands and output from the current session to a file

Specifying OFF closes the previously opened file

STOPONERROR ON/OFF

Tells SQL*DBA, when executing a command file, to stop if it encounters

an error If it finds one, the rest of the command file is not executed, and it returns control to the operating system

TERM PAGE/NOPAGE

Tells SQL*DBA to display output one page at a time The default, NOPAGE, scrolls all output to the output window After that, you can navigate to the output window and scroll through the saved output

TERMOUT ON/OFF

Controls the display of output from SQL commands to the output window ON enables display of the output whereas OFF disables the output This is helpful if you're spooling output to files The output is sent

to the spool file but not the terminal

TIMING ON/OFF Displays the parse, execute, and fetch times for every SQL statement

executed The default is OFF This option is useful for establishing response times

ERRORS Shows all errors encountered during the last compilation of a function, procedure, or package

Output includes the line, column, and error message generated

LABEL This is a Trusted Oracle parameter

PARAMETERS

Shows the current values for all database parameters specified in the startup files for the current instance Used alone, it displays all parameters Used in conjunction with a parameter name, it shows the specific parameter If a partial parameter name is used, the output includes all parameters that are similar

Shuts down the database by preventing new connections, terminating all existing sessions, and committing or rolling back current transactions and then checkpoints the database before dismounting and closing it Media recovery is not required

NORMAL This is the default It waits for currently connected users to disconnect, prevents new connections,

checkpoints, and then closes and dismounts the database No media recovery is required

OFF Closes the currently opened file.

RESTRICT

Same as the ALTER SYSTEM ENABLE RESTRICTED SESSION command; enables the database to start up in restricted mode and will only give access to users with the RESTRICTED SESSION role

Enables the database to start up with a specific parameter file (INIT.ORA) Very useful if the INIT.ORA file is not in the current directory or if you are starting up a new

OPEN Default option; mounts and opens the default database

RECOVER

Similar to the RECOVER DATABASE command; starts the current instance and recovers the database, if required

The recovery works as if AUTORECOVERY were set to

ON If the recovery fails, the database remains mounted but does not open

database Starts this specific instance If no instance is specified,

startup runs on the default instance

mount options Specifies three types of options for the startup:

single instance to use

parallel mode

failing

Examples:

STARTUP;

STARTUP MOUNT;

STARTUP PFILE='/home/oracle/init.ora' PARALLEL;

STARTUP MOUNT RESTRICT;

STARTUP FORCE;

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

Summary

SQL*DBA is a powerful tool that is useful for creating, managing, and tuning all your Oracle instances The flexibility

to run in command, line, or menu mode gives the user a definite advantage that many other packages do not provide The capability to automate many of the SQL*DBA commands enables the database administrator to turn over some of the database operations to secondary support personnel—which can help create a higher availability system with less down time

Overall, this tool is valuable in the day-to-day responsibilities of every database administrator and custom developer

Previous

Page TOC

Next Page Home

Previous

Page TOC

Next Page Home

● 8

❍ SQL*Loader

■ Introduction

■ Basic SQL*Loader Components

■ The Input Data

■ The Control File

■ The Log File

■ Discard and Bad Files

■ Physical Versus Logical Records

■ Concatenated Records

■ SQL*Loader Paths

■ The Conventional Path

■ The Direct Path

■ Parallel Data Loading

■ Control File Syntax

■ INTO TABLE Clause

■ Table-Specific Loading Method

■ Table-Specific OPTIONS Clause

■ Figure 8.13 Column specifications

■ Multiple Table Statements

■ Command-Line Options and Parameter Files

SQL*Loader utility, a very versatile tool that loads external data into Oracle database tables SQL*Loader is very flexible, and it is configurable to the point that you often can avoid development of 3GL procedures with embedded SQL Whenever you face the task of converting foreign data into the Oracle format, first consider the use of

SQL*Loader before resorting to other alternatives

The purpose of this chapter is to provide an overview of SQL*Loader's functionality, highlight its capabilities, describe commonly used syntax, and provide practical examples For additional information and in-depth reference material, refer

to the Oracle7 Server Utility User's Guide

Basic SQL*Loader Components

SQL*Loader requires two types of input: the external data, which can reside on disk or tape, and control information

(contained in the control file), which describes the characteristics of the input data and the tables and columns to load The outputs, some of which are optional, include the Oracle table(s), log file, bad file(s) and discard file(s) Figure 8.1 illustrates the components

Figure 8.1 SQL*Loader components.

The Input Data

SQL*Loader can process practically any type of data file, and it supports native data types for almost any platform Data

is usually read from one or more data files; however, data also may be embedded in the control file, after the control information The data file can exist as a fixed or variable format

In fixed format, the data exists in fixed-length records that all have the same format The fields for fixed-format files are

defined by starting and ending positions within the record, and the fields contain the same data type and length

throughout the file (see Figure 8.2.) Binary data must be in a fixed-format file, as SQL*Loader cannot handle it in a variable format

Figure 8.2 Fixed-format records.

In variable-format files, the data exists in records that may vary in length, depending on the length of the data in the

fields The fields are only as long as necessary to contain the data Fields in variable-format files may be separated by termination characters (such as commas or white space), enclosed by delimiter characters (such as quotation marks), or both (See Figure 8.3.)

Figure 8.3 Variable-format records.

If you are using files with termination characters, make sure that any field that contains the termination character

as part of the data is delimited For example, if you are using a file with comma separation, you can use double quotes to delimit any field containing a comma

To increase performance, use fixed-length records Based on the tests I have done, SQL*Loader takes about 50% longer to process a variable-format file than a fixed-format file I used the same amount of data for both

formats and comma separation for the variable data

Through the Oracle National Language Support (NLS), SQL*Loader has the capability to interpret and convert data with different character encoding schemes from other computer platforms and countries For example, SQL*Loader can load

an EBCDIC file into a database on an ASCII platform, or it can load an Asian character-set file into an American

character-set database

When porting a file from one platform (like EBCDIC mainframe) to a different target platform (like ASCII UNIX) that contains binary data (like packed decimal), remember that the file is transferred in an image or binary state For example, it you are using FTP to port the file, after you connect to the host system, be certain to put the session in an image state by typing binary at the FTP prompt Otherwise, FTP interprets and converts the data, thereby corrupting the binary data

The Control File

Before SQL*Loader can process the data in the data file(s), you must define the data specifications to SQL*Loader You use the control file to define the physical data file specifications, as well as the format of the data in the file(s) The control file is a free-format file that also contains additional control data, instructing SQL*Loader how to process the data The details concerning the control file are described in a later section

The Log File

Upon execution, SQL*Loader creates a log file containing detailed information about the load, including these items:

● Names of the input data file(s), control file, bad file(s), and discard file(s)

● Input data and associated table specifications

● SQL*Loader errors

● SQL*Loader results

● Summary statistics

See Figure 8.4 for a sample log file

Figure 8.4 Sample log file.

Discard and Bad Files

SQL*Loader has the built-in functionality, through specifications in the control file, to format the input data and include

or exclude the input record based on record-selection criteria If SQL*Loader includes the record for processing, it is passed to the Oracle kernel for insertion into the database table Figure 8.5 shows the record-filtering process

Figure 8.5 Record-filtering process.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

If SQL*Loader rejects the record due to a format error, or the Oracle kernel cannot insert the record into the database table(s) for any reason, the input record is written to the BAD file, in the same format as the original input data file If SQL*Loader rejects the record due to an exclusion based on the record-selection criteria, the input record is written to the DISCARD file (providing it was specified in the control file), also in the same format as the original input data file Because both the BAD and DISCARD files are written in the same format as the original input data file, they can be edited, if necessary, and used as input data files to another SQL*Loader session

Physical Versus Logical Records

Physical records are the individual lines in the input data file as they were created by the operating system on the

platform from which the file originated Physical records are terminated by a record-terminator character (like a carriage

return) Logical records correspond to a row in a database table A physical record can have a one-to-one association

with a logical record (See Figure 8.6.) SQL*Loader also enables you to create a many-to-one association between physical and logical records through the use of the CONCATENATE or CONTINUEIF clause in the control file You may create a one-to-many relationship by splitting one physical record into multiple logical records

Figure 8.6 Physical versus logical records.

Concatenated Records

SQL*Loader can concatenate records either by specifying the number of physical records that form one logical record or

by specifying conditional evaluations based on character occurrences within the data If the number of physical records that comprise a logical record varies, then you must base the concatenation on conditional evaluations The

CONCATENATE and CONTINUEIF clauses in the control file facilitate physical record concatenation

SQL*Loader Paths

SQL*Loader provides two paths for loading data:

● The conventional path

● The direct path

The Conventional Path

The conventional path generates a SQL INSERT command with the array processing interface to load the data into the table(s) Because of this interface, SQL*Loader competes with all other Oracle processes for buffer cache resources; Oracle looks for and tries to fill partially filled blocks on each insert (See Figure 8.7.) If you are loading small amounts

of data, this method is usually acceptable; however, with large volumes of data, this technique becomes too time

consuming and resource-intensive

Figure 8.7 Conventional loader path.

These conditions exist when you load data with the conventional path:

● Other users and Oracle processes can be accessing the table concurrently with SQL*Loader

● Indexes are updated as the rows are inserted into the table

● All referential and integrity constraints are enforced as the data is loaded into the table

● Database Insert triggers fire as the rows are inserted into the table

● You can apply SQL functions to the input data as it is being loaded

● Data can be loaded into a clustered table

● Data can be loaded with SQL*Net

The Direct Path

In contrast to the conventional path, the direct path is optimized for bulk data loads Instead of using the buffer cache to obtain and fill the database blocks, the direct path option uses the extent manager to get new extents and adjust the high water mark Direct path creates formatted database blocks and writes them directly to the database (See Figure 8.8.)

Figure 8.8 Direct loader path.

The direct path has several significant advantages:

● You can load and index large amounts of data into empty or non-empty table(s) in a relatively short period of time

● If loading data into empty tables, you can load presorted data and eliminate the sort and merge phases of the index build, thereby significantly increasing performance

● You can load data in parallel, which enables multiple SQL*Loader sessions to perform concurrent direct path loads into the same table

● You can specify that a direct path load be done in an UNRECOVERABLE mode, which bypasses Oracle's redo logging activity and significantly increases performance

Although the direct path significantly increases performance, it does have some limitations:

● The table(s) and index(es) into which you are loading data are exclusively locked at the start of the load and not released until the load is finished; the table(s) cannot have any active transactions on them and are not available

to other users or processes until the load is completed

● Indexes are put into a direct load state at the start of the load and need to be rebuilt, either automatically or manually, after the load is completed If the SQL*Loader session does not complete successfully, the indexes are left in the direct load state and need to be rebuilt manually Any PRIMARY KEY or UNIQUE constraints are not validated until after the load is complete and the index rebuild occurs; you may have duplicate keys and need to correct them through the use of the exceptions table before you can rebuild the index

● The NOT NULL constraint is the only constraint checked at insertion time All other integrity and referential constraints are re-enabled and enforced after the load is complete If any violations exist, they are placed into the exceptions table, which you should specify when you create the constraint The exceptions table must be created before the load session

● Database Insert triggers do not fire Any application functionality that relies on them must be accomplished through some other method

● You cannot apply SQL functions to the input data as it is being loaded

● Data cannot be loaded into a clustered table

● Only in the case where both computer systems belong to the same family, and both are using the same character set, can data be loaded through SQL*Net You should not use SQL*Net for direct path loads, as the direct path Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

should be used only for large amounts of data Network overhead offsets any performance gains associated with the direct path

● DEFAULT column specifications are not available with the direct path

● Synonyms that exist for the table(s) being loaded must point directly to the table; they cannot point to another synonym or view

The main advantage to the direct path method is performance No hard and fast rules exist to determine when to use the conventional method vs the direct path method, because the definition of "large amounts of data" varies from application to application Other external factors vary also, such as database availability, the cleanliness of the data being loaded, and system resources I have seen loads go from days to hours using the parallel, direct path method vs the conventional path method, with clean data on a multi-processor system But I have also seen cases where significant amounts of time were spent cleaning the table data so an index could rebuild after a direct path load You need to

analyze your situation, and based on all the factors, decide which method is better for your application

Parallel Data Loading

Oracle version 7.1 introduced the functionality of performing direct path loads in parallel This feature gives

SQL*Loader nearly linear performance gains on multi-processor systems By using the parallel option, you can load multiple input files concurrently into separate tablespace files, with each file belonging to the tablespace in which the table resides Maximum throughput is achieved by striping the tablespace across different devices and placing the input files on separate devices, and preferably separate controllers (See Figure 8.9.)

Figure 8.9 Striping parallel loads.

When using the parallel option, SQL*Loader creates temporary segments, sized according to the NEXT storage

parameter specified for the table, in the tablespace file specified in the OPTIONS clause of the control file

The specified file must be in the tablespace in which the table resides, or you get a fatal error

Upon completion of the SQL*Loader session, the temporary segments are merged (with the last extent trimmed of any free space) and added to the existing table in the database, above the high water mark for the table

You should drop indexes, primary key constraints, and unique key constraints on the table before doing a parallel load Oracle version 7.1 introduced parallel index creation, but you may use it only with a CREATE INDEX statement, not within an ALTER TABLE CREATE CONSTRAINT statement Therefore, the best method is to create the indexes first, using the parallel option, then create the primary key and unique constraints, which use the previously created indexes

Parallel SQL*Loader sessions that are interrupted normally (for example, by a Ctrl+C in UNIX) will terminate normally; they stop processing where they were interrupted Any temporary segments created during the session are added to the table's high water mark Any parallel session that was "killed" from an O/S command terminates

abnormally; the temporary segments are dropped and not added to the table's high water mark

If you are creating a very large table (which you know will be populated by the parallel option of SQL*Loader), first create a striped tablespace to hold the table, equally sizing the data files that comprise the tablespace across multiple devices Next, create the table with the minimal initial extent size (one Oracle block), and the NEXT extent sized to fully populate the size of the stripes, less one Oracle block Be sure to set PCTINCREASE to 0 Next, you must do some analysis of the data being loaded to determine the size of each of the input data files you want to load You want to size the input files so that SQL*Loader fully populates (as much as possible) the striped tablespace files to minimize wasted space

Your goal is to have concurrent SQL*Loader sessions each process an input file and place the output in a separate tablespace file, thereby maximizing throughput Each SQL*Loader session creates one temporary segment, in its

specified tablespace file, with the extent size being the size of the data file When the session completes, SQL*Loader trims the excess space from the temporary extent (because it has only one extent) and adds it above the table's high water mark

Using this method, you are evenly distributing the data across devices, thereby maximizing database I/O, minimizing the number of extents for the table, and maximizing SQL*Loader performance

Control File Syntax

The control file is in free format; however, it does have a few rules:

● White space, carriage returns, tabs, and so on are allowed at any position in the file

● As in Oracle, the contents of the file are case insensitive except for quoted (single or double) strings

● You can include comments anywhere, except within the data(assuming the data is contained in the control file),

by prefacing them with two hyphens; SQL*Loader ignores anything from the double hyphen to the end of the line

● You may use reserved words for table or column names; however, the words must be enclosed in double quotation marks

It is generally good practice not to use Oracle reserved words for any database object names I have seen numerous cases in which Oracle got confused when reserved words were used as database object names (the error messages are very ambiguous) For the complete lists of reserved words for SQL*Loader, SQL*DBA, and Oracle, refer

to the Oracle7 Server Utility User's Guide and the SQL Language Reference Manual

The control file is logically organized into seven sections:

● Table loading method

● CONCATENATION clause

● INTO TABLE clause

Listings 8.1, 8.2, and 8.3 help illustrate some of the syntax described in this section

Listing 8.1 is a sample control file for a direct path parallel load using a fixed-format input file This control file was used to test SQL*Loader results using the direct path parallel option in an unrecoverable mode For illustration purposes only, the SQL*Loader functions CONSTANT, SEQUENCE, SYSDATE, and RECNUM were used to populate column data

Listing 8.1 Parallel load control file.

OPTIONS (direct=true, parallel=true)

loader_desc POSITION (01:30) char

loader_col1 POSITION (31:40) char,

loader_col2 POSITION (41:50) char,

loadr col3 POSITION (51:60) char,

loader_col4 POSITION (61:70) char)

Listing 8.2 is a sample control file for a conventional path load using a variable-format file

Listing 8.2 Variable-format control file.

LOAD DATA

BADFILE'prod.bad'

INSERT INTO TABLE pord'

FIELDS TERMINATED BY','OPTIONALLY ENCLOSED BY ""

Listing 8.3 Foreign character set control file.

LOAD DATA CHARACTERSET WE8EBCDIC500

INFILE 'data01ORACLE/TEST/prod_detail'"FIX 28"

INSERT INTO TABLE prod_detail

(

PROD_CODE position(01:04) char,

SALES_MTD_LY position(05:10) decimal(11,2),

SALES_YTD_LY position(11:16) decimal(11,2),

SALES_MTD position(17:22) decimal(11,2),

SALES_YTD position(23:28) decimal(11,2)

)

OPTIONS Clause

The OPTIONS clause, which enables you to specify some of the run-time arguments in the control file rather than on the command line, is optional This clause is particularly useful if the length of the command line exceeds the maximum command-line length for your operating system The arguments you can include in the OPTIONS clause are described in Table 8.1 Even if you specify the arguments in the OPTIONS clause, the command-line specifications override them

Table 8.1 Control file OPTIONS clause arguments.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

Argument Description

LOAD = n Logical records to load (default all)

ERRORS = n Errors to allow before termination

ROWS = n Rows in bind array (conventional); rows between saves (direct)

BINDSIZE = n Size of bind array in bytes

SILENT = {HEADER|FEEDBACK

ERROR|DISCARDS|ALL} Messages to suppress

DIRECT = {TRUE|FALSE} Load path method

PARALLEL = {TRUE|FALSE}

Multiple concurrent sessions

When using the parallel loader, you can specify multiple input files and tables The FILE parameter specified in the OPTIONS clause becomes the global default for all INSERT INTO TABLE options clauses In addition to the OPTIONS clause for the load, each INSERT INTO TABLE clause can have an OPTIONS clause, which specifies the tablespace file where the temporary segments are created (See Listing 8.1.) If multiple input files are specified or multiple tables are being loaded, you should further qualify the options in the options section for that table

UNRECOVERABLE/RECOVERABLE Clause

These options apply only to direct path loads; all conventional loads are by definition recoverable When the database is

in archivelog mode, if RECOVERABLE is specified, the loaded data is written to the redo logs Specifying

UNRECOVERABLE bypasses writing to the redo logs, which improves performance (by about 100%) but forces you to drop and re-create the loaded data if media recovery is required

Unless you are appending data to existing data in a table, you should specify UNRECOVERABLE for performance issues If for some reason the instance needs recovery, recover it, and truncate the table(s) into which you were loading the data Then start the SQL*Loader session again

LOAD DATA Clause

The LOAD DATA clause is the main statement in the control file Only comments, the OPTIONS clause, and the

RECOVERABLE clause can precede LOAD DATA in the control file LOAD DATA is followed by phrases and

clauses that further qualify it For the complete syntax of the control file, refer to the Oracle7 Server Utilities User's Guide

The LOAD DATA clause begins with the keyword LOAD, optionally followed by the keyword DATA Note in Listing 8.3 that the keyword CHARACTERSET followed by the character set name is required if the input data file(s) is from a foreign character set, in this case EBCDIC The control file may have only one LOAD DATA clause

INFILE Clause

To specify the input file containing the data to be loaded, specify the INFILE or INDDN keyword, followed by the filename and an optional O/S-dependent file-processing specifications string Note in 8.4 that the string "FIX 28" follows the complete file pathname for a UNIX system Listing 8.4 contains some examples of file specifications from other platforms

Listing 8.5 Sample file specifications.

As a rule, use single quotes around any file specification that contains punctuation marks

If the operating system uses a single backslash to specify an escape character, then use a double backslash in directory structures

Filename specifications and the file-processing specifications string are generally not portable between platforms and may need to be rewritten if you are migrating to a different platform

Following the INFILE statement is the optional bad file specification, which begins with the keyword BADFILE or BDDN followed by the filename If no name is specified by the bad file, the name defaults to the name of the data file followed by a BAD extension A bad file is created only if records were rejected because of formatting errors, or the Oracle kernel returned an error while trying to insert records into the database

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.