Performance Tuning document STAD:-We can get last 2 days info with terminal IDs The Business Transactions

Analysis (transaction STAD) calculates the resource usage of individual transactions for ABAP systems and provides a detailed analysis of a transaction and the dialog steps. The selection criteria include user, transaction, program, and task type, start date, and start time. The statistical records contain detailed information about: Proportions of the response time Database accesses Memory use RFC calls

ST03 Or STO3N:- The ST03 Workload Monitor is the central access point for analyzing performance problems in the SAP system. ST03N is a revised version of transaction ST03. In current SAP Releases transaction ST03N replaces transaction ST03 and is automatically started when you enter transaction code ST03. -Number of users working on the different instances -Response time distribution -Transactions with the largest response times and database time -Look at the DB time. It should not be more than 40% of the response time ST12:-Combines both ABAP and Sql Performance trace and used for tracing work process , program/ transaction or user. ST02:- you can see the following overview of the SAP Memory underneath the Buffer overview Roll area, Page area, Extended memory and Heap memory Current user, Max use, In memory and On disk ST06:- You can display the memory requirements and the swap space by choosing Detail analysis menu on the entry screen of transaction ST06. This displays the requirements and swap space either as a snapshot or from over a period of hours (buttons Memory and Swap). /SDF/MON:-Highly useful transaction it will gives various types of system snapshots for our reference like CPU, memory, process, SQL, application enqueues, Inbound and outbound snap-shots etc Based on snap-shots you can do system performance analysis to identify contention and load balance. -Run Sap transaction/Program /SDF/MON. Yes the transaction code and program name is the same. -Click the SCHEDULE New Monitoring button on the initial screen of sdf/mon. -Name your trace and tell SAP what, when and how often you would like system to collect snap-shots. -Submitted your request through execution button. Shared Cache:- is high performance distributed and replication cache system built for .Net applications running in server farms. provides distributed and replicated cache topologies which minimize load factor on your databases. Your advantages from this point of view is quite simple, you can scale out your application linear only with hardware and non additional software cost.

Shared Cache is written in C# and its 100% managed code. Library Cache:- The library cache includes the shared SQL areas, private SQL areas (in the case of a shared server configuration), PL/SQL procedures and packages, and control structures such as locks and library cache handles. CBO:- The CBO determines which execution plan is most efficient by considering available access paths and by factoring in information based on statistics for the schema objects (tables or indexes) accessed by the SQL statement. The CBO also considers hints, which are optimization suggestions placed in a comment in the statement. The optimizer compares the costs of the plans and chooses the one with the lowest cost INDEX:- The index contains not only the indexed value, but also the rowids of rows in the table having that value. Therefore, if the statement accesses other columns in addition to the indexed columns, then Oracle can find the rows in the table by using either a table access by rowid or a cluster scan

ANALYZE INDEX index_name COMPUTE STATISTICS ANALYZE INDEX index_name VALIDATE STRUCTURE SQL> select lf_blks, del_lf_rows from index_stats;
INDEX SKIP SCAN:- Consider, for example, a table employees (sex, employee_id, address) with a composite index on (sex, employee_id). Splitting this composite index would result in two logical subindexes, one for M and one for F. For this example, suppose you have the following index data: (`F',98) (`F',100) (`F',102) (`F',104) (`M',101) (`M',103) (`M',105) The index is split logically into the following two subindexes: The first subindex has the keys with the value F. The second subindex has the keys with the value M. INDEX JOINS:- An index join is a hash join of several indexes that together contain all the table columns that are referenced in the query. If an index join is used, then no table access is needed, because all the relevant column values can be retrieved from the indexes. An index join cannot be used to eliminate a sort operation. The index join is available only with the CBO. ST05:-go to ST05, Click on Trace on, let all user or particular user accomplish his activity then once again go to ST05 and trace off output:/usr/sap/PRD/DVEBMGS00/TRACE000.LOG

HOW TO IDENTIFY EXPENSIVE SQL QUERY: a) Is it logical IO's per execution? b) Is it physical IO's per execution? c) Is it cpu used? d) Is it based on number of parse calls? e) Is it elapsed time used? f) Is is number of executions? g) Is is size consumed in shared pool? h) Is is number of child versions found? OS Bottle necks:- Testing of input and output rates as described in preceding section is an effective way to isolate performance of the application subsystem, although it does not describe end-to-end performance. You should also test end-to-end performance because some bottlenecks cannot be identified until multiple resources begin to contend for the same shared resource (for example, the MessageBox database).

Summary
1) Analysis and tuning a specific SAP transaction Use SAP transaction STAD (and ST03n) to identify most time consuming area and start with it Use specific analysis tools for each area (e.g. SE30 for ABAP or ST05 for SQL) Do not care about system wide metrics (usually) 2) Analysis and tuning the general system performance Use transactions like DBACKCOKPIT, ST02, ST03n or ST06 to get metric values and create the "big picture" Identify the most time consuming area and the causer (sometimes you need to drill down through various levels down to OS) and start with it If various transactions in sum cause the high system load use the "Analysis and tuning a specific SAP transaction" approach for each 3) Analysis and tuning the general system performance by better hardware utilisation Tune your SAP itself system first (Analysis and tuning the general system performance) to get a valid system state Include all special requirements (like HA) when using more system resources to get better performance Measure with platform specific tools