SAP BW System admin.txt

7/27/2019 SAP BW System admin.txt

1/9

In an end user perspective, performance is nothing but, is the next logical dialog screen appears on his/her GUI without any long delay. If there is a delay, itappears to be a bad performing system.In a traditional way, performance tuning of an SAP application deals with buffermanagement, database tuning, work process tuning, fragmentation of the database, reorganization of the database, reducing I/O contention, operating system tuning, table stripping and the list goes on depending on the nature of the system.

This document deals with more of performance tuning in a BW perspective rather than general R/3 parameter tuning. Like, query performance, data load performance, aggregate tuning etc.This document will focus the following key aspects in a detailed fashion. 1.

What are the different ways to Tune an SAP system? ( General )2. What are the general settings we need to adapt in a good performing BW system?3. What are the factors which influence the performance on a BW system?4. What are the factors to consider while extracting data from source system?5. What are the factors to consider while loading the data?6. How to tune your queries?7. How to tune your aggregates?8. What are the different options in Oracle for a good performing BW system?9. What are the different tools available to tune a BW system? (With screen

shots).10. What are the best practices we can follow in a BW system?1. What are the different ways to tune an SAP system?Aim of tuning an SAP system should focus on one major aspect. Availability of the next logical screen to all users (end users/business users/super users) with equal or unequal (depending on the business requirement) allocation of technicalresources in a timely manner. And also we need to keep in mind that we have spent just the optimal amount of money on the technical resources.There are two major paths we need follow to tune an SAP system.Tune it depending on the business requirement.Tune it depending on the technical requirement. Business requirement.

Consider how many Lines of businesses we have in our company. Which Lines of business uses which IT infrastructure and how efficiently or inefficiently does that LOB uses the IT infrastructure? Who are all my critical users? Is it possibleto assign a part of the technical resources just for them to use? How is the growth of my database? What are the key LOB's and who are the key users influencingthe growth in the database? What is the data most frequently used? Is that dataavailable always? Likewise, the list goes on... Understanding the business requirement and we can tune the system accordingly. Technical requirement:How many CPU's? How many disks? Is there an additional server node required? Howbalanced is the load? How much is the network speed? Is table stripping required? What is the hit ratio? What is the I/O contention? Should we reorganize? Whatis the efficiency of the operating system? How is the performance of BEX? Likew

ise here also the list goes on...By gauging, analyzing and balancing the two lists of technical requirements andbusiness requirements we can end up in a good performing SAP system. 2. What arethe general settings we need to adapt in a good performing BW system?Following are the main parameters we need to monitor and maintain for a BW system. To start with performance tuning in a BW system, we have to focus on the following parameters. Rsdb/esm/buffersize_kb.Rsdb/esm/max_objects.Rtbb/max_tables.


2/9

Rtbb/buffer_length.Rdisp/max_wprun_timeGw/cpic_timeoutGw/max_connGw/max_overflow_sizeRdisp/max_comm_entriesDbs/ora/array_buf_sizeIcm/host_name_fullIcm/keep_alive_timeoutDepending on the size of the main memory, the program buffer should be between200 and 400 MB. Unlike in R/3 Systems, a higher number of program buffer swaps is less important in BW Systems and is often unavoidable since the information stored in the program buffer is significantly less likely to be reused. While theresponse times of R/3 transactions is only around several hundred milliseconds,the response times of BW queries takes seconds. However, by tuning the programbuffer, you can only improve the performance by milliseconds.Therefore, if the available main memory is limited, you should increase the sizeof the extended memory. However, the program buffer should not be set lower than 200 MB. If the available main memory is sufficient, the program buffer in BW 2.X/3.X systems should be set to at least 300 MB.BW users require significantly more extended memory than R/3 users. The size ofthe extended memory is related to the available main memory but should not be lower than 512 MB.

Set the Maximum work process runtime parameter to maximum and also set the timeout sessions to be high. Set the parameter dbs/ora/array_buf_size to a sufficiently large size to keep the number of array inserts, for example, when you uploaddata or during the rollup, as low as possible. This improves the performance during insert operations.The main performance-related tables in the BW environment are: F-Fact tables: /BI0/F E-Fact tables: /BI0/E Dimension tables: /BI0/D SID tables: /BI0/S SID tables (navigation attribute, time-independent): /BI0/X SID tables (navigation attribute, time-dependent): /BI0/YIn addtion to the /BI0 tables delivered by SAP, you also have customer-specific /BIC t

ables with a naming convention that is otherwise identical.Since objects and partitions are frequently created and deleted in BW, and extents are thus allocated and reallocated, you should use Locally Managed Table spaces (LMTS) in the BW environment wherever possible.Since numerous hashes, bitmap and sort operations are carried out in the BW environment especially; you must pay particular attention to the configuration of the PGA and PSAPTEMP table spaces. These components are crucial factors in the performance of processing the operations described. You must therefore ensure thatPGA_AGGREGATE_TARGET is set to a reasonable size and that PSAPTEMP is in a high-speed disk area. It may be useful to add up to 40 % of the memories available for Oracle to the PGA.If you work with large hierarchies, you have to increase the size of this bufferconsiderably. You should be able to store at least 5,000 objects in the buffer.

The BW basis parameters must be set optimally for the BW system to work withouterrors and the system to perform efficiently. The recommendations for BW systems are not always the same as those for R/3 systems.3. What are the factors which influence the performance on a BW system?There are three major factors that influence the performance of a BW system. How we administer the BW system? Technical resources available. How the entire BW landscape is designed?BW ADMINISTRATION


3/9

First step to resolve most of the problems in BW system is Archive. Archive themost amount of data you can.Archive data from Info Cubes and ODS objects and delete the archived data from the BW database. This reduces the data volume and, thus, improves upload and query performance.An archiving plan can also affect the data model. For a yearly update, an Multiprovider partitioning per yearThe archiving process in the BW system works slightly differently to that in anR/3 environment. In an R/3 system, the data is written to an archive file. Afterwards, this file is read and the deleted from the database, driven by the content of the file. In a BW system, the data from the archived file is not used in the deletion process (only verified to be accessible and complete). The values ofthe selection characteristics, which have been used for retrieving data in the 'Write' job, are passed to the selective deletion of the data target. This is thesame functionality that is available within data target management in the Administrator Workbench ('Contents' tab strip). This functionality tries to apply anoptimal deletion strategy, depending on the values selected, that is, it drops apartition when possible or copies and renames the data target when more than acertain percentage of the data has to be deleted.Reloading archived data should be an exception rather than the general case, since data should be archived only if it is not needed in the database anymore. When the archived data target is serving also as a data mart to populate other datatargets, we recommend that you load the data to a copy of the original (archived) data target, and combine the two resulting data targets with a MultiProvider.

In order to reload the data to a data target, you have to use the export Data Source of the archived data target. You then trigger the upload either by using'Update ODS data in data target' or by replicating the Data Sources of the MYSELF source system and subsequently scheduling an Info Package for the respective Info Source. In this scenario we have used the first option. Load balancing:Load balancing provides the capability to distribute processing across severalservers in order to optimally utilize the server resources that are available. An effective load balancing strategy can help you to avoid inefficient situationswhere one server is overloaded (and thus performance suffers on that server), while other servers go underutilized. The following processes can be balanced:

? Logon load balancing (via group login): This allows you to distribute the workload of multiple query/administration users across several application servers.

? Distribution of web users across application servers can be configured in the BEx service in SICF.And also, Process chains, Data loads and data extractions should be

routed to perform in specific target servers.In some cases, it is useful to restrict the extraction or data load to a specific server (in SBIW in an SAP source system, or SPRO in BW), i.e. not using loadbalancing. This can be used for special cases where a certain server has fast CPUs and therefore you may want to designate it as an extraction or data load server.Reorganize the table:

Logs of several processes are collected in the application log tables. These tables tend to grow very big as they are not automatically deleted by the system and can impact the overall system performance.

Table EDI40 can also grow very big depending on the number of IDOC records.Depending on the growth rate (i.e., number of processes running in the system),either schedule the reorganization process (transaction SLG2) regularly or delete log data as soon as you notice significant DB time spent in table BALDAT (e.g., in SQL trace).

Delete regularly old RSDDSTAT entries.If several traces and logs run in the background, this can lead to bad overall performance and sometimes it's difficult todiscover all active logs. So be sure to switch off traces and logs as soon as t


4/9

hey are not used any more.Technical resources available:

The capacity of the hardware resources represents highly significant aspect ofthe overall performance of the BW system in general. Insufficient resources in any one area can constraint performance capabilitiesThese include:? Number of CPUs? Speed of CPUs? Memory? I/O-Controller? Disk architecture (e.g. RAID)A BW environment can contain a DB server and several application servers. Theseservers can be configured individually (e.g. number of dialog and batch processes), so that the execution of the different job types (such as queries, loading,DB processes) can be optimized. The general guideline here is to avoid hot spotsand bottlenecks.For optimizing the hardware resources, it is recommended to define at least twooperation modes: one for batch processing (if there is a dedicated batch window) with several batch processes and one for the query processing with several dialog processes.Different application servers have separate buffers and caches. E.g. the OLAP cache (BW 3.x) on one application server does not use the OLAP cache on other servers.BW landscape design:

Info Cube modeling is the process by which business reporting requirements are structured into an object with the facts and characteristics that will meet the reporting needs.Characteristics are structured together in related branches called dimensions.The key figures form the facts.The configuration of dimension tables in relation to the fact table is denoted as "star schema".For a BW system to perform better we should not combine dynamic characteristicsin the same dimension in order to keep dimensions rather small. Example: Don't combine customer and material in one dimension if the two characteristics are completely independent. As a general rule, it makes more sense to have many smallerdimensions vs. fewer larger dimensions. Dimension tables should be sized less than 10% of the fact table.

Use MultiProvider (or logical) partitioning to reduce the sizes of the Info Cubes.Example: Define Info Cubes for one year and join them via a MultiProvider so wecan have parallel access to underlying basis Info Cubes, load balancing, and resource utilization.Define large dimensions as line item dimensions (e.g. document number or customer number) if (as a rule of thumb) the dimension table size exceeds 10 % of the fact table(s) size; B-tree is generally preferable for cases where there is highcardinality (high number of distinct values)Info Cubes containing non-cumulative key figures should not be too granular. Ahigh granularity will result in a huge amount of reference points which will impact aggregate build significantly. Reference points can only be deleted by deleting an object key not specifying the time period, i.e. all available records for

this key are deleted.The data model has tremendous impact on both query AND load performance. E.g. bad dimension model. Example: Customer and material in one dimension instead of separate dimensions can lead to huge dimension tables and thus slows down query performance, as it is expensive to join a huge dimension table to a huge fact table. Transaction RSRV can be used to check the fact to dimension table ratio.As non-cumulative key figures are well defined for every possible point in time(according to the calculation algorithm), it could make sense to restrict the validity to a certain time period. Example: If a plant is closed, it should not show up any stock figures. These objects can be defined as validity objects. Note


5/9

that for every entry in the validity table, a separate query is generated at query runtime.

4. What are the factors to consider while extracting data from source system?Data load performance can be affected by following key aspects.Customer exits. Check with RSA3, SE30 and ST05Resource utilization. SM50 / SM51Load balancing. SM50 / SM51 (Configure ROIDOCPRMS)Data package size.Indices on tables. ST05Flat file format.Content Vs generic extractor. The size of the packages depends on the application, the contents and structure of the documents. During data extraction, a dataset is collected in an array (internal table) in memory. The package size settingdetermines how large this internal table will grow before a data package is sent. Thus, it also defines the number of Commit's on DB level.Use RSMO and RSA3 to monitor the load.Indices can be built on Data Source tables to speed up the selection process.If there is a poor performance in data load, refer the following noteNote 417307 - Extractor package size: Collective note for applications.If you define selection criteria in your Info Package and the selection of thedata is very slow, consider building indices on the Data Source tables in the source system.

5. What are the factors to consider while loading the data?There are two major aspects to consider while loading data.I/O contention.O/S Monitors. I/O contention.High number of DB writes during large data loads.Disk Layout and Striping. (What is located on the same disk or table space/DB space etc.?)At the time of data load we need to also check the transformation rules. Use SE30 and ST05.The master data load creates all SIDs and populates the master data tables (attributes and/or texts). If the SIDs does not exist when transaction data is loaded, these tables have to be populated during the transactiondata load, which slows down the overall process.Another major function which could be performed at data load is buffering number

ranges.SID number range can be buffered instead of accessing the DB for each SID.If you encounter massive accesses to DB table NRIV via SQL trace (ST05), increase the number range buffer in transaction SNRO.Always load master data before transaction data. The transaction data load willbe improved, as all master data SIDs are created prior to the transaction data load, thus precluding the system from creating the SIDs at the time of load.In transaction RSCUSTV6 the size of each PSA partition can be defined. This sizedefines the number of records that must be exceeded to create a new PSA partition. One request is contained in one partition, even if its size exceeds the user-defined PSA size; several packages can be stored within one partition.The PSA is partitioned to enable fast deletion (DDL statement DROP PARTITION). P

ackages are not deleted physically until all packages in the same partition canbe deleted.Transformation rules are transfer rules and update rules. Start routines enableyou to manipulate whole data packages (database array operations) instead of changing record-by-record. In general it is preferable to apply transformations asearly as possible in order to reuse the data for several targets.Flat files: Flat files can be uploaded either in CSV format or in fixed-length ASCII format. If you choose CSV format, the records are internally converted in f


6/9

ixed-length format, which generates overhead.You can upload files either from the client or from the application server. Uploading files from the client workstation implies sending the file to the application server via the network - the speed of the server backbone will determine thelevel of performance impact, Gigabit backplanes make this a negligible impact.The size (i.e., number of records) of the packages, the frequency of status IDocs can be defined in table RSADMINC (Transaction RSCUSTV6) for the flat file upload. If you load a large amount of flat file data, it is preferable to use fixed-length ASCII format, to store the files on the application server rather than onthe client and to set the parameters according the recommendations in the referenced note.If possible, split the files to achieve parallel upload. We recommend as many equally-sized files as CPUs are available. 6 / 7. How to tune your queries and aggregates?The data in a Data Warehouse is largely very detailed. In SAP BW, the Info Cubeis the primary unit of storage for data for reporting purposes. The results obtained by executing a report or query represent a summarized dataset.An aggregate is a materialized, summarized view of the data in an Info Cube. Itstores a subset of Info Cube data in a redundant form. When an appropriate aggregate for a query exists, summarized data can be read directly from the databaseduring query execution, instead of having to perform this summarization during runtime. Aggregates reduce the volume of data to be read from the database, speedup query execution time, and reduce the overall load on the database.A sound data model in BW should comprise of the following

Dimensional modeling.Logical partitioning.Physical partitioning.The main purpose of aggregate is to accelerate the response time of the queries, by reducing the amount of data that must be read in the database for a navigation step. Grouping and filtering will enhance the value of an aggregate.We can group according to the characteristic or attribute value, according to the nodes of the hierarchy level, and also filter according to a fixed value.It is guaranteed that queries always deliver consistent data when you drilldown.This means that data provided when querying against an aggregate is always fromthe same set of data that is visible within an Info Cube.RollupNew data packets / requests that are loaded into the InfoCube cannot be used at

first for reporting if there are aggregates that are already filled. The new packets must first be written to the aggregates by a so-called "roll-up". Data thathas been recently loaded into an InfoCube is not visible for reporting, from the InfoCube or aggregates, until an aggregate roll-up takes place. During this process you can continue to report using the data that existed prior to the recentdata load. The new data is only displayed by queries that are executed after asuccessful roll-up. See the attachment for more details on the technical processof a roll-up.The split of a query is rule-based.Parts of the query on different aggregation level are split.Parts with different selections on characteristic are combined.Parts on different hierarchy levels or parts using different hierarchies are split.

After the split, OLAP processor searches for an optimal aggregate each part. Parts which use the same aggregate will be combined again (in some cases it is notpossible to combine them)Maintaining an aggregate: RSDDV.After selecting a particular info cube, we could drill down to the options of the aggregate to tune each of them.

This is the same screen for BI Accelerator index.


7/9

RSDDBIAMON:This is another important T code where we could perform the following actions. Possible actionsRestart host: restarts the BI accelerator hardwareRestart BIA server: restarts all the BI accelerator servers and services. This includes the name server and index serverRestart BIA index server: restarts the index server. (The name servers are not restarted.) Rebuild BIA indexes: If a check discovers inconsistencies in the indexes, you can use this action to delete and rebuild all the BI accelerator indexes.Reorganize BIA landscape: If the BI accelerator server landscape is unevenly distributed, this action redistributes the loaded indexes on the BI accelerator serversChecksConnection CheckIndex Check

In our system BIA monitor is not set up. So, we need to set up this. Here am notgoing to set up this, because it might affect few other RFC destinations.Query design: Multi-dimensional Query.Inclusion / Exclusion.Multi provider query.Cell calculation

Customer exits.Query read mode.Every Query should start with a relatively small result set; let the user drilldown to more detailed information.Do not use ODS objects for multi-dimensional reporting.Queries on Multi Providers usually access all underlying Info Providers, even if some cannot be hit as no key figures within the query definition are containedin this Info Provider.In ORACLE, fact tables can be indexed either by bitmap indices or by B-tree indices. A bitmap index stores a bitmap stream for every characteristic value. Bitmap indices are suitable for characteristics with few values. Binary operations (AND or OR) are very fast.B-tree indices are stored in a (balanced) tree structured. If the system searche

s one entry, it starts at the root and follows a path down to the leaf where therow ID is linked. B-tree indices suit for characteristics with lots of values.In some cases, ORACLE indices can degenerate. Degeneration is similar to fragmentation, and reduces the performance efficiency of the indexes. This happens whenrecords are frequently added and deleted.The OLAP Cache can help with most query performance issues. For frequently usedqueries, the first access fills the OLAP Cache and all subsequent calls will hitthe OLAP Cache and do not have to read the database tables. In addition to thispure caching functionality, the Cache can also be used to optimize specific queries and drill-down paths by 'warming up' the Cache; with this you fill the Cache in batch to improve all accesses to this query data substantially.8. What are the different options in Oracle for a good performing BW system?I/O hotspots:

The purpose of disk layout is to avoid I/O hot spots by distributing the data accesses across several physical disks. The goal is to optimize the overall throughput to the disks.The basic rule is: stripe over everything, including RAID-subsystems.Managing table spaces:Locally-Managed Table spaces manage their own extents by maintaining bitmaps in each data file. The bitmaps correspond to (groups of) blocks.Be sure that all (bigger) table spaces are locally managed. Extent and partitionmaintenance is drastically improved, as DB dictionary accesses are minimized. Administration maintenance is also reduced.


8/9

Parallel query option:ORACLE can read database table contents in parallel if this setting is active. BW uses this feature especially for staging processes and aggregate build. The Parallel Query Option is used by default. Be sure, that the init.ora-entriesfor PARALLEL_MAX_SERVERS are set appropriate to the recommendations in the ORACLE note.

Table partitioning:Table partitions are physically separated tables, but logically they are linkedto one table name. PSA tables and non-compressed F-fact table are partitioned bythe system (by request ID). The (compressed) E-fact table can be partitioned bythe user by certain time characteristics. For range-partitioned InfoCubes, theSID of the chosen time characteristic is added to both fact tables.When using range partitioning, query response time is generally improved by partition pruning on the E fact table: all irrelevant partitions are discarded and the data volume to be read is reduced by the time restriction of the query.In ORACLE, report SAP_DROP_EMPTY_FPARTITIONS can help you to remove unused or empty partitions of InfoCube or aggregate fact tables. Unused or empty partitionscan emerge in case of selective deletion or aborted compression and may affect query performance as all F fact table partitions are accessed for queries on theInfoCube.9. What are the different tools available to tune a BW system?RSMO is used to monitor data flow to target system from source system. We can see data by request, source system, time request id etc. It provides all necessa

ry information on times spent in different processes during the load (e.g., extraction time, transfer, posting to PSA, processing transformation rules, writingto fact tables). In the upload monitor you are also able to debug transfer and update rules.If the extraction from an SAP source system consumes significant time, use the extractor checker (transaction RSA3) in the source system.If the data transfer times are too high, check if too many work processes are busy (if so, avoid large data loads with "Update Data Targets in Parallel" method), and check swapping on one application server (set "rdisp/bufrefmode = "sendoff, exeauto" during load phase if you use several application servers).RSRTThe Query Monitor (transaction RSRT) allows you to execute queries and to tracequeries in a debug mode with several parameters (e.g., do not use aggregates, d

o not use buffer, show SQL statement).In the debug mode, you can investigate if the correct aggregate(s) are used andwhich statistics the query execution generates. For checking reasons, you can switch off the usage of aggregates, switch to no parallel processing (see for moredetails in the MultiProvider section) or display the SQL statement and the runschedule.

Select a particular query and then click on performance info.Like this query we can generate detailed performance info for every query. Below is the screen shot containing the detailed information for this query.

Query tracing:RSRTRACE. The Query Trace Tool (transaction RSRTRACE) allows you to record some

important function module calls and process and debug them at a later stage. Transaction RSRCATTTRACE takes the log of RSRTRACE as input and gives aggregates suggestions for the first execution AND all further navigations performed.

RSRV:BW objects can be checked for consistency in transaction RSRV and inconsistent objects can be repaired.Apart from these BW tools, we have standard ABAP based tools like ST05, ST03n,SE30, SM50 and SM51 to check and measure the performance of the system.In SE 30, we have special options like if cases, field conversions and monitoring the SQL interface.


9/9

ST05: The SQL trace (transaction ST05) records all activities on the database and enables you to check long runtimes on a DB table or several similar accessesto the same data.If we find problems for an isolated process (upload or query) and we have analyzed for example the existence of aggregates, we can detail our analyses by usingthe SQL trace. Filter on a specific user (e.g. query user or extraction user ALEREMOTE) and make sure that no concurrent jobs run at the same time with this execution. We will find out which tables are accessed, what time is consumed and ifsome tables are accessed redundantly.Another important tool to be used is ST10.Here we can find out the statistics of the table and get more detailed info on aparticular table. If we assume a general buffer problem, check ST10 and check the buffer settings of all tables; compare usage of buffer vs. invalidations.ST04, DB02, SM50, SM51, ST02, ST06 are some the important tools which we normally use in R/3. These transaction codes should be extensively used here as well for gauging and optimizing the performance of the system. 10.What are the best practices we can follow in a BW system?Best practices for a production BW system can be drafted only with a close interaction with the functional team and technical team and the nature of the production system.Here, are couple of best practices we could implement to improve the performance.

Activate Transfer rule for info source:When you have maintained the transfer structure and the communication structure, you can use the transfer rules to determine how the transfer structure fields are to be assigned to the communication structure InfoObjects. You can arrange for a 1:1 assignment. But you can also fillInfoObjects using routines or constants.Use scheduler:The scheduler is the connecting link between the source systems and the SAP Business Information Warehouse. Using the scheduler you can determine when and fromwhich InfoSource, DataSource, and source system, data (transaction data, masterdata, texts or hierarchies) is requested and updated.The principle behind the scheduler relates to the functions of SAP background jobs. The data request can be scheduled either straight away or it can be scheduled with a background job and started automatically at a later point in time. We g

et to the data request via the Scheduler in the Administration Workbench Modeling, by choosing InfoSource Tree Your Application Component InfoSources Source System Context Menu Create InfoPackageAssign several info sources: Assign several DataSources to one InfoSource, if you want to gather data from different sources into a single InfoSource. This is used, for example, if data from different IBUs that logically belongs together isgrouped together in BW.The fields for a DataSource are assigned to InfoObjects in BW. This assignment takes place in the same way in the transfer rules maintenance.

Documents

SAP BW System admin.txt