Re: Handling of archive logs

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
Received on Sat Oct 21 2000 - 03:11:27 CDT