Upload
ananda-babu-vodnala
View
219
Download
0
Embed Size (px)
Citation preview
8/12/2019 b w Performance
http://slidepdf.com/reader/full/b-w-performance 1/27
© 2010 SAP AG
Best-Practice Document
Monitoring for BW Data Staging
Dietmar-Hopp-Allee 16D-69190 Walldorf
DATE
April 2011
SOLUTION MANAGEMENT PHASE SAP SOLUTION
Operations Implementation
Operations & Continuous Improvement
SAP SAP NetWeaver Business Warehouse (BW)
TOPIC AREA SOLUTION MANAGER AREA
Application management
Business process operations
Technical operations
System Monitoring
System Administration
Business Process Monitoring
8/12/2019 b w Performance
http://slidepdf.com/reader/full/b-w-performance 2/27
Best-Practice DocumentMonitoring for BW Data Staging
© 2011 SAP AG page 2/27
Table of Content
1 Management Summary 3
1.1 Goal of Using This Service 3
1.2 Alternative Practices 3
1.3 Staff and Skills Requirements 3
1.4 System Requirements 3
1.5 Duration and Timing 3
2 Best-Practice Document 4
2.1 Preliminary Tasks 4
2.2 Procedure 4
2.2.1 Monitor Data Staging 4
2.2.2 Performance 14
2.2.3 Data Management 16 2.2.4 Data Consistency 23
3 Further Information 25
3.1 Overview about jobs and tasks 25
8/12/2019 b w Performance
http://slidepdf.com/reader/full/b-w-performance 3/27
Best-Practice DocumentMonitoring for BW Data Staging
© 2011 SAP AG page 3/27
1 Management Summary
1.1 Goal of Using This ServiceUse this service to obtain the correct procedures for monitoring your BW system in the area of data staging,uploads and process chains.
1.2 Alternative Practices
You can get SAP experts to deliver this Best Practice if you order the Solution Management Optimization
(SMO) service “System Administration Workshop” in the scope of a MaxAttention or Safeguarding Support
engagement.
1.3 Staff and Skills Requirements
For optimal benefit you should make sure that you have experience in the following areas:
Knowledge of standard SAP application and database monitors
Practical experience with the SAP BW Data Warehousing Workbench
Experience with monitoring of data uploads
Experience in job scheduling in an SAP environment
1.4 System Requirements
This document refers to SAP NetWeaver 7.x BW systems.
1.5 Duration and Timing
Monitoring tasks have to be performed in a BW system on an ongoing basis. The time required for the
monitoring tasks depends on the objects being used and the data volume being loaded.
8/12/2019 b w Performance
http://slidepdf.com/reader/full/b-w-performance 4/27
Best-Practice DocumentMonitoring for BW Data Staging
© 2011 SAP AG page 4/27
2 Best-Practice Document
2.1 Preliminary Tasks
Before performing this best-practice document, ensure that you perform the following preliminary tasks or
checks in the system:
Read this Best Practice completely before any given recommendations are implemented
We strongly advise against direct changes in the production environment, and recommend first testing any
changes in a test system.
2.2 Procedure
2.2.1 Monitor Data Staging
Frequency: Daily
Please evaluate the monitoring strategy for the production BW system. If there are reports or data which need
to be available at a certain agreed time, then the upload process for this data needs to be analyzed and it
should be decided if it is necessary to monitor the jobs during the night or at the weekend.
Uploads and reports should be assigned a business priority status. Then a monitoring strategy appropriate to
the priority can be defined. For example, a high priority report could be the “Daily Logistics Report”. A priority
period could be the period end closing.
When the monitoring is performed in the morning one hour before the query users start working, this strategy
is cost effective and often sufficient for many uploads. However, this may cause severe delays in data and
report availability if priority uploads need to be restarted. In the case of failed extractions it can also mean that
when the extraction processes are restarted in the morning it causes an extra load on the source system
during online working hours.
A successful BW monitoring strategy requires close co-operation between both application and basis teams.
In BW, in comparison to SAP ERP, these two areas of expertise are more closely linked and the teams are
interdependent. As BW uploads involve extractions in other systems, it is also necessary to ensure that
communication and monitoring is as seamless as possible between the BW and source system teams.
If the monitoring will be performed by Basis individuals, then further training in BW will be necessary or vice-
versa. Close co-operation could mean assigning priority to certain BW jobs and documentation which details
the correct course of action and contact people if the job were to fail.
Automation methods include adding notification processes (available as standard) to critical Process Chains.
Most important BW Monitors are accessible via a central point of entry in the Data Warehousing Workbench
(transaction RSA1) – Administration – Monitors:
8/12/2019 b w Performance
http://slidepdf.com/reader/full/b-w-performance 5/27
Best-Practice DocumentMonitoring for BW Data Staging
© 2011 SAP AG page 5/27
The monitor “BI CCMS” is discussed in detail in the Best Practice Document “Monitoring for BW Basis (ABAP
and Java)”, the monitors “BW Accelerator”, “Precalculation Server” and “Aggregates” are discussed in detail
in the Best Practice Document “Monitoring for BW Reporting”.
The following monitors and tools are important for Data Staging, dependent on your specific scenario to
monitor:
2.2.1.1 Workload Monitor ST03
8/12/2019 b w Performance
http://slidepdf.com/reader/full/b-w-performance 6/27
Best-Practice DocumentMonitoring for BW Data Staging
© 2011 SAP AG page 6/27
The workload monitor in transaction ST03 is useful for general and BW specific performance overviews.
In transaction ST03, chose “expert mode”, “BI Workload” and “Load data”. The BW upload part of transaction
ST03 gives an overview for the different uploads (InfoPackage or DTP uploads) and process chains. The
most important performance indicators for the upload like runtime and data volume are summarized here.
The different stages of the upload process, like source system extraction or transformations, are visible and
possible bottlenecks can be identified here.
2.2.1.2 Process Chain Monitor
For the application-side analysis of the processes executed via process chain you can use the Process Chain
Monitor that is included in the the Data Warehousing Workbench – Administration – Monitors – Process
Chains. Here you have an overview about the progress of your process chains and which process chains are
running at the moment:
8/12/2019 b w Performance
http://slidepdf.com/reader/full/b-w-performance 7/27
Best-Practice DocumentMonitoring for BW Data Staging
© 2011 SAP AG page 7/27
By double-clicking on a certain process chain, you jump to transaction RSPC and see an overview about theprogress of the processes of this chain and the process steps executed so far for each process. From here
you can jump to more detailed monitors of single processes (Upload Monitor, transaction RSMO, Application
Log, transaction SLG1) or to the job log of the processes (transaction SM37).
2.2.1.3 BW Job Overview in RSM37
The BW job overview in transaction RSM37 eases the administration of background jobs “behind“ BW
Process Chains and other BW Jobs through transparency on the involved objects. Transaction RSM37 allows
you to display background jobs and their BW context (depending on the BW Job):
Process Chain / Process Variant DTP / InfoPackage
InfoSource / DataSource
Request ID
In this example, the administrator would like to get an overview on all process chain jobs finished, cancelled
or still active on June 5th 2008:
This selection leads to the following output list:
8/12/2019 b w Performance
http://slidepdf.com/reader/full/b-w-performance 8/27
Best-Practice DocumentMonitoring for BW Data Staging
© 2011 SAP AG page 8/27
The above output list has to be customized to only show jobs belonging to process chains. Change the layout
and filter on the selection value “chain”:
8/12/2019 b w Performance
http://slidepdf.com/reader/full/b-w-performance 9/27
Best-Practice DocumentMonitoring for BW Data Staging
© 2011 SAP AG page 9/27
The BW job overview in transaction RSM37 is available with SAP NetWeaver 7.0 BW Support Package
(ABAP) 13 = SAP NetWeaver 7.0 Support Package Stack 12. Please see SAP Note “1035318: No overview
of jobs and their program variants”.
2.2.1.4 Upload Monitor
To have an overview about all upload processes running on your BW system, you should use the Upload
Monitor (Data Warehousing Workbench – Administration – Monitors – Load Data). In the detail-monitor of
each request (upload process) the progress of this upload and the single process steps are shown. The
Upload Monitor provides all necessary information on times spent in different processes during the load (for
example, extraction time, transfer, posting to PSA, processing transformations, writing to fact tables).
If you encounter upload performance problems, try to identify within the upload monitor where the problem
resides (for example, transformations):
If the extraction from a SAP source system consumes significant time, use the extractor checker(transaction RSA3) in the source system for further analysis.
If the PSA upload times are unacceptable, check the system for I/O contention because of the highnumber of writes ( disk layout and striping, DB I/O) and the PSA partitioning configuration.
If the upload bottleneck resides in transformations, please review your coding regarding performanceproblems. You can use the debug feature in the monitor, SQL trace (transaction ST05) or ABAPperformance trace (transaction SE30).
If a monitoring during an upload is possible, transaction SM50 can be used to view the running processes.
2.2.1.4.1 Decision Tree Upload Performance
8/12/2019 b w Performance
http://slidepdf.com/reader/full/b-w-performance 10/27
Best-Practice DocumentMonitoring for BW Data Staging
© 2011 SAP AG page 10/27
Transaction
RSMO or RSRQ
Slow
Extraction
=>Source system
Transaction RSA3
…
Slow
Transformation
Indexes dropped?
Size of dimension tables
DB parameterization
Customer exit?Hardware bottleneck?
Simulate update
N
N
Y
Y
YDB Access?
PSA/
Cube
Transaction
ST03
2.2.1.5 Change Run Monitor
For problems with change runs you can use the Change Run Monitor (Data Warehousing Workbench –
Administration – Monitors – Change Run). The Change Run Monitor displays all characteristics that are
involved in the current change run. It also provides a list of InfoCubes and their associated aggregates that
have already been adjusted as well as those aggregates that still have to be adjusted by the change run. The
change method, or the way in which the aggregate data is modified, is also displayed. There are three
change methods: Delta, Delta Rollup and Reconstruction.
8/12/2019 b w Performance
http://slidepdf.com/reader/full/b-w-performance 11/27
Best-Practice DocumentMonitoring for BW Data Staging
© 2011 SAP AG page 11/27
2.2.1.5.1 Decision Tree Change Run Monitoring
8/12/2019 b w Performance
http://slidepdf.com/reader/full/b-w-performance 12/27
Best-Practice DocumentMonitoring for BW Data Staging
© 2011 SAP AG page 12/27
Identify long running
change runs in your processchains
Many/large
Aggregates processed?
Check the DB settings,
indexes, no. of
partitions,
etc.
Bad DB
performance?
N
Y
Y
Check Application log
(SLG1) and job log (SM37)
to identify the critical part
Review youraggregate design
Change run mode
(R, D) reasonable? N Check DELTALIMIT
setting
N
2.2.1.6 Real-Time Data Acquisition
For problems with Real-Time Data Acquisition (RDA) you can use the Monitor for Real-Time Data Acquisition
(Data Warehousing Workbench – Administration – Monitors – Real-Time Data Acquisition). Here you see all
daemons that control RDA runs and their current status: Active or inactive. For each daemon you can see
which InfoPackage, Data Transfer Process and Data Target belongs to it and in which periodicity the data is
fetched. You can also see when the last upload happened and how many records the last upload and the
currently open request contains.
8/12/2019 b w Performance
http://slidepdf.com/reader/full/b-w-performance 13/27
Best-Practice DocumentMonitoring for BW Data Staging
© 2011 SAP AG page 13/27
2.2.1.7 Open Hub Monitor
In SAP NetWeaver 7.x BW systems, Open Hub can be set up as a Data Target for Data Transfer Processes,
where the monitoring is fully integrated with the normal upload monitors.
Open Hub processing via InfoSpokes is obsolete from SAP NetWeaver 7.30 BW systems onwards. In SAP
NetWeaver 7.0 BW systems, Open Hubs that are still being processed via InfoSpokes can be monitored via
the Open Hub Monitor (transaction RSBMO2).
2.2.1.8 DataStore Objects Overview
The Status Overview of DataStore Objects can be accessed via the Data Warehousing Workbench –
Administration – Monitors – DataStore Objects. It provides an overview about the loading and activation
status of the last request to be loaded into each DataStore Object:
2.2.1.9 BW Delta Queue Maintenance
The BW Delta Queue can be monitored with the BW Delta Queue Maintenance (transaction RSA7). The BW
Delta Queue for the BW system itself can be accessed via the Data Warehousing Workbench –
Administration – Monitors – BW Delta Queue. However please note that this link does not include the BW
Delta Queues in the connected source systems. The BW Delta Queues for the source systems have to be
accessed directly via transaction RSA7 in each source system.
It is especially important to monitor these queues before release or Support Package upgrades to ensure the
BW Delta Queues are empty.
8/12/2019 b w Performance
http://slidepdf.com/reader/full/b-w-performance 14/27
Best-Practice DocumentMonitoring for BW Data Staging
© 2011 SAP AG page 14/27
2.2.2 Performance
2.2.2.1 Compression
Frequency: Daily
InfoCubes should be compressed regularly. Uncompressed cubes increase the data volume and have a
negative effect on query and aggregate build performance. If too many uncompressed requests are allowed
to build up in an InfoCube, this can eventually cause unpredictable and severe performance problems.
Basically the F-fact table is optimized for writing (upload) and the E-fact table is optimized for reading
(queries).
A well run and high performing BW system is not possible unless there is a regular compression of InfoCubes
and aggregates. A regular compression strategy should be defined with the business data owners. In line
with the requirements of the business process, data in the F-fact table should be compressed regularly. For
more information refer to the documentation in the SAP Help Portal:
Technical description
During the upload of data, a full request will always be inserted into the F-fact table. Each request gets its
own request ID and partition (DB dependent), which is contained in the 'package' dimension. This feature
enables you, for example, to delete a request from the F-fact table after the upload. However, this may result
in several entries in the fact table with the same values for all characteristics except the request ID. This will
increase the size of the fact table and the number of partitions (DB dependent) will unnecessarily decrease
the performance of your queries. During compression these records are summarized to one entry with the
request ID '0'. Note that once the data has been compressed some functions are no longer available for this
data (for example, it is not possible to delete the data for a specific request ID).
Real-time InfoCubes in a Planning environment
You should compress your InfoCubes regularly, especially the real-time InfoCubes. In a planning process a
request is closed when the open request contains 50,000 records or when it is switched manually between
loading and planning mode.
For Real-time InfoCubes that are used for planning there is another advantage through compression (on
ORACLE databases). The F-fact table has a B-tree index and is partitioned according to request ID, whereasthe E-fact table has a bitmap index and partitioning according to your settings (time characteristics). Read
accesses to the E-fact table are faster than those to the F-fact table because B-tree indices are favorable for
data write processes but not for read processes. Please check SAP Note 217397 for details.
The planning function “Delete” is used to remove data from the selected planning package. The records are
not directly deleted from the InfoCube. Instead, the system creates additional records with offsetting values.
The original and offsetting record are deleted when the InfoCube is compressed.
2.2.2.2 Report SAP_INFOCUBE_DESIGNS
Frequency: Monthly
8/12/2019 b w Performance
http://slidepdf.com/reader/full/b-w-performance 15/27
Best-Practice DocumentMonitoring for BW Data Staging
© 2011 SAP AG page 15/27
Running the report SAP_INFOCUBE_DESIGNS shows the database tables of an InfoCube, the number of
records in these tables and the ratio of the dimension table size to the Fact table size. If dimension tables are
too large then they can cause badly performing table joins on database level. Because the data volume
grows and the data allocation changes over the time, this check should be executed regularly.
When loading transaction data IDs have to be generated in the dimension table for the entries. If you do have
a large dimension this number range operation can negatively affect performance.
In the InfoCube star schema, a dimension table can be omitted if the InfoObject is defined as a line item. This
means that SQL-based queries become easier. In many cases, the database optimizer can select better run
schedules.
However, this also has one disadvantage because you cannot include additional characteristics in a
dimension that is marked as a line item at a later date. This is only possible with normal dimensions. If a
dimension table has more than one characteristic with a high granularity then consider placing these
characteristics into separate dimension tables.
Example:
A line item is an InfoObject, for example an order number, where one or a few facts in the fact table of the
InfoCube are listed.
Guidelines How to Limit the Number of Records in Dimension Tables
1. If an InfoObject has almost as many distinct values as there are entries in the fact table, define the
dimension of the InfoObject as a line item dimension. If defined in this manner, the system will write the data
directly to the fact table (a field with the data element RSSID, which immediately shows the SID table of the
InfoObject, is written in the fact table) instead of creating a dimension table that has almost as many entries
as the fact table.
2. Only group related characteristics into one dimension. Unrelated characteristics can use too much disk
space and cause performance problems (for example, 10,000 customers and 10,000 materials may result in
100,000,000 records).
3. Avoid characteristics with a high granularity meaning many distinct entries compared with the number of
entries in the fact table.
4. If you cannot avoid characteristics with a high granularity and most of your queries do not use thesecharacteristics, create an aggregate that stores summarized information. Do not use characteristics with a
high granularity in this aggregate.
Please note that the line item flag can have a negative performance impact on F4 help usage for which the
setting 'Only Values in InfoProvider' is used (transaction RSD1 Tab 'Business Explorer').
5. It is also worthwhile to try the checks in transaction RSRV. Use for example RSRV All Elementary Tests
Transaction Data Entries Not Used in the Dimension of an InfoCube.
Implementation
When creating the dimensions as part of InfoCube maintenance, flag the relevant dimension as a line item.You can assign this dimension to exactly one InfoObject. To check which InfoObject has the highest
cardinality in the dimension, you can look at the fields of the dimension table highlighted in report
8/12/2019 b w Performance
http://slidepdf.com/reader/full/b-w-performance 16/27
Best-Practice DocumentMonitoring for BW Data Staging
© 2011 SAP AG page 16/27
SAP_INFOCUBE_DESIGNS. For example, Transaction DB02 => Detailed Analysis (Tables and Indexes
section) => Enter dimension table name => Check for the field with the most distinct objects.
The table below shows as an example a list of InfoCubes with large dimension tables:
INFOCUBEDIMENSION TABLE NO OF ROWS IN
DIMENSION
% ENTRIES IN DIMS COMPARED TO
F-TABLE
YCCA_C11 /BIC/DYCCA_C114 1.796.665 32
YCS_C01 /BIC/DYCS_C011 855.039 53
2.2.3 Data Management
2.2.3.1 Archive Data
Frequency: Depending on the retention period of your data.
Without archiving, unused data is stored in the database and DataStore objects and InfoCubes can grow
unrestricted. This can lead to a deterioration of general performance.
Establish a BW data archiving project to identify InfoCube and DataStore objects that can be archived. Data
storage also needs to be planned and estimated to determine data storage requirements and the cost
involved. The benefits of BW archiving include:
Reduction of online disk storage
Improvement in BW query performance
Increased data availability as rollup, change runs and backup times will be shorter
Reduced hardware consumption during loading and queries
An archiving strategy should include the following points and tasks:
Periodical archiving of objects
Estimation of required data storage
Identification of InfoCube and DataStore objects that can be archived
Mapping of Data targets to archiving objects
Validation of archived data
Read capability from archived data
Retention period of archived and deleted data
Time to adjust or rebuild aggregates
Timings for locking the data target whilst deletion is taking place.
For more information refer to the SAP Notes 643541 and 653393.
Consider the usage of Near Line Storage. Near Line Storage is recommended for data that you may still
need. Storing historical data in Near Line Storage reduces the data volume of InfoProviders; however, the
data is still available for queries. As Near Line Storage is a third party tool, it might be necessary to schedule
further periodic jobs for this tool. Further information about Near Line Storage is available in the SAP
Documentation::
http://help.sap.com/ SAP NetWeaver Release SAP NetWeaver by Key Capability Information
8/12/2019 b w Performance
http://slidepdf.com/reader/full/b-w-performance 17/27
Best-Practice DocumentMonitoring for BW Data Staging
© 2011 SAP AG page 17/27
Integration by Key Capability Business Intelligence Data Warehousing Data Warehouse
Management Information Lifecycle Management Data Archiving Process
8/12/2019 b w Performance
http://slidepdf.com/reader/full/b-w-performance 18/27
Best-Practice DocumentMonitoring for BW Data Staging
© 2011 SAP AG page 18/27
2.2.3.2 Delete Persistent Staging Area (PSA) data
Frequency: Weekly
Determine a defined data retention period for data in the PSA tables. This will depend on the type of data
involved and data uploading strategy. As part of this policy, establish a safe method to periodically delete the
data. If the PSA data is not deleted on a regular basis, the PSA tables grow unrestricted. Very large tables
increase the cost of data storage, the downtime for maintenance tasks and the performance of data upload.
Request deletion is integrated in Process Chains.
2.2.3.3 Delete Change Log data
Frequency: Weekly
Please note that only already updated change log requests can be deleted and that after the deletion a
reconstruction of requests for subsequent data targets using the DataStore change log will not be possible.
Change log requests can be deleted via Process Chains:
2.2.3.4 Delete DTP Temporary Storage
Frequency: Weekly
8/12/2019 b w Performance
http://slidepdf.com/reader/full/b-w-performance 19/27
Best-Practice DocumentMonitoring for BW Data Staging
© 2011 SAP AG page 19/27
The Data Transfer Process (DTP) can be set up from the temporary storage in case of a problem. You can
view and verify the data in the temporary storage in case of problems.
The deletion of temporary storage can be set from DTP Maintenance Goto Settings for DTP Temporary
Storage Delete Temporary Storage:
Here you can choose for each DTP:
For which steps you want to have a temporary storage
The level of detail for the temporary storage
8/12/2019 b w Performance
http://slidepdf.com/reader/full/b-w-performance 20/27
Best-Practice DocumentMonitoring for BW Data Staging
© 2011 SAP AG page 20/27
The retention time of the temporary storage.
2.2.3.5 Archive / Delete Administration Tables
Frequency: Weekly
SAP Note 706478 (and the referenced sub notes) provides an overview of administrative basis tables that
may considerably increase in size and cause problems if the entries are not regularly archived or deleted.
Growing administration tables increase the total size of the system and negatively impact performance, for
example during monitoring the requests.
Affected tables are (among others):
Application Log Tables (BAL*)
IDoc Tables (EDI*) BW Monitoring Tables for requests and process chains
Job Tables (TBTCO, TBTCP)
Archive or delete entries in these tables as described in the SAP Note.
2.2.3.6 Delete BW Statistic Tables
Frequency: Quarterly
The BW statistic tables RSDDSTAT* and the planning statistic tables UPC_STATISTIC* have to be deleted
regularly.
Please follow the SAP Notes 211940, 195157, 179046 and 366869 before deleting or archiving.
For the BW statistic tables RSDDSTAT*, the deletion of records older than x days can be done in transaction
RSA1. To delete data, call transaction RSA1, choose 'Tools' 'Settings for BW Statistics’ and select 'Delete
Statistical Data':
8/12/2019 b w Performance
http://slidepdf.com/reader/full/b-w-performance 21/27
Best-Practice DocumentMonitoring for BW Data Staging
© 2011 SAP AG page 21/27
The time period for data which should be deleted can now be entered. Please read SAP Note 309955 for
information on usage and errors in the BW Statistics.
For the BPS statistic tables UPC_STATISTIC*, the deletion of records older than x days can be done in
transaction BPS_STAT0:
8/12/2019 b w Performance
http://slidepdf.com/reader/full/b-w-performance 22/27
Best-Practice DocumentMonitoring for BW Data Staging
© 2011 SAP AG page 22/27
2.2.3.7 Delete tRFC Queues
Frequency: Weekly
In BW and all connected source systems, check all outbound tRFC queues (transaction SM58) from time to
time to see whether they contain old unsent data packages or Info-IDocs. The reason for these leftover
entries could be that they have already been processed in BW and therefore cannot be processed again or
they contain old requests that cannot be sent following the system copy or RFC connection change.
You should then delete these tRFC requests from the queue, not only to reduce the data volume in your
system but primarily to prevent you from accidentally sending these old entries again to BW data targets:
In the RFC destination (transaction SM59) from the source system to BW, the connection should be set up to
prevent a terminated transfer from being restarted automatically and, most importantly, to prevent periodic
automatic activation of incorrectly sent data:
8/12/2019 b w Performance
http://slidepdf.com/reader/full/b-w-performance 23/27
Best-Practice DocumentMonitoring for BW Data Staging
© 2011 SAP AG page 23/27
2.2.4 Data Consistency
2.2.4.1 Schedule RSRV Checks
Frequency: Weekly, important checks daily.
Use transaction RSRV to analyze the important BW objects in the system. This transaction also provides
repair functionality for some tests. These tests only check the intrinsic technical consistency of BW Objects
such as foreign key relations of the underlying tables, missing indexes and so on. They do not analyze any
business logic or semantic correctness of data.
Missing table indexes or inconsistencies in master or transactional data can have a negative impact on your
system performance or lead to missing information in your BW reporting.
You can schedule the tests in RSRV to be run regularly in the background by defining a specific test package
for your core business process and needs. Weekly checking (for example on the weekend) should be
adequate in general, but important checks (for example missing table indexes) could be also performed on a
more frequent basis (daily for example).
Another option is to start these checks based on an event (for example tests are triggered after data loading).
8/12/2019 b w Performance
http://slidepdf.com/reader/full/b-w-performance 24/27
Best-Practice DocumentMonitoring for BW Data Staging
© 2011 SAP AG page 24/27
If you do so, make sure that the application log is checked regularly for the results and the recommended
necessary corrections are made in time.
For further information please read SAP Note 619760 containing the latest news about RSRV checks:
A detailed description of the test information as to whether repair functionality is available in the check. When
the results of the checks are displayed in the application log, you can double click on the message. You will
then see the message again on the right hand side with additional buttons for long texts and details (scroll to
the right side) if applicable.
8/12/2019 b w Performance
http://slidepdf.com/reader/full/b-w-performance 25/27
Best-Practice DocumentMonitoring for BW Data Staging
© 2011 SAP AG page 25/27
3 Further Information
3.1 Overview about jobs and tasks
The table below lists all the jobs and tasks discussed in this Best Practice.
Area Job / Task Frequency
Monitor Data Staging Workload Monitor ST03 Daily
Process Chain Overview Daily
BW Job Overview in RSM37 Daily
Upload Monitor Daily
Change Run Monitor Daily
Real-Time Data Acquisition Daily (when RDA is used)
Open Hub Monitor Daily
DataStore Objects Overview Daily
BW Delta Queue Maintenance Daily
Performance Compression Daily
Report SAP_INFOCUBE_DESIGNS Monthly
Data Management Archive Data Depending on the retention
period of your data.
Delete PSA data Weekly
Delete Change log data Weekly
Delete DTP Temporary Storage Weekly
Archive / Delete Administration Tables Weekly
8/12/2019 b w Performance
http://slidepdf.com/reader/full/b-w-performance 26/27
Best-Practice DocumentMonitoring for BW Data Staging
© 2011 SAP AG page 26/27
Delete BW Statistic Tables Quarterly
Delete tRFC Queues Weekly
Data Consistency Schedule RSRV Checks Weekly, important checks
daily.
8/12/2019 b w Performance
http://slidepdf.com/reader/full/b-w-performance 27/27
Best-Practice DocumentMonitoring for BW Data Staging
© Copyright 2011 SAP AG. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG.
The information contained herein may be changed without prior notice.Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9,iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server,PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes,BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX,Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation.Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporatedin the United States and/or other countries.Oracle is a registered trademark of Oracle Corporation.UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of CitrixSystems, Inc.HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, MassachusettsInstitute of Technology.Java is a registered trademark of Sun Microsystems, Inc.JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented byNetscape.SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, Clear Enterprise, SAP BusinessObjects Explorer and other SAP products andservices mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and othercountries.Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, andother Business Objects products and services mentioned herein as well as their respective logos are trademarks or registeredtrademarks of SAP France in the United States and in other countries. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this documentserves informational purposes only. National product specifications may vary.The information in this document is proprietary to SAP. No part of this document may be reproduced, copied, or transmitted in any formor for any purpose without the express prior written permission of SAP AG.This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This documentcontains only intended strategies, developments, and functionalities of the SAP® product and is not intended to be binding upon SAP toany particular course of business, product strategy, and/or development. Please note that this document is subject to change and may
be changed by SAP at any time without notice.SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of theinformation, text, graphics, links, or other items contained within this material. This document is provided without a warranty of any kind,either express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, or non-infringement.SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages thatmay result from the use of these materials. This limitation shall not apply in cases of intent or gross negligence.The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you mayaccess through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provideany warranty whatsoever relating to third-party Web pages.