Message-ID: <F001.005D2B67.20031010080925@fatcity.com>
Date: Fri, 10 Oct 2003 08:09:25 -0800
To: Multiple recipients of list ORACLE-L <ORACLE-L@fatcity.com>
Sender: ml-errors@fatcity.com
Reply-To: ORACLE-L@fatcity.com
Errors-To: ML-ERRORS@fatcity.com
From: Daniel Fink <Daniel.Fink@Sun.COM>
Subject: Re: Redos gone crazy--a job for audit?
Organization: Fat City Network Services, San Diego, California
Precedence: bulk
Mime-Version: 1.0
Content-type: multipart/mixed; boundary=------------5B288BAD5969C517399E069E
--------------5B288BAD5969C517399E069E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Barb,

Even if you can't find the user, you can still find the session info and
run a trace on the session. If it is consistent, you should be able to
trace for a short amount of time and retrieve the statements that are
generating redo. Then you can go back to the vendor and say "This
statement (update emp set empno = empno) is generating 3g of redo per
day and it is not performing any work. Please consider this a P1 bug and
we need a fix in 10 days." It is especially valuable if you can trace
the 'old-good' app and compare it with the 'new-bad' app.

Dan

Barbara Baker wrote:

> Dan:
> Thanks for this -- I'll definitely tuck this away for
> future reference.
>
> Sadly, it's not going to help this time.  I don't have
> a user generating redo, I have an application running
> amuck.
>
> The users (reporters) never log into the database.
> Some service (Solaris high availability service, I
> believe) logs a database user on 20 times, then
> buffers requests from the HA service to the database.
>  A minute or two later, it logs the 20 sessions out
> and logs in 20 more.
>
> Between around 5:30 am and 3:00 am the following day,
> the database is rolling a new redo log about every 16
> minutes.  Pretty much new log file every 16 minutes
> like clockwork.   Between 3:00 and 5:30, the HA
> service is disabled and some kind of maintenance is
> running.  The entire database is about 4100 megs.
> We're generating more than 3 gigs of redo per day.
>
> I sure would like to know what's in those redo logs.
>
> Thanks for the help!
> Looks like another beautiful weekend to hang out on
> top of a mountain.  Did you get to see the leaves
> turning this year??
>
> Barb

--------------5B288BAD5969C517399E069E
Content-Type: text/x-vcard; charset=us-ascii;
 name="daniel.fink.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Daniel Fink
Content-Disposition: attachment;
 filename="daniel.fink.vcf"

begin:vcard 
n:Fink;Daniel
x-mozilla-html:FALSE
org:Sun Microsystems, Inc.
adr:;;;;;;
version:2.1
title:Lead, Database Services
x-mozilla-cpt:;9168
fn:Daniel  W. Fink
end:vcard

--------------5B288BAD5969C517399E069E--

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Daniel Fink
  INET: Daniel.Fink@Sun.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@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).