Free Oracle RMAN 11g Backup and Recovery by Robert Freeman

lengths to protect the integrity of the Oracle data blocks within the files. RMAN, however, is different.
    Because RMAN is integrated into the RDBMS, it has access to your data at the same level that the database itself uses: the data block.
    Block-level access is what distinguishes RMAN from any other backup utility, and even if you didn’t already know this, it’s why you are reading this book and implementing an RMAN backup strategy. This is an extremely powerful level of access that provides nearly all the benefits that you will get from using RMAN. It is because of this access that we can utilize the data block for more efficient backup and recovery.
    The Data Block Backup Overview
    Here’s how it works: RMAN compiles the list of files to be backed up, based on the backup algorithm rules. Based on the number of channels and the number of files being simultaneously backed up, RMAN creates memory buffers in the Oracle shared memory segment. This is typically in the Private Global Area (PGA), but there are circumstances that push the memory buffers into the Shared Global Area (SGA). The channel server process then begins reading the datafiles and filling the RMAN buffers with these blocks. When a buffer is full, it pushes the blocks from an input buffer into an output buffer. This memory-to-memory write occurs for each individual data block in the datafile. If the block meets the criteria for being backed up and the Chapter 2: Introduction to the RMAN Architecture 45
    memory-to-memory write detected no corruption, then the block remains in the output buffer until the output buffer is full. Once full, the output buffer is pushed to the backup location—a disk or a tape, whichever it may be.
    Once the entire set of files has been filtered through the memory buffers, the backup piece is finished, and RMAN writes the completion time and name of the backup piece to the target database control file.
    The Benefits of Block-Level Backups
    Memory-to-memory writes occur for each block that is moved from disk into memory. During this operation, the block can be checked for corruption. Corruption checking is one of the nicest features of RMAN, and we discuss it in more detail in Chapter 12. Be aware that block checking is not used if you are performing a proxy copy.
    Null Block Compression
    Null block compression becomes an option when we have access to the data block. We can eliminate blocks that have never been used (have a zeroed header) and discard them during the memory-to-memory write. Therefore, we only back up blocks that have been used and that have a more efficient backup.
    This is a good place to mention the different misconceptions related to null block compression.
    The first misconception is that null compression eliminates empty blocks. The null compression algorithm has only two access points that RMAN has to the database: the file header and the block header. RMAN can only draw conclusions about the contents of a block from its header or from the file header information. Why no space management information? Space management information is only available when the database is open, and RMAN null compression cannot rely on the database being open. We must rely only on that information that we can get without an open database: namely, file headers and block headers. So, if you truncate a table, all the blocks that had information in them but are now empty will be backed up, because RMAN only knows that the block has been initialized by a segment. It does not know that the block is empty.
    The second common misconception about null block compression is that null compression saves time during the backup, as less is being backed up. This is true, to a certain extent, but only if your backup device is an extremely bad bottleneck. If you stream very quickly to your disk or tape backup location, then the act of eliminating blocks in memory saves little time, because RMAN is still reading every block in the file into