Re: Newbie backup question

I'm missing something here. Please set me straight.

My understanding of ARCHIVELOG mode is that everytime the database switches log files, it copies the previous log file to the specified archive directory. So, as hours, days, and months go by, many files will be copied to the archive directory. If left to run unattended, wouldn't the disk drive fill up?

"Steve Bell" <sbell_at_sympatico.ca> wrote in message news:0H8q6.406614$JT5.12527371_at_news20.bellglobal.com...
> Hi Brian,
> ARCHIVELOG mode doesn't rely on the users doing the backups...it simply
> means that records of transactions that are occurring (redo logs) are
> archived in such a way that they can be used to restore the database in
 the
> event of certain failures.
> It will run unattended...
> You can't switch back and forth between the two modes as you're asking;
 the
> good news is you don't have to.
>
> One of the problems running NOARCHIVELOG mode is you can only recover your
> database to the time of the last full backup. Since you say you don't
 allow
> "planned" outages (does this include backups?) a minor disk failure could
> leave you with a complete loss of data..you'd be starting from day one...
>
> Best regards,
> Steve
>
> "Brian Dick" <bdick_at_home.com> wrote in message
> news:GU7q6.13461$PR.91191_at_news1.wwck1.ri.home.com...
> > I understand that we are in a compromising position. But our backup
> > requirements are a bit odd for a database system.
> >
> > We run NOARCHIVELOG mode because the database runs unattended. We cannot
> > guarantee that the users will do periodic backups, so we cannot manage
 the
> > size of archived redo logs.
> >
> > The 24x7 requirement is for "planned" outages. We can't have any. But
 are
> > willing to suffer some data loss due to "unplanned" outages. We are
> > gathering real-time data, and gaps due to an unplanned outages are
> > permissible.
> >
> > Is it possible to temporarily turn ARCHIVELOG mode on, do a hot backup,
 and
> > then turn ARCHIVELOG mode off? If we can limit the size of the archived
 redo
> > logs, then would have a workable solution.
> >
> > "andrew_webby at hotmail" <spam_at_no.thanks.com> wrote in message
> > news:984151599.9387.0.nnrp-07.c30bdde2_at_news.demon.co.uk...
> > > You're on the road to hell already.
> > >
> > > 24x7 and NOARCHIVE? You can't create a backup like that without
 shutting
 the
> > > database down.
> > >
> > > If you want 24x7, you need to be doing hot backups in ARCHIVELOG mode,
 so
> > > read the appropriate chapters in Oracle manual for that.
> > >
> > > Also, search the web - there are quite a few hotbackup scripts in
> > > circulation, the reading of which will help you become familiar with
 what
> > > you need to do.
> > >
> > > "Brian Dick" <bdick_at_home.com> wrote in message
> > > news:D66q6.13243$PR.91127_at_news1.wwck1.ri.home.com...
> > > > I am mainly an application developer, but I've been tossed onto a
 project
> > > > that needs a quick solution for backup. We have no "real" DBA, just
 me
 as
 a
> > > > "de facto" DBA.
> > > >
> > > > The project uses Oracle V8.1.6 as an imbedded database, so it needs
 to
 run
> > > > almost entirely unattended and 24x7. The database is relatively
 small
 and
 is
> > > > configured to run in NOARCHIVE mode.
> > > >
> > > > But the users of the system do want to be able to frequently run a
 script
> > > > that takes a full backup of the database. If the system incurrs a
 media
> > > > crash, then the users would run a script for a restore from the
 backup.
 Loss
> > > > of data from the time of backup to the time of restore is NOT an
 issue.
> > > >
> > > > I've read the Oracle8i Backup and Recovery Guide a couple of times,
 and
 I
 am
> > > > confused with all of the options available. I think my requirements
 are
> > > > fairly simple and all of these ARCHIVE/NOARCHIVE,
 consistent/inconsistent,
> > > > complete/incomplete decisions really blur the picture.
> > > >
> > > > I know the above scenario is less than optimal, but I have to play
 with
 the
> > > > cards I have been delt. We plan to have a robust backup/recovery
 process
 in
> > > > the next version of our system (promise <g>).
> > > >
> > > > Later,
> > > > BEDick
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Received on Fri Mar 09 2001 - 12:53:02 CST