Re: oracle total recall
From: Ilmar Kerm <ilmar.kerm_at_gmail.com>
Date: Tue, 3 Apr 2012 14:36:05 +0300
Message-ID: <CAKnHwtcWWmi6NuFDNbOcCVbPD2snehKOyz749UqydTF-9po4cg_at_mail.gmail.com>
On Tue, Apr 3, 2012 at 2:00 PM, Remigiusz Sokolowski <remigiusz.sokolowski_at_nordea.com> wrote:
> hi,
>
> I wonder if anybody used this feature and what are Your impressions?
>
> We turn it on lately on some application and here a little subjective
> first look:
> - enabling it is easy - point A
> - we add data - point B
> - first "restore" of previous state was quite fast - point C, logical
> state from A
> - then we do a little more changes - point D
> - and flashback again - point E, logical state from C - this time it
> went really long (ie. few days), which puzzles me - it was 15 min. of
> changes and flashing them back was longer then creating the database
> from scratch (ie. import file)
>
> We assumed this is a penalty for not purging total recall data when in
> C, so the next time I did it (ie. purging). This time it seems to run
> faster, but I may only dream about the performance of the first time
> (ie. C). Sure, the database is founded on some test environment, but not
> so bad, I dare to say, though storage is some RAID5, but still wonder...
>
> I saw that flashback goes with db file sequential reads block by block,
> so it can not be too fast, but still wonder...
>
> Did anybody notice such characteristic of that feature? Any clever tips
> or tricks to speed things up (and I do not mean a faster IO susbsystem,
> more memory and faster CPU, but rather suggestion for example to get rid
> of flashback archive after every flashback operation and enable it again
> or truncate somehow flashback archive system tables with drop storage
> option, because I have noticed the segments after purge are of the same
> size as before).
> Of course there is always an option I did something wrong... (and this
> would be also good to know)
Date: Tue, 3 Apr 2012 14:36:05 +0300
Message-ID: <CAKnHwtcWWmi6NuFDNbOcCVbPD2snehKOyz749UqydTF-9po4cg_at_mail.gmail.com>
On Tue, Apr 3, 2012 at 2:00 PM, Remigiusz Sokolowski <remigiusz.sokolowski_at_nordea.com> wrote:
> hi,
>
> I wonder if anybody used this feature and what are Your impressions?
>
> We turn it on lately on some application and here a little subjective
> first look:
> - enabling it is easy - point A
> - we add data - point B
> - first "restore" of previous state was quite fast - point C, logical
> state from A
> - then we do a little more changes - point D
> - and flashback again - point E, logical state from C - this time it
> went really long (ie. few days), which puzzles me - it was 15 min. of
> changes and flashing them back was longer then creating the database
> from scratch (ie. import file)
>
> We assumed this is a penalty for not purging total recall data when in
> C, so the next time I did it (ie. purging). This time it seems to run
> faster, but I may only dream about the performance of the first time
> (ie. C). Sure, the database is founded on some test environment, but not
> so bad, I dare to say, though storage is some RAID5, but still wonder...
>
> I saw that flashback goes with db file sequential reads block by block,
> so it can not be too fast, but still wonder...
>
> Did anybody notice such characteristic of that feature? Any clever tips
> or tricks to speed things up (and I do not mean a faster IO susbsystem,
> more memory and faster CPU, but rather suggestion for example to get rid
> of flashback archive after every flashback operation and enable it again
> or truncate somehow flashback archive system tables with drop storage
> option, because I have noticed the segments after purge are of the same
> size as before).
> Of course there is always an option I did something wrong... (and this
> would be also good to know)
I somehow got the feeling, that maybe you are mixing up two different
flashback features:
* flashback database, for a very quick entire database rollback
* flashback archive (total recall), mainly for providing historical
views of a table data for a long period in time, by storing the needed
undo records
-- Ilmar Kerm -- http://www.freelists.org/webpage/oracle-lReceived on Tue Apr 03 2012 - 06:36:05 CDT