This sounds similar to a known bug with ASSM tablespaces. The stats job updates tables in SYSAUX. Those tables have indexes and up to 10.2.0.2 if an instance does massive DML (which the stats job does in our case. Terabyte oltp with daily data loads and many schemas) on segments in an ASSM tablespace that has indexes, the undo is unbelievable. In our case it produces 10x the undo / redo it normally would. It can cause not only ora-1555 (See ora-1555.ora-code.com), but you can blow out the max extents (32767) for an undo segment. The 'workaround' of coalescing the indexes prior to running such DML is only minimally effective. The backport patch for previous versions in some cases flat doesn't work (I know from experience.) The only sure fix is to upgrade to 10.2.0.2, which I am told definitely fixes the issue, and which I am preparing to do on several production instances even thought I HATE applying the latest patchset (hornet's nest). Of course, if you are already on 10.2.0.2 and are seeing this, please let me know!
-- --Original Message-- -- From: oracle-l-bounce@(protected) [mailto:oracle-l-bounce@(protected)] On Behalf Of Alex Gorbachev Sent: Tuesday, June 27, 2006 2:52 PM To: oracle-l@(protected) Subject: Re: ORA-01555 (See ORA-01555.ora-code.com): snapshot too old: rollback segment number 24 with name "_SYSSMU24$" too small
Duration 1151404820? That's like 36+ years... a bit odd, uh? :)
Anyway, ORA-1555 (See ORA-1555.ora-code.com) is often thrown regardless space availability in UNDO tablespace. You can get it any time for read only transaction (or single select) after it's running for retention_period time. Select requires read consistent image of blocks and those are reconstructed from UNDO info. UNDO info is kept for undo retention period. As soon as you reach it - chances are you hit ORA-1555 (See ORA-1555.ora-code.com) on any more or less often updatable table.
And yet another reason to delete this infamous job ASAP!
2006/6/27, arul kumar <arul76_2000@(protected)>: > I have this recent error in alert log coming from the > stats update job. Though the SQL is given partly, not > able to find the EXACT database object that had > problem. Any clue? > > .. > .... > Tue Jun 27 03:40:20 2006 > ORA-01555 (See ORA-01555.ora-code.com) caused by SQL statement below (Query > Duration=1151404820 sec, SCN: 0x0849.81c92aa1):
