Safely upgrading an Oracle database using Remote Copy on the IBM Storwize V7000 storage system

Transcription

1 Safely upgrading an Oracle database using Remote Copy on the IBM Storwize V7000 storage system Configurations and benefits Mayur Shetty IBM Systems and Technology Group ISV Enablement May 2012

2 Table of contents 1 Abstract Introduction Overview Benefits of using this method Intended audience IBM Storwize V7000 storage technology stack IBM Storwize V7000 storage system overview IBM Storwize V7000 storage system functionalities IBM Storwize V7000 storage terminology Lab setup Test environment Storwize V7000 storage Host nodes Oracle configuration Setting up the Remote Copy feature Enabling a premium feature Setting up Enhanced Remote Copy Creating partnership between the IBM Storwize V7000 storage system and??? Creating a Remote Copy relationship between IBM Storwize V7000 volumes IBM Power Systems server setup for Remote Copy Detailed example for upgrading oracle Preparing the servers and storage Procedure on the source Procedure on the target Summary Resources About the author Trademarks and special notices Safely upgrading an Oracle database Using Remote Copy on the IBM Storwize V7000 storage system Copyright IBM Corporation, 2012

3 1 Abstract This paper explains the procedures for successfully using the Remote Copy feature of the IBM Storwize V7000 storage system, with Oracle Database Upgrade Assistant (DBUA), to upgrade Oracle Database 11g R1 to Oracle Database 11g R2. Using the IBM Storwize V7000 storage feature named remote copy, reduces the time and complexity of the upgrade by taking a mirrored set of disk drives from a production database and upgrades the database without affecting the production database. 2 Introduction This section provides an overview on the various topics explained in this paper, the assumptions made, and the intended audience who can benefit from this paper. 2.1 Overview When you need to perform a major upgrade of a production database, as an Oracle Database administrator, you have many options for performing the upgrade. In every case, there is some type of a replication or backup performed before the upgrade. You always need to provide a mirror image of the production database to be used for an upgrade to a new major release. You can use the mirror image for any of the following tasks: Testing an in place upgrade on a separate server than the production server Performing the upgrade on separate storage and servers to eliminate the impact on the current production database Migrating to new storages or servers during the upgrade Using the Remote Copy feature of IBM Storwize V7000 storage reduces the time and complexity of the upgrade. Remote copy allows you take a mirrored set of disk drives from a production database and upgrade the database without affecting the production database. This method uses Remote Copy to remotely mirror the Oracle database binary files, as well as all of the data files that make up the database. Using the Remote Copy feature allows you to create a similar environment where you can practice the upgrade. During practice, you can document the necessary steps before attempting the upgrade on the production database. This paper provides the procedures for successfully using Remote Copy with Oracle DBUA, to upgrade an Oracle Database 11gR1 to Oracle Database 11gR2. For more information about the functionality of Oracle DBUA or about the database upgrade process, refer to Oracle documentation. 2.2 Benefits of using this method When using Remote Copy, you can create a copy of the database and clone it onto a different server. Then, you can perform certain critical functions on the clone rather than on the production database. Using a clone for critical functions has several advantages, such as: No disruption of the source production database Fewer staff resources Anytime duplication of the database Data replication for recovery of the production database 1

4 There are many benefits of using the Remote Copy feature. The Remote Copy premium feature is an option for real-time replication of data that creates copies of the source logical drive on a second target storage subsystem. The second storage subsystem might reside within the same computing environment, or for disaster recovery purposes might reside many miles away or even in a different state or country. A fully-synchronized Remote Copy setup provides many ways to use the remote mirrors without disrupting the primary source logical drive. Remote Copy provides rapid recovery from a disaster or a catastrophic failure of the primary site by using role reversals to promote the secondary logical drive to a primary role. Hosts can then read and write to the newly promoted logical drives and business operations can continue. When you use Remote Copy to test an Oracle upgrade, Remote Copy has even more advantages: You can create another set of logical drives faster using Remote Copy compared to using RMAN, using a copy process, or using File Transfer Protocol (FTP). The increase in speed is a result of performing Remote Copy at the storage hardware level. You do not have to touch the data that is currently used for the source database. You can use the upgrade process to test an actual upgrade in place and work out any issues before attempting the upgrade on the production database. You can resynchronize the mirrors and start the process over if the upgrade process fails. 2.3 Intended audience The intended audience of this paper is an Oracle Database administrator with experience in the following areas: Oracle database and its related components Oracle database cloning Storage, including an understanding of data services and the premium features that support those services 3 IBM Storwize V7000 storage technology stack This section includes concepts related to the IBM Storwize V7000 storage systems. 3.1 IBM Storwize V7000 storage system overview The IBM Storwize V7000 storage solution provides a modular storage system that includes the capability to virtualize external storage area network (SAN) attached storage and its own internal storage. The IBM Storwize V7000 storage system provides a number of preset configuration options that are aimed at simplifying the implementation process. It also provides an active-active solution, and is a clustered, scalable, midrange storage, as well as an external virtualization device. Included with the IBM Storwize V7000 storage system is a simple and easy to use graphical user interface (GUI) that allows storage to be deployed quickly and efficiently. The GUI runs on the IBM Storwize V7000 storage system, and therefore, there is no need for a separate console. The IBM Storwize V7000 storage solution consists of a control enclosure, which includes the chassis, node canisters, drives, and energy sources that include batteries, expansion enclosures (which are hardware units that includes expansion canisters, drives, and energy sources) that do not include batteries. Within each enclosure, there are two canisters (which are the hardware units) that includes the node hardware, 2

5 fabric and service interfaces, and serial-attached SCSI (SAS) expansion ports, determining the role of the enclosure IBM Storwize V7000 storage system functionalities The following functionalities are available with the IBM Storwize V7000 storage system: Thin provisioning: With thin provisioning, applications can grow dynamically, but consume only the space that they are actually using. Without thin provisioning, pre-allocated space is reserved irrespective of whether the application uses it or not. Volume mirroring: Volume mirroring provides a single volume image to the attached host systems while maintaining pointers to two copies of data in separate storage pools. Copies can be on completely separate disk storage systems that are being virtualized. IBM Tivoli Storage FlashCopy Manager: FlashCopy creates instant application copies that can be used for backup or application testing. FlashCopy makes better use of the space with incremental copy, where only the changed blocks are copied. Metro Mirror: Metro Mirror provides synchronous remote mirroring function up to approximately 300 km between sites. As the host I/O completes only after the data is cached at both the locations, performance requirements might limit the practical distance. Metro Mirror is designed to provide fully-synchronized copies at both the sites with zero data loss after the initial copy is completed. Global Mirror: Global Mirror provides long distance asynchronous remote mirroring function up to approximately 8,000 km between sites. With Global Mirror, the host I/O completes locally, and the changed data is sent to the remote site later. This is designed to maintain a consistent, recoverable copy of data at the remote site which lags behind the local site. Data migration: A data migration wizard can be used to import the external storage system into the IBM Storwize V7000 storage system. IBM System Storage Easy Tier : Provides a mechanism to seamlessly migrate hot spots to a higher performing storage pool within the IBM Storwize V7000 storage solution. This can be to internal drives within the IBM Storwize V7000 storage system or to external storage systems that are virtualized by the IBM Storwize V7000 storage system. 3

6 Figure 1: The IBM Storwize V7000 storage system virtualizing external and internal storage 4

7 3.1.2 IBM Storwize V7000 storage terminology Table 1 lists the Storwize V7000 storage terminology used in the paper. For an entire list of the Storwize V7000 storage terminology, refer to Implementing the IBM Storwize V at ibm.com/redbooks/redpieces/abstracts/sg html?open IBM Storwize V7000 storage term Control enclosure Expansion enclosure Node canister Host mapping Internal storage Managed disk (MDisk) Storage pool Thin provisioning or thin provisioned Volume Extent Definition A hardware unit that includes the chassis, node canisters, drives, and energy sources including batteries. A hardware unit that includes expansion canisters, drives, and energy sources that do not include batteries. A hardware unit that includes the node hardware, fabric and service interfaces, and SAS expansion ports. A controlling process in which hosts have access to only specific volumes within a cluster. Array-managed disks and drives that are held in enclosures and nodes that are part of the cluster. A component of a storage pool that is managed by a cluster. An MDisk is either a part of a RAID array of the internal storage or a Small Computer System Interface (SCSI) logical unit (LU) for external storage. An MDisk is not visible to a host system on the SAN. A collection of storage capacity that provides the capacity requirements for a volume. The ability to define a storage unit (full system, storage pool, or volume) with a logical capacity size that is larger than the physical capacity assigned to that storage unit. A discrete unit of storage on disk, tape, or other data recording medium that supports some form of identifier and parameter list, such as a volume label or I/O control. Each MDisk is divided into segments of equal size called extents. When a volume is created from a storage pool, the volume is allocated based on the number of extents required to satisfy the capacity requirements for the volume. Table 1: IBM Storwize V7000 storage terminology 5

8 4 Lab setup This section lists the hardware and software configurations that were used in the lab exercises. 4.1 Test environment Use the reference architectures as guidelines for setting up your own system environment. The reference architectures serve as examples only. You can modify the system environment as necessary to suit your needs. The following Figure 2 illustrates the reference architecture: The IBM Storwize V7000 storage reference architecture consists of one primary sever and one secondary server attached to two Storwize V7000 storage controller enclosures. Refer to Figure 2. Figure 2: IBM Storwize V7000 storage Remote Copy reference architecture 6

9 Figure 3 shows the logical drive configuration in the tests of IBM Storwize V7000 Remote Copy feature for Oracle upgrade. Figure 3: IBM Storwize V7000 storage volume configuration 4.2 Storwize V7000 storage The following table lists the node model and the software level used in the exercise. Node model IBM Storwize V7000 storage Software level Host nodes The following table lists the AIX hosts that were used in the exercise. Server type IBM pseries Processor IBM PowerPC Memory 16 GB Operating system (Pre-Upgrade Oracle host) 6.1 Operating system(post-upgrade Oracle host) Oracle configuration The following table shows the Oracle configuration used in the exercise Server version pre-upgrade Server version post-upgrade

10 5 Setting up the Remote Copy feature After the system environment is set up, the next step is to enable the Remote Copy premium feature. You can enable the feature from either host. You need to enable the feature only once for it to become enabled throughout the storage subsystem. To enable the premium feature, obtain the Feature Key file from IBM. 5.1 Enabling a premium feature You can configure the IBM Storwize V7000 storage license by clicking Settings and then clicking General. On the General page, click Licensing, and the Update License view opens in the right pane, as shown in Figure 4. In the Update License view, there are two license options that you can set: External Virtualization Limit and Remote-Copy Limit. Set these two license options to the limit you obtained from IBM. Figure 4: IBM Storwize V7000 Update License view For assistance with licensing questions or to purchase an External Virtualization or Remote Copy license, contact your IBM account team or IBM-authorized Business Partner. 5.2 Setting up Enhanced Remote Copy Remote Copy allows you to create an identical copy of the source logical drives on a second storage subsystem or on a remote storage subsystem. Remote Copy requires a physical hardware connection between the two storage subsystems. For the best practices on setting up Remote Copy refer to Implementing the IBM Storwize V from IBM Redbooks. 8

11 5.2.1 Creating partnership between the IBM Storwize V7000 storage systems When creating a partnership, connect two IBM Storwize V7000 storage systems that are separated by a distance. After the partnership creation has been configured on both the systems, further communication between the node canisters in each of the storage systems is established and maintained by the SAN network. All inter-cluster communication happens through the Fibre Channel (FC) network. Partnership must be defined on both the IBM Storwize V7000 storage systems to make the partnership fully functional. Before creating the partnership between the two IBM Storwize V7000 storage systems, check the zoning and the system status, also make sure that the storage can see each other. Then, create the partnership by selecting the appropriate remote storage systems, and define the available bandwidth between the two systems. The bandwidth that is entered here is used by the background copy process between the clusters in the system. To set the background copy bandwidth, optimally consider the primary storage, intercluster link bandwidth, and the secondary storage to avoid overloading them so as to affect the foreground I/O latency. A partnership is created between the two IBM Storwize V7000 storage systems that are to be used for the Oracle upgrade solution. In the GUI of the source IBM Storwize V7000 storage system, on the Partnership panel, you can manage the partnership between the two storage systems. To access the Partnership panel, click Copy Services and then click Partnerships. Figure 5: Creating a partnership between the IBM Storwize V7000 storage systems After the partnership definition is completed on the first IBM Storwize V7000 storage system, the partnership of the first panel displays Partially Configured: Local. 9

12 Figure 6: Partially configured partnership between the IBM Storwize V7000 storage systems Create the partnership on the remote target IBM Storwize V7000 storage system. Figure 7: Creating a partnership between the IBM Storwize V7000 storage systems on the remote storage system 10

13 The following shows the actual background command that runs to create the partnership between the IBM Storwize V7000 storage systems. Figure 8: Actual background command that creates the partnership After creating the partnership on the remote target IBM Storwize V7000 storage system successfully, the partnership pane displays the text, Fully Configured, on both the source and the target Storwize V7000 storage systems. Figure 9: Fully configured partnership on the remote Storwize V7000 storage system 11

14 Partnership screen on the source Storwize V7000 storage system. Figure 10: Fully configured partnership on the source Storwize V7000 storage system Creating a Remote Copy relationship between IBM Storwize V7000 volumes A Remote Copy relationship is a relationship between two individual volumes of the same size. These volumes are known as the master (source) volume and the auxiliary (target) volume. Typically, the master volume contains the production copy of the data and is the volume that the application normally accesses. The auxiliary volume typically contains a backup copy of the data and is used for disaster recovery. Next, create a new consistency group to add the Metro Mirror relationships that you create. The following figure shows the creation of the new consistency group, named orcl_upgrade. 12

15 Figure 11: Enter the name of the new consistency group for the Metro Mirror relationships As shown in Figure 12, the wizard indicates that the auxiliary volumes are on a remote storage system. Figure 12: Auxiliary volumes on a remote IBM Storwize V7000 storage system Create an empty Metro Mirror consistency group as shown in Figure 13, and then click Next. 13

16 Figure 13: New Metro Mirror relationship creation The following figure shows that a new consistency group, named orcl_upgrade, has been created and it has no relationships in it. Figure 14: Empty consistency group created 14

17 The Remote Copy master and auxiliary volumes are specified as shown in Figure 15. Both, the master and auxiliary volumes must be of the same size to be used in a Remote Copy relationship. Figure 15: Selecting the master and auxiliary volumes for Metro Mirror relationship Figure 16 shows that you have created a Metro Mirror relationship between the master volume vol01 and the auxiliary volume, vol01_target, master volume vol02 and auxiliary volume vol02_target, and master volume vol03 and auxiliary volume vol03_target. Figure 16: The three paired volumes to be used in a Metro Mirror relationship 15

18 In the next step as shown in Figure 17, you are asked if the volumes are already synchronized. As the data in the master volumes and the auxiliary volumes are not identical, select No. Figure 17: Specifying that the Metro Mirror volumes not synchronized already To start the initial copy from the master volumes to the auxiliary volumes, select Yes, start copying now and click Finish. Figure 18: Initial copy between the Metro Mirror volumes Below is the actual command that runs in the background to start the Remote Copy between the master volumes and the auxiliary volumes. 16

19 Figure 19: Command to start Remote Copy consistency group As shown in Figure 20, you see that the three relationships in the v7k_mm_orcldr Consistency Group are in the Inconsistent Copying state. Figure 20: The relationships and the consistency groups in the Inconsistent Copying state As shown in Figure 21, the GUI has three running tasks, indicating the percentage of copy that has been completed between the master volumes and the auxiliary volumes. 17

20 Figure 21: Percentage of copying that has completed between the volumes After the three Remote Copy operations are completed, the Metro Mirror volume relationships reach the Consistent Synchronized state. You can see that the orcl_upgrade is also is the Consistent Synchronized state (as shown in the Figure 22). Figure 22: The relationships and the consistent groups in the Consistent Synchronized state 18

21 5.2.3 IBM Power Systems server setup for Remote Copy This session describes the setup of the IBM Power Systems server for using Remote Copy for upgrading the Oracle database. The following example explains the setup for Metro Mirror remote copy. On the source system, create volume groups: ora_home, ora_db, and ora_rec on the physical disks hdisk41, hdisk42, and hdisk43. isvp14_ora> lspv hdisk0 00f62a6b98742dad rootvg active hdisk1 00f62a6ba297b925 swap active hdisk41 00f62a6b13847e30 ora_home active hdisk42 00f62a6b1384b114 ora_db active hdisk43 00f62a6b13851fe9 ora_rec active Create three 64 GB file systems /u02, /oradb, and /oraarc on the volume groups ora_home, ora_db, and ora_rec respectively. On the target system, you also need to create the volume groups and the file systems, before you start the consistency group orcl_upgrade. After the Remote Copy has completed and the consistency group is in the Consistent Synchronized state, stop the consistency group, orcl_upgrade. The Remote Copy relationship in the consistency group can be stopped by clicking Actions Stop on the top of the Remote Copy panel, as shown in Figure 23. Figure 23: Stopping the consistency group Select the Allow secondary read/write access check box to grant read/write access to the secondary volumes, as shown in Figure 24, and click Stop Consistency Group to proceed. 19

22 Figure 24: Allowing read and write access to the secondary volumes Figure 25 shows the actual command that is run to stop the consistency group. Figure 25: Command to stop the consistency group Figure 26 shows that the relationships between the master volumes and the auxiliary volumes are now in the idling state. 20

23 Figure 26: Consistency group and relationships in the idling state Now that the volumes on the target have read and write access, the file systems can be mounted using the following commands. isvp15_ora> mount /u02 Replaying log for /dev/lv03. isvp15_ora> mount /oradb Replaying log for /dev/lv04. isvp15_ora> mount /oraarc Replaying log for /dev/lv05. isvp15_ora> df -g Filesystem GB blocks Free %Used Iused %Iused Mounted on /dev/hd % % / /dev/hd % % /usr /dev/hd9var % % /var /dev/hd % 579 1% /tmp /dev/hd % % /home /dev/hd11admin % 5 1% /admin /proc /proc /dev/hd10opt % % /opt /dev/lv % % /u02 /dev/lv % 29 1% /oradb /dev/lv % 33 1% /oraarc isvp15_ora> Login as user oracle, and start up the database instance from the target host. Oracle database instance is now started on the target. 21

24 6 Detailed example for upgrading oracle Using a test case as a detailed example, this section describes the server setup, the premium feature configuration, and the Oracle commands that you must run to upgrade the database using the Oracle DBUA. In the test case, the Oracle Database 11g R1 uses file systems for its data files. NOTE: The reference architecture uses file systems, but you can also manage your data computing with Oracle Automatic Storage Management (Oracle ASM) disk groups. The production environment uses an instance of Oracle Database 11g R1, named testdb, which is located on isvp14_ora. The Oracle Database 11g R1 binary files on HOST1 are located on the /u02 file system. In this test case, the Metro Mirror logical drives are attached to isvp15_ora. On isvp15_ora, the drives are mounted as /u02 to exactly match the production system. Metro Mirror is configured to mirror the /u02 file system from isvp14_ora, which contains both the Oracle binary files (both Oracle 11g R1and Oracle 11g R2). All the Oracle data files are in the /oradb file system. After mirroring the data, stop the Metro Mirror process, producing a point-in-time image of the Oracle Database 11g R1 on a remote set logical drive. Mount this logical drive on isvp15_ora and start the Oracle Database 11g R1. As isvp14_ora uses /u02, /oradb, and /oraarc, the logical drives on isvp15_ora are also mounted as /u02, /oradb, and /oraarc. From this standpoint, the database is an exact mirror image of the production database and the steps for the upgrade process performed on this mirrored logical drive is exactly the same as that you follow when you perform the upgrade on the production system. 6.1 Preparing the servers and storage For the best practices on SAN configuration planning, refer to the Implementing IBM Storwize V7000 guide from IBM Redbooks. Set up the primary server and the storage subsystem. After the primary server and the storage subsystem are running in an optimal state, validate the following components: 1. Databases are optimal and running. Primary storage is optimal Secondary storage is optimal Remote Copy feature is enabled and the Remote Copy links are connected 2. Set up the secondary server. Let the secondary server remain idle until it is needed. Do not assign LUNs on the secondary server yet. 3. Using the IBM Storwize V7000 storage system, initiate a Metro Mirror copy for the source logical drive /u02, /oradb, and /oraarc to the logical drive of the target storage subsystem. 4. The test case uses the following options: Metro Mirroring (synchronous copy) Highest priority rate with automatic resynchronization 22

25 6.2 Procedure on the source Complete the following steps to prepare the source. In the test case, the source database is named testdb and resides on isvp14_ora. 1. After the synchronization is complete, quiesce the database to allow for a clean break in the Remote Copy mirrors. SQL> alter system switch logfile; SQL> alter database begin backup; SQL> alter system quiesce restricted; SQL> select active_state from v$instance; ACTIVE_STATE QUIESCED 2. In the IBM Storwize V7000 storage system GUI, right-click a LUN associated with the Remote Copy logical drives, and then delete the Remote Copy links in the Remove Mirror Relationship window. 3. Bring the source database back online. SQL> alter system unquiesce; SQL> alter database end backup; Database altered. 6.3 Procedure on the target Complete the following steps to prepare the target. In the test case, the target is the testdb database and is located on the isvp15_ora host. Important: Before you upgrade to Oracle Database 11g R2 from a prior version, update the daylight saving time package. Applying the patch ahead of time makes sure that both, the source and the target, meet the upgrade requirements. For more information, refer to Note , Updated Time Zones in Oracle Time Zone File Patches, on Oracle Metalink. 1. Map the target Metro Mirror logical drives to isvp15_ora, and then make the Metro Mirror logical drive visible to the host operating system. a. Run cfgmgr to make sure that the operating system can find the new devices. b. Mount the file system as /u02, /oradb, and /oraarc. 2. After mounting the copy logical drive and applying the time zone patch, run the Oracle Database 11g utlu112i.sql (in the Oracle Database 11g R2 $ORACLE_HOME/rdbms/admin directory) on the Oracle Database 11g R1 before starting the upgrade process. a. Change the directory to the Oracle Database 11g R2 $ORACLE_HOME/rdbms/admin. b. Set all of the Oracle environment variables for the Oracle Database11g R1. SQL> startup; ORACLE instance started. Total System Global Area bytes Fixed Size bytes Variable Size bytes 23

26 Database Buffers bytes Redo Buffers bytes Database mounted. Database opened. Oracle Database 11.2 Pre-Upgrade Information Tool :00:09. ********************************************************************** Database: ********************************************************************** --> name: TESTDB --> version: > compatible: > blocksize: > platform: AIX-Based Systems (64-bit) --> timezone file: V4. ********************************************************************** Tablespaces: [make adjustments in the current environment] ********************************************************************** --> SYSTEM tablespace is adequate for the upgrade.... minimum required size: 1042 MB... AUTOEXTEND additional space required: 352 MB --> SYSAUX tablespace is adequate for the upgrade.... minimum required size: 964 MB... AUTOEXTEND additional space required: 305 MB --> UNDOTBS1 tablespace is adequate for the upgrade.... minimum required size: 456 MB... AUTOEXTEND additional space required: 431 MB --> TEMP tablespace is adequate for the upgrade.... minimum required size: 61 MB... AUTOEXTEND additional space required: 41 MB. ********************************************************************** Flashback: OFF ********************************************************************** ********************************************************************** Update Parameters: [Update Oracle Database 11.2 init.ora or spfile] ********************************************************************** -- No update parameter changes are required.. ********************************************************************** Renamed Parameters: [Update Oracle Database 11.2 init.ora or spfile] ********************************************************************** -- No renamed parameters found. No changes are required.. ********************************************************************** Obsolete/Deprecated Parameters: [Update Oracle Database 11.2 init.ora or spfile] ********************************************************************** -- No obsolete parameters found. No changes are required. ********************************************************************** Components: [The following database components will be upgraded or installed] ********************************************************************** --> Oracle Catalog Views [upgrade] VALID --> Oracle Packages and Types [upgrade] VALID --> JServer JAVA Virtual Machine [upgrade] VALID --> Oracle XDK for Java [upgrade] VALID --> Oracle Workspace Manager [upgrade] VALID --> OLAP Analytic Workspace [upgrade] VALID --> OLAP Catalog [upgrade] VALID --> EM Repository [upgrade] VALID 24

27 --> Oracle Text [upgrade] VALID --> Oracle XML Database [upgrade] VALID --> Oracle Java Packages [upgrade] VALID --> Oracle intermedia [upgrade] VALID --> Spatial [upgrade] VALID --> Oracle Ultra Search [upgrade] VALID --> Expression Filter [upgrade] VALID --> Rule Manager [upgrade] VALID --> Oracle Application Express [upgrade] VALID --> Oracle OLAP API [upgrade] VALID. ********************************************************************** Miscellaneous Warnings ********************************************************************** WARNING: --> Database is using a timezone file older than version After the release migration, it is recommended that DBMS_DST package... be used to upgrade the database timezone version... to the latest version which comes with the new release. WARNING: --> Database contains schemas with stale optimizer statistics.... Refer to the Upgrade Guide for instructions to update... schema statistics prior to upgrading the database.... Component Schemas with stale statistics:... SYS... CTXSYS... XDB... ORDSYS... WKSYS WARNING: --> EM Database Control Repository exists in the database.... Direct downgrade of EM Database Control is not supported. Refer to the... Upgrade Guide for instructions to save the EM data prior to upgrade. WARNING:--> recycle bin in use.... Your recycle bin is turned on and it contains object(s). It is REQUIRED... that the recycle bin is empty prior to upgrading... your database.... The command: PURGE DBA_RECYCLEBIN... must be executed immediately prior to executing your upgrade.. PL/SQL procedure successfully completed. SQL> shutdown immediate; --- shutdown the 11g R1 database 3. Set the Oracle environment variables to point to the /u02 mount point to use the Oracle Database 11g R2 binary files on it. The following example shows how the environment variables were set before the upgrade in the test case. bash-3.2$ env AUTHSTATE=files HOSTNAME=isvp15_ora TERM=xterm SHELL=/usr/bin/ksh USER=oracle PATH=/usr/bin:/etc:/usr/sbin:/usr/ucb:/home/oracle/bin:/usr/bin/X11:/sbin:/u02/ap p/oracle/product/11.2.0/dbhome_1/bin:/usr/java6_64/bin:. LOGIN=oracle PWD=/home/oracle HOME=/home/oracle LOGNAME=oracle 25

28 DISPLAY=isvp15_ora.storage.tucson.ibm.com:1 ORACLE_HOME=/u02/app/oracle/product/11.2.0/dbhome_1 ORACLE_SID=testdb ORACLE_BASE=/u02/app/oracle bash-3.2$ Note: All of the variables point to the Oracle Database 11g R2 binary files, and ORACLE_SID indicates the name of the Oracle Database 11g R1 instance. 4. Before starting the upgrade process, make sure that oratab has an entry for the Oracle Database 11g R1. In the test case, the /etc/oratab entry for the Oracle Database 11g R1 is specified as follows. testdb:/u02/app/oracle/product/11.2.0/dbhome_1:n 5. At the UNIX prompt, enter DBUA to open the Oracle DBUA wizard. Follow the instructions in the Oracle Database Upgrade Guide 11g Release 2 (11.2) document at the following link: To verify that the upgrade process is completed successfully, run the following query from sqlplus. SQL> select INSTANCE_NAME, HOST_NAME, VERSION, STARTUP_TIME from v$instance; INSTANCE_NAME HOST_NAME VERSION STARTUP_T testdb isvp15_ora.storage.tucson.ibm.com APR-12 The result from this query shows the instance ID and the version of the database you are running. Instance testdb shows in open status and at version

29 7 Summary The production Oracle database was successfully upgraded to the latest version using the Remote Copy feature of the IBM Storwize V7000 storage system following the procedure mentioned in this white paper. Using the Remote Copy feature of the IBM Storwize V7000 storage system to upgrade a production Oracle database has a number of advantages, as there is no disruption or risk to the source production database during the entire upgrade process. Also, in a situation where the host server running the production Oracle database is on an older version of the host operating system (which is not supported by the latest Oracle version), the Remote Copy feature of the Storwize V7000 storage system provides an excellent solution as demonstrated in this white paper. 27

30 Resources The following websites provide useful references to supplement the information contained in this paper: Safely Upgrading an Oracle Database Using Enhanced Remote Mirroring on DS4000 and DS5000 ibm.com/support/techdocs/atsmastr.nsf/webindex/wp Safely Upgrading an Oracle Database Using Data Replicator Software oracle.com/technetwork/articles/systems-hardware-architecture/upgrading-db-using-drs pdf Leveraging DS8000 Advanced Copy Services for Oracle User-Managed Backup and Recovery ibm.com/support/techdocs/atsmastr.nsf/webindex/wp Implementing the IBM Storwize V ibm.com/redbooks/redpieces/abstracts/sg html?open IBM Business Partner support and resources ibm.com/partnerworld/pwhome.nsf/weblook/index_us.html IBM Publications Center IBM Redbooks ibm.com/redbooks IBM developerworks ibm.com/developerworks About the author Mayur Shetty is a consultant in IBM Systems and Technology Group ISV Enablement Organization. He has more than 10 years of experience working with the Enterprise Server and Storage products, and Oracle database. 28

31 Trademarks and special notices Copyright IBM Corporation References in this document to IBM products or services do not imply that IBM intends to make them available in every country. IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol ( or ), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Intel, Intel Inside (logos), MMX, and Pentium are trademarks of Intel Corporation in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. Linux is a trademark of Linus Torvalds in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others. Information is provided "AS IS" without warranty of any kind. All customer examples described are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual environmental costs and performance characteristics may vary by customer. Information concerning non-ibm products was obtained from a supplier of these products, published announcement material, or other publicly available sources and does not constitute an endorsement of such products by IBM. Sources for non-ibm list prices and performance numbers are taken from publicly available information, including vendor announcements and vendor worldwide homepages. IBM has not tested these products and cannot confirm the accuracy of performance, capability, or any other claims related to non-ibm products. Questions on the capability of non-ibm products should be addressed to the supplier of those products. All statements regarding IBM future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives only. Contact your local IBM office or IBM authorized reseller for the full text of the specific Statement of Direction. Some information addresses anticipated future capabilities. Such information is not intended as a definitive statement of a commitment to specific levels of performance, function or delivery schedules with respect to any future products. Such commitments are only made in IBM product announcements. The 29

32 information is presented here to communicate IBM's current investment and development activities as a good faith effort to help with our customers' future planning. Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon considerations such as the amount of multiprogramming in the user's job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve throughput or performance improvements equivalent to the ratios stated here. Photographs shown are of engineering prototypes. Changes may be incorporated in production models. Any references in this information to non-ibm websites are provided for convenience only and do not in any manner serve as an endorsement of those websites. The materials at those websites are not part of the materials for this IBM product and use of those websites is at your own risk. 30