Re: Cheap Cheap Database Recovery

From: Michael Austin <maustin_at_firstdbasource.com>
Date: Tue, 24 Feb 2009 18:00:04 -0600
Message-ID: <jQ%ol.23495$ZP4.18080_at_nlpi067.nbdc.sbc.com>

johnbhurley_at_sbcglobal.net wrote:
> On Feb 24, 3:27 pm, pitufo <vandr..._at_gmail.com> wrote:

>> I got it at last!
>> There is no inconsistency. Problem was that when I do a full backup at
>> 2:30pm, this is a consistent backup, meaning that all changes in the
>> online redo logs are commited to the datafiles before closing the
>> database.  Once the database start operations, the online redo logs
>> will start filling up one by one, faster or slower depending on the
>> activity of the database.  So if I try an incomplete recovery in the
>> middle of the day, I will be able to advance from 2:30 am until the
>> last archived file that is not present in the online redo log file.
>> That really, explains the mistery. BUT,   if I query v$log, I can see
>> that only one online redolog file is marked as 'CURRENT', and of
>> course has a 'NO' in the ARCHIVED column. The rest of the online
>> redologs are already archived....if that it is true (as it is), then
>> why the 'until cancel' does not move all the way up to the last
>> archived file known by the current controlfile ?
>> Thanks!

>
> Well you got most of it! You only "mess around" with control file
> backups and restoring them if you have a valid reason to do so ...
> like a damaged control file.
>
> You don't have a problem with your control file. You have a complete
> consistent cold backup that has good control files. You use that
> control file along with your complete database backup plus future
> archive logs to go forward in time until you don't have any more
> archive logs. Because you are on a different server recovering
> elsewhere ... that's the best you can do. ( Another point ... make
> sure your archive log switches make some amount of sense with how
> close in time to the present that you intend to be able to recover
> to ).
>
> Have you tried testing based on that setup instead of ( for reasons
> unknown to me ) trying to somehow shoehorn in newer versions of your
> controlfile ( past the cold backup )?
>
> If you start trying to put in play more recent versions of a control
> file yes they will have some unrealistic and unhelpful information ...
> since you can only go as far as your last archived log ... what's the
> point?

I will be so glad when they get rid of the control file concept all together. That data should be stored in the system tables - with the rest of the meta-data. And you really cannot say it can't be done as at least 2 other enterprise class db's do it that way... (for those that may have an adverse reaction to the statement :) ). Received on Tue Feb 24 2009 - 18:00:04 CST