Re: Recovery

In article <8rdcu7$ajp$1_at_nnrp1.deja.com>,   Sambavan <sambavan_at_mail.utexas.edu> wrote:
> Instead of taking the tablespace off-line and disrupting the readwrite
 

> process on the tablespace, the database places the tablespace in the
> read-only mode as a result the users would be able to do any kind of
> query on the tables that were on the tablespace but no, other ddls and
> dmls are permitted on it. When you take the tablespace to the backup
> mode, a check point will be performed on that tablespace. This also
> prevents the sequence number in the datafile header from changing, so
> that in case of recovery, logs are applied from backup start-time. So
> overall, it permits the database to be in normal transactional mode.
>
> I hope this would explain things to an extent.
> Sam
>
> In article <8rd2ip$gg2$1_at_bob.news.rcn.net>,
> "Roman Gelfand" <rgelfand_at_masmid.com> wrote:
> > Can someone give me a general idea as to what is taking place where
 alter
> > tablespace start backup command is issued?
> >
> > Thanks,
> >
> > Roman
> >
> >
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>

You neglected to mention that all transactions from the time of "alter tablespace ... begin backup;" to the time of "alter tablespace ... end backup;" are written to the redo logs, and, hence, are archived. This increases redo log activity during the tablespace backup period but allows the datafiles in the affected tablespace to remain readconsistent  so that the files can be backed up without affecting the users (at least as far as they can see -- their transactions are still being processed as though the datafiles were not being backed up). Once the tablespace files are backed up and the tablespace is taken out of backup mode the archived redo and the current redo logs are applied to the datafiles; this is a slight performance hit after the backup is complete but Oracle will still process user requests during the redo log application so the users won't see much of a difference.

This in no way allows the entire database to be read-consistent after the backup -- that would require a cold backup (an act that usually is frowned upon for 24/7 systems). At least the tablespaces are readconsistent  so that in the event a tablespace file or, God forbid, an entire tablespace is wiped out the tablespace file or files can be restored with a minimum of effort on the part of the DBA.

--
David Fitzjarrell
Oracle Certified DBA


Sent via Deja.com http://www.deja.com/
Before you buy.