Network Appliance, a pioneer and industry leader in data storage technology, helps organizations understand and meet complex

technical challenges with advanced storage solutions and global data management strategies.

SAP R/3: Windows /Oracle with NetApp Filers: Best Practices

Marco Schoen, SAP Competence Center, Network Appliance, Inc. | 8/21/2003 | TR 3278

TECHNICAL REPORT

TECHNICAL REPORT

Network Appliance Inc.

TECHNICAL REPORT

Table of Contents
1 Network Appliance Filer Technology NetApp Filer Hardware The Data ONTAP Operating System Administration Hardware and Software Upgrades Configuring the NetApp Filer in the SAP Environment SAP Network Structure with the NetApp Filer Configuring Volumes and LUNs SAP Basis Administration with the NetApp Filer Filer Installation Space Management and Tuning Homogeneous System Copy Upgrades, Support Packages, and Database Reorganization SAP Customer-Based Upgrade (CBU) SAP Backup and Recovery with the NetApp Filer Introduction Split Mirror Backup on the Database Server Using Snapshot Copies Backup/Recovery with Snapshot and SnapRestore Recommendations: Backup/Restore Strategy in the SAP Environment Disaster Recovery Disaster Recovery with SnapMirror Oracle DataGuard Total Cost of Ownership (TCO) Acquisition Costs Operational Costs Business Costs Further Information 4 4 6 10 12 13 13 15 17 17 18 18 19 20 21 21 23 24 24 25 25 27 28 28 28 29 29

1.1 1.2 1.3 1.4

2

2.1 2.2
3

3.1 3.2 3.3 3.4 3.5

4

4.1 4.2 4.3 4.4

5

5.1 5.2
6

6.1 6.2 6.3

7

Network Appliance Inc.

TECHNICAL REPORT

Table of Figures
Figure 1) Figure 2) Figure 3) Figure 4) Figure 5) Figure 6) Figure 7) Figure 8) Figure 9) Figure 10) Figure 11) Figure 12) Figure 13) Figure 14) Figure 15) Figure 16) NetApp Filer Hardware....................................................................................................... 4 Filer Cluster........................................................................................................................ 6 WAFL File System ............................................................................................................. 7 SnapDrive GUI ................................................................................................................... 8 File System Structure......................................................................................................... 9 Snapshot Software............................................................................................................. 9 SnapRestore Software ..................................................................................................... 10 Filer Administration with Telnet ........................................................................................ 11 Filer Administration with Remote Shell............................................................................. 11 FilerView .......................................................................................................................... 12 Network Structure in the SAP Environment with a NetApp Filer....................................... 14 Volume Configuration....................................................................................................... 16 SAP Customer-Based Upgrade........................................................................................ 21 NetApp Snapshot Backup at the Database Server........................................................... 23 Disaster Recovery with SnapMirror .................................................................................. 26 Disaster Recovery with Oracle DataGuard (standby database) ....................................... 28

Network Appliance Inc.

TECHNICAL REPORT

1) Network ApplianceTM Filer Technology Developments in storage technology show that an increasing number of functions are being relocated from servers to storage systems. Storage systems are becoming a key element in computer centers and at decentralized locations. The server is regarded as a compute node, which provides computing power for the application. The storage system must ensure that these compute nodes are easily scalable and, therefore, support flexible data access and simple data sharing for the compute nodes.

1.1)

NetApp Filer Hardware

The Network Appliance filer hardware has a very simple structure and comprises industry-standard components. This minimizes maintenance and administration and ensures that the filer can be easily upgraded to include the latest technological developments. The Network Appliance filer comprises two main components: the filer head and the disk shelves.

Figure 1)

NetApp Filer Hardware

1.1.1) Filer Head Network Appliance manufactures filers with a range of performance levels. The filer head is a single unit and can be installed in any standard 19 rack. The head of the FAS250 series is a plug-in module for the shelf.

F800 series CPUs Expansion Slots Main Memory Non-Volatile RAM Power Supplies (hot-swappable) Intel 6 to 10 PCI 512MB to 3GB 128MB 2

FAS250 Broadcom n/a 512MB 64 2 (integrated in the shelf)

FAS900 series Intel 7-9 PCI-X 3 to 6GB 256MB 2

Network Appliance Inc.

TECHNICAL REPORT

TemperatureControlled Fans Base Connectivity

Hot-swappable 1x Ethernet 10/100 Copper

Integrated in the shelf power supplies 2x Ethernet 10/100/1000 Copper

Hot-swappable 1x Ethernet 10/100 Copper

Network Appliance offers the following PCI/PCI-X cards for the expansion slots: Intel 10/100Base-T network interface (F800) Intel 4-port 10/100Base-T network interface (F800) Intel Gigabit Ethernet copper/optical network interface (single/dual/quad) DAFS (GbE VI/IP) Fore ATM-OC3/OC-12 network adapter (F800) Cluster interconnect adapter HVD/LVD SCSI or FC adapter for tape drives FC adapter for connecting disk shelves Dual FC adapter for host attach

1.1.2) Disk Shelves The disk shelves are also designed to be installed in standard 19 racks. A disk shelf comprises the following components: Power supplies (hot-swappable). 14 bays for 18GB, 36GB, 72GB or 144GB Fibre Channel disk drives (hot-swappable). 2 LRC (loop redundancy circuit) or 2 ESH (electrically switched hub) modules for connecting the disk shelves to the filer head, looped through for connecting additional disk shelves. Several disk shelves can be connected to a single Network Appliance filer. Depending on the filer type, the maximum capacity for each filer is currently between 1TB and 24TB. Additional disk shelves can be connected to a Network Appliance filer without interrupting operation.

1.1.3) Filer Cluster Technology A cluster can be created with two filer heads by connecting the filer heads via a cluster interconnect. This connection is redundant and is used to exchange cluster heartbeats and synchronize the NVRAM on both filers. The disk shelves of the cluster partner are connected to the second filer head via a second Fibre Channel loop. If the first filer head fails, the second filer head handles its disk shelves. The MAC and IP addresses and the WWPN of the first filer head are also adopted. Since the NVRAM is mirrored on both filer heads via the cluster interconnect, no data is lost.

Network Appliance Inc.

TECHNICAL REPORT

Figure 2)

Filer Cluster

A filer cluster has an availability level of 99.998+%. Both filer heads in the cluster can be used actively. A filer cluster is recommended if server clustering is used for the application.

1.2) The Data ONTAPTM Operating System The Data ONTAP operating system is a highly efficient real-time kernel. The code base comprises approximately 1,500,000 code lines (in comparison, other operating systems have approximately 40 million code lines). There is no layered software, since all functions are executed in the kernel space. The entire code is written in C, which ensures that it is easily portable and less dependent on technological trends in the chip industry. 1.2.1) The WAFL File System Network Appliance has developed its own file system for the filer: the WAFL (Write Anywhere File Layout). It was designed to fulfill four basic objectives: Fast data access via NFS, CIFS, HTTP, DAFS, FCP, and iSCSI. Support large file systems with dynamic online expansion of the file system (currently up to 8TB). Use RAID (redundant array of independent disks) to protect against disk failures without compromising performance. Fast boot procedure and no file system check (for example, after a power failure).

Network Appliance Inc.

TECHNICAL REPORT

The WAFL file system is a block-oriented file system with a type of tree structure. The smallest organizational units are the data blocks. The metadata in the file system is also stored as a file, which enables a file system to be expanded online. The root inode, which forms the access point, branches to the inode file. The inode file contains the actual inodes, which, in turn, branch to individual files. The WAFL uses non-volatile RAM to maintain a file system log and respond quickly to write requests. Write requests are acknowledged as soon as they have been stored in the NVRAM; in other words, they do not have to be written to disk immediately.

Figure 3)

WAFL File System

To calculate the parity data, a RAID implementation must run through the read-calculate-write sequence for each write operation. The write anywhere design enables the WAFL to combine several write accesses in such a way that the read-calculate-write sequence of the parity information is also sufficient for several write accesses, thereby almost completely eliminating the main performance drawback of a RAID solution. Consistency points are written after each write operation from the NVRAM to the actual file system on disk, which ensures that the file system on disk is always consistent. In the event of a system failure (power failure, for example), transactions that have yet to be completed are executed and completed from the NVRAM when the system is restarted. The file system does not, therefore, have to be checked when the NetApp filer is booted. 1.2.2) SnapDrive/LUNs LUNs are files in a volume, which are shown as local disks at the servers. These disks can be accessed by using FCP or iSCSI. Network Appliance SnapDrive is a server-based software solution that provides advanced storage virtualization and management capabilities for Microsoft Windows environments. It is tightly integrated with the Microsoft NTFS file system and provides a layer of abstraction between application data and physical storage associated with that data. With SnapDrive, LUNs can be managed easily:

Creation and deletion of LUNs Mount and unmount of LUNs

Network Appliance Inc.

TECHNICAL REPORT

Online expansion of LUNs Generation of Snapshot copies Creation of Writable Snapshot copies SnapMirror LUNs

Figure 4)

SnapDrive GUI

1.2.3) Snapshot Copies File System Backup Snapshot copies are based on the WAFL tree structure. A virtual read-only copy of the file system can be created by copying the root inode. This copy is stored in the active file system as the ~snapshot in Windows.

Network Appliance Inc.

TECHNICAL REPORT

Figure 5)

File System Structure

Block/Snapshot assignments are managed in a block map file. Snapshot copies can be taken in just a few seconds and require hardly any additional disk capacity. When changes are made to files in the active file system, the "copy-on-write" method ensures that blocks that also belong to a Snapshot are not changed. Changes are stored in new blocks, and pointers in the file system are adjusted accordingly. A maximum of 255 Snapshot images can be stored in each volume. Additional disk capacity may be required depending on the dynamics of a file system.

Figure 6)

Snapshot Software

Fig.6 (a) shows a simplified representation of the file system with the root inode (active file system) and the corresponding branches to the individual data blocks. Fig.6 (b) shows a copy of the root inode, the Snapshot copy, and the corresponding branches. The root inode always points to the original data blocks until they are changed or deleted. Fig.6 (c) shows the process involved in changing a data block. The active file system no longer points to the original C data block, but instead to the new C data block created by the WAFL, while the Snapshot duplicate still points to the original C data block. Each Snapshot can be read online.

Network Appliance Inc.

TECHNICAL REPORT

1.2.4) SnapRestore Restore File System/Files SnapRestore enables an entire file system to be restored to the status of a specific Snapshot copy in a very short time. SnapRestore copies the inode table for a Snapshot copy back to the inode table for the active file system. SnapRestore requires only a few minutes to restore the data, regardless of the file system size.

Figure 7)

SnapRestore Software

Single File Restore provides the possibility to restore a file (iSCSI or FCP LUN) to the status of a specific Snapshot copy in a very short time. 1.2.5) SyncMirrorTM SyncMirror is synchronous mirror of a volume. It maintains a strict physical separation between the two copies of your mirrored data. In case of an error in one copy, the data is still accessible without any manual intervention. 1.2.6) SnapMirror Copy File System/Qtrees SnapMirror enables you to create an asynchronous mirror of a volume or qtree. After the initial transfer, SnapMirror transfers only the data blocks that have changed between two mirror updates. SnapMirror is based on Snapshot duplicates of the source file system, which are then transferred to the destination volume or qtree. The destination file system is, therefore, always consistent. The time interval between the mirror updates can be configured as required. The transport protocol used is TCP/IP, which means that SnapMirror is independent of the Layer1 and Layer2 network technology used. The bandwidth required by SnapMirror can be set as required. This mirror technique enables disaster recovery sites to be set up over long distances (via a WAN, for example). 1.3) Administration

The simple hardware and software designs of the Network Appliance filer also mean that it is easy to operate. No more than 40 commands are required for system administration. A command-line interface and browser-based graphical interface (FilerView) are provided for filer administration. In the Microsoft environment, standard tools (server manager, user manager) are used for share and user administration, and SnapDrive for LUN management. The command-line interface can be accessed via: The serial system console

Network Appliance Inc.

10

TECHNICAL REPORT

A telnet session or secure shell (ssh)

Figure 8)

Filer Administration with Telnet

A remote shell (rsh) Commands in scripts can be executed via the remote shell interface, which makes it ideal for automating administration tasks.

Figure 9)

Filer Administration with Remote Shell

Network Appliance Inc.

11

TECHNICAL REPORT

A Web browser (Microsoft Internet Explorer 5.x, Netscape Navigator 6.x) can be used to access the browser-based graphical interface (FilerView). To do so, enter the following address in the browser: http://filer_name/na_admin

Figure 10) FilerView

1.4)

Hardware and Software Upgrades

The NetApp filer hardware can be upgraded by simply exchanging the filer head. All the data, as well as the operating system itself, is stored on the disks in the disk shelves, which means that the hardware can be upgraded within minutes. The Data ONTAP operating system software can be upgraded while the system is running. To activate the new release, the NetApp filer must be restarted.

Network Appliance Inc.

12

TECHNICAL REPORT

2) Configuring the NetApp Filer in the SAP Environment 2.1) SAP Network Structure with the NetApp Filer

The SAP network structure with a NetApp filer comprises several network segments on Layer2. One segment enables the user to access the SAP application. The SAP GUI is connected to the dialog work processes on the application servers via this user LAN. When logon groups are used, the SAP GUI is connected to the message server work process. Since the message server runs on the central SAP instance, it must be possible to connect the SAP GUI to the central instance. A further network segment allows the SAP application servers, the SAP central instance, and the database server to communicate with each other. Since this network contains a large volume of data, this segment is normally separated from the user LAN. We recommend using a third network segment: the storage network. This can be a Gigabit Ethernet Network (iSCSI) or a Fibre Channel Network (FCP). The filer is also connected to the database backbone, thereby enabling all of the data and binaries on the SAP application server to be stored on the filer and manage the LUNs with SnapDrive. Connecting the filer to the user LAN allows filer administration to be carried out via telnet or FilerView, for example.

Network Appliance Inc.

13

TECHNICAL REPORT

Figure 11) Network Structure in the SAP Environment with a NetApp Filer

Network Appliance Inc.

14

TECHNICAL REPORT

2.2)

Configuring Volumes and LUNs

A volume on the NetApp filer is a file system, which contains LUNs. These LUNs are mounted by the connected server via FCP or iSCSI. A filer volume comprises one or more RAID groups; one RAID group is always assigned to exactly one volume. A RAID group comprises a minimum of 2 disks (1 parity disk and 1 data disk) and a maximum of 28 disks (1 parity disk and 27 data disks). The number of disks for each volume or RAID group can be configured as required by the user. The risk of a double disk failure increases with the number of disks in the RAID group. Therefore we recommend using a RAID group size of 8. When a disk in a RAID group fails, a spare disk automatically replaces it. Spare disks are all the disks in the system that have not been assigned to a volume. Write and read performance depend directly on the number of disks in the volume. Please ensure that enough disks are used, depending on your performance needs. If the "Writable Snapshot" and "LUN clone" NetApp filer features will be used, e.g., for homogeneous system copies of mySAP systems, more space will be needed in the volume due to these features. Create a copy of a LUN in the same volume. These copies can be created and used within seconds. The following example illustrates a three-system landscape comprising a production, integration, and development system on one NetApp filer. The Oracle and SAP data and binaries are distributed across LUNs and filer volumes as follows. The operating system is stored on the local server disks. All the other Oracle and SAP directories are stored on the filer. Each SAP system database is stored in its own LUN. The Oracle and SAP binaries are stored in one LUN for each system. The online and offline redo logs as well as all the other SAP directories are stored in one LUN for each system. For security reasons, the data files and the log files must be separated physically. For additional security the Oracle Mirrlogs can be stored in an additional LUN, which isn't in the same volume as the LUN containing the Oracle Origlogs.

Network Appliance Inc.

15

TECHNICAL REPORT

Figure 12) Volume Configuration Storing all the SAP and Oracle data means that the SAP server can be easily replaced. The SAP application can be transferred to a different server by simply mounting the LUNs. In this way, simple manual switchover solutions can be implemented (the OS, Oracle, and SAP software have to be installed at the new server). A NetApp filer simplifies storage management: Volumes and LUNs can be extended online. It takes only a few seconds to add disks to a file system. The additional capacity is available in the file system immediately. All the data files are stored in one LUN. You do not have to optimize performance by assigning specific tables or tablespaces to separate disks. The data LUN is shared by all tablespaces, thereby utilizing the available disk capacity to optimum effect.

Network Appliance Inc.

16

TECHNICAL REPORT

Several LUNs for several SAP systems can share a filer volume. Therefore the available resources are optimized. The time and effort involved in planning, creating, and scaling the disk layout are significantly reduced.

3) SAP Basis Administration with the NetApp Filer The tasks normally carried out by an SAP Basis administrator include the following: SAP system setup and installation Storage management - Disk layout tuning - Disk space management Data backup and recovery Creating homogeneous system copies Importing support packages or transports Database and SAP upgrades Database reorganization Disaster recovery solution setup and administration

3.1)

Filer Installation

It takes approximately 30 minutes to install a NetApp filer. The following section describes the steps involved in preparing a SAP installation. Basic filer configuration via setup dialog Network parameters (IP addresses, host name, DNS, and so on) User parameters (root password, and so on) CIFS parameters (domains, WINS, and so on) Volume configuration for the SAP system Create the two volumes for data and logs Create the qtrees Generate the CIFS shares Configure rsh access for SnapDrive Install SnapDrive on the server Create and mount the LUNs using SnapDrive All the file systems required for the SAP installation are then available Start the SAP installation

Network Appliance Inc.

17

TECHNICAL REPORT

3.2)

Space Management and Tuning

The LUNs are very easy to manage because SnapDrive is able to expand LUNs online without interrupting the SAP application. Also, additional volume capacity can be made available at any time without interrupting the application. If the system still contains spare disks, additional disks can be assigned to a volume. The volume can be increased online and the additional capacity is made available in the file system immediately. If no spare disks are available in the system, an additional disk shelf can be installed in the system without interrupting operation. Areas from different volumes can always be used for additional LUNs mounted from the SAP server. The NetApp filer volumes are structured in such a way that the disk layout does not have to be tuned by moving individual tablespaces or tables, since optimum I/O distribution across all the disks in the volume is always ensured.

3.3)

Homogeneous System Copy

Copies of the SAP production system must be created on a regular basis for the following reasons: Setting up a new integration system with current master and transaction data Setting up a new development system as a copy of the production system Testing an SAP upgrade, database reorganization, with "real" production data One option here is to copy all the Oracle data files. An existing offline backup of the production data is often used for this purpose. When a NetApp filer is used, a system copy can be created using writable Snapshot copies and LUN cloning (LUN cloning converts a writable Snapshot duplicate to a normal LUN while the system is online). With all variants, the source database must be set to offline for only a short time to minimize the impact on the production system while the system copies are being made. If an online Snapshot backup is used, no downtime is necessary. Procedure when taking a Snapshot/writable Snapshot: Shut down the database or bring all tablespaces/data files to backup mode. Take the Snapshot copy using SnapDrive GUI or CLI. Start the database or bring all tablespaces/data files to normal mode. Mount the Snapshots of the LUNs to the destination server. For system copies that are needed only for a short time, this writable Snapshot copy can be used. LUN clone procedure: Shut down the database or bring all tablespaces/data files to backup mode Take the Snapshot using SnapDrive GUI or CLI Start the database or bring all tablespaces/data files in normal mode Create a writable Snapshot copy using the filer command lun create b

Network Appliance Inc.

18

TECHNICAL REPORT

Clone the writable Snapshot using the filer command lun clone Connect the LUN to the server using SnapDrive

3.4) Upgrades, Support Packages, and Database Reorganization Upgrading a database, carrying out an SAP upgrade, or importing support packages and critical transports always involves SAP system downtime. It is important that this downtime is kept to a minimum and that the previous state can always be restored. The specified system changes are usually first made in the development system in order to test the general functionality and procedures. To estimate the time required for the conversion, a current system copy of the production data is created in the integration system. This enables the functionality of the changes to be tested with the current master and transaction data. The following section describes the process involved in an SAP upgrade. The basic procedure for importing support packages and so on is identical.

UPGRADING IN A 3-SYSTEM LANDSCAPE

NETAPP FILER FEATURES

ADVANTAGES FOR SCHEDULING

Upgrading the development system: 1. 2. 3. Back up the development system. Perform the upgrade. In the event of an error, restore the system and repeat the upgrade. 4. Test the functionality, create the modification adjustment. Back up with a Snapshot copy (-> few seconds). In the event of an error, restore with SnapRestore (-> few minutes). No tape backup required. Restore from tape not required.

Upgrading the integration system: 5. Create a homogeneous production system copy in the integration system. 6. 7. 8. Back up this new integration system. Perform the upgrade. Test the functionality, import the transports of the modification adjustment. Homogeneous system copy with writable Snapshot or LUN cloning. Back up within a Snapshot copy (-> few seconds). Restore from tape not required. No tape backup. Required.

Upgrading the production system: Back up with a Snapshot copy No tape backup

Network Appliance Inc.

19

TECHNICAL REPORT

9.

Back up the production system.

(-> few seconds). Take several Snapshot copies during the upgrade (e.g., before importing the transports for the modification adjustment) (-> few seconds). Back up the system with the new release status by taking a Snapshot copy. In the event of an error, restore the system to the former release status with SnapRestore (-> few minutes).

required.

10. Perform the upgrade. 11. Test the functionality, import the transports of the modification adjustment. 12. Back up the production system with the new release status or restore the system to the former release status in the event of an error. 13. Release the system for production.

No tape backup required/restore from tape not required.

In many cases, test systems must be upgraded several times, since problems can occur that can only be solved by restoring the system and restarting the upgrade. In this respect, Snapshot and SnapRestore can save a considerable amount of time. A tape backup does not have to be made; a Snapshot can be taken instead. In the event of an error, the system can be quickly restored to its original status with SnapRestore and the upgrade repeated. When the integration system is upgraded, the homogeneous system copy can be created using writable Snapshot duplicates or LUN cloning. This significantly reduces the time required in comparison with a restore from tape. A backup of the system can be made with a Snapshot after the system copy has been created, and does not have to be made on tape. Scheduling is extremely important when the production system is upgraded, since the system is not available at various stages during the upgrade. Scheduling must also allow time for restoring the system to its former release status. Depending on the size of the database and the time and effort required for the functional test and importing the transports for the modification adjustment, one normal weekend may not be sufficient for the upgrade. Using Snapshot as a backup method and SnapRestore for restoring the system to its former release status ensure a higher level of flexibility with regard to scheduling. By taking several Snapshot copies at certain stages of the upgrade, you can, to save time, restart the upgrade without having to revert to the former release status.

3.5)

SAP Customer-Based Upgrade (CBU)

The SAP customer-based upgrade is an upgrade variant that significantly reduces downtime while a production system is being upgraded. A simplified step-by-step representation of the customer-based upgrade is shown below: Create a copy of the production system Carry out a standard upgrade on the system that has been copied

Network Appliance Inc.

20

TECHNICAL REPORT

Carry out the modification adjustment Export the repository of the upgraded system Create a copy of the production system Perform the upgrade with the repository export created Verify the upgrade Perform the upgrade on the production system with the repository export created

Figure 13) SAP Customer-Based Upgrade During a customer-based upgrade, the production database must be copied at least twice. Even with this upgrade variant, the standard upgrade and the upgrade with the repository export created may have to be carried out several times on the system that has been copied. This could mean that the production system has to be copied more than twice. The LUN cloning feature provides a quick and easy method for handling this with minimum impact on the production system. With this upgrade variant, Snapshot and SnapRestore offer the same advantages as those described in 3.4.

4) SAP Backup and Recovery with the NetApp Filer 4.1) Introduction

When implementing backups or doing a restore with recovery, the following characteristics are important:

Network Appliance Inc.

21

TECHNICAL REPORT

1. Time window available for the execution of the backup (backup window) 2. Actual time window necessary for the execution of the backup 3. Maximum justifiable time window for the execution of a restore with recovery 4. Actual time window necessary for the restore with recovery (MTTR, mean time to recover) Points 1 and 3 are characteristics given by the environment of the SAP application. Productive systems must often be available 24 hours times 7 days. Thus the backup window is very small. The maximum justifiable time window for a restore with recovery usually depends on the business processes that are disturbed by the stop of the SAP system, and the costs that result from this stop. These characteristics are not determined by the technology used, but by the business processes that use this technology. Characteristics 2 and 4 are values, which are defined only by the technology used. This technology must ensure that the backup can be carried out in the available backup window, and a restore with recovery can be done in the time window defined by 3. When executing a backup, two fundamental variants must be differentiated: Offline backup (cold backup) In this case the database is shut down before the execution of the backup and started again when the backup is finished. The SAP application is not available during the backups. The characteristic for this backup variant is the amount of time that the database is not available. Online backup (hot backup) In this case the database is switched into hot backup mode before the execution of the backup. When the backup is finished, hot backup mode is switched off again. The characteristic for this backup variant is the amount of time the database is in hot backup mode, since this mode means a performance decrease. The time that is necessary for a restore with recovery consists of two values: The time for the restore of the database from the backup medium The time for the recovery of the database with all redo logs from the time the backup was made to the point of failure The NetApp filer features Snapshot and SnapRestore allow backups when only very small backup windows are available, and offer a drastic time reduction when executing restores with recovery. Back up the database on tape with brbackup using the SAP Split Mirror scenario. In this scenario the database is saved from the Snapshot copy. With this procedure, the time the database is offline (cold backup) or runs in the hot backup mode is reduced to a few minutes or a few seconds. Back up the database by taking a Snapshot copy => Back up to disk in a few seconds. Backups can be taken in smaller time intervals (hour range) during online operation. Restore the database to the state of a Snapshot copy with SnapRestore. The restore takes only a few seconds regardless of the size of the database.

Network Appliance Inc.

22

TECHNICAL REPORT

Fast recovery of the database because only a few redo logs have to be applied = > prerequisite: Several Snapshot copies were taken during online operation.

4.2)

Split Mirror Backup on the Database Server Using Snapshot

The SAP brbackup tool enables the database to be backed up from a mirror. This mirror is split before the backup is made. This method supports both online and offline backups, during which the Oracle database is only offline or switched to hot-backup mode for a short time. This function provides a highly efficient way of backing up large databases or systems with small backup time frames. The backup can be made directly on the database server or via a separate backup server. The separate backup server minimizes the effects on production system performance when the data is backed up. The database can be backed up using all the methods supported by brbackup (local tape, backint, etc.). The employment of the NetApp Snapshot technology offers several advantages in relation to normal techniques in the SAP Split Mirror environment. No double disk capacity necessary for the mirror Simple configuration for the mirrored disks with SnapDrive No file system check necessary after the mirror is split Easy mount of the mirror disks after the mirror is split

Figure 14) NetApp Snapshot Backup at the Database Server

Network Appliance Inc.

23

TECHNICAL REPORT

4.3)

Backup/Recovery with Snapshot and SnapRestore

With Snapshot, complete copies of the database can be provided in a few seconds. These copies can be restored completely with SnapRestore. The restore of a Snapshot duplicate with SnapRestore takes only a few seconds. Snapshot copies work on volume levelSnapRestore with SnapDrive restores only the chosen disk. To be able to perform a rollforward of the database with the online and offline redologs, different issues must be considered. The online redo logs and the offline redo logs (OriglogA/B, MirrlogA/B, and Saparch) must be stored in disk other than the data files (Sapdata1-6). At least one copy of the control files must be outside the Sapdata LUN. After a SnapRestore operation is accomplished, this control file must be copied into the appropriate directory in the Sapdata LUN. If all control files are stored in the Sapdata LUN, a rollforward can be made only by: recover database using backup control file;. After such a recovery the database can be opened only with alter database open resetlogs;. This has the disadvantage that then complete recovery of an older backup is not possible. To be able to reset the database to the state of a Snapshot copy, one control file must be stored in the Sapdata LUN. If possible, only the Sapdata directories should be stored in the Sapdata LUN, so that no log files, etc., are reset to an old timestamp when using SnapRestore.

4.4)

Recommendations: Backup/Restore Strategy in the SAP Environment

4.4.1) SAP Production Systems When backups or restores are carried out using Snapshot and SnapRestore technology a substantial time gain is possible. Take a daily online or offline backup with Brbackup and SAP Split Mirror with Snapshot. The time the database is offline or the time the database is in hot backup mode is limited to a few minutes or seconds. Whether the backup is to be taken directly at the database server or with a separate backup host depends on the performance influence, which can be accepted at the database server. These Snapshots can be stored, for example, one week. Take several Snapshot copies of the database in hot backup mode daily, for example, every two hours. These copies provide a very fast restore of the database with SnapRestore. In the case of an error, the offline redo logs of the last two hours must be applied. The backup of the offline redo logs with Brarchive should be taken in such a way that the logs of the last two hours are still on disk, so that in the restore/recovery case no logs must be restored from tape. In this example 7+12=19 Snapshot copies are held in the Sapdata volume. Altogether 255 Snapshot copies are possible per volume. The space requirement of the duplicators depends on the change behavior of the SAP application. The number of backups taken with Brbackup and the number of additional Snapshot copies in hot backup mode must be planned for each customer individually.

Network Appliance Inc.

24

TECHNICAL REPORT

When installing support packages, doing an SAP Upgrade, euro conversion, or database reorganization, the use of Snapshot offers additional timesavings. In case of an error the system can be quickly brought back to the starting point using SnapRestore. Thus it's possible to repeat the procedure and to carry out the conversion successfully. A restore from tape takes too long, depending on database size, to be able to make a second attempt.

4.4.2) SAP Test Systems Test runs of larger conversions are carried out on test systems in the SAP environment before these conversions are done on the production system. Examples are: Installing support packages SAP upgrade Database reorganization Normally these test runs have to be done more than once, or have to be repeated in the case of an error. The use of Snapshot and SnapRestore provides the possibility of quickly resetting the test system to the starting point, without restoring the system from tape.

5) Disaster Recovery 5.2) Disaster Recovery with SnapMirror

As an asynchronous mirror, SnapMirror enables a disaster recovery site to be connected via a WAN. The WAN connection between the filers can take the form of any TCP/IP network. The bandwidth used by SnapMirror for transferring data can be configured as required. SnapMirror works on the following principle: Level 0 transfer: SnapMirror makes a Snapshot copy of the source volume or qtree and copies all the blocks to the destination volume or qtree. Incremental transfer: SnapMirror makes a Snapshot duplicate and copies all the blocks that have been changed since the last Snapshot to the destination volume or qtree. The time intervals between the incremental transfers can be configured as required (minimum value: 1 minute). After the level 0 transfer has been completed, only the blocks that have been changed at the source are transferred. This means that SnapMirror can also be used across networks with smaller bandwidths. The bandwidth actually required depends on how the SAP application changes. The amount of data lost in the event of a disaster depends on the frequency with which the incremental transfers are carried out. If a database mirror is to be created using this method, all the data files and all the online and offline redo logs must be stored in one LUN.

Network Appliance Inc.

25

TECHNICAL REPORT

Figure 15) Disaster Recovery with SnapMirror If it is crucial that no data is lost in the event of a disaster, a different method must be chosen. This requires a Gigabit Ethernet connection between the primary and disaster recovery sites. A LAN between the primary and disaster recovery sites can normally be implemented on the company premises.

Procedure: Mirror the data volume/LUNs with SnapMirror Take a Snapshot copy using the SnapDrive CLI of the source data LUNs while the database is in hot backup mode. Once this Snapshot copy has been taken, the SnapMirror mirror must be updated by using SnapDrive. In this way, the destination volume always contains a Snapshot image that matches an online backup of the database. This means that a forward recovery with this initial status is always possible using the mirrored online and offline redo logs. Mirror the online redo logs with Oracle methods (-> additional log member) Mirror the offline redo logs with Oracle methods (-> additional archive destination) With this procedure, the functionality of a synchronous mirror with regard to data loss is supported, and the advantages of an asynchronous mirror with regard to variable point-in-time recovery are retained. In

Network Appliance Inc.

26

TECHNICAL REPORT

addition, the disaster recovery site can be used to back up the primary site, since the Snapshot copies taken at the primary site match an online backup of the database, and all the archive logs are available at the disaster site.

SnapMirror fulfills all disaster recovery requirements: Disaster recovery via a WAN enables large distances between the primary and disaster recovery site to be covered. Disaster recovery via a LAN does not result in any loss of data. Flexible forward recovery enables logical errors that have already occurred to be eliminated at the recovery site. The primary site is relieved of backup tasks.

5.2)

Oracle DataGuard

Oracle DataGuard (standby database) provides a synchronous or asynchronous mirror of an Oracle database. It fulfills all disaster recovery requirements: The physical standby database (asynchronous mode) enables large distances between the primary and disaster recovery site to be covered. The logical standby database (synchronous mode) does not result in any loss of data. Flexible forward recovery enables logical errors that have already occurred to be eliminated at the recovery site. Oracle DataGuard protects the database from corrupted blocks. The primary site can be relieved of backup tasks.

A disaster recovery scenario with the Oracle standby database involves the following basic steps: Install the SAP/Oracle environment at the disaster recovery site (binaries, directory structure, users, and so on). Copy all the databases and log files from the primary site to the disaster recovery site. Create a special control file for the standby database. Mount the standby database in "standby database mode." Use Oracle DataGuard to copy the archive logs from the primary site to the disaster recovery site and to import the archive logs to the standby database (physical standby database). Use Oracle DataGuard to apply the SQL statements from the primary database (logical standby database) to the standby database at the disaster recovery site.

Network Appliance Inc.

27

TECHNICAL REPORT

Figure 16) Disaster Recovery with Oracle DataGuard (standby database)

6) Total Cost of Ownership (TCO) 6.1) Acquisition Costs

Since the NetApp filers are highly scalable, the system currently required can be purchased. The system can be expanded in line with future requirements. Snapshot technology enables functions to be implemented that are otherwise only possible with several 1:1 mirrors. As a result, certain functions require less disk capacity. 6.2) Operational Costs

Thanks to the appliance philosophy of the NetApp filer, installing and managing the filer require very little time and effort. Daily administrative tasks, such as disk layout tuning and backup recovery design, are either considerably easier or no longer have to be carried out at all, resulting in lower overall personnel costs for operating the SAP systems. Installation The storage network is based on standard Ethernet or Fibre Channel components. The filer takes approximately 15 minutes to install.

Administration

Network Appliance Inc.

28

TECHNICAL REPORT

Planning disk layout tuning The volume-based file systems, in which the LUNs reside, mean that a large number of individual file systems do not need to be created for the individual data areas. Individual tablespaces or tables do not have to be moved to improve performance, since the file system of the NetApp filer enables the read and write accesses to be distributed efficiently across all the disks in a volume. Backup recovery The Snapshot NetApp filer feature enables backups to disk to be made very quickly. The number of Snapshot copies possible in each volume allows several Snapshot copies a day to be taken. With SnapRestore, a restore can be carried out very quickly on the basis of these Snapshot images. In this way, the usual backup (small backup time frame) and restore (fast restore and recovery) requirements can be easily fulfilled.

6.3) Business Costs The NetApp filer significantly reduces both planned and unplanned downtime, which, in turn, significantly reduces the business costs incurred during SAP system downtime.

Planned downtime SAP upgrade, importing support packages, database reorganization, and so on. System expansions: capacity, throughput Hardware and software upgrades Snapshot, SnapRestore, writable Snapshot copies and LUN cloning can save considerable time when the SAP system is upgraded, for example. Disk capacity can be made available to the connected systems online and with no downtime. Hardware and software upgrades can be carried out with minimum downtime (a few minutes). Unplanned downtime System failure caused by software or user errors System failure caused by hardware errors With Snapshot and SnapRestore, recoveries after software or user errors can be performed much more quickly. System failures caused by hardware errors are significantly reduced by using the filer cluster and setting up disaster recovery sites with SnapMirror.

7) Further Information Installing SAP R/3 with a NetApp filer: SAP R/3 Oracle/Windows/MSCS: Integrating with a NetApp Filer: http://www.netapp.com/tech_library/3172.html

Network Appliance Inc.

29

TECHNICAL REPORT

SAP R/3 Oracle backup/recovery with a NetApp filer: SAP R/3 Oracle/Windows: Backup and Recovery with NetApp Filers: http://www.netapp.com/tech_library/3213.html

Oracle DataGuard with a NetApp filer: Using Oracle Data Guard with the NetApp Filer: Disaster Recovery with Zero Data Loss http://www.netapp.com/tech_library/3219.html

General information on NetApp filers: High-Availability Storage Appliance: http://www.netapp.com/tech_library/3127.html Architecting a Gigabit SAN for Database Application Environments: http://www.netapp.com/tech_library/3112.html Data Protection Strategies for Network Appliance Filers http://www.netapp.com/tech_library/3066.html Data Protection Solutions Overview http://www.netapp.com/tech_library/3131.html SnapMirror and SnapRestore: Advances in Snapshot Technology http://www.netapp.com/tech_library/3043.html

Network Appliance Technical Library: http://www.netapp.com/tech_library

Network Appliance, Inc. Company Confidential and Proprietary. Network Appliance Inc. 2002 Network Appliance, Inc. All rights reserved. Specifications subject to change without notice. NetApp, the Network Appliance logo, FAServer, FilerView, NetCache, SecureShare, SnapManager, SnapMirror, SnapRestore, and WAFL are registered trademarks and Network Appliance, ApplianceWatch, BareMetal, Camera-to-Viewer, Center-to-Edge, ContentDirector, ContentFabric, ContentReporter, DataFabric, Data ONTAP, EdgeFiler, HyperSAN, InfoFabric, MultiStore, NearStore, NetApp Availability Assurance, NetApp ProTech Expert, NOW, NOW (NetApp on the Web), RoboCache, RoboFiler, SecureAdmin, Serving Data by Design, Smart SAN, SnapCache, SnapCopy, SnapDirector, SnapDrive, SnapFilter, SnapMigrator, Snapshot, SnapSuite, SnapVault, SohoCache, SohoFiler, The evolution of storage, Vfiler, and Web Filer are trademarks of Network Appliance, Inc. in the U.S. and other countries. All other brands or products are trademarks or registered trademarks of their respective holders and should be treated as such.

30