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

Similar Messages

  • Direct Path Inserts = By DBWR or by Shadow Process

    Hello guys,
    if i use the append hint (direct path inserts) - which process is writting the data to the datafile?
    In the documentation of oracle:
    http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96524/c21dlins.htm#10778
    Oracle appends the inserted data after existing data in the table. Data is written directly into datafiles, bypassing the buffer cache Ok that is clear - but who is writing down the data? The shadow process which is handling the insert statement or is it given to the dbwr and it flushes the data directly to the datatfile without putting it into the buffer cache.
    And another question regarding direct path inserts:
    http://sai-oracle.blogspot.com/2006/03/parallel-query-is-it-good-or-bad.html
    If you want to do direct path insert in parallel, you would block all other non direct path insert operations on that table. This is because direct path insert would append above highwater mark, and no other process is allowed to update HWM until your operation is doneIf i insert data in serial with direct path insert... i also write data behind the High-HWM .. why is it only locked in parallel mode?
    And why does oracle not check if there is enough space in some other blocks below the High-HWM and using these blocks for "normal" inserts?
    Regards
    Stefan

    It's the server process that's responsible for writing direct path blocks to disk.
    DBWR only ever flushes out of the buffer cache.
    You do NOT write "data behind the HWM" in direct path mode, ever. Direct path works so fast because all you do is slam whole blocks of data onto disk ABOVE the high water mark. You can slam whole blocks down without worrying about what you're over-writing precisely because the blocks are above the HWM and thus cannot possibly be in use by anyone for anything. Under the HWM and you have to start worrying about locking and contention and stuff like that.
    Parallel operations (or simultaneous serial operations by two different users) inevitably have to block each other for this sort of thing: if I am busy writing to blocks above the HWM, great. But if you want to do it too... well, what's to stop us from over-writing each other's blocks?! Nothing, actually. So Oracle simply has to lock the entire table from any other direct path operation to make the situation manageable.

  • 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.

  • Forcing DIRECT PATH INSERT to go CONVENTIONAL.

    According to Oracle, to force a statement to avoid using DIRECT-PATH insert it must fall into the following:
    Direct-path INSERT is subject to a number of restrictions. If any of these restrictions is violated, then Oracle Database executes conventional INSERT serially without returning any message, unless otherwise noted:
        *     You can have multiple direct-path INSERT statements in a single transaction, with or without other DML statements. However, after one DML statement alters a particular table, partition, or index, no other DML statement in the transaction can access that table, partition, or index.
        *      Queries that access the same table, partition, or index are allowed before the direct-path INSERT statement, but not after it.
        *      If any serial or parallel statement attempts to access a table that has already been modified by a direct-path INSERT in the same transaction, then the database returns an error and rejects the statement.
        *      The target table cannot be part of a cluster.
        *      The target table cannot contain object type columns.
        *      Direct-path INSERT is not supported for an index-organized table (IOT) if it is not partitioned, if it has a mapping table, or if it is reference by a materialized view.
        *      Direct-path INSERT into a single partition of an index-organized table (IOT), or into a partitioned IOT with only one partition, will be done serially, even if the IOT was created in parallel mode or you specify the APPEND hint. However, direct-path INSERT operations into a partitioned IOT will honor parallel mode as long as the partition-extended name is not used and the IOT has more than one partition.
        *      The target table cannot have any triggers or referential integrity constraints defined on it.
        *      The target table cannot be replicated.
        *      A transaction containing a direct-path INSERT statement cannot be or become distributed.Are there any others that are not documented here? We have a vendor based app and want to avoid the DIRECT PATH INSERT and have it go CONVENTIONAL. We tried the TRIGGER approach, but that did not help at all.

    Why are you wanting to force conventional ?
    Are you sure the application uses direct path ?

  • Archive log / nologging/ direct path insert

    Could you please confirm if following are true or correct me if my understanding is wrong:
    1 ) Archive log mode and LOGGING is needed to deal with media recovery; it was not needed for instance recovery.
    2) IF insert is in NO APPEND mode , redo is generated even if table is in nologging mode and database is in noachive log mode. This redo is needed for instance recovery.
    3) Direct path insert skips undo generation and may skip redo generation if the object is in nologging mode.
    Thanks.
    In case if it is relevant , I am using Oracle 11.2.0.3.

    1) Yes, Archive logs are needed for media recovery.
    2 and 3) Even if the table is in nologging mode , it generates little bit of redo for index maintenance and dictionary data. Upon a restart from a failure - Oracle will read the online redo logs and replay any transaction it finds in there. That is the "roll forward" bit. The binary redo information is used to replay everything that did not get written to the datafiles. This replay included regenerating the UNDO information (UNDO is protected by redo).
    After the redo has been applied, the database is typically available for use now - and the rollback phase begins. For any transaction that was being processed when the instance failed - we need to undo its changes, roll it back. We do that by processing the undo for all uncommitted transactions.
    The database is now fully recovered.
    Also read he following link
    http://docs.oracle.com/cd/B19306_01/server.102/b14220/startup.htm
    http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:5280714813869

  • 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

  • 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 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 path read caused by direct path insert?

    Oracle 9.2
    ========
    Consider this INSERT statement
    INSERT /*+ APPEND USE_HASH*/ INTO schema.tablename (...)
    SELECT * FROM view_tablename;
    This statement takes about 30 minutes to complete.
    If I look at the v$session_wait, I can see that the session waits denoting db file scattered read (which is understandable). However, at the very end of the 30-minute wait, the v$session_wait view shows that it is waiting denoting direct path read. I want to understand how can a direct path INSERT (or for that matter a simple INSERT statement) can cause a direct path read wait. Can you show me some doc which expalain this in more detail than Oracle doc? Thanks in advance.

    Hmm....ok, well,first, there's a problem w/ the hint specification.
    The USE_HASH hint makes no sense as a hint to the insert statement. It only makes sense in the context of a select statement. Also, it should specify a table alias. So, you could have something like:
    insert /*+ APPEND */.into some_tab
    select /*+ use_hash(tab_alias) */ col1,col2,col3 from .....
    Now, as to the question of direct path read:
    The direct path read event indicates a disk sort. So, it's likely the source of the direct path read wait was due to sorting in the processing of the select statement. I can't imagine how the insert would cause direct path read.
    Hope that helps,
    -Mark

  • Nologging direct-path insert into an indexed table

    Hello,
    Does anyone have an idea how I can suppress generation of undo logs for direct-path insert into an indexed table on 11.2.0.1.0:
    CREATE TABLE TBL(ID NUMBER) NOLOGGING;
    CREATE INDEX IDX ON TBL(ID) NOLOGGING;
    INSERT /*+ APPEND */ INTO TBL SELECT /*+ APPEND */ ROWNUM FROM ...; -- Source table has 400,000,000+ rows
    Regards,
    Angel Tsankov

    Pl do not post duplicates - Why does Oracle not use direct-path insert when instructed to do so - pl continue the discussion in your original thread

  • A lot of messages "direct path write temp" and "direct path read temp"

    Hello, all
    Please, understand me, what is going on in my system (DB: Oracle database 11.2.0.3, OS: Windows 2008 R2).
    In AWR report (1 hour) I see next:
    Foreground Wait Events
                                                                 Avg               
                                            %Time Total Wait    wait    Waits   % DB
    Event                             Waits -outs   Time (s)    (ms)     /txn   time
    direct path write temp          132,627     0      1,056       8      0.8   21.7
    direct path read temp           308,969     0        565       2      2.0   11.6
    log file sync                    19,228     0        241      13      0.1    5.0
    direct path write                17,698     0        135       8      0.1    2.8
    db file sequential read          21,149     0         94       4      0.1    1.9
    SQL*Net message from dblin           59     0          5      86      0.0     .1
    Segments by Direct Physical Reads         DB/Inst: SGRE/sgre  Snaps: 1039-1040
    -> Total Direct Physical Reads:         392,273
    -> Captured Segments account for   94.7% of Total
               Tablespace                      Subobject  Obj.        Direct       
    Owner         Name    Object Name            Name     Type         Reads  %Total
    ** MISSING TEMP       ** TRANSIENT: 437734 MISSING ** UNDEF       38,290    9.76
    DBSNMP     TEMP       MGMT_TEMPT_SQL                  TABLE       38,242    9.75
    ** MISSING TEMP       ** TRANSIENT: 438784 MISSING ** UNDEF       37,790    9.63
    ** MISSING TEMP       ** TRANSIENT: 437312 MISSING ** UNDEF       37,661    9.60
    ** MISSING TEMP       ** TRANSIENT: 439257 MISSING ** UNDEF       37,477    9.55Some selects:
    SELECT   S.sid,
             T.blocks * TBS.block_size / 1024 / 1024 mb_used, T.tablespace, T.SEGTYPE
    FROM     v$sort_usage T, v$session S, v$sqlarea Q, dba_tablespaces TBS
    WHERE    T.session_addr = S.saddr
    AND      T.sqladdr = Q.address (+)
    AND      T.tablespace = TBS.tablespace_name
    AND      S.sid = 732
    ORDER BY S.username, S.sid;
    SID     MB_USED     TABLESPACE     SEGTYPE
    732     2          TEMP          LOB_DATA
    732     1          TEMP          INDEX
    732     1          TEMP          DATA
    732     1          TEMP          INDEX
    732     1          TEMP          DATA
    732     1          TEMP          INDEX
    732     1          TEMP          DATA
    732     1          TEMP          INDEX
    732     1          TEMP          INDEX
    732     1          TEMP          DATA
    732     1          TEMP          INDEX
    732     1          TEMP          INDEX
    732     1          TEMP          DATA
    732     1          TEMP          INDEX
    732     1          TEMP          INDEX
    732     1          TEMP          DATA
    732     1          TEMP          INDEX
    732     1          TEMP          INDEX
    732     1          TEMP          DATA
    732     1          TEMP          INDEX
    732     1          TEMP          INDEX
    732     1          TEMP          DATA
    732     1          TEMP          INDEX
    732     1          TEMP          INDEX
    732     1          TEMP          DATA
    732     1          TEMP          INDEX
    732     1          TEMP          INDEX
    732     1          TEMP          DATA
    732     1          TEMP          INDEX
    732     1          TEMP          LOB_INDEX
    select st.sid, sn.name, st.VALUE
    from V$statname sn, v$sesstat st
    where st.STATISTIC# = sn.STATISTIC#
    and (sn.name like 'sorts%')
    and st.sid in (select sid from v$session_wait where event like '%direct path write temp%')
    order by st.sid
    SID     NAME          VALUE
    732     sorts (memory)     591408
    732     sorts (rows)     102126
    732     sorts (disk)     0Why I do not see any disk sorts? If TEMP is used for no sort operations, then for which operations?
    How I can see that? How can I decrease direct path write temp without tuning SQL?
    Additional information:
    PGA_AGGREGATE_TARGET is set to big value - 6GB (3GB enough due to advisory recommendation)
    Please, help.
    Regards, user12103911.

    user12103911 wrote:
    SELECT optimal_count, round(optimal_count*100/total, 2) optimal_perc,
    onepass_count, round(onepass_count*100/total, 2) onepass_perc,
    multipass_count, round(multipass_count*100/total, 2) multipass_perc
    FROM
    (SELECT decode(sum(total_executions), 0, 1, sum(total_executions)) total,
    sum(OPTIMAL_EXECUTIONS) optimal_count,
    sum(ONEPASS_EXECUTIONS) onepass_count,
    sum(MULTIPASSES_EXECUTIONS) multipass_count
    FROM   v$sql_workarea_histogram); 
    OPTIMAL_COUNT OPTIMAL_PERC  ONEPASS_COUNT ONEPASS_PERC  MULTIPASS_COUNT MULTIPASS_PERC
    13150685      100           0             0             0               0No n-pass executions.That's a pretty convincing display - given that your AWR manages to NAME an object that is in the TEMP tablespace, an obvious point to follow up is global temporary tables. If you have any declared as "on commit preserve" (duration = 'SYS$SESSION') then you could have code which does "insert /*+ append */ into gtt", and if you then query this in parallel (or - since you're on 11.2.0.3 - the data volume is large enough) Oracle could choose to do direct path writes to load the GTT and direct path reads to read it back.
    Regards
    Jonathan Lewis

  • What is the diff b/w Conventional Path and Direct Path?

    What is the diff b/w Conventional Path and Direct Path?
    While doing exp/imp
    which one is best in peroformance Conventional Or Direct
    consider my Oracle is 9i (9.2.0) and Os is Solaris 9
    Could you please clarify.....
    Thanks

    http://download.oracle.com/docs/cd/B10501_01/server.920/a96652/ch01.htm#1005685

  • Wait events 'direct path write'  and 'direct path read'

    Hi,
    We have a query which is taking more that 2 min. It's a 9.2.0.7 database. We took the trace/tkprof of the query,and identified that there are so manay 'direct path write' and 'direct path read' wait events in the trace file.
    WAIT #3: nam='direct path write' ela= 5 p1=201 p2=70710 p3=15
    WAIT #3: nam='direct path read' ela= 170 p1=201 p2=71719 p3=15
    In the above, "p1=201" is a file_id, but we could not find any data file, temp file, control file with that id# 201.
    Can you please let us know what's "p1=201" here, how to identify the file which is causing the issue.
    Thanks
    Sravan

    What does:
    show parameter db_filesreturn? My guess, is that it returns 200.
    The direct file read and direct file write events are reads and writes to TEMP tablespace. In those wait events, the file# is reported as db_files+temp file id. So, 201 means temp file #1.
    Now, as to your actual performance problem.
    Without seeing the SQL and the corresponding execution plan, it's impossible to be sure. However, the most common causes of temp writes are sort operations and group by operations.
    If you decide to post your SQL and execution plan, please be sure to make it readable by formatting it. Information on how to do so can be found here.
    Hope that helps,
    -Mark
    Edited by: mbobak on May 1, 2011 1:50 AM

  • Direct Path Insert into temporary table

    Hi,
    I made the following experiment (temp_idtable is a temp table with a single column id, V_PstSigLink is a complex View):
    14:24:28 SQL> insert into temp_idtable select id from V_PstSigLink;
    17084 Zeilen wurden erstellt. (in english: rows inswerted)
    Statistiken
    24 recursive calls
    52718 db block gets
    38305 consistent gets
    16 physical reads
    4860544 redo size
    629 bytes sent via SQL*Net to client
    553 bytes received via SQL*Net from client
    3 SQL*Net roundtrips to/from client
    4 sorts (memory)
    0 sorts (disk)
    17084 rows processed
    14:24:41 SQL> commit;
    Transaktion mit COMMIT abgeschlossen.
    14:25:29 SQL> insert /*+ APPEND*/into temp_idtable select id from V_PstSigLink;
    17084 Zeilen wurden erstellt. (in english: rows inswerted)
    Statistiken
    1778 recursive calls
    775 db block gets
    38847 consistent gets
    40 physical reads
    427408 redo size
    613 bytes sent via SQL*Net to client
    565 bytes received via SQL*Net from client
    3 SQL*Net roundtrips to/from client
    27 sorts (memory)
    0 sorts (disk)
    17084 rows processed
    As you can see, with /*+ APPEND*/ there will be much less REDO generated.
    How can it be?
    1. /*+ APPEND*/ only doesn't mean that there shouldn't be REDO generated, does it? For that one has to declare the table with NOLOGGING.
    2. In the doc there is a statement that for temp. tables there is no REDO log generated, just UNDO (and REDO only for UNDO).
    Where is the difference coming from?
    If I use Direct Path (APPEND) for a temp table, where will be the table populated - in the Buufer Cache or directly in a temporary segment on the disk?
    Balazs

    Hi John,
    I'm a little confused about your statement " Oracle does not cache data blocks until they are read from a table.". I wanted to make a little experiment with KEEP Buffer Cache to see weather I can 'pin' the content of a temp table. But before getting to pin I realized an interesting behavior. Please see this sqlplus log:
    SQL> create global temporary table temp_ins(id NUMBER);
    Table created.
    SQL> insert into temp_ins values (1);
    1 row created.
    SQL> insert into temp_ins values (2);
    1 row created.
    SQL> insert into temp_ins values (3);
    1 row created.
    SQL> set autotrace on explain statistics;
    SQL> select * from temp_ins;
    ID
    1
    2
    3
    Execution Plan
    0 SELECT STATEMENT Optimizer=CHOOSE
    1 0 TABLE ACCESS (FULL) OF 'TEMP_INS'
    Statistics
    0 recursive calls
    0 db block gets
    4 consistent gets
    0 physical reads
    0 redo size
    416 bytes sent via SQL*Net to client
    503 bytes received via SQL*Net from client
    2 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    3 rows processed
    SQL>
    I realized exectly the opposit of your statement! Oracle apparently cached the content of the temp table before it read from it!! Could you please explain why? Now I'm going to try it with a normal table...
    Balazs

  • External Table and Direct path load

    Hi,
    I was just playing with Oracle sql loader and external table features. few things which i ovserved are that data loading through direct path method of sqlloader is much faster and takes much less hard disk space than what external table method takes. here are my stats which i found while data loading:
    For Direct Path: -
    # OF RECORDS.............TIME...................SOURCE FILE SIZE...................DATAFILE SIZE(.dbf)
    478849..........................00:00:43.53...................108,638 KB...................142,088 KB
    957697..........................00:01:08.81...................217,365 KB...................258,568 KB
    1915393..........................00:02:54.43...................434,729 KB...................509,448 KB
    For External Table: -
    # OF RECORDS..........TIME...................SOURCE FILE SIZE...................DATAFILE SIZE(.dbf)
    478849..........................00:02:51.03...................108,638 KB...................966,408 KB
    957697..........................00:08:05.32...................217,365 KB...................1,930,248 KB
    1915393..........................00:17:16.31...................434,729 KB...................3,860,488 KB
    1915393..........................00:23:17.05...................434,729 KB...................3,927,048 KB
    (With PARALLEL)
    i used same files for testing and all other conditions are similar also. In my case datafile is autoextendable, hence, as par requirement its size is automatically increased and hard disk space is reduced thus.The issue is that, is this an expected behaviour? and why in case of external tables such a large hard disk space is used when compared to direct path method? Performance of external table load is also very bad when compared to direct path load.
    one more thing is that while using external table load with PARALLEL option, ideally, it should take less time. But what i actually get is more than what the time was without PARALLEL option.
    In both the cases i am loading data from the same file to the same table (once using direct path and once using external table). before every fresh loading i truncate my internal table into which data was loaded.
    any views??
    Deep
    Message was edited by:
    Deep

    Thanx to all for your suggestions.
    John, my scripts are as follows:
    for external table:
    CREATE TABLE LOG_TBL_LOAD
    (COL1 CHAR(20),     COL2 CHAR(2),     COL3 CHAR(20),     COL4 CHAR(400),
         COL5 CHAR(20),     COL6 CHAR(400),     COL7 CHAR(20),     COL8 CHAR(20),
         COL9 CHAR(400),     COL10 CHAR(400))
    ORGANIZATION EXTERNAL
    (TYPE ORACLE_LOADER
    DEFAULT DIRECTORY EXT_TAB_DIR
    ACCESS PARAMETERS
    (RECORDS DELIMITED BY NEWLINE
    FIELDS TERMINATED BY WHITESPACE OPTIONALLY ENCLOSED BY '"' MISSING FIELD VALUES ARE NULL     
    LOCATION ('LOGZ3.DAT')
    REJECT LIMIT 10;
    for loading i did:
    INSERT INTO LOG_TBL (COL1, COL2, COL3, COL4,COL5, COL6,
    COL7, COL8, COL9, COL10)
    (SELECT COL1, COL2, COL3, COL4, COL5, COL6, COL7, COL8,
    COL9, COL10 FROM LOG_TBL_load_1);
    for direct path my control file is like this:
    OPTIONS (
    DIRECT = TRUE
    LOAD DATA
    INFILE 'F:\DATAFILES\LOGZ3.DAT' "str '\n'"
    INTO TABLE LOG_TBL
    APPEND
    FIELDS TERMINATED BY WHITESPACE OPTIONALLY ENCLOSED BY '"'
    (COL1 CHAR(20),
    COL2 CHAR(2),
    COL3 CHAR(20),
    COL4 CHAR(400),
    COL5 CHAR(20),
    COL6 CHAR(400),
    COL7 CHAR(20),
    COL8 CHAR(20),
    COL9 CHAR(400),
    COL10 CHAR(400))
    and ya, i have used same table in both the situations. after loading once i used to truncate my table, LOG_TBL. i used the same source file, LOGZ3.DAT.
    my tablespace USERS is loaclly managed.
    thanks

Maybe you are looking for

  • Error 15 file not found.

    I was able to install arch linux on a 2 GB flash drive. But I cannot boot into arch linux from the grub menu. I greeted by a message like "error 15 file not found" my menu.lst file looks like # Config file for GRUB - The GNU GRand Unified Bootloader

  • How to Use Cost Depreciation 20 in assets

    Hi, All could you please tell possible ways to use Cost depreciation After that the below points i am expecting 1  We need to recognize both type(costed depreciation) of  depreciation. 2  Only costed depreciation we need to recognize reversal entry t

  • Problems with Delete Rejected Photos

    I hope this hasn't been addressed earlier. I checked as far back as I had patience. I recently upgraded to a new Vista 64bit system. LR 64bit seems to "Not Respond" after I use the "delete rejected photos". Both instances the photos were deleted but

  • IDVD Force Quit when Burning

    Hi, I have Made a Movie with iMovie and it contains clips which I have made with my built in iSight Camera. Then I have added Sound effects from the iMovie Media Pane. I have then Shared the Movie to iDVD and created a Menu. When I want to burn the D

  • Dmp file created using data pump

    Hi All, I have created dmp file using oracle datapump utility and identified that even after dropping dmp file physically from hard disk. I saw there is no storage release. Is there any specefic way to get spaces free from disk? Best Regards, Abida