Expert Oracle Exadata - Parent Directory

CHAPTER 13 MIGRATING TO EXADATANote that some large DW databases are designed to use NOLOGGING for large data loads to save CPUand disk space (fewer archive logs generated). These databases rely on incremental backups plus datareloads as a recovery strategy. In such databases, forcing redo logging for everything may causeunacceptable performance degradation and archive log generation. In those cases it makes sense toconfigure the ETL engine to perform loads to both the old and new DW system during the transitionperiod.Sequences are not replicated. They must be dropped from the target and recreated from the sourcedatabase during the final cut-over. Triggers on the target tables must be disabled during replication andre-enabled during the final cut-over (after replication has been shut off).Logical StandbyAnother type of replication useful for database migration is logical standby. Logical standby is a built-infeature of the Oracle database. It was introduced in version 9i release 2 as an extension or additionalfeature of Data Guard (formerly Physical Standby). On the surface, this strategy sounds a lot like Streamsand Golden Gate in that it is basically doing the same thing. Changes to the source database are minedfrom the redo (or archived redo) and converted to SQL statements and executed on the target database.As in other logical replication methods, the database is open and available while replication is running.Logical standby is far more restrictive than Streams or Golden Gate. Because the logical standby isactually instantiated from a physical, block-for-block, copy of the source database, several rules comeinto play. The database version must be the same for the source and the target databases, even down tothe patch level. With few exceptions, source and target platforms must also match at least within theprocessor architecture. For example, logical standby does support a source database running on anAMD64 processor architecture while the target database, Exadata in our case, runs on an Intel EM64Tprocessor. The operating system for both source and target must be the same, although differentdistributions of Linux will work. For example, you could be running Suse Linux on the source system butOracle Enterprise Linux on the target as long as the Linux kernel is the same.It might surprise you to know that while indexes and materialized views can be created in the targetdatabase, you cannot use logical standby to implement a partitioning strategy there. For example, youcan create or drop indexes on a target table, but you cannot pause replication, drop the table, recreate itas a partitioned table, reload it, and resume replication. Table compression is not supported, either. Wetried working around that by compressing the table after converting the target database from a physicalto a logical standby, but that doesn’t work. Remember that HCC compression only works with directpath load, and logical standby applies changes using conventional inserts. Compression and tablepartitioning are very important performance strategies for Exadata. The lack of support for thesefeatures is a significant downside for logical standby.The list of unsupported data types is the same for logical standby as it is for Streams and GoldenGate:• BFILE• ROWID, UROWID• User-defined types• Collections (including VARRAYS and nested tables)• XMLType stored object relationally or as binary XML• Multimedia data types (including Spatial, Image, and Oracle Text)448