Contents

....................................................................................Error! Bookmark not defined.

Document History ....................................................................................................... 5
· Revision History ........................................................................................... 5
· Approvals ..................................................................................................... 5
· Distribution ................................................................................................... 5
BW Operations Handbook .......................................................................................... 6
· BI ................................................................................................................ 6
· BW Landscape ............................................................................................. 6
· General BW Housekeeping Principles ......................................................... 6
· BW Housekeeping Execution Grouping ....................................................... 6
· Reporting Rationalisation ............................................................................. 7
BASIS Housekeeping ................................................................................................. 7
· Basis Parameters ......................................................................................... 7
· RFC Connection ........................................................................................... 8
· Work Process Distribution ............................................................................ 8
· Missing Indexes or Tables............................................................................ 9
· Reconstruct Oracle Indexes/Space ............................................................ 10
· ABAP Dumps ............................................................................................. 10
· Job Logs..................................................................................................... 10
· TemSe Logs ............................................................................................... 10
· Change Pointers......................................................................................... 11
· Deletion of Roles & Links ........................................................................... 12
· Table Logging............................................................................................. 13
· Transactional RFC (tRFC) .......................................................................... 14
SAP BW Application Housekeeping ......................................................................... 15
· Load Schedule ........................................................................................... 15
· Intermediary Documents (IDocs) ................................................................ 15
· BW Statistics .............................................................................................. 16
· BATCH Logs .............................................................................................. 17
· DTP Error Logs .......................................................................................... 19
· PSA Error logs............................................................................................ 19
· PSA Tables Cleanup .................................................................................. 20
· Process Chain Logs ................................................................................... 21
· SAP BW Temporary Tables ....................................................................... 22
· Security Logs.............................................................................................. 22
 · BW Requests ............................................................................................. 23
· Development Using ABAP ......................................................................... 24
· Bookmarks ................................................................................................. 25
· Trace Files.................................................................................................. 26
· Instance Cleanup ....................................................................................... 26
· Long Running Extractors ............................................................................ 26
Reporting .................................................................................................................. 27
· Reporting Tool Selection ............................................................................ 27
· Use of BWA ................................................................................................ 27
· Complex Crystal Reports ........................................................................... 27
Use of Cyr................................................................................................................. 27
· Use of ERP Standard Reports.................................................................... 27
Volume Management Housekeeping........................................................................ 28
· Lifecyle of Data........................................................................................... 28
· Persistent Staging Area (PSA) ................................................................... 28
· Change Logs .............................................................................................. 28
· Corporate Memory Layer ........................................................................... 29
· Propagation Layer ...................................................................................... 29
· Business Transformation Layer .................................................................. 29
· Reporting Layer .......................................................................................... 29
System Stability ........................................................................................................ 30
Document History

Revision History
Date of this revision:
Revision Summary of Changes Author Changes
Date Marked
18/12/15 Document Created Javaid Awan No

Approvals
This document requires the following approvals:
Name Title Method of signoff Date of Version
Approval
BI Services Manager

Distribution
This document has been distributed to:
Name Title Date of Version
Issue
BW Operations Handbook
The purpose of this document is to provide housekeeping and monitoring tasks for BW (Business
Warehouse) appliance. It is a critical appliance in the Analytics landscape as all design, build and data
loading for reporting is executed within BW. This document is not a training guide on BW, an appendix
has been included to highlight key terms and references in the BW architecture.
This documentation provides a starting point for Project, BAU Support and BI Administrators to
familiarise themselves with the procedures for the optimal operation and use of SAP NetWeaver BW
Business Warehouse. It contains specific information for various housekeeping tasks, and lists the tools
that you can use to perform them. It also refers to documentation required for these tasks.
In this documentation, it is assumed that the system or systems are running, or could at least be started
once. This documentation therefore contains no information about installation. Configuration tasks are
only described if they also occur during running operations.
Technical maintenance and management of BW resides completely within the Data Centre. Even
though BW technical infrastructure is managed by T-Systems, certain tasks must be carried out by the
relevant BAU service organisation or in conjuctions with T-systems depending on the RACI.

BI
BI is a single Instance Enterprise Data Warehouse in BAT. It is based on a Layered Scalable
Architecture (LSA) and includes BWA as an accelerator to increase data availability and reporting
performance. All Info Providers are indexed in BWA and there is a step in the Process chain that will
load the data into BWA

BW Landscape

General BW Housekeeping Principles

The following are general guidelines around BW housekeeping. For details, please refer to sections
documented in this handbook.

· Housekeeping starts during all phases of design and build but is managed by operations

· Housekeeping covers basis, volume management and application management (i.e PSA and
change logs)

· Load schedule and reporting rationalisation is a fundamental part of housekeeping

· LSA is a framework that needs to move towards a more optimal balance within the context of
BAT actual reporting needs and volumes.

· Coding should implement best practise in a consistent way to avoid further housekeeping via
optimistion activities.

BW Housekeeping Execution Grouping

This document will group housekeeping in to the following main groups.
 · Basis

· SAP BW Application

· Reporting

· Volume Management

· System Stability

Reporting Rationalisation
As part of good housekeeping practise, it is essential that the following guidance is adopted by design,
build and operations teams.

· Review reports that are actually used by the business to make decisions rather than ones that
exist

· Review report selection parameters that overlap or have small differences

· Reviw global key figures, rows and colums across reports to avoid overlap

· Do not develop reports that are already available in ERP especially for formatting purposes

· Development of master data reports should be avoided for formatting purpose or data quality
purposes as these are process issues

BASIS Housekeeping
A range of basis activities need to be peformed on a regular basis (subject to BAT
internal alignment) to allow smooth functioning of the basis layer within SAP BW. The
checks should be carried out monthly as a minimum and verified as being correct
during volume testing for each and every technical and functional release.

Basis Parameters
SAP BW is installed with some default parameters during the installation process as
determined by the basis team. These parameters are stored in the profile of the
instance and need to be regularly managed to reflect the performance of the system
that may change as a result of changing usage, design, deployment of technical infra-
structure and volumes. The following parameters need to be reviewed regularly by
basis.

Parameter Current Value

abap/buffersize 7680000
abap/heap_area_total 16800000000
abap/heaplimit 300000000
em/initial_size_MB 28672
j2ee/cpu_count 8
j2ee/phys_memsize 47889
 rsdb/ntab/entrycount 180000
rsdb/ntab/ftabsize 225000
rsdb/obj/buffersize 750000
enque/max_requests 15000

The above are the minimum parameters that need to be managed on a regular basis.

RFC Connection
SAP BW communicated with the ERP or SAP source systems using a remote
functional call (RFC) method on a transactional basis. The RFC connection needs to
be set to load balancing. In addition, the RFC logon group must be set to PUBLIC. The
definition for PUBLIC can be checked using transaction code SMLG.

Work Process Distribution

SAP BW installation has some default values for work proceeses and these need to
be adjusted regularly to allow integration between SAP source systems and withinSAP
BW. The first adjustment should be before the first go-live of a functional release as a
minimum. Subsequent adjustments should be based on the following criteria.

· Number of source systems v application servers

· Load times from SAP ERP
· Number of reporting solutions accessing BW (i.e. BOBJ)
· Lack of parallel processing for data loads
· Non-optimised dependcies in data loads

Work process distribution should be towards dialog processes for extraction and
loading into BW. Application servers need to be dedicated to Business objects and to
ERP proceeses. In addition, the logon groups should be checked for load distribution
across application servers to ensure optimal performance via testing to determine
whether to use an available , best or weighted method (also called round robin
methods). This load distribution can be checked using transaction code SMLG.
Missing Indexes or Tables
Performance in SAP BW is managed using a consistent set of indexes and table
entries. Each time data is loaded, these are updated to ensure improved performance.
It is a mandatory that during the design and build (testing) phase, consideration is given
to process chains that control these updates. However, it is also mandatory to check
this during operations to ensure that changes are correctly reflected in the database.
These can be checked using transaction code DBACOCKPIT under the diagnotics
node.

The check should be performed daily for new deployments and root cause understood.
SAP has issued an OSS note(1820508 - Missing secondary indexes for infocubes in
transaction DB02 > Missing Tables and Indexes) to help with this. These indexes and
missing entries need to be assessed in context of BAT’s load schedule too. For
example, the indexes may just be missing temporarily during load times given the 3
hour load.

Reconstruct Oracle Indexes/Space

See note 332677.

ABAP Dumps
Basis should carry out a weekly checks of ABAP dumps to ensure that all jobs initiated
by SAP BW are executing properly. Job status can be checked using transaction code
ST22. Evey job that has been cancelled or has not finished after the SLA time needs
to be investigated to allow basis parameters to be verified and redetermined.

Job Logs
Use report RSTS0024 to delete job logs that are no longer relevant for application
processing.

TemSe Logs
Use report RSPO1041 to remove spool requests as these are not automatically
removed by SAP.
Schedule this monthly. This will help to remove inconsistencies in temporary sequential
files or spool database.

Change Pointers
SAP generates change pointers for loads. These can be deleted if already processed
or have become obsolete.
Deletion of Roles & Links
Using report RSRLDREL unwanted roles and links between objects can be removed
that would otherwise be stored in cluster VRBINRELATION.
Table Logging
Ensure that unnecessary able logging is removed. This can be done using transactio
SLG2 or report SBAL_DELETE.
This report should be run monthly. If deletion is not needed, then archive these using
archive object BC_SBAL.

Transactional RFC (tRFC)

SAP BW uses tRFC to connect asynchronously to process jobs. Since these are
asynchronous, values ar stored in tables until the job is complete. Issues in tRFC can
show symptoms where process chains are slow or Idocs are not being transferred.
These tRFC need to be monitored daily to ensure the queues are not stuck and any
unwanted enteries are deleted. This can be achieved using transction code SM58.

Upon execution, a list of tRFC and their status can be viewed.

These tRFC queues can be reprocessed, deleted or re-organised using options in the
menu.

SAP BW Application Housekeeping

BW application house keeping is an additional housekeeping group of tasks that need
to be executed. This will help to improve system management and optimisation of BW
resoruces.

Load Schedule
BAT loads data on a 24/7 basis every 3 hours including all master data. Given the level
of layers and volume of data, this needs to be reviewed on a daylight basis rather than
the current approach. This activity should be considered to optimise the continued use
of system resoruces and master data refreshes.

Intermediary Documents (IDocs)

SAP BW uses IDOCs to pull and push data between source system and within BW.
Use of program RSETESTD with a variant within a process chain can help to reduce
unwanted Idocs.
The above snapshot shows that anything older than 3 months needs to be deleted
alond with application lods and transactional RFC entries. To reduce the volumes of
IDocs, the parameter should be set more aggressively to a lower day threshold.

BW Statistics
Each time an event arises for runtime objects, SAP BW records the start and end
times. These statistics are recorded for a range of events such as queries, DTPs, BWA
indexes etc. These in turn can be analysed using SAP BW technical content. Over
time, these tables grow large and take up storage. These statics are written to
RSDDSTAT* or UPC_STATISTIC*, RSDDSTAT_OLAP, RSSDDSTAT_DM,
RSDDSTATWHM, RSDDSTATDTP and RSL_STAT.

To manage the BW statics size, use program RSDDSTAT_DATA_DELETE with a

variant to remove any unwanted BW statistics. BAT would need to provide a
retention period to ensure only relevant data is removed.
The above screen shot shows the variant that deletes statistics greater than 3 months
based on free date selection.

BATCH Logs
SAP BW manages all background messages and parameters using special log tables
held in table RSBATCHDATA. These are needed to control processing of BW events
and should not be held when background jobs have completed or have been
investigated for any issues. It is recommened to remove these logs to ensure table
overflow does not occur . This can be done using transaction code RSBATCH or
program RSBATCH_DEL_MSG_PARM_DTPTEMP.

Using RSBATCH, the following screen is shown.

Using ‘Deletion Selections’ the following screen allows maintenance of retention.

Alternatively, using the program RSBATCH_DEL_MSG_PARM_DTPTEMP gives the

following output.
Here you specify the retention periods and scope of the deletion. Once done, this can
be scheduled. It is recommended that logs greater than 30 days are deleted. BAT can
choose to be reduce this threshold if needed to follow it monitoring capability.

DTP Error Logs

Table RSBERRORLOG contains DTP error logs that occur during each and every
movement of data between source and target objects. These are visible per DTP within
the SAP BW administration and should also be output in every custom transformation
with a business meaning. These logs should be monitored and managed on a weekly
basis after all loads with errors have been processed. This can be done using program
RSBM_ERRORLOG_DELETE.

A retention timeframe can be specified within a variant and executed as part of a batch schedule or
manually. The delete flag needs to be activated to remove from the database.

PSA Error logs

Tables RSERRORLOG and RSERRORHEAD store error logs relating to PSA. PSA
will store errors in its stacks during data load processes for DTP or infopackages. For
example, an error stack in PSA can be created for duplicate keys during loadinfg or
data recovery purpose for missing records.These can take up unnecessary space that
could be deployed more usefully to the reporting layer. Report
RSSM_ERRORLOG_CLEANUP can be used to analyse and delete these error
stacks.
By specifying the parameters, the following is output.

The technical name of the DTP can be determined from request monitoring.

PSA Tables Cleanup

Report RSAR_PSA_CLEANUP_DEFINITION can be used to manage this on a weekly
basis.

A check can be made along with deletion of unused PSA content. This can be
managed using a variant within a batch job.
Process Chain Logs
Report RSPC_INSTANCE_CLEANUP can be used to clear process chain logs that
are no longer needed.

The process chain can be made retention date dependent and can be executed with
a variant.

The output is shown above. These in turn can be removed to clean up the system
using the deletion flag in the variant.

RSPC_LOG_DELETE
SAP BW Temporary Tables
Read OSS note 449891 before running this housekeeping task. Report
SAP_DROP_TMPTABLES

Security Logs
Each time the system is accessed, SAP BW creates logs to allow audit trail to take
place. Given the frequency of report execution during the month and month end, these
log tables grow. The manage authorisation logs, go to transaction code RSECADMIN
and analyse the logs before deletion.
Click on authorisation logs and specify a range of parameters to allow analysis and
deletion.

This will allow a manual deletion and display of logs. One can also use archiving objet
RSEC_CHLOG and RSECPROT to archive logs for security. This will need to be
scheduled via jobs and an archive location needs to be set up.

BW Requests
During request processing, tables RSMON* and RS*DONE are used to process the
status for administration purposes. If the request is not complete, the status of the
request is set accordingly. These statuses along with other data are stored as
administration data that grows over time to allow request queries to take place. This
takes up space in the landscape and needs to be managed. To manage this
information, use the object BWREQARCH to archive the data with transaction code
SARA or using program RSARDISP.

This will allow deletion for those tables that are linked to this object. Follow the normal
archiving principles.

Above screen show the write variant fields that need to be specified as per BAT’s
retention policy for this object.

Development Using ABAP

In BAT, a substantial part of the design requires ABAP code to transform data. Whilst
this is common to allow harmonisation, good development practise needs to be
followed in a consistent way to allow support and error resolution. The following
guidelines should be used as part of housekeeping during design, build and
operations.

· Always check the actual code against development standards

· Always ensure that design team has provide pseudo code to the build team
· Always ensure that build team has documented the actual code against the
pseudo code within code comments and in formal documentation
· Always ensure that code is consistently coded at appropriate points such as
start routines to allow packet processing rather than rule groups etc.
· Always ensure only 1 method of coding standard is used rather than a mixture.
For example, true object oriented only rather than a mix of methods

Absence of the above will make housekeeping and optimisation more challenging
rather than routine. To check for variations, check the dataflow transformations for rule
groups, constants, start routines, end routines and the code contained therein. A strong
recommendation is to get a strong developer to check all code to ensure it is optimally
written as poor code will lead to performance issues and low reusability.

Bookmarks
You can remove entries that are no longer required from the table RSWR_DATA
using the report RSWR_BOOKMARK_DELETE (SAP Note 1419451).

This should be run at least monthly.

Trace Files
Using report RSTT_TRACE_DELETE, any RSTT traces can be deleted.

Removal of traces should be run weekly. Using OSS note 1334342, implement
avoidance of traces that lead to generation of these logs.

Instance Cleanup
Use the report RSPC_INSTANCE_CLEANUP to delete old data from the table
RSPCINSTANCE

This should be run monthly.

Long Running Extractors

One of the simplest house keeping activities is to determine long running exractors
from ERP into BW. It is quite common that the same extractors either take a long time
or do not finish the load requests from ERP. These need to be analysed on a weekly
basis to allow remdial action. Follow
· Check for delta loads where possible in the extractor definition. Avoid high
volume full loads into BW.
· Check for extractors that do not complete regularly. For example, product
costing. If these are not running, it is likely that the business do not actually use
the reports. In this instance, consider switching off the extractor and the
 corresponding data flows and reports.
· Check for ERP enhancements within the extractor. If such enhancements exits,
check the ABAP Code.
All extractors should be reviewed regularly for usage and completion (i.e.
0CO_PC_ACT_10) to see if these are actually needed.

Reporting
One of the core house keeping tasks is to analyse reporting that is carried out in BW
using business objects via BW. At start of projects, it is not uncommon to meet
business demand

Reporting Tool Selection

Use of BWA
Use of BWA is very common with BAT for majority of the reports. In addition, this
seems to be the default position to improve performance. As part of housekeeping, it
is recommend to keep BWA memory usage at 50% of the total. To support, this, BWA
needs to be reviewed monthly as follows.

· Check which reports have the highest usage in terms of access

· Validate the high usage reports against business criticality
· Give priporty to business critical reports
· Generate indexes on those cubes for BWA that have high business criticality
first. Then, allocate the remainder to other reports, if needed.
· Analyse the indexes for report clusters (similar functional needs) and see which
cubes can actually be merged to reduce the number of cubes in use within
BWA.

Essentially, BWA index generation should be minimised via reduction in the load
frequency.

Complex Crystal Reports

Use of Cyr

Use of ERP Standard Reports

As part of the reporting strategy, it is recommended that a reporting decision tree
should be used to use standard ERP reports for all business needs and user audience
(senior management v operational user), where possible. The deployment of these
reports can be grouped together within portal roles if needed to allow a single point of
entry for the end user. As part of design and operational excellence, the following
housekeeping guidelines should be used.
 · Based on business requirements, understand whether there is a standard SAP
ERP report that meets the business need (operational or non-operational).
· Determine whether this business need for reporting around format or complex
joins to create decision support reports. Where it is just mainly format, then use
ERP where possible.

Development of master data reports in SAP BW/ should be avoided as these can, in
general, be found in ERP and are of ‘format’ nature.

Volume Management Housekeeping

BAT uses the LSA framework that distributes data by domain and buckets to allow
processing to take place. An sub-optimal deployment of LSA can lead to high volumes
within the database as it increases data redundancy of the same data in multiple points
of the layer. To ensure, LSA does not become an issue, follow the guideleines below.

Lifecyle of Data
All reporting, and their dataflows, contribute to increase in the size of the database with
creation of logs, statistics, index records, partitions and number of records per object.

· Recovery method for lost data or incorrect data

· System of record
· Reconciliation data flows
· Unused data for decision making
·

Persistent Staging Area (PSA)

In BAT, the data is always loaded to the PSA at time of acquisition. Over years this
has not been managed even though the data is very old. There may be a need to
recover data but this can be managed through active monitoring of loads and
correcting errors within the retention period for PSA. The PSA should be kept close to
7 days retention as possible unless there are specific business critical issues identified.
The deletion of PSA can be schedule as part of the load schedule or managed
manually.

Change Logs
Given the numbr of standard DSOs in BAT, the change logs allow the before and after
image comparison during th load process. The volumes have built up over time with
little value to the business as this is primarily a technical requirement of design. It is
suggested that this be deleted as part of a scheduled job to ensure technical
persistency decreases within the Oracle DB. Remov change logs that are older than 1
month to manage data volumes. To do this follow the guidelines below.

· Source Data Lifecycle

The lifecycle of the data is related to the business object in the system of record
rather than BW. This means that ensuring change logs relate to life of a given
 transaction is important. For example, accounting objects do not have logn
lifecycle compared to purchase orders around commitments.

· Recovery Process

The recovery of data is often sited as a reason to keep change logs. However,
the change logs only relate befor and after image in areas of transformation and
delta management within BW. Given the lifecycle of data and specific
identification of values that require recovery, it is advisded that a manual
recovery would be sufficient rather than long residence of change logs.

· DSO Type

The standard DSO is primarily used to generate change logs. Use of this object
should be limited. However, if used as part of design, lifecycle and recovery
process guideliens should be used to remove change data.

Corporate Memory Layer

Currently the size of this layer is 9.5 TB. This can be removed or keep minimal
snapshots for recovery or new enhancements.

Propagation Layer
Currently, the size of this layer is 12TB. This can be removed or kept to a minimal level
for recovery of new change requests where any basic transformations take place.

Business Transformation Layer

Currently, the size of this layer is less than 1 TB. Unless this is the reporting layer, this
can b optimized too in size. This would require that each transformational object is
understood for its usage and number of errors in transformation. If these are minimal,
data can be archived or deleted.

Reporting Layer
Currently, the size of this layer is 2.7TB.The primary purpose of this layer is to provide
queries with data that the business needs for reporting. Most of the cubes are line item
enabled and have residenc in BWA as well. It is advised to optimis this layer as follows.

· Carry out a business review on number of years of data that is actually

needed for business decisions on a report by report basis.
· Assess whether line item cubes are actually needed relative to creating
summary cubes
· Review whether all cubes are needed in BWA based on business criticality.
Removal of these cubes from BWA will simplify the BWA usage and index
generation process.
· Use drill down functionality from summary to line item cubes. Summary cubs
with more years of data and line items with 12-18 months of data
 · Reconciled data to ensure removal of line item cubes and objects

System Stability
The primary objective of housekeeping during design, build and operations is to ensure
system stability. System stability needs to be understood and reported on to allow a
sense check based on facts rather than opinions. It is recommened to measure system
stability around business criticality, system integrity and performance.

· Busines Criticality
It is strongly recommended to give priority or operations to business critical
reports and linked dataflows during at least period end or daily activities. Each
report should be given a ranking for measuring system performance and
integrity. A list of all business critical reports (top 20%) should be managed first
followed by the next 30% and then the remaining 50%.

· Performance
o Load Performance. The end to end analysis of the dataflow and the steps
within from the extractor to the final delivery point of the meta chain
needs to be measured and reported.

o Reporting Peformance. Give the wide use of BWA with Crystal reports
and Analysis for office, regular runtime statistics and root cause needs
to be reported based on business criticality.

o Volume Management. This is already covered under volume

management. Suffice to say, lower the volumes, better the performance
and lower the TCO. An agreement with the business needs to be made
to ensure reporting volumes are low as possible.

o Custom ABAP Performance. SP BW in BAT has a substantial amount of

ABAP for transactional and master data reporting. It is strongly
recommended that expert ABAP resources are used rather tha
resources who are part time developers. To this end, a regular review of
all low performing dataflows with custom code should be carried out
based on load performance.

· Integrity
o Techncial reconciliation. Here we measure the number of records match
the source system and the source layer within SAP BW as expected.

o Functional Reconcilation
§ Transactional values match the source system. These should be
carried out for business critical activities only on at least monthly
basis based on optimal selection parameters.
§ Transactional volumes match the source system. These should
be carried out for business critical dataflows
 § Master data matches the source system. Typically, main cause of
errors in reporting is caused by incorrect master data during data
migration into OLTP or transformations within SAP BW.

o Transformational Reconciliation. Any data transformations are carried

out as expected per business reqirements. Statistics should be kept for
number of incidents and service requests where this is not the case by
dataflow. This will help to define recovery processes.

o Archive Reconciliation. The use of warm or cold to ensure delivery and

retrieval from the content server is working as expected for values and
number of records

Use of LSA going forward should now be controlled given the change of
technology and its duplication of data.