RMAN Slow due to Compression Oracle 12.2.0.1; Red Hat Enterprise Linux 7.6 RMAN script: backup as compressed backupset incremental level 0 tag='INCREMENTAL0' database include current controlfile plus archivelog; It took several hours to finish backing up a 200GB database. Most of the time one oracle server process spawned by rman is using 99 or 100% CPU (user-, not sys-CPU by cross-referencing with `vmstat'). Its wait events (Disk file operations I/O, KSV master wait, etc.) are not relevant because v$session.state is 'WAITED SHORT TIME', so the process is almost always on CPU, not waiting. So, let's focus on CPU instead of Oracle's wait events and see what the process is busy doing. Since Linux 7 no longer has pstack as a separate package to install, instead of `yum install pstack', run `yum install gdb', which includes gstack, which pstack is a symbolic link to. mydbhost:~# pstack 868 | head <-- 868 is the CPU-hogging process running on behalf of rman #0 0x000000000f1b44dd in kgccgmtf () #1 0x000000000f1b7db9 in kgccbuf () #2 0x000000000f1b80cf in kgccm () #3 0x000000000f1b8445 in kgccbz2do () #4 0x0000000003dd9987 in kgccdo () #5 0x000000000cf5c875 in krbbcdo () #6 0x000000000cf3bf91 in krbb3crw () #7 0x000000000cf17ad9 in krbbpcint () #8 0x000000000cf13842 in krbbpc () #9 0x000000000cf89ecc in krbibpc () Repeat the command multiple times. Function kgccgmtf consistently shows up at the top. MOS (support.oracle.com) has no document specifically about this function. But those few that mention it (such as Doc 567796.1) talk about compression. (According to http://berxblog.blogspot.com/2011/11/, kgcc is for compression and mtf probably means move-to-front transform, a data encoding scheme.) Solution: Remove "as compressed backupset" from the backup command in the RMAN script, and re-run RMAN. Now the backup takes 11 minutes to complete. Most of the time, the oracle process shows __io_getevents_0_4 as the top function, which is doing real work. mydbhost:~# pstack 9168 | head #0 0x00007f3812b94644 in __io_getevents_0_4 () from /lib64/libaio.so.1 #1 0x0000000003deb72c in skgfrliopo () #2 0x0000000003deb254 in skgfrwat () #3 0x00000000032df0d2 in ksfdwtio () #4 0x00000000032eb60a in ksfdwat_internal () #5 0x00000000068a6386 in kfk_reap_ufs_async_io () #6 0x00000000012dd908 in kfk_reap_ios_from_subsys () #7 0x00000000012e9bb9 in kfk_reap_ios () #8 0x00000000012dfa69 in kfk_io1 () #9 0x00000000012de833 in kfk_transitIO () Analysis: The reason disabling compression speeds up the backup significantly is that this specific database contains mostly one single BLOB. The content is unknown to me but it must be something already compressed (like jpeg image). Data pump dumps of the database confirm this hypothesis: the dump file is barely reduced in size by gzip. A mystery is that this same data exists in a 11.2.0.4 database running on Red Hat Linux 6.10, with the database and OS and hardware configured as similarly as possible to this server and yet the compressed backup of that database takes only 1.5 hours. That LOB in both databases is basic (not securefile). The sizes are very close.