question & answers

1.What is the difference between System Trace, Developer Trace and System Log?
Ans: ST01 - System Trace which will be required when you want to record trace for system
        ST05- Performance Trace (Developer Trace) which is required when any user complaning for a long transaction and you want to record all activity of Transcation.
        SM21- System log is for the recent logs for your CI and application server. What ever happen in SAP it will write a system log.

2. what is the process of kernel upgrade in sap ?
Ans:  Kernel Upgrade Process having following simple steps.

        1.Checks to be done before kernel upgrade
        2.Download the latest kernel patch from SMP
        3.Stop the Application Server and the SAP OS Collector
        4.Take Backup of the present Kernel directory
        5.Copy the new kernel files to the RUN folder location
        6.Check the permissions of the files in the kernel directory
        7.Start the Application server and the SAP OS Collector

Kernel Upgrade Process

Step 1) Checks to be done before kernel upgrade
a) Find the current version of the  kernel
         ==> execute the command disp+work -v to get the present kernel version
         ==> use the R/3 SYSTEM->STATUS to get the present kernel level
b) Note the Compilation mode from disp+work -v (here UNICODE)
c) The Operating system BIT length.
     ==>This can be found using "winmsd" (in windows) and "isainfo -v" or "uname -a" on unix servers.
             Also "tp -v" will give the OS bit length.

Step 2) Download the latest kernel patch from SMP

http://service.sap.com/swdc 

 --->Support Packages and Patches --->SAP NetWeaver ---> SAP NETWEAVER---> SAP NETWEAVER 7.0 (2004S) ---> Entry by Component---> Application Server Java--->SAP Kernel 7.00 32 bit UNICODE
There are 2 files to be downloaded from SMP:

a) Database Independent Files
This is of the nomenclature SAPEXE_<Patch level>-<release date>.SAR

b) Database Dependent files
This is of the nomenclature SAPEXEDB_<Patch level>-<release date>.SAR

Step 3) Uncar the .SAR files
Uncar the files using the SAPCAR utility and store it in a directory. Use the command:
SAPCAR -xvf <filename.SAR>

Step 4) Stop the Application Server and the SAP OS Collector

               In windows, stop the SAPOSCOL service (Start-> run-> services.msc)
               In Unix servers, use the command:   saposcol –k

Step 5) Take Backup of the present Kernel directory 

==> Copy the present kernel folder safely. This is important because the activity is completely reversible and 

switching over to the old kernel will be possible. 

Step 6) Copy the new kernel files to the RUN folder location 

 ==>Copy the files in such a manner that the RUN folder is overwritten by the new files. 

Step 7) Check the permissions of the files in the kernel directory 

The Database independent files such as "brtools", "brbackup", "R3load" etc. will usually have <DB>SID as 

the owner. In such cases, the owner of the files needs to be changed using the "CHOWN" command to the 

appropriate user. 

                      chown [-R] newowner filenames 

                      chmod <1>permissions filename 

Step 8) Start the Application server and the SAP OS Collector 

Now the kernel patching activity is complete. 

In windows, start the SAPOSCOL service (Start-> run-> services.msc) 

In Unix servers, use the command:  saposcol –l 

Step 9) Check the latest Kernel level 

==> Execute the command disp+work -v to get the new kernel level 

==> Also run the command R3Trans -d to check if database connection too is fine.

==> use the R/3 SYSTEM->STATUS to get the updated kernel level

How to identify long running background jobs

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

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.

Troubleshooting long running transport

How to troubleshoot when a transport is running for unusually long duration and not getting completed or terminated ?

How to troubleshoot when a transport is in truck status for a long duration of time ?

How to cancel a transport request which is in truck status or running status ?

How to terminate a long running transport request to re-import again ?

Transport is not getting terminated. How to do terminate?

How to troubleshoot when a transport is running for unusually long duration and not getting completed or terminated ?

Go to transaction STMS_IMPORT and identify the transport which is running since a long duration.
In the below screenshot, transport with the truck symbol is the long running one



Issue could be due to following reasons :
1) Non availability of space to perform the operation (i.e filesystem or tablespace is 100% full)
Ans:Check out if any of the filesystems (like sapmnt, oraarch etc) of the Central Instance, Database and application servers is 100% full. If so, please add necessary space, which resolves the issue automatically and completes the import of transport.
Also, check out tablespaces fill levels. If autoextend is off and tablespace is 100% full then add sufficient datafiles, which resolves the issue

2) RD* jobs are not running in SAP system
Ans:Check out in SM37 whether RDD* jobs(RDDIMPDP, RDDIC3L, RDDVERSL etc) are running or not. If not, please make sure they are scheduled and perform the import of the transport again

3) Update got deactivated
Ans:Checkout in SM13 whether update is active or not. If it is not active, activate it and import the Transported to Production System.

4) There are no free background workprocesses
Ans:Check in SM50 whether all background workprocesses are in running status. If so, you will need to wait for the free background workprocess to run RDD* jobs to complete the import of the transport. To avoid this issue in future you may increase the number of background workprocesses

Transport is not getting terminated. How to do terminate?

1) If you are unable to terminate a transport which is running, goto SM50 and identify the pid of the transport process. Try to cancel the process with core or without core as shown below.



2) If it is not getting terminated from SAP level, then goto Oslevel and kill.

Command for the same in AIX or HP-UX is kill -9 <PID>
If it is not getting killed from oslevel also, try to search for processes related to tp or R3trans and kill them as well
Eg in AIX or HP-UX : ps –ef |grep tp     Or      ps –ef |grep r3trans

3) If it is not getting terminated from that level, you may try to kill as shown below at SAP level :
Goto Import monitor and


Navigate as below and right click and delete entry to delete the transport which is being imported


By any one of the above 3 methods, transport will surely get terminated. So then you can add to queue again and re-import

Some knowledge on sap workprocess

1. DIALOG WORK PROCESS


Parameters
rdisp/max_wprun_time=600 to 1800sec
rdisp/wp_no_dia


Monitoring Dialog Work Process


SM50-Local Instance (Central Instance):- To display the list of process configured on that instance.
SM66-Global Instance (Including Central Instance and Dialog Instances)


Dialog Process Screen
No, Type, PID, Status (Running, Waiting, Holding, Terminated/Stopped, Ended), Reason (Sleep, Private, Enque mode), Start, Err, Semaphore, CPU, Time, Report, Client, Users, Action, Table.


Using DPMON we can monitor the status of Work Process at OS Level


2. BACKGROUND PROCESS


Background Job Classes
ClassA- High Priority
ClassB- Medium Priority
ClassC- Low Priority


SM36- We can Define Background Jobs
SA38- We can create variant.


Variants are stored in Table TVARV.


Job Status
1. Scheduled, 2. Released, 3. Ready, 4. Active, 5. Finished, 6. Canceled.


Background Job Steps
ABAP Program
External Program
External Commands
Using above Programs we can define Background jobs


Background Job Mechanism
When the dialog user defines to run a job in the background it is entered into the tablesTBTCT and TBTCS


TBTCS (Background processing time schedule table)
TBTCT (Compare value for batch job selection)


Background job scheduler runs for every 60sec or the time specified by the parameterrdisp/btctme=60sec
rdisp/wp_no_btc


Monitoring


SM37- We can monitor Background jobs
SM62- It’s used to display SAP events which will be triggered in the Background by using SAPEVT.
SM69, SM49-External Commands
SM64- To trigger the event in the Background


3. UPDATE PROCESS


SAP TRANSACTION: - It consists of multiple transactions which are handled by different Dialog work process these are updated in Temporary tables. Update process reads the Temporary tables to update the Database based on Transaction Id.
Each Transaction is Logical Unit of Work (LUW).


LUW: - It’s a Transaction which can be committed or rolled back


Types of Updates
Local Update
Asynchronous Update
Synchronous Update


Types of Update Process
V1 Update- High Priority
V2 Update- Low Priority
V3 Update- SAP Reserved
There should be at least one V1 update process defined for every 5 Dialog process


Dialog Process updates each dialog step tasks in temporary tables. These are VB* tables and each of them
VBHDR (Header):- It stores header information
VBMOD (Modules):- These are used to update the transaction.
VBDATA: - The exact data to be updated.
VBERR (Error):- The errors that are occur during the update.


Transaction Id is generated from “NRIV” table (Number Range Intervals)
Monitoring
SM13-We can monitor Update process
SM14- We can activate and deactivate Update process
Update Status
Init, Run, Auto, Error (Ora1631, 1632, 1653, 1654, 255, 275, 1555, Deadlock, Number Range Problem, Support Packages or Notes)


Using following Transactions we can get the granular information about Update Failure
SM21, SM37, ST22, SM13, SM50, SM66




Update Parameters


rdisp/vb_stop_active= 0 or 1:- Set to “0” so that update can be deactivated. If the value is set to be “1”update can’t be deactivated
rdisp/vbdelete:- This parameter delete the old update requests based on number of days. Default 50 days (which are older than 50 days it will delete).
rdisp/vbmail:- It’s used to send an email if update throws an error. This can be viewed in “SBWP” (SAP Business Work Place). Based on user
rdisp/vbname:- Name of the server where updates are processed.
rdisp/vbreorg=0 or 1:- Use to delete the incomplete the update request “0” for Not Delete, “1” for Delete
rdisp/vb_delete_after_execution:- It’s used to delete the update request soon after the execution of update. Set it to “1” for delete record and “2” for not deleting
rdisp/wp_no_vb


4. ENQUEUE PROCESS


It’s used to communicate to obtain a lock while updating a record.


Enqueue time will be 1m/s to 5m/s for Central Instance and 100m/s for Dialog Instance


SM12:- Monitoring Enqueue locks. It displays lock arguments based on Table name, Client and User name (Lock arguments Time and Table)


Enque Problems


Lock Table overflow
enque/table_size=4 MB By Default ( We can increase up to 100 MB)
Enque Time Increase
rdisp/wp_no_enq ( Increase enqueue work process from 0 to 100)
Dead Locks
SM12:- Releasing locks
SM04:- for ending the user session.




5. SPOOL PROCESS


It is only process which is used to output the documents to the printers, fax, Email, etc.
TemSe: - (Temporary Sequential objects) it’s nothing but spool request. It will store spool request up to 32,000 to 99, 000.
rspo/spool_id/max_number=32000 to 99000
rdisp/wp_no_spo


Parameter
rspo/store_location =g or db (To store the spool request at OS level or Database level)
g= OS Level (TemSe Resides in Global Directory) Spool size is small (Around 300MB)Path= \usr\sap\<SID>\SYS\global


db=Database level (TemSe resides in these tables TST01, TST03)


TST01:- It stores the objects and details of spool requests (Author name, No of Copies, Name of Printer etc)
TST03:- Spool Data to be printed


Spool process reads TemSe to generate out put requests. Out put request depends upon the Access Methods
Local Access Method:- Spool process and Host spool resides on the same system (C for windows, L for Unix )
Remote Access Method: Spool process and Host spool resides on two different machines (S for windows, U for Unix)
Front End Printing:- Printers are directly connected to end user systems (F for all)
rdisp/wp_no_spo_fro_max=2 (if 10 spool work process are available 2 will be set for front end printing)


Spool Server: - The server with at least one spool process is called as spool server. It can be Logical (For Fail over and Load balancing of Printers) or Real servers.


SPAD: - For defining the Printer (Output device) and the Spool Server (Logical or Real).


Monitoring
SP01:- It displays the list of spool request (Based on Username and Date Time)
Status (-, +, Waiting, In Process, Printing, Completed, Problem and Error)
SP02:- It displays Individual users spool requests
SPIC: - Spool installation Check use to check spool devices and pending requests
SP12:- TemSe Administration to check memory allocation objects and performs the TemSe consistency check