This action might not be possible to undo. Are you sure you want to continue?
SQL*Loader loads data from external files into tables of an Oracle database. It has a powerful data parsing engine that puts little limitation on the format of the data in the datafile. You can use SQL*Loader to do the following:
y y y y y y y y y y y y y
Load data across a network. This means that you can run the SQL*Loader client on a different system from the one that is running the SQL*Loader server. Load data from multiple datafiles during the same load session. Load data into multiple tables during the same load session. Specify the character set of the data. Selectively load data (you can load records based on the records' values). Manipulate the data before loading it, using SQL functions. Generate unique sequential key values in specified columns. Use the operating system's file system to access the datafiles. Load data from disk, tape, or named pipe. Generate sophisticated error reports, which greatly aid troubleshooting. Load arbitrarily complex object-relational data. Use secondary datafiles for loading LOBs and collections. Use either conventional or direct path loading. While conventional path loading is very flexible, direct path loading provides superior loading performance. See Chapter 11.
A typical SQL*Loader session takes as input a control file, which controls the behavior of SQL*Loader, and one or more datafiles. The output of SQL*Loader is an Oracle database (where the data is loaded), a log file, a bad file, and potentially, a discard file. An example of the flow of a SQL*Loader session is shown in Figure 6-1. Figure 6-1 SQL*Loader Overview
Description of the illustration sut81088.gif
SQL*Loader is invoked when you specify the sqlldr command and, optionally, parameters that establish session characteristics. In situations where you always use the same parameters for which the values seldom change, it can be more efficient to specify parameters using the following methods, rather than on the command line:
Parameters can be grouped together in a parameter file. You could then specify the name of the parameter file on the command line using the PARFILE parameter. Certain parameters can also be specified within the SQL*Loader control file by using the OPTIONS clause.
Parameters specified on the command line override any parameter values specified in a parameter file or OPTIONS clause. See Also:
y y y
Chapter 7 for descriptions of the SQL*Loader parameters PARFILE (parameter file) OPTIONS Clause
SQL*Loader Control File
The control file is a text file written in a language that SQL*Loader understands. The control file tells SQL*Loader where to find the data, how to parse and interpret the data, where to insert the data, and more. Although not precisely defined, a control file can be said to have three sections. The first section contains session-wide information, for example:
y y y
Global options such as bindsize, rows, records to skip, and so on INFILE clauses to specify where the input data is located Data to be loaded
The second section consists of one or more INTO TABLE blocks. Each of these blocks contains information about the table into which the data is to be loaded, such as the table name and the columns of the table. The third section is optional and, if present, contains input data. Some control file syntax considerations to keep in mind are:
The syntax is free-format (statements can extend over multiple lines). It is case insensitive; however, strings enclosed in single or double quotation marks are taken literally, including case.
In control file syntax, comments extend from the two hyphens (--) that mark the beginning of the comment to the end of the line. The optional third section of the control file is interpreted as data rather than as control file syntax; consequently, comments in this section are not supported. The keywords CONSTANT and ZONE have special meaning to SQL*Loader and are therefore reserved. To avoid potential conflicts, Oracle recommends that you do not use either CONSTANT or ZONE as a name for any tables or columns. See Also: Chapter 8 for details about control file syntax and semantics
Input Data and Datafiles
SQL*Loader reads data from one or more files (or operating system equivalents of files) specified in the control file. From SQL*Loader's perspective, the data in the datafile is organized as records. A particular datafile 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. Note: If data is specified inside the control file (that is, INFILE * was specified in the control file), then the data is interpreted in the stream record format with the default record terminator.
Fixed Record Format
A file is in fixed record format when all records in a datafile are the same byte length. Although this format is the least flexible, it results in better performance than variable or stream format. Fixed format is also simple to specify. For example:
INFILE datafile_name "fix n"
This example specifies that SQL*Loader should interpret the particular datafile as being in fixed record format where every record is n bytes long. Example 6-1 shows a control file that specifies a datafile that should be interpreted in the fixed record format. The datafile in the example contains five physical records. Assuming that a period (.) indicates a space, the first physical record is [001,...cd,.] which is exactly eleven bytes (assuming a single-byte character set). The second record is [0002,fghi,\n] followed by the newline character (which is the eleventh byte), and so on. Note that newline characters are not required with the fixed record format. Note that the length is always interpreted in bytes, even if character-length semantics are in effect for the file. This is necessary because the file could contain a mix of fields, some of which are processed with character-length semantics and others which are processed with byte-length semantics. See Character-Length Semantics.
Example 6-1 Loading Data in Fixed Record Format
load data infile 'example.dat' "fix 11" into table example fields terminated by ',' optionally enclosed by '"' (col1, col2) example.dat: 001, cd, 0002,fghi, 00003,lmn, 1, "pqrs", 0005,uvwx,
Variable Record Format
A file is in variable record format when the length of each record in a character field is included at the beginning of each record in the datafile. This format provides some added flexibility over the fixed record format and a performance advantage over the stream record format. For example, you can specify a datafile that is to be interpreted as being in variable record format as follows:
INFILE "datafile_name" "var n"
In this example, n specifies the number of bytes in the record length field. If n is not specified, SQL*Loader assumes a length of 5 bytes. Specifying n larger than 40 will result in an error. Example 6-2 shows a control file specification that tells SQL*Loader to look for data in the datafile example.dat and to expect variable record format where the record length fields are 3 bytes long. The example.dat datafile consists of three physical records. The first is specified to be 009 (that is, 9) bytes long, the second is 010 bytes long (that is, 10, including a 1-byte newline), and the third is 012 bytes long (also including a 1-byte newline). Note that newline characters are not required with the variable record format. This example also assumes a single-byte character set for the datafile. The lengths are always interpreted in bytes, even if character-length semantics are in effect for the file. This is necessary because the file could contain a mix of fields, some processed with character-length semantics and others processed with byte-length semantics. See Character-Length Semantics. Example 6-2 Loading Data in Variable Record Format
load data infile 'example.dat' "var 3" into table example fields terminated by ',' optionally enclosed by '"' (col1 char(5), col2 char(7)) example.dat: 009hello,cd,010world,im, 012my,name is,
On Windows NT. you must specify it. SQL*Loader defaults to the line feed character. The use of the backslash character allows the character string to specify the nonprintable line feed character. character strings are converted to the character set of the datafile. '|\n'. Example 6-3 Loading Data in Stream Record Format load data infile 'example. then SQL*Loader uses either \n or \r\n as the record terminator. On UNIX-based platforms. This means that if you know that one or more records in your datafile has \n embedded in a field. some nonprintable characters can be specified as ('char_string') by using a backslash. Hexadecimal strings are assumed to be in the character set of the datafile. For example: y y y y y \n indicates \t indicates \f indicates \v indicates \r indicates a line feed a horizontal tab a form feed a vertical tab a carriage return If the character set specified with the NLS_LANG parameter for your session is different from the character set of the datafile.Stream Record Format A file is in stream record format when the records are not specified by size. if no terminator_string is specified. if no terminator_string is specified. instead SQL*Loader forms records by scanning for the record terminator. Stream record format is the most flexible format. This is done before SQL*Loader checks for the default record terminator. \n. The specification of a datafile to be interpreted as being in stream record format looks similar to the following: INFILE datafile_name ["str terminator_string"] The terminator_string is specified as either 'char_string' or X'hex_string' where: y y 'char_string' is X'hex_string' is a string of characters enclosed in single or double quotation marks a byte string in hexadecimal format When the terminator_string contains special (nonprintable) characters. but you want \r\n to be used as the record terminator. it should be specified as a X'hex_string'.dat' "str '|\n'" into table example fields terminated by '.' optionally enclosed by '"' . but there can be a negative effect on performance. depending on which one it finds first in the datafile. However. Example 6-3 illustrates loading data in stream record format where the terminator string is specified using a character string. so no conversion is performed.
Most control-file field specifications claim a particular part of the logical record. end. In this case.| james. Loading Combined Physical Records (see SQL*Loader Case Studies for information on how to access case studies) Data Fields Once a logical record is formed. This mapping takes the following forms: y y y y The byte position of the data field's beginning. SQL*Loader can be instructed to combine a number of physical records into a logical record. or both. This specification form is not the most flexible. The byte offset and/or the length of the data field can be specified. This way each field starts a specified number of bytes from where the last one ended and continues for a specified length. See Also: o o Assembling Logical Records from Physical Records Case study 4. according to the specified record format. the first n number of bytes of the data field contain information about how long the rest of the data field is. A delimited data field is assumed to start where the last data field ended. it is possible for a logical record to contain data that is not claimed by any control-file field specification. can be specified. but it provides high field-setting performance. Also.world. The strings delimiting (enclosing and/or terminating) a particular data field can be specified.bond.dat: hello. Length-value datatypes can be used.| Logical Records SQL*Loader organizes the input data into physical records. Field setting is a process in which SQL*Loader uses control-file field specifications to determine which parts of logical record data correspond to which control-file fields. field setting on the logical record is done. SQL*Loader can be instructed to follow one of the following logical record-forming strategies: y y Combine a fixed number of physical records to form each logical record.(col1 char(5). col2 char(7)) example. It is possible for two or more field specifications to claim the same data. Combine physical records into logical records while a certain condition is true. By default a physical record is a logical record. See Also: o Specifying the Position of a Data Field . but for added flexibility. unless the byte position of the start of the data field is specified.
because a key is not unique.bad extension. either by SQL*Loader or by the Oracle database. for example. SQL*Loader uses the field specifications in the control file to interpret the format of the datafile. SQL*Loader rejects the record. if the second enclosure delimiter is missing. The row may be invalid. If the row is determined to be invalid. it is sent to the Oracle database for insertion into a table as a row.o Specifying Delimiters Data Conversion and Datatype Specification During a conventional path load. It will have the same name as the data file. For example. stored form. Rejected records are placed in the bad file. The Oracle database accepts the data and executes the INSERT statement to store the data in the database. Discarded and Rejected Records Records read from the input file might not be inserted into the database. then SQL*Loader automatically creates one. Such records are placed in either a bad file or a discard file. because a required field is null. The Oracle database uses the datatype of the column to convert the data into its final. and populate the bind arrays that correspond to a SQL INSERT statement using that data. Keep in mind the distinction between a field in a datafile and a column in the database. If you do not specify a bad file and there are rejected records. 2. then the record is rejected and SQL*Loader puts it in the bad file. If the Oracle database determines that the row is valid. with a. Some of the possible reasons for rejection are discussed in the next sections. then the row is inserted into the table. or if a delimited field exceeds its maximum length. SQL*Loader Rejects Datafile records are rejected by SQL*Loader when the input format is invalid. parse the input data. There are two conversion steps: 1. The Bad File The bad file contains records that were rejected. See Also: y Specifying the Bad File . data fields in the datafile are converted into columns in the database (direct path loads are conceptually similar. or because the field contains invalid data for the Oracle datatype. Remember also that the field datatypes defined in a SQL*Loader control file are not the same as the column datatypes. Oracle Database Rejects After a datafile record is accepted for processing by SQL*Loader. but the implementation is different).
Conventional Path Loads. the input records are parsed according to the field specifications. including a description of any errors that occurred during the load. Thus. Loading Combined Physical Records (see SQL*Loader Case Studies for information on how to access case studies) Specifying the Discard File Log File and Logging Information When SQL*Loader begins execution.y Case study 4. the LOBFILE could not be found). You can specify the maximum number of such records that the discard file can accept. an array insert is executed. the LOB field . The discard file contains records that were filtered out of the load because they did not match any record-selection criteria specified in the control file. Direct Path Loads. it may create a file called the discard file. See Also: y y Case study 4. See Also: y y Data Loading Methods Bind Arrays and Conventional Path Loads SQL*Loader stores LOB fields after a bind array insert is done. The log file contains a detailed summary of the load. This file is created only when it is needed. and each data field is copied to its corresponding bind array. Loading Combined Physical Records (see SQL*Loader Case Studies for information on how to access case studies) The Discard File As SQL*Loader executes. execution terminates. it creates a log file. and only if you have specified that a discard file should be enabled. If it cannot create a log file. and External Table Loads SQL*Loader provides the following methods to load data: y y y Conventional Path Loads Direct Path Loads External Table Loads Conventional Path Loads During conventional path loads. if there are any errors in processing the LOB field (for example. The discard file therefore contains records that were not inserted into any table in the database. Data written to any database table is not written to the discard file. When the bind array is full (or no more data is left to read).
[Added per mail from Elaine Egolf in March 05. BEFORE and AFTER row triggers may not work as expected for LOB columns. This is not possible because the LOB contents will not have been loaded at the time the trigger fires. with data and that you want a BEFORE row trigger to examine the contents of this LOB column and derive a value to be loaded for some other column. If a datafile is big enough. C2. C1. but entails several restrictions. and builds a column array. See Also: Direct Path Load Parallel Direct Path A parallel direct path load allows multiple direct path load sessions to concurrently load the same data segments (allows intrasegment parallelism). Direct path load is much faster than conventional path load. based on its examination. This is because the triggers fire before SQL*Loader has a chance to load the LOB contents into the column. The newly formatted database blocks are written directly to the database. The load executes INSERT statements to insert the data from the datafile into the target table. Direct Path Loads A direct path load parses the input records according to the field specifications. suppose you are loading a LOB column. Parallel direct path is more restrictive than direct path. Note also that because LOB data is loaded after the array insert has been performed. converts the input field data to the column datatype. The advantages of using external table loads over conventional path and direct path loads are as follows: y y An external table load attempts to load datafiles in parallel. which creates data blocks in Oracle database block format. Note: An external table load is not supported using a named pipe on Windows NT. it will attempt to load that file in parallel. An external table load allows modification of the data being loaded by using SQL functions and PL/SQL functions as part of the INSERT statement that is used to create the external table.is left empty. See Also: Parallel Data Loading Models External Table Loads An external table load creates an external table for data that is contained in a datafile. The column array is passed to a block formatter.] . bypassing much of the data processing that normally takes place. For instance.
The case studies are based upon the Oracle demonstration database tables. Case Study 6: Loading Data Using the Direct Path Load Method . there are situations in which one method is more appropriate than the other. (In some case studies. SQL*Loader Case Studies SQL*Loader features are illustrated in a variety of case studies.Loads data using the direct path load method. Case Study 5: Loading Data into Multiple Tables . Free-Format File . emp and dept. Case Study 2: Loading Fixed-Format Fields . Case Study 8: Loading Partitioned Tables .Loads stream format records in which the fields are terminated by commas and may be enclosed by quotation marks. The following is a summary of the case studies: y y y y y y y y Case Study 1: Loading Variable-Length Data . starting with the simplest scenario and progressing in complexity. due to the different architecture of external tables and SQL*Loader. additional columns have been added. Transformations are not required on the data. so normally there is not a major performance difference for the same record format. . However. use external tables for the best load performance: y y You want to transform the data as it is being loaded into the database. The data is found at the end of the control file.Loads data from a separate datafile. You want to use transparent parallel processing without having to split the external data first. Case Study 4: Loading Combined Physical Records . in the following situations. "External Tables Concepts" Chapter 13. and the data does not need to be loaded in parallel. In the following situations. Case Study 7: Extracting Data from a Formatted Report . However.)The case studies are numbered 1 through 11. The data is found at the end of the control file.Combines multiple physical records into one logical record corresponding to one database row.Loads data into multiple tables in one run. owned by scott/tiger. "The ORACLE_LOADER Access Driver" Choosing External Tables Versus SQL*Loader The record parsing of external tables and SQL*Loader is very similar.Extracts data from a formatted report. use SQL*Loader for the best load performance: y y You want to load data remotely.See Also: y y Chapter 12.Loads partitioned tables. Case Study 3: Loading a Delimited.Loads data from stream format records with delimited fields and sequence numbers.
ctl ulcase10.dat ulcase9.ctl) Datafiles (for example.sql ulcase10.dat N/A ulcase8. Table 6-1 Case Studies and Their Related Files Case 1 2 3 4 5 6 7 .ctl ulcase5.ctl ulcas4. each case study is comprised of the following types of files: y y y Control files (for example.sql N/A ulcase3. in little-endian byte order.ctl ulcase8.ctl ulcase7. UTF16. Case Study Files Generally.Loads a customer table that has a primary key as its OID and stores order items in a VARRAY. ulcase5.sql script for that case.Loads data in the Unicode character set.sql .dat) Setup files (for example.ctl ulcase3. ulcase5. Case study 2 does not require any special set up.ctl ulcase9.sql ulcase7e.sql ulcase4.dat ulcase7. Loads an order table that has a reference to the customer table and the order items in a VARRAY. and loads multiple LOBFILEs into the emp table. This case study uses character-length semantics.sql ulcase6. Case Study 11: Loading Data in the Unicode Character Set .ctl .sql ulcase9.dat .ctl ulcase2.dat N/A ulcase4.Adds a CLOB column called resume to the table emp. They are located in the $ORACLE_HOME/rdbms/demo directory.sql) These files are installed when you install Oracle Database.dat ulcase1. so there is no . uses a FILLER field (res_file). Table 6-1 lists the files associated with each case.dat ulcase5.y y y Case Study 9: Loading LOBFILEs (CLOBs) .sql ulcase7s.dat ulcase6.sql ulcase5. If the sample data for the case study is contained within the control file.ctl N/A ulcase2.sql ulcase1.sql 8 9 10 ulcase8.ctl ulcase6. Case Study 10: REF Fields and VARRAYs .dat file for that case. Case study 7 requires that you run both a starting (setup) script and an ending (cleanup) script. ulcase5. then there will be no .
At the system prompt.Case 11 . execute the SQL script for the case study. to execute the SQL script for case study 1.dat ulcase11. start SQL*Plus and perform a select operation from the table that was loaded in the case study.log 9. Start SQL*Plus as scott/tiger by entering the following at the system prompt: 2. For example. .sql ulcase11. This is because the log file for each case study is produced when you execute the case study. sqlldr USERID=scott/tiger CONTROL=ulcase1.sql Running the Case Studies In general. Checking the Results of a Case Study To check the results of running a case study. you use the following steps to run the case studies (be sure you are in the $ORACLE_HOME/rdbms/demo directory. For example. as follows: 1. Substitute the appropriate control file name and log file name for the CONTROL and LOG parameters. The SQL prompt is displayed. 4. If you do not wish to produce a log file. This is done. provided that you use the LOG parameter. which is where the case study files are located): 1. sqlplus scott/tiger 3. Be sure to read the control file for any notes that are specific to the particular case study you are executing.ctl LOG=ulcase1. 7. enter the following: 5. as follows: 8.ctl ulcase11. Start SQL*Plus as scott/tiger by entering the following at the system prompt: 2.ctl . Case Study Log Files Log files for the case studies are not provided in the $ORACLE_HOME/rdbms/demo directory. sqlplus scott/tiger 3. omit the LOG parameter from the command line. case study 6 requires that you add DIRECT=TRUE to the SQL*Loader command line. At the SQL prompt. This prepares and populates tables for the case study and then returns you to the system prompt. invoke SQL*Loader and run the case study. SQL> @ulcase1 6.dat .
Check to make sure that your record terminator is not part of the data record. Now let us take a look at the loading some sample data to a table using command prompt and OEM interface. Just to avoid any issues with various character sets. SQL> SELECT * FROM emp. Variable Record Format and Stream Record Format. use the SELECT statement to select all rows from the table that the case study loaded. the default to the line feed character will be n and Windows uses either n or rn as the default record terminator. This format provided greater flexibility to have the data loaded compared to fixed record formatted files. you may want to check NLS_LANG parameters for your session. enter: 5. Char is enclosed in single or double quotes and hexadecimal should be used when nonprintable characters like new line feed or tab characters. please use ³sqlldr´ for the parameters and usage. . There are various options available. Stream Record Format: This format is used when the records are not in the fixed or specified size. Variable Record Format: This format is used when you have different record lengths in the data file. if the table emp was loaded. Fixed Record Format: This format is useful when you have a data file with fixed layout. 4. You can specify terminator_string either in character or hexadecimal format. Each record can be any length and records will be identified by using the record terminator.The SQL prompt is displayed. Fixed Record Format.Input Data and Datafiles. The contents of each row in the emp table will be displayed. 6. SQL*Loader . At the SQL prompt. SQL* Loader supports three different type of data files. Please note that these may change based on the operating system you are using. You will need to specify the record length in the beginning of the each record. For example. In Unix/Linux based systems. You will need to specify the ³INFILE´ parameter with the file format and additional parameters required.Loading data using OEM In this tutorial you will learn about SQL*Loader . There are few types of hex characters which can be used. SQL*Loader is useful when you need to load the files in batch mode.
(Note: If you have followed default installation with starter database.y y Log into OEM. ) Login and select Data Movement. . Oracle needs access to the host. you will have a link in Oracle menu to ³Database Control ± ³database name´. enter the server login and password. (If you have a control file already then you can use or select "Automatically Generate Control File" option). In this tutorials we are going to select the first option. y Select Load Data from user file option. then use the generated control file to load the data using command prompt. if you prefer you can check ³Save as Preferred Credentials´ otherwise leave it unchecked.
Country4 5.Country1 2.com .Step 1 .Country2 3.Country3 4.Address4. Sample Code 1.LastName3.Load Data: Data Files Here is the sample file we are going to use.Address1. FirstName2.Address2.LastName1. FirstName1.Address3.City2. Copyright exforsys. FirstName4.LastName2.City4. FirstName3.City3.LastName4.City1.
Step 2 . Table Name. Last_Name char(50).Character Delimiters Here you can change the settings. 7. 3. Copyright exforsys. 5. Address char(50). 6. CREATE TABLE customer 2. City char(50).Load Data: Table and File Format Enter Database name. In our care Field delimiter is comma and optional filed enclosure is double quotes. 4. if you need to create select ³ Create new table´ option or just enter the table name which is already there. . Sample Code 1. (First_Name char(50).com Step 3 . Country char(25)).
Load Data: Load Method .Verify the setting and click next to continue with Step 4 Step 4 .
Load Data: Schedule . select Bad file option and enter the path for the file to be generated.There are various methods you can use to load the data and it depends on the need and how much data you are loading . Keep in mind all of these paths related to the server not your local PC. Step 5 . For simplicity we are going to use Conventional path method. Step 6 . We will be discussing these methods in details later.Load Data: Options If you would like any records to written to the rejected file.
Review Verify the setting. submit job .If you would like to schedule the job to run later date. you can use this step else click next Step 7 .
dat' "STR 'rn'" . INFILE 'D:APPEXFORSYSORADATAEXFORSYSexample1. LOAD DATA 2.Click on the Job link to see the status Control file created Sample Code 1.
( 7. FIRST_NAME CHAR. COUNTRY CHAR 12. LAST_NAME CHAR.com If you see the following error during the job submission . ADDRESS CHAR. Here are few things you will need to verify Make sure service is running You will need to run the following command . INTO TABLE customer 5. FIELDS TERMINATED BY '. 10.3. 8. CITY CHAR. APPEND 4. 11. 9.' OPTIONALLY ENCLOSED BY '"' 6. ) Copyright exforsys.
return back and continue the same step again where you have received the error Login to SQL Plus to remove the data we have loaded from OEM.Logon as SYSMAN and run Sample Code 1.ctl . After you complete the above. Copyright exforsys. execute MGMT_USER. Launch Command Prompt Sample Code 1.MAKE_EM_USER(µusername¶). sqlldr username/password@dbname control=commandload.com username is the username that you are using to load the data.
FIRST_NAME CHAR.com . 8. 9. LAST_NAME CHAR. ) Copyright exforsys. CITY CHAR. INTO TABLE customer 5. 11. 10.' OPTIONALLY ENCLOSED BY '"' 6. Sample Code 1. FIELDS TERMINATED BY '. ADDRESS CHAR. APPEND 4.dat' "STR 'rn'" 3. LOAD DATA 2. INFILE 'E:oraclesqlloadercommandload.Copyright exforsys. COUNTRY CHAR 12.com Here is the copy of the control file used in the example. ( 7.
--------------------25. TABLE CUSTOMER. Discard File: none specified 10. SQL*Loader: Release 11. ALL rights reserved. INSERT OPTION IN effect FOR this TABLE: APPEND 22. . Control File: commandload. 3. 5. O(") CHARACTER 28. Path used: Conventional 19. 0 Rows not loaded because all fields were null.0. Sample Code 1. 4. O(") CHARACTER 30.----. O(") CHARACTER 26.Here is the logfile generated from the above demo.ctl 6. maximum of 256000 bytes 17. -----------------------------. COLUMN Name Position Len Term Encl Datatype 24. Number TO skip: 0 15. Oracle AND/OR its affiliates. 13. FIRST_NAME FIRST * .2. Bad File: commandload. Table CUSTOMER: 33.bad 9. Errors allowed: 50 16. 36. 31. 21. O(") CHARACTER 29.---------.1. DATA File: E:oraclesqlloadercommandload. 0 Rows not loaded due to data errors. 2009. 35.------. COUNTRY NEXT * . CITY NEXT * . LAST_NAME NEXT * . 20.0 . (Allow ALL discards) 12. 0 Rows not loaded because all WHEN clauses were failed. loaded FROM every logical record. Continuation: none specified 18. 23. O(") CHARACTER 27. Copyright (c) 1982. 34. 32. File processing OPTION string: "STR 'rn'" 8.dat 7.Production ON Sun Mar 6 13:19:31 2011 2. Bind array: 64 rows. 11. Number TO LOAD: ALL 14. 4 Rows successfully loaded. ADDRESS NEXT * .
Total logical records discarded: 46. CPU time was: 00:00:00. Total logical records read: 44. Total logical records skipped: 43. Space allocated for bind array: 82560 bytes(64 rows) 40. Run ended on Sun Mar 06 13:19:31 2011 49. 38. 47. Total logical records rejected: 45. Read buffer bytes: 1048576 41. Elapsed time was: 00:00:00.37.05 51. 50. Run began on Sun Mar 06 13:19:31 2011 48.03 ) 0 4 0 0 . 39. 42.
Figure 29-3 shows an example of user scott accessing the emp table on the remote database with the global name hq.com: Figure 29-3 Database Link .acme. but users connected to database B cannot use the same link to access data in database A. each database in the distributed system must have a unique global database name in the network domain. A database link connection is one-way in the sense that a client connected to local database A can use a link stored in database A to access information in remote database B. The global database name uniquely identifies a database server in a distributed system. If local users on database B want to access data on database A. A database link connection allows local users to access data on a remote database. This section contains the following topics: y y y y y y y y y What Are Database Links? Why Use Database Links? Global Database Names in Database Links Names for Database Links Types of Database Links Users of Database Links Creation of Database Links: Examples Schema Objects and Database Links Database Link Restrictions What Are Database Links? A database link is a pointer that defines a one-way communication path from an Oracle Database server to another database server. A database link is a connection between two physical database servers that allows a client to access them as one logical database. For this connection to occur. then they must define a link that is stored in the data dictionary of database B. The link pointer is actually defined as an entry in a data dictionary table. To access the link. you must be connected to the local database that contains the data dictionary entry.Database Links The central concept in distributed database systems is a database link.
then only the user who created the link has access. One principal difference among database links is the way that connections to a remote database occur. if Jane uses a fixed user link that connects to the hq database with the username and password scott/ tiger. . If they are private. if they are public. then she connects as scott. Users access a remote database through the following types of links: Type of Link Description Connected user link Users connect as themselves. Users connect using the username and password referenced in the link. Current user links are an aspect of Oracle Advanced Security. A local user can connect as a global user in the link context of a stored procedure. which means that they must have an account on the remote database with the same username and password as their account on the local database. without storing the global user's password in a link definition. accessing Scott's account and Scott's schema on the hq database. Fixed user link Current user A user connects as a global user. Jane can access a procedure that Scott wrote. Jane has all the privileges in hq granted to scott directly. then all database users have access. For example. and all the default roles that scott has been granted in the hq database. For example.Description of "Figure 29-3 Database Link" Database links are either private or public.
a network connection is established directly out of the shared server process in the local server. The reuse of the connection can occur if the connection was established on the same server process with the same database link. In a non-shared database link. When a user needs to establish a connection to a remote server from a particular server process. a connection is not shared across multiple sessions. the process can reuse connections already established to the remote server. When you use a shared database link in a shared server configuration. and requiring data to go through the dispatcher. For a non-shared database link on a local shared server. The link is shared because multiple client processes can use the same link simultaneously. See Also: y y Oracle Database SQL Language Reference for syntax of the CREATE DATABASE statement Oracle Database Advanced Security Administrator's Guide for information about Oracle Advanced Security What Are Shared Database Links? A shared database link is a link between a local server process and the remote database. Shared links differ from standard database links in the following ways: y y y Different users accessing the same schema object through a database link can share a network connection. either database can run in dedicated or shared server mode. this connection would have been established through the local dispatcher. When a local database is connected to a remote database through a database link. you can use it to specify schema objects in SQL statements. requiring context switches for the local dispatcher. After a link is created. The following table illustrates the possibilities: Local Database Mode Dedicated Dedicated Shared server Shared server Remote Database Mode Dedicated Shared server Dedicated Shared server A shared database link can exist in any of these four configurations. possibly in a different session.Create database links using the CREATE DATABASE LINK statement. See Also: .
a local user can access a link to a remote database without having to be a user on the remote database. assume that employees submit expense reports to Accounts Payable (A/P). The database forms a global database name by prefixing the database network domain. For example. The A/P users should not need to be hq database users to do their jobs. you must first understand what a global database name is. with the individual database name. Figure 29-4 Hierarchical Arrangement of Networked Databases . In other words.Oracle Database Net Services Administrator's Guide for information about shared server Why Use Database Links? The great advantage of database links is that they allow users to access another user's objects in a remote database so that they are bounded by the privilege set of the object owner. Each database in a distributed database is uniquely identified by its global database name. Figure 29-4 illustrates a representative hierarchical arrangement of databases throughout a network. specified by the DB_DOMAIN initialization parameter at database creation. For example. and further suppose that a user using an A/P application needs to retrieve information about employees from the hq database. The A/P users should be able to connect to the hq database and execute a stored procedure in the remote hq database that retrieves the desired information. specified by the DB_NAME initialization parameter. they should only be able to access hq information in a controlled way as limited by the procedure. See Also: y y "Users of Database Links" for an explanation of database link users "Viewing Information About Database Links" for an explanation of how to hide passwords from non-administrative users Global Database Names in Database Links To understand how a database link works.
com and uk.acme_auto.us.com each contain a sales database.europe.acme_auto. The global database name for mfg is created by concatenating the nodes in the tree as follows: y mfg. each database must have a unique global database name. For example.americas.uk.com While several databases can share an individual name.Description of "Figure 29-4 Hierarchical Arrangement of Networked Databases" The name of a database is formed by starting at the leaf of the tree and following a path to the root. the mfg database is in division3 of the acme_tools branch of the com domain.acme_auto.com See Also: "Managing Global Names in a Distributed System" to learn how to specify and change global database names Names for Database Links . The global database naming system distinguishes the sales database in the americas division from the sales database in the europe division as follows: y y sales. For example.acme_tools.com sales.division3.acme_auto.europe. the network domains us.americas.
and GLOBAL_NAMES is TRUE. For example. not the DB_DOMAIN setting in the initialization parameter file (see "Changing the Domain in a Global Database Name").com as foo. Note: Oracle recommends that you use global naming because many useful features.acme. For example. then the link name must be called hq. the following statement creates a database link in the local database to remote database sales: CREATE PUBLIC DATABASE LINK sales.com USING 'sales1'. Private User who created the link. require global naming.com. See Also: Oracle Database Reference for more information about specifying the initialization parameter GLOBAL_NAMES Types of Database Links Oracle Database lets you create private. Note that the database checks the domain part of the global database name as stored in the data dictionary. When you set the initialization parameter GLOBAL_NAMES to TRUE.acme. including Replication. the database ensures that the name of the database link is the same as the global database name of the remote database.com.Typically. database links are essentially transparent to users of a distributed database because the name of a database link is the same as the global name of the database to which the link points.oracle. If you set the initialization parameter GLOBAL_NAMES to FALSE.acme. Only the owner of a private database link or PL/SQL subprograms in the schema can use this link to access database objects in the corresponding remote database. then the database link is also called sales. public. a database link has the same name as the global database name of the remote database that it references. After you have enabled global naming.us. View ownership Creates a database-wide link. if the global database name for hq is hq. All users and PL/SQL data through views shown for subprograms in the database can use the link to .com.acme. then you are not required to use global naming. and global database links.oracle. For example. These basic link types differ according to which users are allowed access to the remote database: Type Owner Description Creates link in a specific schema of the local database. You can then name the database link whatever you want. you can name a database link to hq.division3.us. For example. View ownership data through: y y y DBA_DB_LINKS ALL_DB_LINKS USER_DB_LINKS Public User called PUBLIC.com. if the global database name of a database is sales.
global database links refer to the use of net service names from the directory server. an administrator can conveniently database link manage global database links for all databases in the system. the directory server private database links. you can database link create a single public database link for all users in a database. or subprograms within the same schema. because only the owner of the database link private link. In this document. Note: In earlier releases of Oracle Database. Determining the type of database links to employ in a distributed database depends on the specific requirements of the applications using the system. Global User called PUBLIC.Type Owner private database links. Public When many users require an access path to a remote Oracle Database. When an Oracle network data through views shown for uses a directory server. Users and PL/SQL subprograms in any database can use a global link to access objects in the corresponding remote database. Description access database objects in the corresponding remote database. The use of an Oracle Names server has been deprecated. Consider these features when making your choice: Type of Link Features Private This link is more secure than a public or global link. Global When an Oracle network uses a directory server. View ownership Creates a network-wide link. Database link management is centralized and simple. automatically create and manages global database links (as net service names) for every Oracle Database in the network. See Also: y y "Specifying Link Types" to learn how to create different types of database links "Viewing Information About Database Links" to learn how to access information about links . can use the link to access the remote database. a global database link referred to a database link that was registered with an Oracle Names server.
and the database connects to the SYSTEM schema in the remote database. accesses a public link in a query.Users of Database Links When creating the link. If a link includes a fixed user. but is any user who is accessing the link. See Oracle Database Advanced Security Administrator's Guide for information about global security Fixed user A user whose username/password is part of the link definition. The global user must be authenticated by an X. Current user A global user in a CURRENT_USER database link. you determine which user should connect to the remote database to access the data. CREATE PUBLIC DATABASE LINK hq CONNECT TO CURRENT_USER using 'hq'. CREATE PUBLIC DATABASE LINK hq CONNECT TO jane IDENTIFIED BY doe USING 'hq'. The advantage of a connected user link is that a user referencing the link connects to the remote database as the same user. If SYSTEM USING 'hq'. then the connected user is SYSTEM. Current user links are an aspect of the Oracle Advanced Security option. See Also: "Specifying Link Users" to learn how to specify users when creating links Connected User Database Links Connected user links have no connect string associated with them.509 certificate (an SSLauthenticated enterprise user) or a password (a passwordauthenticated enterprise user). and credentials don't have to be stored in the link definition in the data dictionary. The following table explains the differences among the categories of users involved in database links: Sample Link Creation Syntax User Type Description CREATE PUBLIC Connected A local user accessing a database link in which no fixed DATABASE LINK hq user username and password have been specified. Note: A connected user does not have to be the user who created the link. and be a user on both databases involved in the link. . the fixed user's username and password are used to connect to the remote database.
or externally authenticated by the operating system or a network authentication service. Also. Fixed User Database Links A benefit of a fixed user link is that it connects a user in a primary database to a remote database with the security context of the user specified in the connect string.Connected user links have some disadvantages. local user joe can create a public database link in joe's schema that specifies the fixed user scott with password tiger. then jane is the user on the local database. If jane uses the fixed user link in a query. Current User Database Links Current user database links make use of a global user. and be a user on both databases involved in the link. The ability to use a connected user database link depends on several factors. It is retained for backward compatibility only. giving users more privileges than they need violates the fundamental security concept of least privilege: users should only be given the privileges they need to perform their jobs. they require more privilege administration for administrators. The username and password are stored with other link information in data dictionary tables. Because these links require users to have accounts and privileges on the remote databases to which they are attempting to connect. For example. which is set by the REMOTE_OS_AUTHENT initialization parameter. The REMOTE_OS_AUTHENT parameter operates as follows: REMOTE_OS_AUTHENT Value TRUE for the remote Consequences An externally-authenticated user can connect to the remote database using a connected user database link. but she connects to the remote database as scott/tiger. then the ability to use a connected user link also depends on whether the remote database accepts remote authentication of users. An externally-authenticated user cannot connect to the remote database using a connected user database link unless a secure protocol or a network authentication service supported by the Oracle Advanced Security option is used. chief among them whether the user is authenticated by the database using a password. If the user is externally authenticated. A global user must be authenticated by an X. .509 certificate or a password. Fixed user links have a username and password associated with the connect string. database FALSE for the remote database Note: The REMOTE_OS_AUTHENT initialization parameter is deprecated.
or trigger that accesses a database link.p (created by scott). procedure. See Also: o "Distributed Database Security" for more information about security issues relating to database links o Oracle Database Advanced Security Administrator's Guide o Oracle Database PL/SQL Language Reference for more information about invoker-rights functions. or packages. For example. The table gives examples of SQL statements that create database links in a local database to the remote sales.us. then the invoker's authorization ID is used to connect as a remote user.acme_auto. if jane calls procedure scott.com USING 'sales_us'. then the current user is the same as the connected user accessing the link. then scott is the current user of the link. if user jane calls procedure scott. which connects her to hq as global user scott. then jane is the current user. or package. if scott issues a SELECT statement through a current user link. Note that current user database links have these consequences: y y y y If the current user database link is not accessed from within a stored object. You cannot connect to a database as an enterprise user and then use a current user link in a stored procedure that exists in a shared. For example. she can access a stored procedure to retrieve data from the hq database. For example. global schema.us. and not the user that calls the object. then the current user is scott.com database: Connects To Database Connects As sales using Connected user SQL Statement CREATE DATABASE LINK sales. and the link appears inside procedure scott. The procedure uses a current user database link.The user invoking the CURRENT_USER link does not have to be a global user.p (an invoker-rights procedure created by scott). Link Type Private connected user net service name sales_us .p. the current user is the user that owns the stored object. Creation of Database Links: Examples Create database links using the CREATE DATABASE LINK statement.americas. For example. view. When executing a stored object such as a procedure. but jane is not. User scott is a global user and authenticated through a certificate over SSL. and a current user link appears within the called procedure. procedures. if user jane accesses a stored procedure in the shared schema guest on database hq. she cannot use a current user link in this schema to log on to a remote database.acme_auto.americas. If the stored object is an invoker-rights function. For example. if jane is authenticated (not as a global user) by password to the Accounts Payable database.
com CONNECT TO scott IDENTIFIED BY tiger USING 'sales_us'.americas. You must also be authorized in the remote database to access specific remote objects. you can execute SQL statements that access objects on the remote database. you can issue: SELECT * FROM email@example.com.SQL Statement CREATE DATABASE LINK foo CONNECT TO CURRENT_USER USING 'am_sls'. Connects To Database Connects As sales using Current global Link Type Private current user service name am_sls user CREATE DATABASE LINK sales. sales using scott using net service name sales password tiger. to access remote object emp using database link foo. Naming of Schema Objects Using Database Links .com CONNECT TO scott IDENTIFIED BY tiger AUTHENTICATED BY anupam IDENTIFIED BY bhide USING 'sales'.acme_auto.us. sales using scott using net service name sales_us password tiger Private fixed user CREATE PUBLIC DATABASE LINK sales CONNECT TO scott IDENTIFIED BY tiger USING 'rev'.acme_auto.americas. Constructing properly formed object names using database links is an essential aspect of data manipulation in distributed systems. For example. sales using scott using net service name rev password tiger Public fixed user CREATE SHARED PUBLIC DATABASE LINK sales. authenticated as anupam using password bhide Shared public fixed user See Also: y y "Creating Database Links" to learn how to create link Oracle Database SQL Language Reference for information about the CREATE DATABASE LINK statement syntax Schema Objects and Database Links After you have created a database link.
unless the parameter GLOBAL_NAMES is set to FALSE. assume you issue the following query against a table in a remote database: SELECT * FROM emp@hq. If GLOBAL_NAMES is set to FALSE.division3. The database must do a SELECT * on the remote object in order to determine its structure.acme. synonym. # link name different from global name Authorization for Accessing Remote Schema Objects To access a remote schema object.acme.com. you can access the remote database as follows: SELECT name FROM scott. Then.acme. view. global_database_name is the name that uniquely identifies a remote database. firstname.lastname@example.org. This name must be the same as the concatenation of the remote database initialization parameters DB_NAME and DB_DOMAIN. along with the UPDATE. You can create the synonym emp for emp@hq. Further.dept@sales. index. using a database link to database sales. A schema is owned by a database user and has the same name as that user. schema For example. a user or application can reference remote data as follows: SELECT * FROM scott.com so that you can issue the following query instead to access the same data: .division3. INSERT.com.schema_object@global_database_name where: y y y is a collection of logical structures of data. you can call the link foo. Synonyms for Schema Objects Oracle Database lets you create synonyms so that you can hide the database link name from the user. For example.com. # emp table in scott's schema SELECT loc FROM scott. or a database link. A synonym allows access to a table on a remote database using the same syntax that you would use to access a table on a local database.com.emp@foo. you must be granted access to the remote object in the remote database. or DELETE privilege.com. or schema objects.division3. For example. Unlike when accessing a local object. in which case any name is acceptable. Each user owns a single schema. inserts.Oracle Database uses the global database name to name the schema objects globally using the following scheme: schema. the SELECT privilege is necessary for accessing a remote object because the database has no remote describe capability. to perform any updates. you must be granted the SELECT privilege on the object. package. schema_object is a logical data structure like a table. then you can use any name for the link to sales.acme. or deletes on the remote object.division3.acme.
UPDATE jane.accounts@hq. 'BOWER'. a schema object name is always unique within the database. and that within a schema each object has a unique name.SELECT * FROM emp. a query can reference a remote table by specifying its fully qualified name. INSERT INTO jane. For example.com.acme. DELETE FROM jane. See Also: "Using Synonyms to Create Location Transparency" to learn how to create synonyms for objects specified using database links Schema Object Name Resolution To resolve application references to schema objects (a process called name resolution). the database resolves application references to the local name of the object. do support DESCRIBE operations: o Tables o Views o Procedures o Functions Analyze remote objects Define or enforce referential integrity Grant roles to users in a remote database . For example. however. For example. Furthermore. The following remote email@example.com to access objects in the scott and jane schemas on remote database hq: SELECT * FROM scott. the database forms object names hierarchically.acme. Database Link Restrictions You cannot perform the following operations using database links: y y y y y Grant privileges on remote objects Execute DESCRIBE operations on some remote objects.accounts@hq. including the database in which it resides. balance) VALUES (5001.acme. acc_name. In a distributed database. The database extends the hierarchical naming model with global database names to effectively create global object names and resolve references to the schema objects in a distributed database system. the database guarantees that each schema within a database has a unique name. assume that you connect to the local database as user SYSTEM: CONNECT SYSTEM@sales1 You then issue the following statements using database link hq. As a result.com WHERE acc_name = 'BOWER'.com (acc_no. a schema object such as a table is accessible to all applications in the system.com SET balance = balance + 500.acme.acme. 2000).accounts@hq.
If all participants respond to the coordinator that they are prepared.Phase .y y y Obtain nondefault roles on a remote database. if all participants cannot prepare. password. jane receives scott's default roles on the remote database. the coordinator asks all nodes to commit the transaction. or NT native authentication 104. Jane cannot issue SET ROLE to obtain a nondefault role. the coordinator asks all nodes to roll back the transaction. Describe two phases of Two-phase commit? Prepare phase .The global coordinator (initiating node) ask a participants to prepare (to promise to commit or rollback the transaction. if jane connects to the local database and executes a stored procedure that uses a fixed user link connecting as scott. . For example. even if there is a failure) Commit . Execute hash query joins that use shared server connections Use a current user link without authentication through SSL.
10 LOOP INSERT INTO at_test (id. SELECT * FROM at_test. INSERT INTO at_test (id. we create a test table and populate it with two rows. END. DECLARE PRAGMA AUTONOMOUS_TRANSACTION.Autonomous Transactions Autonomous transactions allow you to leave the context of the calling transaction. which contains a commit statement. ID ---------1 2 DESCRIPTION -------------------------------------------------Description for 1 Description for 2 2 rows selected. 'Description for 2'). so only commited data can be shared by both transactions. description VARCHAR2(50) NOT NULL ). Local procedures and functions defined in a PL/SQL declaration block. END LOOP. we insert another 8 rows using an anonymous block declared as an autonomous transaction. ID DESCRIPTION . INSERT INTO at_test (id. The autonomous transaction has no link to the calling transaction. Packaged procedures and functions. CREATE TABLE at_test ( id NUMBER NOT NULL. The following types of PL/SQL blocks can be defined as autonomous transactions: y y y y y Stored procedures and functions. SELECT * FROM at_test. Type methods. Top-level anonymous blocks. description) VALUES (1. 'Description for 1'). / PL/SQL procedure successfully completed. The easiest way to understand autonomous transactions is to see them in action. Notice that the data is not commited.. SQL> Next. BEGIN FOR i IN 3 . perform an independant transaction. To do this. 'Description for ' || i). COMMIT. description) VALUES (i. and return to the calling transaction without affecting it's state. description) VALUES (2.
. SQL> The 2 rows inserted by our current session (transaction) have been rolled back. we now have 10 rows in the table. SELECT * FROM at_test. If we now issue a rollback statement we get the following result. For example. Autonomous transactions are commonly used by error logging routines. log_timestamp TIMESTAMP NOT NULL. so the internal commit statement did not affect the calling session. error_message VARCHAR2(4000).---------1 2 3 4 5 6 7 8 9 10 -------------------------------------------------Description for 1 Description for 2 Description for 3 Description for 4 Description for 5 Description for 6 Description for 7 Description for 8 Description for 9 Description for 10 10 rows selected. ROLLBACK. ID ---------3 4 5 6 7 8 9 10 DESCRIPTION -------------------------------------------------Description for 3 Description for 4 Description for 5 Description for 6 Description for 7 Description for 8 Description for 9 Description for 10 8 rows selected. The presence of the PRAGMA AUTONOMOUS_TRANSACTION compiler directive made the anonymous block run in its own transaction. CONSTRAINT error_logs_pk PRIMARY KEY (id) ). while the rows inserted by the autonomous transactions remain. As a result rollback was still able to affect the DML issued by the current statement. We define a procedure to log error messages as an autonomous transaction. SQL> As expected. CREATE TABLE error_logs ( id NUMBER(10) NOT NULL. CREATE SEQUENCE error_logs_seq. the following table holds basic error messages. regardless of the the commit/rollback status of the transaction. where the error messages must be preserved.
-. in 999 times out of 1000.CREATE OR REPLACE PROCEDURE log_errors (p_error_message IN VARCHAR2) AS PRAGMA AUTONOMOUS_TRANSACTION. / PL/SQL procedure successfully completed.. SELECT * FROM at_test WHERE id >= 998. which is trapped and logged. if you find yourself "forced" to use an autonomous transaction it likely means you have a serious data integrity issue you haven't thought about. here's a quote from Tom Kyte posted on my blog (here): ".Force invalid insert. 'Description for 998').107625 ORA-01400: cannot insert NULL into ("TIM_HALL".. INSERT INTO at_test (id."AT_TEST". Be careful how you use autonomous transactions. END. EXCEPTION WHEN OTHERS THEN log_errors (p_error_message => SQLERRM). SYSTIMESTAMP. END. and cause confusion when analyzing session trace. SQL> From this we can see that the LOG_ERRORS transaction was separate to the anonymous block. description) VALUES (998. NULL). ROLLBACK. If it weren't. / The following code forces an error."DESCRIPTION") 1 row selected. description) VALUES (999. no rows selected SELECT * FROM error_logs. we would expect the first insert in the anonymous block to be preserved by the commit statement in the LOG_ERRORS procedure. p_error_message). ID LOG_TIMESTAMP ---------. error_message) VALUES (error_logs_seq. COMMIT. BEGIN INSERT INTO error_logs (id.-------------------------------------------------------------------------ERROR_MESSAGE --------------------------------------------------------------------------------------------------1 28-FEB-2006 11:10:10.NEXTVAL. To hammer this point home. . BEGIN INSERT INTO at_test (id. log_timestamp. If they are used indiscriminately they can lead to deadlocks.
Ouch.not OK. that has to hurt when you rollback.Where do people try to use them? y y in that trigger that calls a procedure that commits (not an error logging routine). in that trigger that is getting the mutating table constraint." . Almost everything else . that hurts *even more* Error logging .OK. Ouch.