Re: unrecoverable datafiles ?
Date: Fri, 28 Aug 2015 10:10:21 -0600
Message-ID: <CAAaXtLA3+dPPtDL4GsMZ2S3NbrFfpS90vcjRLdtMZ+3=Z6ueGw_at_mail.gmail.com>
I could be mistaken here, but it sounds like the only remaining problem is that the PRIMARY database does not think a backup has been made since the NOLOGGING changes were applied.
Is it possible that a level-0 backup (on the primary) will clear the reports of unrecoverable datafiles?
On Fri, Aug 28, 2015 at 9:47 AM, Norman Dunbar <oracle_at_dunbar-it.co.uk> wrote:
> On 27/08/15 15:03, Chris King wrote:
>
>> I ran the backup validate command on the standby. Lots of output, but no
>> corruption found on the standby. Also
>> I did a select from v$database_block_corruption when done and it
>> returned no rows.
>>
> This is good - the standby is fine. :-)
>
>
> So I have to conclude that the standby database is
>> okay.... but then why does this query, on both primary and standby,
>> still return five rows with Jan/Feb dates?
>>
>
> Because V$DATAFILE stores the most recent unrecoverable change# and time
> for each data file in the database. If that date or change# keeps changing
> (and force logging is off) than there are scripts/applications/SQL
> Loader/DBAs and/or developers that need to be tracked down and educated.
>
> Those details of unrecoverable changes will, as far as I am aware, remain
> until the end of time! Which makes sense given that the point of those two
> columns is to let you know when the most recent unrecoverable change took
> place.
>
>
> Is it possible that the standby is sound but the production/primary
>> database is not?
>>
> I'd think not.
>
> The standby must have been created after the most recent unrecoverable
> change.
>
> The primary still has the data that was loaded in this manner because you
> have not attempted to restore to a backup taken before the afore mentioned
> change, and recovered through the unrecoverable changes.
>
> I would say that both your databases are fine. Just be sure that you have
> force logging turned on at all times. In a past job, we set up a monitoring
> script to ensure that all our databases were in force logging mode. You can
> probably do this in OEM as a metric extension I suspect too. Or Nagios etc.
>
> HTH
>
>
>
> Cheers,
> Norm.
>
> --
> Norman Dunbar
> Dunbar IT Consultants Ltd
>
> Registered address:
> 27a Lidget Hill
> Pudsey
> West Yorkshire
> United Kingdom
> LS28 7LG
>
> Company Number: 05132767
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Fri Aug 28 2015 - 18:10:21 CEST