Re: Compressing oracle *.dbf files / Dangerous?
Date: Fri, 8 Oct 93 20:50:19 GMT
Message-ID: <1993Oct8.205019.10082_at_exlog.com>
In article <D8YHBHSN_at_gwdu03.gwdg.de> plewe_at_dl.mpi-dortmund.mpg.de (J.Plewe) writes:
>Esa Karell (karell_at_cs.Helsinki.FI) wrote:
>: An Oracle rep told me that they strongly advise
>: against compressing oracle's db files. I've used
>: gtar with -Z (tar + compress) and never had any problems
>: when restored from a backup tape. I looked at db files
>: (aix, oracle 6.0.36) and none of them looked strange (e.g. sparse).
>: Pls, tell if there's more to it than what I know.
>: --
>
>If you do not try to get a compressed copy of your database files
>while the database is RUNNING, I cannot see any objectives against
>compressing database files.
Ah the old "How does utility X handle sparse files problem"
The problem as I understand it is as follows:
Unix allows you to create a sparse file (a file with a hole in it). You would do this by opening a new file and lseeking N bytes into it. You haven't written anything to the file just defined it as being n bytes large.
When utilities like tar, compress or cpio read this guy they are going to do a read from disk and expect to get back the size of the buffer read or a -1 to indicate EOF. But on a spare file you'll get a 0 back. tar/cpio/compress should understand that this 0 means I read a buffer full from the disk and didn't find any characters so when you write it back make sure you inlude that empty space.
I think the problem was that some version of these utilities dont understand that and just zip along assuming that nothing is to be recorded for those buffers. So when you uncompress/untar/uncpio you get a file shorter than what you started with.
This should be pretty easy to test out. create a 1MB datafile and compress/tar/cpio it. If it comes out the other end the same size you would be ok.
This will also depend on how oracle creates its dbf files on your platform. Some version/system may write nulls out rather than create sparce files.
-- Regards, Lee E. Parsons Baker Hughes Inteq, Inc Oracle Database Administrator lparsons_at_exlog.comReceived on Fri Oct 08 1993 - 21:50:19 CET