Re: recover from TRUNCATE TABLE via physical standby?
From: Kevin Jernigan <kevin.jernigan_at_oracle.com>
Date: Thu, 23 Aug 2012 15:55:43 -0700
Message-ID: <5036B4EF.3040901_at_oracle.com>
Yes, you do have to enable Flashback Data Archive for each table individually. But I don't understand what you mean by "...if the number of potential candidate isn't well known up front.": are you saying that you might not know which tables you need to enable FDA on before you truncate them?
Date: Thu, 23 Aug 2012 15:55:43 -0700
Message-ID: <5036B4EF.3040901_at_oracle.com>
Yes, you do have to enable Flashback Data Archive for each table individually. But I don't understand what you mean by "...if the number of potential candidate isn't well known up front.": are you saying that you might not know which tables you need to enable FDA on before you truncate them?
-- Kevin Jernigan Senior Director Product Management Advanced Compression, Hybrid Columnar Compression (HCC), Database File System (DBFS), SecureFiles, Database Smart Flash Cache, Total Recall, Database Resource Manager (DBRM), Direct NFS Client (dNFS), Continuous Query Notification (CQN), Index Organized Tables (IOT), Information Lifecycle Management (ILM) (650) 607-0392 (o) (415) 710-8828 (m) On 8/23/12 3:30 PM, Adric Norris wrote:Received on Thu Aug 23 2012 - 17:55:43 CDT
> I'll look into that option, but doesn't Flashback Data Archive have to be
> explicitly enabled for each relevant table? If so, that could be a problem
> if the number of potential candidate isn't well known up front.
> On Thu, Aug 23, 2012 at 4:52 PM, Kevin Jernigan
> <kevin.jernigan_at_oracle.com>wrote:
>
>> You could enable Flashback Data Archive (Total Recall) on the table, then
>> use Flashback Query to select from the table AS OF a timestamp right before
>> the TRUNCATE. This would be much easier to implement, with no need to muck
>> around with disconnecting the standby db etc...KJ
>>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
-- http://www.freelists.org/webpage/oracle-l