SAP BPC 10 NW MEGA ELITE ENABLEMENT

Server Performance Tuning and Analysis

Exercise 3 Pre-Req – Establish Performance Benchmarks and Baselines
Exercise 3 Part I – Check the OS Configuration
Exercise 3 Part II – Check the DB Configuration
Exercise 3 Part III – Check the ABAP Application Server Configuration
Exercise 3 Part IV – Check the BPC Application Configuration
Exercise 3 Post Config – Validate Results against Benchmarks and
Baselines
Overview of the Business Case
The Business has been experiencing performance problems with normal business operations like optimizing a cube,
running an report, writing data, and data manager execution. During your analysis you have determined that the cause
is due to the general system health and that a tuning exercise must be accomplished. The Database itself must be
tuned as well as the BW Application Server which BPC has been installed on.

This exercise will teach you how to perform simple checks on a BPC Installation that is running on NW 7.3, SP4. The
BPC version is 10, SP4. The Operating system we will be using is Microsoft Windows Server 2008 R2, Datacenter x64
Edition, with Service Pack 1 installed. The Database we will be using is Microsoft SQL Server 2008 R2.

You should already have a basic understanding of the following concepts:

BW Basis Administration
DB Administration
BPC Installation and Administration
Memory Tuning Concepts
Client/Server Architecture

You will be analyzing various configuration settings of the overall system architecture which are commonly used to
impact and acheive better performance. The exercise will focus on the following main areas:

Checking the Operating System

Checking the Database Server
Checking the SAP NetWeaver (ABAP) Application Server
Checking BPC specific Load Balancing Parameters

IMPORTANT NOTES: This exercise is built mainly for you to check and acheive a "diagnostic reference" for
further discussion and action. For example: We will mention BPC Load Balancing, however we do not provide a
distributed landscape to see the effects of these settings. We will show you where you would change these properties
but because the landscape itself is not built on multiple distributed instances their settings would not have an effect on
this particular system.

DISCLAIMER: For the sake of time, we have already prepared the systems you will use in this class to perform
reasonably well. Please be advised that this exercise is only intended to provide you with a system to learn various
generic concepts of general tuning for a BPC NetWeaver installation. Individual results will always vary based on a
wide array of potential impacts. While the areas discussed here are all related to acheiving optimal performance this
exercise is in no way intended to cover every possible performance tuning scenario.

2
Pre-Req – Establish Performance Benchmarks and
Baselines
This section simply informs you to first establish benchmarks to compare against after you made any changes
to system configuration. This will greatly help and facilitate the project team in evaluating the results of their
tuning and configuration. It is imperative that the Business plans for heavy End User testing not only for
Business Functionality but for Technical Reliability and Scalability as well. Use of a Third Party Tool for
concurrency and load simulation (such as HP LoadRunner) is undoubtedly a great way to achieve these
benchmarks and baselines; however the set up of such tests and activities can no doubt be very complex and
difficult depending on the use case. As always, it is important for the business to properly schedule sufficient
project windows in which they can allow a team to perform a full blown analysis of their systems and
implementation. To aid in this activity, SAP offers several services which can be utilized such as Early Watch
and Go Live Checks that check many of these settings automatically and with greater detail.

Please note that the intention of this exercise as a whole is to provide you with a very basic understanding of
the different areas of performance tuning and configuration so that you can be more prepared to identifying
and resolving potential issues when they arise. We do not ask you to perform all of the individual tasks during
the class but simply to note the importance of these activities in a real world scenario.

To get a good understanding of where performance benefits can be made you should first establish as many different
types of benchmarks as possible relating to the activities that a Business User would perform. Here are some
examples of areas you should be sure to establish benchmarks on:

-Importing data to a BPC Environment/Model

-Running BPC Business Rules and Logic
-Running a simple EPM Report of baseline data
-Running a complex EPM Report with built in business functions (such as Default Logic, Hierarchy Logic, Excel
Macros,
-Optimization of a BPC Environment/Model
-Performing a full End to End test with multiple actions from the Front End

3
Part I – Check the Operating System Configuration
This exercise will show you how to evaluate some basic Operating System Settings related to performance.
We are using Microsoft Windows Server 2008 R2, Datacenter x64 Edition, with Service Pack 1 installed.
Microsoft makes many of these settings quite easy with generalized configuration. Other operating systems
(such as Linux, AIX, etc) will require different configuration but in general the topics discussed here should
follow the same line of thought.

NOTE: You can find additional information on these settings in the following MSDN how to guide:
http://support.microsoft.com/kb/308417 (the article is for Windows XP but it still applies)

1. Check the general performance options. In the Start menu, Right-Click on “Computer” and select Properties:

2. Click on “Advanced System Settings”:

4
 3. In the “System Properties” window, click on the Performance “Settings” button as follows:

4. Under the "Visual Effects" tab, click on the "Adjust for best performance" radio button. This option limits the
amount of graphics processing used on the server (generally, back-end servers do not need powerful graphics
processing):

5
 5. Under the "Advanced" tab, make sure you have selected the performance for Background Services as shown in
the screenshot. In general, server operating systems are configured to allow for better background processing
and system caching. The reason is that most of the Application processing that happens on the server level is
done with background jobs and heavy system cache usage. In addition, you would not normally have users
logging onto the server to perform end user OS level tasks (follows the common Client/Server architecture):

6. Check the Virtual Memory (paging file). While still on the "Advanced" tab click the "Change" button:

6
 7. This step shows you where you can configure Virtual Memory (paging file). Notice that you can set up different
amounts of Virtual Memory (page files) for each Hard Drive that is mounted on your Server. The recommended
size for Virtual Memory on an SAP ABAP Application Server will inevitably depend on the amount of RAM the
server has. In the past, when RAM was limited (due to 32bit architecture and hardware limitations), SAP
recommended 2x (Two times) and sometimes even 3x the amount of RAM available on the Server. In today’s
world we have much more RAM available (due to 64bit architecture and major hardware advances) so we don’t
actually need as much Virtual Memory. The Servers you are using in this class are virtualized in the Cloud
environment, and have been allocated 17.5GB of RAM. You can see that we have already configured at least 2x
the amount of RAM for our paging file on the C: Drive (even though this much Virtual Memory is typically not
needed).

You can actually get away with less Virtual Memory than what we have configured here (most 64bit SAP
Systems can start up and run with a 20GB Page File), but the size of your Page File will depend on how much
RAM you have available and how much RAM your Application Server consumes. As a very simple reference, if
your Application Server logs show a large amount of Swapping over time then you would probably need to
increase the amount of Physical RAM it was using. If you run out of Physical RAM to use and you are still
Swapping heavily, then you might need a server with more Physical RAM or you might need to configure the
Application in such a way that it uses less. We will expand upon some of the concepts of configuring memory
settings for our ABAP Application Server in Part III of this exercise.

st
Set the C: Drive to “System managed size” (1 screenshot) and click on the “Set” button. Next, click on the D:
nd
Drive and set it to a Custom size of 35GB (2 screenshot). The S: Drive (where the SAP Application Server has
been installed) shouldn’t have a Paging File because we want all Hard Drive activity on that Drive to be
dedicated to the Application Server and not have to deal with the additional paging overhead.
When you are done setting the new Virtual Memory paging file configuration, click “OK”.

1st Screenshot 2nd Screenshot:

NOTE: The Back End Server should always have a dedicated Hard Drive for the Paging File for performance
reasons. In this exercise we are using the D: Drive which has been virtually provided to us through the Cloud
Instance configuration. Please review the article mentioned at the beginning of Part I for additional information
about paging file configuration within Windows.

7
 8. After clicking the “OK” button in the Virtual Memory pop-up window, the system will prompt you that it needs to
restart before the changes can take effect. This is fine, but we will restart later at the end of Part I.

9. After clicking through the restart warning, go to the "Data Execution Prevention" tab and ensure your screen
looks like the following screenshot. In this server, we have turned DEP off permanently (this is done with a
parameter at the boot level (see wiki article below for more details). DEP can impact performance, and while it
might be necessary for certain landscape security protocols, we don’t want it to interfere with our performance.
After reviewing this setting, click the “OK” button.

NOTE: This setting will vary depending on the Business Security requirement. The idea here is that if this server
is only dedicated to running SAP we can assume there is no malicious software, however different Businesses
have different Security policies.

For additional information about DEP, please refer to the following wiki site:
http://en.wikipedia.org/wiki/Data_Execution_Prevention

8
10. After clicking “OK” on the “Performance Options” window, the system will remind you that it needs to restart to
make the changes effective. Click on “Restart Later” – we will restart the server at the end of Part I:

11. In this next step, we will check to see if the Hard Drive where the SAP Application Server lives needs to be
defragmented. Go to “All Programs->Accessories->System Tools->Disk Defragmenter” as shown in the two
screenshots below:

9
12. Select the S: Drive and click on “Analyze disk” (DO NOT click on “Defragment disk”):

Analyzing the disk should only take a few minutes. When it is done you should see how much of the drive is
fragmented. In a real world scenario you want to keep the fragmentation to a minimum since fragmented disks
tend to work much harder than defragmented disks. Fragmentation can potentially impact file system I/O, so it is
important to keep it in mind when tuning.

NOTE: Do not attempt to Defragment the disk during class, as this step will take a long time and is
resource intensive.

For additional information about Fragmentation, please refer to the following wiki site:
http://en.wikipedia.org/wiki/File_system_fragmentation

10
13. If you have changed any of the settings in Part I, you should restart the server (NOTE: make sure you have
correctly shutdown the SAP Application Server before a System Restart):

11
Part II – Check the Database Configuration
This exercise will show you how to evaluate basic Database configuration. We are using Microsoft SQL Server
2008 R2. Other Database systems (such as Oracle, DB2, SAPDB, etc) will require different methods of
configuration but the general concepts should remain the same.

Tuning a Database can be a very complex and involved project, so for the sake of time we will only focus on a few
areas:

-Check the Database Cache Size

-Check the Database Parameters
-Check the Database Table Spaces

NOTE: You can find additional information about tuning Microsoft SQL Server for SAP with the following whitepaper on
SDN: SAP with Microsoft SQL Server 2008 and SQL Server 2005: Best Practices for High Availability, Maximum
Performance, and Scalability - Part I: SAP Architecture and SQL Server Basic Configurations, Features Used, and
Windows Configurations

1. Open up the SQL Server Management Studio tool by going to “All Programs->Microsoft SQL Server 2008 R2-
>SQL Server Management Studio” as shown in the two screenshots below:

2. When SQL Server Management Studio starts up, keep the default values and click "Connect" as shown below:

12
 3. Expand the Databases folder (underneath the Top Node) and notice that we have several different databases
within this Database Server. You can see that we have Databases for CSA (Our ABAP Application Server
where BPC 10 is installed), FIM (Financial Information Management), IC (InterCompany), and Disclosure
Management, to name a few.

4. In addition to the Databases we have installed for this training, there are some default system databases used
for normal operation and configuration. Of particular importance is the “tempdb” database, which SQL Server
uses to store temporal joins and other structures which are needed when accessing your particular Database.
Note that SAP BW Systems require a much larger TEMPDB database than standard R/3 systems.

For more information about TEMPDB and SAP BW, see the following:
SAP Note 1174635 - TempDB sizing in SAP BW systems on Microsoft SQL Server.

13
 5. Right-click on the Database Server itself (Top Node) and select “Properties”:

6. In Microsoft SQL Server, this is where you can manage the Database Server properties. These properties are
global to all Databases within this Database Server (we will look at the individual CSA Database configuration
later in this section). In the next few steps, we will be checking the global Database Server Cache in addition to
a few other properties specific to this Database Server:

NOTE: During this class we will only be looking at these properties to gain a better understanding of how you
can configure the Database Server itself. Remember that in any real world scenario, Database tuning and
configuration can become quite detailed and specific to the actions you are performing with the Application that
is using that Database. It is highly recommended to involve a Database Expert who is knowledgeable with how
the SAP Application Server interacts with the Database. As a simple example, ERP based systems and BW
based systems each use the Database in a different way, and may require different technical settings and
configuration.

14
 7. Click on the “Memory” category. A properly tuned landscape should always try to stay within the limits of the
Resources it has access to. Notice here we have chosen to configure the Database Server Memory to be 7GB
minimum and 10GB maximum. This means that when the Database Server starts it will immediately reserve
7GB and set a limit to the amount it can grow to 10GB. Since we have installed the Database Server and the
SAP Application Server on the same instance they must share the overall physical memory that has been
allocated to the server. In our case, the servers we are using have been allocated a grand total of 17.5GB of
RAM from the Cloud Infrastructure.

It is important to note that when we add the Database Server memory and the SAP Application Server memory
usage together, the sum should not go over the total RAM allocated for the computer. Keep in mind that you
also need an additional 1-2GB for the Operating System itself.

The following simple relationship can help us estimate for Memory Consumption at maximum resource usage:
DB Memory + AppServer Memory + OS Memory Total RAM for the Server.
In our case:
DB Memory is Set to 7GB (Max 10GB)
SAP Application Server Memory is Set to Max 10GB (We will cover this in the next section)
OS Memory use can be estimated around 1-2GB (Depending on the Operating System)

NOTE: This Database is configured with a maximum size of more than half of the available RAM. In addition,
the SAP Application Server is configured with a maximum size of more than half of the available RAM. During a
maximum resource usage scenario the system could potentially run out of RAM and start swapping heavily with
Virtual Memory and Hard Disk reads. This is a special case when all server resources are being heavily used
and the system performance would degrade considerably. It could happen under very high user concurrency
combined with many simultaneous database reads and writes. In general, if your system has been tuned
appropriately, this scenario should not occur. Because we are limiting the use of this server to a single individual
user at a time we should never reach this limit, however it is important to know the mechanics behind the scenes
in order to prevent a scenario like this from occurring.

(Click on Help for additional info):

15
 8. Click on the “Processors” category. A properly tuned landscape should always try to stay within the limits of the
Resources it has access to. Remember that not only is the RAM shared between the Database Server,
Application Server, and Operating System; but the Processors are also shared between these Applications. In
our case, the servers we are using have been allocated two powerful server grade CPUs from the Cloud
infrastructure.

Notice here we have kept the default value of ‘0’ under the “Maximum worker threads” setting. This means the
Database Server will start with a predefined value based on the number of CPUs and whether it is a 32-bit or 64-
bit Architecture. The systems you are using in this exercise are 64-bit and have two CPUs, which mean the
default setting is 512 maximum worker threads (see the help for more info). It is important to configure a value
here which can sufficiently handle the total expected read and write requests on the Database Server at one
time. Keep in mind that we have installed several Databases on this Database Server, and these worker threads
are used by all activities on the Database Server.

NOTE: This Database Server is configured with the default number of worker threads (512 in our case). If all
Databases were being heavily accessed with many work requests, it could result in a shortage of worker threads,
meaning each request over the limit would have to wait until a thread became available. This would impact the
overall Database Server performance considerably and the Applications connected to each Database would
undoubtedly experience this loss in performance. This should not occur due to the fact that we are only using
this server with a single user at a time, but it is important to know the mechanics behind the scenes in order to
prevent a scenario like this from occurring.

(Click on Help for additional info):

16
 9. Click on the “Connections” category.

Notice here we have kept the default value of ‘0’ under the “Maximum number of concurrent connections”
setting. This means the Database Server will allow an unlimited number of connections. Keep in mind that we
have several Applications using this Database Server (BW, IC, Disclosure Management, etc) and each one can
make connections to their Database. In our case, BPC NW utilizes the built-in NetWeaver connectivity to the
Database. In a NetWeaver BW system, each worker process (from Transaction SM50) can establish a
connection to the Database. In a large scale landscape, this can mean several hundred (or more) potential
connections to the Database under heavy concurrency. Remember that once the connection has been
established, the individual work for that connection is done with a worker thread (see previous step).

(Click on Help for additional info):

17
10. Click on the “Advanced” category:

Notice here we have the ability to set some advanced parameters for SQL Server. Of particular importance is
the “Max Degree of Parallelism” setting. This parameter controls how many processors are used when
executing a query plan in parallel. Since we have it set to 1, the parallel plan generation is suppressed. At first
thought, you might think we should turn it on, however this feature is generally only beneficial in specific query
plans. Setting it here makes a global effect on the query optimizer within SQL Server, and you may not want all
query plans to be executed in parallel since the overhead of managing the CPU parallelism may outweigh the
benefit of executing in parallel.

Fortunately, the “Max Degree of Parallelism” parameter is dynamic, meaning that you don’t have to restart the
Database Server for it to take effect. This means we can potentially control when to turn it on and off – resulting
in a more efficient use of this parallel feature. With an SAP Note, (listed below) you can actually control this
behavior from within the SAP Application Server so that Star Join Optimization is used for BI Query execution
plans only (typically, BI Queries can benefit greatly from star join optimization when parallelism is used).

NOTE: For additional information on ways to speed up queries using the parallelization features mentioned in
this step, please refer to the following:

SAP Note 1126568 – Enable star join optimization with SQL Server 2008
SAP BW 7 and SQL Server 2008 Star Join Optimization
http://blogs.msdn.com/b/saponsqlserver/archive/2010/12/03/sap-bw-7-and-sql-server-2008-star-join-
optimization.aspx

(Click on Help for additional info):

18
11. Each Database that SAP supports (SQL Server, Oracle, SAPDB, DB2) has advanced parameters that can be
turned on or off to impact normal behavior. Many of these parameters are very specific and require special
considerations to determine if they should be used or not. Within SQL Server, there are several special
parameters that are not shown in the SQL Server Management Studio. In order to change these parameters,
you can use the “sp_configure” system stored procedure. In this exercise we will not be changing any of these
special parameters, but want to note that they do exist and can help in certain situations. As with any complex
Database issue, you should involve a Database Expert to help analyze the situation and determine if it will be
necessary to use one of these additional settings. You can see a complete list of the SQL Server Advanced
Parameters available in the Help menu.

Click on the help icon and scroll to the bottom of the help window:

Click on the Link “Setting Server Configuration Options” and scroll to the bottom for the list of available
parameters:

19
12. Now let’s check the actual Database Data Files that have been configured for our Database. In the SQL Server
Management Studio, expand the Databases folder (underneath the Top Node). You can see that we have the
Database CSA for our ABAP Application Server where BPC 10 is installed:

13. Right-Click on the “CSA” Database and select “Properties” as shown here:

14. While similar, it is important to note that these are not the Global properties of the Database Server you changed
in the previous steps, these properties are specific to this Database:

20
15. Click on the “Files” category (first screenshot). These files represent the CSA Database on the File System.
Take note of the file locations and sizes. We have eight Data Files of 8.4GB each and one Log File of 6GB.
This means that currently, the maximum size of the CSA Database is slightly more than 64GB with a 6GB Log.
Each Data File also has an Autogrow setting which allows it to be increased in small chunks to a specified limit.
In our case we have unrestricted growth (we do not anticipate the class to run out of space on this installation).

Understanding the Data Files of your Database can also help you gain optimal performance. In an ideal
situation, the Data Files themselves should be physically mounted on separate drives (this can be implemented
as a RAID or SAN configuration) so that reading and writing can be done in parallel. The Log File should always
be placed on a separate drive so that it can be written to while working on the Data Files. Worker processes can
be dispatched to look for data amongst several different Data Files, so it is important to have evenly distributed
data and each Data File should be the same size (to prevent imbalance). The whitepaper referenced at the
beginning of this section has some great recommendations and descriptions of proper Data File management on
SQL Server. It is highly recommended to read it first before installing BW on SQL Server.

NOTE: You can also see the database size and fill level on the ABAP System with tcode “DBACOCKPIT”
(second screenshot). We will go through a few more Database maintenance procedures in Part III.

SQL Server Management Studio View:

ABAP Application Server View (Tcode DBACOCKPIT):

21
Part III – Check the ABAP Application Server Configuration
BPC is installed as an Add-On to BW. Inherently, this means that tuning for BPC must start with tuning for BW
since it uses the BW platform to function. This exercise will show you how to change a few ABAP Application
Server parameters on the BW platform that can help improve performance.

Tuning an ABAP Application Server can be a very complex and involved project, so for the sake of time we will only
focus on a few actions. This exercise will be broken up into the following parts:

-View and Modify Application Server Profile Parameters

-Check Logon Group for Load Balancing
-Check Background Processing Server Group
-Check RFC Server Group
-Check the OLAP Cache Configuration
-Check Database Cockpit
-Schedule and Run SGEN Job

1. Log on to the SAP GUI (user: BPC_XX, pwd: Welcome!)

 2. Let’s start by adjusting the ABAP Application Server memory/profile parameters. In this exercise we will only
focus on a few of the main memory parameters. When tuning memory settings, the parameter values will vary
depending on the hardware and resource configuration of the system. A properly tuned landscape should
always try to stay within the limits of the resources it has access to. Remember that in our case, we are using a
Cloud Server which has been allocated 17.5GB RAM and has 2 powerful server processors.

SAP Memory Management can be a very complex and specific subject depending on various factors. While
there are some concepts that can be applied across most scenarios, there are undoubtedly cases where you
might want to change or tweak certain settings depending on any number of different factors. In tuning an SAP
ABAP Application Server, it is highly recommended to involve both a Basis and BW Expert who is
knowledgeable with how the SAP Application Server uses its resources.

Further Documentation: It is important to get a very good understanding of how SAP Manages Memory if you
are planning to tune your ABAP Application Server. If you are unsure of the architectural concepts you should
first go to the main SAP Help Site (http://help.sap.com) and find the “Technical Operations Guide” for
NetWeaver:
http://help.sap.com/saphelp_nw73/helpdata/en/48/0dd91ad6013d1be10000000a42189d/frameset.htm
Within the “Technical Operations Guide”, you can navigate to the “Administration of Application Server ABAP”
section and find out more about how the Application Server can be managed from a Technical perspective:
http://help.sap.com/saphelp_nw73/helpdata/en/08/9453deb78e4412a5c9ab0d0dcf809e/frameset.htm
Once you have reviewed the Administration Topics, check out “SAP Memory Management” and go through each
section carefully:
http://help.sap.com/saphelp_nw73/helpdata/en/49/325d4ee93934ffe10000000a421937/frameset.htm

23
 3. First we should check the current status of the system and note what the settings are showing before you
change them. Note that with this transaction, you can double click on each row and select
Go to transaction "ST02". This screen provides a current snapshot of the SAP Buffer and Memory Statistics:

4. Next, check the Operating System Status with Transaction “ST06”. Here you can view current (and historical)
statistics of the Operating System:

24
5. Now we are ready to change our ABAP Application Server Profile Parameters. Go to Transaction “RZ10”:

6. Select the Menu option "Utilities->Import profiles->Of active servers":

7. The import will display a Check Log:

 8. Enter transaction "RZ10" again, and click the drop down button for the Profile. When the drop down window
pops up, double click on the "Instance profile":

9. Select the "Extended maintenance" button and click on "Change":

10. You should see a simple list of Profile Parameters for the system:

26
11. We will be adding a few new parameters and adjusting some existing ones (see the next steps for how to change
the values):

Profile Parameters:

abap/buffersize 500000

PHYS_MEMSIZE 10240

rsdb/ntab/entrycount 30000

rsdb/ntab/irbdsize 16000

rsdb/obj/buffersize 300000

rsdb/obj/max_objects 12500

rsdb/esm/buffersize_kb 500000

rsdb/esm/max_objects 12500

abap/shared_objects_size_MB 200

rtbb/buffer_length 100000

rtbb/max_tables 1200

zcsa/table_buffer_area 300000000

zcsa/presentation_buffer_area 100000000

zcsa/db_max_buftab 15000

gw/cpic_timeout 60

gw/max_conn 2000

gw/max_overflow_size 25000000

icm/keep_alive_timeout 3600

icm/HTTP/server_cache_0/memory_size_MB 300

icm/HTTP/server_cache_0/size_MB 600

icm/server_port_0 PROT=HTTP, PORT=1080, PROCTIMEOUT=3600, TIMEOUT=3600

icm/server_port_1 PROT=HTTPS, PORT=1443, PROCTIMEOUT=3600, TIMEOUT=3600

icm/server_port_2 PROT=SMTP, PORT=1025, PROCTIMEOUT=300, TIMEOUT=300

icm/min_threads 50

icm/max_threads 250

mpi/total_size_MB 200

rdisp/max_comm_entries 2000

rdisp/max_wprun_time 3600

rdisp/plugin_auto_logout 3600

rdisp/wpdbug_max_no 3

rdisp/wp_no_dia 30

rdisp/wp_no_btc 10

27
12. For the existing parameters, you can just change the value directly in the list:

13. For the new parameters, click the "New" icon:

14. In the maintenance screen, enter the parameter name and the value, then click the "Copy" button:

15. Click the green "Back" button and confirm the change:

NOTE: Repeat these steps for all parameter values.

28
16. Repeat steps 12 through 15 until all new parameters have been entered. Your parameter list should now show
the values from the table given above in step 11:

NOTE: This screenshot is only for reference, actual values will be based on what you entered in steps 11 - 15.

17. Click the "Copy" button first, and then click on the green back button:

18. Now you must hit the "Save" button in order for the changes to be copied to the server:

29
19. When you save, an automatic check will run to inform you about incorrect parameters… you can ignore this
message:

20. Next, the system will ask you if you want to Activate the profile, click "Yes":

21. You should see the following informational message next, click the green check mark (Continue):

22. The system will then inform you that you must restart the server for the changes to take effect:

23. We will now restart the ABAP Application Server to ensure that the Profile Parameter changes we made earlier
are activated and in use. Open the SAP Management Console icon located on the desktop of the Server:
24. Right-click on "CSA" and choose "Restart":

25. Select "Ok"

26. Enter the BPC_XX password "Welcome!":

31
27. Expand the node under the CSA Root Node, select the line that says “Process List” and hit refresh to see the
status:

28. Give the server some time to start up and make sure all the indicators are green:

29. Using SAP Gui, log back on to the Training System "CSA" with the BW User "BPC_XX " and Password
"Welcome!":

32
30. Go to transaction "ST02" and verify that the values are what you added earlier in the exercise:

33
31. Next we will check the Logon Group. Go to transaction SMLG. Notice we have created the Logon Group
"PUBLIC" already. In this transaction you can create and modify Logon Groups for the ABAP Application Server.
These Logon Groups are for grouping together specific Application Servers so that you can configure your own
Load Balancing. Load Balancing is essential in a distributed landscape which has more than one Instance. This
is helpful for example if you wish to execute all BPC related activity on a specific group of dedicated Instances.

NOTE: For this training course we are only using a single Instance. In a real world scenario you can have many
more instances in your landscape. Each Logon Group can contain one or more Instances (additional instances
would show up in the list under the same Logon Group but with different Instance names).

32. Double Click the PUBLIC Logon Group to see the properties:

Logon Group Assignment:

Logon Group Attributes:

34
33. Now let’s check the Background Processing Server Groups. In the ABAP Application Server you can also create
groups of Instances for Background Processing Load Balancing. This allows you to execute background jobs on
a specific set of Instances only. This is helpful for instance if you wanted to execute all BPC Background Jobs
(such as Data Manager Packages) on a specific group of dedicated Instances.

Go to transaction SM61 and click on the button labeled “Job-Servergruppen” as shown in the screenshot below:

34. In the next screen you should see a list of the available Background Processing Server Groups. Note that it
should be empty. You will create a new Background Processing Server Group in this step. Click on the “Create”
icon as shown in the screenshot below:

NOTE: In this step we will create the default Background Processing Server Group “SAP_DEFAULT_BTC” as
described in SAP Note 786412 – Determining execution server of jobs w/o target server

35. Name your new Server Group “SAP_DEFAULT_BTC”:

35
36. Now we need to assign the Instances to the Server Group we just created. Select the SAP_DEFAULT_BTC
Server Group and click on the “Assignment” button as follows:

37. In the Assignment screen, locate the Instance for this Application Server using the dropdown menu. Click
“Continue” when you have assigned the Instance “EPM10_CSA_00”:

38. Your Background Processing Server Group “SAP_DEFAULT_BTC” should now be created:

36
39. Now let’s check the RFC Server Groups. In the ABAP Application Server you can also create groups of
Instances for RFC Load Balancing. This allows you to execute RFCs on a specific set of Instances only. This is
helpful for instance if you want to execute all BPC Parallel Scripts (using the *XDIM_PACKAGEBY keyword) on
a specific group of dedicated Instances.

NOTE: This step should already be completed already if you have finished the Script Logic and BADI exercise.

Go to transaction /nRZ12:

Here you will see the default RFC Server Group: “parallel_generators”. Since we do not have a distributed
landscape set up for this class, you will only see one instance which belongs to this group. You can always
create your own RFC Server Group here which contains only those instances you want to use for parallel
processing.

See the following SAP Help Site for additional information about implementing Parallel Processing:
http://help.sap.com/saphelp_nw73/helpdata/en/4d/909309eba36e73e10000000a15822b/frameset.htm

40. You can see the specific controls for this Server Group by double clicking on the line named
“parallel_generators”:

37
41. Now let’s check the OLAP Cache Configuration. In the ABAP Application Server you can set up a Cache for
executing BI Queries so that when a query runs on a data selection that is already in the cache the OLAP engine
will retrieve the data from Cache instead of going to the Database. The OLAP Cache can be persisted in a few
different ways, (for instance Main Memory, Cluster Table, etc). Each mechanism has pros and cons and proper
analysis should be done to determine which setting is best in your environment. Remember that the OLAP
Cache setting we change here is Global for all users. If you want to make an individual setting on an InfoCube
(or even on an individual Query) you can override the Global setting.

NOTE: The OLAP Cache uses memory from the Export/Import Shared Memory Buffer which is sized according
to several profile parameters we have set already. (see profile parameters tuning at the beginning of this
section).

Go to transaction RSRCACHE:

42. Click on the “Cache Parameter” button:

38
43. Set the Local Size MB to 100, and the Global Size MB to 200. Next, change the Cache Persistence Mode to
“Cluster Table”. For a detailed description of the Persistence Modes, use F1 as noted in the Screenshot:

IMPORTANT NOTE: THIS IS THE GLOBAL SYSTEM SETTING FOR NEW OBJECTS (existing settings on
individual cubes and queries will stay the same). In this exercise we will also change the individual
settings for one of the BPC Cubes to demonstrate flexibility with the Caching mechanism itself.

44. Make sure to SAVE your change. When the system prompts you for a workbench request, create a new one by
clicking on the “Create Request” icon:

39
45. After clicking the “Save” button, click “Continue” in the prompt for workbench request screen:

46. You should see that your changes were saved:

47. Now, let’s change the individual setting on a BPC InfoProvider to override the Global setting we just made. Go to
transaction RSA1 and find the InfoArea for the BPCP_XX Environment as follows:

40
48. Double-Click on the “Planning” Multiprovider and click through the pop-up message informing you which
InfoCubes are in this Multiprovider:

49. Select the menu option “Extras->InfoProvider Properties->Change”:

NOTE: We are changing the OLAP Cache for the Multiprovider (not the InfoCube) of the Planning model
because BPC Reports get their data from the Multiprovider. The OLAP Cache setting we make here only affects
this particular Multiprovider. This means you can set different Cache modes and settings for different BPC
Environment/Models.

50. Click continue on the information pop up about “R3TR”:

41
51. Change the Cache Mode for the Planning Multiprovider to: “Main Memory Cache Without Swapping” and hit the
“Save” button.

IMPORTANT NOTE: Notice here we are changing the caching mechanism specifically for this BPC
Multiprovider. Queries on this Multiprovider will use Main Memory for the persistence of its OLAP Cache
entries whereas the global setting for the rest of the system is to use a cluster table.

52. The following screenshot demonstrates the relationship between the Infoprovider Name and the default OLAP
Query Name. All Infoproviders have a default OLAP Query Name, and BPC NetWeaver uses the Query for the
Multiprovider in order to retrieve data from the Infocube itself. If we wanted to, this could allow us to further
modify the individual Cache settings down to the Query level itself (although it doesn’t really matter since there is
only one Query built on this Multiprovider).

<infoprovider technical name>/!!O<infoprovider technical name>

42
53. In order to demonstrate that the Cache is being filled, let’s delete all of the Cache Entries (for the entire system).
Go to transaction RSRCACHE and click on the “Delete” icon as follows:

54. Click “Yes” on the pop up screen:

55. Now go back to the RSRT transaction (Click BACK once):

56. At this point, we can RUN a BPC Report to see if it fills the OLAP Cache. Open the EPM Add-In and logon to the
BPCP_XX/Planning Environment/Model:
57. Open the Server Root Folder:

58. Choose the report named “PRODUCT_LINE_REPORT.XLSX”

59. Refresh the Worksheet:

44
60. The Report should show some values (indicating that data was in fact retrieved):

61. Now let’s go back to SAP GUI and enter transaction “RSRCACHE” so we can view the Cache Monitor. This
should allow us to see the Cache Entry that was just created in Main Memory. Click on the “Main Memory”
button as follows:

62. We can see that a new Cache Entry in Main Memory was created for the BPC Report we just refreshed
(PRODUCT_LINE_REPORT):

NOTE: You can see that the Memory ID is based upon the Query name (which is also made up of the Technical
Name of the BPC Multiprovider)

45
63. Now let’s look at how we can manage the Database from within SAP GUI. Go to transaction "DBACOCKPIT". A
pop-up will show up describing the transaction, click "Continue":

64. Expand the “Performance” Folder and double-click on “Overview”. Here we can see some high level information
about the performance of our Database:

65. Expand the Configuration Folder and double-click on “Overview”. Here we can see some basic Database
configuration. (Notice we can see the minimum/maximum memory values as well as the “Max Degree of
Parallelism” setting we discussed in Part II):

46
66. Double-click on “Configuration Options” while still under the “Configuration” Folder. Notice here we can see a
detailed list of all the Database Parameters:

67. Double-Click on “SQL Server Setup Check” while still under the “Configuration” Folder. This will run a simple
check to make sure basic parameters and settings have been made:

47
68. Expand the "Jobs" folder and double-click on "DBA Planning Calendar". Here you can schedule DBA
Maintenance Jobs to run periodically. Because SQL Server automates many of the standard Optimizer Statistics
jobs we won’t need to schedule them manually in this system, however if this was on a different Database, you
could schedule Optimizer Statistics to run on a periodic basis.

69. Another great way to keep general system performance at an efficient level is to run the SGEN utility periodically.
SGEN is a transaction in which you can schedule the generation of ABAP Programs. Each time a program has
been changed or updated, you need to re-generate it before it can run. SGEN allows you to generate all ABAP
Programs in a parallelized manner. Having to generate ABAP Programs can take time depending on the amount
of generation needed, so it is important that you run SGEN during downtime after big system changes such as
Support Package upgrades. Often programs get modified and changed in the system as time goes by, so SGEN
provides a way to schedule a background job which keeps track of programs that need to be re-generated. We
can schedule this job to run weekly (or even daily in some cases) so that program generation is always up to
date.

Go to transaction “SGEN”:

48
70. Let’s schedule the SGEN Maintenance job to run weekly. Because the report will handle the generation and
tracking of which programs will need to be regenerated, all we have to do is schedule the Report
RSGENINVLAS to run periodically:

NOTE: For more information about the RSGENINVLAS program, see SAP Note 438038 – Automatic
regeneration of invalidated loads

71. Go to transaction SE38 and enter the program name “RSGENINVLAS” as shown below:

49
72. Click on the menu path “Program->Execute->Background” as shown below:

73. In the next window, click on the Schedule button:

74. Give the background job the name “RUN_RSGENINVLAS_PROGRAM” and set the Start date to some point in
the future (try to schedule this during system downtime). After making these changes, click on the “Schedule
periodically” button:

50
75. In the period selection pop-up, choose “Weeks” and click “Continue”:

76. The program should now be scheduled to run weekly.

77. You can check the status of (or cancel/modify) the job in transaction SM37:

51
Part IV – Check the BPC Application Configuration
This exercise will show you how to change a few BPC NetWeaver parameters that enable Back End Load
Balancing. Note that Front End Web Server Load Balancing can be achieved by installing SAP Web
Dispatcher. The SAP Web Dispatcher can load balance Web requests to an SAP Application Server Logon
Group of your choice. Web Server Load Balancing will not be covered in this exercise.

Tuning a BPC Application can depend on many different factors. As with any Business Application, the model is of the
utmost importance. Model discussions will vary depending on the type of implementation you are performing, so this
exercise will only focus on tuning and maximizing BPC throughput and load capability. Tuning BPC reports and input
schedules through various modeling and formatting techniques will not be a part of this exercise.

This exercise will be broken up into the following parts:

-Configure Load Balancing for BPC 10

-Configure the Background Server Group for BPC 10
-Configure the Parallel Processing Server Group for BPC 10

1. Let’s configure BPC 10 to take advantage of Application Server Load Balancing. BPC communication to the
Back End happens with a special BPC Service User and a special BPC RFC Destination. To enable the Back
End Load Balancing for BPC 10, we only need to set the option in the BPC RFC Destination:

Go to transaction SM59, select the BPC RFC Destination “BPC_RFC_DEST” as shown in the screenshot below
and click on the “Change” icon (pencil).

NOTE: This RFC Destination was created and mapped to BPC according to the BPC 10 Installation Guide. For
details about this process, please refer to the Installation Guide.

52
 2. In the maintenance screen, make sure to select “Yes” under the Load Balancing section. Change the Group to
“PUBLIC” and click the “Save” icon:

3. Next we will specify a background server group (which you have already created in Part III) for the BPC Data
Manager Packages. In this step, we are showing how you can specify a Background Server Group for which
you want to execute your BPC Data Manager Packages on. This is helpful if you want to force all BPC Data
Manager Activity to execute on a specific set of Application Servers within your landscape. Remember that this
exercise is only to show you how and where you would change this setting, but because we are only working
with a single instance landscape the configuration won’t have any effect.

Go to transaction SPRO and click on the “SAP Reference IMG” button:

53
 4. Expand the menu for “Planning and Consolidation” and “Configuration Parameters” and click the execute button
next to “Set Global Parameters”:

5. Click on the “New” Icon:

6. Enter the Parameter name “BACKGROUND_SERVER_GROUP” in the detail screen and click “Continue”:

7. Enter the Background Processing Server Group “SAP_DEFAULT_BTC” in the detail screen and click “Continue”.
This is the Background Server Group you created in Part III and it is used when executing Data Manager
Packages:

54
 8. Click the “Save” icon:

9. Now we need to make sure that the BPC Global parameter "PARALLEL_SERVER_GROUP" has been set, so
that BPC knows which RFC Server Group to execute parallel runs on. Remember from the Script Logic and
BADI exercise that you have already set this parameter up. When running Script Logic with the
*XDIM_PACKAGEBY keyword, you can designate an RFC Server Group for which to execute the parallel runs.

NOTE: In this step we will review the steps for setting this parameter even though it should already be complete
on your server. Only complete the following steps if your Server does not have the
“PARALLEL_SERVER_GROUP” parameter set.
Click on the “New” Icon:

10. Enter the Parameter name “PARALLEL_SERVER_GROUP” in the detail screen and click “Continue”:

11. Enter the name Server Group you created at the beginning of this section “SAP_DEFAULT_BTC” in the detail
screen and click “Continue”. This is the Background Server Group used to execute the BPC Script Logic parallel
runs:

55
12. Click the “Save” icon:

56
Post Config – Validate Results against Benchmarks and
Baselines
This section directs you to validate results against the Benchmarks established in the beginning of this
exercise. (See the Pre-Requisite Section for additional details).

57
Appendix
SAP Notes:

SAP Note 1126568 – Enable star join optimization with SQL Server 2008
http://service.sap.com/sap/bc/bsp/spn/sapnotes/index2.htm?nlang=EN&numm=1126568

SAP Note 786412 – Determining execution server of jobs w/o target server
http://service.sap.com/sap/bc/bsp/spn/sapnotes/index2.htm?nlang=EN&numm=786412

SAP Note 1476057 – Enable server group in BPC job execution

http://service.sap.com/sap/bc/bsp/spn/sapnotes/index2.htm?nlang=EN&numm=1476057

SAP Note 192658 – Setting parameters for BW systems

http://service.sap.com/sap/bc/bsp/spn/sapnotes/index2.htm?nlang=EN&numm=192658

SAP Note 1044441 – Basis parameterization for NW 7.0 BI systems

http://service.sap.com/sap/bc/bsp/spn/sapnotes/index2.htm?nlang=EN&numm=1044441

SAP Note 1530280 – overflow warning for OLAP main memory cache
http://service.sap.com/sap/bc/bsp/spn/sapnotes/index2.htm?nlang=EN&numm=1530280

SAP Note 702728 – Profile parameter for export/import buffer instances

http://service.sap.com/sap/bc/bsp/spn/sapnotes/index2.htm?nlang=EN&numm=702728

SAP Note 656060 – OLAP: Cache main memory displacement not functioning
http://service.sap.com/sap/bc/bsp/spn/sapnotes/index2.htm?nlang=EN&numm=656060

SAP Note 480710 – Profile parameters for table buffers

http://service.sap.com/sap/bc/bsp/spn/sapnotes/index2.htm?nlang=EN&numm=480710

SAP Memory Management:

http://help.sap.com/saphelp_nw73/helpdata/en/49/325d4ee93934ffe10000000a421937/frameset.htm

OLAP: Cache Monitor:

http://help.sap.com/saphelp_nw73/helpdata/en/41/b987eb1443534ba78a793f4beed9d5/frameset.htm

RSGENINVLAS - Automatic Regeneration of Invalidated Loads

http://help.sap.com/saphelp_nw04/helpdata/EN/d1/6e583cf7388362e10000000a114084/frameset.htm

SAP and SQL Server Whitepaper:

http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/4ab89e84-0d01-0010-cda2-82ddc3548c65

Running SAP Applications on SQL Server (MSDN Blog):

http://blogs.msdn.com/b/saponsqlserver/

SQL Server Online Library:

http://msdn.microsoft.com/en-us/library/ms130214.aspx

58
© 2010 by SAP AG.
All rights reserved. SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services
mentioned herein as well as their respective logos are trademarks or registered tradem arks of SAP AG in Germany and other countries.

Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other
Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered tradem arks of Business
Objects S.A. in the United States and in other countries. Business Objects is an SAP company.

All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves
informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for
informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to
the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

59