RE: Computing resource consumption

From: Jamadagni, Rajendra <Rajendra.Jamadagni_at_espn.com>
Date: Fri, 25 Jul 2003 08:32:59 -0400
Message-Id: <26013.339599@fatcity.com>

This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible.

------=_NextPartTM-000-9643add0-6c88-4bda-809e-004d69248210 Content-Type: multipart/alternative;

boundary="----_=_NextPart_001_01C352A8.E208DAFE"

------_=_NextPart_001_01C352A8.E208DAFE
Content-Type: text/plain;

charset="iso-8859-1"

Thanks Cary,

thanks, but here is a question ... you say capturing physical IO is redundant ... what about REDO generated by session? Isn't that part of physical writes? If I just concentrate on LIO (I am currently using "Logical IO' (statistic#9 in 9202).

Currently I am concentrating on following statistics to create a matrix

  9 -- session logical reads 
 12 -- CPU used by this session  
 20 -- session pga memory 
 21 -- session pga memory max 
 42 -- physical reads 
 46 -- physical writes 
115 -- redo size 
236 -- bytes sent via SQL*Net to client 
237 -- bytes received via SQL*Net from client

not sure if all of them will matter in the end, but at-least it is a start for me.

Another problem is capturing the work done by background processes on behalf of these sessions ... how does one go about capturing that workload??

Thanks in advance
Raj

Rajendra dot Jamadagni at nospamespn dot com All Views expressed in this email are strictly personal. QOTD: Any clod can have facts, having an opinion is an art ! -----Original Message-----
From: Cary Millsap [mailto:cary.millsap_at_hotsos.com] Sent: Friday, July 25, 2003 1:24 AM
To: Multiple recipients of list ORACLE-L Subject: RE: Computing resource consumption

Raj,

A pretty common (and actually pretty accurate) charge back unit is the LIO. You can get this information by using the standard AUDIT CONNECT feature, and using the LREAD value as your basis. If you wanted to get fancy, you might also charge by the parse call (which you're already collecting in your V$SESSTAT query). The reason I'd focus on these two metrics is because these are the two operations on an Oracle system that absolutely prevent the system from scaling.

You could count physical I/Os as well, but that would be redundant if you're already catching LIO call counts.

Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com

Upcoming events:

- Hotsos Clinic 101 in Denver, Sydney
- Hotsos Symposium 2004 March 7-10 Dallas
- Visit www.hotsos.com for schedule details...
-----Original Message-----

From: ml-errors_at_fatcity.com [mailto:ml-errors_at_fatcity.com] On Behalf Of Jamadagni, Rajendra
Sent: Thursday, July 24, 2003 12:04 PM
To: Multiple recipients of list ORACLE-L Subject: Computing resource consumption

Does anyone know any papers or techniques to compute resource consumption by users in a DB systems? This may or may not be for computing charge-back to the client, but my questions are
1. What do you compute?
2. are there any standard methods and or standard formula? I am collecting v$sesstat when a session exits, but is data alone from session stats sufficient? How about the work done by background processes on user's behalf?
Do you do anything like this at your workplace? This is something that might be coming down the line, so I have been asked to start looking for related stuff.
Thanks in advance
Raj

Rajendra dot Jamadagni at nospamespn dot com All Views expressed in this email are strictly personal. QOTD: Any clod can have facts, having an opinion is an art !

------_=_NextPart_001_01C352A8.E208DAFE
Content-Type: text/html;

charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.45">
<TITLE>RE: Computing resource consumption</TITLE>
</HEAD>
<BODY>

Thanks Cary,


thanks, but here is a question ... you say capturing =
physical IO is redundant ... what about REDO  generated by = session? Isn't that part of physical writes? If I just concentrate on = LIO (I am currently using "Logical IO' (statistic#9 in = 9202).

Currently I am concentrating on following statistics =
to create a matrix


  9 -- session logical reads 
  12 -- CPU used by this session  
  20 -- session pga memory 
  21 -- session pga memory max 
  42 -- physical reads 
  46 -- physical writes 
 115 -- redo size 
 236 -- bytes sent via SQL*Net to client 
 237 -- bytes received via SQL*Net from client =



not sure if all of them will matter in the end, but =
at-least it is a start for me. 


Another problem is capturing the work done by =
background processes on behalf of these sessions ... how does one go = about capturing that workload??

Thanks in advance
 Raj
 <FONT =

SIZE=3D2>---------------------------------------------------------------=
----------------- </FONT>

 Rajendra dot Jamadagni at nospamespn dot com 
 All Views expressed in this email are strictly =
personal. 
 QOTD: Any clod can have facts, having an opinion is =
an art ! 
 -----Original Message-----
 From: Cary Millsap [<A =
HREF=3D"mailto:cary.millsap_at_hotsos.com">mailto:cary.millsap_at_hotsos.com</= A>]
 Sent: Friday, July 25, 2003 1:24 AM
 To: Multiple recipients of list ORACLE-L
 Subject: RE: Computing resource consumption

 

Raj,


A pretty common (and actually pretty accurate) charge =
back unit is the LIO. You can get this information by using the = standard AUDIT CONNECT feature, and using the LREAD value as your = basis. If you wanted to get fancy, you might also charge by the parse = call (which you're already collecting in your V$SESSTAT query). The = reason I'd focus on these two metrics is because these are the two = operations on an Oracle system that absolutely prevent the system from = scaling.

You could count physical I/Os as well, but that would =
be redundant if you're already catching LIO call counts.


Cary Millsap
 Hotsos Enterprises, Ltd.
 <A HREF=3D"http://www.hotsos.com" =
TARGET=3D"_blank">http://www.hotsos.com</A>


Upcoming events:
 - Hotsos Clinic 101 in Denver, Sydney
 - Hotsos Symposium 2004 March 7-10 Dallas
 - Visit www.hotsos.com for schedule =
details...
 -----Original Message-----
 From: ml-errors_at_fatcity.com [<A =
HREF=3D"mailto:ml-errors_at_fatcity.com">mailto:ml-errors_at_fatcity.com</A>] = On Behalf Of Jamadagni, Rajendra
 Sent: Thursday, July 24, 2003 12:04 PM
 To: Multiple recipients of list ORACLE-L
 Subject: Computing resource consumption


Does anyone know any papers or techniques to compute =
resource consumption by users in a DB systems? This may or may not be = for computing charge-back to the client, but my questions are =


1. What do you compute? 
 2. are there any standard methods and or standard =
formula? 
 I am collecting v$sesstat when a session exits, but =
is data alone from session stats sufficient? How about the work done by = background processes on user's behalf?

Do you do anything like this at your workplace? This =
is something that might be coming down the line, so I have been asked = to start looking for related stuff.

Thanks in advance 
 Raj 
 <FONT =

SIZE=3D2>---------------------------------------------------------------=
----------------- </FONT>

</BODY>
</HTML>

------_=_NextPart_001_01C352A8.E208DAFE--

------=_NextPartTM-000-9643add0-6c88-4bda-809e-004d69248210 Content-Type: text/plain;

name="ESPN_Disclaimer.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;

filename="ESPN_Disclaimer.txt"

********************************************************************This e-mail message is confidential, intended only for the named recipient(s) above and may contain information that is privileged, attorney work product or exempt from disclosure under applicable law. If you have received this message in error, or are not the named recipient(s), please immediately notify corporate MIS at (860) 766-2000 and delete this e-mail message from your computer, Thank you.*********************************************************************2

Received on Fri Jul 25 2003 - 07:32:59 CDT