HP LeftHand SAN Solutions

(1)

HP LeftHand SAN Solutions

Support Document

Application Notes

(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 12.211 and 12.212, 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

(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.

(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.

(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

(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.

(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 usersys:

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 =

(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

(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 {

(10)

5> tag tbs_users

6> format ‘/oracle/backups/<SID>/data/tbs_users_t%t_s%s’ 7> (tablespace users);

• To view this tablespace backup in the catalog, use the following command: RMAN> list backupset of tablespace users;

4) Control file backup

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);

NOTE: Full database backup will automatically backup the control file. 5) Backing up Archive logs:

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);

(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);

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:

(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;

(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.