02 Basic Technical Architecture

Basic Technical Architecture
Topics
General remarks Configuration of SAP instance Memory Configuration of the Web Application Server (ST02) Important SAP Buffers and Settings ICM and ICF: Configuration of WebServices Load Balancing Operation System and Hardware Database DB All platforms DB Oracle Basics of Memory Management CBO Statistics Tablespace Management Analysis Roadmaps
SAP AG 2005, 02 Customizing and Basic Architecture of SAP BW 3.x Performance, Pascal Prassol / 2
Response Time Components

Average response time in SAP BW is larger than in SAP R/3!
CPU time
Network
Wait time
Roll in
Load time
Processing time
Network
Database time
Response time
Presentation Server
Application Server
Database Server
Response time in milliseconds: Starts when a user request enters the dispatcher queue; ends when the next screen is returned to the user. The response time does not include the time to transfer from the screen to the front end. Wait time in milliseconds: This is the time a user request sits in the dispatcher queue. It starts when user request is entered in the dispatcher queue; and ends when the request starts being processed. Roll-in time in milliseconds: The amount of time needed to roll user context information into the work process. Load time in milliseconds: The time needed to load from the database and generate objects like ABAP source code, CUA, and screen information. Processing time: This is equivalent to response time minus the sum of wait time, database request time, load time, roll time, and enqueue time. Database request time: Starts when a database request is put through to the database interface; ends when the database interface has delivered the result. CPU time in milliseconds: This is the CPU time used by the R/3 work process
Classic Analysis Roadmap I

Problem symptoms: Large roll time Performance problem? Check: Workload on all servers
Large load time Large database request times (Cont.) (Average) Large CPU times
All users affected? No Program analysis
Yes
Processing time much larger than CPU time
If a problem is detected, the data in the Workload Monitor (Transaction ST03N) can be used as follows to identify the area of the system where the problem is located. First check for general performance problems affecting all transactions. Good general performance is normally indicated by:
Wait time < 10% response time Main menu (choose Transaction Profile) < 100 ms
In the Workload Monitor, the following values normally indicate good performance:
Average roll-in time Average roll out time Average load (and generation) time Average database request time Average CPU time Average CPU time < 20 ms < 20 ms < 10 % of response time (<50 ms) depending on the process depending on the process Not much less than processing time
Classic Analysis Roadmap II
Large roll time
Problems with SAP memory management, CPU bottleneck SAP buffer too small CPU/memory bottleneck on database server, network problems, expensive SQL statements, database locks, missing indexes, missing statistics Expensive ABAP processing, for example, processing large tables, frequent accessing of SAP buffers CPU bottlenecks, network problems, communication problems
Large load time Large database request times
(Average) Large CPU times
Processing time much larger than CPU time
Topics
Web Application Server: Memory Configuration
Server
Virtual memory
Shared memory
Roll buffer SAP Paging buffer SAP buffers (programs, tables) Extended memory (user contexts)
Local memory
Heap memory (temporary)
Local memory
Local memory
...
Local memory
1:n
SAP roll file SAP paging file Work process Work process
1:1 ...
Work process
Virtual memory Virtual memory = sum of shared and local memory which is configured for the instance The operating system determines itself, if the allocated memory area resides in the physical memory or in the operating system swap space. Memory areas SAP memory areas are located in one or more of the following: Local memory Shared memory File system Local memory: is associated with individual work processes. Is for: Executables, data stack, buffer for datadabes transfer, local roll area, local paging area Extendend Memory (EM) Contains user context that is, user objects associated with individual users, such as variables, lists and internal tables Most important area for processing data. Swapping should never happen!!. With swapping the performance goes absolutely down. Recommendation: Max use of EM < 80 % of EM in memory SAP buffer: Contain global objects for all users and workprocesses such as programs and customizing tables Usually the program buffer is the largest object (less swapping allowed)
Web Application Server: Work processes (1)

Typical configuration of work process types (SM50):
Restrictions
Not more than 60-100 workprocesses (64-bit operating system) should be configured for one SAP instance (due to administration overload on dispatcher and semaphore lock situations)
Example: Old settings in your system rdisp/wp_no_dia = 10 rdisp/wp_no_btc = 15 rdisp/wp_no_vb = 4 rdisp/wp_no_vb2 = 2 rdisp/wp_no_enq = 1 rdisp/wp_no_spo = 1 BW doesnt need any wp_no_vb2 at all and it is enough to have only one wp_no_vb. Provide enough work processes (wp_no_dia) if you want to load Data in paralell from ODS Layer in the Cubes. Sometimes it is useful to configure operation mode load with more than 8-10 BTC processes and operation mode reporting with just a few BTC processes (e.g. 4). Theoretically: there is no restriction to 100 for the number of workprocesses per instance, but due to adminstrative overhead, it makes no sense to configure more than 100 WP/Instance (see note: 9942). In BW additionally semaphore lock wait situations can occur, if more than 60 workprocesses are configured. If a work process is blocking a ressource, he sets a semaphore. Another workprocess which wants to access this ressource too has to wait. 8 New settings in your system (recommended) => 16 => 8 => 1 => 0
Web Application Server: Work processes (2)

Distribution of workprocess types:
For data staging and reporting mainly DIA workprocesses are used! UPD and UP2 are not (!) used for updating and inserting data targets BTC-Workprocesses are mainly used for deletion of data, aggregation and compression of requests It is not possible (yet) to use spool work-processes for printing query results
ST02: Buffer overview
Max. Use of extended memory should be always smaller than In memory!!!

The status of the buffers can be checked using transaction ST02. Table buffers are used to implement a caching mechanism for data read from the database. The caching mechanism has to be enabled for individual tables. In general, there should be no swaps on any of the buffers, except for the program buffer, for which even very large buffers swaps will occur. Swaps for nametab buffers, CUA, screen, and calendar buffers should always be avoided by increasing the size of the buffer, or the number of directory entries (whichever caused the swaps). If the generic key or single record buffers are swapping due to a lag of directory entries the number of entries should be increased or you can check whether some generically-buffered tables have generic regions that are too small. If the generic key or single record buffers are swapping due to a bottleneck in available memory, check whether enough shared memory is available to increase the buffer size or whether buffering should be disallowed for some tables that are consuming too much space inside the buffer. For the export/import buffer, a few swaps can be tolerated if otherwise the buffer would increase to more than 100 MB. In contrast to the export/import buffer, the export/import SHM buffer has no inherent replacement. Whenever a select is done for a table with caching enabled, the data is first looked for in the buffer and only when it is not there, it is read from the database. The first access to a table puts the information of this table into the buffer. The number of invalidations and the size of the buffer represent costs associated with buffering. The number of database accesses gives a feeling for the savings. The buffer settings and the access pattern for the larger tables in the buffer have to be checked carefully, especially in the case of memory problems in the generic key buffer. Are there any invalidations for the large tables? (Invalidations are more expensive if a larger buffer area is invalidated. As invalidations are very expensive in general, it is also a good idea to sort the display by number of invalidations and see what is causing them). To check the number of directory entries used per table, double-click a table and look at Generic Regions. If problems are identified here that cannot be fixed by changing the parameters of the buffer, check the technical settings for the tables and/or the statements accessing the table. In addition to the information that can be obtained from transaction ST02, you can use the RSDBBUFF report to check the buffers.
10
ST02: detailed analysis: storage
Size results from configured SAP buffers
Size results from # of workprocesses x process local storage
Total size for SAP instance which will be allocated after startup of SAP instance
The size of virtual memory allocated is the amount of memory, the SAP instance allocates during the startup.
11
Single record buffer

Buffered Objects
Master data tables /BI0/P <InfoObjectname> /BIC/P <InfoObjectname> SID Tables /BI0/S <InfoObjectname> /BIC/S <InfoObjectname> Text Tables /BI0/T<InfoObjectname> /BIC/T <InfoObjectname> Metadata Tables
Parameter
Size of buffer rtbb/buffer_length: 200000 kB (Up to SAP Basis Release 4.6D the maximum size limit is 200 MB see note 480710 for details) Max. number of buffered tables rtbb/max_tables: 500
To access a table in single record buffer, the statement must contain the select single command in ABAP. The handling of the single record buffer in combination with BW SID tables is more expensive compared to BW 2.x For changing the buffering settings globally for BW tables see SAPNote 550784. Is espacially recommended for large tables in which only a few records are accessed. Since 6.10 the maximum size for table bufer and single record buffer is 4 GB. Individual records of tables with single-record buffering are managed in the single-record table buffer TABLP. Technical Implementation and Buffer Access The single-record table buffer contains a central administrative structure, a table directory and the data area. The data area is organized in frames of a fixed size (default value 4 KB). The table names are sorted alphabetically in the directory. The table entries are also stored sorted in the corresponding frames of the data area. In a buffer access, a binary search is first used to find the entry in the table directory, followed by the corresponding frame and then the record searched for within the frame. Frames can overflow in the data area if new data is inserted while adhering to the sort sequence. Such overflow frames have to be divided up and their administrative structure must be updated. This explains why the single-record table buffer is somewhat less efficient than the generic/full table buffer. In the single-record table buffer, the data records must be added one after the other while reorganizing the frame structure. In the generic/full buffer, however, all the data of a table is transferred in one step, already sorted by the database.
12
Generic key buffer

Buffered Objects
Tables can be buffered full or generic (only parts) Metadata Tables Customizing Tables
Parameter
Size of buffer zcsa/table_buffer_area: 200.000.000 Byte Max. number of buffered objects zcsa/db_max_buftab: 5000
Entries in a table buffer are always sorted by primary key Generic buffering is recommended for the following tables Client-dependent Language-dependent (in general, only records of one language will be needed) Full buffering is recommended for the following tables: Tables up to 30KB in size. If a table is accessed frequently, but all accesses are read accesses, this value can be exceeded. Pay attention to the buffer utilization factor. Larger tables where large numbers of records are frequently accessed. Tables where frequent attempts are made to access data not contained in the table. Generic table areas or full tables are managed in the generic/full table buffer TABL. The individual generic areas are managed in the buffer like autonomous, fully buffered tables. Technical Implementation and Buffer Access Like the single-record buffer, the generic/full table buffer has a central administration structure, a table directory and the data area. The main difference between the generic/full buffer and the single-record buffer lies in the data area administration. The generic/full buffer divides its storage into areas (extents) of variable length. The length of an extent is a multiple of a fixed block size (256 bytes). The buffer management tries to place the contents of a generic table area or a whole table in an extent. This reduces the storage requirements for buffered data in comparison to single-record buffering. The table names are sorted alphabetically in the table directory. The data records are transferred to the corresponding extent in one step, already sorted by the database. In a buffer access, there is first a binary search for the corresponding table name in the table directory. Then there is a binary search for the corresponding data record in the extent. 13
Export/Import Buffer
Buffered Objects
Metadata of InfoCube Query definition Hierarchy definition Intermediate results when using MultiProvider in Parallel mode
Parameter
Size of buffer rsdb/obj/buffersize: 100000 kB Max. number of objects in the buffer rsdb/obj/max_objects: 15000 Estimation for the size of the largest object rsdb/obj/large_object_size: 8192 Byte
The entries in the buffer can be read as follows: RSIX: 500: RS: used by the OLAP processor client query definition of OLAP
The next 25 digits are the GENUNIID of the query The last 5 digits (R5100) are interesting for development Example 500RS3M68URSQE6LEVH7T6XSQ42Q2GR5100 The Genuniid can be converted using the function module CONVERSION_EXIT_GENID_OUTPUT.
The profile parameters 'large_object_size' determines which influence the larger objects in the buffer have. The unit is Bytes. The size of this parameter determines the size of the freespace list and has influence on the overall performance. If a lot of objects are larger than 8 kBytes, this parameter should be adjusted. Converning the maximum size of the buffer there is a limit of 32 GB. See SAPNote 156957 for details how to calculate the size of Exp/Imp Buffer
14
Export/Import SHM Buffer

Buffered Objects
Query results for OLAP Cache which can be reused if a query: a) selects the same data (identical select) b) filters data, which was selected by another query before c) aggregates data, which was selected by another query before
Parameter
Size rsdb/esm/buffersize_kB: 4096 kB too small for BW installations Recommended: 200-300 MB Max. number of objects in the buffer rsdb/esm/max_objects: 2000 Recommended: 10.000 Estimation for the size of the largest object rsdb/esm/large_object_size: 8192 Byte
With BW2.0B only local query cache was available. Objects, which were buffered in local query cache are only available for the same user again. Usage of objects from local query cache is user-dependent. With BW3.0B additionally to the local cache a global query cache is available. Objects in the global cache are available for each user. Usage of objects from global cache is user-independent. By default the Import/Export SHM Buffer is too small for BW, if the globale query cache is used For optimal query performance when using huge hierarchies (e.g. PSP (project structure plan) elements) rsdb/esm/buffersize_kb has to increased by factor 10 20. The exp./imp. SHM buffer has no inherent replacemant. Is used by the ABAP keyword export to / import from shared memory
15
Profile maintenance RZ10
Directory: /usr/sap/<SID>/SYS/profile
DEFAULT.PFL INSTANCE.PFL default profile overwrites the basic parameters stored in the coding overwrites the basic parameters stored in the coding and in the
16
Web Application Server Settings for BW

Recommended settings for BW (RZ10):
rdisp/max_wprun_time: Max workprocess run time recommended: >3600 (or 0) rdisp/rfc_min_wait_dia_wp: Number of waiting dialog work processes recommended: 2 rdisp/gui_auto_logout: Maximum time of no input at the GUI recommended: 3600 (or 0) rdisp/keepalive: Timer for check unused connections recommended: 3600 (or 0) Further information: SAP Note 192658 Setting basis parameters for BW Systems
Online queries allocate dialog workprocesses, webqueries additionally ICM threads. Default value for max_wprun_time are 600s. Usually too small for BW! rdisp/keepalive: Specifies the maximum time (in seconds) after which the dispatcher uses a ping to check a SAP GUI connection on which no data has been transferred since this time. If the SAP GUI does not respond within the time specified by %%rdisp/keepalive_timeout%%, the dispatcher terminates the connection.
17
New Basis: Web Application Server (Overview)
SAP Web AS
DIAG Dispatcher Workprocess Workprocess Workprocess Workprocess
HTTP HTTP(S) HTTPs ICMan intern J2EE Engine File I/O CGI
New with 6.20: HTTP(s) port + necessary infrastructure

DB
New terms:
ICMAN = Internet Communication Manager ICF = Internet Communication Framework
In the past usually communication took place via SAP-specific DIAG port. Since WebAS 6.10 there is also a HTTP, HTTPS or SMTP port availaible Full SAP Application Server (not just a gateway) with ABAP runtime, Database, DDIC, Security... Runtime and Development Environment for page based Web programming model (Business Server Pages) HTTP Server and Client functionality Native support for open protocols; HTTPS, SSL, SSO, Server and Client Certificates (X.509) XML/XSLT engine, integrated J2EE Engine Datatransfer between ICMAN (threads) and SAP workprocesses with memory pipes (very fast!)
18
ICF: ICM Admin and Monitoring

Administrative Tools
Tcode: SMICM and SICF Command line monitor: icmon{.exe}
ICM status: Trace Level (0-3) Created threads: Connections used: Queue entries used: runs 1 10 / 10 50 (current / peak / maximum) 10 / 10 50 (current / peak / maximum) 10 / 10 50 (current / peak / maximum)
Profile Parameters
See Reference guide for details (icm/*) Online Help
ICMAN.EXE starts the ICM (usually automatically via startsap). There is just one process running on OS level, because of multi threaded architecture. Similiar to disp+work.exe you have to patch periodically icman.exe in order to fix bugs and to get new functionality SMICM
Similiar to Workprocess monitor Status information, traces, logfiles, services, ...threads Temporary configuration of additional services possible
SICF:
Activatation, modification or creation of services Switch on http compression
Administration: profile parameters

icm/HTTP/server_cache<xx>/max_entries icm/HTTP/server_cache<xx>/expiration etc.
19
ICF: Internet Communication Manager (ICM)

Overview:
External Process (icman{.exe}) controlled by Dispatcher Multithreaded architecture with thread pool and dynamic number of threads Managed from ICM Monitor: transaction SMICM Protocol independent due to dynamic plugins (HTTP, HTTPS, SMTP, NNTP, ) Plugins are delivered with SAP executables or downloadable Platform independent Available on all R/3 platforms (NT, Unix, AS/400, etc) Supports both server and client role Uses memory based communication (Memory Pipes = MPI) to enable copy free data transport (I/O) to and from the work process.
20
Services in SICF
Activation:
Activation of ICF-services after the installation necessary in order to work with the ICM (e.g for webreproting). Due to security aspects only activiation of really necessary services is recommended. After installation all ICF services are inactive per default.
right
For Web Reporting only activation of the subtree BW including all subnodes is necessary. Deactivation and activation during runtime of the SAP instance is possible.
21
ICF: Services
Transaction SICF:
services define URL for HTTP handlers Default user settings for public sites Default client, language Definition of Aliases Individual ICF Services for BSP and HTTP Applications BW services delivered as standard
Attend to SAP Note 550669
After installation all services are inactive manually.
required services have to activate
Due to security aspects activate only really necessary services. SAP kernel 6.20 Patchlevel: 251 ( SAPNote 542576). http compression works for all plattforms
After applying http compression you have to invalidate the http server cache ( SAPNote 550669). SAP kernel 6.20 Patchlevel: 850 ( SAPNote 629124). automatic session handling is improved
22
ICF Services Definition

Ability to define default User-id/password, client, and Language
Ability to define user authentification for execution of the service
Service Data Handler List Error Pages Anonymous Logon Data Logon Data Required Client User Password still initial Language Security Requirements Standard SSL Client Certificate w. SSL Basic Authentification Standard R/3 User Internet Users Service Options Server Group: SAP Authorization ErrorType 0 Session Timeout 00:00:00 (HH:MM:SS) Compression (if possible)
Internal SAP security user authentication
Server group: selection for load balancing. SAP Authorization: Check for value in users S_ICF authorizations and the message type to send Session timeout: timeout for user session otherwise profile parameter rdisp/plugin_auto_logout is used Compression: gzip compression option
23
Load Balancing
Concepts
Provides the capability to distribute processing across several servers optimally utilize the server resources that are available. Avoid inefficient situations where one server is overloaded while other servers go underutilized. The following processes can be balanced: Logon load balancing: workload of query/administration users Distribution of web users can be configured in SICF. ODS Object Data Activation is definable for specific server groups Process Chains can be processed on specified server groups Extraction from the mySAP source system: RFC destination (SM59). Data staging via XML over HTTP/SOAP can be processed on specified server groups.
For information on load balancing for web applications, see SAPNote 493475 (BW Web Intelligence and using the message server) and SAPNote 561885 (BW Web Intelligence and SAP BW Web Dispatcher/Reverse).
24
Static or dynamic load distribution
WORKLOAD DISTRIBUTION
STATIC
Start parallel processes manually Start a report that starts processes with fixed packages
DYNAMIC
using logon groups using RFC server groups
25
Static load distribution

T1 = Time until completion Goal: Minimize T1 !!!
WP 1
17 19 18 13 9 5 14 15 10 6 1 16 11 7 2 12 8 3 4
time waiting active T1
WP 2
WP 3
WP 4
WP 5
26
Dynamic load distribution

Distribution of work packages Balanced workload distribution
WP 1
5 4 3 2
7 9 6 8 1
10 11 12 13 15
18 19
WP 2
WP 3
17 16 14
time
WP 4
WP 5
waiting
active
T1 (now)
T1 (before)
27
Dynamic load distribution
Logon Server Groups
RFC Server Groups
SMLG
RZ12
both using asynchronous remote function calls (aRFC)
28
Usage of Server Groups in BW

Logon Server Groups
Logon of Users Standard GUI BEX Analyzer Web
RFC Server Groups

Upload of data from SAP R/3 to BW Schedule data load from BW to SAP R/3 Activation of ODS Objects Hierarchy- and Attribute Changerun Process Chains
Problem with Logon Server Groups in BW: No rebalancing of users, once they are connected. If the user doesnt logoff by himself, this can lead to an overload of the application server. Solution: Terminate the connection automatically by setting the profile parameter rdisp/gui_auto_logout.
29
aRFC: Usage of RFC Server Groups aRFC Call

PROGRAM RS01. ...
CALL FUNCTION '...' DESTINATION IN GROUP 'A STARTING NEW TASK ABC
Instance 1 Instance 2 Instance 1 Instance 2
Server Group A
Server Group B
SAP System
Synchronous RFC Call: The calling program stops until the function module has been processed on the target server and any results have been returned to the caller. Only then does the calling program continue processing. Asynchronous RFC: The calling program runs parallel to and independently of function module processing in the target system. Programmers are responsible for the processing of the results. In addition, the target system must also be available at the time of the RFC call. Transactional RFC: Several function modules can be grouped into one transaction. They are processed only once in the target system, within an LUW, and in the sequence in which they were called. In the case of an error, a message is sent to the calling system that you can analyze using transaction SM58. For transactional RFC, the target system does not have to be available at the time of the RFC call. In addition, you can configure the frequency and intervals of individual queries.
30
Resource Determination Logon Server Groups

CALL FUNCTION ... DESTINATION IN GROUP ... STARTING NEW TASK 'ABC'
Use quotas? yes
Server Group A
Message Server
Instance 1 Instance 2
Dispatcher Queue
1. at least 3 free dialog WPs WP 1 WP 2 WP 5 2. less than 10% ongoing requests in the wait queue NOT CONFIGURABLE !!!
Dispatcher Queue
WP 1 WP 2 WP 5
WP 3
WP 4
WP 6
WP 3
WP 4
WP 6
Configurable is the max amount of users and the response time
31
Resource Determination RFC Server Groups

CALL FUNCTION ... DESTINATION IN GROUP ... STARTING NEW TASK 'ABC'
Use quotas? yes
Server Group A
Message Server
Instance 1 Instance 2
1. dispatcher queue: rdisp/rfc_max_queue % 2. at least rdisp/rfc_max_ own_used_wp free dialog work processes 3. at most rdisp/rfc_max_login % of allowed logins ...
Dispatcher Queue
WP 1 WP 2 WP 5
Dispatcher Queue
WP 1 WP 2 WP 5
WP 3
WP 4
WP 6
WP 3
WP 4
WP 6
rdisp/rfc_max_queue: Quota for dispatcher request queue Quota for the maximum number of requests in the dialog queue. If this value is exceeded, no further resources are returned to the caller, as the server should be protected from overload. The value is specified as a percentage, that is, it depends on the current value set in the profile. The total number of requests in the queue is specified by the parameter %%rdisp/elem_per_queue%%.
rdisp/elem_per_queue: Number of Requests per Work Process Queue This parameter determines the number of requests which can be held in one queue (dialog, update, lock, background, spool) in the dispatcher. A request requires less than 200 bytes of storage. Most requests require an additional data block, which is drawn from the pool of blocks provided in wp_ca_blk_no. Servers that provide only dialog services (interactive users) require relatively few blocks. In servers that offer enqueue, batch, and update services, require more blocks. In general, the default value is sufficient even for the higher demands in non-dialog servers.
32
Creation of RFC Server Groups
Determination of resources in RZ12 is available as from release 4.5A. Settings are valid for a single instance, not for the whole server group. Do not forget to save the settings. Assign more than one server to a server group.
33
RFC Server Group Quotas (1)
RZ12
defined per instance
validuntil until valid shutdown shutdown
percentage value
absolute value
Activated: Switch to activate or deactivate the resource determination 0 Routine for resource destermination is deactivated 1 Routine for resource determination is activated Profile parameter : rdisp/rfc_use_quotas Default value : 1
34
35
Referring to: dispatcher queue Transaction SM51 rdisp/rfc_max_queue Default value: 5 %

36
Referring to: user logons Transaction SM04 rdisp/rfc_max_login Default value: 90 %

37
Referring to: OWN user logons Transaction SM04 rdisp/rfc_max_own_login Default value: 25 %
38
Referring to: number of work processes Transaction SM50 rdisp/rfc_max_own_used_wp Default value: 75 %
39
Referring to: number of work processes Transaction SM50 rdisp/rfc_min_wait_dia_wp Default value: 1
40
Referring to: communication table Transaction SM51 rdisp/rfc_max_comm_entries Default value: 90 %

Additional hint: SAPNote 74141 Resource Management for tRFC and aRFC
Very detailed and technical description of the configurable profile parameters
41
RFC & IDOCS: Tips and Tricks

Addidional SAPNotes
538052 Maintenance of the myself-connection 524554 Maintenance of RFC-destinations in the BW-environment 415878 Dump because request no. is blank in "RSM1_INIT_PARTTAB" 527481 IDOC_INBOUND_ASYNCHRONOUS ; Transaction recorded in SM58; Note describes settings necessary for tRFC and qRFC 673940 Duplicate transfer of data packages/lock message MC 601 415878 The TRFC queue should be controlled daily 81814 TRFC entries can be deleted by report RSARFCER
610938 Error 7 during transfer of an IDoc into BW

Further Tips and Tricks: In the SM59 connection of the source system to the BW system, the connection should be set so that a cancelled transmission is NOT started automatically again. Hanging IDOCs (Status 64) => SAPNote 561880 and 555229 Error No RFC destination maintained in the source system, but the destination is existing. => In the RFC destination the language is missing. ABAP runtime error CALL_FUNCTION_REMOTE_ERROR: The termination occurred in the ABAP/4 program "SAPLRSAOS " in "METADATA_20_UPLOAD". The main program was "RDDEXECU ". => SM59 Check MYSELF-Destination , User without password? Its also possible to delete the RFC destination and to recreate it by executing the restore function. Transport of ODS-Objects: Error message: RSDODSO 102 ODS Object ZTST_ORD is not available for version A Check the myself connection in the RFC destination Check in SM59 works fine, but you have communication errors in SM21 during the data upload. Transaction SMGW (in SourceSystem) gives timeout during allocate: Maybe the BW has too less DIALOG processes. For SM59-checking purpose, there are less dialog processes needed than during a data load. In the transaction SMQS in the SourceSystem the number of maximum connections for the destination BW can be set to a value (for example to 10, that means that the SourceSystem tries to get 10 dialog processes in the BW). SM58: Statustext column contains a text like Transaction recorded To much gateway traffic !
Notes: 63483, 38682, 530997, 527481, 460235, 74141 and schedule report RSARFCEX periodically (Message 376965 / 2002). Make sure that the customer implements the actual qRFCversion and the actual supplement.
42
Topics
43
Operating system monitor: ST06
Total size of memory configured for SAP (from ST02) and for Database (ST04) must not exceed the size of physical memory available
44
Compare CPU / IO values

Try to find critical CPU and IO times
00:00:00 01:00:00 02:00:00 02:20:00 02:40:00 03:00:00 04:00:00 05:00:00 05:20:00 05:40:00 06:00:00 06:20:00 %usr 0 2 6 41 32 24 16 21 8 8 18 %sys 0 1 2 2 3 1 3 4 2 2 3 %wio %idle 0 99 4 94 26 66 13 44 24 41 0 74 69 11 32 43 28 62 34 56 28 50
In this example: Operating System AIX sar-command
What processes are runnning? Is the degree of parallelism too high? Additional IO Controller necessary?
45
Disk Layout
Purpose
Distributing the data accesses across several physical disks. Avoid I/O hot spots Optimize the overall throughput to the disks. Usually storage (sub-)systems are used to handle bigger transparent storage units (and not one physical disks), e.g. RAID systems and RAID arrays.
46
Topics
47
Overview Database and System parameters

Database and system parameters define sizes of DB memory, sizes of disk areas, behavior of the DB optimizer, logging, processes etc. These parameters must be in sync with the SAP recommendations when installing the system. After the installations, some parameters cant be changed without high effort (e.g DB_BLOCK_SIZE). Especially in scenarios with a high data volume these parameters can have a great influence on the overall system performance!
The number of dialogue processes should be by one higher than the other processes (see SAPNote 74141: Resource management for tRFC and aRFC for more details). Note that a BW application server does not need an UP2 process and not more than 2 UPD processes. Check the following SAP notes for the respective underlying DB management system: SAPNote 192658: Setting basis parameters for BW systems SAPNote 180605: Oracle database parameter settings for BW SAPNote 302429: DB2 UDB EEE: Performance on BW 2.0B, 2.1C, 3.0A SAPNote 546262: DB6: Performance on SAP BW 3.0B SAPNote 307077: AS/400: Performance optimizing in BW Systems SAPNote 501572: iSeries: EVI stage 2 support SAPNote 541508: iSeries: Checking the system parameters SAPNote 390016: DB2/390: BW: DB settings and performance SAPNote 181945: Performance guide: BW on Informix SAPNote 327494: Configuration Parameters for SQL Server 2000 SAPNote 28667: Microsoft SQL Server Specific Profile Parameters
48
DB Statistics MS SQL: Manual statistic generation

Problem
MS SQL Server is automatically updating statistics if the database option "auto create statistics" and "auto update statistics" are set. Nevertheless, very small tables are not automaticly updated. This behaviour is intended by Microsoft and normally does not cause any problems. Indeed we have never seen any performance problems on OLTP systems because of this behaviour, besides these joins in BW systems and BW based systems. Statistics can be maintained using the admin workbench: Right mouse click at the infocube entry -> Manage -> Performance
Solution
In a default BW installation on MS SQLserver the neccessary push buttons are invisible. You can make them visible by running the ABAP/4 report RSDD_MSSQL_PROG_01 This report is sending an output telling if statistic maintenance is enabled or not.
SAPNote 542468
49
Database monitor: ST04 (Oracle)
Total memory consumption Sum of memory for DataBase Buffers + Shared Pool Size
Dont forget the process local memory sizes
Total memory consumption (Oracle 8) Global settings Data buffer + Shared Pool Size + Java Pool Size Process local settings in Oracle 8i hash_area_size sort_area_size bitmap_merge_area_size create_bitmap_area_size PGA Aggregate target in Oracle 9i
50
DB02 Database monitoring: Tables and Indexes
51
DB02 Missing Indexes

Missing Indexes run ABAP reports (SAPNote 157918):
SAP_UPDATE_DBDIFF SAP_INFOCUBE_INDEXES_REPAIR
Transaction DB02 is frequently used by administrators to check for missing indexes: simply call transaction DB02 and press the button "Missing Indexes". This will lead you to the screen shown in the lower left-hand corner of the slide. If many facttable primary or secondary indexes are missing then you might apply SAPNote 157918: run the ABAP reports
SAP_UPDATE_DBDIFF, and SAP_INFOCUBE_INDEXES_REPAIR
and check DB02 again. Details of the reports are provided on the following slide.
52
ABAP Reports (delivered by BW)

SAP_UPDATE_DBDIFF
updates table DBDIFF Facttables without primary index temporary views other temporary objects (see SAPNote 308533 for temp. obj.) needs to be run only once
SAP_INFOCUBE_INDEXES_REPAIR
applies to all active infocubes and aggregates Re-creates missing P-indexes re-creates missing secondary indexes should be run as a batch job
BW provides two ABAP reports that are relevant foSAPNote 157918. SAP_UPDATE_DBDIFF This report updates the table DBDIFF which lists tables or tablespaces that do not comply with ABAP dictionary standards. In the context of BW these are facttables withouth primary index and temporary objects (tables, views, triggers, ...). This report will make sure that facttables and temporary objects are properly listed in DBDIFF which in turn is used by DB02. DB02 will take differences into account that are listed in DBDIFF and thus avoid to list those differences as errors. The report has to be run only once in order to make up for differences that originate from BW 1.2 or BW 2.0A and that remained when the system was updated to BW 2.0B. All objects that are created in BW 2.0B or above should be tracked DBDIFF when they are activated. SAP_INFOCUBE_INDEXES_REPAIR This report applies to all active infocubes and their aggregates. It removes existing primary indexes these might be left-overs from BW 1.2 recreate missing Pindexes and recreate missing secondary indexes. This report can be used to repair infocube indexes system-wide, i.e. without looking at each infocube individually. This is particularly interesting for administrators. The report should be run as a batch job as it might run for a while.
53
Temporary database objects in BW 3.x

Generated temporary objects
The BW System uses temporary database objects. They are generated outside of the ABAP DDIC for performance reasons or because they cannot be defined there. All these objects have names that start with /BI0/0... /BI0/01... /BI0/02... /BI0/03... /BI0/04... /BI0/05... /BI0/06... /BI0/0D... interim results during query processing Interim results during processing ext. Hierarchies Views for every SQL query Stored Procedures while compressing InfoCubes Triggers while compressing InfoCubes Reused interim results during query processing Materialized results of OpenHub read processes
You can run report SAP_DROP_TMPTABLES to remove temporary objects.
SAPNote 449891 The BW System uses different temporary objects for the query and other processes. The system often generates them outside of the ABAP DDIC for performance reasons or because they cannot be defined there (as stored procedures or triggers). The SAP_DROP_TMPTABLES report deletes all objects (except for the tempor ary hierarchy tables) without taking into account whether or not they are still in use. This can result in terminations of queries, compression and data extraction, for example, if these are running simultaneously. If temporary objects prove to be inconsistent under DB02, you must execu te report SAP_UPDATE_DBDIFF once. If you use the DB02 afterwards once again, you must make sure that the system refreshes the results. The report copies information on differences between definitions in the ABAP DDIC and in the DB catalog into table DBDIFF. DB02 includes the table during the check for inconsistencies.
54
Oracle Data Dictionary Performance

Problem
Problem: Rule Based Optimizer used for Data Dictionary Access in 8.1.7 and 9.2.0 Statements accessing the Oracle Data Dictionary objects may cause long response times in BW systems. SAP BW depends on the partitioning concepts of Oracle to perform well. By using many partitions in the database access to certain data dictionary objects may become slow. Examples of these dictionary objects are DBA_EXTENTS, DBA_SEGMENTS... In Oracle versions 8.1.7 and 9.2 statements accessing the Oracle data dictionary objects are optimized with the Rule Based Opimizer (RBO).
Solution
Using the Cost Based Optimizer can dramatically improve the accesses to DDIC
In an SAP BW installation all optimization and execution techniques like HASH JOINS or BITMAP OPERATIONS are enabled by having the correct initialization parameters set in the init<SID>.ora Statistics have to created on data dictionary tables and clusters.
SAP Note 558746 The following script allows you to create the necessary optimizer statistics. The script must be run from sqlplus under the database user SYSDBA. his script should only be applied to a BW system and NEVER (!!!) to a R/3 System: set timing on set echo on spool ana_dict execute dbms_stats.gather_schema_stats ('SYS',cascade=>true,degree=>4); analyze cluster C_OBJ# compute statistics ; analyze cluster C_USER# compute statistics ; analyze cluster C_FILE#_BLOCK# compute statistics ; analyze cluster C_TS# compute statistics ; analyze cluster C_COBJ# compute statistics ; analyze cluster C_MLOG# compute statistics ; analyze cluster C_RG# compute statistics ; analyze cluster C_OBJ#_INTCOL# compute statistics ; analyze cluster C_TOID_VERSION# compute statistics ;
55
Optimizer Determination of Access Path
Select * from /BIC/P... WHERE name=Miller AND pnum=123456 AND city=HAMBURG
The optimizer determines the optimal access path
57
Create CBO statistics with DBMS_STATS package

Problem
Traditionally CBO Statitics are created with the ANALYZE TABLE command, but without histograms. Histograms are generally required to select efficient execution plans in the context of BW queries for the Oracle optimizer.In contrast to this, it is taking customers a very long time to calculate DB statistics if there is a very large data volume. Oracle allows you to create database statistics using the PL/SQL package DBMS_STATS.
Solution
As of SP8 (BW3.0B) possible. Report SAP_RSADMIN_MAINTAIN with the following parameters: OBJECT = ORA_DBMS_STATS VALUE = 0 (analyze), 1 (noparallel with histograms), >1 (parallel without histograms)
See SAP Note 351163 for details to create CBO statistics with DBMS_STATS package. As an alternative to the traditional ANALYZE TABLE command, Oracle allows you to create database statistics using the PL/SQL package DBMS_STATS.The advantages of this are improved performance since DBMS_STATS can determine statistics in parallel -, however, with the restriction that the table statistics are created without histograms. Histograms are generally required to select efficient execution plans in the context of BW queries for the Oracle optimizer.In contrast to this, it is taking customers a very long time to calculate DB statistics if there is a very large data volume.DBMS_STATS may be an alternative here. If a bottleneck arises in the statistics calculation, you should test the approach described here and then monitor the performance of BW queries afterwards.If you notice that the performance is impaired, you should no longer use DBMS-STATS and return to the traditional ANALYZE TABLE method. The option of calculating Oracle statistics via DBMS_STATS is available as of BW 2.0B Support Package 8.In Oracle-based BW 3.x systems, DBMS_STATS is the standard method for calculating Oracle statistics (see below). Isolated errors occur within DBMS_STATS (for example, ORA-20000, ORA-4021, ...). These errors will be solved in future Oracle releases.In this case, you must convert the "ANALYZE TABLE method" again. parallel degree = 0: ANALYZE TABLE ... is used parallel degree = 1: DBMS_STATS is used;histograms are created (size = 75) (default) parallel degree > 1: DBMS_STATS is used; parallel execution;no histograms Dont mix creating CBO statistics with the ANALYZE command and the DBMS_STATS package. See SAP note 489352. Histograms: The histogram captures the distribution of different values in a column, so it yields better selectivity estimates. Having histograms on columns that contain skewed data (in other words, values with large variations in number of duplicates) greatly helps the CBO generate good selectivity estimates.
58
Avoid creation of BW initiated CBO statistics

Problem
CBO statistics are created at certain times in BW. These processes can occupy a considerable portion of the runtime, especially in the case of large scenarios. If, however, a rollup or changerun takes place during a night or weekend time window, in which very few queries or no queries at all are running, it may be useful to forgot the DB statistics at first and compile these at the end of the process.
Solution
As of SP6 (BW3.0B) possible. Report SAP_RSADMIN_MAINTAIN with the following parameters: OBJECT = DB_STATISTICS VALUE = OFF
59
Options to create CBO statistics with BRCONNECT - I

Recommendation
Usage of BRCONNECT (release 6.20 or higher) for gathering all DB statistics for BW tables. The proposed way to call BRCONNECT is brconnect -u / -c -f stats -t all If your BW system had been upgraded from a BW 2.x or BW 3.0A system then you have to run the report SAP_DBSTATC_CLEANUP once. This report will clean up the table DBSTATC which was used in the earlier releases to separate the tables that had to be analysed by SAPDBA from those that had to be analysed by the report SAP_ANALYZE_ALL_INFOCUBES. If DBSTATC is not cleaned up then BRCONNECT might not gather all necessary statistics!
See SAP Note 129252 for details.
60
Options to create CBO statistics with BRCONNECT- II

Remark
Previously, many customers used the following two calls of BRCONNECT to gather statistics in any of the BW releases prior to BW 3.0. The first call deals with non-InfoCube related tables, the second one with InfoCube related tables, thereby discarding DBSTATC entries. While this is not the officially recommended strategy we document those calls here:
brconnect -u / -c -f stats -t all -e info_cubes,all_part brconnect -u / -c -f stats -t info_cubes,all_part -f allsel
brconnect -u / -c -f stats -t all -f monit Create statistics and if there is no MONITORING attribut, it will be created.
61
Check of DB Statistics with RSRV
Alternative you can check the statistics by analyzing the log of BRCONNECT (DB14).
62
Memory Management: Tablespaces DB02
Locally managed tablespaces With each SAP standard Installation on Basis 6.10 or higher all SAP tablespaces are locally managed except PSAPROLL and SYSTEM only 6 tablespaces after installation
63
Locally managed Tablespaces vs. Dictionary managed Tablespaces (1)

Locally managed
Extent allocation Tablespace manages its own extents by maintaining a bitmap in each datafile to keep track of the free or used status of blocks in that datafile. When an extent is allocated or freed for reuse, Oracle changes the bitmap values to show the new status of the blocks. These operations do not generate rollback information.
Dictionary managed
Extent allocation Oracle has to update the appropriate dictionary tables (FET$, UET$), whenever an extent is allocated or freed for reuse and must store rollback information about each update of these objects.
Locally Managed Tablespaces A tablespace that manages its own extents maintains a bitmap in each datafile to keep track of the free or used status of blocks in that datafile. Each bit in the bitmap corresponds to a block or a group of blocks. When an extent is allocated or freed for reuse, Oracle changes the bitmap values to show the new status of the blocks. These changes do not generate rollback information because they do not update tables in the data dictionary (except for special cases such as tablespace quota information). Dictionary Managed Tablespaces If you created your database with an earlier version of Oracle, then you could be using dictionary managed tablespaces. For a tablespace that uses the data dictionary to manage its extents, Oracle updates the appropriate tables in the data dictionary whenever an extent is allocated or freed for reuse. Oracle also stores rollback information about each update of the dictionary tables. Because dictionary tables and rollback segments are part of the database, the space that they occupy is subject to the same space management operations as all other data.
64
Locally managed Tablespaces vs. Dictionary managed Tablespaces (2)

Advantage of locally managed tablespaces
No recursive space management operations, i.e. consuming or releasing space in an extent results in other operations that consume or release space in data dictionary tables or rollback segments in the case using dictionary managed tablespaces No need to coalesce free extents Better performance
Locally managed tablespaces have the following advantages over dictionary managed tablespaces: Local management of extents automatically tracks adjacent free space, eliminating the need to coalesce free extents. Local management of extents avoids recursive space management operations. Such recursive operations can occur in dictionary managed tablespaces if consuming or releasing space in an extent results in another operation that consumes or releases space in a data dictionary table or rollback segment. The sizes of extents that are managed locally can be determined automatically by the system. Alternatively, all extents can have the same size in a locally managed tablespace and override object storage options. The LOCAL clause of the CREATE TABLESPACE or CREATE TEMPORARY TABLESPACE statement is specified to create locally managed permanent or temporary tablespaces, respectively.
65
Strategy for creating and assigning Tablespaces

Create Tablespaces on database level for Larger InfoProvider Aggregates of larger InfoCubes PSA Tables ODS Tables Maintain tables (see SAPNote 46272) and transport the corresponding entries for DDART, DARTT from development to the productive system Assign data classes to the objects before activating them in the development system and transport the objects The Tablespaces can differ between development and productive system (correlation between data class and table space is stored in table DDART), but the assignment of data classes to the objects must not.
66
Database Storage parameters

InfoCubes (fact tables and dimension tables): Admin WB > Modeling > InfoProvider > InfoCube change > Extras Menu > Maintain DB Storage Parameters Aggregates of an InfoCube (fact tables and dimension tables): Admin WB > Modeling > InfoProvider > InfoCube change > Extras Menu > Maintain DB Storage Parameters ODS object (delta queue and active data table): Admin WB > Modeling > InfoProvider > ODS object change > Extras Menu > Maintain DB Storage Parameters PSA tables* Admin WB > Modeling > InfoSource > Transfer rules change > Extras Menu > Maintain DB Storage Parameters InfoObject (tables) Admin WB > Modeling > InfoObjects > InfoObject change > Extras Menu > Maintain DB Storage Parameters
67
DataClasses and size category for aggregates

InfoCube SALES01
Aggregates of IC SALES01
Technical settings
(Tablespace Assignment...) are derived from InfoCube
Tablespace PSAPSALES
Tablespace PSAPSALES
Own Tablespace for the aggregates of InfoCube SALES01 possible!
e.g. Tablespace PSAPSALAGGR

68
Oracle 9i New features
Automatic UNDO Management PGA: Automatic Memory Management SGA: Dynamic Resizing Multiple Block Size Support
69
Oracle 9i - Automatic UNDO Management (1)

Automatic UNDO Management
Simplifies management of undo information No need to create, drop, alter rollback segments manually UNDO segments can be managed either manual or automatic Data is managed by a single UNDO-tablespace (PSAPUNDO)
Look at SAPNote 600141 for detailed information
70

initSID.ora parameters to setup AUM
UNDO_MANAGEMENT Switches automatic UNDO management on/off UNDO_TABLESPACE Defines which automatic UNDO tablespace is used (SAP UNDO_SUPPRESS_ERRORS Supresses errors if invalid UNDO command is issued UNDO_RETENTION Specifies the time in seconds Read Consistency should be guarenteed
PSAPUNDO)
SAPNote 600141: UNDO_RETENTION: start with 10800 sec
71

V$UNDOSTAT
Displays the UNDO usage in 10 minute intervals:
72
Oracle 9i - PGA: Automatic Memory Management (1)

Automatic Memory Management (PGA)
Simplifies and improves memory allocation Oracle work areas can be adjusted automatically and dynamically Ease of memory tuning Reduction of time to tune memory Better throughput Improved query response time
73

Standard R/3
Untunable Memory
Tunable Memory = SORT_AREA_SIZE
Process PGA Process PGA Process PGA
Process PGA
95 %
5%
<= PGA_AGGREGATE_TARGET
74

SAP BW
Untunable Memory
Tunable Memory
SORT_AREA_SIZE HASH_AREA_SIZE BITMAP_MERGE_AREA_SIZE CREATE_BITMAP_AREA_SIZE
Process PGA Process PGA Process PGA
Process PGA
5%
95 %
<= PGA_AGGREGATE_TARGET
75

initSID.ora parameters to setup PGA
PGA_AGGREGATE_TARGET Specifies the target aggregate PGA memories of all server processes attached to the instance Recommendation: >= 20% of physical memory (=40% of physical memory in case of standalone installation)
WORKAREA_SIZE_POLICY Specifies the policy for sizing work areas and controls the mode in which work areas are running MANUAL (Default) AUTO (Default if PGA_AGGREGATE_TARGET is set)
76

New section for PGA in V$SYSSTAT
Ideal case: only optimal executions, no onepass, no multipass... But hard to realize
V$SYSSTAT: cumulated values since start of instance
77

V$PGASTAT
Displays general information about PGA usage:
Total PGA inuse: actual resource consumption
78

New entries for process local PGA usage in V$PROCESS
79
Oracle 9i - SGA: Dynamic Resizing (1)

Oracle 9i - SGA: Dynamic Resizing
Oracle 8i memory management is static: SGA is defined by initSID.ora since startup of the instance. With Oracle 9i memory management becomes flexible several parts of the SGA could be changed dynamically, memory could be shifted between different areas without restarting the instance.
80

Oracle 8i
Shared_Pool_Reserved_Size
SHARED_POOL_RESERVED_SIZE
Shared Pool
SHARED_POOL_SIZE
Buffer Pool
Default Recycle Keep
DB_BLOCK_BUFFERS
BUFFER_POOL_RECYCLE BUFFER_POOL_KEEP
Static memory configuration Recycle Pool and Keep Pool are defined out of all DB_BLOCK_BUFFERS
Keep: table is automatically kept in memory, read operations are then not processed by the LRU algorithm, but are read directly Recycle: the contrast of the keep pool Shared_Pool_Reserved_Size: if very large objects are required and requested
81

Oracle 9i
Shared Pool
SHARED_POOL_SIZE
Keep Recycle
DB_KEEP_CACHE_SIZE DB_RECYCLE_CACHE_SIZE
Default
DB_CACHE_SIZE
SGA_MAX_SIZE
9i memory components can be changed dynamically -> no database restart necessary
Changeable with alter system...
82

initSID.ora parameters to setup dynamic SGA
DB_CACHE_SIZE Specifies the size of the cache for standard block size buffers DB_KEEP_CACHE_SIZE Specifies the number of buffers in the KEEP buffer pool. The size of the buffers is the primary block size (DB_BLOCK_SIZE) DB_RECYCLE_CACHE_SIZE Specifies the number of buffers in the RECYCLE buffer pool. The size of the buffers is the primary block size (DB_BLOCK_SIZE) SGA_MAX_SIZE Specifies the maximum size of the System Global Area for the lifetime of the instance
83

You can use V$DB_CACHE_ADVICE to estimate optimal buffer cache sizes
Advice for two different buffer pools (8K and 16k)
Physical reads depends on the block size
84
Oracle 9i - Multiple Block Size Support (1)

Multiple Block Size Support
Tablespaces within one database can have different Oracle Block Sizes Supported Block Sizes: 2k, 4k, 8k, 16k, 32k Block size setup on tablespace creation Each block size has an own buffer cache Separate buffer cache must exist, before a tablespace can be created System TS and Temp TS must have default blocksize
85

Shared Pool
SGA_MAX_SIZE
16K Buffer Area
DB_16K_CACHE_SIZE
32K Buffer Area

Keep Recycle
DB_32K_CACHE_SIZE DB_KEEP_CACHE_SIZE DB_RECYCLE_CACHE_SIZE
Default = 8K Buffer Area
DB_CACHE_SIZE
86

View V$BUFFER_POOL displays information about specified buffer pools
87

Benefit of Multiple Block Size Support
Less I/O less system calls on OS- level i.e. faster full table scans Less space consumption less space needed to store administrative information like block headers etc. fewer number of blocks
88

initSID.ora parameters to setup Multiple Block Support
DB_2K_CACHE_SIZE Specifies the size of the cache for 2K buffers. Parameter can be set only when DB_BLOCK_SIZE has a value <> 2K DB_4K_CACHE_SIZE Specifies the size of the cache for 4K buffers. Parameter can be set only when DB_BLOCK_SIZE has a value <> 4K DB_8K_CACHE_SIZE Specifies the size of the cache for 8K buffers. Parameter can be set only when DB_BLOCK_SIZE has a value <> 8K DB_16K_CACHE_SIZE Specifies the size of the cache for 16K buffers. Parameter can be set only when DB_BLOCK_SIZE has a value <> 16K ...
89
Usage of Oracle compression and BW

Feature description
Oracle9i Release2 Enterprise Edition introduces a compression technique that is useful for large data warehouses. The focus should clearly be located on the space saving aspects. This feature is only used for available data. New data will always be stored uncompressed. In order to compress data a dba has to do a reorganization of the table (insert as select.... or import/export). Compressed objects should not be changed anymore. If you change the object you will get an error message from oracle for compressed objects. This solution should not be used in general.
SAPNote 701235 PSA: The PSA tables could be compressed if the data will be stored for a longer period Cubes: Historical Cubes (e.g. sales cube 1999) are suiteable objects for compression. Looking at partitions it is the same. "Old" partitions which are not being changed could be compressed. Aggregates: In general the aggregates should not have navigational attributes, if you want to compress aggregates. If you have nav. attributes and you change the value, the compression will be lost due deletes and updates. ODS: The ODS has 3 physical tables (activation queue, active data and change log) The change log could be compressed without any restrictions. (Only inserts are applied) The activation queue should not be compressed, because normally the data is deleted after activation. The active data could be compressed but you have to keep in mind if the number of updates is higher than the number inserts the compression will be lost after a certain time. Please keep in mind that the ABAP Dictionary does not currently support compression. This means that the compression is lost when a compressed table is reorganized.
90
Oracle 9i: ASSM Automatic Segment Space Management In Detail: Hierarchical structure of bitmap blocks
Segment Header
Level 2
Level 1
Level 1
Level 1
Ranges of data blocks

92
Oracle 9i: ASSM Automatic Segment Space Management In Detail: A table with 4 extents and 8 blocks each
E1 1 2 Segment 3
E2
Segment 3
E3 E4
Segment 3 Segment 3 1001 0001 0111
Data Block Segment Header 1/2 L2/L1-Bitmap Block
At every time its known how much each data block is filled (in 25% steps)
93
Oracle 9i: ASSM Automatic Segment Space Management DBA_TABLESPACES
SEGMENT_SPACE_MANAGEMENT = AUTO -> Locally Managed Tablespace using Automatic Segment Space Management (since SAP basis release 6.40) SEGMENT_SPACE_MANAGEMENT = MANUAL -> Locally Managed Tablespace using Free Lists
94
APPENDIX
95
SAPConnect
Configuration of SAPConnect
Sending an email for information about failed requests: Some information in message 131724. Configuration of SAPCONNECT: 1. Change the instance profile in RZ10 2. Add a system background user for messages 3. Configure SICF 4. Configure SCOT Note 455140 contains some info about this.
96
How to save the transfer rules of a source system

RSA1 Transport Connection Button 'Collection mode' set to 'start manual collection'
Press 'Source system assignment' button (it's the one left of the 'Request BEx' button) Select the source systems you want to save the transfer rules for Continue Button 'Grouping' set to 'Save for system copy Extend tree 'Source system' LSYS At the left border click on 'Object Types'
Double click on 'Select objects'
Select the source systems you want to collect objects for the source system is now displayed in the right box Press collecting button ('gather dependent objects') this may take a while
Right click on the root of the tree and select Transport all below Expand the whole tree and check if there isn't an object which is locked by an other open transport request !! (the column 'Transport request' has to be empty !) Press the transport button => A transport request is created. Check if the request contains all ISMP and ISTS objects. Release the request! (BEFORE deleting the corresponding source system connection!)
97

02 Basic Technical Architecture

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

02 Basic Technical Architecture

Uploaded by

Copyright:

Available Formats

Basic Technical Architecture

Response Time Components

Classic Analysis Roadmap I

All users affected? No Program analysis

Processing time much larger than CPU time

Classic Analysis Roadmap II

Large roll time

Large load time Large database request times

(Average) Large CPU times

Processing time much larger than CPU time

Web Application Server: Memory Configuration

Web Application Server: Work processes (1)

Web Application Server: Work processes (2)

ST02: Buffer overview

Max. Use of extended memory should be always smaller than In memory!!!

ST02: detailed analysis: storage

Size results from configured SAP buffers

Size results from # of workprocesses x process local storage

Single record buffer

Generic key buffer

Export/Import SHM Buffer

Profile maintenance RZ10

Web Application Server Settings for BW

New Basis: Web Application Server (Overview)

New with 6.20: HTTP(s) port + necessary infrastructure

ICF: ICM Admin and Monitoring

Administration: profile parameters

ICF: Internet Communication Manager (ICM)

After installation all services are inactive manually.

required services have to activate

ICF Services Definition

Ability to define user authentification for execution of the service

Internal SAP security user authentication

Static or dynamic load distribution

Static load distribution

Dynamic load distribution

Dynamic load distribution

Logon Server Groups

RFC Server Groups

both using asynchronous remote function calls (aRFC)

Usage of Server Groups in BW

RFC Server Groups

aRFC: Usage of RFC Server Groups aRFC Call

Resource Determination Logon Server Groups

Use quotas? yes

Configurable is the max amount of users and the response time

Resource Determination RFC Server Groups

Use quotas? yes

Creation of RFC Server Groups

RFC Server Group Quotas (1)

validuntil until valid shutdown shutdown

RFC Server Group Quotas (2)

RFC Server Group Quotas (3)

Referring to: dispatcher queue Transaction SM51 rdisp/rfc_max_queue Default value: 5 %

RFC Server Group Quotas (4)

Referring to: user logons Transaction SM04 rdisp/rfc_max_login Default value: 90 %

RFC Server Group Quotas (5)

RFC Server Group Quotas (6)

RFC Server Group Quotas (7)

RFC Server Group Quotas (8)

Referring to: communication table Transaction SM51 rdisp/rfc_max_comm_entries Default value: 90 %

RFC & IDOCS: Tips and Tricks

610938 Error 7 during transfer of an IDoc into BW

Operating system monitor: ST06