compress doesn't compress

[Ronelle van Niekerk]

THe dba's cron job of compressing .dbf files failed on the 7th due to the fact that compresss won't compress those files.

We've tried to compress them manually but still no luck.

Running file on the files produces various things, some are data, some are awk program text and some are lex program text.

The compress gives no errors, it just runs for a while and then comes back to command line as you would expect. But the file remains uncompressed. The error code after the compress command is 2.

Any ideas?

[Con O'Kelly]

Hi Ronelle

Only a guess but certain files depending on the contents are actually larger after the compress. Its possible that the compress is not failing but choosing not to compress as the file will be larger.

Not sure but maybe gzip uses a different algorithm so you might be able to compress with them.

Cheers
Con

[Steven E. Protter]

compress needs free space to work. While its compressing there are two copies of the file, one full size, one building .Z file.

Check free space and post back in the a.m.

SEP

[Bhuvaneswari Selvaraj]

Hi,

compress uses an algo which sometimes can result in increase/no change in the size of the original file. This actually depends on the contents of the file. Try compressing an already compresed file, you can see the same.

However, you can try using tar/ gzip to compress the same.

[Con O'Kelly · Accepted solution]

Hi (again)

I had a look at the compress man page which explains that an rc of 2 shows
"Last file is larger after (attempted) compression"

Compress will only compress a file if it ends up smaller, hence why it appears compress is not working on some of your files.

Cheers
Con

[Ronelle van Niekerk]

Well thanks guys, especially Con, I guess next time I should RTFM properly.

[Michael Steele_2]

Also look into bad data within these files. For if the post file is larger, then its probably due to bad data. This type of file is also known as a 'sparse' file.

To determine sparse or not, use this command:

# ls -sl

The "-s" (read: size) tells you, how many blocks (of 512 bytes each) and "-l" tells you the possition of that last byte in that file.

Here's a thread:

http://forums1.itrc.hp.com/service/forums/parseCurl.do?CURL=%2Fcm%2FQuestionAnswer%2F1%2C%2C0xc7265fe8b250d71190080090279cd0f9%2C00.html

[James A. Donovan]

Since these are the .dbf files (the files containing the tablespaces), then they are almost certainly "sparse" files. It's not that unusual to have very large datafiles with very few objects/tablespaces located in those files.

[Jeff Schussele]

Hi,

I'm not sure compress handles +2GB files.
Man pgs make no commitment yea or nay.

Try gzip, but use a ver 1.3.1 or higher. DO NOT use the gzip included in the OS - 1.2.4. Get a higher ver from the porting centres.

My 2 cents,
Jeff