Fastest way to load data

Question

Option 1:
Insert statement with:
table mode: NOLOGGING    
insert mode: APPEND        
archivelog mode: noarchive log mode  
Option 2:
CTAS with NOLOGGING mode
Both options above would generate no redo log. Which one is better for performance? I'm loading large volume or rows (a few million) on a daily basis and this is a staging table so there is no problem to reprocess in case of failure.

Answer 1

Jonathan,
> Insert /*+ append */ can optimise for indexes by capturing the necessary column values as the data is loaded and then creating the indexes without needing to re-read the table
How did you do to came to this conclusion?
I did a simple test (t2 has a single column index) and got the following trace files
1- Direct path load
insert /*+ append */ into t2
select * from t1
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.01          0          1          0           0
Execute      1      0.05       0.08          3        140         87        1000
Fetch        0      0.00       0.00          0          0          0           0
total        2      0.05       0.09          3        141         87        1000
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 39
Rows     Row Source Operation
      1  LOAD AS SELECT  (cr=140 pr=3 pw=3 time=84813 us)
   1000   TABLE ACCESS FULL T1 (cr=5 pr=0 pw=0 time=92 us)
Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  control file sequential read                    8        0.00          0.00
  db file sequential read                         2        0.00          0.00
  direct path write                               1        0.02          0.02
  SQL*Net message to client                       1        0.00          0.00
  SQL*Net message from client                     1        3.49          3.49
2- Conventional load
insert
into t2
select * from t1
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.01       0.00          0          1          0           0
Execute      1      0.02       0.00          1         22        275        1000
Fetch        0      0.00       0.00          0          0          0           0
total        2      0.03       0.01          1         23        275        1000
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 39
Rows     Row Source Operation
   1000  TABLE ACCESS FULL T1 (cr=5 pr=0 pw=0 time=31 us)
Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  db file sequential read                         1        0.00          0.00
  SQL*Net message to client                       1        0.00          0.00
  SQL*Net message from client                     1        1.21          1.21
The trace file of the append hint contains a direct path write and a control file sequential read wait events confirming the direct path insert. But I still have not found in the trace file an indication on how the index is maintained separately from the table during a direct path load. Additionally I see that in both trace files there are two TABLE ACCESS FULL T1.
What I used to know is that during a direct path insert indexes are maintained differently from their table. Mini indexes are built on the incoming data and are finally merged with the physical index. But I don't see this also in the trace file.
However, In the append trace file there is the following select (occurring before the insert statement) that does not exist in the normal insert
select pos#,intcol#,col#,spare1,bo#,spare2
from
icol$ where obj#=:1
call     count       cpu    elapsed       disk      query    current        rows
Parse        2      0.00       0.00          0          0          0           0
Execute      2      0.00       0.01          0          0          0           0
Fetch        4      0.00       0.00          0          7          0           2
total        8      0.00       0.01          0          7          0           2
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      1  TABLE ACCESS BY INDEX ROWID ICOL$ (cr=3 pr=0 pw=0 time=25 us)
      1   INDEX RANGE SCAN I_ICOL1 (cr=2 pr=0 pw=0 time=21 us)(object id 40)
I am not sure if this has a relation with the mini-index pre-built data to be merged with the physical index.
That is my question : where to see this in the trace file?
Thanks
Mohamed Houri