-
Hi Folks,
I'm using RMAN to do full-backup an 11GB database. RMAN is giving me exactly the same filesize. As you can imagine, this is unacceptable given the fact that the database is only about 35-40% used.
I've tried to do some clever stuff by creating a named pipe and compressing this pipe in the background using gzip. The problem is that RMAN will not output to my named pipe.
It gives error like "ORA-19504 Failed to create file" and ORA-27038 File exist". I know this file exist and I have also changed permission to 777 so that RMAN can at least modify it. But it doesn't!
Does anyone have any idea of how to compress RMAN backupsets as they are produced. Don't tell me to compress after RMAN completes because I don't have the space for the full backup set.
This pipe business works very well for Exp/Imp. Why not RMAN?
Thanks,
Jide.
-
RMAN performs compression on its backups, which means that the server session does not write datafile blocks that have never been used. Image copies of a datafile, however, always contain all datafile blocks.
Data blocks in the datafile are grouped into buffers. When RMAN encounters a used data block in a buffer, it writes only the used block to the backup set. When RMAN encounters four contiguous buffers of unused input blocks, it writes one compression block (of size DB_BLOCK_SIZE) to the backup set.
Use the DB_FILE_DIRECT_IO_COUNT initialization parameter to set the size of the buffer. For example, set the parameter to a value of 64K. In this case, RMAN writes one compression block for each 256K of contiguous unused input blocks in the input file.
-
Hi Prasy,
I do know about the compression which RMAN does, but it still isn't efficient enough. The output backupset file is still huge! Imagine having an entire block written out when only a fraction of it is used!
How to assist the compression being done by RMAN by using OS system compression utility like gzip without first outputting the entire file is what I'm looking for.
Anyone with other ideas?
Jide.
-
Do you have the option to stream the data to tape? If you can do this at least once then you can implement an incremental backup strategy which would greatly reduce the size of your backup sets as only blocks that have been touched since a prior full or incremental backup will be copied. You do need a starting point however and your business requirements can determine if the database can be down a little bit longer to accomodate a full backup to tape.
