Escolar Documentos
Profissional Documentos
Cultura Documentos
a physical directory on the servers file system. They contain the location of a specific operating system directory. They provide greater file management flexibility because the names of the directory objects can be used in Enterprise Manager, so you are not required to hard-code directory path specifications. Directory objects are owned by the SYS user. Directory names are unique across the database because all the directories are located in a single name space (that is, SYS).
the file locations for Data Pump because it accesses files on the server rather than on the client. In Enterprise Manager, select Administration -> Directory Objects. To edit or delete a directory object, select the directory object and click appropriate button.
SQL*Loader : Overview
tables of an Oracle database. It has a powerful data parsing engine that puts little limitation on the format of the data in the data file.
specified in the control file. From SQL*Loader perspective, the data in the data file is organized as records. A particular data file can be in fixed record format, variable record format, or stream record format. The record format can be specified in the control file with the INFILE parameter. If no record format is specified, the default is stream record format.
that SQL*Loader understands. The control file indicates to SQL*Loader where to find the data, how to parse and interpret the data, where to insert the data, and so on. Although not precisely defined, a control file can be said to have three sections:
Global options, such as the input data file name, and records
to be skipped. INFILE clauses to specify where the input data is located. Data to be loaded.
for example,
Global options, such as the input data file name, and records to be skipped. INFILE clauses to specify where the input data is located. Data to be loaded.
TABLE blocks. Each of these blocks contains information about the table (such as the table name and the columns of the table) into which the data is to be loaded. The third section is optional and, if present , contains input data.
SQL*Loader begins execution, it creates a log file. If it cannot create a log file, execution terminates. The log file contains a detailed summary of the load, including a description of any errors that occurred during the load.
Bad file :
The bad file contains the records that are rejected, either
by SQL*Loader or by the Oracle database. Data file records are rejected by SQL*Loader when the input format is invalid.
SQL*Loader, it is sent to the Oracle database fro insertion into a table as a row. If the Oracle database determines that the row is valid, then the row is inserted into the table. If the row is determined to be invalid, then the record is rejected and SQL*Loader puts it in the bad file.
if you have specified that a discard file should be enabled. The discard file contains records that are filtered out of the load because they do not match any recordselection criteria specified in the control file.
you to efficiently load large amounts of data into a database. If you have data in a flat file, such as commadelimited text file, and you need to get that data into the Oracle database, SQL * Loader is the tool to use.
comma-delimited file Load the data from the fixed width text file Load the data from a binary file Combine multiple input records into one logical record Store data from one logical record into one table or into several tables
data as it is being read from a file combine data from multiple files into one table Filter the data in the input file, loading only selected rows Collect bad records that is, those records that wont load into a separate file where you can fix them And more!
file
contain a number of commands and clauses describing the data that SQL*Loader is reading. Control files also tell SQL*Loader where to store that data , and they can define validation expressions for that data. The control file is aptly named, because it controls almost every aspect of how SQL*Loader operates. The control file describes the format of the data in the input file and tells SQL*Loader which tables and columns to populate with this data.
All of these items represent things that you specify when you write a SQL*Loader control file.
control files consist of one long command that starts out like this: LOAD DATA The keyword DATA is optional. Everything else in a control file is a clause of some sort that is added onto this command.
containing the data that you want to load. The data can be in a file separate from the control file, which is usually the case, or you can place the data within the control file itself. Use multiple INFILE clauses if your data is spread across several files. Control File Data: If you are loading the data from a text file, you have the option of placing the LOAD command at the beginning of that file, which then becomes the control file.
you need to specify whether you expect the table that you are loading to be empty. By default, SQL*Loader expects that you are loading the data in completely empty table. If, when load starts, SQL*Loader finds even one row in the table, the load will be aborted. Four keywords control SQL*Loaders behaviour when it comes do dealing with empty vs. nonempty tables:
APPEND
REPLACE
TRUNCATE
to specify which table or tables you wan to load. It also specifies the format of the data contained in the input file. The INTO TABLE clause is the most complex of all the clauses.
example: LOAD DATA INFILE 'load1.csv' INSERT INTO TABLE LOAD_TEST ( eno char terminated by ",", ename char terminated by ",", city char terminated by "," )
SQL*Loader supports a variety of data types. Some of the most useful data types for loading data from text files are given below:
Data Type Description Name CHAR Identifies the character data. If you are loading data into any type of text field, such as VARCHAR2, CHAR, or CLOB, use the SQL*Loader CHAR data type. Identifies a date. Even though its optional, specify the format to avoid problems.
DATE [format]
INTEGER Identifies an integer value that is stored in character form. EXTERNAL For ex: the character string 123 is a valid INTEGER EXTRNAL value.
(precision, Zoned decimal fields are numeric values represented as character strings and that contain an assumed decimal point. For ex., a definition of ZONED (5,2) would cause 12345 to be interpreted as 123.45.
example: LOAD DATA INFILE 'load1.csv' INSERT INTO TABLE LOAD_TEST ( eno char terminated by ",", ename char terminated by ",", city char terminated by "," )
within parenthesis. This list defines the fields being loaded from the flat file into the table. Each entry in the field list has this general format:
column_name POSITION (start:end) datatype column_name : the name of a column in the table that you are loading POSITION (start:end) : the position of the column within the record. The values for start and end represents the character positions for the first and last characters of the column. The first character of a record is always position 1.
data, is similar to that used for fixed-width data. The difference is that you need to specify the delimited being used. The general format of a delimited column definition looks like this: column_name datatype TERMINATED BY delim [OPTIONALLY ENCLOSED BY delim] The elements of this column definition are described as follows: column_name : the name of a column in the table that you are loading datatype : A SQL*Loader datatype TERMINATED BY delim : identifies the delimiter that marks the end of the column OPTIONALLY ENCLOSED BY delim : Specifies an optional enclosing character. Many text values, for example, are enclosed by quotation marks.
careful to describe them in the order in which they occur. Take a look at following record which contains delimited data:
100,1-jan-2000,23.5,Flipper seemed unusually hungry today. It can be defined as below: animal_id INTEGER EXTERNAL TERMINATED BY ,, feeding_date DATE dd-mon-yyyy TERMINATED BY ,, pounds_eaten DECIMAL EXTERNAL TERMINATED BY ,, note CHAR TERMINATED BY , OPTIONALLY ENCLOSED BY
cases where not all fields are present in each record in a data file. For example, look at two records:
100,1-jan-2000,23.5,Flipper seemed unusually hungry today. 151,1-jan-2000,55 The first record contains a note, while the second does not. SQL*Loaders default behavior is to consider the second record as an error because not all fields are present. You can changes this behavior and cause SQL*Loader to treat missing values at the end of a record as nulls, by using TRAILING NULLCOLS clause.
TRAILING NULLCOLS clause is the part of the INTO TABLE clause, and it appears as follows:
INTO TABLE animal_feeding TRAILING NULLCOLS (
values appear as blanks in data file. For ex: 100120-mar-2012good morning all 11100223-mar-2012this is demo
The first record is missing the two digit id value. If this case is not
handled, then the record will be rejected from the load. If you prefer to treat a blank field as a null, you can use the NULLIF clause to tell SQL*Loader to interpret it as null value. The NULLIF clause comes after the datatype and takes the following form:
NULLIF field_name= BLANKS e.g: cid POSITION (1:3) INTEGER EXTERNAL NULLIF cid=BLANKS,