Re: Fast roll-back
Date: Fri, 23 Jan 2009 08:57:09 -0800 (PST)
On Jan 23, 6:33 am, "Jonathan Lewis" <jonat..._at_jlcomp.demon.co.uk> wrote:
> You may be thinking of something like the following:
> If a process issues a rollback; then all the rows it had
> locked will stay locked until the entire rollback is complete.
> If the session is killed or the database is restarted (before
> the process commits its transaction) then smon handles the
> rollback. But if some other user process needs to update
> some of the inconsistent data, it can detect that it's looking
> at blocks that are in need of rollback and perform a "localised"
> rollback against just those blocks.
> This means that killing a session (or in your extreme case bouncing
> the database) can allow other work to resume faster than it could
> if you waited for a process rollback to complete.
> It's possible that in earlier versions of Oracle, this "localised" rollback
> could take place only at database restart. In modern versions it can
> happen after a "kill session". Of course, it won't necessarily be the
> case that killing a session will help.
> Jonathan Lewishttp://jonathanlewis.wordpress.com
> Author: Cost Based Oracle: Fundamentalshttp://www.jlcomp.demon.co.uk/cbo_book/ind_book.html
> The Co-operative Oracle Users' FAQhttp://www.jlcomp.demon.co.uk/faq/ind_faq.html
Fairlie Rego reported a problem with parallel rollback, which defaults to low instead of false:
"IMHO (atleast from past experience) serial recovery is faster than parallel recovery atleast in the case where the transaction causes a lot of index block splits"
That probably accounts for some of the slow rollback cases.
Yong Huang Received on Fri Jan 23 2009 - 10:57:09 CST