Tuning an insert sql that inserts a million rows doing a full table scan

Question

Hi Experts,
I am on Oracle 11.2.0.3 on Linux. I have a sql that inserts data in a history/archive table from a main application table based on date. The application table has 3 million rows in it. and all rows that are older then 6 months should go into a history/archive table. this was recently decided and we have 1 million rows that satisfy this criteria. This insert into archive table is taking about 3 minutes. The explain plan shows a full table scan on the main table - which is the right thing as we are pulling out 1 million rows from main table into history table.
My question is that, is there a way I can make this sql go faster?
Here is the query plan (I changed the table names etc.)
   INSERT INTO EMP_ARCH
   SELECT *
FROM EMP M
where HIRE_date < (sysdate - :v_num_days);
call     count       cpu    elapsed       disk      query    current        rows
Parse        2      0.00       0.00          0          0          0           0
Execute      2     96.22     165.59      92266     147180    8529323     1441230
Fetch        0      0.00       0.00          0          0          0           0
total        4     96.22     165.59      92266     147180    8529323     1441230
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: FIRST_ROWS
Parsing user id: 166
Rows     Row Source Operation
1441401   TABLE ACCESS FULL EMP (cr=52900 pr=52885 pw=0 time=21189581 us)
I heard that there is a way to use opt_param hint to increase the multiblock read count but didn't seem to work for me....I will be thankful for suggestions on this. also can collections and changing this to pl/sql make it faster?
Thanks,
OrauserN

Answer 1

Also I wish experts share their insight on how we make full table scan go faster (apart from parallel suggestion I mean).
Please make up your mind about what question you actually want help with.
First you said you want help making the INSERT query go faster but the rest of your replies, including the above statement, imply that you are obsessed with making full table scans go faster.
You also said:
our management would like us to come forth with the best way to do it
But when people make suggestions you make replies about you and your abilities:
I do not have the liberty to do the "alter session enable parallel dml".  I have to work within this constraings
Does 'management' want the best way to do whichever question you are asking?
Or is is just YOU that want the best way (whatever you mean by best) based on some unknown set of constraints?
As SB already said, you clearly do NOT have an actual problem since you have already completed the task of inserting the data, several times in fact. So the time it takes to do it is irrevelant.
There is no universal agreement on what the word 'best' means for any given use case and you haven't given us your definition either. So how would we know what might be 'best'?
So until you provide the COMPLETE list of constraints you are just wasting our time asking for suggestions that you refute with a comment about some 'constraint' you have.
You also haven't provided ANY information that indicates that it is the full table scan that is the root of the problem. It is far more likely to be the INSERT into the table and a simple use of NOLOGGING with an APPEND hint might be all that is needed.
IMHO the 'best' way would be to partition both the source and target tables and just use EXCHANGE PARTITION to move the data. That operation would only take a millisecond or two.
But, let me guess, that would not conform to one of your 'unknown' constraints would it?