-
I am new to this position and will appreciate all the help I can get. I checked the alert log for this database and I see that we have been getting these errors for past couple of months. Could someone please tell me how to fix it? PLEASE. I know this is a lot of info. Please help!!!!!!
COPY OF THE ALERT LOG.
Tue Nov 13 12:11:59 2001
Errors in file /u01/app/oracle/admin/rc1/bdump/smon_25614.trc:
ORA-01595: error freeing extent (1) of rollback segment (72))
ORA-01594: attempt to wrap into rollback segment (62) extent (1) which is being used
Thu Nov 1 11:52:00 2001
Thread 1 advanced to log sequence 183
Current log# 3 seq# 183 mem# 0: /u01/app/oracle/admin/rc1/links/redo1/redo3a.l
og
Current log# 3 seq# 183 mem# 1: /u01/app/oracle/admin/rc1/links/redo2/redo3b.l
og
Tue Nov 6 15:24:10 2001
Thread 1 advanced to log sequence 184
Current log# 4 seq# 184 mem# 0: /u01/app/oracle/admin/rc1/links/redo1/redo4a.l
og
Current log# 4 seq# 184 mem# 1: /u01/app/oracle/admin/rc1/links/redo2/redo4b.l
og
Mon Nov 12 03:39:02 2001
Thread 1 advanced to log sequence 185
Current log# 1 seq# 185 mem# 0: /u01/app/oracle/admin/rc1/links/redo1/redo1a.l
og
Current log# 1 seq# 185 mem# 1: /u01/app/oracle/admin/rc1/links/redo2/redo1b.l
og
Tue Nov 13 12:11:59 2001
Errors in file /u01/app/oracle/admin/rc1/bdump/smon_25614.trc:
ORA-01595: error freeing extent (1) of rollback segment (72))
ORA-01594: attempt to wrap into rollback segment (62) extent (1) which is being
freed
COPY OF THE BDUMP TRACE FILE
Dump file /u01/app/oracle/admin/rc1/bdump/smon_25614.trc
Oracle8 Enterprise Edition Release 8.0.5.0.0 - Production
PL/SQL Release 8.0.5.0.0 - Production
ORACLE_HOME = /u01/app/oracle/product/8.0.5
System name: HP-UX
Node name: cae27
Release: B.11.00
Version: U
Machine: 9000/800
Instance name: rc1
Redo thread mounted by this instance: 1
Oracle process number: 7
Unix process pid: 25614, image: ora_smon_rc1
*** SESSION ID:(6.1) 2001.10.29.12.06.52.867
*** 2001.10.29.12.06.52.867
SMON: following errors trapped and ignored:
ORA-01595: error freeing extent (1) of rollback segment (62))
ORA-01594: attempt to wrap into rollback segment (62) extent (1) which is being
freed
*** 2001.11.13.12.11.59.405
SMON: following errors trapped and ignored:
ORA-01595: error freeing extent (1) of rollback segment (72))
ORA-01594: attempt to wrap into rollback segment (62) extent (1) which is being
freed
-
-
If you don't have the metalink support, please let us know and we would try to explaing what is causing this problem.
Sam
-
You have too small rollback segments, probably.
When SMON is generating undo after internal operation, this undo needs to be wrapped into the next extent. But your next extent is just being shrunk.
Make INITIAL, NEXT (and OPTIMAL) a bit larger.
-
Hello,
This is the complete explanation available in METALINK :
**********************
Error: ORA 1594
Text: attempt to wrap into rollback segment (%s) extent (%s) which is being fr
eed
-------------------------------------------------------------------------------
Cause: Undo generated to free a rollback segment extent is attempting
to write into the same extent due to small extents and/or too
many extents to free
Action: The rollback segment shrinking will be rollbacked by the system;
increase the optimal size of the rollback segment.
*** Important: The notes below are for experienced users - See [NOTE:22080.1]
Explanation:
1594 is reported when a rollback segment is being shrunk but there is
not enough space in the current undo extent to complete the job.
Shrinking uses whatever is available in the current extent in the
rollback segment. If no more space is left and the extent you
would move into is one that is being freed you will get 1594.
This error is harmless. When you retry, chances are you will not get
the same error again.
Usually this is caused by running a transaction after a huge
transaction commits. Because of the setting of OPTIMAL, a very large
number of extents need to be deallocated all at once.
One way to avoid this problem is to have larger extent size.
Another way is to have a larger OPTIMAL setting, so that only a smaller
number of extents will be removed at one time.
SET TRANSACTION USE ROLLBACK SEGMENT is also a good idea for large
jobs so you know which rollback segment they will use.
Note: There are changes to the way SMON shrinks rollback segments
in 7.2. It should try to shrink a small number of extents at
a time.
Hope this helps
Regards
-
I executed this query
select a.name, b.extents, b.rssize, b.optsize, b.shrinks, b.aveshrink, b.aveactive, b.wraps, b.extends, b.status
from v$rollname a, v$rollstat b
where a.usn = b.usn;
This is what I got.
I have 300 rbs, each with about 2 extents, 1056768 rssize, 2097152 optsize, shrinks are 0 and wraps are about 5 aveactive is 216024.
Should I still increase optimal.
Thanks
-
I think you should reorganize your undo/rollback segments. How many concurrent users do you have? More than 1000? Then 300 is probably the right amount. But 2 extents in a segment is really the minimum. 20 is OK.
-
Thanks all for your assistance. You are a great bunch of people.
