I recall seeing a case in the early days of automatic undo where a very big
serial DML batch had a problem because due to the cost of stealing a very large
number of unexpired undo extents while it ran; and then everything running at
9:00 having a problem because all the small(ish) concurrent DML stuff from the
end users had to steal the extents back - and that caused a massive contention
problem for a few minutes.
If someone had run into that problem they might have decided to run with manual
rollback and specify a particular segment in a separate tablespace for the
batch job as a workaround.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
@jloracle
________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx [oracle-l-bounce@xxxxxxxxxxxxx] on behalf
of Chris Taylor [christopherdtaylor1994@xxxxxxxxx]
Sent: 23 August 2016 15:03
To: ORACLE-L
Subject: Are any of you guys managing rollback segments manually?
I was having a discussion with a guy about improving data load speeds and he
was asking me about creating a large rollback segment and how I would handle
it. I was a bit taken aback because I haven't manually managed rollback
segments in a long, long time.
So, I'm curious if this is still "a thing"? Managing rollback segments
manually especially in regard to large data loads?
If so, I'd like to understand why managing rollback segments manually makes
more sense than using a dedicated UNDO tablespace and letting Oracle manage the
rollback segments?
I've been googling some this morning and I see some bits and pieces here and
there but I don't see any use cases where managing rollback segments manually
makes sense to me. (So I'm trying to put 2+2 together in my own mind)
Regards,
Chris
