Professional Documents
Culture Documents
GetPDF aspx/4AA1-7725ENW PDF
GetPDF aspx/4AA1-7725ENW PDF
Overview . . . . . . . . . . . . . . . . . . . . . . .
Goals . . . . . . . . . . . . . . . . . . . . . . .
Solution configuration . . . . . . . . . . . . . . . . . .
Overall solution configuration . . . . . . . . . . . . .
Blade enclosure configuration . . . . . . . . . . . .
SAP production system application server . . . . . .
SAP production system database server . . . . . .
SAP test/QA system server . . . . . . . . . . . .
SAP development system server . . . . . . . . . .
Management server . . . . . . . . . . . . . . .
Active Directory domain controller and load generator
Storage configuration . . . . . . . . . . . . . . . .
Testing . . . . . . . . . . . . . . . . . . . . . . . .
Test objectives . . . . . . . . . . . . . . . . . . .
Test setup . . . . . . . . . . . . . . . . . . . . .
Performance testing setupUser load . . . . . . .
Performance testing setupActive data sizes . . . .
Backup/restore setup . . . . . . . . . . . . . .
Test results . . . . . . . . . . . . . . . . . . . . .
SAP system tuning . . . . . . . . . . . . . . .
SQL memory tuning . . . . . . . . . . . . . . .
Server performance . . . . . . . . . . . . . . .
Storage results . . . . . . . . . . . . . . . . .
Data protector functionality . . . . . . . . . . . .
SAP backup/restore testing with Data Protector . . .
Monitoring database backup/restore from SAP . . .
Best practices and results . . . . . . . . . . . . . . . .
SAP administrator . . . . . . . . . . . . . . . . . .
Database administrator . . . . . . . . . . . . . . .
Storage administrator . . . . . . . . . . . . . . . .
Backup/recovery (Data Protector) administrator . . . . .
Conclusion . . . . . . . . . . . . . . . . . . . . . .
We value your feedback . . . . . . . . . . . . . . .
Appendix A Bill of Materials . . . . . . . . . . . . . . .
Appendix B Setting up and using Data Protector 6.0 . . . . .
Data Protector installation . . . . . . . . . . . . . .
Adding clients . . . . . . . . . . . . . . . . .
Adding devices . . . . . . . . . . . . . . . . .
Set up and use SQL Server backup . . . . . . . .
Restore SQL Server . . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
(optional)
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3
4
4
5
5
5
5
6
6
6
6
9
9
9
9
9
10
10
10
13
14
15
16
18
19
23
23
23
23
23
25
26
27
28
28
29
33
37
39
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
41
42
44
44
44
44
Overview
Small-to-medium businesses (SMBs)companies with 100499 employeesare projected to
increase their IT spending at rates that are higher than the overall market. Most SMBs also intend to
increase their ratio of new investments to overall IT spending. These trends reflect business growth
initiatives. The most prevalent initiatives include deploying major new software applications and
replacing or upgrading existing applications. To support these initiatives, SMBs will be seeking to
upgrade or replace their servers and storage.
Goals
The goal of this project is to develop detailed best practices for deploying a 250-user/250-GB
three-tiered SAP ERP landscape in an HP BladeSystem c3000 blade enclosure with HP ProLiant
BL460c blade servers running Microsoft Windows Server 2003, an HP StorageWorks Enterprise
Virtual Array (EVA) 4400 disk array, and an Ultrium 448c tape blade with HP Data Protector
software. The goal is to provide best practices that can help accomplish the following:
Accelerate the time and reduce the effort to deploy
Optimize performance
Simplify operation
Lower risks
Minimize total costs
This paper describes the test results, methods, and best practices derived from the testing, and it
addresses the following fundamental deployment and operational issues:
Best practices for configuring an entire three-tiered SAP landscape across the server blades,
optimizing both performance and availability
The appropriate configuration for the HP EVA disk array, including the following:
Configuring the disks into the appropriate number of EVA disk groups, including a comparison
of the pros and cons of using one EVA disk group for all data versus isolating production
data into its own disk group
Solution configuration
Overall solution configuration
This project tests an SAP ERP 2005 landscape, using MS SQL Server 2005 on Windows Server
2003. The SAP landscape runs on the ERP Central Component (ECC) 6.0, NetWeaver 7.0, and
includes a development system, a test/quality assurance (test/QA) system, and a highly available
production system. We test performance of these systems with an ERP workload using a 250 GB
database and 250 users on the production system. Additional users are simulated on the test/QA
and development systems. HP also tests SAP management and backup/recovery to tape with SAP
Solution Manager 7.0 and HP Data Protector 6.0 respectively.
The hardware includes an HP BladeSystem c3000 with an EVA4400 for backend storage. These
components are connected through two Brocade 4-GB SAN switches for HP c-Class BladeSystem.
Figure 1 shows the logical configuration.
The powerful, yet compact nature of this setup allows the entire SAP landscape to fit easily inside a
14U rack, an ideal configuration for small and medium-sized businesses. Figure 2 shows the SAP
landscape in a 14U rack.
Storage configuration
The backend storage is composed of an EVA4400 2C2D with 24 146-GB 15 K RPM Fibre Channel
(FC) drives, which is tested in two different configurations:
Configuration 1 consists of a single disk group for all three SAP systems.
Configuration 2 consists of two disk groups: one with 16 drives for the SAP production system
(because that system consistently receives the heaviest workload and its performance is more
critical than that of the other two systems), and a second disk group with the remaining eight
drives that is shared by the SAP test/QA and development systems.
Figure 4 illustrates these configurations.
For both array configurations, we use Vraid 5 for all virtual disks (Vdisks) except those that store
database transaction logs, which use Vraid 1. Each SAP system has its own SQL database, and
we use two database data files in each database (the default is three). Because the EVA has two
controllers and the data files are accessed more heavily than most of the other files created by SAP,
we use an even number of data files, with each file on its own Vdisk. This configuration allows the
EVA to evenly load balance those Vdisks and their workloads across the controllers.
Best practice
Use an even number of data files balanced across an even number of Vdisks to allow optimal controller load balancing in
the EVA.
Table 1 summarizes the components. For more information, see Appendix A Bill of Materials.
Table 1. Component list
Components
Component type
Description/use
Servers
Tape blade
Backup hardware
HBAs
Switches
EVA
Backend storage
Software
Backup/recovery application
Testing
Test objectives
The testing goal is to determine the equipment capabilities and best practices for setting up the
described SAP landscape. Specific goals include the following:
Determine best practices for storage configuration.
Determine best practices for placing a three-system SAP landscape in a c3000 blade enclosure.
Verify best practices from previous CFT SAP white papers for current hardware. For
more information, see Best practices for SAP ERP using HP Blade System c-Class
blades at http://h71028.www7.hp.com/ERC/downloads/4AA1-5661ENW.pdf and
Best practices for configuring and deploying SAP ERP using HP ProLiant servers, HP
StorageWorks 8000 Enterprise Virtual Array, Windows Server, and Microsoft SQL Server at
http://h71028.www7.hp.com/ERC/downloads/4AA1-5523ENW.pdf.
Test Data Protector backup/recovery functionality for SAP.
Test setup
Four different scenarios are tested to attain the most accurate data possible. The variables defining
the four test scenarios include the storage array configuration (one disk group or two) and the
active data set size (small or large).
Performance testing setupUser load
For testing the performance of the SAP landscape, we use a series of scripts to simulate an ERP
workload for a given number of users and to generate the appropriate I/O load on the system.
This project requires running tests for each system concurrently. HP cautions against running the
test/QA and development systems during peak usage times of the production system. However, we
do this to ensure that the environment can handle the unlikely situations in which you must heavily
exercise all three systems simultaneously.
The primary goal is to simulate 250 production-system users, with fewer users for each additional
system. Table 2 shows the simulated load for each system.
Table 2. Simulated-user load
System
Users
Production system
250 users
Test/QA system
Development system
Total
550 simultaneous users running in the SAP landscape for each test
To understand how the array performs with such variations, two different active data capacities in the
database are tested. This reveals difference in performance between a young, sparsely populated
database and a database with large amounts of data. Similar to the user load, the active data sizes
are scaled down for the test/QA and development systems. Table 3 shows the active data sets.
Table 3. Active data sets
Data set
System
Capacity
Total used
capacity
Production system
150 GB
Note
This simulates a production system
database with a 250 GB capacity that
is 30% full.
Test/QA system
20 GB x 2 data files = 40 GB
Development system
15 GB x 2 data files = 30 GB
Production system
350 GB
Note
This simulates a production system
database with a 250 GB capacity that
is 75% full.
Test/QA system
Development system
30 GB x 2 data files = 60 GB
Backup/restore setup
We use Data Protector 6.0 to back up the SAP production system to tape through the Ultrium 448c
tape blade in the c3000 enclosure.
Note
All three SAP systems can be backed up with Data Protector; however, we focused testing on only the production system.
Data Protector contains an SAP backup agent. However, the agent component uses the SAP backup
tools (BR tools) which are only available when Oracle is the underlying database. When SAP uses
a database other than Oracle, the backup components for that specific database must be used along
with file system backups. Therefore, we use the SQL Server and file system backup components to
perform our SAP backups. For more information on the actual setup and use of Data Protector, see
Appendix B Setting up and using Data Protector 6.0.
Test results
SAP system tuning
These testing results verify best practices presented in Best practices for SAP ERP using HP Blade
System c-Class blades at http://h71028.www7.hp.com/ERC/downloads/4AA1-5661ENW.pdf
10
and Best practices for configuring and deploying SAP ERP using HP ProLiant servers, HP
StorageWorks 8000 Enterprise Virtual Array, Windows Server, and Microsoft SQL Server at
http://h71028.www7.hp.com/ERC/downloads/4AA1-5523ENW.pdf.
Before testing the SAP landscape, we run a few baseline tests and observe the swaps occurring in the
production system (using SAP transaction ST02). To obtain improved performance, we then tune
the SAP system according to the best practices documented in previous white papers by CFT SAP
engineers. According to these white papers, SAP default values provide a very limited capacity for
several memory buffers. Therefore, we tune the memory buffers using SAP transaction RZ10 and
adjust the system to use the buffer values recommended in the white papers:
abap/buffersize = 500,000
zcsa/db_max_buftab = 80,000
zcsa/table_buffer_area = 120,000,000
rsdb/obj/max_objects = 40,000
rsdb/obj/buffersize = 81,920
rdisp/ROLL_SHM = 32,768
rdisp/ROLL_MAXFS = 32,768
rdisp/PG_SHM = 16,384
em/initial_size_MB = 10,000
Note
These values were adjusted to eliminate SAP swapping for the current workload. Because each environment is
different, tune each system in your environment based on the amount of memory given to SAP and according to the
recommendations in the referenced white papers.
Previous testing indicates that the default number of the Dialog, Update1, and Update2 work
processes rarely equal the recommended number. Testing also indicates that it is beneficial to have
five work processes per CPU core. Accordingly, we adjust the SAP systems to 20 work processes
each (five work processes for each of the four CPU cores in each server).
Adjusting the number of work processes involves using transaction RZ10 and changing the following
parameters:
rdisp/wp_no_dia (Dialog Work Process)
rdisp/wp_no_vb (Update Work Process 1)
rdisp/wp_no_vb2 (Update Work Process 2)
The following is a good balance for the work processes of servers with two dual core processors:
17 Dialog processes
2 Update1 processes
1 Update2 process
11
When tuning an SAP system, tune each profile in the system (not just the default profile). Also, be
sure to tune each system in the SAP landscape independently, according to the number of processor
cores the system has.
After tuning the memory buffers and work processes, we repeat the baseline tests and observe that
all SAP swapping has ceased. Figure 5 shows the Swaps column of transaction ST02.
In addition to eliminating SAP swaps, system response times decreased by up to 5 ms, depending
on the system and workload applied. While this improvement is relatively small for the workload,
other environments and workloads may benefit greatly from these adjustments. These results verify the
best practices presented in the previous CFT SAP white papers.
Best practice
To eliminate SAP swaps, tune the memory buffer according to the suggestions in Best practices for SAP ERP using HP Blade
System c-Class blades at http://h71028.www7.hp.com/ERC/downloads/4AA1-5661ENW.pdf and Best practices for
configuring and deploying SAP ERP using HP ProLiant servers, HP StorageWorks 8000 Enterprise Virtual Array, Windows
Server, and Microsoft SQL Server at http://h71028.www7.hp.com/ERC/downloads/4AA1-5523ENW.pdf.
12
Best practice
For better system performance, tune the number of SAP work processes to five per CPU core. For more information,
see Best practices for SAP ERP using HP Blade System c-Class blades at http://h71028.www7.hp.com/ERC/
downloads/4AA1-5661ENW.pdf and Best practices for configuring and deploying SAP ERP using HP ProLiant
servers, HP StorageWorks 8000 Enterprise Virtual Array, Windows Server, and Microsoft SQL Server at
http://h71028.www7.hp.com/ERC/downloads/4AA1-5523ENW.pdf.
13
Best practice
If using a dedicated database server, allocate all available memory except for approximately 2 GB RAM (for the
operating system) to SQL Server. Doing so provides more capacity in SQL Servers cache.
Server performance
With SAP tuned appropriately, tests of the environment with all 550 concurrent users (250 production
users and 300 users of the test/QA and development systems) reveal that the servers are fully capable
of handling the user load. On the production system, average processor utilization for the application
server ranges between 35% and 40%, with even lower usage of the database server processors.
For scale-up testing, we double the production system workload to about 500 users on the production
system alone and find its processors are still able to handle the load, running at about 70% utilization
on the application server.
SAP uses CPU core zero more than the other cores on each application server. During this scale-up,
core zero is used at about 80%. Pay close attention to core zero because its saturation could quickly
cause increased SAP system response time. This is because the SAP dispatcher does not evenly
dispatch the work to all available work processes.
14
Best practice
Be sure to monitor core zero on application servers. Saturating core zero will greatly increase response times in the system.
Storage results
Two array configurations are tested:
Single disk group
Two disk groups with the production system in its own group of 16 drives
For each array configuration, two active data set sizes are tested:
Small data set: 150 GB
Large data set: 350 GB
The production system has the highest priority in an SAP environment because of its direct impact on
business data availability. To maintain a responsive production system, we target 20 ms or less for
EVA disk latency. With a single disk group and a small set of active data, the production system
performs well at 18 ms. However, when the database has more data, the production system disk
latency degrades to 22 ms. Figure 8 shows the EVA latencies for a single disk group.
Figure 8. Single disk group: EVA latencies (ms) per SAP system
An analysis of the two-disk configuration (16 disks for the production system and eight disks for the
test/QA and development systems), reveals that the production system (the most critical system)
performs well (less than 15 ms) despite the heavy load on the other two systems. Figure 9 shows the
EVA latencies for two disk groups.
15
Figure 9. Two disk groups: EVA latencies (ms) per SAP system
Initially, the test/QA system performance looks unacceptable; however, this is a worst-case scenario.
Remember that in this configuration, the test/QA system is running a workload with only slightly
fewer users than that of the production system. It also has only eight disks and is sharing them with
the development system, causing more I/O requests per disk for that disk group and, as expected,
higher latencies in that disk group. However, we have verified that the production system performs
well even with all three systems simultaneously running a heavy load. HP does not recommend that
you run strenuous workloads on your test/QA and development systems during peak hours of use of
the production system. However, by using two disk groups, the environment is fully capable of doing
so. In fact, using two disk groups for this landscape improves production system performance by up
to 40% (13 ms versus 22 ms in a single disk group).
Best practice
Place the SAP production system in its own disk group to prevent any impact from simultaneous workloads generated by the
test/QA or development systems. Doing so can reduce production system latencies by up to 40%.
Further analysis of the EVA finds that its CPU use is approximately 30%, and I/O requests have
begun to queue up on the disks. From this we conclude that the number of spindles is the bottleneck;
therefore, disk latency will decrease and IOPS will increase when drives are added to the EVA.
Best practice
Add disks to the EVA to decrease response times and increase the arrays ability to handle more IOPS.
16
profiles or other configuration files. As explained in Backup/Restore Setup, the Data Protector SAP
backup component is used only when Oracle is the underlying database, so you must use the SQL
Server and file system Data Protector components. For information on deploying and using Data
Protector in this environment, see Appendix B Setting up and using Data Protector 6.0.
Data Protector enables you to create full, differential, or transaction log backups of your SQL Server
databases. Regularly creating full backups is important to any SAP environment and should be
complemented with differential and transaction log backups. After restoring from full or differential
backups, the database is in the same state as at the time of the backup. However, when restoring
from a transaction log backup, Data Protector enables you to choose a very specific point in time
from which to restore data.
Best practice
Use Data Protector to perform periodic full backups and more frequent differential backups, depending on how critical your
SAP environment is to your business. If time-specific restoration capability is necessary, complement full and differential
backups with transaction log backups.
Note
To keep data consistent when performing a SQL Server database restoration, the database cannot be in use by any other
source. Therefore, the SAP system using that database must be shut down before you can restore the data.
Data Protector also enables you to back up entire volumes, folders, or even individual files from a
file system. Likewise, when restoring data to a file system, you can choose to restore individual files,
folders, or entire volumes. This functionality enables you to back up only the critical SAP profile and
configuration files and to save time and tape capacity. Frequent backups of the database is critical.
File system backups are also important, but they do not need to be performed as often because
profile and configuration data does not change as much or as frequently as the data in the database.
Best practice
Keep a full backup of initial SAP profiles and configuration files, using Data Protectors file system backup utility. Maintain
periodic backups of critical SAP files and create a new backup after any major SAP profile or configuration changes.
By creating and scheduling backup jobs (for both the database and file system), you can automate
and simplify your backup procedure.
Best practice
Create a consistent backup schedule and use Data Protectors scheduling utility to manage your backups. Periodically verify
that these scheduled backups are completing successfully and are not hindered by worn-out media or other issues.
Data Protector has several other useful features that make it a powerful utility. These include the
following:
Backup media auto-detection: Data Protector automatically recognizes tape blades and other
backup media.
17
Backup media pooling: If multiple sources of backup media are available (for example, if a
second tape blade were in the enclosure), Data Protector allows you to create pools of media to
increase performance of backup/recovery by writing to several locations simultaneously.
Backup file protection: Data Protector protects backup files until a specified time, preventing you
from accidentally overwriting needed backup data.
Media quality assurance: Data Protector shows the age of backup media (such as a tape
cartridge), its current capacity, and how many times the data has been overwritten. Data
Protector assigns a lower quality value to older media that has been used extensively. When
the media reaches a certain quality threshold, Data Protector stops backups to that media
to prevent data loss.
Figure 10. Data Protector: media capacity
Predefined pre- and post-script execution: During backup setup, you can specify your own scripts
to run immediately before or after a backup.
For more information about features, see Appendix B Setting up and using Data Protector 6.0.
SAP backup/restore testing with Data Protector
Testing SAP backup and recovery with Data Protector is composed of the following steps:
Perform several online SQL backups of each type (full, differential, and transaction log) with
database changes between each backup.
18
Perform several online file system backups of the volumes with the SAP profiles and configuration
files.
Make changes and deletions to the database and file system. In some tests, delete some of the
database data files (after shutting down SAP) and then shut down SAP to verify the ability to
restore both the database and file system files. Then bring SAP back online and verify successful
data restoration.
Note
HP does not recommend deleting data files from your database to test backup/recovery. This is a high-risk activity that was
tested in this project to verify successful data restoration.
Best practice
Periodically restore some test data using Data Protector to verify that no hardware or other issues exist and that your data
restoration process is fully functional.
For steps on how to deploy and use Data Protector in its environment, see Appendix B Setting up
and using Data Protector 6.0.
Monitoring database backup/restore from SAP
SAP provides several tools for SAP and DB administrators. One of these tools is a DBA planning
calendar, from which you can track completed and scheduled tasks. This can greatly aid planning
of the backup strategy. Using the calendar is especially useful if the database administrator and
SAP administrator are different people, and the SAP administrator does not have access to Data
Protector. These tools can be used cooperatively to ensure the system remains sufficiently backed up.
Figure 11 shows the SAP DBA planning calendar.
19
With SAP, you can monitor the completed database backups and restores using transaction DB12.
This transaction provides links for viewing media statistics, such as which tapes are needed for data
restoration. Figure 12 shows SAP backup and restore information.
20
The screen shown in Figure 13 and several other screens with useful statistics and settings can be
accessed through transaction ST04. This transaction provides several valuable links and pieces of
information through the Detail analysis menu and the DB Collector buttons.
21
SAP and Data Protector both provide many details about the backups in your system. For SAP
administrators, especially those without direct access to Data Protector or the database, using these
transactions simplifies tracking database backups.
Best practice
Use SAP transactions DB12, DB13, and ST04 to monitor all backup/restore activity for the database SAP is using.
22
Database administrator
If using a dedicated database server, allocate all available memory except for approximately
2 GB RAM (for the operating system) to SQL Server to provide more capacity in SQL Servers
cache.
Storage administrator
Place the SAP production system in its own disk group to prevent impact from simultaneous
workloads generated by the test/QA or development systems. This configuration can reduce
production system latencies by up to 40%.
Add disks to the EVA to decrease response times and increase the arrays ability to handle
more IOPS.
Use an even number of data files, placing each on its own Vdisk to allow optimal controller
load balancing in the EVA.
23
Create a consistent backup schedule and use Data Protectors scheduling utility to manage your
backups. Periodically verify that these scheduled backups are completing successfully and are not
hindered by worn-out media or other issues.
Periodically restore some test data, using Data Protector, to verify that no hardware or other issues
exist and that your data restoration process is fully functional.
24
Conclusion
The test results and related information in this paper demonstrate how to properly plan for,
successfully deploy, and productively use a fully operational three-tiered SAP NetWeaver landscape
on an HP server/storage infrastructure.
Key planning considerations include the following:
When selecting and configuring the servers, use dedicated blades for each function in the
landscape.
When configuring the disk array, use two disk groups, with the production system in a disk group
with 16 drives, and test and development systems sharing an eight-drive disk group. This provides
up to a 40% improvement in production system response time.
Increasing the workloads in SAP systems tends to cause high disk queue depths and latencies.
The best practice is to increase the number of spindles by adding disks to the array to increase
overall IOPS and decrease response times.
When deploying HP Data Protector, acquire the latest patches, determine the best system to be
the cell manager, and perform the installation.
Key software tuning considerations include the following:
Tune the SAP buffers until no swaps (that is, no paging to disks) are observed.
Configure the appropriate number of SAP work processes. Testing confirmed earlier results that
using a ratio for SAP work processes to CPU cores of 5:1 is optimal.
Configure the dedicated database server. Some memory might not be used unless specifically
allocated for SQL Server. To efficiently use memory in a dedicated database server, adjust the
memory given to the database to consume available memory (memory not needed for the OS).
This allows SQL Server to cache more data and spend less time going to the disk.
Key operating considerations include the following:
When using Data Protector for backup of MS SQL data in SAP environments, the database and
file system are backed up separately.
While it is both possible and a best practice to back up while running, SAP must be shut down
when restoring data to ensure integrity of the restored data.
Key backup considerations include the following:
Use a variety of database and file system backups to ensure your data is secure.
Maintain a consistent backup schedule with Data Protector to minimize potential impact to the
environment in case of data loss.
Periodically restore test data to verify that data restoration is functioning as expected.
A good understanding of these major considerations and the procedures associated with them are
key to successfully deploying and operating a three-tiered SAP NetWeaver landscape using HP
servers, storage, and enterprise management. The test-proven techniques developed here serve as a
complete guide that can be used with confidence to ensure success.
25
26
Quantity
Part Number
Description
437507-B21
447707-B21
416660-L21
416660-B21
397415-B21
447711-B21
10
418367-B21
406770-B21
403621-B21
351580-B21
440947-B21
410917-B21
AE371A
448589-B21
AG637A
AG638A
24
AG556A
B6961AA
EVA 4400
Applications
1
27
28
6. Download and install on Cell Manager all necessary Data Protector patches from
the patch download site at http://h20000.www2.hp.com/bizsupport/TechSupport/
DriverDownload.jsp?prodNameId=3241177&lang=en&cc=us&taskId=135&prodClassId=
1&prodTypeId=18964&prodSeriesId=3241176.
7. Start the Data Protector GUI.
Adding clients
1. Select Add New Clients from the pop-up window.
2. Right-click Clients in the scoping pane (the tree menu on the left part of the window), and select
Add Clients. Figure 16 shows how to add clients.
29
3. Browse to each of the servers you need, including the virtual name for the SQL Server (not just
the physical box that it is on) and click Add. When added, the servers are listed under Client
Systems. Figure 17 shows how to add servers.
30
4. Click Next and select the components to be installed on all of your servers, or click I want to
customize these options for client systems independently (below the component list). Figure 18
shows how to customize client systems. Figure 19 shows how to install specific components
on each server.
31
32
HP customizes components for each server. Table 4 shows the installed modules. If you
choose to customize servers, keep the following information in mind:
The modules specific to SAP integration are not used for MS SQL Server, so do not
include those.
Table 4. Modules installed
Installed modules
Functions
Location
Disk Agent
Every server
Media Agent
User interface
MS SQL 7.0/2000
Integration
Adding devices
1. Select Devices & Media from the context list.
2. In the scoping pane, under Environment, right-click Devices and select Autoconfigure Devices.
Figure 21 shows how to set automatic configuring of devices and media.
33
34
35
36
2.
3.
Select the backup device, make sure Load Balancing is not selected, and click Properties.
If you have only one backup device, load balancing will have no effect regardless of the
selection.
For a small SAP landscape similar to that used in this project, HP does not recommend
using load balancing unless you are using multiple device streaming. This is because you
may wish to explicitly select where backup objects are stored, and because you will likely
be backing up only a few items.
For more information about device lists and load balancing, see the HP OpenView Storage
Data Protector Concepts Guide at http://bizsupport.austin.hp.com/bc/docs/support/
SupportManual/c00751562/c00751562.pdf.
37
4. From the Device Properties window, select the media pool you wish to use and click OK.
5. Click Next, set any other optional changes, and then click Next. (Default settings were used
in testing.)
6. Set up a schedule (optional) and click Next to save the template.
7. Create a backup specification by expanding Backup Specification. Figure 26 shows how to
select databases.
8. Right-click MS SQL Server and select Add Backup.
9. Select the backup template you just created.
10. Select Local or network backup, clear Load balanced, and click OK.
11. Under the Application section, and from the Client menu, select the name of the SQL Server (not
the physical server that the database resides on, but the name of the virtual server managing
your database). Click Next to continue.
12. If an authentication window pops up, use Integrated Security if using a domain account with
access to the database, or select Standard Security to use a database user.
13. Select the databases you wish to back up, and then click Next.
38
14. Make selections on subsequent screens, as you did when setting up the template.
15. Save the backup specification. You are now ready to back up your database.
16. Right-click the backup you just created in the scoping pane, and click Start Backup.
17. Select the backup type to create and click OK.
Note
Differential and transaction log backups are an option only if a full backup already exists.
39
5. Select the backup version you wish to restore from and click OK. If you select a transaction
log backup, you can restore to a specific point in time. Figure 28 shows where to select a
backup version.
40
41
10. Select what to back up and then click Next. You can select volumes, folders, and files.
11. Select the appropriate backup device and media pool, and then click Next.
12. Continue clicking Next to use default settings and save the backup.
13. In the scoping pane, expand Filesystem and select the backup specification you created to make
changes, or right-click the backup and select Start Backup.
14. Select the backup type and start the backup.
Note
A full backup must exist before incremental backups can be created.
42
5.
Select the file system backup version to restore and click OK.
6.
Click Restore.
43
44