Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Excessive Redo Generation

Re: Excessive Redo Generation

From: Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk>
Date: Thu, 02 Jan 2003 02:29:00 -0800
Message-ID: <F001.00525331.20030102022900@fatcity.com>

How are you deciding that you are
generating excessive redo ?

What is excessive for 1,500 concurrent
users in a banking operation ?

Using log miner to examine the problem
sounds like a very painful last resort.

Have you taken snapshots of session stats to try and pin down any patterns to redo generation so that you can (possibly) associate large volumes with specific processes ?

Have you tried comparing redo size with
commit / rollback counts to see if there is any pattern to activity that shows you were the most redo is generated ?

Couple of thoughts: if your banking application is typical, then code to update a field on screen may be turned into SQL to update every single column in the table - this generates a lot of undo and redo (especially on wide tables).

If you banking appliation is typical, then it could spend a lot of its time generating scratch data in working tables, then rolling it back or deleting it. This generates a lot of undo and redo.

Both issues can be corrected, but only if you have access to source, or very compliant suppliers.

Regards

Jonathan Lewis
http://www.jlcomp.demon.co.uk

Coming soon a new one-day tutorial:
Cost Based Optimisation
(see http://www.jlcomp.demon.co.uk/tutorial.html )

Next Seminar dates:
(see http://www.jlcomp.demon.co.uk/seminar.html )

____England______January 21/23

The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html

-----Original Message-----
To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com> Date: 02 January 2003 07:52

>
> We seem to Be Generating Excessive Redo .
>
> All Tablespaces are LOCALLY Managed except SYSTEM .
> Size of Redo Logfile = 200 MB
> log_check_point_interval = 300000
> log_checkpoint_timeout = 0
> log_buffer = 2MB
>>
> NOTE - We have purposely kept increased log_check_point_interval =
300000 based on past experience .
>
>> Any /etc/system , init.ora parameter Changes too ?
>>
>> Concurrent Oracle processes = 1500 Approx.
>>
> Machine Box = SF6800
> Application = Banking (Hybrid )
>> Oracle 8.1.7.4
>> Solaris 8
>>
> We shall be taking Logminer Outputs
> Anything in particular to Look for in the Logminer Output to Check
for Excessive Redo Generation ?
>
> [VIVEK_SHARMA] Thanks
>>
>--
>Please see the official ORACLE-L FAQ: http://www.orafaq.net
>--
>Author: VIVEK_SHARMA
> INET: VIVEK_SHARMA_at_infosys.com
>
>Fat City Network Services -- 858-538-5051 http://www.fatcity.com
>San Diego, California -- Mailing list and web hosting services
>---------------------------------------------------------------------
>To REMOVE yourself from this mailing list, send an E-Mail message
>to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
>the message BODY, include a line containing: UNSUB ORACLE-L
>(or the name of mailing list you want to be removed from). You may
>also send the HELP command for other information (like subscribing).
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Jonathan Lewis
  INET: jonathan_at_jlcomp.demon.co.uk

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
Received on Thu Jan 02 2003 - 04:29:00 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US