Oracle RMAN disk-to-disk backup
methods using the IBM Storwize V3700
storage system
Practice guide: Backup and restore of native Oracle database solutions
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 ... 16
Prerequisite on the AIX host ... 16
Creating an ASM disk group ... 16
Creating an Oracle database and schema ... 16
Summary... 17
Appendix: Resources... 18
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.
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.
• 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).
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
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.
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
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
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®.
http://www.redbooks.ibm.com/redbooks/pdfs/sg247938.pdf
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.
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.
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.
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 6 shows the actual command line that runs to create the individual volumes.
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.
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 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
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.
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
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
www.elink.ibmlink.ibm.com/public/applications/publications/cgibin/pbi.cgi?CTY=US
• IBM Redbooks
ibm.com/redbooks • IBM developerWorks®
ibm.com/developerWorks • Oracle database documentation
Trademarks and special notices
© Copyright IBM Corporation 2012.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 www.ibm.com/legal/copytrade.shtml.
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
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.
