Direct-Load INSERT

Can I use two select statement in Direct-Load INSERT;
I have one table test with
NO NUMBER
NAME VARCHAR2(20)
Columns
I would like insert in no column by SEQUENCE & one from another
table.
Can anybody tell me HOW?
Regards, Chaitanya

If you do not really care what the sequence is, you can do
something like
INSERT INTO table1 (numbercol,othercol)
SELECT rownum,othercol2
FROM table2;

Similar Messages

  • Direct load insert  vs direct path insert vs nologging

    Hello. I am trying to load data from table A(only 4 columns) to table B. Table B is new. I have 25 million records in table A. I have debating between direct load insert,, direct path insert and nologging. What is the diference between the three methods of data load? What is the best approach??

    Hello,
    The fastest way to move data from Table A to Table B is by using direct path insert with no-logging option turned on table B. Meaning this will be produce minimum logging and in case of DR you might not be able to recover data in table B. Now Direct path insert is equivalence of loading data from flat using direct load method. Generally using conventional method it's six phases to move your data from source (table, flat file) to target (table). But with direct path/load it will cut down to 3, and if in addition you will use PARALLEL hint on select and insert you might have faster result.
    INSERT /*+ APPEND */ INTO TABLE_B SELECT * from TABLE_A;Regards
    Correction to select statement
    Edited by: OrionNet on Feb 19, 2009 11:28 PM

  • Direct load insert internals

    Hi,
    I usually posts threads regarding the internals of oracle. today the topic is direct load inserts.
    Here is the mains concept
    in direct load insert oracle by pass the buffer cache and inserts in directly into the data file. By by passing the buffer cache oracle avoid redo log generation and other over head. oracle builds a block in the memory and inserts it into the data file above the high water mark.
    here are the questions
    where does oracle builds the data block in memory is it in server process PGA.
    does oracle builds more than one data blocks
    does increasing the size of PGA memory can have any effect on direct load inserts.
    if oracle by pass buffer cache than rollback segament are still generated. What its mechanism under direct load inserts
    regards
    Nick

    Nick Naughty wrote:
    from above document. it seems that oracle streams and array size play an important role in performance but the above document is regarding sql loader what about this statementFor SQL Loader...only
    insert /*+ append */ into dest_table
    select * from source_table;
    here we could not set oracle stream or array size a mentioned in above document. kindly elobrate with respect to above statement. Does not apply.
    Perhaps you could explain what you are trying to do, or add some context of the problem. This would aid with responses.
    Regards,
    Greg Rahn
    http://structureddata.org

  • Direct Load Insert problem

    Hello,
    we want to make bulk insert in C++ faster by avoiding generating redo logs. I plan to use Direct Load Insert. The problem is, DLI works only on insert /*+ APPEND */ into .. select ... but not with 'values' clause. To get rid of this, I want to bulk insert the rows into a temporary table, and than, at the end of the transaction, issue an insert /*+ APPEND */ into target_tab select * from temp_tab. After truncate temp_tab, I commit the transaction.
    I know, REDO will be generated on the UNDO, but inserts generate only very low UNDO. By the way, can I avoid generating UNDO for temp tables?
    What do you think about this? Any oppinion? Will it be really faster? Do you have any other idea?
    Thank you,
    Balazs

    There is no hint call "NOLOGGING".So /*+ APPEND NOLOGGING */ will be ignored in your case.You may be better performance ,if you do it this way..
    1) Create temp_tab with required columns matching target table. using CTAS method.
    Create table temp_tab
    tablespace <TS_name>
    storage( ..................)
    PCTFREE 0
    NOLOGGING
    as
    select /*+ PARALLE(a,4) */ col1,col2,col3.....
    from soruce_table a;
    Comments: Above operation will be with NO REDO and NO UNDO. I used PCTFREE 0 to pack as many rows in the block,so that it helps in querying the temp_tab table in next steps.
    2) Load the data into target table .Using parallel direct load , instead of serial-Direct load ( /*+ APPEND */ )
    sql > alter session enable parallel dml;
    sql > INSERT /*+ PARALLEL(a,4) */ INTO target_table a
    SELECT /*+ PARALLEL(b,4) */ from temp_tab b;
    sql>commit;
    To give to some benchmarks , a 14 GB table is loaded with above method within 9 minutes on 12cpus busy unixbox.
    Note : Check the other effect of parallel direct load in 8i concept

  • Direct-load Insert. ORA-00907: missing right parenthesis

    Hi All,
    i created one dummy table with two character columns
    im trying to insert values like this.
    insert into dummy select ('x','y') from dual;
    the error is
    ERROR at line 1:
    ORA-00907: missing right parenthesis
    Thanks in advance

    SQL> insert into dummy1 select 'x','y' from dual;
    1 row created.
    SQL> select * from dummy1;
    COL1 COL2
    x y
    Regards,
    Sanju

  • Direct Load Inserts (contd...)

    Hello Mr.Justin,
    Okk...I need to give u the complete scenario then.
    I have an application (lets call it as Version1). Its accessing Oracle Database. Now There is an upgradation to the application (Now it becomes version 2). There are some design changes. (Hope this is not a mistake ..right ?). but the database, as you know is critical. so we need to take data from the older version and port it into the new version, so that the new application with enhanced features can work. (The databases are same. Oracle and the versions are also same). I am triggering this migraion through PL/SQL procedures.
    My problem is it takes lot of time (for 70 gigs). Can you give me some solution.
    Regards,
    Ravi

    Yup. It finds the HWM and writes beyond it and resets the HVM at the end of the write. That is one of the reasons why it is so fast.

  • Insert /*+ Append */ and direct-path INSERT

    Hi Guys
    Does insert /*+ Append */ into hint cause Oracle 10G to use direct-path INSERT?
    and if insert /*+ Append */ into hint does cause Oracle to use direct-path INSERT, does insert /*+ Append */ is subject to the same restrictions as direct-path such as "The target table cannot have any triggers or referential integrity constraints defined on it."
    Thanks

    Dear,
    Here below a simple example showing the effet of existing trigger on the append hint
    mhouri@mhouri> select * from v$version where rownum=1;
    BANNER                                                                         
    Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production         
    mhouri@mhouri> create table b as select * from all_objects where 1 = 2;
    Table créée.
    mhouri@mhouri> insert /*+ append */ into b
      2  select * from all_objects;
    70986 ligne(s) créée(s).
    mhouri@mhouri> select * from b;
    select * from b
    ERREUR à la ligne 1 :
    ORA-12838: impossible de lire/modifier un objet après modification en parallèle
    mhouri@mhouri> rollback;
    Annulation (rollback) effectuée.The direct path took place as far as I can't select from the table before I commit
    mhouri@mhouri> create trigger b_trg before insert on b
      2  for each row
      3  begin
      4  null;
      5  end;
      6  /
    Déclencheur créé.
    mhouri@mhouri> insert /*+ append */ into b
      2  select * from all_objects;
    70987 ligne(s) créée(s).
    424 ligne(s) sélectionnée(s).
    mhouri@mhouri> select count(1) from b;
      COUNT(1)                                                                     
         70987                                                                      While in the presence of this trigger on the table, the append hint has been silently ignored by Oracle. The fact that I can select from the table immediately afte the insert has finished is the indication that the table has not be inserted using direct path load
    Best Regards
    Mohamed Houri

  • Direct path insert

    Hi Friends,
    If i used direct path insert from a (LAN) remote table with 5 million rows using:
    sql> insert /*+ append */ into EMP using select * from EMP@dblink1;
    1) Do i need to create big rollback segment?
    *Note that in direct path sqlloader, no big rollback is needed.
    2.) Can i still undo it or rollback it the 5 millions rows?
    If i can then it sure holds or need a big rollback segment.
    Thanks a lot
    Message was edited by:
    [email protected]

    From same link see below points from Tom
    b) a direct path load always loads above the high water mark, since it is formatting and writing blocks directly to disk - it cannot reuse any existing space. Think about this - if you direct pathed an insert of a 100 byte row that loaded say just two rows - and you did that 1,000 times, you would be using at least 1,000 blocks (never reuse any existing space) - each with two rows. Now, if you did that using a conventional path insert - you would get about 70/80 rows per block in an 8k block database. You would use about 15 blocks. Which would you prefer?+
    c) you cannot query a table after direct pathing into it until you commit.+
    See point c. So, this will mark block header transaction flag to commit. if you rollback as they are written above HWM and since there is no commit flag yet it just need to set table HWM to original one and that's it.

  • Direct Path Insert on Forms

    Hi,
    I am using following insert statement on my forms application to do direct path insert.
    insert into /*+append*/ abc select * from xyz;
    as redo is not generated if you do direct path insert but in above case redo is generating for the above insert statement.
    I then created a procedure test_insert as below
    create procedure test_insert is
    begin
    insert into /*+append*/ abc select * from xyz;
    end;
    i then replaced the insert statement with above procedure on form and after that redo for the insert statement stopped.
    i was wondering if we could use append hint for direct path insert on forms?

    My point, though, is that if you're doing your hourly load into a separate table and building the index(es) on that table before moving the partition into the partitioned table, there is no risk of doing anything to screw up the partitioned table. It's also a very handy way to ensure that your load process doesn't interfere with your production data.
    If i have understood your point right, what about the space required ( tablespaces and the indexes). Trust me, my table at source gets populated @ over 230 MIL records /day. If i have a temp table, i will have to maintain hourly partitions/indexes/tablespaces for the temp table to hold so much data, isn't it? And, the data i move (say today's data) will be used by the user only after 4 days (because it is available in the source). We have provisioned our user interface to connect to 2 databases, one with 5 days of data (incl. sysdate) and the other one is a archive DB that holds 45 days worth of data.
    </>
    I wouldn't expect that a direct path load into a single partition of a partitioned table would invalidate local indexes on other partitions, but since I'd never do a direct path load into a single partition of a partitioned table, I've not tested this to make sure.
    No problem, if i try this out i will share it in the forum. </>Thanks

  • Regarding Direct Load or Direct Path Load

    Why Direct Load and Direct Path Load is faster?
    In which situation Direct Load, Direct Path Load are faster?

    >
    Why Direct Load and Direct Path Load is faster?
    In which situation Direct Load, Direct Path Load are faster?
    >
    See About Direct-Path INSERT in the DBA doc
    http://docs.oracle.com/cd/E11882_01/server.112/e17120/tables004.htm#i1009100
    >
    About Direct-Path INSERT
    Oracle Database inserts data into a table in one of two ways:
    •During conventional INSERT operations, the database reuses free space in the table, interleaving newly inserted data with existing data. During such operations, the database also maintains referential integrity constraints.
    •During direct-path INSERT operations, the database appends the inserted data after existing data in the table. Data is written directly into datafiles, bypassing the buffer cache. Free space in the table is not reused, and referential integrity constraints are ignored. Direct-path INSERT can perform significantly better than conventional insert.

  • How can I tell if direct-path insert is really being used?

    I have a number of INSERT statements with /*+ APPEND */ hints, that I suspect are not using direct-path insert processing. How can I tell (via the plan, via Enterprise Manager, whatever) if direct-path is being used?
    If it is not being used, then I can research why that might be, and try to resolve the obstacles there. But if it is being used, then I want to know that so I can focus elsewhere.
    Thanks,
    Mike

    mtefft wrote:
    The question of whether direct-path is possible with multi-table inserts has been on my mind...
    Moreover, in another forum post, we have eyewitnesses that it has happened at least once:
    APPEND Hint in Multi-table insert
    So I think that post (giving examples of Explain plans with multi-table inserts successfully using direct-path) answers my question.
    Mike,
    Thanks for that link. When I checked my example again I realised that it had a foreign key constraint between the two tables I was inserting into. (It was a demonstration of how to normalise an incoming denormalised address table, so converted a flat table into address/address lines). When I removed the constraint I got the multi-table insert.
    However, I followed this up with a check on the execution plans and for the 10.2.0.3 I was running noted the following:
    Plan reported after running the insert and select from dbms_xplan.display_cursor()
    | Id  | Operation           | Name | Rows  | Bytes | Cost  |
    |   0 | INSERT STATEMENT    |      |       |       |    30 |
    |   1 |  MULTI-TABLE INSERT |      |       |       |       |
    |   2 |   TABLE ACCESS FULL | T3   | 10000 |  1240K|    30 |
    ------------------------------------------------------------Plan reported after explain plan / select from dbms_xplan.display()
    | Id  | Operation           | Name | Rows  | Bytes | Cost  |
    |   0 | INSERT STATEMENT    |      | 10000 |  1240K|    30 |
    |   1 |  MULTI-TABLE INSERT |      |       |       |       |
    |   2 |   DIRECT LOAD INTO  | T1   |       |       |       |
    |   3 |   DIRECT LOAD INTO  | T2   |       |       |       |
    |   4 |    TABLE ACCESS FULL| T3   | 10000 |  1240K|    30 |
    ------------------------------------------------------------If you try to check for direct path inserts by looking at the in-memory plans, you might not see the direct load that is really happening. (Perhaps the a check that both / all the target tables are locked with TM mode 6 may give you a clue.)
    Regards
    Jonathan Lewis

  • DIRECT LOAD

    I have few questions in direct path data load.
    I have below questions When we load direct path in sqlloader or use
    APPEND hint in INSERT statement,
    1. Does primary key/UNDIQUE INDEX/UNIQUE KEY disable during the direct load?
    I know, check constraint and FK constraints are disabled. I am not sure about
    other keys.
    2. During the direct path load, does table have lock(exclusive lock)? if so,
    others can not apply INSERT/UPDATE/DELETE on the table during the Direct load.
    Please clarify?
    3. During the direct path load, i believe, the indexes are disabled or unusable?.
    Is that true?? Please clarify.

    This is the original file before the load
    100,Stévén,Kíng
    101,Nééná,Kóchhár
    102,Léx,Dé Háán
    103,áléxándér,Húnóld
    104,Brúcé,érnst
    105,Dávíd,áústín
    106,Vállí,Pátábállá
    107,Díáná,Lóréntz
    Character conversion after the load:
    EMPLOYEE_ID LAST_NAME                 FIRST_NAME
            100 StΘvΘn                    Kφng
            101 NΘΘnß                     K≤chhßr
            102 LΘx                       DΘ Hßßn
            103 ßlΘxßndΘr                 H·n≤ld
            104 Br·cΘ                     Θrnst
            105 Dßvφd                     ß·stφn
            106 Vßllφ                     Pßtßbßllß
            107 Dφßnß                     L≤rΘntz
    ...

  • Direct load with Force Logging enable

    Hi All,
    I have a dataguard environment with one physical standby database, I have to load a big flat file with close to 50Millions records using sqlldr. can i use direct=true in sqlldr,with force logging enabled on primary? or they is any other way to load this file
    FYI- ORACLE 11GR2
    Thanks

    Thanks for that information.
    The direct=true means what you think, Loaded data will not be replicated. However its make sense and your test proves that Data Guard overrides this.
    based on this you might as well go conventional path.
    Does this help?
    Its makes sense that Data Guard would override this, otherwise Data Guard would (or Forced logging) would not be doing its job.
    From Oracle doc A96524-01 Database Concepts 19 Direct-Path INSERT
    If the database or tablespace is in FORCE LOGGING mode, then direct path INSERT always logs, regardless of the logging or nologging setting.
    I know this an older doc, but its unlikely this would have changed

  • While using direct load whether trigger get fired

    1. While using direct load whether trigger get fired?
    2. Is it possible to log the errors with triggers if any event get failed?
    Say for example am have a trigger audit  with insert event on a table A.
    is it possible to have any error table to monitor when the event get failed. Like the audit table or else track the failure operation with  the audit trigger.

    1. While using direct load whether trigger get fired?
    Oracle doesn't use direct-path INSERT if the target table has any triggers or referential constraints.
    See the SQL Language doc:
    http://docs.oracle.com/cd/E11882_01/server.112/e26088/statements_9014.htm
      The target table cannot have any triggers or referential integrity constraints defined on it.
    So you would not be using direct-path if the table has any triggers.
    2. Is it possible to log the errors with triggers if any event get failed?
    Say for example am have a trigger audit  with insert event on a table A.
    is it possible to have any error table to monitor when the event get failed. Like the audit table or else track the failure operation with  the audit trigger.
    Yes and No - DML Error logging can put rejected rows into an error table so that the entire INSERT will not get rolled back.
    But some datatypes are not supported and there are other restrictions also:
    See the SQL Language doc
    http://docs.oracle.com/cd/E18283_01/server.112/e17118/statements_9014.htm#SQLRF55101
    Restrictions on DML Error Logging
      The following conditions cause the statement to fail and roll back without invoking the error logging capability: 
    Violated deferred constraints.
      Any direct-path INSERT or MERGE operation that raises a unique constraint or index violation.
      Any update operation UPDATE or MERGE that raises a unique constraint or index violation.
      You cannot track errors in the error logging table for LONG, LOB, or object type columns. However, the table that is the target of the DML operation can contain these types of columns. 
    If you create or modify the corresponding error logging table so that it contains a column of an unsupported type, and if the name of that column corresponds to an unsupported column in the target DML table, then the DML statement fails at parse time.
      If the error logging table does not contain any unsupported column types, then all DML errors are logged until the reject limit of errors is reached. For rows on which errors occur, column values with corresponding columns in the error logging table are logged along with the control information.
    See also the direct-path and dml error logging sections of the DBA guide
    http://docs.oracle.com/cd/E18283_01/server.112/e17120/tables004.htm#InsertDMLErrorLogging

  • Direct load vs nologging

    Hi all,
    I have a insert .... select statement and i am using append hint to enforce direct load.
    Is it same as the statement without hint on nologging table.
    Thanks in advance.
    Jaggy

    If you use insert with append hint, there won't be redo logs amount will be minimal. Of course I don't calculate redo logs generated by indexes. Any index on the table affected by the load will produce logs which requires time. If you want to speed up this process then make indexes on the affected table unusable and rebuild them after the load is done.
    If you use insert into without HINT on nologging table, then it is totally different because it is not an direct load method. Redo logs will be generated for the table and all indexes. This option will be much slower.
    If you have nologging enabled than it redo logs won't be generated only if you use direct path load (using append hint or import utility)

Maybe you are looking for