Sapdatabase for all sap modules

sapdatabase provides you all sap modules information,latest updates

Sapdatabase for sap education

sapdatabase provides you all sap modules material,interview needs

Sapdatabase for all sap information

Sapdatabase makes you as a sap professional

Sapdatabase for outsourcing and online training

Sapdatabase provides you online training,outsource services for all sap modules in econamic fee

Sapdatabase for sap jobs

Sapdatabase makes job searching for you

Sunday, April 29, 2012

BI sizing based on Throughput sizing screens

Note: The values under Steps, ChngRec, Data/st, Data/Usr etc are the default values came when the screen for SRM sizing is opened. No manual entries were given.

Thursday, April 19, 2012

Sap system monitoring tasks with analytically

System Monitoring Daily Checklist




What to look for

Global Alerts


þ Red Alerts (depending upon thresholds set)

Workload Monitor


þ High Average response time



þ Active connection

SAP Instances (Graphic)or

SAP Instances (Text)

RZ02 or RZ03

þ Active / inactive application servers (Standard View)

þ Red alerts (Alert View)

Update records


þ Failed updates

System Log


þ Errors with type K-SAP Basis problems

þ Errors with type T-Transaction problems

þ ABAP Short dumps

(Sys Log errors also displayed in Alert views)

Batch Input Sessions



Background jobs


þ Canceled jobs

Work processes


þ Work processes that have restarted or are not running

þ Work processes that have long process times

Application Servers


þ Access individual app servers to monitor work processes, users, etc.

Gateway Monitor


þ View trace file for connection errors/failures

þ Activate/view statistics

Spool Request


þ spool errors



þ hit ratio - 90% - 95%

þ low freespace or directory entries

þ high object swapping

þ memory utilization (roll, page, ext., heap)

Workload by task type: Dialog, Background and Update


þ CPU time - approx. 40% of avg. response time

þ elapsed time -

þ avg. response times - approx. 1 second (1000ms) for dialog, <1 second for update

Dump Analysis


þ Short dumps

Current Statistical Records


þ Transaction code response times






What to look for

Database availability

Telnet to server

þ Issue R3trans -d to insure database is available

Backup Status - Monitor Backup and Archive logging


þ Display and /or Print Recovery Report

þ Verify Last Successful Backup Date and Time

þ Check Overview of Backup logs - Return Code of 0000

þ Check Free Space in Archive LOG directory

þ Check Status of most recent logs -

þ Check Overview of redo log backup logs - RC 0000

Database Performance : Tables & Indexes - Monitor Tablespaces


þ Database System

þ Checks Button

þ Check next extent size button

þ Sort on Total Extents column

Extents should not be more than 80% of Max extents

þ Tablespaces

þ Verify Freespace problems = 0

þ Check Current Sizes Button

þ Sort on used column

All should be Less than 80% Status should be online

þ Tables and indexes

þ Verify Missing in database Tables and Indexes = 0

þ Verify Missing in R/3 DDIC Tables and Indexes = 0

þ Verify Freespace problems Tables and Indexes = 0

Database - continued

Performance Monitoring


þ Detailed Analysis button > File System Request button

þ Sort on avg(ms) of Blk Reads (all should be < 40ms)

þ Sort on avg(ms) of Blk Writes (all should be < 95ms)

þ Return to Oracle Database Overview (st04)

þ Detailed Analysis button > Database message button

þ Choose only Alerts

þ Go to Last page

Page back several pages to review unusual activity

þ Return to Oracle Database Overview (st04)

þ Verify Performance Statistics:

þ Data Buffer Quality >95 %

þ Physical Reads - (1:10 ratio to Reads)

þ Busy Waits Times 0

þ Shared Pool DD-Cache Quality > 90%

þ Log Buffer Alloc fault rate 0

þ Calls: User Calls /Rec. calls > 5

þ Table Scans: Long Tables (Full Table scans - NG)

þ Table Fetches: Continued row indicates chaining within

þ Sorts: Disk ( should be 0)

Check System Log for DB errors


þ Parameters

þ From Date/Time

þ To Date/Time

þ Select Problems and warnings

þ Go to last page

þ Review previous pages for unusual activity

Operating System Disk space availability

Telnet to server

þ Issue df -k command to insure disk space availablity

Operating System




What to look for

OS Alert Monitor


þ Items that exceed threshold limits

File System Monitor


þ Files systems approaching or exceeding threshold limits

OS Monitor


þ CPU utilization - idle CPU, top processes

þ memory allocation - page out activity and free physical memory

þ disk response time

þ file system utilization

þ Operating System log

NFS Mounts

Telent to server

þ Issue df -k to insure NFS Mount points are mounted (/usr/sap/trans, /interface)

Unix Print queue


þ jobs not printing

Wednesday, April 18, 2012

Client copy issues in sap & who needs take care about that issues

General problem
When running the client copies in I1M, MM1 & S1M in the weekends, there were a lot of issues, which caused the copies not to finish before Monday morning. In the next paragraphs short summary of the encountered issues and how they were solved. The over-all coordination in case of these problems is with the SAP Landscape Team. They will get in contact with the involved parties and make sure actions are followed up. It’s important to make people aware of the importance of the issues. When getting closer to Go-Live the urgency of the issues gets higher, since they can have a big impact on it. When having issues always raise a Remedy ticket or TPR. This helps making people aware of the issues and the importance of them.
Data load activities
When data loads are running during the weekend, they take up a lot of background processes and disk space. This decreases the system performance and slows down the client copies. This could also cause locks on tables, which can stop a client copy or can cause errors during the copy.
It has been agreed with the data managers that during the weekend there are no data loads running and there are as little people in the system as possible.
Action for: MI-RMG / Data Managers
Truncation of tables
There are a number of tables – mostly containing log information - that are growing very rapidly and take a long time to clear out and fill again. This can increase the runtime of the client copy with a couple of hours.
One of the actions assigned to the Basis team is to truncate – empty – these tables every week before the client copies start. Currently the following tables are being truncated weekly:
Action for: SAP Basis Team
When client copies are running, redo logs are created and stored in SAPARCH. The same happens with the backup logs. During the weekend SAPARCH regularly filled up causing the client copies to stop and the system to become inaccessible.
A script running during the weekend regularly deletes the redo logs of the client copies. Also the backups are stopped during the weekend, which gives more space in the file system. The Basis team also monitors SAPARCH preventing that it fills up and stops the client copies.
Action for: SAP Basis Team
Outstanding IDocs
When running data loads IDocs are created and stored in the system. This increases the size of the client copy and therefore also the runtime for the client copy on that client. The IDocs have a retention period of about a month.
Agreements have been made with the Archiving Team (X-function) that the systems are being cleared out on a monthly basis.
Action for: Archiving team (X-Function)
During the week backups are running in the different systems. This takes up a lot of system resources and also tends to fill-up SAPARCH. Since the logs of the backups are removed from SAPARCH to prevent it from filling up, the backups are not use full during the weekend.
The backups are stopped during the weekends, which will help on the system resources and will help solving the problems with SAPARCH.
Action for: SAP Basis Team
Table space sizes
Client copies have often stopped because the table they were filling ran out of space. This locks the refresh, which won’t start until the space has been extended.
It has been agreed that the table space sizes are increased when the client copies are scheduled making sure that this won’t cause the refresh to stop.
Action for: SAP Basis Team
Multiple copies running
Client copies were originally scheduled to start at a specific time. This means that if the previous client copy hasn’t finished yet, multiple client copies are running at the same time on the system. This has severe impact on the system performance and can cause a table to be locked which stops the client copies.
The copies are now scheduled to start after the previous copy. This may cause that not all copies finish during the weekend, but it does decrease the runtime of the refresh.
Action for: SAP Basis Team
IDocs Jobs / Link with production system
During the week send & zload jobs are running to send IDocs from one system to the other if necessary. These jobs used to run every ten minutes and shouldn’t take any time if there are no IDocs to process. Normally there is an ALE link active from MP1 to MM1; from MM1 to I1M & from MM1 to S1M to make sure the M-Systems have the latest Master Data. The link uses the zsend & zload jobs to get the data in and out of the system.
During the weekend the link between MP1 and MM1 is deactivated to prevent IDocs being sent to MM1, which would take a lot of system resources. This means that in principle the zsend & zload jobs should not be processing anything. However, in practice it has turned out the jobs still take some time to finish. Therefore it has been arranged that the zsend & zload jobs are rescheduled – also during the week – to run every hour instead of every 10 minutes. This reduces the system resources required.
Action for: ICC
Change Pointer table BDCPV
Table BDCPV gets really big dependent on the number of message types set with Activate flags on and the amount of data base changes that take place.
There are a number of ways to deal with the table and to prevent the contents from being copied client to client. One option is to run transaction BD22 over the table to delete processed change pointer entries and / or unprocessed entries – that are not required – for specific message types. A batch job could be set up to do this; just need to make sure the settings are correct. Another option is to ensure that when the master client is built, the message types are reviewed (BD50) and checked to see if the Activate flag is on.
Action for: Data Manager / ICC
Other actions
Some other things that can be checked when copies take too long to finish are the Oracle parameters. In the past the following parameters have been changed:
Action for: SAP Basis Team
Also it can be checked on which cluster a system is located. If systems with client copies are on the same cluster, they can affect each other's system performance. It’s preferred that systems with multiple client copies are located on different, relatively quiet clusters.
Action for: SAP Basis Team

If the problem remains over a longer period, the priority of the different clients has to be estimated during the week. Then the most important ones are scheduled as the first copies, which increase the chances of the copy to finish during the weekend. It also prevents that it’s always the same clients that get refreshed, while others are never refreshed. Also it’s possible to schedule client copies during the week for the smaller clients in the system. When clients are no longer in use, they could be deleted, which gives more space in the system. This can be confirmed by the MI-RMG team and the data managers.
Action for: SAP Landscape Team

Another option is to lock out all the users while the client copies are running. Downside is that certain jobs won’t run, which will give a backlog in the job schedule on Monday morning. This could give performance issues. However, if users are not able to access the system, the run time of the copies will decrease. This option hasn’t been used before and should only be used as an ultimate solution.

Tuesday, April 17, 2012

How to see a transaction used by a which users

Steps to be followed:
Run the T-Code ST03N

Choose Expert mode

The below screen will appear 

Expand the Total

  1. Select a date :
  2. Go to Analysis view à expand Transaction profile à select standard

Select any of the row of the transactions. In the below screen STMS is chosen

Now double click on the row selected. It will show the users who have used the transaction on the selected date

SAP ECC Update Deactivated Troubleshooting Guide

Scope:                  ECC systems (may be generally applicable to all systems with the exception of application specific details like EDI, VA02, etc.)
·         HPOV generated alerts:  
o   Full Alert Text:   'SAPSPI-127: Updating deactivated by system or user.(r3monupd)  [Policy: SAP R3 opcmsg]'
o   Full Alert Text:   'SAPSPI-228: 100616-07:22:06 : SAPOPC: System didn't responding in 120 seconds. nr=77 host=hpusir10 name=PA1 rel=XXX instance=XXX dbname=XXX dbhost=XXX monitor=r3monal  [Policy: SAP R3 opcmsg]'
o   Full Alert Text:   'SAPSPI-161: Update Status : PA1 : Warning: update is inactive. status=AL_STAT_ACTIVE severity=50  [Policy: SAP R3 opcmsg]'
·         SM13, indicating updates are stopped
·         SM51, many/all DIA/BGD processes in a stopped state
·         User reports of slow system performance
·         SM12, high number of locks (over 1000)
·         Others?
·         Others?
Troubleshooting Checklist:
·          SM13 - Check to see if updates are stopped
o   Need criteria to determine if we can restart the update queue or not, or whether we need GADS support right away to determine cause of update failures
·         SM12 – Check to see if there are a lot of locks held
·         DB01 – Check to see if there are a lot of Oracle level locks displayed by the lock monitor
·         DB02, Alerts à Alert monitor – Check to see if any alerts generated for table spaces  full, unable to expand segments due to insufficient space, etc.  stoppage  (Note: If updates are hung, it is possible that the alert monitor logs did not get posted, so do not count only on DB02 alert monitor  logs in these types of events).
·         SM21 – Check to see if any syslog errors reported indicating issues with the database, update failures, update stoppage  (Note: If updates are hung, it is possible that no syslog entries could be written, so do not count only on syslog in these types of events).
·         At UNIX Level, check the Oracle Alert log to see if we have had any Oracle level events that could impacted updates (Table space full, SAPARCH file system full, etc.) – Ratish, can you add the path here as a reference?  /oracle/<SID>/saptrace/background/alert_<SID>.log ??
·         At UNIX level, make sure /oracle/sap arch is not full.  If full, contact DBA team to have them resolve the sap arch issue.
·         At UNIX level, check the file systems and make sure we do not have a database file system at or near 100% (may not be enough room for a table space to extend due to insufficient freepsace blocks, even if the file system is not 100% full).
·         Logon to the HPOV Java console, and see if we got any errors at the OS/ Oracle level
·         Other things to check?  Ratish, Joe?
Common/Known Issues:
·         EDI update locks – Joe, can you add the criteria for this and what to do about it.
·         NRIV table locks – Most commonly caused by table space PSAPGLCAI being full,  unable to extend, or if undo segments cannot be written due to SAPARCH being full. Check the oracle alert logs, and determine if PSAPGLCAI is full, or has been unable to be extended. Have the DBA/UNIX team extend the File System, and or manually extend the table space if this is the case.  Once the table space has been extended, you will need to restart Updates (SM13).
·         Other known issues?

Monday, April 16, 2012

What things need to check when sap down

We have different levels in sap. based on problem we need to check the different things 
System (hardware) is down:
- Check console messages.
- Reboot and keep important system log files.
- Check hardware components.
- Analyze with diagnosis tools.
- Escalation procedure: call hardware support.
- Check main log files.
- Analyze with diagnostic tools.
- Start up/shut down log files.
- Check operating system log files.
- Identify other problems (startup/shutdown, disks and operating systems, database, operational R/3, performance).
Startup and shutdown problems (R/3 and application servers):
1. Check processes or services at operating system level.
2. Check whether database is up.
3. Check connection with database (i.e., tnsping, R3trans). 
4. Check whether file systems are full. 
5. Check for network problems in the server network. 
6. Check backup log for problems after backup. 
7. Check for problems after system crash. 
8. Check for problems with PDC file server. 
9. Check files permissions and authorizations. 
10. Manually start up or shut down database and then the application server. 
11. Check hosts and services files.
Operating system problems:
1. Check operating system log and event viewers.
2. Check disks and file systems.
3. Check directories and permissions.
4. Check path names.
5. Check security.
Database problems:
- Starting and stopping database
- Refer to startup problems.
- Check database specific error log file.
- Database storage status
- Check database error numbers.
- Check database alerts.
R/3 application operational problems:
1. Check whether all users are affected.
2. Check whether there is no work at all, or whether work is just limited. 
3. Check whether application servers are available (SM51). Check with standard monitoring transactions: SM50, SM04, SM12, SM13, ST22, SM37, and SP01. 
4. Check trace files on work directory (/usr/sap/<SID>/<instance>/work). 
5. Check SAP systems alerts. 
6. Analyze database problems.
Specific operational problems:-
Problems with printing:
A. Check network.
B. Check SP01/SPAD spool request logs.
C. Check system log.
Problems with batch input:
A. Check directories and files.
B. Check SM35 logs.
C. Check system log.
Problems with lock entries:
A. Check lock entries.
B. Check update process.
Problems with update process:
A. Check update process.
B. Check database.
C. Check network connections.
4. Problems with enqueue:
A. Check database.
B. Check instance parameters.
C. Check operating system processes.
5. Problems with message server:
A. Check processes.
B. Check network.
C. Check log files at work directory.
6. Problems with background processing:
A. Check job log.
B. Check background system consistency.
C. Check file systems.
D. Check system log.
7. Performance problems:
1. Perform workload analysis.
2. Perform debugging.
3. Perform runtime analysis.
4. Perform SQL trace.
5. Check for operating system problems.
6. Check disks for input/output bottlenecks.
Resolution process:
1. Search or SAPnet notes for hints, solutions, or workarounds. 
2. Escalation: enter message on SAP hotline or SAPnet. 
3. Enter problem on hardware partner hotline. 
4. Follow problem actions and SAP indications. 
5. Apply patches and corrections; test and verify results. 

Thursday, April 12, 2012

BADI for purchase requisition in sap ABAP

BADI for Purchase requisition : ME_PROCESS_REQ_CUST

Purpose: when ever user is changing price in PR it will display error message to maintain text .


**added by satya for valuation price change in PR'S related for projects

data: it_ci_eban type MEREQ_ITEM,

it_ci_eban1 type ref to IF_PURCHASE_REQUISITION,

it_ci_eban2 type MEREQ_HEADER.


DATA:wrk_object TYPE thead-tdname.








call method IM_ITEM->GET_DATA


re_data = it_ci_eban.



RE_REQUISITION = it_ci_eban1.

call method it_ci_eban1->GET_DATA


RE_DATA = it_ci_eban2.


select single VERPR from mbew into V_PREIS where matnr eq it_ci_eban-matnr and bwkey = it_ci_eban-werks.

CONCATENATE it_ci_eban2-BANFN it_ci_eban-BNFPO INTO wrk_object.

call function 'READ_TEXT'


client = sy-mandt

id = 'B01'

language = sy-langu

name = wrk_object

object = 'EBAN'


lines = t_remarks


not_found = 4.

delete t_remarks where TDLINE eq space.

IF V_PREIS NE it_ci_eban-PREIS.

.IF t_remarks[] IS INITIAL.

MESSAGE 'Please mention reason for change of price in Item->Texts->Item Note' TYPE 'E'.