"Chuck" <chuckhNOSPAM_at_softhome.net> wrote in message
news:adl8ln$1tk4$1_at_ID-85580.news.dfncis.de...
> In an ideal world and in text books that would be possible - but so would
> having one CPU for each process, and terabytes of real memory so no tasks
> ever swap out. In the real world rollback segments fill up, disk size is
> limited, and sometimes you have to commit more frequently than you want
to.
> I would not want to be in the position of having to explain to my boss why
> I'm tying up gigabytes of space for a rollback segment that gets used once
> in a blue moon.
Well then don't do it. We do have a process that we run once a year that
takes an exceptional amount of rollback space. So what do we do. Once a year
take all the other rollback segments offline (having shrunk them). We then
create our large segment run the transaction and then drop the rollback
segment and put everything back. The point being that we want to run
processes like this in 'off hours' just because of the impact of this one
process on the system (not to mention the fact that it does intermediate
commits so I want to make damn sure I can't leave the db in an unknown
state).
Received on Thu Jun 06 2002 - 05:52:32 CDT
