Barbara,
Shoot in the dark. Any chance last vendor upgrade
introduced global temporary tables?
- Daniel Fink <Daniel.Fink_at_Sun.COM> wrote: > 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
> > 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
>
Post your free ad now!
http://personals.yahoo.ca
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Boris Dali
INET: boris_dali_at_yahoo.ca
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 Fri Oct 10 2003 - 12:54:26 CDT
