I was co-presenting recently at Sydney Oracle Meetup
about Data Guard Compression and in preparation I did
some tests to see how it works for 184.108.40.206 (Linux x86-64)
…and I am still not able to see it working.
There is a note “Redo Transport Compression in a Data Guard Environment [ID 729551.1]”
on MOS how to set compression for redo transport destination
and for log archive gaps but none of those settings helped to see compression
reported neither in trace files nor in v$archived_log view (compressed column).
Possibly at first compression for archive logs was mentioned in the
“Archivelog compression?” post but even “alter database archivelog compress enable”
works in 220.127.116.11 (still not documented)
it does not affect compression of archive logs although archivelog_compression in
v$database changed to ENABLED.
Later on I checked ability of alter database… to influence compression of archive logs
in 18.104.22.168 and 22.214.171.124 (Linux x86-64) and got positive results:
in both versions archive logs of 50M were decreased in size to ~10M
and trace file for ARCH process was updated with information about ratio
Archivelog compression complete. Input: 50969088 bytes Output: 10307875 bytes Compression Performance: 79.78 percent or 1.62 bits per byte
But for 11g Rel.2 database created from predefined templates compression did not work.
Does it require some special additional options or specific hidden parameters configuration
in addition to mentioned in the note COMPRESSION=ENABLE and “_redo_transport_compress_all”
(which by default set to TRUE)?
Definitely truth is out there…
Have a good day!
4 Responses to “Redo Transport Compression”
Leave a Reply