Re: oracle total recall

  • From: Tim Hall <tim@xxxxxxxxxxxxxxx>
  • To: remigiusz.sokolowski@xxxxxxxxxx
  • Date: Tue, 3 Apr 2012 13:32:19 +0100

Hi.

I agree with Ilmar, your post does sound a little confusing because
you do sound like you are talking about flashback database. :)

Ignoring that, what it sounds like you are saying is the more changes
you make to the table, the longer a flashback operation takes to
complete.

Well, that's kinda obvious since the way the undo-based flashback
operations work is to use the undo in the undo tablespace (and
flashback data archive if present and required) to build up a specific
point in time representation of the data. In the case of flashback
table, this representation of the data is used to alter the table
data, effectively recovering to the previous state. This is a
transactional operation though, so the next flashback operation you
try will have more data to wade through to get your result. The same
way, flashing back 1 minute will be quicker than flashing back 1 week,
since the amount of undo processing will be vastly less (assuming even
load over time etc.)

Sorry if I misunderstood your point...

Cheers

Tim...


On Tue, Apr 3, 2012 at 1:10 PM, Remigiusz Sokolowski
<remigiusz.sokolowski@xxxxxxxxxx> wrote:
> W dniu 03.04.2012 13:36, Ilmar Kerm pisze:
>> On Tue, Apr 3, 2012 at 2:00 PM, Remigiusz Sokolowski
>> <remigiusz.sokolowski@xxxxxxxxxx> wrote:
> [..]
>> 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
>>
>
> That is an interesting statement.
> I certainly do not use flashback database, but flashback table
> statements (thus this will use data from UNDO tablespace).
> So, if I understand You well, my idea that flashback table will use
> flashback archives if called on flashback-archive-enabled table is not
> really a reality ? ;-)
> That would be something I look for.
>
> Regards
> Remigiusz
> --
> Pole nakazi
>
> ----------------------------------------------------------------------
> Remigiusz Sokolowski <remigiusz.sokolowski@xxxxxxxxxx>
> pos   : DBA at DIiUSI
> addr  : Nordea Bank Polska SA, Luzycka 6A Street, 81-537 Gdynia, Poland
> phone : +48 58 667 17 43
> mobile: +48 602 42 42 77
> Nordea Bank Polska S.A. z siedzibą w Gdyni, ul. Kielecka 2, 81-303 Gdynia,
> wpisaną do Rejestru Przedsiębiorców Krajowego Rejestru Sądowego pod numerem: 
> 0000021828,
> dla której dokumentację przechowuje Sąd Rejonowy Gdańsk - Północ w Gdańsku,
> VIII Wydział Gospodarczy Krajowego Rejestru Sądowego,
> o kapitale zakładowym i wpłaconym w wysokości: 277.493.500,00 złotych,
> NIP: 586-000-78-20, REGON: 190024711--
> //www.freelists.org/webpage/oracle-l
>
>
--
//www.freelists.org/webpage/oracle-l


Other related posts: