HP LeftHand SAN Solutions

Transcription

1 HP LeftHand SAN Solutions Support Document Application Notes Oracle Backup Recovery Setup on LeftHand Networks IP SAN

2 Legal Notices Warranty The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. The information contained herein is subject to change without notice. Restricted Rights Legend Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR and , Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license. Copyright Notices Copyright 2009 Hewlett-Packard Development Company, L.P. 2

3 Oracle Backup & Recovery Setup on Lefthand Networks IP SAN Overview The ability to preserve database data for long periods of time and then retrieve it quickly is more crucial today than ever. Timely access to critical data is often the difference between the success and failure of the business. Traditional backup and recovery methods are simply not the answer to the growing quest for online (24x7) data. Clearly, acceptable downtime is being pushed to zero hours, and demand for speedy recovery and cost effective backup systems has become eminent. LeftHand Networks has capitalized on recent advancements in Ethernet networks, and introduced the LeftHand SAN, an IP-based Storage Area Network (SAN) that brings the robust capabilities of the most advanced storage technologies to an affordable and scalable backup solution. Oracle RDBMS architecture provides a high level of flexibility and scalability. However, the transaction logging is still sequential and, under archive mode, requires incremental archiving of transaction logs to archive log files. These archive logs are crucial to any type of recovery. Oracle has dedicated a separate process, ARCH, to prepare these archive log files. Typically, the archive log files are stored on the local system for a short period of time, and then pushed off to some tape-drive storage system. Later, these tape cartridges are labeled and stored onsite or sent to remote storage along with other database file backups. Murphy s Law is that, when trying to recover from a catastrophic database failure, the administrator is not able to find the right tape-cartridge or has problems with the tape-storage system. Such situations can result in hours or days worth of downtime, thereby impairing a company s productivity and profitability. This paper combines the LeftHand Networks LeftHand SAN with Oracle RDBMS to develop cost-effective and time-efficient Oracle backup and recovery solutions. 3

4 LeftHand SAN The low cost and pervasiveness of Ethernet technology provides the opportunity for a superior new solution: an IP-based storage area network. The basic idea is to build a storage subnet just like Fiber Channel (FC) SAN, but instead of using the high-cost, hard-to-manage FC technology, build the subnet on the pervasive and inexpensive Ethernet technology. (See Figure 1) Figure 1IP SAN on Ethernet An IP SAN can provide all the benefits of a higher-cost Fiber Channel SAN: High-performance of block level operations. Infinite scalability of storage for a server or group of servers. Capacity consolidation across storage devices on the subnet. Aggregation of storage, allowing higher utilization. Offloading of storage traffic from the main LAN. Furthermore, IP SAN can achieve all these benefits without requiring customers to deal with the cost, administration, and distance limitations of a Fiber Channel network. Finally, after the partial solutions provided by DAS and SAN, there is a complete solution that addresses all of customers pain points. There is no need to integrate hardware and software separately from different vendors. LeftHand Networks supplies everything a customer needs to create an end-to-end solution. 4

5 LeftHand Networks and Oracle Solutions Preliminary Set-up Oracle8i Backup Architecture Oracle databases are widely implemented in two operational modes; 1) No-archivelog mode and 2) Archivelog mode. Under the first mode, Oracle does not archive filled groups of online of the database. In the second mode, Oracle Archiver process archives the groups of online redo log files, hence providing for complete recovery from a disk failure to the instant that the failure occurred (or, to the desired noncurrent time). Overall, Oracle data files is made up of three types: a datafile, a control file and an online redo log. In archive log mode, redo logs are archived to archive log files. Therefore, it is imperative to back-up each of these file types to guarantee complete data protection and disaster recovery of the enterprise data. Setting Up the Volume LeftHand Networks recommends a minimum of three NSMs to fully utilize the SAN/iQ Software (the LeftHand SAN core management software) performance and availability of the data. For this solution, a management group called Oracle is established with a single storage cluster called Backup. To map the Oracle data-file types explained in the last paragraph, three volumes are created; 1) data, 2) control and 3) redo-log. Each volume should be appropriately sized and given a replication level that meets your capacity planning and recovery strategy. 5

6 Figure 2Centralized Management Console (CMC) View of SAN/iQ Volumes The next two Oracle solutions will use the configuration depicted in SAN/iQ setup Figure 2 to exhibit the archive log files backup and a complete backup implementation. Solution 1: Oracle8i Online Archived Logs on LeftHand SAN In a high volume online transaction processing system, archiving Oracle online redo logs becomes an important operation. In case of system failure, recovery depends on how quickly these log files can be retrieved and applied to restore the state of the system. As mentioned earlier, the traditional backing up of archived redo logs on a tape-storage system is time consuming and prone to human error. This section illustrates how these archive logs can be stored directly to either an on-site or an off-site LeftHand SAN solution. The step-by-step instructions are for a Linux platform. 1 Prepare the SAN/iQ volume for your desired storage planning. 6

7 2 On the database server side, install the LeftHand Networks AEBS Client Driver (refer to the product installation and configuration guide), and configure the aebs.conf file to incorporate the volume. Later, at the operating system level, bind these volumes to the file system as shown below: (Note: Unlike Oracle data files, archive log files cannot be stored on a raw partition). # <install AEBS Client driver> AEBS Driver Installation # mke2fs /dev/aebs/disk2 b 4096 Create FS on NSM Volume # mkdir /data/u08/oradata/sid/archlog Create mount point # mount /dev/aebs/disk0 /data/u08/oradata/sid/archlog Mount FS 3 Let s assume the database is: not created in archive mode mounted, not open Apply the following commands at the svrmgrl or sqlplus prompt as user sys: svrmgrl> alter system set svrmgrl> log_archive_dest = /data/u08/oradata/sid/archlog; svrmgrl> alter database archivelog; svrmgrl> archive log start; 4 To view if the log mode is enabled and automatic archival is set: svrmgrl> archive log list; 5 Edit the init<sid>.ora file set above configurations permanently: log_archive_start = true log_archive_dest = /data/u08/oradata/sid/archlog log_archive_format = log_%s.arc 6 Optional: to mirror or multiplex the archive logs for added security and safety, edit the init.ora file and set following parameters to your desired path: log_archive_duplex_dest = log_archive_min_succeed_dest = 2 7

8 Solution 2: Oracle8i Complete Backup & Recovery Setup on LeftHand SAN Next is outlined a complete Oracle8i backup and recovery setup procedure on a LeftHand SAN, using Oracle s preferred integrated Backup & Recovery tool, Recovery Manager (RMAN). The following illustration assumes the reader is familiar with: Oracle backup terminology RMAN architecture And that a the RMAN recovery catalog and repository has been established. (Refer to The Oracle8i Server Backup and Recovery Guide for more details.) For ease of illustration, the RMAN command line interface (CLI) is used. Following are the configurations for this example: the target database is called targdb, is in archivelog mode, and has the same TNS alias. targdba has been granted SYSDBA privileges. the recovery catalog database is called rcat and has the same TNS alias. the schema containing the recovery catalog is rman (same password). 1) Mounting SAN/iQ Volumes on RMAN host Install and configure the LeftHand Networks AEBS Client Driver on the RMAN host. Bind NSM volumes to operating system files as shown below: # <install AEBS Client driver> AEBS Driver Installation # mke2fs /dev/aebs/disk0 b 4096 Create FS for Data Files # mke2fs /dev/aebs/disk1 b 4096 Create FS for Control # mke2fs /dev/aebs/disk2 b 4096 Create FS for Redo Logs # cd /oracle/backups/<sid> # mkdir data control redolog Create mount points # mount /dev/aebs/disk0 /oracle/backups/<sid>/data Mount FS # mount /dev/aebs/disk1 /oracle/backups/<sid>/control Mount FS # mount /dev/aebs/disk2 /oracle/backups/<sid>/redolog Mount FS 2) Starting RMAN and registering target database Before invoking RMAN, set the NLS_DATE_FORMAT and NSL_LANG environment variables. Much of the RMAN LIST output is date/time related. Example NLS settings: NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1 8

9 NLS_DATE_FORMAT=DD-MON-YYYY HH24:MI:SS For RMAN to connect to the recovery catalog and the target database, the recovery catalog database must be open, while the target instance must be at least STARTED and OPEN in case of archivelog mode. Set ORACLE_SID to be the target database, and issue the following: # rman rcvcat rman/rman@rcat RMAN> connect target Or if the target database uses a password file: #rman rcvcat rman/rman@rcat target targdba/<password>@targdb Now register the target database and view the schema to reconfirm the registration: RMAN> register database; RMAN> report schema; 3) Complete the database backup on the NSM Database Status: Recovery catalog database is OPEN, target database is mounted or OPEN. Use the following: RMAN> run { 2> # backup the complete database to disk 3> allocate channel dev1 type disk; 4> backup 5> full 6> tag full_db_sunday_night 7> format /oracle/backups/<sid>/data/db_t%t_s%s_p%p 8> (database); 9> release channel dev1; 10> } To view this backup in the catalog, use the following command: RMAN> list backupset of database; To do a single tablespace backup: RMAN> run { 2> # backup users tablespace to disk 3> allocate channel dev1 type disk; 4> backup 9

10 5> tag tbs_users 6> format /oracle/backups/<sid>/data/tbs_users_t%t_s%s 7> (tablespace users); 8> release channel dev1; 9> } To view this tablespace backup in the catalog, use the following command: RMAN> list backupset of tablespace users; 4) Control file backup Database Status: Recovery catalog database is OPEN, target database is mounted or OPEN. Use the following: RMAN> run { 2> # backup control file to disk 3> allocate channel dev1 type disk; 4> backup 5> tag cf_monday_night 6> format /oracle/backups/<sid>/control/cf_t%t_s%s_p%p 7> (current controlfile); 8> release channel dev1; 9> } NOTE: Full database backup will automatically backup the control file. 5) Backing up Archive logs: Database Status: Recovery catalog database is OPEN, target database is mounted or OPEN. Use the following: RMAN> run { 2> # backup Archive logs to disk 3> allocate channel dev1 type disk; 4> backup 5> format /oracle/backups/<sid>/redolog/archlog_t%t_s%s_p%p 6> (archivelog all); 7> release channel dev1; 8> } To view the archive logs in the catalog, use the following command: 10

11 RMAN> list backupset of archivelog all; 6) Backing up Online Redo logs: Online logs cannot be backed up using RMAN; they must be archived first. To archive on-line logs, issue SQL commands from RMAN e.g.: RMAN> run { 2> allocate channel dev1 type disk; 3> sql alter system archive log current ; 4> backup 5> format /oracle/backups/<sid>/redolog/archlog_t%t_s%s_p%p 6> (archivelog from time sysdate-1 all delete input); 7> release channel dev1; 8> } The above script archives the logs, backs them up and deletes them after backing them up. If the backup fails, logs will NOT be deleted. The script can be executed after a full database open backup. The script would ensures all the redo logs to recover the database to a consistent state would be backed up. Oracle8i Server Recovery Scenarios: The Oracle8i server recovery process is best explained with a few examples. Once again, RMAN is used to illustrate following recovery scenarios. The great advantage here is that SAN/iQ which makes the backups available online all time. Unlike with tape-storage systems, DBAs will not have to search or track down the appropriate cartridge to perform restore or recovery procedures. Furthermore, using RMAN makes the recovery process very simple and time-efficient. Just like backups, RMAN can restore whole or partial database with just a few commands. Scenario 1: Database open and datafile deleted In this example, a datafile has been accidentally deleted from a running database. There are two methods of open database recovery: restore the datafile recover: o the datafile o the tablespace. The following RMAN session illustrates restoring and recovering datafile: 11

12 RMAN> run { 2> allocate channel dev1 type disk; 3> sql alter tablespace users offline immediate ; 4> restore datafile 4; 5> recover datafile 4; 6> sql alter tablespace users online ; 7> release channel dev1; 8> } Scenario 2: Complete Database recovery This example exhibits a situation where online redo logs are lost, and the database needs to be completely restored and rolled forward. The process is started by closing the database and determining the point in the log sequence where the recovery needs to be performed. The following RMAN command illustrates the sequence of recovery: RMAN> run { 2> allocate channel dev1 type disk; 3> set until logseq=105 thread=1; 4> restore controlfile to /oracle/dbs/ctrltargdb.ctl ; 5> replicate controlfile from /oracle/dbs/ctrltargdb.ctl ; 6> restore database; 7> sql alter database mount ; 8> recover database; 9> sql alter database open resetlogs ; 10> release channel dev1; 11> } 12

13 SUMMARY Oracle database backup on the LeftHand Networks SAN provides a cost-effective and timeefficient solution. All the of the procedures and scenarios presented in this white paper have been validated at the LeftHand Networks test labs, and all were successful in backing up and recovering the Oracle8i database without any loss of data or logs. Many other Oracle backup solutions can be created from the above examples deployed on LeftHand Networks products where storage is unlimited and highly scalable and manageable. Furthermore, SAN/iQ technology can be integrated as an Oracle Standby configuration or a High Availability (HA) solution. 13