SQL Loader Direct Path and Nulls

I'm using Sql Loader with Direct Path and I cannot find a way to remove trailing spaces in varchar2 fields.
I'm trying to avoid updating the tables after loading.
Any ideas?

Hi Alan,
How big is this table and what sort of indexes are they?
An index update using SQL*Loader unrecoverable direct path load is achieved by an isolated sort followed by a nologging merge of the old index and the new mini-index into a new index segment (this according to seminar notes by Jonathan Lewis). This will conceivably take a long time for a large table / large index.
Performance improvements? Are you loading all records into a new partition?
Cheers,
Colin

Similar Messages

  • SQL Loader, direct path and indexes on partition tables

    Hi,
    I have a big partitioned table and I have two indexes on it.
    When I use SQL Loader to upload data to my table with using OPTIONS (DIRECT=TRUE) UNRECOVERABLE , then it takes almost half hour to load just one record!!
    When I remove OPTIONS (DIRECT=TRUE), then it takes just two seconds to upload the same one record.
    Am I missing anything? Can I use direct path load on indexed partitioned tables and have reasonable load time ?
    An scheduled external job loads almost 100,000 records into this table every hour and I am trying to make the sql*loader performance it as fast as possible.
    Any help would be appreciated,
    Alan

    Hi Alan,
    How big is this table and what sort of indexes are they?
    An index update using SQL*Loader unrecoverable direct path load is achieved by an isolated sort followed by a nologging merge of the old index and the new mini-index into a new index segment (this according to seminar notes by Jonathan Lewis). This will conceivably take a long time for a large table / large index.
    Performance improvements? Are you loading all records into a new partition?
    Cheers,
    Colin

  • SQL Loader direct path loads and unusable indexes

    sorry about all the questions. I am researching several issues. I am reading the Utilities document. It says that in certain circumstances indexes will become unusable. I have some questions about my scenario.
    1. tables partitioned by range
    2. local indexes
    3. all tables have 1 primary key and other indexes are non-unique
    4. all sql loads will go into the most recent partition
    5. users will be querying tables while sql loader is occurring
    6. only one sql loader session will run per table
    7. no foreign keys, triggers, or other constrants other than primary keys.
    The docs are not clear. Do I have a concern about unusable indexes with direct path loads? Will indexes function while the sql loader direct path is occurring(this I can't test since I have small data files now and they load fast, but I will have larger ones in production).
    My understanding is that Extertnal tables using Insert append is exactly the same as sql loader direct path load. Is this true?

    if you dont have anything productive to say how about you don't post at all? you have made ignorant posts like this for years.
    as far as reading the docs what do you think "the docs are not clear" means? By the docs I am referring to the utilities document.
    As far as version number its 10.2 and I forgot that. However, it does not appear that sql loader has really changed all that much over the last few versions.
    Finally I plan on testing it out and its more than a 2 minute test. I wanted to make sure I don't miss anythng in my tests.
    don't respond to any threads or posts I make from now on.

  • Oracle Replication and SQL*Load direct Path

    We are setting up Oracle replication and have a few tables which are loaded using SQL*Loader Direct path. I have following questions:
    1. Can MultiMaster replication replicate direct patch sqlloaded data.
    2. If the answer to the above question is no, should we set up a new snapshot replication group . All other tables are in the Multi Master replication.
    3. Another question is on the number of replication groups. How many of these we should create. We have total of about 500 tables and database size is about 450 Gig. We plan to replicate all the tables and the refresh interval we want to be one minute for all the tables. Does having more/less replication groups help??
    Thanks for your help

    We are setting up Oracle replication and have a few tables which are loaded using SQL*Loader Direct path. I have following questions:
    1. Can MultiMaster replication replicate direct patch sqlloaded data.Yes, I don't think it should matter how the table is getting updated.
    2. If the answer to the above question is no, should we set up a new snapshot replication group . All other tables are in the Multi Master replication.see above
    3. Another question is on the number of replication groups. How many of these we should create. We have total of about 500 tables and database size is about 450 Gig. We plan to replicate all the tables and the refresh interval we want to be one minute for all the tables. Does having more/less replication groups help??
    Thanks for your help I believe what Oracle recommends is that you split up your tables into replication groups transactionally. I personally have 6 replication groups supporting 700+ tables. They are broken up more by business function than by number and size.

  • Cannot get Oracle sequence to be used with SQL Loader direct path load.

    I attempted to load approximately 3 million rows from a flat file into a 10g database using SQL Loader direct path load. In order to generate a primary key for each of these rows I used a simple SQL expression which gets the next number of an Oracle sequence and assigned that to my primary key column inside the control file. The strange thing is no primary key was generated for each of these columns as I see the sequence was not advanced. Furthermore when I try to run a query to find the count on those rows which have this column as NOT NULL ,I get the total of all the rows even though on inspection this column is empty in each of the rows.
    As far as I know, in the control file for a direct path load I am able to use a SQL Expression that returns simple scalar data which a NEXTVAL on a sequence does. (Oreilly Oracle SQL Loader The Definitive Guide p.184)
    Does anybody why my primary key was not generated and furthermore why is this column in a query appear to be NOT NULL when in fact it has nothing in it?

    Daniel,
    I appreciate your response alot.
    Now a follow on. You say that SQL*Loader is the fastest way to get data into Oracle Spatial even though the conventional path. How does SQL*Loader do this? Doesn't it use OCI?
    I just can't help but think that coverting my data to SQL*Loader format, and then having it parse it and send it to the database in some form must be slower than me just sending whatever SQL Loader sends to the DB myself using OCI. Am I missing something?
    The SQL Loader documentation seems to suggest that SQL*Loader just turns the input into alot of INSERT stateemnts. If so, can't I just do this?
    My performance with OCI and INSERT statements isn't very good, but I believe I am doing one transaction per insert. Might I be as well off to concentrate on fine tuning my OCI based code using INSERTs?
    I will actually do some time tests myself, but I would appreciate your opinion.
    Once again thanks for the great info you have provided.

  • SQL Loader Direct Path issue

    Hi,
    I am trying to load data using SQL Loader Direct Path. One of the tables has a REC_UPD_DT column which is of timestamp datatype. The table was created with default value of SYSTIMESTAMP on this column. However when I load the table, the REC_UPD_DT is null due to the behavior(bypasses the sqlfunctions, etc) of the Direct Path method.
    What is the way out to achieve my objective?
    I do not want to use the conventional path since that is proven to be slow for my case.
    Thanks in advance
    Pavin

    Hi,
    My apologies for not providing requested information before. Here are the scripts:
    I am testing from my windows m/c.
    Database version: 10.2.0.3
    Table creation script:
    CREATE TABLE TXN_DEFAULT
    (MAPPER_Q_ID NUMBER(1,0) NOT NULL,
    TRANSACTION_SEQUENCE NUMBER(10,0) NOT NULL,
    RECORD_COUNT NUMBER(4,0),
    STATUS VARCHAR2(1 CHAR),
    USER_ID VARCHAR2(20 CHAR),
    USER_IP_ADDRESS VARCHAR2(35 CHAR),
    REC_UPD_DT TIMESTAMP (6) DEFAULT SYSTIMESTAMP
    Loader Control file script:
    OPTIONS (DIRECT=TRUE)
    load data
    CHARACTERSET WE8ROMAN8
    into table TXN_DEFAULT
    append
    FIELDS TERMINATED BY '     '
    trailing nullcols
    MAPPER_Q_ID,
    TRANSACTION_SEQUENCE,
    RECORD_COUNT,
    STATUS,
    USER_ID,
    USER_IP_ADDRESS,
    REC_UPD_DT     
    Sample Dat file contents:
    0     251939112     3     N     chowdsr     10.222.79.20     
    1     251939113     140     N     zhuanre     146.222.52.176     
    2     251939114     41     N     sombupo     146.222.187.155     
    0     251939116     75     N     BaseAdmin     146.222.4.246     
    Log File contents:
    SQL*Loader: Release 10.2.0.1.0 - Production on Mon Dec 7 13:22:23 2009
    Copyright (c) 1982, 2005, Oracle. All rights reserved.
    Control File: Control.ctl
    Character Set WE8ROMAN8 specified for all input.
    Data File: Control.dat
    Bad File: Control.bad
    Discard File: none specified
    (Allow all discards)
    Number to load: ALL
    Number to skip: 0
    Errors allowed: 50
    Continuation: none specified
    Path used: Direct
    Table TXN_DEFAULT, loaded from every logical record.
    Insert option in effect for this table: APPEND
    TRAILING NULLCOLS option in effect
    Column Name Position Len Term Encl Datatype
    MAPPER_Q_ID FIRST * WHT CHARACTER
    TRANSACTION_SEQUENCE NEXT * WHT CHARACTER
    RECORD_COUNT NEXT * WHT CHARACTER
    STATUS NEXT * WHT CHARACTER
    USER_ID NEXT * WHT CHARACTER
    USER_IP_ADDRESS NEXT * WHT CHARACTER
    REC_UPD_DT NEXT * WHT CHARACTER
    Table TXN_DEFAULT:
    4 Rows successfully loaded.
    0 Rows not loaded due to data errors.
    0 Rows not loaded because all WHEN clauses were failed.
    0 Rows not loaded because all fields were null.
    Bind array size not used in direct path.
    Column array rows : 5000
    Stream buffer bytes: 256000
    Read buffer bytes: 1048576
    Total logical records skipped: 0
    Total logical records read: 4
    Total logical records rejected: 0
    Total logical records discarded: 0
    Total stream buffers loaded by SQL*Loader main thread: 1
    Total stream buffers loaded by SQL*Loader load thread: 0
    Run began on Mon Dec 07 13:22:23 2009
    Run ended on Mon Dec 07 13:22:23 2009
    Elapsed time was: 00:00:00.75
    CPU time was: 00:00:00.08
    If I run using Conventional path, the REC_UPD_DT is populated with the a systimestamp value. However, this column values are null when I use the Direct path. Log files have no errors. What is the way out to achieve my objective?
    Thanks in advance.
    - Pavin

  • Sql loader direct path

    Hi All,
    Can anyone confirm whether SQL loader DIRECT path option can load in clustered tables?
    Also what is the difference between Clustered Server and Clustered Table? Will the clustered Server by default have clustered tables?

    That is 1/2 of the questions asked.
    What do you mean by clustered server? Do you mean RAC or HACMP or Veritas something else?
    What do you mean by clustered table? Do you mean like a single table hash cluster or something else?
    Please be specific ... you don't want an answer based on a guess.
    And what is 10g? Is that 10.1.0.3, or 10.2.0.1, or 10.2.0.5? Again this is computers please be precise.I am sorry. version is 10.2.0.1. its Oracle RAC. I am not sure what kind of table clustering exists. I believe its table cluster using a cluster key(what kind of table clustering is this?)
    I just want to know if sql loader direct path option can load data in Oracle RAC / Clustered tables? If not, any workaround for that?

  • Sql loader direct path leaving indexes unusuable

    10.2.0.3
    redhat 4.5
    temp tablespace 6.5 GB
    datafile size 33k
    I thought in version 10 you can do direct path loads without indexes going unusuable?
    i saw this, but we have plenty of temp space.
    http://dbasolve.com/OracleError/ora/ORA-01502.txt
    Oracle Error:
    ORA-01502 Oracle Index in Unusable State
    Cause and Solution:
    When trying to perform query on Oracle tables with select SQL statement, Oracle returns this error.
    The error indicates an attempt has been made to access an index or index partition that has been marked unusable by a direct load or by a DDL operation.
    The problem usually happens when using the Direct Path for the SQL*Loader, Direct Load or DDL operations. This requires enough temporary space to build all indexes of the table. If there is no enough space in TEMP tablespace, all rows will still be loaded and imported, but the indices are left with STATUS = 'INVALID'.
    Invalid indexes can be checked with down SQL statement.
    SQL>SELECT * from USER_INDEXES WHERE STATUS = 'INVALID';
    Solution to this error is simple. You can:
    1. Drop the specified index and/or recreate the index
    2. Rebuild the specified index
    3. Rebuild the unusable index partition
    Generally, the following SQL manipulation language will be able to rebuild the unusable index:
    SQL>ALTER INDEX index_name REBUILD online

    Hi Alan,
    How big is this table and what sort of indexes are they?
    An index update using SQL*Loader unrecoverable direct path load is achieved by an isolated sort followed by a nologging merge of the old index and the new mini-index into a new index segment (this according to seminar notes by Jonathan Lewis). This will conceivably take a long time for a large table / large index.
    Performance improvements? Are you loading all records into a new partition?
    Cheers,
    Colin

  • Loading VARRAY's with SQL loader, direct path in 9i?

    Isn't it possible to load VARRAY's with SQLloader and direct path in a Oracle 9i database?
    /Magnus Hornstrom
    mailto:[email protected]

    Daniel,
    I appreciate your response alot.
    Now a follow on. You say that SQL*Loader is the fastest way to get data into Oracle Spatial even though the conventional path. How does SQL*Loader do this? Doesn't it use OCI?
    I just can't help but think that coverting my data to SQL*Loader format, and then having it parse it and send it to the database in some form must be slower than me just sending whatever SQL Loader sends to the DB myself using OCI. Am I missing something?
    The SQL Loader documentation seems to suggest that SQL*Loader just turns the input into alot of INSERT stateemnts. If so, can't I just do this?
    My performance with OCI and INSERT statements isn't very good, but I believe I am doing one transaction per insert. Might I be as well off to concentrate on fine tuning my OCI based code using INSERTs?
    I will actually do some time tests myself, but I would appreciate your opinion.
    Once again thanks for the great info you have provided.

  • Errors when using sql loader direct path with a nvl functin on a date field

    I thought I read in 10g that all sql functions now work in direct path mode.
    the following function works without direct path mode. When we turn direct path mode on the load fails. When we take the function out in direct path mode it works.
    mydate DATE "YYYY-MM-DD" "nvl(:mydatedate,to_date('9999-01-01','YYYY-MM-DD'))"
    with direct path mode I get:
    EVERY record gets rejected with this error.
    Record 10: Rejected - Error on table MYTABLE
    ORA-00604: error occurred at recursive SQL level 1
    ORA-01861: literal does not match format string
    again works fine without direct=true, works fine with direct=true if i get rid of the function.
    any ideas?
    Message was edited by:
    Guess2
    Message was edited by:
    Guess2

    like usual your posts are completely useless daniel.
    I could have swarn that oracle advertised that you can use functions with 9i or 10g release in the new features guys or the first releases.

  • Sql Loader Direct Path Upload

    I am trying DIRECT path upload to insert data from flat file to oracle table which has some indexes.The table is used by a procedure for dml operations on another table.
    Previously,we used conventional path upload with PARALLEL=TRUE option.
    I read that DIRECT upload affects indexes,and since I use the table being populated by direct upload for some other dml operation I don't want any performance degradation to other operations in the procedure.
    How do I inspect the impact of DIRECT upload on my tables and procedure execution.
    Also,are there any other side-effects of DIRECT Path Upload.
    Any ideas?

    since I use the table being populated by direct upload for
    some other dml operationOne of the restrictions for Direct Path Loads is
    that the tables to be loaded do not have any active transactions pending.
    For other restrictions on using direct path loads and conditions causing a direct path load to leave an index in usables state see
    http://download-west.oracle.com/docs/cd/B14117_01/server.101/b10825/ldr_modes.htm#i1008815

  • SQL LOADER , EXTERNAL  TABLE and ODBS DATA SOURCE

    hello
    Can any body help loading data from dbase file .dbt to an oracle 10g table.
    I tried last day with SQL LOADER, EXTERNAL table , and ODBC data source.
    Why all of these utilities still failing to solve my problem ?
    Is there an efficient way to reach this goal ?
    Thanks in advance

    export the dbase data file to text file,
    then you have choice of using either sql loader or external table option to use.
    regards

  • Sql loader using position and functions

    Hi all, i need help loading some data in my table using sql loader. consider the following
    CREATE TABLE er
    a1 NUMBER,
    a2 number,
    a3 VARCHAR2(100),
    a4 VARCHAR2(100),
    a5 VARCHAR2(100),
    a6  VARCHAR2(100),
    a7  VARCHAR2(100),
    a8  VARCHAR2(100)
    OPTIONS (BINDSIZE=20548000, READSIZE=20548000, STREAMSIZE=20548000, DATE_CACHE=25000,  SKIP=0)
    LOAD DATA
    INTO TABLE er
    APPEND    
    TRAILING NULLCOLS
      a1            POSITION(0001:0021)               ,
      a2            POSITION(0022:0042)       "DECODE(SUBSTR(:a2,1,3),'***',NULL,:a2)"      ,
      a3            POSITION(0043:0053)       ,
      a4            POSITION(0054:0064)          ,
      a5            POSITION(0065:0075)           ,
      a6            POSITION(0076:0086)       ,
      a7            POSITION(0087:0093)      "DECODE(SUBSTR(:a7,1,3),'***',NULL,:a7)"  
    BEGIN
                     0.00 ******************** X          X          X          *X          ****
    END;if you look at the data, some fields have a lot of * and some has af few such as ****. i want to load this data into a table and when a field contain all * as a value, i want to set it to null. if a field contain a * and alphanumeric then that value should be load as it is.
    in the example above, ******************** should be set to null and **** should also be set to null. notice that there is a field with X. since this field contain alpha numeric, it should be loaded into the table as is.  the only time field should be set to null is when the value contain all .
    somebody in this forum suggest using decode but it looks like it is not working and i get error when it reads second field and try to insert into a2 number column.
    is there any way to use regular expression to find out if a field contain all *. also i want to trim each field since they might contain leading spaces.
    can some one help with this using the sqlloader ctl and data above?

    You can include regular expression in you SQL*Loader control file.
    An example can be found here:
    http://www.morganslibrary.org/reference/sqlloader.html
    Demos 7 and 8 using the UPPER and DECODE functions to illustrate how to do it.

  • SQL Loader, nested tables and default values

    Is there a way to specify a default value for a nested table entry when SQL*Loader encounters a 'null' value?
    I want to avoid this:
    Record 5: Rejected - Error on table LEVEL_DESC, column LEVELS.
    NULL nested table element is not allowed

    Use the NULLIF parameter in your control file for the nested table objects.
    e.g
    LOAD DATA
    INFILE 'level_data.dat'
    INTO TABLE LEVEL
    (LEVEL_ID POSITION (01:05) CHAR
    LEVEL_NAME POSITION (07:20)
    LEVEL_DESC COLUMN OBJECT
    (LEVELS POSITION (22:25) CHAR NULLIF LEVEL_DESC.LEVELS=BLNAKS,
    ... ))

  • Executing sqlldr (sql loader) from java and returning the error code

    I'm wandering do sqlldr return any error code whenever it hit error while running in java.
    For example, if i run in command prompt using the command below,
    C:\ >sqlldr uid/pwd data=abc.dat control=abc.txt
    It might give me some indicator that error occurs such as
    SQL*Loader-601: For INSERT option, table must be empty. Error on table CURRENCY
    or
    SQL*Loader-500: Unable to open file (abc.txt)
    SQL*Loader-553: file not found
    SQL*Loader-509: System error: The system cannot find the file specified.
    But when i run in java using the code below,
    Runtime rt = Runtime.getRuntime();
    Process proc = rt.exec("sqlldr uid/pwd data=abc.dat control=abc.txt");
    int exitVal = proc.waitFor();
    System.out.println("Process exitValue: " + exitVal);
    it will only give me the same exitValue of 1(i presume its error) / 0 (i presume no error) instead of the details of the error.
    How can i get the exact error code/message if i were to execute it using java?
    Any solution?

    mg,
    I don't think user576271 wants the exit code, I think [s]he wants the error message.
    But wouldn't error messages from SQL*Loader be sent to the stderr stream, and not the stdout stream?
    In which case user576271 would need method "getErrorStream()" of class java.lang.Process, no?
    Good Luck,
    Avi.

Maybe you are looking for