Tunning SQL HP

44
Best practices for deploying an SAP landscape using the c3000 Blade Enclosure and the EVA4400 (Windows/MS-SQL) Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Solution configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Overall solution configuration . . . . . . . . . . . . . . . . . . . . . . 4 Blade enclosure configuration . . . . . . . . . . . . . . . . . . . . . 5 SAP production system application server . . . . . . . . . . . . . . . 5 SAP production system database server . . . . . . . . . . . . . . . 5 SAP test/QA system server . . . . . . . . . . . . . . . . . . . . . 5 SAP development system server . . . . . . . . . . . . . . . . . . . 6 Management server . . . . . . . . . . . . . . . . . . . . . . . . 6 Active Directory domain controller and load generator (optional) . . . . 6 Storage configuration . . . . . . . . . . . . . . . . . . . . . . . . . 6 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Test objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Test setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Performance testing setup—User load . . . . . . . . . . . . . . . . 9 Performance testing setup—Active data sizes . . . . . . . . . . . . . 9 Backup/restore setup . . . . . . . . . . . . . . . . . . . . . . . 10 Test results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 SAP system tuning . . . . . . . . . . . . . . . . . . . . . . . . 10 SQL memory tuning . . . . . . . . . . . . . . . . . . . . . . . . 13 Server performance . . . . . . . . . . . . . . . . . . . . . . . . 14 Storage results . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Data protector functionality . . . . . . . . . . . . . . . . . . . . . 16 SAP backup/restore testing with Data Protector . . . . . . . . . . . . 18 Monitoring database backup/restore from SAP . . . . . . . . . . . . 19 Best practices and results . . . . . . . . . . . . . . . . . . . . . . . . . 23 SAP administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Database administrator . . . . . . . . . . . . . . . . . . . . . . . . 23 Storage administrator . . . . . . . . . . . . . . . . . . . . . . . . . 23 Backup/recovery (Data Protector) administrator . . . . . . . . . . . . . . 23 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 We value your feedback . . . . . . . . . . . . . . . . . . . . . . . . 26 Appendix A Bill of Materials . . . . . . . . . . . . . . . . . . . . . . . . 27 Appendix B Setting up and using Data Protector 6.0 . . . . . . . . . . . . . . 28 Data Protector installation . . . . . . . . . . . . . . . . . . . . . . . 28 Adding clients . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Adding devices . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Set up and use SQL Server backup . . . . . . . . . . . . . . . . . 37 Restore SQL Server . . . . . . . . . . . . . . . . . . . . . . . . 39

Transcript of Tunning SQL HP

Page 1: Tunning SQL HP

Best practices for deploying an SAP landscape using the c3000 Blade Enclosure and the EVA4400 (Windows/MS-SQL)

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Solution configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Overall solution configuration . . . . . . . . . . . . . . . . . . . . . . 4 Blade enclosure configuration . . . . . . . . . . . . . . . . . . . . . 5

SAP production system application server . . . . . . . . . . . . . . . 5 SAP production system database server . . . . . . . . . . . . . . . 5 SAP test/QA system server . . . . . . . . . . . . . . . . . . . . . 5 SAP development system server . . . . . . . . . . . . . . . . . . . 6 Management server . . . . . . . . . . . . . . . . . . . . . . . . 6 Active Directory domain controller and load generator (optional) . . . . 6

Storage configuration . . . . . . . . . . . . . . . . . . . . . . . . . 6 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Test objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Test setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Performance testing setup—User load . . . . . . . . . . . . . . . . 9 Performance testing setup—Active data sizes . . . . . . . . . . . . . 9 Backup/restore setup . . . . . . . . . . . . . . . . . . . . . . . 10

Test results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 SAP system tuning . . . . . . . . . . . . . . . . . . . . . . . . 10 SQL memory tuning . . . . . . . . . . . . . . . . . . . . . . . . 13 Server performance . . . . . . . . . . . . . . . . . . . . . . . . 14 Storage results . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Data protector functionality . . . . . . . . . . . . . . . . . . . . . 16 SAP backup/restore testing with Data Protector . . . . . . . . . . . . 18 Monitoring database backup/restore from SAP . . . . . . . . . . . . 19

Best practices and results . . . . . . . . . . . . . . . . . . . . . . . . . 23 SAP administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Database administrator . . . . . . . . . . . . . . . . . . . . . . . . 23 Storage administrator . . . . . . . . . . . . . . . . . . . . . . . . . 23 Backup/recovery (Data Protector) administrator . . . . . . . . . . . . . . 23

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 We value your feedback . . . . . . . . . . . . . . . . . . . . . . . . 26

Appendix A Bill of Materials . . . . . . . . . . . . . . . . . . . . . . . . 27 Appendix B Setting up and using Data Protector 6.0 . . . . . . . . . . . . . . 28

Data Protector installation . . . . . . . . . . . . . . . . . . . . . . . 28 Adding clients . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Adding devices . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Set up and use SQL Server backup . . . . . . . . . . . . . . . . . 37 Restore SQL Server . . . . . . . . . . . . . . . . . . . . . . . . 39

Page 2: Tunning SQL HP

Set up and use file system backup . . . . . . . . . . . . . . . . . . 41 Restore the file system . . . . . . . . . . . . . . . . . . . . . . . 42

For more information . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 CFT SAP best practices white papers . . . . . . . . . . . . . . . . . . 44 Data Protector information . . . . . . . . . . . . . . . . . . . . . . . 44 HP solutions and training . . . . . . . . . . . . . . . . . . . . . . . 44

Page 3: Tunning SQL HP

Overview

Small-to-medium businesses (SMBs)—companies with 100–499 employees—are 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:

– Data file placement onto the EVA virtual disks (Vdisks)

– 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

– Choosing the appropriate number of disks

• Best practices for tuning the overall environment

• Best practices for backing up and restoring critical SAP data

3

Page 4: Tunning SQL HP

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.

Figure 1. Solution 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.

4

Page 5: Tunning SQL HP

Figure 2. SAP landscape in a 14U rack

Blade enclosure configuration

The blade system includes a total of six BL460c servers. One is optional for this SAP landscape, serving only as the Active Directory domain controller and a load generator for testing.

For the SAP production system, the configuration uses the Microsoft cluster service (MSCS) with two

server nodes to provide increased server availability. The test/QA, development, and management systems each run on individual servers.

Each server has two Intel® Xeon® 5160 3-GHz dual-core processors and has the following

specifications:

SAP production system application server

• 16 GB RAM

• SAP Central Instance (dedicated application server, except in the case of node failover)

• Node 1 of 2-node MSCS cluster

SAP production system database server

• 16 GB RAM

• MS SQL Server (dedicated database server, except in the case of node failover)

• Node 2 of 2-node MSCS cluster

SAP test/QA system server

• 16 GB RAM

• Test system’s Central Instance and database server

5

Page 6: Tunning SQL HP

SAP development system server

• 8 GB RAM

• Development system’s Central Instance and database server

Management server

• 8 GB RAM

• SAP Solution Manager 7.0

• Command View EVA 8.0

• Data Protector 6.00 Cell Manager

Active Directory domain controller and load generator (optional)

• 8 GB RAM

• Active Directory domain controller, dynamic host configuration protocol (DHCP), and domain

name server (DNS)

• Load generation

The enclosure has an Ultrium 448c tape blade for backup. One to two free bays remain available

for future growth (depending on whether the optional sixth server is used). Figure 3 shows the

blade system layout in the enclosure.

Figure 3. Blade enclosure setup

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:

6

Page 7: Tunning SQL HP

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

Figure 4. Array configuration

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.

7

Page 8: Tunning SQL HP

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 BL460c with 2 dual-core CPUs, 16 GB RAM SAP production system central instance server

BL460c with 2 dual-core CPUs, 16 GB RAM SAP production system database server

BL460c with 2 dual-core CPUs, 16 GB RAM SAP test/QA system server

BL460c with 2 dual-core CPUs, 8 GB RAM SAP development system server

BL460c with 2 dual-core CPUs, 8 GB RAM Management server (SAP Solution Manager 7.0, Command View EVA 8.0, Data Protector 6.00 Cell Manager)

BL460c with 2 dual-core CPUs, 8 GB RAM

(optional) Active Directory domain controller (also running

DHCP and DNS as needed)

Tape blade HP Ultrium 448c tape blade Backup hardware

HBAs HP BLc Emulex LPe1105 4 GB FC (5) 1 HBA per server

Switches GbE2c Ethernet Blade switch (2)

Brocade 4/24 SAN switch (2)

Gigabit Ethernet switch

Fibre channel switch

EVA EVA 4400 2C2D with 24 146 GB 15 K RPM

Fibre Channel drives Backend storage

Software HP OpenView Data Protector Start Pack for Windows

Backup/recovery application

8

Page 9: Tunning SQL HP

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 setup—User 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 200 users (80% of production system load)

Development system 100 users (40% of production system load)

Total 550 simultaneous users running in the SAP landscape for each test

Performance testing setup—Active data sizes

When analyzing performance data, keep the amount of data in the database in mind. The more

data, the more total distance the drive heads may be required to move when retrieving and writing

data to the disk, which means greater disk latency.

9

Page 10: Tunning SQL HP

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

Small data set Production system 40 GB (per data file) x 2 data files =

80 GB

Note

This simulates a production system database with a 250 GB capacity that is 30% full.

150 GB

Test/QA system 20 GB x 2 data files = 40 GB

Development system 15 GB x 2 data files = 30 GB

Large data set Production system 95 GB x 2 data files = 190 GB

Note

This simulates a production system database with a 250 GB capacity that is 75% full.

350 GB

Test/QA system 50 GB x 2 data files = 100 GB

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

Page 11: Tunning SQL HP

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

Page 12: Tunning SQL HP

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.

Figure 5. SAP page swapping

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

Page 13: Tunning SQL HP

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.

SQL memory tuning

Testing reveals that the dedicated database server for the production system uses less than half of the memory available on that Windows server. This reduction is caused by default settings of that SQL Server and limits the amount of data SQL Server can cache.

To adjust the memory allocated to SQL Server use the following steps:

1. Start the SQL Server Management Studio and connect to the database.

2. Right-click the name of the SQL Server and select Properties. Figure 6 shows the SQL Server properties.

Figure 6. SQL Server Management Studio: SQL Server properties

3. In the Server Properties window, select Memory.

4. Adjust the Minimum server and Maximum server memory values according to your system’s available memory. Figure 7 shows the SQL Server memory settings.

13

Page 14: Tunning SQL HP

Figure 7. Modifying SQL Server memory

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 Server’s 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

Page 15: Tunning SQL HP

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

Page 16: Tunning SQL HP

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 array’s ability to handle more IOPS.

Data protector functionality

Keeping frequent backups of an SAP system is critical to maintaining the landscape. To back up

your SAP system, back up both the full database and critical parts of the file system, such as the SAP

16

Page 17: Tunning SQL HP

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 Protector’s 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 Protector’s 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

Page 18: Tunning SQL HP

• 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

Page 19: Tunning SQL HP

• 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

Page 20: Tunning SQL HP

Figure 11. SAP DBA planning calendar (transaction DB13)

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

Page 21: Tunning SQL HP

Figure 12. SAP backup and restore information (transaction DB12)

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

Page 22: Tunning SQL HP

Figure 13. SAP database performance analyzer (transaction ST04)

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

Page 23: Tunning SQL HP

Best practices and results

SAP administrator

• To eliminate SAP swaps, use suggestions for the memory buffer tuning cited 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.

• For increased system performance, tune the number of SAP work processes to five per CPU core, as explained 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.

• Use SAP transactions DB12, DB13, and ST04 to monitor all backup/restore activity for the

database SAP is using.

• Be sure to monitor core zero on application servers. Saturating core zero will greatly increase

response times in the system.

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 Server’s 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 array’s 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.

Backup/recovery (Data Protector) administrator

• Use Data Protector to perform periodic full backups and more frequent differential backups, depending 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.

• Keep a full backup of initial SAP profiles and configuration files, using Data Protector’s file system

backup utility. Maintain periodic backups of critical SAP files and create a new backup after any

major SAP profile or configuration changes.

23

Page 24: Tunning SQL HP

• Create a consistent backup schedule and use Data Protector’s 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

Page 25: Tunning SQL HP

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

Page 27: Tunning SQL HP

Appendix A Bill of MaterialsQuantity Part Number Description

c3000 Blade Enclosure

1 437507-B21 HP BLc3000 CTO Enclosure

5 447707-B21 HP BL460c G1 Dvlss CTO Blade

5 416660-L21 HP X5160 BL460c G1 FIO Kit

5 416660-B21 HP X5160 BL460c/xw460c G1 Kit

8 397415-B21 HP 8GB FBD PC2-5300 2x4GB Kit

5 447711-B21 HP HDD Bkpln BL460c FIO Kit

10 418367-B21 HP 146GB 10K SAS 2.5 DP HDD

5 406770-B21 HP BLc NC373m Mfn Gigabit Svr Adapter

5 403621-B21 HP BLc Emulex LPe1105 FC HBA Opt Kit

5 351580-B21 HP SA 641/642/E200 128MB BBWC Kit

2 440947-B21 HP Ultrium 448c Tape Blade

2 410917-B21 HP BLc Bnt 1GbE2 Switch Opt Kit

2 AE371A Brocade BladeSystem 4/24 SAN Swt Powr Pk

1 448589-B21 HP BLc3000 FIO Onboard Admin Option

EVA 4400

1 AG637A HP EVA4400 Dual Controller Enclosure

4 AG638A HP M6412 Fibre Channel Drive Enclosure

24 AG556A HP 146GB 15K FC EVA M6412 Enc HDD

Applications

1 B6961AA HP OpenView Data Protector Start Pack for Windows

27

Page 28: Tunning SQL HP

Appendix B Setting up and using Data Protector 6.0

This section details how to configure and use Data Protector.

Data Protector installation

1. On the Cell Manager server, start the Data Protector installation and accept the license

agreement.

2. Select Cell Manager as the Installation type. Figure 14 shows the installation type.

Figure 14. Data Protector installation type

3. Enter the appropriate username and password.

4. Select the installation path.

5. Select the components you want to install on the Cell Manager and click Next. For testing, we

use the default settings. Figure 15 shows the component selection screen.

28

Page 29: Tunning SQL HP

Figure 15. Data Protector Cell Manager component installation

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

Page 30: Tunning SQL HP

Figure 16. Adding clients

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

Page 31: Tunning SQL HP

Figure 17. Added servers

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

Page 32: Tunning SQL HP

Figure 18. Customize options for client systems

Figure 19. Adding server components

32

Page 33: Tunning SQL HP

• 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 For each system involved in data backup Every server

Media Agent For the server in the same enclosure

quadrant as the tape blade or that is connected to other necessary backup

media

Management server, because it is in the

same quadrant as the tape blade

User interface For the server used for managing Data

Protector Management server with Solution Manager, Command View, and Data Protector Cell Manager

MS SQL 7.0/2000

Integration

For all servers acting as SQL clients or

servers Both servers in the production system and

the test/QA and development servers

Figure 20 lists the Data Protector server components.

Figure 20. Data Protector server components

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

Page 34: Tunning SQL HP

Figure 21. Automatically configuring devices and media

3. Select the client server with access to the backup device.

4. Select the device found (in this case, HP:Ultrium 2-SCSI) and click Finish. Figure 22 shows how to add devices.

34

Page 35: Tunning SQL HP

Figure 22. Adding devices

5. Expand Media in the scoping pane.

6. If the devices do not appear, right-click Pools and select Add Media Pool.

7. Provide a pool name, select the media type (we selected LTO-Ultrium), and finish creating

the pool.

8. Right-click on the media pool you created and select Format. Figure 23 shows how to format media.

35

Page 36: Tunning SQL HP

Figure 23. Formatting media

9. Select the device to format and click Next.

10. Provide a name for the media and click Next.

11. If the media has been used before, you may need to click the Force operation check box. Click Finish. Figure 24 shows where to select Force operation.

36

Page 37: Tunning SQL HP

Figure 24. Force operation

Your system is now ready to create backups.

Set up and use SQL Server backup

1. Select Backup from the context list.

2. Expand Templates, right-click MS SQL Server, and select Add Template.

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

Page 38: Tunning SQL HP

Figure 25. Creating a backup template

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

Page 39: Tunning SQL HP

Figure 26. Selecting databases to back up

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.

Restore SQL Server

Note

To maintain data consistency in the database, SQL Server requires that there be no active connections to the database. Therefore, before restoring your data, you must shut down all SAP instances with connections to that database.

1. Select Restore from the context list.

2. Expand the MS SQL Server list to display the backed-up databases.

3. Select the components to restore. For simple SAP system restorations, select only your primary

system database. Figure 27 shows where to select components to restore.

4. Right-click the name of the database and click Properties.

39

Page 40: Tunning SQL HP

Figure 27. Restoring SQL database files

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

Page 41: Tunning SQL HP

Figure 28. Selecting a backup version

6. Click Restore to start restoring your database.

Set up and use file system backup

1. Select Backup from the context list and expand Templates. Figure 29 shows where to select the file system backup file.

2. Right-click Filesystem and select Add Template.

3. Select the backup device, clear Load balancing, and click Properties.

4. Select the media pool to use and click OK.

5. Click Next and give the backup a description.

6. Select the protection level, apply a filter (optional), and then click Next.

7. Set up a schedule if necessary, and save the template.

8. Expand Backup Specifications, right-click Filesystem, and click Add Backup.

9. Select the template you created, clear Load Balanced, and then click OK.

41

Page 42: Tunning SQL HP

10. Select what to back up and then click Next. You can select volumes, folders, and files.

Figure 29. File system backup file selection

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.

Restore the file system

1. Select Restore from the context list. Figure 30 shows the file system restore feature.

2. Expand Backup Specifications and Filesystem.

3. Select the backup specification from the scoping pane, and then select the volumes, folders, or files you wish to restore.

4. Right click a volume and select Restore Version.

42

Page 43: Tunning SQL HP

Figure 30. File system restore

5. Select the file system backup version to restore and click OK.

6. Click Restore.

43

Page 44: Tunning SQL HP

For more information

CFT SAP best practices white papers • Best practices for SAP ERP using HP Blade System c-Class blades

http://h71028.www7.hp.com/ERC/downloads/4AA1-5661ENW.pdf

• Best practices for configuring and deploying SAP ERP using HP ProLiant servers, HP StorageWorks 8000 Enterprise Virtual Array, Windows Server, and Microsoft SQL Server

http://h71028.www7.hp.com/ERC/downloads/4AA1-5523ENW.pdf

Data Protector information

• Patch download site

http://h20000.www2.hp.com/bizsupport/TechSupport/DriverDownload.jsp?prod

NameId=3241177&lang=en&cc=us&taskId=135&prodClassId=-1&prodTypeId=18964&prod

SeriesId=3241176

• Data protector manuals/guides site

http://h20000.www2.hp.com/bizsupport/TechSupport/DocumentIndex.jsp?contentType=Sup

portManual&lang=en&cc=us&docIndexId=64179&taskId=135&prodTypeId=18964&prod

SeriesId=3241176

• HP OpenView Storage Data Protector Concepts Guide

http://bizsupport.austin.hp.com/bc/docs/support/SupportManual/c00751562/

c00751562.pdf

HP solutions and training

• Customer Focused Testing solutions

http://www.hp.com/go/hpcft

©2008 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. 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. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. SAP, SAP NetWeaver, SAP Solution Manager, SAP ERP, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. Microsoft and Windows are U.S. registered trademark of Microsoft Corporation. Intel and Intel Xeon are trademarks of Intel Corporation in the U.S. and other countries. 4AA1-7725ENW, October 2008

44