RE: Poor Performance of undo space management in 10.2 - bug info

From: <Joel.Patterson_at_crowley.com>
Date: Wed, 13 Feb 2008 14:14:30 -0500
Message-ID: <0684DA55864E404F8AD2E2EBDFD557DAAFA27C@JAXMSG01.crowley.com>


I believe the note is 5387030.8    

Joel Patterson
Database Administrator
joel.patterson_at_crowley.com
x72546
904 727-2546


From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of John Hallas Sent: Wednesday, February 13, 2008 11:19 AM To: oracle-l
Subject: Poor Performance of undo space management in 10.2 - bug info  

This note is a heads-u on a bug which has caused me some problems over the last few days and yet is easily identifiable and resolvable (once you recognize the issue).    

We have spent the last 2 days trying to run a benchmark to prove end to end performance of a new code set. We have been plagued by undo tablespace problems which had the following symptons :-  

  • Rapid growth of used undo tablespace
  • Serious deterioration in performance as the undo tablespace got very full
  • Loss of application connectivity as responses were not received in time (trading system with about 7 servers being used to hold components of the system)

The complex set up of the test rig tended to mask the database aspect on each run and it was only this morning that we really focused on the undo tablespace.  

We had AUM set and a 60 second retention period and various sized t/s using both Ramsan and local disk.  

The problem was identified as undo extents remaining marked as unexpired well past the retention period, despite all connections being terminated and no active transactions running.

Searching on Metalink showed Note 5387030.1 which refers to a bug with the TUNED_UINDORETENTION setting. This can be seen in v$undostat and once we had run alter system set "_smu_debug_mode" = 33554432; the v$undostat.tuned_undoretention statistic dropped from 345600 to 2188 and performance improved with unexpired undo segments hardly rising despite heavy throughput.  

This bug is common through 10.2.01 to 10.2.0.3 or is fixed in 10.2.0.4 or V11.  

John  

+44 (0)113 223 2274 (direct)

+44 (0)113 297 9797  


The information included in this email and any files transmitted with it may contain information that is confidential and it must not be used by, or its contents or attachments copied or disclosed, to persons other than the intended addressee. If you have received this email in error, please notify BJSS.
In the absence of written agreement to the contrary BJSS' relevant standard terms of contract for any work to be undertaken will apply. Please carry out virus or such other checks as you consider appropriate in respect of this email. BJSS do not accept responsibility for any adverse effect upon your system or data in relation to this email or any files transmitted with it.
BJSS Limited, a company registered in England and Wales (Company Number 2777575), VAT Registration Number 613295452, Registered Office Address, First Floor, Coronet House, Queen Street, Leeds, LS1 2TW

--
http://www.freelists.org/webpage/oracle-l
Received on Wed Feb 13 2008 - 13:14:30 CST

Original text of this message