What type of compression are they using? gzip? Better to use lzjb or lz4 (if available, I don't have an S10 system to check.) Much lighter on CPU usage.
I am off site until Tuesday, but from memory it should be lzjb as default.?
Yes, if you just set "compress=on" then it defaults to lzjb. If even that has a significant impact on CPU usage, then I guess you are right with your assessment to turn of compression altogether. The M4000 is pretty old and does not have that much CPU horsepower compared to a current system.
It did raise a 2nd question when I showed them how files remained compressed until copied though.
They pointed out the compressed file was still being written to by the DB. Did this remain compressed as it was currently, or would it eventually grow.
As I understand it Oracle Redo logs constantly writes to bits of the file. If te block being written to was compressed the I presume it stays compressed ?
Time it takes you to uncompress 250MB is abnormal. Andris Perkons-Oracle tries not to talk about this.
If a block is full, it remains as is, compressed, or not.
If not full, then operating system writes to it new bytes, as it appends them to file. So, it compresses it again.
If you copy from compressed to compressed file, system should simply copy compressed data as is, without decompression. It should take you the same 15 seconds as uncompressed.
This way any file system works. Not just ZFS.
... Or supposed to work. A stupid system may redo the entire file, instead of just 1 new block... Or double work: uncompress, and compress again. Or both.
In ZFS a block can be large. Specification arbitrarily restricts it to 128kB. It simply states so, without any reason. Technically, in theory, a block can be a lot larger. Though, operating system may not be designed to deal with this. It would be stupid, if system compresses anew entire block, rather than just 1 sector on disk. Then it might take a lot of time. But this might happen, only if you append, rather than copy. If this happens always, it would be super stupid.
I did not test if this is the case in Solaris.