|ztta/roll_extension||Limit for Extended Memory|
|ztta/roll_extension_dia||EM Quota for Dialog Work Processes|
|ztta/roll_extension_nondia||EM Quota for Non-Dialog Work
|abap/heap_area_dia||Heap Memory Limit for Dialog Work
|abap/heap_area_nondia||Heap Memory Limit for Non-Dialog
|abap/heap_area_total||Total Quota for Heap Memory|
|ztta/roll_area||Size of Roll Area Roll Area|
|ztta/roll_first||Size of the Initial Allocation
from the Roll Area
|abap/heap_area_total||Heap Memory Limit|
|em/initial_size_MB||Extended Memory Pool Size|
|rdisp/ROLL_SHM||Roll Buffer Size|
|rdisp/ROLL_MAXFS||Maximum Roll File Size|
|rdisp/PG_SHM||Size of the Paging Buffer|
|rdisp/PG_MAXFS||Maximum Size of SAP Paging File|
|em/blocksize_KB||Segment Size for the Extended
Memory Memory Management Statistics
|em/stat_log_size_MB||Statistics – User Context Size|
|em/stat_log_timeout||Statistics – User Context Size|
Tcode SM50 is used to see the workprocess overview in application
server you are logged in.
There are several fields diplayed in the work
process overview screen.
Each of the field value is described in below
Menu path for this tcode is
Tools –> Administration–> Monitor –>System monitoring –> Process –> overview
|No||This is the work process number and is unique to each work process.|
|Type||This denotes the type of work process.
These are the possible values for type field
|PID||Process ID which is a unique no to identify the process at os level.|
|Status||This shows the status of work process like PRIV mode etc..|
|Ended||Work process has been terminated because of some error in SAP kernel.
Running – work process is busy processing user request.
Waiting – work process is ready to accept user request.
PRIV – Work process running with heap memory (noramally basis admins terminate the dia wp if it enters priv mode).
|Completed||The work process has been terminated and they can not be restarted.|
|Reason||If a work process status is stopped, this field gives the reason why it is stopped.|
|Start||This field tells if the dispatcher can restart the work process if it gets terminated.|
|Err||Err field gives the no of times the work process .|
|Sem||Number of semaphore.
With Green background =>Process is holding the semaphore.
With Red background => Process is waiting for the semaphore.
|CPU||The CPU Time utilization by each work process format minutes:seconds|
|Time||The time that has been consumed processing the current request (in seconds).|
|Report||The name of report which is being executed|
|User||Name of user whose request is currently being executed.|
|Action||For the work process with status “running”, this displays the current action.|
|Table||The DB tables that is accessed previously by work process.|
In UNIX, if Roll memory gets full Heap memory is occupied and if heap memory gets full extended memory is used.
in windows it is different, after roll memory (ztta/roll_first) is
filled the work process uses Extended memory, after extended memory is
fill then remainder of roll memory ( ztta/roll_area – ztta/roll_first)
is used soon..
|Unix or Unix like systems||Windows|
or HM Exhaust
or EM Exhaust
or EM Exhaust
or HM Exhaust
SAP has an independent locking processover and above the database that it runs on, a LUW on SAP is may have different meaning and execution to what it is on Oracle or DB2.
Lock Transaction SM12:
The SAP system is equipped with a special lock mechanism the purpose of the lock mechanism is to prevent two transactions from changing the same data on the database simultaneously.
Locks are defined generically as “lock objects” in the Data Dictionary. Lock entries are usually set and deleted automatically when user programs access a data object and release it again.
The SAP lock mechanism is closely related to the Update Mechanism .
The documentation is divided into the following sections:
SAP Lock Concept: describes how the SAP lock works. You have to understand the concepts described here in order to use the SAP locks when you are programming applications. You can use different types of locks. The lock mode describes what type of lock it is.
S (shared Lock): Several users can access locked data at the same time in display mode. Requests from further shared locks are accepted, even if they are from different users. An exclusive lock set on an object that already has a shared lock will be rejected.
E(Exclusive): An exclusive lock protects the locked object against all types of locks from other transactions. Only the same lock owner can reset the lock .
Important Profile Parameters: A list of the profile parameters relevant for the lock concept.
enque/table_size: Size of the lock table managed by the enqueue server in the main memory. The lock table contains information on which locks are currently held by whom.
In this case, you should check whether the update server is functioning correctly, since the lock table can grow very fast if the update function stops. If no update problems exist, you can use this parameter to increase the size of the lock table.
The Computing Center Management System (CCMS) monitors the status of the lock table constantly and outputs warnings if the space available is not adequate.
Default value: 4096kb
rdisp/wp_no_enq: Number of enqueue work processes that are to run on this instance.
rdisp/enqname: Name of the application server that provides the enqueue service.
Managing Lock Entries: It describes lock management , which you use to display, check, and delete lock entries. This may be necessary if the SAP dispatcher, the operating system, or the network connection fails, and the dispatcher cannot delete lock entries. In this case, invalid lock entries remain effective and block access to the locked data when the system is restarted.
How to monitor a Lock entry:In SM12 check any lock entry older than 2 days, if any outdated entry check the corresponding User and check the user online or offline in AL08 and contact that User (you can get the User info from su01) and inform about the lock else if the user is offline release the table from lock by deleting the lock.
Some important categories of SAP system parameters.
You can view parameters using RZ11 and change them using RZ10.
or use report RSPFPAR through SA38.
* ES/* : Related to extended memory settings
* INSTANCE* : Identify an instance or server
* ABAP/* : Related to program execution, including heap settings
* AUTH/* : Related to authorization
* DBS/<DB Type/* : Database specific parameters
* EM/* : General system related settings
* ENQUE/* : Settings for the enqueue WP (or standalone ENQ server)
* GW/* : SAP Gateway related settings
* ICF/* & ICM/* : Settings for the Internet control framework and ICM
* LOGIN/* : Controls the logon environment (such a multiple sessions etc)
* MS/* : Message server related settings
* RDISP/* : Controls the dispatcher & dispatcher controlled processes
* STAT/* : Statistics collector related parameters
* SCSA/* : Shared common system area parameters
* ZTTA/* : Extended memory related parameters
The Following are the transaction codes used for the System Monitoring:
This Traction is used for Check for Lock Entries. There may be old locks still in place from transactions that did not release, or from when the user was cut off from the Network. If any lock entries are exist then we have to check since how long this lock existing. If, this lock existing from more than one day then we should check that particular User is available or not (By using the Transaction Code AL08). If he is not available then Delete that lock. Otherwise we should wait 1 or 2 Days.
This Transaction is used for Check for any Errors in Update Records. A failed or “Update Terminate” is an update to the failed database. These failed Updates occurs when a user entry or transaction is not entered or Updated in database. And we should check Whether Update is ACTIVE or not. And also we should check any Update Records are terminated.
This Transaction is used to check System Logs. After hitting the traction we should goto System log–> Chooseà All Remote System logs, and set Date and time to before the Last log review. And we should check whether any Errors, Warnings, Security Messages, Database, Abends, Any other different Events are there.The log is important because unexpected or unknown warnings and errors could indicate a serious problem.
This Transaction is used to check that all Application Servers are UP. And also This transaction is a central transaction from which you can select the instance to be monitor.
This Transaction is used to check Work Process Overview and for Systems with out Servers. Here all work processes with a “Running” or “Waiting” State. If Batch Jobs are not Running, If all the work processes are in use, this transaction provide a hint of this problem.
This Transaction is used for System Trace. By this transaction we can trace that what are the operations performed on particular file by particular user on which dates.
This transaction is used for Buffer tuning or Buffer Statistics. And it is used to tune Buffer perameters of R/3. The Buffer is important because significant buffer swaping reduces performance. Look under “Swaps” for Red Entries. Regularly check these entries to establish trends and get a feel of the Buffer behaviour. And in this transaction we should Maintain “Hit Ratio” is in between 90 – 100% for all , and “Heap Memory” allocated should be “0” , and “Swaps” is 0.
This Transaction is used to Check Work Load Analysis of . Workload Analysis is used to determine System performance. Check Statistics and Record Trends to get a feel for the System’s Behaviour and Performance. Understanding the System when it is running well helps us to determine what changes may need to be made when it is not.
This Transaction is used for Database Performance Analysis. This transaction provides the ability to Monitor the Database in related to 1) In Shared Pool “SQL Area Get Ratio” should be 90 – 95% 2) In Log Buffer Allocation Retries / Entries <1% 3) In Data Buffer “Quality” should be in 90 – 95% 4) In Sorts Disk / Memory <1% 5) In Table Scan & Fetches “Long Table Scans” should maintain as minimum as possible. And we should check Detailed Analysis then we should hit “Detailed Analysis menu” Button in this screen. In that we can check Database Overview like “Exclusive Lock Waits” , “Wait Events”, “Buffer Busy Waits”, “ File System Request”, “ Database Message logs”, “ SQL Requests”, Summery Report for all activities, etc
This Transaction is used to Analyse ABAP Dumps or Short Dumps. This transaction is also used for Analyse and Determine why the error occurred and take corrective action. It looks for an excessive number of dumps, and also dumps of an unusual nature. A ABAP dump is generated when a report or transaction terminates as a result of a serious error. The system records in the System Log(SM21) and writes a snapshot of the program terminate to a special table.
This transaction is used to check all table Spaces and Indexes. Here we should check table spaces sizes. If any table used space is =>99 then we should increase add the space for particular table space. And this transaction is provides a way to examine database allocation. And this transaction is allows us to monitor items such as: a) DB Space History b) DB Analysis By this transaction we can view Database history by Dates and Times.
This Transaction is used to check database Backups. And in this we should we see successful Backups and Unsuccessful Backups list
This transaction is used to Check the users on the System. This transaction displays User Ids and Terminal Names who are currently logged on the system.
This transaction is used for Monitoring Background Jobs. Background are batch jobs scheduled to run at specific time during the day. Here we should check for cancelled jobs. Here If we want to check particular job then,we should enter the Job Name and enter User name in User name field or ‘*’ and hit execute Button. And verify that all critical jobs are successful.
If you haven’t got SAP Solution Manager installed and configured yet, give me a buzz, if you haven’t got the money, use the guide below 😉 cheap and cheerful and will keep you busy for a few hours every day.
Daily System Monitoring:
SM51 SAP Servers :
1- Check Availability of All Servers
2- Check Process Lists for All Servers for Unusual Processes or Activities (e.g. Extra-long execution times, too many errored processes, too many sequential reports)
SM66 Global Process Monitor:
1- Check for over-all system process utilization
2- Are Batch id’s taking up too many DIA processes
3- Is one user running too many BGD jobs for the same report
4- Is one server being used heavily compared to others
SM21 System Logs:
1- Is there any repetitive errors in the system log
2- Any unusual repetitive failed login attempts
ST22 Short Dumps:
1- Except ‘Time-Out’ errors, is there any short dumps.
SMLG Logon Groups:
1- Check load distribution (Menu: Goto–>Load Distribution)
2- Are server response times acceptable? (< 2 sec)
3- Is user distribution even among active servers
ST03N Workload Analysis:
1- Check is daily, weekly and monthly totals are being calculated for each server
2- Check for Avg. Dialog Response Times. Is it below 2 secs
SM12 Lock Overview:
1- Check for outdated lock records
2- Verify that these lock records are not actively being used and delete these lock records if they are obsolete
SM13 Update Records:
1- Check if the ‘Update System’ is active.
2- If not active, investigate what happened
3- Activate ‘Update System’ after fixing the problem
4- Review update records of past two days and delete if errored or obsolete
SM37 Background Job log:
1- Check if the are any critical jobs that were canceled
2- Identify/Fix the problem
3- Contact canceled job user for details
4- Reschedule if needed
SP01 Spool Request overview:
1- Check if there unusual number of errors in spool (>100)
2- Check if there are spool request with more then 200 pages
3- Should not be a need to delete any as the daily job should handle, unless too many spools are old.
ST04 Database Activity Monitor:
1- Check ‘Data Buffer’ and ‘Shared Pool Cache’ quality
2- Investigate and make suggestions to the team to improve quality of these buffers
DB02 Database Performance:
1- Check ‘Current Sizes’ to see if any tablespace is above %90
2- Add new datafile to the tablespace if needed
3- Check if there is space-critical objects
4- Check if there is any missing objects in DB or R/3 Data Dictionary
DB16 Database Check, Overview of message:
1- Check if there is any messages
2- Take immediate action to fix the problem
3- Notify the team if there is any parameter changes or assistance needed for Production Systems
DB24 Database Operations Logs:
1- Check if all DB Operations are executed
2- Check if any of the operations generated any errors
3- Fix the problem. Notify team if needed
DB12 Database confirm backup success:
1- Check to see that the previous backup was successful
2- If a backup is currently running check its status
3- If the last backup failed , check the reason correct and resubmit.
ST06 OS Monitor:
1- Click on ‘Detailed Analysis menu’
2- Click on ‘CPU’ in ‘Previous Hours’ Group
3- Check if at any past hours is > %80
4- Notify Team if there is any such case
Types of Buffers
The name table (nametab) contains the table and field definitions that are activated in the SAP System. An entry is made in the Repository buffer when a mass activator or a user (using the ABAP Dictionary, Transaction SE11) requests to activate a table. The corresponding name table is then generated from the information that is managed in the Repository.
The Repository buffer is mainly known as the nametab buffer (NTAB), but it is also known as the ABAP Dictionary buffer.
Table definitions: TTAB
Field descriptions: FTAB
Initial record layouts: IREC Buffer (Contains the record layout initialized depending on the field type)
Short Nametab: SNTAB Buffer (A short summary of TTAB and FTAB buffers)
The description of a table in the Repository is distributed among several tables (for field definition, data element definition and domain definition). This information is summarized in the name table. The name table is saved in the following database tables:
DDNTT (table definitions)
DDNTF (field descriptions)
The Repository buffer consists of four buffers in shared memory, one for each of the following
The Short nametab and Initial record layouts are not saved in the database. Instead, they are derived from the contents of tables DDNTT and DDNTF.
When access to a table is requested, the database access agent embedded in each work process first reads the Short nametab buffer for information about the table. If the information is insufficient (for example, the SELECT statement uses a non-primary key) it accesses the Table definitions buffer and then the Field descriptions buffer.
By reading the Repository buffers, the database access agent knows whether the table is buffered or not. Using this information, it accesses the table buffers (partial buffer or generic buffer) or the database
Program buffer: Also called as
SAP executable buffer
PXA (Program Execution Area)
Stores the compiled executable versions of ABAP programs (loads).
The contents of this buffer are stored in tables D010L (ABAP loads), D010T (texts) and D010Y (symbol table)
The SAP calendar buffer stores all defined factory and public holiday calendars.
Calendars are stored in the database tables TFACS and THOCS.
There are two kinds of SAPgui buffers:
The following table shows the SAPgui buffers and their functions:
The buffer has a directory structure. This means that if the shared memory is configured too small, only the required data is loaded; there is no LRU displacement of the contents of the buffer.
Presentation buffer (Screen Buffer): Stores the generated screens (DYNPRO loads)
Menu buffer (CUA Buffer): Stores objects from the SAPgui.
For example, menus, pushbutton definitions.
The buffer has directory structure and supports LRU displacement.
The menu buffer is adjusted by amending its instance profile parameters
The CUA buffer holds objects from the GUI interface, such as menus, pushbuttons, and so on. In the database, these objects are held in tables D342L and D345T. Its size is expressed in KB. The standard SAP recommendation is: Up to 2500 KB for small systems, up to 3000 KB for medium systems and up to 6000 KB for large systems.
SAP ARCHIVING MANAGEMENT:
As the usage of SAP database increases it’ll results in huge amounts of enterprise data, which is stored in SAP R/3. The new updated data is entered into the system while the old data still resides in the SAP enterprise system. So the Database size increases rapidly. Since some of the old data is critical, it cannot be deleted. Hence, a SAP database keeps on expanding rapidly and enterprise systems, which have limited data retention abilities for a few years, suffer from problems such as data overflow, longer transaction processing times, and performance degradation.
The solution of this problem has led to the concept of Data Archiving in SAP. Data Archiving removes out-of-date data from the SAP database that the R/3 system does not need online, but can be retrieved on a later date, if required. This data is known as archived data and is stored at an offline location. Data Archiving is nothing but removal of Application Data belonging to completed business process from the database. Data Archiving not only consistently removes data from the database but also ensures data availability for future business requirements. The removed data is compressed and stored in another location. Before deleting data in the database, a delete program compares the contents of the archive files with the same data stored in the database; deletion takes place only if both sets of data are identical. We can use the Transaction SARA for Archiving management. For each archive run, a specific program variant determines which data should be archived. Depending on the archive object, there maybe several parameters to maintain. During an archive run, the status can be monitored in RZ20.
Data archiving is an administrative task that must be performed regularly, particularly if you are facing fast growing data volumes. How often you archive largely depends on the growth rate of your database tables.
Three Phase Archiving Process
Data archiving process comprises three major phases. They are:
1. Creating an archive file
2. Removing the archived data from the database
3. Transferring the archived files to a location outside the SAP database
Creating Archive Files
The archived files of data are created in the SAP database by the Archiving Management system. The Management system reads the data from the database and writes it to the archive files in the background. In instances of archived files exceeding the maximum specified limit, or if the number of data objects exceed the stipulated limit in the system, then the system automatically creates new archive files.
Deleting files from the Database
While archiving management system writes data on the archive files, another program deletes it from the database permanently. The program checks whether the data has been transferred to the archive. It is quite important too as it is the last check performed by the system before deleting data permanently from the database. Several deletion programs run simultaneously, because the archiving program is much more faster than the deletion programs. This is important as it increases the efficiency of archiving process.
Transferring Archive Files
Once the Archive management system has finished archiving the data, the next step is to save the archived files at a different location other than the SAP database. This can be accomplished by an automated process in the system or by a manual process. This step is optional since many enterprises may wish to keep the archived files within the current database. However, large enterprises transfer their data periodically as a part of their data archiving processes
Background processing is used to: Reduce the load on the dialog processor, as the dialog wp duration is limited.
You can define and schedule background jobs in two ways from the Job Overview:
- Directly from Transaction SM36.
- The Job Wizard : To use the Job Wizard, start from Transaction SM36, there you’ll find Job Wizard
- Call Transaction SM36.
- Assign a job name. Decide on a name for the job you are defining and enter it in the Job Name field.
- Set the job’s Priority or Job Class
- High priority: Class A
- Medium Priority: Class B
- Low priority: Class C
Target server field, indicate whether to use system load balancing.
- For the system to use system load balancing to automatically select the most efficient application server to use at the moment, leave this field empty.
- To use a particular application server to run the job, enter a specific target server.
- If spool requests generated by this job are to be sent to someone as email, specify the email address. Choose the Spool list recipient button.
- Define when the job is to start by choosing Start Condition and completing the appropriate selections. If the job is to repeat, or be periodic, check the box at the bottom of this screen.
- Define the by choosing Step, then specify the ABAP program,external command or external programe to be used for each step.
- Save the fully defined job to submit it to the background processing system.
Status of Background Job:
Scheduled: Job created but start condition not defined.
Released: Job completely defined and is waiting for selection
Ready: Job has been selected for execution
Active: Job is being executed by a Background processor
Finished: Job successfully completed.
Canceled: Job terminated.
Time Based : Immediate, At a date or time, On a chosen workday
Event Based: After an event, After a Job, After an operation mode switch.
Using SM37 you can monitor the Background Jobs.