10.07.2015 Views

Expert Oracle Exadata - Parent Directory

Expert Oracle Exadata - Parent Directory

Expert Oracle Exadata - Parent Directory

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

CHAPTER 13 MIGRATING TO EXADATAtake a backup of the tablespaces in the transport set. Conversion between endian formats may be doneduring the RMAN backup or during the restore on the target system. Here are the steps for transportingtablespaces to <strong>Exadata</strong>:1. Identify tablespace object dependencies.2. Set tablespaces to read-only mode.3. Export metadata for the transport set using Data Pump.4. Take an RMAN backup of the tablespaces in the transport set.5. Copy the export files along with the data file backups to <strong>Exadata</strong>.6. Restore the data files from the RMAN backup to your <strong>Exadata</strong> database. If endianconversion is needed, use the CONVERT DATAFILE command to restore and convert thedatafiles simultaneously.7. Make the tablespaces read/write again.8. Using Data Pump, import the tablespace metadata into the <strong>Exadata</strong> database usingthe transport_datafiles parameter. You can optionally remap the schema of thetablespace contents using the remap_schema parameter.When to Use Transportable TablespacesTTS and XTTS are useful for migrating portions of the source database using the speed of RMAN. If partsof your database are ready to move to <strong>Exadata</strong> but others are not, TTS may be a good fit.What to Watch Out for with the Transportable Tablespace StrategyCheck your <strong>Oracle</strong> documentation for specific restrictions or caveats that may apply to your database.Watch out for tablespace and schema name collisions on the target database. Tablespaces must be putin read-only mode for the move, so this will incur downtime. You can run an RMAN backup of thetablespaces while they are in read/write mode to see how long this operation will take before decidingwhether TTS is an appropriate method or not for your migration.Physical StandbyIn the physical standby strategy, the target database is instantiated from a full backup of the sourcedatabase. The backup is restored to <strong>Exadata</strong> in the same way you would for the “Backup and Restore”strategy. Once the database is restored to <strong>Exadata</strong>, it is started in mount mode and kept in a continualstate of recovery. As changes occur in the source database, archived redo logs are generated andtransmitted to the Standby database where they are applied (Redo Apply). Unlike the “Backup andRestore” strategy this database is kept in recovery mode for a period of time. Because archived redo logsare constantly being applied to the Standby database, conversion from big-endian to little-endianformat is not supported. Standby databases have been around since version 7 of <strong>Oracle</strong>. The capability isinherent in the database architecture. Of course, back then you had to write scripts to monitor thearchive log destination on the source system and then copy them (usually via FTP) to the Standbysystem where another script handled applying them to the Standby database. In version 9i, <strong>Oracle</strong>458

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!