In addition to being careful when applying compression to already-compressed data, you should look into storing the LOB data in separate tablespaces, and then marking those tablespaces READ ONLY. Of course, you can only do this if your application doesn't change the LOBs after inserting, and if Partitioning is available (i.e. licensed) in your environment to allow you to partition the LOB data and mark the older partitions READ ONLY. But if you can do this, then the READ ONLY tablespaces won't be included in future full database backups.
If you can't use the READ ONLY + Partitioning approach, you could look into implementing an "incremental forever" backup strategy, in which case only the changed blocks in your database would be included in backups - and if the LOB data is mostly read only, this would greatly reduce the size and time of your backups.
-KJ -- Kevin Jernigan Senior Director Product Management Advanced Compression, Hybrid Columnar Compression (HCC), Database File System (DBFS), SecureFiles, Database Smart Flash Cache, Total Recall, Database Resource Manager (DBRM), Direct NFS Client (dNFS), Continuous Query Notification (CQN), Index Organized Tables (IOT), Information Lifecycle Management (ILM) (650) 607-0392 (o) (415) 710-8828 (m) On 12/19/13, 3:43 AM, Nuno Souto wrote:
On 17/12/2013 1:16 AM, Kumar Madduri wrote:Got some ideas from here for me to test but I would be interested in any feedback that I can get.If those LOBs contain already compressed data such as zip or jpgs, then it is likely trying to compress them further with RMAN will result in longer times and larger backup size than expected. Compressed data does not respond well to recursive attempts at compressing it further. give it a try without compression and if it results in faster backup with with smaller backup files, you know that's the case.
-- //www.freelists.org/webpage/oracle-l
