Re: Fast roll-back

From: Yong Huang <yong321_at_yahoo.com>
Date: Fri, 23 Jan 2009 08:57:09 -0800 (PST)
Message-ID: <4beee02b-f439-4cc0-823d-e64c39ff3aa6_at_m12g2000vbp.googlegroups.com>

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.
>
> --
> Regards
>
> 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:

http://el-caro.blogspot.com/2008_11_01_archive.html

"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