Title: RE: monitor transactions over time
Make that bug #2506744.....
Sorry..
 
 
- Kirti
-----Original Message-----
From: Deshpande, Kirti
Sent: Thursday, March 13, 2003 7:20 PM
To: '[EMAIL PROTECTED]'
Subject: TXNCOUNT in V$UNDOSTAT (9i R2) [ Was -- RE: monitor transactions over time ]

Today, Oracle Support updated my TAR, stating that there won't be a patch released to fix this bug (#2506774) in 9i R2. 
 
Suggested workaround is to derive TXNCOUNT by subtracting the numbers from the previous sample period.  
And when you write one, watch out for those -ve numbers for TXNCOUNT..   :-))  
 
Somebody is watching this list...... seriously....   ;)  
Rajendra,  you need to put your script on e-bay  ;)
 
Regards,
 
 
- Kirti
 
-----Original Message-----
From: Deshpande, Kirti
Sent: Friday, March 07, 2003 9:14 PM
To: Multiple recipients of list ORACLE-L
Subject: RE: monitor transactions over time

From what I know Oracle Development folks have identified the code changes to correct this problem. Just do not when Oracle would issue the patch. Since the bug was logged against 9i R2, patch would be provided.  
 
This bug was originally logged in Aug 2002. There was no follow up.
 
The other issue with v$undostat view is that it does not work in Manual Undo Mode. Forget using it while in Manual Undo Management mode to monitor your undo usage to size undo tablespace accordingly. Forget what the documents, white papers say. Some of them are 'syntactically' correct in saying, "This view is available in Automatic and Manual Undo Management mode." Yes, that is true. The view is available in MUM mode. But, it returns one useless row in 9i R1 and nothing in 9i R2. I was told by Oracle Development that it did not work in 9i R1, in MUM mode, so they simply changed it to return nothing in 9i Rel 2.         
Hmmm... wonder if I followed this principle for some of the bugs in our Applications......... ;)  
 
 I will talk about this, and a few other things, in my Quick Tips Sessions, on AUM and FBQ, at the IOUG Conf next month.
 
- Kirti  
-----Original Message-----
From: Jamadagni, Rajendra [mailto:[EMAIL PROTECTED]
Sent: Friday, March 07, 2003 4:44 PM
To: Multiple recipients of list ORACLE-L
Subject: RE: monitor transactions over time

I wrote a script to fix the problem in 9202, but don't tell Oracle ... we want them to fix the bug. as soon as they know there is a workaround, the priority on the bug will go down. Log a iTar and request a patch ... the bug# is 2506744

Raj
-------------------------------------------------------------
Rajendra dot Jamadagni at espn dot com
Any views expressed here are strictly personal.
QOTD: Any clod can have facts, having an opinion is an art !!


-----Original Message-----
From: Ehresmann, David [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 07, 2003 5:04 PM
To: Multiple recipients of list ORACLE-L
Subject: monitor transactions over time


List,

Does anybody know a way to monitor the number of transactions occurring over
time, say 5 minute or 10 minute intervals?  I am looking at v$undostat and
it appears to have a problem accumulating transactions under txncount when
it should report over a 10 minute interval ( metalink doc# 260990.995, query
v$undostat)

BEGIN_TIM END_TIME    UNDOBLKS   TXNCOUNT

---------              ---------           ----------   ----------

05-MAR-03 05-MAR-03         38                  161519

05-MAR-03 05-MAR-03         24                  161468

05-MAR-03 05-MAR-03          1                  161227

05-MAR-03 05-MAR-03          4          161075

05-MAR-03 05-MAR-03         71          160881

05-MAR-03 05-MAR-03       6932          160748

05-MAR-03 05-MAR-03          8          160073

05-MAR-03 05-MAR-03      14545          159887

05-MAR-03 05-MAR-03      19588          159010

05-MAR-03 05-MAR-03       2333          157084

05-MAR-03 05-MAR-03       6972          152649 

the undo blocks appear correct, but transactions are accumulating.  Does
anybody know how to use v$transaction or another view to do this? This is
9iRel2 on Unix and the application is geared toward transaction processing.

thanks,                                   

David Ehresmann

Reply via email to