Daily monitoring activities in ABAP System
SM50 : (Work Process Overview Local)
We need to consider the freely available workprocess specified in the status column. Keenly monitor the reason column as it specifies whether a workprocess is running in private mode. Restart after error contains two values yes and no. yes means after killing of workprocess it should be started automatically. No defines after killing of workprocess it should not be started automatically.
This transaction code will be useful to view the processes that are running currently in an sap instance. In this view you can check whether there are free workprocesses to execute the processes. If all the workprocesses are in running state and no work process is idle it means that wait times will increase for the processes that are waiting in the dispatcher queue leading to performancedegradation. If you find that there are no free workprocceses for maximum times that you may consider, increasing the number of workprocesses.
There are 7 types of workprocesses of which we can’t monitor Message server and Gateway server in sm50.We have separate t-codes to monitor those services.
SM66 : (Global process overview) This transaction code is same as sm50 but we can monitor the workprocess of all the instances. It displays the memory consumed by workprocess
This transaction code will be useful to view the processes that are running across all instances/application servers of a SAP system. Similar to SM50 checks can be done in this transaction as well.
SM51 : (Application servers status)
This transaction code is to check the active servers.
Special Note: This is very dangerous T-code. So I Sunil Kumar can’t explain the bad of it.
This transaction code will be useful to view all the hostnames and application servers status. If any application server is down, the same can be identified using status of the server column. We can also figure out different Message types (Dialog, Batch, Update, Upd2, Spool, ICM etc) configured for the respective servers.
SM12 : (Lock entry list)
Special Note: It depends on the company’s policy that for how long a lock can be tolerated. As per the rule of thumb if it is more than 12 hours. Than consider to delete the lock.
This transaction code will be useful to view all the sap locks that are present in the system. As part ofmonitoring, we need to look for any old sap locks that are more than 1 day. If any such
locks, we need to analyse the reason for that lock for such longer duration and take actions accordingly. A lock can be set for such a long duration due to a long running background job or a lock is not released due to an application error or a program terminated abruptly but lock not released etc.
ST22 : (ABAP Dumps )
This transaction code will be useful to view all the abap dumps that have occured in the system on a given day. As part of daily monitoring, it is the responsibility of the basis administrator to analyse the dumps and take necessary actions to avoid issues.
Some of the examples of abap dumps are timeout issue, database space issue, spool overflow issue etc
SM21 : (System log)
This transaction is useful to view the log of the sap system for various operations. This log will be very useful to identify various issue in advance and to take necessary measures. System log is the place to check out for any timeout, network issues, database space issues, message server issues, spool overflow, locktable overflow etc issues. Additional details : SAP System log
SM58 : (Failed TRFC) :
This transaction code is useful for checking the failed trfcs and deleting the same
SM13 : (Update Requests overview)
This transaction is useful to figure the status of update system. Incase an update is inactive we can figure out the same from this transaction and necessary action can be taken and update can be activated again.
Update got deactivated. what is the reason for update deactivation? How to activate the update ?
SM14 transaction can be called internally from SM13. These both transactions are useful for update administration.
In SM13, you can select status (canceled, to be updated, v1 executed, v2 executed, all ) and time interval during which you would like to view the status execute to check the overview of updates as per the status and time interval selected.
In case of canceled updates, analysis to be done whether to repeat update.
ST02 : (Application Buffer Hit Ratio)
This transaction will be used to monitor
Buffer statistics like hitratio, swaps, db access details, size of buffer and free size of buffer etc
Important statistics related to Roll area, Page area, Extended memory and heap memory
Call statistics like select, insert, update and delete
As a basis administrator, it is our responsibility to ensure there is more hit ratio for the buffers and less swaps to ensure efficient performance of the sap system. In case you see there are more swaps and less hit ratios for most of the buffers, then tuning buffers to be carried out to ensure optimal performance.
DB12 (Database Backup logs) : This transaction is useful to check the details of
last successful backup
overview of database backups ( Success / failure of backup with log details)
Archiving directory status (Free space of oraarch )
Overview of redolog files ( Number of redologs that are not yet backed up)
overview of redolog backups (Success / failure of backup with log details)
DB13 (DBA Planning calender) :
This transaction will be useful to schedule various database backups & clean up jobs like ( whole database backup offline/online, Full backup online/offline, incremental backup offline/online, redolog backup, update statistics, check db, cleanup logs, compress database, verify database, initialize tape and validate structure jobs).
In this transaction, you can also check the status of every job that was scheduled and can reschedule in case of failures.
DB14 (DBA operations log) :
This transaction will be useful to check the status of following :
Database backup
Redolog backup
BRSPACE log (extend tablespace issues etc)
BRCONNECT operations (Update optimiser statistics , database check etc)
As an sap basis administrator it is our responsibility to check and ensure backups and other cleanup jobs are successful everyday. Incase of failures, should figure out root cause and take actions like rescheduling and ensure these jobs are successful.
SM37 ( Background Job Monitoring) :
This transaction will be useful to have an overview of jobs with different statuses.
As part of daily monitoring, SAP basis administrator should use this transaction to findout canceled jobs and active jobs(for eg: long running - more than 24hrs etc).
Incase of canceled jobs, root cause for the failure to be figured out from the logs of the respective job and to be actioned by rescheduling etc.
Incase of long running jobs, we need to figure out the reason for long running and action them accordingly.
In SM37, using extended job selection option, we can even select the jobs based on start condition, steps (like abap program, external command or external program), period etc
How to identify long running jobs in sap ?
How to troubleshoot a background job running for long duration in sap?
ST04 (Database Performance Hit Ratio) :
This transaction will be useful for (oracle) database administration. In this screen, goto Alerts and drill down further. Click on "Database Check" to find out any errors or warnings related to database like MISSING_STATISTICS, STATS_TOO_OLD, LAST_BACKUP_FAILED, LAST_ARCHIVE_FAILED etc. After going through the error or warning in details take
necessary corrective actions based on the error like running update stats again, re-triggering backup etc
Under Alerts, you can view Alert monitor which will summarize status of the database under different heads like
Space Management
Performance
Backup/restore
SAP Consistency
Health
Drill down on each of these to find out potential problems. These are color coded for ease of administrator (Red for errors, yellow for Warnings and Green for OK status)
For Eg: If PSAPSR3 tablespace is >90%, you can see Space management in red color. Then it is the responsibility of Basis administrator to take necessary actions on the same.
SP01 ( Check Spool status ) :
This transaction is useful to find out the status of spool request and output request. In SP01 transcation, you can list the spool requests or output requests between a given interval.
In the list generated, you can check out the status of spool requests and findout any errors by drilling down further.
For eg: if so many spools are in waiting status, find out whether output device is available or not.
If many spool are in error status, figure out if there is any network issue and take necessary actions.
What are the different Spool statuses and their significance?
If customers complain that they are not able print anything from SAP, check out whether there is any spool overflow.
What is spool overflow ? How to troubleshoot spool overflow issue ?
SP02 ( Check Spool status ) : Same as sp01 but local
St06(Application Level Monitoring) :
We can monitor the following by executing this T-Code
Cpu utilization
Hourly cpu utilization
Page in kb/h peak
Page out kb/h peak
Min free memory
In detail analyses menu se can check all the relevant details of Which we can also monitor from OS level.
St07(Application Level Monitoring) : We can monitor the following in this t-code.This T-code is helpful in deciding in advance that whether we should go for logon load balancing or not.
One dialog workprocess can serve maximum upto 10 users.
Each dialog workprocess consume 75-300 mb of memory.
E.g.- If there are 10 workprocesses and we have 50 users. On an average a user can consume upto 187 mb of memory and we have only 8 gb of ram. Than we can consider the following
187*50=9350 mb(around 10 gb of memory)
But in this example we have only 8 gb of ram,If hardware allows us to increase the ram than we can.Otherwise build another server and perform logon load balancing(smlg).
Note-This is not the best practice; We should consider the active users.Only active users can generate the dialog steps. It is upto user’s discretion and intelligency. Sunil Kumar(sunilrajputaec@gmail.com) is not responsible for any kind of disturbance for any object in the world caused by this document.
Users v/s workproces.
SXI_Cache : This Tcode is specific to XI or PI system. This Tcode is used to findout whether cache refresh is happening or not. Incase if cache refresh is happening successfully, it will indicate the same in green color. Otherwise it will be in red indicating a problem with cache refresh.
If there is a problem with cache refresh then basis administrator has to troubleshoot the same.
SLDCHECK : This Tcode will be useful to figure out whether connection to the SLD system from the system on which you are testing is fine or not. In case the connection is fine, all checks will appear in green. Incase of any issues, it will appear in red or yellow and then basis administator has to troubleshoot it and make sure SLDCHECK is working fine.
Ensuring SLDCHECK is working fine is important to keep all systems in the landscape in sync.
SXI_MONITOR : This TCode is specific to XI or PI system. This transaction will be useful to figure out any errors or warnings in the processing of XI or PI messages. In case of any issues, this needs to be informed to functional team and should be troubleshooted accordingly with the functional team inputs.
DBO1 : This transaction code is useful to find out the database locks that are present in the SAP system.
As part of daily monitoring, SAP Basis administrator has to figure out if there are any long pending locks more than 1 day etc and analyse reasons for the same. Sometimes if programs/jobs gotterminated abruptly without removing the database locks set, this will lead to performance issues as other programs which needs that lock cannot set etc and they have to wait indefinitely as these locks won't get released automatically. In case of any long pending locks, Basis administrators should contact DBA team if any and figure out the reason for these locks and action accordingly
We need to consider the freely available workprocess specified in the status column. Keenly monitor the reason column as it specifies whether a workprocess is running in private mode. Restart after error contains two values yes and no. yes means after killing of workprocess it should be started automatically. No defines after killing of workprocess it should not be started automatically.
This transaction code will be useful to view the processes that are running currently in an sap instance. In this view you can check whether there are free workprocesses to execute the processes. If all the workprocesses are in running state and no work process is idle it means that wait times will increase for the processes that are waiting in the dispatcher queue leading to performancedegradation. If you find that there are no free workprocceses for maximum times that you may consider, increasing the number of workprocesses.
There are 7 types of workprocesses of which we can’t monitor Message server and Gateway server in sm50.We have separate t-codes to monitor those services.
SM66 : (Global process overview) This transaction code is same as sm50 but we can monitor the workprocess of all the instances. It displays the memory consumed by workprocess
This transaction code will be useful to view the processes that are running across all instances/application servers of a SAP system. Similar to SM50 checks can be done in this transaction as well.
SM51 : (Application servers status)
This transaction code is to check the active servers.
Special Note: This is very dangerous T-code. So I Sunil Kumar can’t explain the bad of it.
This transaction code will be useful to view all the hostnames and application servers status. If any application server is down, the same can be identified using status of the server column. We can also figure out different Message types (Dialog, Batch, Update, Upd2, Spool, ICM etc) configured for the respective servers.
SM12 : (Lock entry list)
Special Note: It depends on the company’s policy that for how long a lock can be tolerated. As per the rule of thumb if it is more than 12 hours. Than consider to delete the lock.
This transaction code will be useful to view all the sap locks that are present in the system. As part ofmonitoring, we need to look for any old sap locks that are more than 1 day. If any such
locks, we need to analyse the reason for that lock for such longer duration and take actions accordingly. A lock can be set for such a long duration due to a long running background job or a lock is not released due to an application error or a program terminated abruptly but lock not released etc.
ST22 : (ABAP Dumps )
This transaction code will be useful to view all the abap dumps that have occured in the system on a given day. As part of daily monitoring, it is the responsibility of the basis administrator to analyse the dumps and take necessary actions to avoid issues.
Some of the examples of abap dumps are timeout issue, database space issue, spool overflow issue etc
SM21 : (System log)
This transaction is useful to view the log of the sap system for various operations. This log will be very useful to identify various issue in advance and to take necessary measures. System log is the place to check out for any timeout, network issues, database space issues, message server issues, spool overflow, locktable overflow etc issues. Additional details : SAP System log
SM58 : (Failed TRFC) :
This transaction code is useful for checking the failed trfcs and deleting the same
SM13 : (Update Requests overview)
This transaction is useful to figure the status of update system. Incase an update is inactive we can figure out the same from this transaction and necessary action can be taken and update can be activated again.
Update got deactivated. what is the reason for update deactivation? How to activate the update ?
SM14 transaction can be called internally from SM13. These both transactions are useful for update administration.
In SM13, you can select status (canceled, to be updated, v1 executed, v2 executed, all ) and time interval during which you would like to view the status execute to check the overview of updates as per the status and time interval selected.
In case of canceled updates, analysis to be done whether to repeat update.
ST02 : (Application Buffer Hit Ratio)
This transaction will be used to monitor
Buffer statistics like hitratio, swaps, db access details, size of buffer and free size of buffer etc
Important statistics related to Roll area, Page area, Extended memory and heap memory
Call statistics like select, insert, update and delete
As a basis administrator, it is our responsibility to ensure there is more hit ratio for the buffers and less swaps to ensure efficient performance of the sap system. In case you see there are more swaps and less hit ratios for most of the buffers, then tuning buffers to be carried out to ensure optimal performance.
DB12 (Database Backup logs) : This transaction is useful to check the details of
last successful backup
overview of database backups ( Success / failure of backup with log details)
Archiving directory status (Free space of oraarch )
Overview of redolog files ( Number of redologs that are not yet backed up)
overview of redolog backups (Success / failure of backup with log details)
DB13 (DBA Planning calender) :
This transaction will be useful to schedule various database backups & clean up jobs like ( whole database backup offline/online, Full backup online/offline, incremental backup offline/online, redolog backup, update statistics, check db, cleanup logs, compress database, verify database, initialize tape and validate structure jobs).
In this transaction, you can also check the status of every job that was scheduled and can reschedule in case of failures.
DB14 (DBA operations log) :
This transaction will be useful to check the status of following :
Database backup
Redolog backup
BRSPACE log (extend tablespace issues etc)
BRCONNECT operations (Update optimiser statistics , database check etc)
As an sap basis administrator it is our responsibility to check and ensure backups and other cleanup jobs are successful everyday. Incase of failures, should figure out root cause and take actions like rescheduling and ensure these jobs are successful.
SM37 ( Background Job Monitoring) :
This transaction will be useful to have an overview of jobs with different statuses.
As part of daily monitoring, SAP basis administrator should use this transaction to findout canceled jobs and active jobs(for eg: long running - more than 24hrs etc).
Incase of canceled jobs, root cause for the failure to be figured out from the logs of the respective job and to be actioned by rescheduling etc.
Incase of long running jobs, we need to figure out the reason for long running and action them accordingly.
In SM37, using extended job selection option, we can even select the jobs based on start condition, steps (like abap program, external command or external program), period etc
How to identify long running jobs in sap ?
How to troubleshoot a background job running for long duration in sap?
ST04 (Database Performance Hit Ratio) :
This transaction will be useful for (oracle) database administration. In this screen, goto Alerts and drill down further. Click on "Database Check" to find out any errors or warnings related to database like MISSING_STATISTICS, STATS_TOO_OLD, LAST_BACKUP_FAILED, LAST_ARCHIVE_FAILED etc. After going through the error or warning in details take
necessary corrective actions based on the error like running update stats again, re-triggering backup etc
Under Alerts, you can view Alert monitor which will summarize status of the database under different heads like
Space Management
Performance
Backup/restore
SAP Consistency
Health
Drill down on each of these to find out potential problems. These are color coded for ease of administrator (Red for errors, yellow for Warnings and Green for OK status)
For Eg: If PSAPSR3 tablespace is >90%, you can see Space management in red color. Then it is the responsibility of Basis administrator to take necessary actions on the same.
SP01 ( Check Spool status ) :
This transaction is useful to find out the status of spool request and output request. In SP01 transcation, you can list the spool requests or output requests between a given interval.
In the list generated, you can check out the status of spool requests and findout any errors by drilling down further.
For eg: if so many spools are in waiting status, find out whether output device is available or not.
If many spool are in error status, figure out if there is any network issue and take necessary actions.
What are the different Spool statuses and their significance?
If customers complain that they are not able print anything from SAP, check out whether there is any spool overflow.
What is spool overflow ? How to troubleshoot spool overflow issue ?
SP02 ( Check Spool status ) : Same as sp01 but local
St06(Application Level Monitoring) :
We can monitor the following by executing this T-Code
Cpu utilization
Hourly cpu utilization
Page in kb/h peak
Page out kb/h peak
Min free memory
In detail analyses menu se can check all the relevant details of Which we can also monitor from OS level.
St07(Application Level Monitoring) : We can monitor the following in this t-code.This T-code is helpful in deciding in advance that whether we should go for logon load balancing or not.
One dialog workprocess can serve maximum upto 10 users.
Each dialog workprocess consume 75-300 mb of memory.
E.g.- If there are 10 workprocesses and we have 50 users. On an average a user can consume upto 187 mb of memory and we have only 8 gb of ram. Than we can consider the following
187*50=9350 mb(around 10 gb of memory)
But in this example we have only 8 gb of ram,If hardware allows us to increase the ram than we can.Otherwise build another server and perform logon load balancing(smlg).
Note-This is not the best practice; We should consider the active users.Only active users can generate the dialog steps. It is upto user’s discretion and intelligency. Sunil Kumar(sunilrajputaec@gmail.com) is not responsible for any kind of disturbance for any object in the world caused by this document.
Users v/s workproces.
SXI_Cache : This Tcode is specific to XI or PI system. This Tcode is used to findout whether cache refresh is happening or not. Incase if cache refresh is happening successfully, it will indicate the same in green color. Otherwise it will be in red indicating a problem with cache refresh.
If there is a problem with cache refresh then basis administrator has to troubleshoot the same.
SLDCHECK : This Tcode will be useful to figure out whether connection to the SLD system from the system on which you are testing is fine or not. In case the connection is fine, all checks will appear in green. Incase of any issues, it will appear in red or yellow and then basis administator has to troubleshoot it and make sure SLDCHECK is working fine.
Ensuring SLDCHECK is working fine is important to keep all systems in the landscape in sync.
SXI_MONITOR : This TCode is specific to XI or PI system. This transaction will be useful to figure out any errors or warnings in the processing of XI or PI messages. In case of any issues, this needs to be informed to functional team and should be troubleshooted accordingly with the functional team inputs.
DBO1 : This transaction code is useful to find out the database locks that are present in the SAP system.
As part of daily monitoring, SAP Basis administrator has to figure out if there are any long pending locks more than 1 day etc and analyse reasons for the same. Sometimes if programs/jobs gotterminated abruptly without removing the database locks set, this will lead to performance issues as other programs which needs that lock cannot set etc and they have to wait indefinitely as these locks won't get released automatically. In case of any long pending locks, Basis administrators should contact DBA team if any and figure out the reason for these locks and action accordingly
No comments:
Post a Comment