ahhh.. brain fart. I get it. I was over thinking things. Thanks howard.
"Howard J. Rogers" <hjr_at_dizwell.com> wrote in message
news:3f920194$0$21653$afc38c87_at_news.optusnet.com.au...
> Ryan wrote:
>
> >> --
> >
> > I get it now. However, its common to stagger your hot backups. Say do a
> > few data files a night. Lets say you have this instance.
> >
> > You have 3 data files and 1 rollback tablespace. You backup 1 data
> > file/night.
> >
> > Do you need to backup your rollback tablespace every night?
>
> No. I hate to keep saying this, but a rollback segment is just a data
store
> like a table is. If you had to backup your rollback segments every night,
> you'd have to back all your tables up every night. And then if you were
> doing tables every night, you'd have to do rollback segments every 12
> hours. And then...
>
> ...and then you'd end up disappearing up your own bottom.
>
> If your rollback segments get backed up every Sunday, and everything else
> gets backed up each night, when you lose your rollback segments, you
> restore the relevant datafile from last Sunday. You then apply redo to it,
> and hence bring it up to date.
>
> Rollback tablespaces are no different to any other tablespace. Backup when
> appropriate, and recovery means restore from the last backup (whenever it
> was taken) and make it current by applying redo.
>
>
> > Also, lets say
> > you are doing a hotbackup of datafile A and you are doing a hotbackup of
> > your rollback tablespace. I would assume you need to keep your datafile
> > and your rollback tablespace in 'backup' mode for the same period of
time.
>
> No, and I'm getting a bit lost with your assumptions. Think of a rollback
> segment as though it were called EMP and treat it accordingly. They are
> really no different from any other segment.
>
> > If you backup your datafile first, then backup your rollback tablespace
> > they could be at two different SCNs.
>
> If you back up SYSTEM, then backup DATA, they WILL be at two different
SCNs.
> Who cares?? What happens when you apply redo to ANY tablespace? It rolls
> forward in time, its SCN increments, and it therefore achieves eventual
> synchronisation.
>
> The process of database recovery is the process of making different SCNs
on
> different datafiles the same. Works regardless of what's in the data
files.
>
> >This means the rollback needed to
> > restore the datafile may not exist in the rollback tablespace at the
time
> > of the backup.
>
> Rollback is NOT needed to restore a datafile. Redo is. When you replay
redo
> to replay your 'update EMP' transactions, the rollback for that update is
> re-generated. Therefore, when we discover at the end of the redo log that
> your update EMP transaction wasn't committed, we can now roll it back
> because the rollback segment is full of the necessary rollback.
>
> You're making a mountain out of a very small molehill on this one.
>
> Just one last time: rollback segments need no more backing up than SYSTEM.
> They are backed up in exactly the same way as SYSTEM or DATA or INDX. They
> are recovered in exactly the same way. They are needed for recovery, but
> recovery also re-constructs them just as it reconstructs transactions in
> EMP or DEPT.
>
> > am I correct here?
>
> Not really, no. Just one last time for this one too: think of a rollback
> segment as a table that's there for Oracle's internal housekeeping, but a
> table nonetheless. And treat it as you would any other table.
>
> Regards
> HJR
> --
> --------------------------------------------
> See my brand new website, soon to be full of
> new articles: www.dizwell.com.
> Nothing much there yet, but give it time!!
> --------------------------------------------
>
Received on Sun Oct 19 2003 - 16:40:50 CDT
