Re: Flashback vs. rollback mechanism
Date: Sat, 24 Jan 2009 12:07:04 -0800 (PST)
Message-ID: <ab5e90a8-6915-4726-8b46-9a3fac546623_at_p36g2000prp.googlegroups.com>
On Jan 23, 10:10 pm, Michael Austin <maus..._at_firstdbasource.com> wrote:
> Mladen Gogala wrote:
> > In the newer versions of Oracle there are 2 distinct mechanisms for
> > undoing the effect of transactions: rollback and flashback. Rollback
> > method is transactional, it simply undoes the changes made to the blocks
> > during the failed transaction while the flashback method is more akin to
> > recovery. The differences between those two methods are numerous but the
> > outcome will, in many cases be the same.
>
> Except not. The rollback only "restores" the data involved in the
> current transaction. FLASHBACK table/database - restores back to an
> SCN-x (point in time) losing all other data post-SCN-x.
>
> From:
> Oracle® Database Administrator's Guide 10g Release 2
> >>http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/tables...
>
> * Restores all data in a specified table to a previous point
> in time described by a timestamp or SCN.
> * Performs the restore operation online.
> * Automatically maintains all of the table attributes, such as
> indexes, triggers, and constraints that are necessary for an application
> to function with the flashed-back table.
> .....
> * Maintains data integrity as specified by constraints. Tables
> are flashed back provided none of the table constraints are violated.
> This includes any referential integrity constraints specified between a
> table included in the FLASHBACK TABLE statement and another table that
> is not included in the FLASHBACK TABLE statement.
> ....
>
> > Should we expect to see some blending between rollback and flashback? I
>
> Don't think so. Using a FLASHBACK-like mechanism to do a ROLLBACK is
> like using a 20lb sledge hammer to nail a miniature picture frame
> together (ie. does a lot more damage than good... :) ) If you were only
> executing one very large transaction that inserted 100's or thousands of
> records AND was the only thing running AND the transaction committed -
> then a flashback-like mechanism is definitely an option.
>
> > believe that in the future releases the fine line between the rollback and
> > flashback will be blurred, possibly by introducing "fast rollback" which
> > will use recovery-like methods characteristic of the flashback but will
> > be used within transaction as a "get me my old values back" mechanism.
>
> > This, of course, is just a mental experiment. Any thoughts?
>
> I would say your experiment has a long way to go for success... :)
I attempted to reply to this twice on Friday but both attempts returned an error message from Google. So here is another attempt.
There are several flashback mechanisms in Oracle including flashback database, flashback query, and flashback table. Flashback database is similar in nature to running a reverse recovery. That is instead of starting at a point in the past and rolling forward using the archived redo logs you start in the present and roll back using flashback logs. Being that flashback database is database wide I do no thing you can compare it to rollback.
However, all other flashback methods actually depend on undo segment data so I do not think you can consider rollback to be transactional and consider flashback table or query to be non-transitional. Since flashback table and query are based on undo the features might be said to be multi-transactional in that each of capable of rolling back through more than one transaction. That is where a rollback will undo one failed or cancelled transaction the flashback table and query features will rollback as many transactions as necessary to get to the requested point in time providing the undo tablespace still retains the necessary data.
IMHO – Mark D Powell Received on Sat Jan 24 2009 - 14:07:04 CST