I've found that large DML operations create a large amount
of redo even if the objects are in a locally managed tablespace.
Ratio is 17:1, at least for me.
Jared
On Wednesday 05 September 2001 10:11, Mohammad Rafiq wrote:
> Grant,
> I am glad that you found reason for lot of archiving.
> Yes,
Were the indexes also created with nologging?
And for those more knowledgeable than I: If the index was created with
nologging and its associated table has date inserted with APPEND will block
change vectors for the Indexes be written to redo logs?
If so, perhaps dropping the indexes before loa
Grant,
I am glad that you found reason for lot of archiving.
Yes, even with nologging, if table/tablespaces are dictionery managed, there
are redologs generated for extent management.
Archiving may be minimized by commiting after certain amount of rows like
rows >= 1 or whaever which your re
Mohammad and Jaymany thanks for the responses.
Upon running your script Mohammad, I noticed that archive files were being
written to the archive directory during a large insert operation and
stopped being written once the insert had completed. The insert command
uses APPEND, the associated
Even if the table is set to nologging DML will still generate redo unless
the data is loaded using
a) direct load from sql loader
b) insert /*+APPEND*/
Updates and deletes will always generate redo.
Jay Miller
-Original Message-
[mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 04,
Run the following script and check syntex for insert,update and delete which
are generating redos
select
substr(username,1,10)"USER",process,sid,serial#,substr(sql_text,1,200),disk_reads,buffer_gets,rows_processed
from v$session,v$sqlarea
where sql_address=address and status = 'ACTIVE'
order
