Oracle RMAN disk-to-disk backup methods using the IBM Storwize V3700 storage system

Transcription

1 Oracle RMAN disk-to-disk backup methods using the IBM Storwize V3700 storage system Practice guide: Backup and restore of native Oracle database solutions Mayur Shetty IBM Systems and Technology Group ISV Enablement November 2012 Copyright IBM Corporation, 2012.

2 Table of contents Abstract... 1 Introduction... 1 Why Oracle Recovery Manager?... 1 Advantages of backing up to disk rather than to tape... 2 Storing database files... 2 Using file systems for storing database files... 3 Using ASM for storing database files... 3 Avoiding raw devices for storing database files... 4 Fast recovery area... 4 What is stored in the fast recovery area... 4 Using the fast recovery area... 4 What is not stored in the fast recovery area... 4 Configuring the fast recovery area... 5 Tuning the fast recovery area... 5 Selecting disks for the fast recovery area... 6 Integrating the fast recovery area... 6 Configuring the RMAN environment... 7 Configuring storage components... 8 IBM Storwize V3700 configuration... 8 SAN configuration planning... 8 MDisk and storage pool configuration... 8 Volume configuration and mapping to the host system... 9 Oracle ASM and database creation Prerequisite on the AIX host Creating an ASM disk group Creating an Oracle database and schema Summary Appendix: Resources Trademarks and special notices... 19

3 Abstract This paper provides information about IBM Storwize V3700 and serves as a practical guide for backing up and restoring native Oracle database solutions in an IBM AIX operating system environment. The target audience for this paper includes system and storage administrators, architects, consultants, system engineers, and technical managers. Introduction Providing data protection through backup and recovery processes is a key component to database availability. Without a quick and reliable method to back up and recover a database, an organization is at a substantial risk for prolonged outages and lost revenue. Methods that would take long hours to retrieve a tap from an off-site facility no longer meet many service level agreements. Instantaneous, reliable, quick, and easy backup storage methods are required. Of all the available methods, disk-based, also known as array-based backup storage is becoming a clear frontrunner. Array-based data protection using the IBM Storwize V3700 FlashCopy function mitigates risk and enhances reliability for data protection through the backup and recovery process by providing the following advantages: Backups on location and immediately available Increased success rate of recoveries Robust features of storage systems High integration of disk technology into database backup mechanisms Reduced backup window and recovery time Increased performance of backups and recoveries Why Oracle Recovery Manager? Oracle Recovery Manager (RMAN) is an Oracle utility used to back up and restore an Oracle database along with providing other features. RMAN is widely accepted in the Oracle community. RMAN can determine the backup and recovery needs of the database, and also can locate corruption down to the database block level. It is recommended to store the RMAN catalog in a dedicated instance. Separating the RMAN catalog from the production databases aids restoration of the production database. Oracle recommends using RMAN for disk-to-disk backups. This recommendation is based on the reduced cost of storage area networks (SANs) and on the simplicity of RMAN. You should seriously consider using RMAN for disk-to-disk backups because of the intuitive nature of RMAN and the tight integration of RMAN with the Oracle database. Additionally, many databases must be available around the clock. By implementing a disk-to-disk backup and restore methodology, it is possible to achieve a highly available, 24x7 environment. If you use Oracle Automatic Storage Management (ASM), you must also use RMAN to back up and restore the database objects. At this time, no other tool besides RMAN exists to back up the Oracle ASM disk groups. RMAN can create backups of a target database into the fast recovery area. This type of backup aligns with Oracle s recommended strategy of using full backups combined with incremental backups, and of maintaining archive and online redo logs. RMAN integrates tightly with the Oracle kernel. RMAN provides functions for space management of the fast recovery area. Oracle processes delete obsolete files or files that have met the backup retention period. RMAN is aware of what resides in the fast recovery area and 1

4 knows what must be backed up or recovered. Thus RMAN is highly recommended for optimal backup management of Oracle databases to prevent disaster. For instance, RMAN detects block-level corruption, which most alternative backup solutions cannot detect. RMAN also makes use of a catalog that keeps information about each backup. The information aids in the recovery process. Advantages of backing up to disk rather than to tape Availability requirements often dictate the backup and recovery device. For database environments that must be highly available, backing up to a disk is a better option than backing up to a tape. Backups themselves do not hinder the availability of a database, because an Oracle database can remain available while hot backups are running. The real determining factors that favor disk backup over tape backup are as follows: The time taken to back up the database The time taken to recover the database Backing up to a disk is much faster than backing up to a tape. After backing up and recovering the database, you must add the time required to reassemble the individual components of Oracle. The entire recovery process of an Oracle database might result in the database being unavailable for hours if not days depending on how large the database is and what components must be restored. The advantages of disk-based backups and restores are as follows: Decreases the cost by using high-volume, low-cost storage such as the nearline serial-attached SCSI (SAS) drives of the IBM Storwize V3700 storage system Decreases the backup window by using multiple I/O streams Decreases the recovery time by using multiple I/O streams Increases the availability of backups Increases protection through RAID technology Increases the usage and viability of backups by using the premium features within the storage manager software One feature of the RMAN disk-based backup methodology is the incrementally updated backup process, which can make the restore and recovery operation more efficient. The incrementally updated backup process involves rolling the changes from a Level1 incremental backup to a Level0 backup. If the incrementally updated backup process is performed daily, database recovery requires only the following files: The updated image of the incrementally updated backup The archive logs created since the last incremental backup The online redo logs (optional) You can complete the incrementally updated backup process inside the fast recovery area. For more information, refer to the Oracle documentation on RMAN s incrementally updated backup. Storing database files An Oracle database installer has the following three storage options for database files: 2

5 File systems Oracle ASM Raw devices The Oracle installation guide gives further details about each storage option. Refer to the Oracle installation guide for the specific operating system to determine how to take advantage of each storage option. Using file systems for storing database files Most database administrators have used file systems extensively and are very familiar with them. File systems reside on disks in either of the following two ways: Locally attached disks that are internal to the server A Logical Volume Manager (LVM) or Redundant Array of Independent Disks (RAID) that is on a SAN, such as the Storwize family storage systems. Regardless of whether you use a Storwize family storage system, all file systems are mounted on the host server. When Oracle storage is required to create objects or to store data, Oracle uses physical files in a predefined directory structure. Oracle can generate names for the physical files, or you, as the Oracle database administrator, can create names for them. Refer to the Oracle installation guide for the specific operating system to determine how to place database files on a file system and how to follow Oracle s Optimal Flexible Architecture (OFA) to ensure a reliable and manageable installation. Using ASM for storing database files Oracle ASM is Oracle s proprietary storage solution for Oracle databases. Oracle ASM simplifies or eliminates the use of most of the traditional disk management tools. You can realize the following benefits when you implement Oracle ASM: A database administrator no longer needs to lay out or create database directory structures. Oracle ASM handles all underlying disk use. Database objects automatically spread over multiple disk devices. Database availability increases because new disk devices can be added or removed without shutting down the database. Database files automatically rebalance when new devices are added or removed. Oracle Managed Files (OMF) along with striping and optional mirroring capabilities provides a file system that can support a multi-node clustered environment or a single-node database system. You can easily implement OMF. Oracle ASM requires a dedicated Oracle instance on each node to manage the disk groups within the Oracle ASM structure. This Oracle ASM instance communicates with the database instance through the Oracle Cluster Synchronization Services (CSS). To learn how to install and configure Oracle ASM, and how to enable Oracle ASM to work with an Oracle database, refer to the Oracle installation guide for the specific operating system. 3

6 Avoiding raw devices for storing database files Although raw devices are available, they are not recommended for storing database files. Raw devices are simply disks that have not been formatted with a file system. When Oracle writes data to raw devices, Oracle bypasses the file system layer of the operating system and writes directly to the partition or logical drive. Thus, managing raw devices becomes very complex. Because of this increased administrative complexity, and because raw devices provide very little performance benefit, most companies do not recommend using raw devices. Therefore, this paper does not provide information about raw devices. Fast recovery area Oracle fast recovery area is an allocated disk storage location where you can store all backup- and recovery-related files. You can point the fast recovery area to a file system or an Oracle ASM disk group. Starting in Oracle 11g release 2, Oracle has renamed the flash recovery area to be the fast recovery area. What is stored in the fast recovery area You can back up and restore all database-related files required for database recovery in the fast recovery area. This includes: Control files Online logs Archive logs Flashback logs Control file auto backups Control file copies Data file copies Backup pieces Using the fast recovery area The fast recovery area is tightly integrated within the Oracle database and provides a prime area for performing disk-to-disk backups. As long as the fast recovery area has sufficient storage, RMAN creates a powerful mechanism to automate recovery of an Oracle database so that it is faster and simpler. You also can use the fast recovery area to run the Flashback Database command, which returns the database to a previous point in time based on a system change number (SCN), date/time, or to a defined restore point. For more information about Flashback Database, refer to the Oracle documentation on procedures. What is not stored in the fast recovery area Oracle manages the fast recovery area and keeps it clean by storing only what is necessary and by automatically removing the following obsolete files: Files that are no longer needed for a recovery scenario Redundant copies Files that have been backed up 4

7 Configuring the fast recovery area You can configure the fast recovery area by setting the following two init.ora parameters: DB_RECOVERY_FILE_DEST The default location for the fast recovery area. DB_RECOVERY_FILE_DEST_SIZE The amount of disk available for the fast recovery area. Sizing the fast recovery area can be a complex task, depending on what is stored in this area. For more information about how to size this area for the components that you want stored in the fast recovery area and for their retention period, refer to the Oracle documentation. After you set the parameters for the fast recovery area, you can send all RMAN backups, archive logs, control file auto backups, and data file copies to write to the location of your choice. You can send them to automatically write to the specified file system within the fast recovery area. You can send them to write to an Oracle ASM group. For details, refer to the Oracle installation guide for the specific operating system. You can tailor the fast recovery area to meet any database requirement. For example, you can tailor the size depending on the amount of information to be backed up in a single instance. You can make the fast recovery area large enough to keep full logs, incremental logs, and archive logs available. You can make the fast recovery area as large as the database itself, so that you can do a complete backup. You can make the fast recovery area small enough to store only archive logs. At minimum, take advantage of the fast recovery area to archive redo logs, online redo logs (second multiplexed log), and control files. These logs and files already take up disk space, so that there is no real advantage to storing them anywhere but within the fast recovery area. Additionally, the fast recovery area has added features that not normally available for administering database recoveries. Tuning the fast recovery area Depending on how active the database is, and what objects are stored in the fast recovery area, you might need to tune the fast recovery area to provide sufficient I/O throughput. Insufficient throughput impedes the performance of the database. Some methods for increasing throughput are as follows: Set up multiple file systems for the fast recovery area to distribute the I/O over multiple disk devices or even multiple SANs. Use multiple Oracle ASM disk groups for the fast recovery area to distribute the I/O over multiple Oracle ASM disks. Spread the fast recovery area across several Oracle ASM disk devices or SANs to distribute the I/O. Run backup RMAN activity during off-peak hours. 5

8 Selecting disks for the fast recovery area Depending on how active the database is, using a multi-tiered storage system can be sufficient. It is possible to use nearline SAS drives of the Storwize V3700 storage system for the fast recovery area, while using the SAS drives of the storage system for the data and indexes. A multi-tier storage system offers the following features and benefits: Higher disk capacity, if using nearline SAS drives in the Storwize V3700 system Lower cost Sufficient speed for disk-to-disk backups Integrating the fast recovery area Figure 1 shows how you might use a fast recovery area within an Oracle database. You can place the second multiplexed online redo logs in the fast recovery area. You can write archive log destinations directly to the fast recovery area. You can write backups through RMAN to the fast recovery area. Although not shown in Figure 1, you can also store control files in the fast recovery area. Figure 1: Fast recovery area in an Oracle database When you configure database storage, note that the fast recovery area and the database do not require the same storage option. For example, the database might use file systems while the fast recovery area might use Oracle ASM. Raw devices in the fast recovery area are the only unsupported file type, which is yet another reason for not using raw devices. 6

9 Configuring the RMAN environment For clarity, the production Oracle databases should be on a separate server from the RMAN repository. The RMAN catalog resides on its own dedicated instance, on a server that is separate from the databases that need to be backed up and restored. As a result, you drastically reduce the risk of having both the RMAN catalogs unavailable at the same time that the databases need recovery. In contrast, risk increases if you put the RMAN catalog on the same server as the other production databases. If a server-wide issue causes loss of data, the RMAN catalog must be recovered first before the databases can be recovered. As a result, the database will be unavailable for a longer period of time. You can store the following file systems and Oracle ASM disk groups on a RAID 10 storage system: File systems for Oracle data files Oracle ASM disk groups for Oracle data files You can store the following file systems and Oracle ASM disk groups on a RAID 5 storage system: File systems for the fast recovery area Oracle ASM disk groups for the fast recovery area File systems for exports File systems or Oracle ASM disk groups for archiving data The backup created with RMAN can be copied to the secondary storage using the storage manager s fast, internal VolumeCopy feature. A volume copy makes the backup available for disaster recovery activities, for the primary storage system cloning, and various development activities where production data is required. Similarly, you can create quick and instantaneous FlashCopy replicas to keep point-intime copies on the secondary storage system for backups of the primary storage system. 7

10 Configuring storage components You can use different types of storage devices, storage systems, and mirroring options when implementing database features, such as RMAN and fast recovery area. There are two recommended RAID configurations for the database. Use RAID 10 for the primary storage area for table spaces that require high input/output operations per second (IOPS) or MBps throughput. Use RAID 5 for the storage area dedicated to the fast recovery area, if the database does not require high IOPS or MBps. Use the storage manager to configure the storage used by the database. Together, RMAN and fast recovery area provide a powerful combination for backup, for recovery, and for using other features, such as Flashback, for Oracle databases. IBM Storwize V3700 configuration This section focuses on the configuration of various components that were involved in this proof of concept. It includes: SAN configuration, managed disks (MDisks) configuration, storage pools, volumes, and hosts. SAN configuration planning For the best practices on SAN configuration planning, refer to the IBM Storwize V7000 Introduction and Implementation Guide from IBM Redbooks. MDisk and storage pool configuration In Storwize V3700, the internal drives cannot be directly added to storage pools. They need to be included in a RAID configuration to provide protection against the failure of individual drives. A RAID array is created as an MDisk, and during the array creation, wizards and presets are available to suggest configurations to users based on the hardware attached to the system. The recommendation is to use these presets for easy configuration and best performance. For this white paper, as shown in Figure 2, the test team created 16 MDisks using the internal disks of the Storwize V3700 system. MDisks (from mdisk0 to mdisk15) were created using the eight internal hard disk drives (HDDs), each of which is 1000 rpm 558 GB drive. The MDisks were then added to the mdiskgrp0 storage pool. 8

11 Figure 2: IBM Storwize V3700 MDisk and storage pool Volume configuration and mapping to the host system A volume is a logical disk that is presented to a host system by the IBM Storwize V3700 system. The IBM Storwize V3700 storage system translates this volume into a number of extents that are allocated across MDisks present in the storage pool. On clicking the Volumes icon on the side panel of the Storwize V3700 GUI, the panel as shown in Figure 3 is displayed. Then click New Volume to create the volumes. Figure 3: IBM Storwize V3700 storage pool tiers 9

12 In the presets that are displayed for creating new volumes, select the Generic preset, as shown in Figure 4. A choice of the three storage pools that were created earlier to create the volume is displayed. Figure 4: IBM Storwize V3700 new volume creation preset 10

13 It is possible to create multiple volumes simultaneously from the storage pool, as shown in Figure 5. The team created ten 100 GB volumes called ORCL_DATA01 to ORCL_DATA10 from the mdiskgrp0 HDD storage pool. Figure 5: IBM Storwize V3700 new volume creation from the storage pool 11

14 Figure 6 shows the actual command line that runs to create the individual volumes. Figure 6: IBM Storwize V3700 command to create new volumes 12

15 As soon as the volumes are created, a message box asking whether you need to map the volumes to the host system (as shown in Figure 7) is displayed. Select ISVP14_ORA, which is the AIX host that is attached to the Storwize V3700 system used for this white paper. Figure 7: IBM Storwize V3700 host mapping of the volumes 13

16 After selecting the host, click Map Volumes to continue with the host mapping. On the next page, the SCSI IDs of the volumes are displayed. You now have a chance to change it, if required. Then click Map Volumes to continue, as shown in Figure 8. Figure 8: IBM Storwize V SCSI ID 14

17 Figure 9 shows the actual background command that runs to perform the mapping of the volumes to the host system. Figure 9: IBM Storwize V3700 command to create the host mappings Figure 10 shows the new volumes that were created and mapped to the host. Figure 10: IBM Storwize V3700 volumes by pool 15

18 Oracle ASM and database creation This section describes the creation of the Oracle ASM and the Oracle database on the host machine. Prerequisite on the AIX host On the node running AIX, detect and configure the new device. Run the lspv command to list the physical disks already configured on the system. isvp14_ora> lspv To configure the new devices that the team created on the Storwize V3700 system and mapped to the isvp14_ora host, run the cfgmrg command. isvp14_ora> cfgmgr Run the lspv command again and you can see the entry for the new disks in the output. The following command changes an available disk (hdisk13, hdisk14, hdisk15, and hdisk16) to a physical volume by assigning it a physical volume identifier (PVID), if it does not already have one. isvp14_ora> chdev -l hdisk13 -a pv=yes isvp14_ora> chdev -l hdisk14 -a pv=yes isvp14_ora> chdev -l hdisk15 -a pv=yes isvp14_ora> chdev -l hdisk16 -a pv=yes Change the owner and group of the devices to oracle and dba as shown in the following example. isvp14_ora> chown oracle:dba /dev/rhdisk13 isvp14_ora> chown oracle:dba /dev/rhdisk14 isvp14_ora> chown oracle:dba /dev/rhdisk15 isvp14_ora> chown oracle:dba /dev/rhdisk16 The new logical unit numbers (LUNs) are now available to create an ASM disk group. Creating an ASM disk group Using the Oracle ASMCA tool, the test team created an Oracle ASM disk group +DATA using the ten 100 GB LUNs that the team presented to the AIX host. For the +DATA disk group, the team used external redundancy. Creating an Oracle database and schema The test team then created an Oracle database using the General Purpose or Transactional Processing template in the Oracle DBCA tool. In the dbca tool, the team specified ASM as the storage type for the database and used Oracle managed files with +DATA for the database area. Next, the team created the Order Entry schema using the oewizard tool from the SwingBench kit. The Order Entry schema creation involved the creation of the soe user, tables, indexes, data, and so on. For 16

19 this exercise, the team selected a scale factor of 100 that used 100 GB of raw data plus the space required for indexes. A scale factor of 100 created an Order Entry table space of 320 GB in size, and temporary table space size of 60 GB. Summary This paper provides an insight in implementing a RMAN backup and restore methodology using disk storage systems. This paper explained only RMAN's capabilities. For more information about RMAN, refer to the Oracle website. For more information about disk storage systems, refer to the IBM website. Third-party documentation on RMAN is also available. 17

20 Appendix: Resources The following websites provide useful references to supplement the information contained in this document: System Storage on IBM PartnerWorld ibm.com/partnerworld/systems/storage IBM Systems on IBM PartnerWorld www-304.ibm.com/partnerworld/wps/pub/overview/b5001pw IBM Publications Center IBM Redbooks ibm.com/redbooks IBM developerworks ibm.com/developerworks Oracle database documentation 18

21 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. 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 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. 19

22 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. 20