Written by Syed Jaffar Hussain This part of the article series is going to summarize the most commonly adopted database migration approaches and tools to migrate an existing Oracle databases to Exadata Database Machine. Though database migration process and methods largely remains identical between non-Exadata and Exadata, I am going to describe some of the golden rules to choose a right/best approach to your Exadata database migration as not all migration requirements doesn’t’ apply to all scenarios. Also, this paper will focus on some of the best recommendation on network requirements to speed up large databases migration process. Summary An Oracle database migration process typically refers moving a database between different Operating Systems, or migrating from non-Oracle databases to Oracle, (for example, from SQL Server, MS Access, Terradata, DB2, Sybase and Informix to Oracle). Oracle provides various mechanism to perform database migration as there is no single best approach to match the requirements and business needs to all database migrations. One should pick the right migration approach that address business needs, benefits and risks. The following picture depicts the migration challenges and risks involved with database migration process: All Exadata database migration involves the following migration paths: Exadata database migration scenarios Once the Exadata Database machine is arrived and basic configuration is over, the next tough job at hands for an Organization and the technical teams involved is choosing the right database migration approach which can provide minimal downtime, less risk and potentially the fallback plan. Following is the list of common scenarios: Migrating from non-Exadata with: Different platforms with same Oracle version Different platforms with different Oracle versions Similar platform with different Oracle version Similar platform with same Oracle version Migrating from old Exadata Database machine to the new Exadata Machine Common Exadata migration methods Below is the list of some of widely used Exadata migration approaches: Logical Migration methods Data Pump Logical Standby Oracle Golden Gate Create Table As Select (CTAS) Physical Migration methods Physical Standby Transportable Tablespaces (TDB) Transportable Database (TTE) Cross platform transportable tablespaces and incremental backups (XTTS) ASM Online Migration Whenever it comes to database migration or upgrades, a very common question that is typically bothered to the higher management and application owners is the downtime required to complete the task. Will now dig into different migration mechanisms to address how to reduce the downtime and avoid the migration risks. Prerequisites and tools for a faster and smooth migration Let’s take a look at some of the following recommended areas to have a faster and smoother Exadata migration: Ensure latest Exadata patches are applied on the Exadata database machine Review the Database Upgrade Guide and Documentation A faster network is required to quickly move the data between the source and the Exadata machine. Exadata database machine supports 1Gb/s, 10Gb/s and 40Gb/s (InfniBand) network bandwidth. In order to match with the Exadata machine speed, you can upgrade or ensure that the source system network has the same speed. Most typically 10Gb/s is highly recommended while migrating large databases Consider using parallelism with Data pumps can give deliver significant performance gain Ensure the source system doesn’t suffer with I/O, CPU bottlenecks For larger cross platform migrations, use TTS with Incremental backups approach to reduce the overall downtime required At the heart of the Exadata machine, it is important to understand the following key points before performing the migration: No hardware changes can be done on the Exadata database machine Little endian ASM Oracle 11gR2 (minimum Oracle version that can be run over Exadata machine) Linux 64 or Solaris x86 OS Common migration methods Let’s take a look at some of the common migration methods Logical migration approaches Data Pumps approach is the most common and broadly used method to migrate databases. With data pumps any Oracle version 10.1 or higher from any source system can be easily migrated onto the Exadata. This is also a preferred method if you want to compress (HCC) the database while migration as Oracle Data pumps uses direct load method to load the data to the target database. This supports traditional data unloading to a dump file followed by uploading the onto the target system, also, you can directly upload the data onto Exadata using the network feature which eliminates the need of having a big dump file. Use parallelism to speed the data unload and upload process. Oracle Golden Gate approach there are so many benefits of using Golden Gate to perform the database migration. It’s very flexible, a database from any platform, any endian format and Oracle version 9.1 above can be easily migrated online, mostly, nearly zero downtime. However, there are some limitations/restrictions with some Oracle data types which you will have look at closely and investigated before the migration. The following benefits are foreseen with this approach: Minimal downtime Online migration from different source systems Zero data loss and Fallback plan with bi-directional replication Physical migration approaches Physical Standby database approach typically takes very less downtime when migrating from an old Exadata database machine to the newest Exadata machine. This approach is simply requires creating and configuring the Data Guard (Physical Standby database) on the target Exadata database machine and when ready, just perform the switchover to complete the migration. If the Oracle version between the Exadata machines is different, first perform the in-place database upgrade on the source Exadata machine and subsequently proceed with the Physical Standby database setup. The overall downtime is measured by the time consumed to perform the switchover operation, which is pretty low in most of the cases. On the other hand, Oracle also supports unlimited number of Heterogeneous Data Guard configuration between primary and the standby databases. For example, primary database running on a windows system and standby database running on the Linux 64bit system. The approach involves the following procedure: Upgrade the source database using any existing method to match the latest version on the target Exadata database machine Configure standby database on the target Exadata machine Once the data is completely synchronized, perform the switchover Transportable database approach (TDB) if the source system is running Oracle 11.2 or above with Little Endian format, this method can be used to migrate the database to Exadata. {Cross platform} - Transportable tablespaces approach (TTS) is the most flexible migration method which can be used to migrate any Oracle 10.1 or later version and any platform (endian format, for example from big endian). This is the most suitable migration approach when the source system is on IBM or HPUX systems. The approach involves the following procedure Creating a new database Put the source database tablespaces in READ ONLY mode Copy the source datafiles over the Exadata machine, if the source is big endian, then convert the data files to match the little endian format Plug in the data files to the database on the Exadata Export the metadata from the source system Import the metadata to the target system Put the source tablespace back to READ WRITE mode Following image depicts the procedure involved when performing cross platform transportable tablespaces and indicates the full downtime. XTTS and Incremental backups approach when you have a requirement to move large and extremely large cross platform databases to Exadata database machine, the cross platform transportable tablespaces with incremental backups is the best approach. This will not only reduce the overall downtime, helps to move online changes during the procedure. Following are the steps involved in this procedure: Transfer the datafiles to the target system and convert them to required endian format while the source database remain online Create incremental backups on the source system and transfer the backups to the source system Convert the incremental backups to match the target endian format and apply the incremental backups on the target system Put the source database tablespace in READ ONLY mode, perform incremental backups one more time Convert the incremental backups to match the target endian format and apply the incremental backup on the target system Export the metdata on the source system and import the metadata on the target system Make the source tablespace back to READ WRITE mode Following image depicts the procedure involved when performing cross platform transportable tablespaces with incremental backups and indicates the online (green color) and downtime required. Post Exadata database migration steps Here are a few post Exadata database migration steps that you should consider: Get rid-off unwanted indexes with ALTER INDEX INVISABLE followed by DROP INDEX to make use to Exadata SMART SCAN benefits Compress the data with HCC to gain storage savings Gather Exadata system stats using EXEC DBMS_STATS.GATHER_SYSTEM_STATS(‘EXADATA’) Configure IORM to manage the IO resources when multiple databases are running on a DB node Conclusion This paper has summarized most commonly used database migration methods, their pros and cons. Also, make you understand the various methods and procedures. Now it’s up to you to select the right method that best fits and suits to your business needs. Image Courtesy: Oracle presentations References: Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 1389592.1) http://www.oracle.com/au/products/database/xmigration-11-133466.pdf
↧