Background Job running for a Longer time

[Former Member]

Hi All,

I have a background job running for a longer period of time and when i check in SM50 it is doing a

Sequential Read on Table EBAN . The SQL statements are not expensive . Checked for the missing

indexes in DB02 and i could not find any missing indexes. The table EBAN has lot of entries in it .

Is there anything else we need to check ??? Any inputs would be of great help .

Regards,

Ershad Ahmed

[Former Member]

Hi,

The long running background jobs can also be due to the following issues from the SAP side which I missed out in my last posting. Not sure whether it is the case over here:

1) The report that is executed in the background job tries to establish a connection to the GUI. For example, the system tries to display a selection screen or a dialog box. However, this does not work in the background. Depending on how the report or the GUI technology used are configured, the report tries to establish a connection to the GUI after each failed attempt. As a result, the report hangs in an endless loop.

2) It appears as if the background job was still running, but it has terminated. Note that the job status displayed in SM37 or delivered by all programming interfaces is always the job status that is defined in the database.

Fo further details you can check SAP Note 924840 - A background job unexpectedly runs for a long time.

Long running background jobs can be due to a wide range of factors originating from both SAP and database.

Please also check whether the Oracle patches are up to date and whether the Oracle parameters (missed out in my last post) are as per recommendations (Please check SAP Note 830576 - Parameter recommendations for Oracle 10g if you are on Oracle 10g).

Also please reverify whether the SQLs are properly tuned because sometimes the SQLs can go in endless loops and may result in long execution times. Also check the job logs thoroughly and debug the background job from transaction SM50.

regards,

Subhajit.

[Former Member]

Hi,

Please check the Job logs from SM37 to check which job step is taking maximum time.

Also, activate SQL trace before the start of the job to check which SQL statement is taking maximum time. Remember to deactivate the trace once the job is over.

Long running jobs can be due to various issues such as:

1) Improperly tuned SQLs

2) Oracle bugs. Check for the latest patch sets / patches as per SAP Note 871096.

3) Database is inconsistent. Please check SAP Note 23345 (Consistency check of ORACLE database)

regards,

Subhajit.

[fidel_vales]

> Long running jobs can be due to various issues such as:

>

> 1) Improperly tuned SQL

> 2) Oracle bugs. Check for the latest patch sets / patches as per SAP Note 871096.

> 3) Database is inconsistent. Please check SAP Note 23345 (Consistency check of ORACLE database)

I do not agree 100%.

You only point to DB issues (and you also forgot to mention bad/incorrect oracle parameters)

Long running jobs can also be due to bad ABAP

Long running jobs can also be due to bad SAP configuration

and possible a lot of other things that I cannot imagine right now.

Regarding inconsistency, the note you mention check for corruptions.

Corruptions do not make a job to be long running. They make the job to finish with an error.

[Former Member]

Hi Markus ,

Iam not sure of the mount options of SAPDATAs .

The value for the filesystemio_options is setall

Regards,

Ershad Ahmed

[markus_doehr2]

Without knowing where the time is getting lost (database, application, CPU...) everything are just wild guesses.

Markus

[Former Member]

Hi Fidel,

Thanks for the Reply . We are on Oracle 10g with the patch set 10.2.0.4 and its an ECC 6.0 system

running on Sun Solaris. .

As mentioned by you from SM37 i found the PID and checked in ST04 and i checked the Oracle Session

and i see that the PID is active

Client PID Status Event SQL Statement Logical Reads Physical reads

11274 ACTIVE db file sequential read Its a Select Statement 2,804,334 894,909

Regards,

Ershad Ahmed

[markus_doehr2]

you may have an I/O related issue.

What are the mount options of the filesystem the database filesystem resides? What's the value of the Oracle parameter filesystemio_options?

Markus

[Former Member]

Hi Markus,

The job is a Customised program and not an SAP Standard program .

Hi Sushil,

Its not a problem with the Job coz it runs for a longer period of time and completes. Im trying to

investigate why the job is running for a Longer time .

Regards,

Ershad Ahmed

[markus_doehr2]

> The job is a Customised program and not an SAP Standard program .

I would run it under transaction SE30 to find out, where the time lost.

If it read huge amounts of data it's normal that it will take some time to complete.

Markus

[udaykishoreka]

goto sm37

select active Job

menu -> capture -active Job... check it

[fidel_vales]

Hi,

> The SQL statements are not expensive

Really?

May be that the SQL statement is in a loop and now you are executing that query some more times (instead of 100 times, now 1 million, for example)

with the information you provide it is almost not possible to give any advice.

Assuming you are in 10g and that you are a DBA (so you can put yourself some queries together)

From SM37 you find the job, from there you can find where it was started (server and process) from there you can find the SID of the Oracle process that is associated to the workprocess that executed the job (assuming the servers have not been restarted) now you only have to take a look at the Oracle Active Session History to see if the session was spending time at the database (and on what) OR it was "doing" nothing, so the issue is at the ABAP side

[markus_doehr2]

Is this a standard program running or a self written one?

Markus

[Former Member]

Ershad,

Check job log in Sm37. If it is updating the job log it means it is still running. Sometime job gets hangs, so you need to cancel it using SM50 or Sm37.

Thanks

Sushil