Re: Newbie backup question

Yes it will, so put your archivelogs on a large device, or, more properly, set up a script to move ( and zip or tar ) the older ones to an even larger space ( like a tape ) ....You only need them for as far back as your last full backup...

"Brian Dick" <bdick_at_home.com> wrote:

>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 - 16:04:12 CST