Expert Oracle Exadata - Parent Directory

CHAPTER 9 RECOVERING EXADATAcompressed data. For example, the following error is returned when you select from an HCC table on astandard 11.2.x database:SQL> select distinct segment_name from bigtab_arch_high;select distinct segment_name from small_table_arch_high*ERROR at line 1:ORA-64307: hybrid columnar compression is only supported in tablespaces residing on ExadatastorageYour compressed data is still intact. You just cannot read it unless you first uncompress it. HCCcompressedtables can be uncompressed on non-Exadata databases using the ALTER TABLE MOVEcommand as follows:SQL> alter table BIGTAB_ARCHIVE_HIGH move nocompress;Partitioned tables can be uncompressed in a similar manner, and the operation can be parallelizedusing the parallel option, as you can see in the following command:SQL> alter table BIGTAB_ARCHIVE_HIGH move partition JAN_2011 nocompress parallel;Once the table is uncompressed, it can be read from a non-Exadata database. Keep in mind thatwith the high degree of compression HCC provides, you must take into consideration the additional diskstorage that will be required by the uncompressed table or partition, which can be quite substantial.Exadata Optimizations for RMANWhen RMAN performs an incremental backup on the Exadata platform, cellsrv filters out unwantedblocks and sends back only those that have changed since the last level 0 or level 1 backup. Thisimproves the performance of incremental backups and reduces the workload on the database server.But even when only a relatively small number of blocks have changed, discovering them is a very I/Ointensiveprocess, because every block in the database must be examined to determine which ones havechanged since the last incremental backup. This is true for both Exadata and non-Exadata databases.The only difference is where the work is done; on the database server, or on the storage cells. A few yearsago, Oracle 10g introduced block change tracking (BCT) to address this problem. Of course this was longbefore Exadata came onto the scene. This feature maintains a bitmap structure in a file called the blockchange tracking file. Each bit in the BCT file (1 bit per 32K of data) represents a group of blocks in thedatabase. When a data block is modified, Oracle flips a bit in the BCT file representing the group ofblocks in which the changed block resides. When an incremental backup is taken, RMAN retrieves thewhole group of blocks (represented by a flipped bit in the BCT file), and examines them to determinewhich one changed. Block change tracking introduces minimal overhead on the database server and is avery efficient way to track changed blocks. And, since it greatly reduces the number of blocks that mustbe examined during a backup, it improves backup performance while reducing the workload on thedatabase server and storage grid.For the Exadata platform, you may choose to allow cellsrv to do all of the block filtering forincremental backups, or use it in tandem with block change tracking. Block change tracking seems toprovide the most benefit when fewer than 20 percent of the blocks in the database have changed sincethe last level 0 or level 1 backup. If your database is close to that threshold, you should do some testing todetermine whether or not BCT improves incremental backup performance. The BLOCKS_SKIPPED_IN_CELLcolumn of the V$BACKUP_DATAFILE view shows the number of blocks that were read and filtered out at thestorage cell. This offloading is transparent and requires no user intervention or special parameters to beset ahead of time.295