Administration

AL11 Display SAP Directories

BD54 Maintain Logical Systems

OSS1 Logon to Online Service System

SALE IMG Application Link Enabling

SARA Archive Management

SCC3 Copy Analysis Log

SCC4 Client Administration

SCC5 Client Delete

SCC7 Client Import Post-Processing

SCC8 Client Export

SCC9 Remote client copy

SCCL Local Client Copy

SCU0 Customizing Cross-System Viewer

SICK Installation Check

SM01 Lock Transactions

SM02 System Messages

SM04 User Overview

SM12 Display and Delete Locks

SM13 Display Update Records

SM14 Update Program Administration

SM21 System Log

SM35 Batch Input Monitoring

SM50 Work Process Overview

SM51 List of SAP Servers

SM56 Number Range Buffer

SM58 Asynchronous RFC Error Log

SM59 RFC Destinations (Display/Maintain)

SM66 System Wide Work Process Overview

SAINT SAP Add-on Installation Tool

SPAM SAP Patch Manager (SPAM)

SPAU Display modified DE objects

SPDD Display modified DDIC objects

ST11 Display Developer Traces

ST22 ABAP/4 Runtime Error Analysis

SU56 Analyze User Buffer Alert Monitoring

AL01 SAP Alert Monitor

AL02 Database alert monitor

AL04 Monitor call distribution

AL05 Monitor current workload

AL16 Local Alert Monitor for Operat.Syst.

AL18 Local File System Monitor

RZ20 CCMS Monitoring Configuration FILE Cross-Client File Names/Paths

RZ04 Maintain Operation Modes and Instances

RZ10 Maintenance of Profile Parameters

RZ11 Profile parameter maintenance

SE93 Maintain Transaction Codes

SM63 Display/Maintain Operating Mode Sets

SPRO Customizing: Initial Screen

SWU3 Consistency check: Customizing Database Administration

DB01 Analyze exclusive lockwaits

DB02 Analyze tables and indexes

DB12 DB Backup Monitor DB13 DBA Planning Calendar

DB15 Data Archiving: Database Tables Jobs

SM36 Define Background Job

SM37 Background Job Overview

SM39 Job Analysis

SM49 Execute External OS commands

SM62 Maintain Events

SM64 Release of an Event

SM65 Background Processing Analysis Tool

SM69 Maintain External OS Commands Monitoring

AL08 Current Active Users

OS01 LAN check with ping

RZ01 Job Scheduling Monitor

RZ03 Presentation, Control SAP Instances

ST01 System Trace

ST02 Setups/Tune Buffers

ST04 Select DB activities

ST05 Performance trace

ST06 Operating System Monitor

ST10 Table call statistics

ST03 Performance, SAP Statistics, Workload

ST07 Application monitor

STAT Local transaction statistics

STUN Performance Monitoring (not available in R/3 4.6x)

Points to consider when Sizing

This sizing questionnaire is designed to collect enough information to allow us to configure and characterize an appropriate SAP Business Information Warehouse (SAP BW) landscape.

1. Customer Information-This includes customer contact information, in case the sizing engineer needs further input to process the sizing. Here we also ask about the number, version and software of OLTP source systems as well as certain operational issues important to the overall system design.

2. Landscape Configuration
     and  DW Design Planning-This section covers all information around the planned system and DW landscape as well as the Data Model design.

3. User Activity and Workload-There are three basic components to size for a SAP BW system:  number of users/processes, query mix and quantity of data stored in the DW.  This section will gather the information necessary to perform this process.

4. Data Quantity-In this section we ask for the amount of data you have planned to store in your DW and the data model you have planned to use.

5. Technical Requirements-Here we gather information regarding certain technical requirements, such as clustering or backup technology, that may influence the sizing of the system.

Only when a new delta has been requested does the source system learn that the previous delta was successfully loaded to the BW System. Then, the LUWs of the previous delta may be confirmed (and also deleted). In the meantime, the LUWs must be kept for a possible delta request repetition. In particular, the number on the overview screen does not change when the first delta was loaded to the BW System

Via the status of the last delta in the BW Request Monitor. If the request is RED, the next load will be of type ‘Repeat’. If you need to repeat the last load for certain reasons, set the request in the monitor to red manually. For the contents of the repeat see Question 14. Delta requests set to red despite of data being already updated lead to duplicate records in a subsequent repeat, if they have not been deleted from the data targets concerned before.

Table TRFCQOUT and ARFCSSTATE: Status READ means that the record was read once either in a delta request or in a repetition of the delta request. However, this does not mean that the record has successfully reached the BW yet. The status READY in the TRFCQOUT and RECORDED in the ARFCSSTATE means that the record has been written into the DeltaQueue and will be loaded into the BW with the next delta request or a repetition of a delta. In any case only the statuses READ, READY and RECORDED in both tables are considered to be valid. The status EXECUTED in TRFCQOUT can occur temporarily. It is set before starting a DeltaExtraction for all records with status READ present at that time. The records with status EXECUTED are usually deleted from the queue in packages within a delta request directly after setting the status before extracting a new delta. If you see such records, it means that either a process which is confirming and deleting records which have been loaded into the BW is successfully running at the moment, or, if the records remain in the table for a longer period of time with status EXECUTED, it is likely that there are problems with deleting the records which have already been successfully been loaded into the BW. In this state, no more deltas are loaded into the BW. Every other status is an indicator for an error or an inconsistency. NOSEND in SMQ1 means nothing (see note 378903).

The value ‘U’ in field ‘NOSEND’ of table TRFCQOUT is discomforting.

Relationship between RSA7 and the qRFC monitor (Transaction SMQ1)?

The qRFC monitor basically displays the same data as RSA7. The internal queue name must be used for selection on the initial screen of the qRFC monitor. This is made up of the prefix ‘BW, the client and the short name of the DataSource. For DataSources whose name is 19 characters long or shorter, the short name corresponds to the name of the DataSource. For DataSources whose name is longer than 19 characters (for delta-capable DataSources only possible as of PlugIn 2001.1) the short name is assigned in table ROOSSHORTN.

In the qRFC monitor you cannot distinguish between repeatable and new LUWs. Moreover, the data of a LUW is displayed in an unstructured manner there.

What is the purpose of function ‘Delete data and meta data in a queue’ in RSA7?

You should act with extreme caution when you use the deletion function in the delta queue. It is comparable to deleting an InitDelta in the BW System and should preferably be executed there. You do not only delete all data of this DataSource for the affected BW System, but also lose the entire information concerning the delta initialization. Then you can only request new deltas after another delta initialization.

When you delete the data, the LUWs kept in the qRFC queue for the corresponding target system are confirmed. Physical deletion only takes place in the qRFC outbound queue if there are no more references to the LUWs.

The deletion function is for example intended for a case where the BW System, from which the delta initialization was originally executed, no longer exists or can no longer be accessed.

Transport Strategy

Transport strategy is developed to answer the questions as below:

·         What is my system landscape?

·         How many different projects are working on that system?

·         How complex are my scenarios?

·         Who is responsible for transports / development classes (central,

·         decentral)?

·         Which kind of system (development, consolidation, production)?

·         How can the transport of BEx objects be organized?

In a standard three system landscape one development class may be sufficient, transport using object collector. In a complex landscape different objects might have to be transported to different system (different development classes, transport layers). There are typically some common objects that need to be transported to all systems and some specific ones.

Number of Projects in a system

Basically the system landscape considerations also apply for projects. You have to distinguish between common objects and project specific ones. You may want to be prepared to split up into different systems later on (e.g.for performance reasons).

Complexity of Scenarios

In very complex scenarios dependencies of objects can also be complex. Activating automatic transport connection ensures that no objects are forgotten but the order of the imports is then very important. The object collector helps you find the dependent objects but transport requests may contain many objects. In case of problems split up transports (into parts of the data flow).

Responsibility

If you have complex scenarios / system landscape / several projects organizing transport may be a crucial issue. Central management may be necessary to decide. Which object is assigned to which development class, which objects are collected in one transport request, in which order and when do the transports take place.

Type of Systems

The above considerations are focussed mainly on development systems, you may want to create some objects in the consolidation system in exceptional cases. Activation of automatic transport connection for keeping track of all such objects / changes may be a good approach

In the productive system you typically don‘t create objects to be transported but e.g. queries (ad hoc reporting). Using default BW setting (no automatic transport connection) is usually the best option (independent of settings in development or consolidation systems).

Transport of BEx Objects

Since BEx Objects (once they are assigned to a transportable development

class) are transported in a special way there are special considerations:

• All changes of BEx objects (in one development class) in a certain period are transported together (unless standard transport system is activated)
• Granularity of development classes for BEx objects is important for flexibility in transports, e.g.
  • On project level
  • On data target level
  • Several ones for each data target
  • One for each query
• Transport management of BEx requests
  • Agreement on when transport request is released
  • Creation of a new one immediately after (or before) releasing the old one

The only way of grouping BEx objects in a transport (after first transport) is by development class. So you have to determine the granularity you need for transporting BEx objects and set up development classes accordingly.

• No changes to BEx objects are possible if:
  • No BEx request exists
  • The old BEx request is released and no new one is created
  • A new BEx request is already assigned but the old one has not been released.