System Copy

A) Protecting the original system Before you enter the license in the target system, make sure you connect to it using user SAP*, and that you : 1. stop/delete all the application jobs you don't need to run in the target system ( transactions sm37,rspc) 2. delete/change all the RFC destinations that point to systems that were in contact with the original system. ( you really don't want your new target system sending messages to your original [often production ] systems) 3. delete/change content repositories that point to the original system's content repository servers. (transaction oac0) 

B) Enter the license in the target system Sometimes you'll need to delete tables MLICHECK, SAPLIKEY (using database tools) to achieve this. 

C) Configuring transport management system Usually all you'll need to do is connect to the target system in client 000, and press "OK". If the target system was previously connected to a transport domain, you'll have to connect to the domain controller, delete the system copy target system, reconnect to the copied system at 000 and initialize the TMS in transaction stms, Then confirm and distribute the changes in the domain controller. 

if you are using NEWMERIX's automate change tool, this would be a good time to update the license in the target system. 

D) update the logical system Use transaction BDLS in the target system to convert logical system names. 

E) update logon groups and logical servers Since the target system probably runs on a different hardware configuration then the source system, you will have to modify the various logon group definitions : Dialog logon groups – transaction smlg Rfc logon groups - transaction rz12 Spool servers - transaction spad 

F) Update user authorizations Usually, you'll have to make changes in the target system after a system copy, but the exact needs and the methods to do achieve this are shop dependent… 

G) Deleting redundant/sensitive data Depending on your needs , you may not really need all the source systems data in the target system. In this step you delete redundant or sensitive data using sap reorg jobs or archiving. 

z) Testing the new system : this step too is very shop specific, but here are a few not-so-obvious tests : 

a. import a change request into the target system b. use transactions bd87,sxmb_moni to make sure no messages were sent to other system. 

SAP Logon Connection Test

1. Double click on all below instance to check if you are able to login.

2. If login were successful, this means server is alive and has no connectivity issue. A new

screen will pop up. See below

3. Now you are ready to perform the next activity

DB12/DB13 Create and Check backup status for DB2

1. On the command field, key in DB12 and below screen will be displayed. It shows the

summary of the backup status.

2. On command field, enter DB13. This T-code is used to perform backup. You can also

check the backup status.

3. In DB13, select a desired cell which you plan to perform your backup. Double click on the

cell

4. Choose Full database backup to device

5. Backup mode: Offline

6. Device directory: ‘ d:’backup’ (this is just a folder which your backup could be stored)

7. Below is a sample picture.

DB02 Check Database size for DB2

1. Use DB02 to check DB size

2. Database current size (GB) is Total DB size - Free space

SM50 Check if instance is running on all servers

1. All work process is either running or waiting and none are stopped except CPIC

(interprocess communication)

2. Make sure not all dialog work process are used up, otherwise other user cannot make any

transaction.

3. Alternatively you can use SMLG to check whether system respond is good or bad.

RZ20 Check filling degree of spool used numbers

1. Click on SAP CCMS Monitor Templates

2. Click on SPOOL System

3. System Wide > Spool > SpoolNumbers > UsedNumebrs

4. If value greater then 80% in spool numbers - will lead to system wait until spool

reorganisation is done

SM13 Check if update is active

1. Enter SM13 and make sure UPDATE SYSTEM STATUS : Update is active.

2. Make sure client = *, User =* and status = All, Press F8 to execute

3. Click on any entry with error

4. You may have to dig deeper (SM21, ST22, DB02, etc) and work with functional expert to

resolve the issue

SM12 Check lock entries with long duration

1. Type SM12 in command field

2. Client = *

3. User name = *

4. Click list.

Its important to notice all values under the time column show the current time. Jobs with

earlier date should be immediately investigated. These locks are problematic because it

prevents access or changes to the locked records.

ST22 Check and analyze SAP ABAP short Dumps

An ABAP dump (AKA short dump) is generated when a report or transaction terminates as

the result of a serious error. The system records the error in the system log. SM21 and write

a snapshot (dump) of the program terminiation to a special table (SNAP). This transaction

can also be called from the system log (SM21). ABAP dump is used to analyze and

determine why the error occured and take corrective action

(no print screen - currenly my SAP has no Runtime errors)

Once Runtime errors is displayed

1. Double click on the entries

2. A detail analysis on the error will be displayed

3. Dump contains the follow information

- Why program has been terminted

- What caused the program termination

- Where in the program code the termination occured

- What you can do to correct the error

- The values of the relevant system fields when the program terminated

- The calls or events that was active when the program terminated

- Any other programs that are affected

SM21 Check and analyze SAP system log for any critical log entries (hourly)

1. Type SM21 into command field

2. Enter the relevant details and execute

3. Look for unusual entries.

4. Double click on the entries for more information

Lastly, a few more userful transaction

1. SM37 - Check and analyze failed background jobs

2. SP01 - Check SPOOL for errors

3. ST06 - CPU & Memory Utilization

4. ST03 - Check for database performance and response time

5. ST11 - Check for core file entries

Generally large number of users log into SAP sytem. The dialog work processes (wp) available to the users are limited due to performance & system limits. The objective of a dialog work

process is to handle the user requests quickly and display the results. Dialog work process also takes large resources relatively to background processes for display purposes. So it is not wise to have a dialog work process running for each user logged in. A dialog work process is not assigned to a single user for longer time. When a dialog user fires a request, the dispatcher assigns a dialog WP to handle the request. When the request is processed, it relieves the work process from that user so that other users can use it. This helps in handling requests from a large no of users with small no of dialog work process and optimum use of resources.

This article answers the following queries: What is the memory allocation sequence to dialog work processes in SAP?

When does a work process go to PRIV mode?

How to avoid or minimize work process going to PRIV mode ?

What are the SAP parameters used to define initial roll area, extended memory, heap memory, roll area ?

Memory allocation sequence to dialog work processes in SAP : ----------------------------------------------------------------------------------------------------

1. Initially , a defined roll area is used. This roll area is defined by the SAP parameter ztta/roll_first.

Usually ztta/roll_first is set to 1 in SAP so that only technically necessary amount  is allocated to roll memory. If the memory from the initial roll area( i.e. ztta/roll_first) is not sufficient for the user context then

2. Extended memory is used until  the extended memory is full or until the user quota is reached

Extended memory is defined by the SAP parameter em/initial_size_MB and the user quota for dialog workprocess is defined by the parameter ztta/roll_extension_dia.If this memory is also not sufficient, then

3. The rest of the roll area is used. This roll area is defined by SAP parameter ztta/roll_area.

Once this is also fully occupied then4. The system is forced to use local heap memory (Private memory). Then the work process goes into PRIV mode

Heap memory is available until one of the following occurs :i)        Either the limit of the heap memory for dialog workprocesses is reached

(abap/heap_area_dia) or the entire heap memory of all work processes(abap/heap_area_total)  for an application server reaches its limit.

ii)     Operating system limit for allocation of memory

iii)     The swap space in the host system is used up or the upper limit of the operating system address space is reached.

The memory allocation strategy for dialog work processes, aims to prevent work processes from allocating R/3 heap memory and thus entering PRIV mode.When  a work process enters PRIV mode, it remains connected to the user until the user ends the transaction. Most of the time,  we should try to avoid the situation of work process going into PRIV mode for better performance of the SAP system. This can be done by optimally defining abap/heap_area_total parameter.

This article answers the following queries :

How to troubleshoot when no one is able to login to SAP system (ABAP stack)? What could be the reasons if no one is able to login to SAP system (ABAP stack)?

Sometimes users may complain that they are  :

i)       Unable to login to SAP system from SAPGUI

ii)      Other users who have already logged in may complain that system is notresponding

iii)    Some users who have already logged in may complain that system is very slow and response time is very high

Please note that in most of the above cases even SAP basis administrator cannot login to SAP system through GUI. So, he should use database, operating system tools (like PuTTy) and dpmon to identify the issue and troubleshoot.

The most likely reasons for all the above scenarios could be

i)          Oraarch is full and system is not able to respond to user queries due to that and all dialog processes are occupied within a while due to that and system is not allowing any other users to login due to lack of dialog workprocesses

Solution :  As even basis administrator cannot login through SAP GUI at this point of time, Please check at operating system level. If you find that oraarch filesystem is 100% full, please trigger archive log backup immediately and make sure there is enough space. Once there is sufficient space, system will start processing and all the dialog users activities will be resumed and within a while there will be free  workprocesses to login and issue will get resolved

ii)           Some critical filesystem at Oslevel is full and system is not able to perform any activity due to that. Within a while all the dialog workprocesses are full and no other user is allowed to login

Solution :  As even administrator cannot login through SAP GUI at this point of            time, Please check at oslevel whether any filesystem is

100% full. If so, please contact OS team and make sure sufficient space is free either by requesting them to add  more space or by deleting some unnecessary files

iii)        Some tablespace like PSAPSR3 is 100% full and system is not able to perform requests of existing users. Within due time all the workprocesses will get occupied and system will stop responding and it won’t allow any other new user to login due to lack of free workprocesses

Solution :  (In Unix related Operating systems (AIX, HP-UX), login to system                 through <ORASID> user and run brtools to run whether any tablespace is 100% full. If so, please add some datafiles and make sure sufficient free space is created. After that system automatically resumes processing.

iv)    Update got deactivated and system is not able to perform updates and thus all dialog/background workprocesses are full within due time and system is not allowing any other users to login

Solution : In some cases, in all the above error cases i) , ii) and iii) , SAP system may deactivate update automatically to prevent loss of data. So, after fixing the respective issue, we need to manually activate the update through SM13 so that system will resume processing. But you can activate the update only if system allows you to login through SAP GUI.

If you are not able to login to SAP system through SAPGUI, please use dpmon tool to do the same.

How to use dpmon tool

v)          Other scenario could be some processes has gone into PRIV mode consuming so much memory. This leads to memory bottlenecks and all other users requests will either take lot of time to process thus experiencing slowness or high response times.

After a while it also may happen that all dialog workprocesses got full and no other user will be able to login due to lack of free workprocesses

Solution :  This has 2 scenarios :

i) If you are able to login to SAP system through SAPGUI, please goto SM66 and identify the processes that have gone into PRIV mode. After identifying the transactions that are being run in PRIV mode, please check with respective user and terminate the processes or logoff the users from the system after confirmation that his process is non critical and can be terminated.

Terminating user session

ii) If even basis administrator could not login to SAP system, then use dpmon tool to identify the processes that have gone to PRIV mode.

How to use dpmon tool ?

 After identifying processes that have gone to PRIV mode, cross check with the user and after confirmation that his session can be terminated, kill his session by providing PID number

For example: In AIX or HP-UX use command below

Kill -9 <PID>

In the above command, PID is process identification number.

After that system will release all the memory allocated to PRIV mode processes and will sytem will start processing normally.

How to troubleshoot a background job running for long duration in sap?This article answers how to troubleshoot a background job running for a long duration

--------------------------------------------------------------------------------------------

1) First of all identify the job that is long running and identify details like job class, workprocess that is executing the job

How to identify long running background jobs

2) Click on the job to view the display job screen. In the screen, click on job log to understand what is being performed by the job currently. This may give details like job is currently extracting some data packages or processing data packages etc

3) Identify the executing server and process id of the job from the step 1 and goto transaction SM50 of the respective executing server to view more details about the background job running.

Figure out the status of the job like On Hold or running from the process overview. If the job is On Hold, find out the reason for On Hold by examing the "Reason" column of SM50 transaction. Reason for On Hold could be due to CPIC/RFC/DEBUG/ENQ/PRIV/UPD etc.

Double click on the reason column for detailed information on the same and troubleshoot accordingly. If reason is RFC, check out which RFC it is referring to and cross check whether destination system is up or not and any other problems with that system. If it is ENQ, check out any lock issues like lock overflow etc If it is PRIV, check out for memory bottlenecks If it is UPD, check out whether any update issues If it is CPIC, check out for any network , gateway, message server and other communication problems

4) After performing step3, if you figure out job is not on Hold and it is in running state, then examine report column to identify what report/program is being executed by the job. Once you got the report/program details, figure whether it sap program or custom program and take actions accordingly.

5) Also examine Action and table columns in SM50 transaction of respective executing server to identify what is the action( roll in/roll out /Sequential read/Physical read/insert/update/delete etc)  being carried out by the job currently and what is the table on which action is being carried out.

If it is sequential read, figure out the cost of that sequential etc and consider for indexing etc. If it is physical read, check out whether there are too many swaps and consider resizing buffers accordingly. If you observed delay is due to high roll in/roll out, identify reasons for the same and tune buffer/memory parameters accordingly.

6) Once you get the table details on which action is being carried out, figure out        

    How many records are existing in the table ?     Is this taking long time due to volume of records ?     Are there proper indexes on the table ?(If no proper index, consider index creation  by taking help of DBA )     Is the table having upto date statistics ? (If statistics are out of date,              consider updating statistics of that table)

7) Consider debugging the process in SM50 ( Program/Session -> Program ->   Debugging ) to figureout the issue

8) Using ST05 or ST12, a trace can be taken for background job to figure out where exactly time is being consumed and to identify various cpu/memory bottlenecks or any buffer issues.

9) STAT/STAD transcation can be used to figure out what is the reason for high response time and actions can be taken accordingly

10) By taking help of ABAP er, even ABAP run time analysis can be done using SE30 transaction

By following the above steps, you can pin point the issue and take actions accordingly to minimize runtime of long running background jobs.