bw adjusting settings and monitoring data loads

BW Data Load Process and Settings

Field Services SAP NetWeaver BI

Luc Vanrobays SAP Brasil

© SAP 2008 / Page 3

Disclaimer

This presentation outlines our general product direction and should not be relied on in making a purchase decision. This presentation is not subject to your license agreement or any other agreement with SAP. SAP has no obligation to pursue any course of business outlined in this presentation or to develop or release any functionality mentioned in this presentation. This presentation and SAP's strategy and possible future developments are subject to change and may be changed by SAP at any time for any reason without notice. 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 assumes no responsibility for errors or omissions in this document, except if such damages were caused by SAP intentionally or grossly negligent.

© SAP 2008 / Page 4

I. Monitoring 'Data Package'-Settings related Problems

II. Process Chains Settings

III. DTP and DSO Settings

IV. Multiprovider Hints

V. Monitor Archiving Features

VI. Loading Master Data

VII. Loading Transactional Data

Agenda

Technical Architecture of Source System Data Loads

RSRQSTRequest IDOC

...

DataSAP Source System

BW

RSINFOInfo Status 0 or 5

RSINFOInfo Status 1

Requestreceived

Dataselection

scheduled

Selectionrunning /

No. of records

RSINFOInfo Status 2

RSINFOInfo Status 9

Dataselection

ended

Data Load

DataPack-ages

DataPack-ages

DataPack-ages

Further Analysis in case of

Ressource

problems when extracting data...

Double Check ROIDOCPRMS Settings

If no entry was maintained, the data is transferred with a standard setting of 10.000 kbyte, 1 InfoIdoc for each data packet and 100.000 lines

Check the Transfer Parameter Settings (1) SBIW / ROIDOCPRMS Table

For dataload from SAP R/3 you have to maintain these parameters directly in the SAP R/3 (not in BW!)

For datamart (e.g. export datasource scenarios) you have to maintain these parameters in BW (that one, which is used for extraction)

SBIW General settings maintain control parameters for data transfer

Maintain the Transfer Parameter Settings via SBIW

Please check resource consumption in SAP Source System

Extraction is usually done in single batch process

TRFC with parallel dialog processes


Ressource

problems when extracting data...

Check the Parameter Settings (2) – Infopackages – Overcontrol Standard Settings

NOTE: The Maximum settings can not be overridden !!!

RSA12 > select Infopackage > Shift+F8 (or menu Scheduler)

You can reduce individually in the InfoPackage frequency‘ and ‚max. size‘ for the extraction process

It is not possible to overcontrol max. lines

This report can be used on the SOURCE SYSTEM to change the settings for specific datasources in the table ROOSPRMS, to override ROIDOCPRMS settings

Check the Parameter Settings (3) – Maintenance of ROOSPRMS Table

The ROOSPRMS Table can be maintained via SE38: Report Z_CIGE_BW_MAINTAIN_ROOSPRMS

Important Input Parameters:• DataSource: Name of the Infosource

•DWH System: Data Warehouse (BW) System logical system name

•Source System: Logical System Name of the Source System

•Update mode:F = Transfer of all requested dataD = Transfer of the deltas since the last requestI =Transfer of an opening balance for non-cumulative valuesR =Repetition of the transfer of a data packetC =Initialization of the delta transfer

Delete Record: Delete the Entry from the table

Override the ROIDOCPRMS Settings

Extraction from SAP Source Systems

SAP-BW

SAP SystemHuge tables for extraction

Data-package 3

Data-package 2

Data-package 1

Restricted amount of main memory

Restricted amount of main memory

Typical situation:

Huge extraction (millions of records)

Problem:

•It makes no sense to transfer all data in one step, because of restricted main memory on source and target system

Recommendation:

•Splitting data up in several (small) packages, that can be held in main memory while processing in BW

less memory consumption and parallelism in processing possible.

Splitting of Requests & Parallel processing

Several Requests in parallel Split up large request with selection criteria Split up large file into smaller ones and load in parallel Loading with parallel Infopackages possible for Infocubes and ODS Objects

BW

SAP Source System BTC

Dia Dia Dia. . .

BTC

Dia


Ressourceproblems when extracting data... cfr. How To Automate Data Loads with Recursive IP

Use Selection Criteria

'Huge' Data Loads: Split your load in smaller load jobs

Initial Load in Overall (1)

1. At the pre-determined cutover point, take a copy of your source system to a "cutover" client.

2. Run an initialization for delta (without data transfer) from your source system. This will create the delta queue in the R3 system so that delta activity will be accumulated. Users can now resume normal production activity.

3. Run your set up jobs for the initial load from the "cutover" client. Although the jobs may take hours/days to run, the users can still be active in the production system because the delta activity is being captured there. Do your intial load from the setup done in the "cutover" client.

4. Schedule periodic delta updates from the production system.

When the inital load still takes too long....

You could...

Initial and Delta Load in Overall (2)

Restrict the data per Infopackage by using selection criteria.

You can apply multiple processes at one time to upload the data in parallel based on

e.g different sales document numbers in the different Infopackages.

To load larger amounts of data into the BW System, you should generally use several parallel data requests with different selection criterias. Here you should group the data appropriately in the InfoPackage by selection.

You might want to create an index based on the selection criteria to enhance reading performance.

Parallelisation

By the usuage of selection criteria

Document # 501-1000

Document # 1-500

Document # 1001-1500

Source System Performance / Load Impact

Memory settings:

BW extractors need a lot of extended memory (depending very strong to the data package size)

Large memory consumption for extraction processes in parallel (= parallel scheduled InfoPackages)

CPU:

Extraction runs with background processes. Extractors running in parallel are able to slowdown the source system.

Extract data in times when there is just less load on the system•Avoid extractions from OLTP during dialog time. At least don‘t extract in dialog time with InfoPackages in parallel.

•Try to extract during ‘off times‘ of the the source system

Golden Rules

Avoid Data Load with large number of Data Packages per Infopackage (Rule of Thumb: one load should contain less than 250 Datapackages)

BUT (depending from your hardware):

Take care on the Max Size of the Data Packages. Reduce the number of parallel processes for Datapackages with large Sizes!

(too large Values and too many processes lead to memory problems, shortdumps)

Split 'huge' Data Loads (e.g. 'Inits') in several smaller Infopackages

Review / Check the Data Package Settings periodicaly

But, if you don’t split data into packages, you: run the risk of one erroneous record forcing the entire package to be rejected

May face the need for large rollback segments.

Rollback segment is space on database containing images of data (“Before-Image”) prior to the current transaction being committed

Situation Observed : System (Load)Performance decrease !!!

Small data packages in large requests often cause lock situations and a severe decrease in performance due to the monitor overhead.

Transaction SM66:'Stopped ENQ'

Observation: Datapackage Processing Runtimes increase during Data Loads

Data Package 4:

I->II: 0:41:23 - 0:40:42 =

41 s

I->III: 0:43:24 - 0:40:42 =

2 min 42 s

Data Package 2033:

I->II: 21:11:32 - 21:05:33 =

5 min 59 s

I->III: 21:23:27 - 21:05:33 =

17 min 44 s

E.g. Compare Update Time for Data Package Nr. 4 vs. Nr. 2033Result: Increasing factor: 6,5 - 8,7 times more than at to begin

Data Package 4

Data Package 2033I II III

How to Check SAP enqueues and wait situations?

How to check Check for SAP enqueues and wait situations:

Monitor the current system wide enqueue’s situation with SM66 or SM50 Run Performance Trace (transaction ST05) with option Enqueue Trace on.

– Display Extended Trace List to see the timestamp for each statement. – Look for

– All exclusive locks and when they are released either explicitly or implicitly at the end of the SAP LUW.

– Calculate the locking time.

Locking prevents parallel processing

SAP enqueue locks means, that processes can block each other

Time

WP1

WP2

WP3

Update record 1 Commit



Wait time

Wait time

SM12 Large DataPackage Nr and Large List of Locks especially on the RSMON* tables

Monitor SM12 regarding: Datapackage with large

numbers

Waiting situations, long locking time for ALL load processes caused especially by the LOAD with large package number !!!

Long list of Locks on the RSMON* tables, due to high administration overhead for some datapackages

How to identify finished Loads with large number of Data Packages ?

se16 - RSMONICDP

Set the filters:• on DP_NR (e.g. '250' for loads with more than 249 DP's)

•TIMESTAMP

rsrq

Review / Check the requests

Check the DTP / Infopackage settings

1

2

5

3

4

Monitor & Detect the critical Dataload Jobs

CANCEL & Restart specific Data Load JobsBUT ONLY, IF the Data is reloadable without Data Loss With NEW adjusted Transfer / Package Settings

Adjust the transfer parameters (e.g. sizes)in the InfoPackage (decrease)via Report Z_CIGE_BW_MAINTAIN_ROOSPRMS (increase or max reset)

Global Settings (via SBIW) - changes should be done ONLY after extended test cases

Monitor & Detect the critical Dataload Jobs

CANCEL & Restart specific Data Load JobsBUT ONLY, IF the Data is reloadable without Data Loss With NEW adjusted Transfer / Package Settings

Adjust the transfer parameters (e.g. sizes)in the InfoPackage (decrease)via Report Z_CIGE_BW_MAINTAIN_ROOSPRMS (increase or max reset)

Global Settings (via SBIW) - changes should be done ONLY after extended test cases

Recommendations for BI Consultants (1)

•Double Check Memory Settings

•Optimal settings depend on the hardware (CPU and RAM) and the system load, too

•Monitor the memory consumption (ST02, SM66) in your system

•Schedule huge data loads carefully taking care on the system load (see slide 15 - ' Source System Performance/Load Impact)

•Avoid ‘Memory Paging’ caused by

•Too many parallel processes

•Too large Package sizes

•Heavy system loads

•Enough physical memory should be accessible & left for other processes

•Deadlocks because of I/O overload due to high number of parralelprocesses and/or competing read/update acesses.

Recommendations for BI Consultants (2)

Most Important ROIDOCPRMS settings

•Max. (kB) (=maximal package size in kB):

When you transfer data into BW, the individual data records are sent in packets of limited size. You can use these parameters to control how large a typical data packet like this is.If no entry was maintained then the data is transferred with a default setting of 10,000 kBytes per data packet. The memory requirement not only depends on the settings of the data packet, but also on the size of the transfer structure and the memory requirement of the relevant extractor.Unit of this value is kB.

•Max. lines (=maximal package size in number of records)With large data packages the memory consumption strongly depends to the number of records which are transfered by one package. Default value for max, lines is 100.000 per data package.Maximal memory consumption per data package is around 2*'Max. lines'*1000 Byte.

Max proc. (=maximal number of dialog workprocesses which were allocated for this dataload for processing extracted data in BW(!))Enter a number larger than 0. The maximum number of parallel processes is set by default at 2. The ideal parameter selection depends on the configuration of the application server, which you use for transferring data.

Recommendations for BW Consultants (3)

•Calculate the size of the Transfer Rules. The information is required for the Data Package Size Calculation

•See ‘Example: How-To Calculate the Transfer Structure Size’ (slide 28) in this presentation for more details

•Communicate & send the information about large (several hundred kBytes) Transfer Structure Sizes to the BW Admin’s

•Hugh Data Loads with Large Transfer Structures should be monitored with special attention

•Split large dataloads in smaller spaces

e.g. do init load with data and several repair IP with selection

Recommendations for BW Consultants (4) – Data Package Settings

NOTE:

•In the InfoPackage setting it is only possible to understeer the control (SBIW-ROIDOCPRMS) parameters

•Contents of table ROOSPRMS overrules the setting of ROIDOCPRMS

•Increasing the packet size will require more memory to be used than if you use smaller packets

•The real package size depends on the data extractor and there are extractors which can't influence the package size. This is not an error or missing functionality, but depends on the structure of the data

Recommendations for BW Consultants (5) – Data Package Settings

NOTE:

•If you load a 50 MB package, than normally the Workprocess processing this package needs 3-5 times more (if you don´t filter records or produce more records in update or transfer rules).

•So if you load 4 times parallel than you need at least 4 times 300 MB of extended memory (each Work-process needs about 300 MB)

•If you load from flat file than the table rsadminc (IDOCPACKSIZE) controls the size of the datapackages. You can change this settings using the transaction 'RSCUSTV6'. This setting can also be overridden by the settings in the ROOSPRMS table

Determination of Datapackage size

'DP size calculated' = Max.(kB) * 1000 \ Transfer structure size

2 cases:

DP size = 'DP size calculated' IF 'DP size calculated' < Max.lines

DP size = Max.lines IF 'DP size calculated' > Max.linesDefaults: Max.(kB) = 10.000 , Max.lines = 100.000 , Details see note 409641

Data Package size is limited by Max. (kB) or Max.lines for most of standard extractors

Data Package size is influenced by Transfer structure size

Facts:

Determination of Datapackage size:

Note: In some applications the Datapackage size is hardcoded and not influenced by the customizing settings in table ROIDOCPRMS. For details see note 417307.

Examples for Package Size Calculation (OSS 409641)

The general formula is: packet size = MAXSIZE * 1000 \ transfer structure size, but not more than MAXLINES.

eg. if MAXLINES < than the result of the formula, MAXLINES size is transferred into BW.

Here are 3 examples of generic data extraction:

My transfer structure size = 250 Bytes

CASE System Settings

MAXSIZE

Settings MAXLINES Calculated Package Size

Decision Criteria Package Size

1 BW

OLTP

-

20000

-

60000

(MAXSIZE(OLTP) * 1000 \ 250)

80000

MAXLINES = 60000 < 80000

60000

2 BW

OLTP

-

20000

-

-

(MAXSIZE(OLTP) * 1000 \ 250)

80000

MAXLINES default value 100000 > 80000

80000

3 BW

OLTP

10000

20000

-

60000

(MAXSIZE(BW) * 1000 \ 250)

40000

MAXLINES = 60000 > 40000

40000

Example for Package Size Calculation

EXAMPLE:

•You want to keep the number of Data Packages equal (or less) 200.

•You need to load: 20.000.000 Records

•The Transfer Structure is 500 Bytes

CALCULATION:

•20.000.000 Records / 200 Data Packages = 100.000 records per package

•Limit MAXLINES: default value 100.000 => OK

•Limit for package Size MAXSIZE = 'packet size' * 'transfer structure size' / 1000

•MAXSIZE = 100.000 * 500 / 1.000 = 50.000

RESULT

The settings MAXSIZE = 50.000 ; MAXLINES = 100.000 would be a good proposal for this load

(Prerequisite: enough memory can be allocated)

© SAP 2008 / Page 32




IV. Monitor Archiving Features

V. Loading Master Data

VI. Loading Transactional Data

Agenda

Process Chain Basics

Process chain is a logical grouping of processes, jobs or steps

Each step is made up of a ‘Process Type’•Process type generally corresponds to a BW activity•Examples of Process types are ‘Load data’, ‘Activate ODS’ etc.

Process types are maintained in table RSPROCESSTYPES•To view process type definition use Tcode RSPC •Click on the menu option –Settings --> Maintain Process Types•Click on the menu option –Settings > Maintain Process Types

•As of SP14 NW BI 7.0, SAP has supplied 47 process types

Process Chain Details

Process Variant An instance of a process type Contains specific values / parameters to execute a process type (step)

To see the technical details of each step (process type’s variant)

Click on menu option ‘View -> Detailed view on’.

Scheduling time System creates a batch job named BI_PROCESS_<PROCESS TYPE’s name>

1. The job listens to a preceding step’s event (except for Start variant)

-The batch job uses the program RSPROCESS

- Process chain name, variant, wait time etc are passed to the program

Enhanced Administration Features - Repairing and Repeating Instances

Resuming Failed Process Types Repeating a process type

Repeat = starting of a job with a new instance new request no.

Former ‘restart‘ function

Repairing a process type Resume the process within the same instance Some processes like the new data transfer

process use this and offer features to repair broken instances.

Code behind the Process Type’s funcionality is usually an Abap OO

Class

Code behind the Process Type’s funcionality is usually an Abap OO

Class

Determines whether a process type sends back success or error message.

Determines whether a process type sends back success or error message.

BI 7.0 Features

Process Chain features

Process status evaluation (*)

Execution User

Copy process chain

New Process Types Decision Between Multiple Alternatives (*) Construct Database Statistics Deletion of Requests from the Change Log(*) Execute Planning Sequence Switch Realtime InfoCube to Plan Mode / Load Mode Close Request of Real-Time InfoPackage Interrupt process Trigger Event Data Change(*) Archive Data from an InfoProvider Check process chain is already active(*) Data Transfer Process

(*) Covered in detail in later sections

Process Chain Settings - Background User

Background User Runs a process chain Scenarios

Special users for loadbalancing

Be able to see which user has scheduled a certain process chain and is in charge of it

Three options BWREMOTE (default) User actually scheduling the

process chain Manually specified user

Enhanced Administration Features - Handling Of Erroneous Processes

Process Status Valuation Scenario

In a meta chain, prevent the whole chain from being stopped due to errors when ‘only‘ unimportant process steps of a sub chain have failed. -> ‘Unimportant’ means, the subsequent process will run even if the previous step is in Error. That is dependency is ‘Always’ or ‘With Errors’.

Valuate processes with errors as successful for the overall chain

They have a succeeding event for treating errors They have a succeeding event that should be

scheduled in any case Mailing and alerting are not influenced by this attribute Select Check Box in subsequent Pop-Up

Is the Previous Run Still Active ?

Scenario Do not start the process chain, if the previous run is still active. From NW BI 7.0 SP14 onwards, Use a new Process type named ‘Is the Previous run in the chain still

active?’. As shown in the figure below, this process type (PC_ACTIVE) can be

found under ‘General Services’.

Is the Previous Run Still Active ? Cont…

How to use this Process type ? Step 1) Drag the process type ‘Is the Previous run in the chain still

active?’ into the Design window Step 2) When you connect this process type to the next step, the

following pop-up appears. Here, select the radio button ‘Successful’. Step 3) Select the line ‘Inactive’ (value 1) as show in the below figure,

and then press the Green check mark button.

Is the Previous Run Still Active ? Cont…

How to use this Process type ? Step 4) Create another process type for action, if the process chain is

already active.An example of this step would be an ABAP to send an email alert

Step 5) Connect the process type ‘Is the Previous run in the chain still active?’ to the process type created in Step 4.

This time, select the option ‘Active’ (value 2). And press green check box. The process chain will look at this at the end of step 5.

Integration to BEx Broadcasting

Scenario and solution How can we execute reports just after finishing the data load? Use the process type ‘Trigger Event Data Change’ in the process chain. While scheduling BEx broadcaster setting, select the option ‘Execute with Data

change in the InfoProvider’. The steps to achieve this are listed below:

Step 1: Include the process type as a step after data load. See below figure.

Integration to BEx Broadcasting Cont…

Solution Continued Step 2: In the variant specify the InfoProvider (Fig 1) Step 3: Select the option ‘Execute with Data change in the InfoProvider’ (Fig 2). Note:If you schedule many broadcast settings based on the data change, it can affect

your system performanceFig 1. Enter InfoProvider in the variant Fig 2. Scheduling Options in BEx broadcaster

Enhanced Administration Features – Polling Flag

The main process waits until other proceses have finished

UseIf the chain contains distributed processes (for example, a loading process) you use this indicator to specify whether you want to hold back the starting background process until the actual work process is complete in other internal sessions, or whether you want to release it immediately.

Setting the indicator has the following advantages:External scheduling tools that react only to the SAP internal event 'Batch Process Complete', are also informed about the status of distributed processes.Very secure process runs. The starting background process asks about the status of the current processes every two minutes (polling).Setting the indicator also has the following disadvantages:Increased demand on resources. Although the CPU is not under pressure during the waiting time, it is during the status checks that run at two minute intervals.You require one more background process.Note:If you implement a distributed process and want to use this indicator, implement the interface IF_RSPC_GET_STATUS and refer to the documentation for the HOLD-Indicator.

The main process waits until other proceses have finished

UseIf the chain contains distributed processes (for example, a loading process) you use this indicator to specify whether you want to hold back the starting background process until the actual work process is complete in other internal sessions, or whether you want to release it immediately.

Setting the indicator has the following advantages:External scheduling tools that react only to the SAP internal event 'Batch Process Complete', are also informed about the status of distributed processes.Very secure process runs. The starting background process asks about the status of the current processes every two minutes (polling).Setting the indicator also has the following disadvantages:Increased demand on resources. Although the CPU is not under pressure during the waiting time, it is during the status checks that run at two minute intervals.You require one more background process.Note:If you implement a distributed process and want to use this indicator, implement the interface IF_RSPC_GET_STATUS and refer to the documentation for the HOLD-Indicator.

Enhanced Administration Features - Handling Of Erroneous Processes

Synchronous execution Scenario: Reduction of process consumption of ‘small’ process chain

Recommended for ‘simple’ upload processes Used for small volumes of data

Process chain is processed synchronously (by occupying one single dialog process) and in serial (loss of internal parallelism)

Protocols to monitor the execution of the chain are still being created

The synchronous execution of process chains can be startedfrom the menu bar.

How To Debug a Process Chain ?

Synchronous execution How can we set up a Break-Point in a process chain ?

Step 1: RSPC, select the process chain. Go in change mode.

Step 2: Select the process type that you want to debug Right mouse click and select ‘Debug Loop’ option Step 3: Enter a wait time greater than 0 seconds. And then, activate

the Process Chain.

Step 2 Step 3

How To Debug a Process Chain ? Cont…

Synchronous execution Step 4: Go to the menu option: Execution -> Execute

Synchronous to Debugging Step 5: The debug screen will now pop-up

Step 4 Step 5

Pop-UpPop-Up

How To stop a Running Process Chain ?

Solution within a Process Chain Develop a program which uses the function module

RSPC_API_CHAIN_INTERRUPT Accept Process Chain as a ‘Select-Option’ variable. Call the function module for selected chain(s) The parameter I_KILL = ‘X’ will terminate data loading processes.

Alternate Solution Using TCode RSPC, select the process chain. Switch to change mode. Go to menu Execution. Then select ‘Remove from schedule’.

Enhanced Administration Features - Synchronous Execution - 2

Synchronous execution Benefits

Fast and slim execution of the processes within the chain

Process2

Starter

Process1 AND1

Process4AND2

Process41

2 3

4 5 6

Runtime

Process2

Starter

Process1

AND

Process4

Design time

Enhanced Administration Features - Check on Batch Process Consumption

Batch Process Consumption Check Scenario

Prevent process chain from consuming more background processes than available ( could lead to locking issues)

Control of parallel background processes When checking the process chain, the number of parallel processes, which would

be used in optimal case, is calculated (also recursively in case of subchains) If it exceeds the number of batch processes available on the chosen server, the

level which exceeds the resources, is marked as warning (Message: Too many parallel Batch processes for Server XYZ. Message No.: RSPC118)

Check OSS note 621400 for more information on the locking problem and the calculation of how many batch processes are needed to run a particular chain

Deadlocks with Process Chains (Oss 621400)

A deadlock occurs in the job processing if the process chain starts a large number of parallel subchains, because an additional background process is briefly required when a subchain is started.Make sure that there are enough background processes in the system.If the minimum requirement cannot be met, we recommend that you adjust the chain to reduce the number of parallel subchains.

o Minimum (with this setting, the chain runs more or less serially):

Number of parallel subchains at the widest part of the chains + 1Subchains that start additional subchains must be exploded for the calculation.

o Optimal (higher similarity):

Number of parallel processes at the widest part of the chain + 1.Every subchain counts here in this formula with the number of parallel processes at its widest point. Example:

---Load process-Load process--AND

Trigger--|--Load process--AND----------Load process

---Subchain---AND------------

# processes: 1P 2P+1U 3P 2P

In this case, you require at least 1U + 1 = 2 batch processes.The optimal setting would assume the subchain has 3 load processes at its widest point:2 (load processes) + 3 (load processes of the subchain) + 1 = 6 load processes.

Enhanced Administration Features - Alerting Within Process Chains – 1

Alerting Trigger SAP alerts from process chains

Use of alert framework Alerts can be collected in alert inbox of the user who scheduled the process chain

(transaction code ALRTINBOX) Set-up

Attribute of process chain Alert Categories

Capabilities An alert is sent for every

process type which endswith an error

A standardized text is sentfor every error with therelevant data

Errors of batch managementare also capturedand alerts are triggered


Alerting with process chainsThe alert category is derived by the system as follows If there is an error in the batch management the standard category

BWAC_PROCESS_CHAIN_FRAMEWORK is used Otherwise the new table RSPC_ALERT_CAT is accessed to find an alert category

for the process which resulted in an error

This table can be used by the customer to assign own alert categories or customer defined classes to customer-specific and also to standard process types. In the second case no modification has to be made. If the ‚No alert‘ flag is set, no message is sent to the user

If there is no relevant entry in this table, the standard alert category AC_PROCESS_CHAIN_ERROR is being used


User assignment

Properties of the alert category

Alerting with process chains Maintenance of alert categories

Alert categories can be maintained in transaction ALRTCATDEF

© SAP 2008 / Page 55







Agenda

DTP DataLoads- Background Processing

Control PARALLEL degree during activation

When you activate requests in an ODS object, the system does not use parallel processes to access the database table to be read (activation queue). This has a negative effect on performance.

With Support Package 14, the parameter for the "number of parallel processes" from transaction RSCUSTA2 is used.

As of Support Package 16, the "ORA_PARALLEL_DEGREE" parameter is read from table RSADMIN (see SAPNote 544521) and used for the table access.

0: DEFAULT (Oracle determines the PARALLEL degree1: no PARALLEL degree2, 3, 4, ... Value of the PARALLEL degree

Problem

Solution

Further information about parallel degree should be found in the reporting performance improvement documentation

DSO Objects – Additional Information

/BI?/A<TECH_NAME>00 for the old and new A-Table

/BI?/A<TECH_NAME>40 for the new U(pdate)-Table which replaces the old M-Table

/BI?/BXXXXXXXX for the old and new Changelog (PSA-Table)

/BI?/A<TECH_NAME>50 will be generated like …40-Table

RSODSACTUPDTYPE Contains the update type

RSODSACTREQ Requests which are loaded to the ODS

RSREQICODS Monitor: Saving of the updated IC and ODS per request

Consistency Check / Repair of generated ODS programs: SAPNote 698576

Important tables

Loading transactional data into ODS objects

active data

Staging Engine

change log

Activation

Req2Req3

Req1

Activation Queue

ReqID, PackID, RecNo

ReqID, PackID, RecNo

Semantic Key(e.g. document

number)

ODS Object Update Details

Upload to Activation queue

Data from different requests are parallel uploaded to the activation queue.

Activation

During activation the data is sorted by the logical key of active data plus activation queue key.

This guarantees the correct sequence of the records and allows inserts only instead of updates.

Before- and After Image is written to the change log.

Request ID in activation queue and change log differ from each other.

After update, the data in the activation queue is deleted.Staging Engine

Activation queue/BI*/A<ODSname>40

Req.ID I Pack.ID I Rec.No

Change log/BI*/B<number>

ODSRx I P 1 I Rec.1I4711I 10ODSRy I P 1 I Rec.1I4711I-10ODSRy I P 1 I Rec.2I4711I+30

Activation

REQU1 I P 1 I Rec.1I4711I 10REQU2 I P 1 I Rec.1I4711I 30

Req2Req3

Req1

Active data/BI*/A<ODSname>00

Doc.No I Value

4711 I 10

4711 I 30

Standard DataStore Object – Activation

Performance Aspects of activation process

Main ProcessFull (sorted) table scan of activation queue

Fetch Packages

Hand over package for SID creation

Store package in cluster

When finished: start parallel processes

Parallel Processes

Read and delete package from cluster

Check active table for existing values

Fill buffer tables for INS/DEL/UPD

Write buffer tables (active table/change log)

Parallel Processes Parallel Processes

..…

Activation: Determine SIDs

ODSobject

SIDs are required for reporting

Checking / Creating SIDs (referential integrity with master data) required with BEx Reporting flag.

This is done at the beginning of the activation

Parallelization per InfoObject (on the same server only)

Only attribute flag no SIDs

Parallel SID determination

Activation With Unique Data Records

Unique Flag means one record only for each key combination

Performance benefits for activation process

No sorting necessary

No reading of existing records from active data

No before image in change log

(Mass) Inserts only

Set unique flag only / always if you are sure there are no duplicates

Active data

Activation queue

Change log

Activation

Settings for Activation – SID – RollBackin tcode RSODSO_SETTINGS

Mass maintenance per Process Typewith tcode RSBATCH

RSBATCH Mass maintenance per Process Type

How to identify chains that use a particular Process Type?

Scenario: Identify the process chains that use process type –OS Command.Solution: Use TCode RSPC2.In RSPC2, enter the process type value (e.g. COMMAND)

Scenario: Identify the process chains that use process type –OS Command.Solution: Use TCode RSPC2.In RSPC2, enter the process type value (e.g. COMMAND)

How can we incorporate decision branches in a Process Chain ?

Scenario Examples: Compression Only if To-Day is Sunday, Update Cube Only If data Exists in DSO Change Log….Solution: Use decision between multiple alternatives•Define a custom formula that returns a value 1, if any data exist in Change log and Use that function in the formula editor of this process variant.

Scenario Examples: Compression Only if To-Day is Sunday, Update Cube Only If data Exists in DSO Change Log….Solution: Use decision between multiple alternatives•Define a custom formula that returns a value 1, if any data exist in Change log and Use that function in the formula editor of this process variant.

Decision Between Multiple Alternatives?

Solution: Maintain Decision variant (Fig 1)While trying to connect the Decision variant to the subsequent step, the a pop-up appears as shown in (Fig 2).

Solution: Maintain Decision variant (Fig 1)While trying to connect the Decision variant to the subsequent step, the a pop-up appears as shown in (Fig 2).

Final OutLook of the Process Chain (Fig 3)Final OutLook of the Process Chain (Fig 3)

Process Chain Log Deletion - Maintenance

Problem:

Process Chain Logs are increasing with time, deterioratingmonitoring response time.

Solution:

Use the Program RSPC_LOG_DELETE to delete old logsDetermining Retention Policy (ex.Three Months)

Note: It may happen that the deletion program deactivate some steps of the process chain it deals with, requiring reativation.

Problem:

Process Chain Logs are increasing with time, deterioratingmonitoring response time.

Solution:

Use the Program RSPC_LOG_DELETE to delete old logsDetermining Retention Policy (ex.Three Months)

Note: It may happen that the deletion program deactivate some steps of the process chain it deals with, requiring reativation.

Process Chain Analysis and Monitoring

Transactions for Monitoring: RSPC to display Process Chains

RSPC1 to display one Process Chain Log at atime

RSPCM

Transactions for Runtime Analysis:

RSPC2

BWCCMS (similar to RSPCM but access in CCMS)

ST13for monitoring and compare response time

Transactions for Monitoring: RSPC to display Process Chains

RSPC1 to display one Process Chain Log at atime

RSPCM

Transactions for Runtime Analysis:

RSPC2

BWCCMS (similar to RSPCM but access in CCMS)

ST13for monitoring and compare response time

Process Chain Monitoring – RSPCM – RSM37

RSPCM - “One Stop Shop” to monitor critical process chain runs:

Requires to select the chains defined as CriticalOptional Step – Add Email Message

RSM37 - “Because SM37 doesn’t give much insight about Process Chain related jobs ” and makes it difficult to relate a background job to its parent Process Chain.

RSPCM - “One Stop Shop” to monitor critical process chain runs:

Requires to select the chains defined as CriticalOptional Step – Add Email Message

RSM37 - “Because SM37 doesn’t give much insight about Process Chain related jobs ” and makes it difficult to relate a background job to its parent Process Chain.

Can also enter a Variant hereCan also enter a Variant here

Enter Variant Value hereEnter Variant Value here

Analysis and Service Tools Launch Pad – ST13

Choose BW-TOOLS or access via Se38 with /SSA/BWT With PC or Process Type Compare Runtime Feature

-Per Process Chain Id-Per Process Type

Choose BW-TOOLS or access via Se38 with /SSA/BWT With PC or Process Type Compare Runtime Feature

-Per Process Chain Id-Per Process Type

Runtime ValueRuntime Value

Process Type Details and RuntimeProcess Type Details and Runtime

Link to Process LogLink to Process Log

Up to 5 PC Selections to Compare Day-to-Day Runtime

Up to 5 PC Selections to Compare Day-to-Day Runtime

Analysis and Service Tools Launch Pad – ST13 Cont…

Analyze Runtime Per Process TypeAnalyze Runtime Per Process Type

Process Type Details and RuntimeProcess Type Details and Runtime

Analysis and Service Tools Launch Pad – ST13 Cont…

Compare Runtime Per Process ChainCompare Runtime Per Process Chain

Maintain Parallel Settings Per Process Type

Scenario: Increase or Decrease Level of Parallelism per process typeAlter Job Class (Priority)Solution: transaction RSBATCH

Scenario: Increase or Decrease Level of Parallelism per process typeAlter Job Class (Priority)Solution: transaction RSBATCH

Batch Management in SAP NetWeaver 2004s

Select process e.g. Initial Fill of Aggregate

Parameter settings:

Number of Processes (BATCH!)

Job class

Host / Server / Server Group (SM61)

These settings are the default settings but can be overcontrolled for each process chain variant (table RSBATCHPARALLEL)

Transaction RSBATCH

Repair a terminated Load -

To repair (partially finished) loads in DIA (above) or in Process ChainsTo repair (partially finished) loads in DIA (above) or in Process Chains

DTP manually repaired

Process failed at 12:51:56, reiniciated at 14:58:02, Successful at 15:00:37Process failed at 12:51:56, reiniciated at 14:58:02, Successful at 15:00:37

DataStore Specific Transactions

RSODSO_SHOWLOG

Shows the log of requests which have been processed in a DataStore object

Detailed information about main process, data packages, runtime behaviour and runtime settings

Log also accessible via manage

screen


RSODSO_BRKPNT

Can be used to set breakpoints in DataStore application logic

Parameters:

USER

Holds only for the specified user

DATASTORE

Holds only for the specified DataStore

BREAKID

Holds at the specified operation

DATA PACKAGE

Holds only for the specified data package (0 means main process)

WAIT TIME IN SECONDS

Time which is spend to wait for debugging request

Report: rssm_sleep_debug

For example: set breakpoint with id “6” to check the runtime of database statements


RSODSO_RUNTIME

Can be used to measure runtime of activation or SID creation for DataStore object

Parameters: USER

– Measurement only for the specified user

CONTEXT – Measurement context (see

screenshot) PARAMETER

START / STOP OF MEASUREMET INTERVAL– Can be used to enable

measurement only for a specific time frame

Activation SID creation

Parameter 1:

Technical name of DataStore object

Technical name of DataStore object

Parameter 2:

Request SID Data package

Parameter 3:

Data package InfoObject name


RSODSO_RUNTIME

Results can be found in table RSODSO_RUNTIME

© SAP 2008 / Page 85




IV. Multiprovider Hint

V. Monitor Archiving Features

VI. Loading Master Data

VII. Loading Transactional Data

Agenda

MultiProvider Hint (1)

86

An entry in RRKMULTIPROVHINT only makes sense if a few attributes of this characteristic (that is, only a few data slices) are affected in the majority of, or

the most important, queries (SAP Notes: 911939. See also: 954889 and 1156681).

Problem: To reduce data volume in each InfoCube, data is partitioned for example by Time period. A query now have to search in all InfoProviders to find the data (i.e. billing docs from 2007). This is very slow.

Solution: We can add “hints” to guide the query execution. In the RRKMULTIPROVHINT table, you can specify one or several characteristics for each MultiProvider which are then used to partition the MultiProvider into BasicCubes.

If a query has restrictions on this characteristic, the OLAP processor is already checked to see which part cubes can return data for the query. The data manager can then completely ignore the remaining cubes.

Problem: To reduce data volume in each InfoCube, data is partitioned for example by Time period. A query now have to search in all InfoProviders to find the data (i.e. billing docs from 2007). This is very slow.

Solution: We can add “hints” to guide the query execution. In the RRKMULTIPROVHINT table, you can specify one or several characteristics for each MultiProvider which are then used to partition the MultiProvider into BasicCubes.

If a query has restrictions on this characteristic, the OLAP processor is already checked to see which part cubes can return data for the query. The data manager can then completely ignore the remaining cubes.

Multiprovider Hint (2)and Logical Partitioning

AA0

Org

TimeMat

Cust

AA1

Org

TimeMat

Cust

AA2

Org

TimeMat

Cust

AA3

Org

TimeMat

Cust

AA4

Org

TimeMat

Cust

AA5

Org

TimeMat

Cust

2AA0

Org

TimeMat

Cust

Query

Partition Info_from Info_To

WC1AA Y5CO1AA0 Y6CO1MC0







YEDW_STEER used for YGTIPROV

Multiprov InfoObject Position

Y6CO1MC0 0CURTYPE 1

Y6CO1MC0 0VTYPE 2

Y6CO1MC0 0FISCPER 3

RRKMULTIPROVHINT

1. Open query. Enter selections. Execute.

2. YGTIPROV provides filter values for 0INFOPROVIDER using YEDW_STEER

3. Read Hints table

4. Dimension tables are read to determine cubes with data for selection

5. Multiprovider execution plan is constructed

Multiprovider Hint (3)

Solution Table RRKMULTIPROVHINT provides aditional fields: POSIT – to suggest the order in which the Analitical Engine reads the

InfoProvider MAXOR – to define for each characteristic how many rows the WHERE

condition may have NOBUFFER – to deactivate metadata MultiProvider definition buffering Restrictions: Valid for Time INDEPENDENT Navigational Attributes (with SID conditions

values only) Interval Restrictions on compounded Attributes cannot be checked Time Dependent Attributes also ignored Note: if data is deleted from InfoProvider, do not forget to delete the

Dimensions Tables as well (RSRV) OSS 1156681 and 1371598 continuously updated.

Request Archiving – 1

Archiving of Request Monitor Data Archive and delete old monitor data Reduces data in operational database Optimizes performance Facilitates administration


Archiving of Request Monitor Data Create Archive File (via ‘File’) and enter a variant name


Archiving of Request Monitor Data Press ‘Create Archive’ Button or Archiving via transaction SARA and archiving object BWREQARCH Tcode AOBJ (archiving Objects)

Loading master data

General rules for Master Data Loads

Buffer number ranges (SNRO)

Switch off Single record buffering in SE12

Upload in parallel (see SAP note 421419)

Cost Base optimizer statistics

Upload in sequence master data, texts, hierarchies

Use delta handling in mySAP ERP

Put in the name of the characteristic and choose object version = A

See field NUMBRANR of E_S_VCHA for number range to buffer.Add ‘BIM’ as a prefix to NUMBRANR.

E_T_ATR_NAV tells you the navigational attributes to your characteristic

Use function module RSD_IOBJ_GET

Number range buffering – Master data

Key Concept – NRIV – SID - DIMID

Number ranges can cause significant overhead when loading large volumes of data as the system repeatedly accesses the number range table NRIV to establish a unique number range. If a large volume of data is waiting for these values, then the data loading process becomes slow.

One way to alleviate this bottleneck is for the system to take a packet of number range values from the table and place them into memory. This way, the system can read many of the new records from memory rather than repeatedly accessing and reading table NRIV. This speeds the data load.

A bottleneck can occur with both master data and transaction data. When the system loads new master data, it establishes a unique system identifier (SID) value to uniquely identify the master data record. By contrast, when the system loads transactional data into an InfoCube, the system must create unique dimension identifiers called DIM values. Like the SID values for master data, these DIM values establish a unique identifier of each transactional data value within the InfoCube dimension. The system gathers the last value from the NRIV table each time it adds an entry into an InfoCube dimension, and these multiple reads to the NRIV table slow large data loads.

You can set number range buffering for either or both the master data (SIDs) and dimension table (DIMs) to increase performance. Number range buffering helps when loading large volumes of data, but adds little if any performance improvement on smaller master and transactional data loads. Typically, you should set it for initial large data loads and turn it off once the load is complete. You can leave buffering on indefinitely if high volume loading occurs for all master or transactional data loads.

Number ranges can cause significant overhead when loading large volumes of data as the system repeatedly accesses the number range table NRIV to establish a unique number range. If a large volume of data is waiting for these values, then the data loading process becomes slow.

One way to alleviate this bottleneck is for the system to take a packet of number range values from the table and place them into memory. This way, the system can read many of the new records from memory rather than repeatedly accessing and reading table NRIV. This speeds the data load.

A bottleneck can occur with both master data and transaction data. When the system loads new master data, it establishes a unique system identifier (SID) value to uniquely identify the master data record. By contrast, when the system loads transactional data into an InfoCube, the system must create unique dimension identifiers called DIM values. Like the SID values for master data, these DIM values establish a unique identifier of each transactional data value within the InfoCube dimension. The system gathers the last value from the NRIV table each time it adds an entry into an InfoCube dimension, and these multiple reads to the NRIV table slow large data loads.

You can set number range buffering for either or both the master data (SIDs) and dimension table (DIMs) to increase performance. Number range buffering helps when loading large volumes of data, but adds little if any performance improvement on smaller master and transactional data loads. Typically, you should set it for initial large data loads and turn it off once the load is complete. You can leave buffering on indefinitely if high volume loading occurs for all master or transactional data loads.

OSS 857998 - Number range buffering for DIM IDs and SIDs

The number range object of a dimension table should be buffered if

a) the DIM table increases by a large number of data records for each request

b) the size of the DIM table levels out but at the beginning you expected or observed a significant increase

c) there are many accesses to the NRIV table with reference to the number range object of the dimension table

d) the InfoCube or the dimension table is deleted regularly and, therefore, the DIM table increases significantly in each period.

The number range object for the SIDs of an InfoObject should be buffered if

e) you regularly add many new data records to the SID table

f) you know before the initial load that there is a lot of master data to be loaded for this InfoObject

g) you delete the master data periodically and you always load many new records (this should be an exception).

How do you find number range objects of the dimensions and SIDs whose number range should be buffered?

h) You know in advance that the dimension table or the SID table will increase significantly per request.

i) You observe accesses to the NRIV table and you can determine the number range object directly in the current SQL statement.

j) A high number range level may indicate that there is a significant increase for these two BW objects (valid only for BID* and BIM* objects)

Find candidates for Number Range Objects Buffering

1. Check if there are already Number range Object defined with buffering

tcode SE 16 > TNRO > with OBJECT like ‘BI*’ and BUFFER = ‘X’

2. Check (pre-productive) if the occurences for each object deserves Buffering

tcode SE 16 > NRIV with OBJECT like ‘BI*’ sorted by NRLEVEL descending consider OBJECT with occurences over 100.000 (for example)

3. Evaluate (early and post-productive) Data Growth for SID and DIMID.

tcode SE38/SM37 scheduling program ZBC_NRIV_LOG at the beginning of BW productive live and subsequently every month or less.

evaluate ODSO for high number of changes

Switch-off single record buffering – SE11

You can change the buffering to not buffered or to fully

buffered, depending how you access the data.-

Additional remark regarding single record buffering

Symptom:

Because of the design of the single record buffer there can be a performance problem during LOAD and READ SI accesses to this table buffer. You can easily find those reads by performing a ST05 buffer trace. In the most cases the problem occurs during the ODS Data Activation for a high volume of data.

Explanation:

The problem is not only the parallel access of the single key buffer. Instead, the problem is the high number of extents for the table within the buffer (e.g. over 50000). Thus, for entries in the highest extents, the access is slow. Accesses to entries that are found in the first extents are always fast - in parallel or serial access.

Normally, the buffer writes at system shutdown file TBXSTAT/TBXNEW into the DATA directory. This file contains the high water marks of all tables that are in the buffer at shutdown time. At buffer instantiation, this file is read. The high water marks are used to calculate proper extent sizes. The idea is that in a "balanced" system always proper extent sizes are taken.

Generally the size of the extents can be reset the following way:

1. Restart the WP1 in transaction SM50

2. Goto Transaction AL12→ choose 'Edit'→ 'Displ./Reorg'→ Single record buffer and reorganize the single record buffer

The Basis development stated that there has been no change in any support packages regarding this behaviour of the single record buffer. The performance issue is however getting worse and worse when the size of the SID table in further increased.

Additional indexes

Requirement:

You would like to load master data for a certain characteristic.

Problem:

Several attributes are not provided by the DataSource, you have to enrich the master data by routines.

Every time you have to read additional information via routines, additional indices on the accessed tables could be helpful.

In combination with transaction ST05 (SQL Trace) you can recognize where indices are missing.

Solution:

Create such indices with transaction SE11.

Depending on the data enrichment during the extraction,additional indices can be helpful on P-,X-,Y-,SID tables or on customer defined tables

Loading transactional data in InfoCubes and Buffering

Put in the name of the InfoCube and choose object version = A

See field NOBJECT of E_T_DIME for number range to buffer.

Use function module RSD_CUBE_GET

How to detect the Number Range Object attached to Dimensions.How to detect the Number Range Object attached to Dimensions.

Appendix –Buffering Tools

REPORT z_c onv _p uff _ta bl.

Te xt Par ame ters

P_ AL L Buffe rin g Allowed ?

P_ FL PUF F Buf feri ng Typ e

P_ OBJNAM Tab le Name

Te xt Symbol s

00 1 Do y ou Re ally Wa nt to Cha ng e Se ttin gs for Bu ffe ring ?

00 2 Setti ng Ch ang es to Buff eri ng can se riou sly impa ir pe rfo rma nce

00 3 Or le ad to data in con sis te nci es

00 4 L OG is AVAILABLE VI A SE3 8 -- > RADPROT A

REPORT z_c onv _p uff _ta bl.

* Upd ate Buf feri ng Ty pe and Re ac tiv ate tab le or v iew !

* Writ e L og DB - De tec t As well DDIC d epe nd enc ies

* I n c ase DDIC Obj ect s a re b uild up on Ta ble Re act iva ted

* T ABLES : d d09 l.

SELECT- OPT IONS: p_o bjn am FOR d d0 9l-t abn ame NO INTERVALS DEFAULT ' /BI 0/PMAT ERIAL' .

PARAMET ERS: p_ flpu ff T YPE p uffe run g DEFAULT '' ,

p_ all TYPE b ufa llo w.

TYPES:

l _ob j_n ame T YPE rs rang e.

DATA : re spo st a T YPE ch ar1 ,

t _ob j_n ame T YPE ST ANDARD TABLE OF l_ob j_ na me,

s _ob j_ na me T YPE l_ obj _n ame,

o bj_ typ e TYPE tb atg -ob jec t VALUE ' TABL',

i d_n ame LIKE dd 12 l-ind ex na me VAL UE '',

f ct T YPE tb atg -fc t,

g use r T YPE dd refs truc -tb at gus er VAL UE ' DDIC' ,

s ubr c T YPE s y-ta bix ,

p rid LIKE sy-s ub rc,

mcid LI KE dd2 3v -mc id,

p rotn ame LIKE ts trf0 1-fil e,

r ealn ame LIKE ts trf0 1-fil e,

p rot_ de v LIKE dd ref stru c-r sd evic e VAL UE ' T',

mode (1 ) VALUE 'N'. " new pro toc ol o r a pp end

DATA : l_ tab typ e TBATG-TABNAME.

INCLUDE rad bto um.

IF p_ flpu ff IS INITI AL.

MOVE 'N' TO p_ all.

ENDIF .

CALL FUNCT ION 'SALP_POP_ CONFIRM_ 4'

EXPORT ING

tex tlin e1 = tex t-0 01




* TEXT LINE5 = ''

numbr_ of_ bu tto ns = '4 '

IMPORTI NG

ans we r = re sp ost a.

IF res po sta = 'J '.

READ T ABL E p _ob jna m I NT O s_ ob j_na me INDEX 1.

DELETE p_ obj nam WHERE low <> s_o bj_ na me .

APPEND s_ obj _na me TO t_ obj_ na me.

* r esp os ta J K N C

PERF ORM e xec ute _al ter _b uff T ABLES t_o bj _n ame USING p_f lpu ff p_a ll.

EL SEIF r esp ost a = 'K'.

LOOP AT p_ ob jnam INTO s_ obj _na me.

APPEND s _ob j_ name T O t _ob j_n ame.

ENDL OOP.

PERF ORM e xec ute _al ter _b uff T ABLES t_o bj _n ame USING p_f lpu ff p_a ll.

EL SEIF r esp ost a = 'C' OR re spo sta = 'N'.

LOOP AT p_ ob jnam.

WRITE:/ 'Alte raç ão na Bu fferi zaç ão da Ta be la ', p_ ob jna m-lo w , 'ca nce la da !'.

ENDL OOP.

ENDIF .

*&----- ----- ------ ----- ---- ----- ----- ----- ------ ----- ---- ----- ----- ----*

*& Fo rm e xe cu te_ alte r_b uff

*&----- ----- ------ ----- ---- ----- ----- ----- ------ ----- ---- ----- ----- ----*

* tex t

*-- ----- ----- ------ ----- ---- ----- ----- ----- ------ ----- ---- ----- ----- ---*

* - ->T _OBJ_NAME t ext

* - ->P_FL PUF F te xt

* - ->P_AL L t ext

*-- ----- ----- ------ ----- ---- ----- ----- ----- ------ ----- ---- ----- ----- ---*

FORM ex ecu te_ alt er_ buf f TABLES t _o bj_ name USING p _fl puf f p_ all .

LOOP AT t_ obj _na me INT O s_o bj_ name.

UPDAT E d d09 l

SET p uffe run g = p_ flp uff buf allo w = p _al l

WHERE ta bna me = s_o bj_ name-l ow.

IF sy- sub rc < > 0.

WRIT E:/ 'Err o no Upda te DDI C ! ', sy -s ubr c, ' ', p _o bjna m- low.

EL SE.

COMMIT WORK.

CALL FUNCT ION 'DD_L OGNPROT _NAME_GET'

EXPORT ING

ta sk = 'CNV' "CNV mea ns SE14 p ro toc ol

si ng le_ or_ mas s = ' S'

ob j_ typ e = obj_ ty pe

on lin e_ put = 'O'

ob j_ na me = s_o bj _n ame -low

in d_ na me = id_ na me

IMPORT ING

pr otn ame = prot na me

* j obn ame =

EXCEPT IONS

in pu t_e rror = 01

OT HERS = 02.

IF sy -su brc = 0 .

log _op en >: p rot _de v mode 1 'se t_s tyl e' p rotn ame ' ' re aln ame pri d.

EL SE.

* D05 10 : Sta nd ard pro tok oll name k on nte nic ht bere ch ne t we rde n

MESSAGE ID ' D0' TYPE 'A' NUMBER '5 10 '.

ENDI F.

smi2 >: p rid ' ' 'GT0 24 ' s _ob j_n ame -lo w o bj_ typ e.

* d ele te view na DB

CL EAR : l_ta b.

MOVE: 'CNV' TO fct , s_ ob j_n ame -low to l_ tab .

* d ele te view na DB

CALL FUNCT ION 'DD_DB_ OPERATION'

EXPORT ING

fc t = fc t

* FORCED = ' '

* id_ na me = ' '

ob j_ na me = l_ ta b

ob j_ typ e = 'T ABL'

p rid = prid

s tat us = 'D'

us er = gus er

IMPORT ING

su br c = sub rc

EXCEPT IONS

un ex pe cte d_e rro r = 0 1

un su pp orte d_ fun ctio n = 0 2

un su pp orte d_ obj _typ e = 0 3

un su pp orte d_ sta tus = 04

OT HERS = 05 .

IF sy -su brc <> 0.

WRITE: / 'Erro r Ac tiv atin g T ab le ! > RADPROTA ', s ub rc, ' ', s_o bj_ na me- low.

sub rc = 1 .

EL SE.

WRITE: / 'Acti vat ion Su cce ss full - L og Dis pon ive l n a SE38 > RADPROTA ', s_o bj_ name- low.

MESSAGE ID ' D0' TYPE 'S' NUMBER '3 26 ' WITH pro tna me .

clo se> : p rid.

ENDI F.

ENDIF .

ENDL OOP.

ENDF ORM. "e xec ut e_a lte r_b uff

*&----- ----- ------ ----- ---- ----- ----- ----- ------ ----- ---- ----- ----- ----*

*& Re por t ZBC_ NRIV_ BUF FERING_DEF AULTS

*&

*&----- ----- ------ ----- ---- ----- ----- ----- ------ ----- ---- ----- ----- ----*

*&

*&

*&----- ----- ------ ----- ---- ----- ----- ----- ------ ----- ---- ----- ----- ----*

REPORT ZBC_NRIV_BUFF ERING_ DEFAULT S.

ta ble s: n riv, tnro .

da ta: lt_ nriv ty pe sta nd ard tab le o f n riv

wi th key

CL IENT OBJ ECT SUBOBJ ECT NRRANGENR TOYEAR,

ls _n riv typ e nr iv,

lt_ tn ro t ype ha sh ed tab le o f T NRO

wi th uni que ke y OBJECT ,

ls _tn ro typ e tn ro.

da ta: bwobje ct1 ty pe /BI C/OIZCGTCNRBW.

da ta: bwobje ct2 ty pe /BI C/OIZCGTCNRBW.

da ta: l_i nde x ty pe i.

pa ramete rs:

p_v alu e t ype i def ault 10 0,

p_s id ty pe tab len ame ,

p_d im ty pe tab len ame ,

p_t est as ch ec kb ox d efa ult 'X' .

pe rfo rm:

se lec t,

fin d_l ink ed_ ob jec ts,

up dat e_t nro,

di spla y_ list.

*************************************************************

* SEL ECT *

* Sele cti ng n umbe r ra nge ob jec ts f rom NRIV *

*************************************************************

fo rm s ele ct.

pe rfo rm mess ag e u sin g 5 'Re trie vin g obj ect s...' .

if p_s id i s in itia l a nd p_ dim is i niti al.

se lec t * f rom nri v i nto tab le l t_nr iv

wh ere ob ject lik e 'BID%' or o bje ct lik e 'BIM%'.

el se.

se lec t * f rom nri v i nto tab le l t_nr iv

wh ere ob ject = p_ sid or o bje ct = p _d im.

en dif .

en dfo rm.

*************************************************************

* F IND_L INKED_OBJECTS *

* Retr iev ing BW ob jec t n ame for nu mb er r ang e o bje ct a nd *

* e limina ting the o nes th at d o n ot q ua lify (p ack age di ms , et c)

*************************************************************

fo rm f ind _lin ked _o bje cts .

da ta: dte xt(4 4).

so rt lt _nri v b y o bje ct.

loo p a t lt_ nri v i nto ls_ nri v.

con cat en ate 'Li nki ng NR o bj ect ' ls _nr iv-o bje ct

into dte xt se par ate d b y sp ac e.

per form me ss age us ing 77 dt ext .

cle ar b wo bje ct1 .

cas e ls _n riv -ob jec t(3) .

whe n 'BID'.

se le ct s ing le d ime ns ion fro m rs dd ime loc

in to bwo bje ct1 wh ere nu mb ranr = l s_n riv -ob jec t+3 (7).

if bwobj ect1 is ini tial .

de le te lt _nr iv.

el se .

* F ilte r o ut p ack ag e d ime ns ions

mo ve bwobj ect 1 to bwob jec t2.

l_ ind ex = s trle n( b wo bje ct2 ).

su bt ract 1 f rom l_i nde x.

if bwobje ct2 +l_ ind ex (1) = 'P'.

de le te lt_n riv.

en di f.

en di f.

whe n 'BIM'.

se le ct s ing le c ha bas nm fro m rs dc hab as loc

in to bwo bje ct1 wh ere nu mb ranr = l s_n riv -ob jec t+3 (7).

if bwobj ect1 is ini tial or bwobje ct1 cs 'REQUEST'.

de le te lt _nr iv.

en di f.

whe n o the rs.

end cas e.

en dlo op.

en dfo rm.

*************************************************************

* UPDATE_ TNRO *

* Upd atin g d ata ba se tab le T NRO wi th cha ng es *

*************************************************************

fo rm u pd ate_ tnr o.

fie ld- symbol s: < tn ro> typ e t nro.

pe rfor m me ss ag e u sin g 9 5 'Upda tin g T NRO ta ble ...'.

ch eck p_ tes t is in itia l.

se lec t * fr om tnr o in to tab le lt _tn ro

for all ent ries in lt_ nri v

wh ere obj ect = lt_n riv -ob ject .

loo p a t lt_ tnr o a ss ign ing <tn ro> .

if <tn ro>- noi vbu ffe r < p_ valu e.

mov e:

'X' to <tn ro> -bu ffer ,

p_ va lue to <tn ro> -no ivb uff er.

en dif .

en dlo op.

up dat e tn ro f rom ta ble lt_ tnro .

if s y-s ubr c = 0.

c ommit wo rk.

en dif.

en dfo rm.

*************************************************************

* DISPLAY_ LIST *

* Disp lay s li st o f u pd ate s *

*************************************************************

fo rm d isp lay _lis t.

wr ite: tex t-00 1.

ul ine . sk ip. det ail .

loo p a t lt_ nri v i nto ls_ nri v.

writ e:/ l s_ nriv -ob jec t.

en dlo op.

en dfo rm.

****************************************************

* MESSAGE

***************************************************

fo rm mes sag e u sin g p ct tex t.

ca ll fun ctio n ' SAPGUI _PROGRESS_ INDICATOR'

e xp orti ng

p erc en tag e = pc t

t ext = tex t

e xc ept ion s

o the rs = 1 .

ca ll fun ctio n ' ABAP4_ COMMIT_ WORK'.

en dfo rm.

- SNRO Number Ranges Objects are generated, therefore, in order not to open QA or PROD systems, the attached programs- ZBC_NRIV_BUFFERING_DEFAULTS allows to maintain Number Ranges for Initial Loads for example and reset afterwards if necessary- Change Table Buffer Settings allows to change list of Table Buffer settings in one go.

- SNRO Number Ranges Objects are generated, therefore, in order not to open QA or PROD systems, the attached programs- ZBC_NRIV_BUFFERING_DEFAULTS allows to maintain Number Ranges for Initial Loads for example and reset afterwards if necessary- Change Table Buffer Settings allows to change list of Table Buffer settings in one go.

ZBC_NRIV_BUFFERING_DEFAULTS

Change Table Buffer Settings

Appendix - Z_BW_MAINTAIN_ROOSPRMS

To reset ROOSPRMSTo reset ROOSPRMS

Copyright 2009 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, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBM Corporation in 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 Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute 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 by Netscape.

MaxDB is a trademark of MySQL AB, Sweden.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

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