1.

User and password Issues (Authentication/ Authorization) user lock, user id expiry,
password change, lack of roles etc.
2. File system problems: BTC reads from the file system to update the database. File not
opened, or corrupted, file sharing issues, file came with different characters, file not found
as well.
3. Variants are not properly defined.
4. Deadlocks issue (Lock mechanism congested)
5. Update mechanism failed
6. Table space overflow (ORA-1653; ORA-1654)
7. Table space max extent reached (ORA-1631; ORA-1632)
8. Archive struck (ORA-255; ORA-272)
9. The memory is not sufficient and errors
(No Roll Area, PXA (Buffer), Page Errors)
10. Problem in the program and inputs (Indefinite loops like 1/0)
11. Dependent jobs/ events failure
12. Target systems are not available to process the jobs.

In real-time, we may face several scenarios like

i) Background job is processing slow

ii) ABAP program is taking a long time to complete execution
iii) Log_dir is getting full very fast

In the above cases, the Basis team should closely work with database teams and may have
to identify the reasons behind them to resolve the issues.

Example1: If a background job (or an ABAP program) is taking more time to complete, one
of the reasons could be statistics for underlying database tables that this job is accessing
were not up to date. We may have to run statistics to fix the performance issue.
Here we need to know which database table(s) is/are being accessed by job/ABAP program.

Example2: If a background job is running for a long duration and log_dir at the Operating
System level is reaching very high levels (ex: crossing 60% usage), then the reason could be
there is an issue with the underlying ABAP program. If single or multiple processes run for a
long time without committing work to the database, log hold-up will happen and log_dir
usage will increase. If it crosses 70%, the SAP system will face performance issues and if it
reaches 100%, the system wouldn’t be accessible.
To resolve this issue, developers need to modify ABAP program & make sure there are
frequent commit statements. In this case also, database team may request us to provide list
of tables that are being accessed by this job or program.

So, in this article, I’m covering the process of identifying database tables that are being
accessed by an ABAP program or a background job.
First of all, I will cover the process of identifying the underlying ABAP program for a given
background job. Let us say you want to identify, an underlying program for SAP standard job
BI_WRITE_PROT_TO_APPLLOG.
Goto SM37 transaction code and provide name of the job you would like to find abap
program for and execute the same:

It results in below screen:

In the above screen, select the job and click on step icon (highlighted) which results in below
screen
RSBATCH_WRITE_PROT_TO_APPLLOG is the underlying ABAP program for the given
background job BI_WRITE_PROT_TO_APPLLOG. Similarly, we can identify the program for
any background job.

Now, our next task is to identify database tables that are being accessed by the
RSBATCH_WRITE_PROT_TO_APPLLOG program or BI_WRITE_PROT_TO_APPLLOG job.

Go to SE38 transaction and provide the 722program name:

In the same screen, navigate to Utilities -> Environment Analysis as shown below
It will result in below screen.
As we need only database tables, please deselect all ticked options by clicking
highlighted icon and select only database table check box and execute (as shown below).
 It will result in below screen, which lists the database tables that are being accessed by
this program.

This is the process to identify database tables for a given background job or an ABAP
program

How to prevent SAP background jobs from running?

If the background job in SAP is in released state, it will run at the mentioned time or when
respective event occurs (as per the job definition). If for any reason, you would like to hold the
job(s) from execution, you can do the same using SM37 transaction.
In real time scenarios, you may need to hold few jobs from execution like

After system refresh, you may have to hold jobs from execution in target system because the target
system consists of source system jobs and they shouldn’t run. So, it is suggested to hold all the jobs
from execution and release only required jobs and basis standard jobs(housekeeping jobs)
Sometimes, there might be duplicate schedule of same job and you want to hold the duplicate job
to prevent multiple executions
In these cases, to hold the jobs to prevent from execution, we need to set the status of
those jobs from “Released” to “Scheduled”. To do the same, we have login to SAP
system and go to transaction SM37 which will result in below screen.

In the above screen, select the job status as “Released” and keep all other options as
shown above and execute. This will list down all the released status jobs.

From the list, select tick those jobs that you would like to prevent from execution and
change the status from “Released to Scheduled” as shown below:
Then all the selected jobs status will be set as “Scheduled” and those jobs won’t get
executed till you release them again.

How to identify ABAP program for a given background job?

Sometimes, it is required to know the underlying ABAP program name for a background
job.
This can be identified as shown below:

Goto SM37 transaction code. It will result in below screen. Please input job name for
which you would like to know the underlying ABAP program.
After selecting necessary job status, click on execute which results in below screen

Double click on the above job name to display job details as shown below
Click on step icon (highlighted) which shows the step list overview (as shown in below
screen)

Highlighted item is the underlying program name/command.

Parameters is the variant for that program and User is the “user id” with which this job
will be executed.

Note: Sometimes, we can view multiple programs as steps based on the Job definition
done. In other words, a job can have multiple programs or commands as steps
A background job can have the following statuses :

Scheduled : This means that the steps that are required to make up the job are already
completed but the start condition is not yet specified.

Released : This means that all the steps that are required to make up the job including start
condition are defined. A job cannot be released without a start condition. A job can be
released only by the administrator or by the user who has proper authorizations.

Ready : This means that the job is ready for execution. It is kept in the wait queue by the job
scheduler and is waiting for the next free background workprocess to assign the same.

Active : This means that the job is currently active. In this state, job cannot be deleted or
modified.

If the active job is not running correctly, either it can be terminated or it can be canceled in
a background workprocess in debugging mode, analyse it and can be released again.

How to capture a background job ?

Goto SM37 transaction and navigate to Jobs -> Capture active job to capture the job. Once
the job is captured , analyse the same and you can release it again.
Please note that you should be in the application server on which the job is running to
capture a job. Otherwise, you cannot capture it.
How to terminate a background job ?

Goto SM37 and list all the jobs that are active between some time interval.
Once it listed the active jobs, identify the job that is to be deleted. Then navigate to Job ->
Cancel Active job and cancel the job.

Finished: The execution of the job has been completed successfully

Canceled: The job got aborted or canceled. This can happen for 2 reasons.

 One of the job step is terminated with an error

 An administrator has deliberately terminated the job due to various reasons like
running unusually for a long time
 How to schedule Basis standard jobs ?

 Goto transaction SM36 and click on "standard jobs" pushbutton. This inturn displays
standard jobs screen. Here select all the jobs and click on "default scheduling"
push button to schedule all of them as per their default schedule.

 




In case you would like to change the default schedule for each job, it can also be done by
selecting each job and defining its start date/time and periodicity in the same screen.

What is the need of scheduling basis standard jobs ?

Standard jobs are the jobs that should run regularly in the SAP system. These jobs will
perform housekeeping like deleting old spool requests (thus avoiding spool overflow),
deleting old background jobs/logs/updates/batch input sessions/ABAP short dumps,
collecting operating system/database level statistics (used for workload reporting) etc

What are the Standard jobs that should run in an SAP system & their significance ?

SAP_CCMS_MONI_BATCH_DP : Internally this job runs

RSAL_BATCH_TOOL_DISPATCHING report. This job dispatches monitoring architecture
methods

SAP_COLLECTOR_FOR_JOBSTATISTIC : Internally this job runs RSBPCOLL report. This job

generates run time statistics for background jobs

SAP_COLLECTOR_FOR_PERFMONITOR : Internally this job runs RSCOLL00 report. This job

collects data for the performance monitor

SAP_COLLECTOR_FOR_NONE_R3_STAT : Internally this job runs RSN3_STAT_COLLECTOR

report. This job will collect non-abap statistic data (Distributed Statistic Records - DSR)

SAP_REORG_ABAP_DUMPS : Internally this job runs RSSNAPDL report. This job cleans up
old abap short dumps

SAP_REORG_BATCH_INPUT : Internally this job runs RSBDCREO report. This job cleans up
old batch input sessions

SAP_REORG_JOBS : Internally this job runs RSBTCDEL report. This job cleans up old
background jobs

SAP_REORG_JOBSTATIC : Internally this job runs RSBPSTDE report. This job cleans up old
data from the run time statistics of the jobs

SAP_REORG_ORPHANED_JOBLOGS : Internally this job runs RSTS0024 report. This job cleans
up orphaned job logs. The logs that cannot be deleted by RSBTCDEL report (i.e
SAP_REORG_JOBS), remains as orphans which will be deleted by this job.

SAP_REORG_SPOOL : This job internally runs RSPO0041 report. This job deletes old spool
data

SAP_REORG_XMILOG : This job internally runs RSXMILOGREORG. This job deletes XMI logs

SAP_SOAP_RUNTIME_MANAGEMENT : This job internally runs RSWSMANAGEMENT report.

This job does the SOAP runtime monitoring

SAP_REORG_UPDATERECORDS : This job internally runs RSM13002 report and this deletes
old update records.
How to find out long running jobs in SAP ?

Goto SM37 transaction and select the active job status between any 2 given date/time and
list them. In the output, sort the jobs based on duration column in descending order and
identify the jobs that are running for longer duration

All other questions can be answered from the below :

Goto transaction SM37 and list the jobs based on status and time interval.

Select any job for which you want to figure out the details. Double click on the job, which
pops up "display job screen". In that screen, click on job details tab to view

 Job name
 Job class (i.e A, B and C)
 Status of the job
 Exec. Target (server/instance on which job is being run currently)
 Job frequency (hourly, monthly , weekly etc)
 Workprocess that is executing the job
 Client on which job is running
 Release time of the job
 Schedule start of the job