Poor Performance of undo space management in 10.2 - bug info
- From: "John Hallas" <john.hallas@xxxxxxxxxx>
- To: "oracle-l" <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 13 Feb 2008 16:18:53 -0000
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
Other related posts:
