Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Handling of archive logs

Re: Handling of archive logs

From: Syltrem <syltrem_at_videotron.ca>
Date: Tue, 24 Oct 2000 09:19:01 -0400
Message-ID: <TkgJ5.3542$eE2.147014@weber.videotron.net>

This is the 70% - 30% rule of backups.

70% of them can not be used for whatever reason: Tape has bad blocks on it, tape marker fell off, tape unit broke on the day you need it, tape was lost, or more often (and sad) the data is readable but unusable because of blocks inconsistancy in the file (due to bad method of backing up or users access to file during backup).

That's the way it is.
Syltrem

<oratune_at_aol.com> wrote in message news:8t2bja$nqd$1_at_nnrp1.deja.com...
> In article <39F4826C.43E02426_at_home.nl>,
> frank <fbortel_at_home.nl> wrote:
> > Budgets are tight - as ever.
> > Sites I have worked tend to have 1 or two days of uncompressed
 archived
> > log files, and ditto compressed - thus having at least 2 copies on
 disk, and
> > on 2 different tapes. Murphy, huh? Murphy was an optimist.
> >
> > Or -as one of the guys put it- tapes? a tape is just rust on wheels!
> > And, indeed, I have witnessed the chaos when backups cannot be
> > read from tape... But then again, no disaster plan testing...
> >
> > Frank
> >
> > "Howard J. Rogers" wrote:
> >
> > > The realist in me says if you think you can get away with it, why
 not?
> > >
> > > The purist in me says... the archive logs are the only thing
 standing
> > > between you and data loss, so you play around with them at your
 peril.
> > > Compression to me sounds like a very *bad* idea, since you are
 rather
> > > relying on the compression working correctly, and the decompression
 to work
> > > without a hitch when needed. Anything goes wrong at either end,
 and you've
> > > just lost your logs, and hence the data they were supposed to be
 protecting.
> > >
> > > Managerially, it's also suspect: when the database goes down, your
 job is
> > > supposed to be to get it back up and running again as quickly as
 humanly
> > > possible. By compressing your logs, however, you've introduced
 another
> > > stage in the process, and hence meantime to recover will inevitably
 be
> > > longer.
> > >
> > > My suggestion? Buy some more hard disks.
> > >
> > > Regards
> > > HJR
> > >
> > > "Stefan Fournier" <Stefan.Fournier_at_gmx.de> wrote in message
> > > news:8FD3C9489StefanFourniergmxde_at_130.133.1.4...
> > > > Hello,
> > > >
> > > > I have a question around the handling of archived logs and would
> > > > like to hear how you do it.
> > > > Today we did a import of a schema with about 500 MB. While the
 import
> > > > ran, the database wrote so many archived logs that the filesystem
 went
> > > > full.
> > > > I then gzipped the archive logs to release diskspace and the thing
> > > > finished ok.
> > > > My idea now is to create a cronjob which zips new archive logs
> > > > every 15 minutes or so.
> > > > Is that reasonable?
> > > >
> > > > Thanks for any input.
> > > >
> > > > Regards,
> > > > Stefan
> > > >
> > > >
> > > > --
> > > > Stefan.Fournier_at_gmx.de
> >
> >

>

> This is quite true. I don't know how often I have tried to impress
> upon the on-site DBA and System Administrator to read-verify the backup
> tape prior to accepting it as valid. Simply because it "wrote" means
> absolutely nothing, as a successful write only indicates that the
> device was functioning properly. Read-verifying the backup tape
> ensures that the tape is usable (at least at the time the backup is
> created -- I won't go into the hazards and pitfalls of improper tape
> storage). I have seen many "backups" end up in the trash when the tape
> cannot be read at the crucial moment of recovery.
>

> --
> David Fitzjarrell
> Oracle Certified DBA
>
>

> Sent via Deja.com http://www.deja.com/
> Before you buy.
Received on Tue Oct 24 2000 - 08:19:01 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US