Expert Oracle Exadata - Parent Directory

CHAPTER 13 MIGRATING TO EXADATAPlanning VLDB Migration DowntimeWhen you are estimating the downtime or data migration time, you should only rely on actualmeasurements in your environment, with your data, your network connection, database settings andcompression options. While it is possible to load raw data to a full rack at 5TB/hour (Exadata V2) or even10 TB/hour (Exadata X2-2), you probably won’t get such loading speeds when the target tables arecompressed with ARCHIVE or QUERY HIGH. No matter which numbers you find from this book or officialspecs, you will have to test everything out yourself, end to end. There are some temporary workaroundsfor improving loading rates, for example, if you have enough disk space, you can first load to noncompressedor EHCC QUERY LOW-compressed tables during the downtime window and once inproduction recompress individual partitions with higher compression rates.SummaryIn this lengthy chapter we looked into the wide range of tools available for migrating your data toExadata. You should choose the simplest approach you can as this reduces risk and can also save yourown time. We recommend you evaluate Data Pump first, as it can transfer the whole database orschema. And it can do the job fast and is even flexible when you want to adjust the object DDL metadatain the process. Often, however, this approach is not fast enough or requires too much temporary diskspace. It all depends on how much data you have to transfer and how much downtime you are allowed.When moving VLDBs that are tens or even hundreds of terabytes in size, you may have to get creativeand use less straightforward approaches like database links, copying read-only data in advance, orperhaps doing a completely incremental migration using one of the replication approaches.Every enterprise’s database environments and business requirements are different, but you can usethe methods explained in this chapter as building blocks. You may need to combine multiple techniquesif the migrated database is very large and the allowed downtime is small. No matter which techniquesyou use, the most important thing to remember is to test everything, the whole migration process fromend to end. You will likely find and fix many problems in advance thanks to systematic testing. Goodluck!465