How to Migrate to Oracle 11g with Minimal Downtime

Transcription

1 How to Migrate to Oracle 11g with Minimal Downtime Written by Tom Chu, Product Manager & Tony Novak, Senior Systems Consultant Quest Software, Inc. WHITE PAPER

2 2010 Quest Software, Inc. ALL RIGHTS RESERVED. This document contains proprietary information protected by copyright. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording for any purpose without the written permission of Quest Software, Inc. ( Quest ). The information in this document is provided in connection with Quest products. No license, express or implied, by estoppel or otherwise, to any intellectual property right is granted by this document or in connection with the sale of Quest products. EXCEPT AS SET FORTH IN QUEST'S TERMS AND CONDITIONS AS SPECIFIED IN THE LICENSE AGREEMENT FOR THIS PRODUCT, QUEST ASSUMES NO LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL QUEST BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF QUEST HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Quest makes no representations or warranties with respect to the accuracy or completeness of the contents of this document and reserves the right to make changes to specifications and product descriptions at any time without notice. Quest does not make any commitment to update the information contained in this document. If you have any questions regarding your potential use of this material, contact: Quest Software World Headquarters LEGAL Dept 5 Polaris Way Aliso Viejo, CA legal@quest.com Refer to our Web site for regional and international office information. Trademarks Quest, Quest Software, the Quest Software logo, AccessManager, ActiveRoles, Aelita, Akonix, AppAssure, Benchmark Factory, Big Brother, BridgeAccess, BridgeAutoEscalate, BridgeSearch, BridgeTrak, BusinessInsight, ChangeAuditor, ChangeManager, Defender, DeployDirector, Desktop Authority, DirectoryAnalyzer, DirectoryTroubleshooter, DS Analyzer, DS Expert, Foglight, GPOADmin, Help Desk Authority, Imceda, IntelliProfile, InTrust, Invirtus, itoken, I/Watch, JClass, Jint, JProbe, LeccoTech, LiteSpeed, LiveReorg, LogADmin, MessageStats, Monosphere, MultSess, NBSpool, NetBase, NetControl, Npulse, NetPro, PassGo, PerformaSure, Point,Click,Done!, PowerGUI, Quest Central, Quest vtoolkit, Quest vworkspace, ReportADmin, RestoreADmin, ScriptLogic, Security Lifecycle Map, SelfServiceADmin, SharePlex, Sitraka, SmartAlarm, Spotlight, SQL Navigator, SQL Watch, SQLab, Stat, StealthCollect, Storage Horizon, Tag and Follow, Toad, T.O.A.D., Toad World, vautomator, vcontrol, vconverter, vfoglight, voptimizer, vranger, Vintela, Virtual DBA, VizionCore, Vizioncore vautomation Suite, Vizioncore vbackup, Vizioncore vessentials, Vizioncore vmigrator, Vizioncore vreplicator, WebDefender, Webthority, Xaffire, and XRT are trademarks and registered trademarks of Quest Software, Inc in the United States of America and other countries. Other trademarks and registered trademarks used in this guide are property of their respective owners. Updated March 2010 White Paper - How to Migrate to Oracle 11g with Minimal Downtime 2

3 Contents Introduction... 5 About Migrations... 6 Types of Migrations and Their Benefits... 6 Hardware Migrations... 6 Operating System Migrations... 6 Oracle Migrations... 6 Challenges of Migrations... 6 Minimizing Downtime... 6 Planning for Recovery... 7 Best Practices for Migrations... 7 Plan Carefully... 7 Consider Using Export/Import to Restructure Data... 7 Disable Triggers and Cascade Delete Constraints... 8 Import into a New Database Shell... 8 Plan Your Rollback Strategy... 8 Consider Investing in a Log-based Replication Solution... 8 Why Upgrade Oracle What are the Improvements with Oracle 11g?... 9 Improvements in Oracle 11gR Improvements in Oracle 11gR The Oracle Migration Process Overview Step 1. Create a Target Instance (v11g) Step 2. Set up Replication from Source (v9i) to Target (v11g) Step 3. Upgrade the Target Instance Step 4. Resume Replication from Source to Target Step 5. Thoroughly Test the Target Instance Step 5a. Perform Preliminary Checks Step 5b. Implement Desired Oracle 11g Features Step 5c. Test Updating Applications on Oracle 11g Step 6. Set up Replication from Target to Source White Paper - How to Migrate to Oracle 11g with Minimal Downtime 3

4 Step 7. Switch Users to the Target Instance (v11g) Use the Source Instance as a Fallback Step 8. Upgrade the Source 9i System in Minutes Conclusion About the Authors About Quest Software, Inc White Paper - How to Migrate to Oracle 11g with Minimal Downtime 4

5 Introduction In these tough economic times, organizations are trying to lower costs in all of their business operations. One key method for cutting IT costs is migration: migration to hardware that is less expensive to purchase and operate; migration to less costly operating systems; and migration away from older versions of Oracle that may require expensive extended-support contracts. This paper provides an overview of the types of migrations and their challenges, and describes the established best practices for ensuring success. It also provides details on a proven process for upgrading to Oracle11g that minimizes downtime and the risk of failure by using a data replication solution such as Quest SharePlex for Oracle. White Paper - How to Migrate to Oracle 11g with Minimal Downtime 5

6 About Migrations Types of Migrations and Their Benefits Organizations can choose from among several different kinds of migrations, depending on their needs: Hardware Migrations Many organizations with large Unix servers are looking to reduce operating costs, such as power, cooling, hardware and space requirements. These organizations often choose to migrate to newer, lower-cost hardware, such as servers or disk arrays, that are faster and more reliable than their old systems, or that can be configured as a RAC environment for the same or lower cost. Another option is to migrate to a virtualized environment and run more VM servers on fewer large machines. Operating System Migrations Organizations are also reducing operating costs by moving applications onto less expensive operating systems, such as Linux. Operating system migrations can also be necessitated by a move to a virtualized environment. In addition to saving money, operating system migrations can offer valuable flexibility, such as the ability to allocate more memory to particular Oracle instances. Oracle Migrations A number of organizations are still running older versions of Oracle that either require extended support contracts or are no longer supported. Migrating to a current version of Oracle can reduce support costs and ensure the benefits of running a supported version. In addition, you can avoid spending capital on an extended support contract. Organizations are also moving to Oracle Standard Edition in place of Enterprise Edition on less critical database servers to lower operating costs. Standard Edition is not as feature rich as Enterprise Edition, but it offers the same level of reliability and robustness at up to 40 percent less cost. It can run many departmental applications with small to mid-size workloads. Standard Edition is also used for reporting databases, small data repositories, testing applications and web-based 2.0 applications. Challenges of Migrations The key challenges of migrations relate to their potential to disrupt the business. Therefore, two important tasks are to minimize user downtime and establish a sound recovery plan. Minimizing Downtime Before the era of 24x7 operations, upgrades were scheduled for the weekend. Users would log off early Friday afternoon, IT staff would perform a complete backup, and then the upgrade would start. The main goal was to make sure the systems were operational Monday morning either because the upgrade was successful or because the backup from Friday afternoon had been restored before users arrived on Monday morning. White Paper - How to Migrate to Oracle 11g with Minimal Downtime 6

7 Today, being offline for an hour, much less a whole weekend is completely unacceptable, especially for environments such as e-commerce, where a major portion of the week s revenue is generated on weekends. Therefore, every step of the upgrade process must be fine-tuned to minimize downtime for the end user. Is a cold backup necessary? Can we just make a disk copy of the database? Do we have the additional space needed for the migration? Do we have the best recovery technique? Some risks can be anticipated and minimized. For instance, an upgrade requires more disk space and memory than is used in day-to-day operations. If the system doesn t have these extra resources available, the upgrade could easily fail. Other failures can be the result of unexpected problems, such as media failure, a bad backup or a power outage. Some of those risks can be reduced by checking the validity of a backup, which takes a few minutes but is well worth the investment. Imagine needing to revert to the backup and finding that your fallback position is flawed! Planning for Recovery Another significant migration challenge is adequately testing applications after migration to avoid the need for rolling back to the pre-migration environment. Ideally, you want to thoroughly test your applications after the migration before making them available to your user community, but this is seldom possible due to the pressures to get the system back online as fast as possible. What happens if the application does not perform as well on the new version of Oracle or the new OS with a full production workload? Even worse, what if the migration works flawlessly and your users work with the application for a couple of days, but then some part of the application does not work correctly? You must find a way to recover back to the old version of Oracle or the old OS where everything was working, without losing the transactions from the last few days. Best Practices for Migrations Following the best practices outlined below can help ensure the success of your hardware, operating system, or Oracle migration by minimizing the risks of downtime and need for rollback. Plan Carefully There are risks inherent in any migration, including media failures, power outages or running out of time, memory or disk space. Proper planning can help mitigate these risks. Be sure to test as many steps of your migration process as you can and to test multiple times. Document the process carefully to minimize the risk of human error: instead of having to remember various details, you can simply follow your written plan. Consider Using Export/Import to Restructure Data If you are migrating to a new operating system, the only way to move your data to the new OS is by executing an export/import; you cannot simply back up the database and recover to the new server because of file format incompatibilities. But even migrations that do not require export/import can often benefit from it. Export/import enables you to restructure all of the data in your database and clean up any fragmentation. Laying out a database differently can relieve I/O hot spots or enable you to spread out the data into separate tablespaces. However, be aware that with large databases, the export/import process can take a long time. White Paper - How to Migrate to Oracle 11g with Minimal Downtime 7

8 Disable Triggers and Cascade Delete Constraints In any migration, when using a replication technology such as Shareplex for Oracle, be sure to disable triggers and cascade delete constraints on the new instance until it is time to go live in that environment. Otherwise, if the triggers and constraints were to manipulate data in the old environment, those data changes will be replicated via Shareplex to the new instance. If the triggers or cascade delete constraints are enabled on the target, they will execute again and cause out-of-sync conditions. Import into a New Database Shell To take advantage of some of the features of recent Oracle versions, you need to import into a new database shell rather than use the database upgrade script. For example, version 9i included the ability to change the block size of tablespaces, which is achieved by recreating the tablespaces. If you did not take advantage of these new features when you migrated to 9i, or your application did not support them, be sure to import into a new database shell so you can build the tablespaces you need to use this functionality. Plan Your Rollback Strategy Be sure to plan a rollback strategy in case something does not work correctly in the migration. If you are performing an OS upgrade or Oracle migration to a new server, you can usually recover your backup of the original database to the new server. In the case of an OS upgrade, you don t need to do anything else. In the case of an Oracle upgrade, you also need to go through the Oracle upgrade process after the recovery is complete. A safe failback option is to have a replication solution such as Quest SharePlex for Oracle. With SharePlex, you can replicate from the new version of Oracle back to the older version. This safeguards your data if your application does not work correctly after migration, regardless of how much work your users have done since the migration. You can failback to the older version with no loss of user data. Consider Investing in a Log-based Replication Solution A log-based replication solution, such as SharePlex for Oracle, will help minimize downtime and therefore also decrease the impact of the migration on your business. With such a solution, you can manage the migration process behind the scenes, and you ll never have to take your users offline except for a short period when you switch them over to the new database. White Paper - How to Migrate to Oracle 11g with Minimal Downtime 8

9 Why Upgrade Oracle What are the Improvements with Oracle 11g? Oracle version 11g offers new features and enhancements that can make upgrading worthwhile. Improvements in Oracle 11gR2 Some of the features in Oracle s newest release include: Column-level data storage for Exadata. This is a new data storage model with row storage replaced by columnlevel data storage. These column-oriented databases can use compression algorithms to detect patterns in the columns and achieve very high rates of data compression. This packs more data onto each data block, making data warehouse queries run even faster. Oracle flash cache is for systems not already running an SSD back end and resembles the assignment of highuse objects to the KEEP pool. It is designed exclusively for flash, solid-state RAM memory, which is now up to 600 times faster than platter disks. Oracle Omotion is a new online migration utility that is used to facilitate instance relocation in cases involving server failure. This uses far less resources than Data Guard (which requires a standby server) and Streams. With instance relocation, a single standby server could serve hundreds of instances. RAC One Node is multiple instances of RAC running on a single node in a cluster. It has a fast instance relocation feature for cases of catastrophic server failure. Improvements in Oracle 11gR1 Oracle's 11gR1 release provides improvements in many areas, including the following: Oracle Real Application Testing enables customers to stress test their applications before deployment into production, thereby reducing risk and ensuring a smooth deployment Server and client-side caching improves repeatable statements A native compiler for SQL and Java greatly enhances the speed of processing of these objects Optimizer statistics gathering is faster and more accurate Automatic Performance Diagnostics and Monitoring liberates DBAs from manual tasks Improvements in application tuning eliminate the need for manual tuning White Paper - How to Migrate to Oracle 11g with Minimal Downtime 9

10 The Oracle Migration Process Overview You can help ensure a successful upgrade and minimal interruption to production by using the right process and taking advantage of data replication technology. The procedure we recommend for migrating from older versions of Oracle to 11g involves the following steps. We will use Oracle 9i in our example, but this can apply for any older Oracle version: 1. Create a target instance (v11g) 2. Set up replication from source (v9i) to target (v11g) 3. Upgrade the target instance 4. Resume replication from source to target 5. Test the target instance thoroughly 6. Set up replication from target to source 7. Switch users to the target (use the source instance as a fallback if necessary) 8. Upgrade the source instance in minutes Step 1. Create a Target Instance (v11g) The first step is to make a copy of the production database on which to practice and test the upgrade. This can be accomplished in many ways, but the easiest method is to use disk mirroring: split the mirrors and begin replication. Mount the copy on the same mountpoint on another system, and open the instance. After the instance completes its recovery, replication can be started on this system, allowing the transactions that have queued since replication was initiated to post to the target instance. White Paper - How to Migrate to Oracle 11g with Minimal Downtime 10

11 Step 2. Set up Replication from Source (v9i) to Target (v11g) Once you have the target system established via Disk Mirroring, you will need to setup the data replication between source and target so they can continuously replicate production data. Some of the tests to be performed after the update require replication of production activity so you can have genuine production volumes and varieties of transactions going through your target instance. Therefore, the next step is to initiate the data replication. Make sure that you are replicating all of the production tables and sequences so your tests will be complete. If you are using a log-based replication product, such as SharePlex for Oracle, be certain to disable triggers on the target instance. Triggers should not modify the target data, since the results of their actions on the production system were recorded in the redo logs and already replicated. Step 3. Upgrade the Target Instance Once you have replication running, you are ready to perform the upgrade on the target instance. To do so, suspend updates to the target instance and allow the replication product to queue its records of the production activity. Perform the upgrade per Oracle s instructions. Step 4. Resume Replication from Source to Target When you are finished with the upgrade of the target instance, resume replication, allowing the queued transactions to be applied to your new Oracle 11g instance. Step 5. Thoroughly Test the Target Instance Step 5a. Perform Preliminary Checks Replicating production activity is a great start toward testing your newly upgraded instance, because it includes a volume and variety of transactions that would take hours of development work to duplicate. Use replication for at least two days as the only form of a test against the instance. Next, begin running read-only tests, checking your reports and queries for Oracle 11g compatibility. Step 5b. Implement Desired Oracle 11g Features Implement the features that influenced your decision to upgrade to Oracle 11g. Step 5c. Test Updating Applications on Oracle 11g This is undoubtedly the largest part of the task verifying that all applications, packaged and custom, are compatible with the new database. It consists of multiple steps: Plan the Tests First, make a list of all the applications you will test. You may want to organize the list by importance or complexity. (You also may need to organize some of the applications to respect their interdependencies.) The order of your list is not as important as its completeness. Having a list that you can update with the date, time and results is important, because you may forget which applications you actually tested. Be sure to include special periodic applications, such as month-end, quarter-end and year-end processes. White Paper - How to Migrate to Oracle 11g with Minimal Downtime 11

12 Run a Test To test an application that updates the data in your target instance, first stop the replication update process. Next, start a development diagnostic tool so you can determine which tables and sequences are affected by the application. Then run the test and check its results. Reset the Test Environment after Each Test Your options for resetting your target instance depend on the technologies available to the project and the extent of changes made by your tests. If the application you tested made a few changes to some large tables, a quick method to re-sync them is to use DataEquator, a compare-and-repair utility provided with SharePlex for Oracle. It compares the data within pairs of tables and builds a script to make the second table in each pair match the first. You can run the script when you are ready to reset the target instance. Another option is to simply store the target database to tape prior to the test, and restore it afterward (if the changes were massive and the tables have extensive chaining). You also could use the flashback mechanism in Oracle to roll back the tests. Another option is to re-sync from the production system. To do this, you need a list of all the schema changes you ve made on the target instance, both from the upgrade itself and from the Oracle 11g features you implemented. Toad for Oracle from Quest Software can facilitate this process by comparing schemas on the two systems and creating a script of deltas. (You won t run the script on the production system, but you will run it on a copy of the production system.) With that script prepared, you can repeat the process you performed to create the target instance: break the mirrors on the production system, move the copy to the target system, mount it on the same mountpoint, and open the instance. Next, reconcile the image created using the mirroring technique with the transactions contained in the replication queues, eliminating transactions already reflected in the image created through mirroring. Finally, run the script to apply the schema changes, and voila! You have built a fresh, consistent image of production data on your Oracle 11g target instance. When you have completed your test cycles, re-sync the target instance with the production instance once more. Step 6. Set up Replication from Target to Source Next, set up replication in the opposite direction from Oracle 11g to Oracle 9i. Be careful to avoid setting up a neverending loop for any transaction. The default mode of SharePlex for Oracle disables such looping of replication. If you are using another replication product, verify that it will not replicate from one system to the other and back again, endlessly. Step 7. Switch Users to the Target Instance (v11g) When production is least active, quiesce the production system and flush all transactions to the Oracle 11g instance. With all of those transactions posted, you can allow your users to begin working on the new Oracle 11g system. Use the Source Instance as a Fallback There s nothing like having users on a new version of software and the database to help you identify things missed during testing. All issues should be minor. However, if a major issue does arise at a critical time, you have a fallback plan in place: since you are now replicating from Oracle 11g to Oracle 9i, you have the option of redirecting your users to the source 9i system, which is now serving as a backup. The backup system has all of the users work on an Oracle 9i instance, where your applications ran successfully in the past. If a critical application hits a significant snag with Oracle 11g, you can switch the users back to Oracle 9i and continue business. Your IT staff can then determine what needs to be modified to make the application fully compatible with Oracle 11g, fix it, and prepare to switch the users to Oracle 11g again. White Paper - How to Migrate to Oracle 11g with Minimal Downtime 12

13 Step 8. Upgrade the Source 9i System in Minutes Once your production environment has run successfully with the Oracle 11g database and applications long enough to give you confidence in the new version, you will want to upgrade your backup system to Oracle 11g. This process is faster and easier than the original upgrade because you have the data and the applications ready. You simply need to make a copy of them for the other system. Basically, you ll repeat the process you performed when you created the test instance, but in reverse. Split the mirrors on the Oracle 11g instance s system, move the copy to the backup system, mount it at the same mountpoint, and open the instance. Then tell the replication process to perform its reconciliation so that it eliminates transactions from its queues represented in the instance created via the mirroring solution, and then resume active replication. Before shifting the users to the original production system (which has been serving as the backup), set up replication in the opposite direction (source to target). This will prepare you to resume normal operations. Then, when you re ready, you simply quiesce the production system (the target instance), flush the transactions to the backup system (the source), and redirect the users. With replication in place, you can use that secondary instance for day-to-day reports, queries or high availability needs maximizing your primary system s OLTP performance and availability. And you can perform routine maintenance on the production system without interrupting production activity, because that activity can continue on the alternate system. White Paper - How to Migrate to Oracle 11g with Minimal Downtime 13

14 Conclusion By following established best practices for migrations and using the process outlined here for upgrading from older versions of Oracle to 11g, you can minimize downtime and the risk of upgrade failure. In particular, investing in a data replication solution such as Shareplex for Oracle can minimize the downtime required for the migration, helping you meet SLAs for application downtime and reducing IT costs in the process. Shareplex enables you to manage the movement of data to the new environment while your application is still up and running, so the migration will be seamless to your end users. In fact, customers using the approach outlined in this paper have reduced their downtime by an average of 94 percent: the interruption to production users is limited to the time required to switch them from one system to the other and times of replication activation. This approach also minimizes risk, because the upgrade isn t performed directly on the production system and users are not switched until the upgrade has been thoroughly tested and deemed successful. White Paper - How to Migrate to Oracle 11g with Minimal Downtime 14

15 About the Authors Tom Chu has more than 15 years of experience working with data replication solutions. He joined Quest Software in 1994 and has worked with SharePlex for Oracle since its inception in Tom has served in multiple roles for the SharePlex team, including product management, business development and technical consulting. Tony Novak is a strategic systems consultant with 20 years of experience in Oracle database environments as a DBA and an expert consultant. Tony has been with Quest Software for the past nine years as a lead expert on SharePlex for Oracle and data replication solutions. He is considered the high availability specialist in North America at Quest. Tony has provided consultation for hundreds of customers on designing data replication plans and implementation strategies. White Paper - How to Migrate to Oracle 11g with Minimal Downtime 15

16 WHITE PAPER About Quest Software, Inc. Now more than ever, organizations need to work smart and improve efficiency. Quest Software creates and supports smart systems management products helping our customers solve everyday IT challenges faster and easier. Visit for more information. Contacting Quest Software PHONE (United States and Canada) If you are located outside North America, you can find your local office information on our Web site. MAIL Quest Software, Inc. World Headquarters 5 Polaris Way Aliso Viejo, CA USA WEB SITE Contacting Quest Support Quest Support is available to customers who have a trial version of a Quest product or who have purchased a commercial version and have a valid maintenance contract. Quest Support provides around-the-clock coverage with SupportLink, our Web self-service. Visit SupportLink at SupportLink gives users of Quest Software products the ability to: Search Quest s online Knowledgebase Download the latest releases, documentation, and patches for Quest products Log support cases Manage existing support cases View the Global Support Guide for a detailed explanation of support programs, online services, contact information, and policies and procedures. 5 Polaris Way, Aliso Viejo, CA PHONE WEB sales@quest.com If you are located outside North America, you can find your local office information on our Web site Quest Software, Inc. ALL RIGHTS RESERVED Quest Software is a registered trademark of Quest Software, Inc. in the U.S.A. and/or other countries. All other trademarks and registered trademarks are property of their respective owners. WPD-Upgrad2Oracle11gWithMinimalDowntime-US-AG