Re: Recovery scenario

From: Allan Nelson <anelson77388_at_gmail.com>
Date: Fri, 1 Feb 2008 15:17:47 -0600
Message-ID: <ffb96860802011317u1dd54aa7lb6215b3c5626ea11@mail.gmail.com>


Yeah, too much typing, not enough sleep. The Oracle Kernel Error guy already corrected me. (Sorry don't remember the name, just the ORA-600 in the url). I actually do know how recovery works most of the time.

Allan

On Feb 1, 2008 3:12 PM, D'Hooge Freek <Freek.D'Hooge_at_uptime.be> wrote:

> Allan,
>
> Redo is generated as soon as a transaction changes things, not only when
> you perform a commit.
> When redo is generated it is first written to the online redo log buffer,
> from where it will be written out to the online redo logs by the lgwr
> process, as soon as the log buffer is 1/3 full, every 3 seconds and when a
> commit is performed (so yes, the online redo log files contain redo linked
> to an uncommited change).
> When an online redo log is full, the lgwr continues to write to the next
> online redo logfile and signals the dbwr to start writing out the changed db
> blocks that are related to this redo to the datafiles.
>
> Remember that, when you change a db block, oracle will not only generate
> redo, but also undo. These undo blocks are stored in the undo tablespace and
> changes to these db blocks will also generate redo.
>
> During recovery, oracle will process all redo found in the redo log files.
> This is called the rolling forward phase.
> After this, oracle will rollback all changes, for which no commit record
> was found, using the undo found in the undo tablespace (that was recreated
> during the rollforward phase). This is known as the rollback phase.
>
>
> regards,
>
> Freek D'Hooge
> Uptime
> Oracle Database Administrator
> e-mail: freek.dhooge_at_uptime.be
> tel. +32 (0)3 451 23 82
> http://www.uptime.be
> disclaimer
>
>
> From: oracle-l-bounce_at_freelists.org [oracle-l-bounce_at_freelists.org] On
> Behalf Of Allan Nelson [anelson77388_at_gmail.com]
> Sent: 01 February 2008 17:49
> To: p4cldba_at_gmail.com
> Cc: niall.litchfield_at_gmail.com; Hemant K Chitale; jeremiah_at_ora-600.net;
> raindoctor_at_gmail.com; veeeraman_at_gmail.com; Oracle List
> Subject: Re: Recovery scenario
>
>
> Well, one possible explanation is that both committed and uncommitted
> changes are written to the on line logs and hence to the archived logs. In
> the case of a transaction that started before the backup and was running
> through the backup you could need logs from before the backup started. I'm
> sure you could think of other scenarios that are specific to your
> environment.
>
> Allan
>
>
> On Jan 31, 2008 2:12 PM, Prasad <p4cldba_at_gmail.com> wrote:
>
> "Why would oracle ask for a file that is from 5am when the backup finished
> at 1 30am?"
>
> Can this be due to the backup controlfile reading the last scn of online
> redo logs . ??
>
>
> On Thu, Jan 31, 2008 at 7:17 AM, Niall Litchfield <
> niall.litchfield_at_gmail.com> wrote:
>
> On Jan 31, 2008 2:58 PM, Hemant K Chitale <hkchital_at_singnet.com.sg> wrote:
>
>
>
> A "using Backup Controlfile" implicitly means
> "the controlfile is older then the datafiles"
>
>
> I've always thought of it as 'ignore the scn in the controlfile' not the
> controlfile is older..
>
> the RECOVER command then actually _builds_ the archivelog
> file names [using log_archive_dest and log_archive_format].
>
> It wasn't the file name per se but the creation time as in the message
>
> ORA-00279: change 11805815756 generated at 01/30/2008 05:00:15 needed for
> thread 1
>
> Where we were told that the backups including the controlfile backup were
> from several hours before 5 in the morning. The recovery process seems to
> know when this change was created - but I don't really see how it can -
> unless as Andrew suggested the controlfile was actually from after 5am. I'm
> sure I used to know this once, but I'm feeling really old and stupid right
> now.
>
> Niall
>
>
> --
> Niall Litchfield
> Oracle DBA
> http://www.orawin.info
>

--
http://www.freelists.org/webpage/oracle-l
Received on Fri Feb 01 2008 - 15:17:47 CST

Original text of this message