Alter Table nologging still generating archive logs

Hi,
I am using sqlloader to load millions of records into a table.

I issued the following
alter table test nologging;

and then started the sqlloader session to load the data. But still archive logs are being generated at a very fast pace.

Whats going on here.

Please suggest.

Thanks
Anurag

Are you using the direct=y flag?

No I am not using the direct load method. But that shouldnt matter as logging is disabled at the table level.

Anurag

That's a common misconception. NOLOGGING only works with certain operations. Please see http://technet.oracle.com/docs/produ...dlins.htm#4418

Or check the following thread (long thread, check both pages, not just the first one):
http://www.dbasupport.com/forums/sho...?threadid=8919

Thanks for the reply.

I tried this but still it is generating logs.

Below is the sample of my parfile and also I have set the table to nologging.

userid=ofus/ofus@orcl8i
control=loaddata.ctl
errors=25000
direct=true
log=loaddata.log


Also when reading the documentation I saw

"To use a direct path load (with the exception of parallel loads), SQL*Loader must have exclusive write access to the table and exclusive read/write access to any indexes"

How do you make sure of this and what are its implications.

Thanks
Anurag

Still waiting for a response....

Thanks
Anurag

well I havent used sql loader direct load but as far as I know when you do direct load users cannot perform DML on those objects. The way to ensure this? Do it when the database activity is low if it is 24x7 database, otherwise do it at early mornings!

Quote:

---

Originally posted by anuragmin
I tried this but still it is generating logs.

---

There will always be *some* redo logs generated even during the nologged opereations. But the amount of redo generated should be *much* less then normal.

During nologged operations undo information is still written into RB segments and this undo entries are still fully logged. Also the data dictionary operations caused by unlogged operations (extent allocation etc) are still logged.

Quote:

---

Also when reading the documentation I saw

"To use a direct path load (with the exception of parallel loads), SQL*Loader must have exclusive write access to the table and exclusive read/write access to any indexes"

---

It means that during direct path load the table is being locked in the exclusive mode, so other session can still perform reads on that table, but can't perform DMLs. Indexes belonging to the table that is being loaded are marked as UNUSABLE during the direct path load, so they can't be used by other session even for reads.

[Edited by jmodic on 06-11-2001 at 03:54 PM]