Re: how to figure out how much redo sql statements are generating?

From: Steve Adams <steve.adams_at_ixora.com.au>
Date: Tue, 01 Jan 2008 15:42:13 +1100
Message-ID: <4779C4A5.7020304@ixora.com.au>


Hi All,

With in-memory-undo from 10g some redo generation will not be seen in the stats for the session responsible. This is very pronounced if the workload is light. So use a realistic workload when testing.

@   Regards,
@   Steve Adams
@   http://www.ixora.com.au/         - For DBAs
@   http://www.christianity.net.au/  - For all

-----Original Message-----
Date: Mon, 31 Dec 2007 16:06:27 -0700
From: Tim Gorman <tim_at_evdbt.com>
To: oracle-l_at_freelists.org
Subject: Re: how to figure out how much redo sql statements are generating?

> I look at the statistic "redo size" for the session, which is the amount
> of redo generated in bytes. This can be found at the instance-level in
> V$SYSSTAT, at the session-level in V$SESSSTAT, and for the present
> session in V$MYSTAT. For at least the latter two views, the information
> won't be visible until a COMMIT occurs, and I would bet the same with
> V$SYSSTAT as well...
>
> Hope this helps....
>
>
>
> Andrew Kerber wrote:

>> If you know which tables are affected by which parts of the 
>> application, dba_tab_modifcations can give insert/update/delete 
>> activity on the tables.  I believe monitoring has to be turned on for 
>> that though (its on by default).
>>
>> On Dec 31, 2007 12:58 PM, <ryan_gaffuri_at_comcast.net 
>> <mailto:ryan_gaffuri_at_comcast.net>> wrote:
>>
>>     We are generating alot of redo. We have sql loader data loads and
>>     dml on the database. I am trying to track which parts of the
>>     application are probably generating the most redo. Is there a way
>>     to do this?
>>     --
>>     http://www.freelists.org/webpage/oracle-l
>>
>>
>>
>>
>>
>> -- 
>> Andrew W. Kerber
>>
>> 'If at first you dont succeed, dont take up skydiving.' 

> -- http://www.freelists.org/webpage/oracle-l
--
http://www.freelists.org/webpage/oracle-l
Received on Mon Dec 31 2007 - 22:42:13 CST

Original text of this message