Re: unrecoverable datafiles ?

From: Norman Dunbar <oracle_at_dunbar-it.co.uk>
Date: Fri, 28 Aug 2015 16:47:35 +0100
Message-ID: <55E08297.2010406_at_dunbar-it.co.uk>



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
Received on Fri Aug 28 2015 - 17:47:35 CEST

Original text of this message