Background jobs stuck in Ready status or their poor load balancing

If you have multiple application servers, change and set the parameter rdsip/btctime to a different value on each one eg. 56, 57,58,59 etc. The job scheduler "SAPMSSY2" runs every "rdisp/btctime" seconds (60 by default) and looks for all the pending jobs in the job queue and assigns them to the available free batch work processes in the system.

If there are other batch work processes waiting while the jobs are in the ready status, ensure that you have not over-allocated batch WPs for Class A jobs only. You can change such allocation from the transaction RZ04.

If you find that WPs are not over-allocated to Class A jobs, it could be that a job is blocking access to the WPs. Run temse check as explained below and kill/restart the WPs that are in waiting status to get the WP working.
  • Run Transaction SM65
  • Select Goto > Additional tests
  • Select these options:
    • Perform TemSe check
    • Consistency check DB tables
    • List
    • Check profile parameters
    • Check host names
    • Determine no. of jobs in queue
    • All job servers
    • Then click on execute
  • Once you get the results check to see if you have any inconsistencies in any of your tables.
  • If there are any inconsistencies reported then run the "Background Procesing Analyses" (SM65 > Goto > Additional Tests) again. This time check the "Consistency check DB tables" and then "Remove Inconsistencies" options.
  • Run this a couple of times until all inconsistencies are removed from the tables.
  • NOTE: Make sure you run this SM65 check when the system is quiet and no other batch jobs are running as this would put a lock on the TBTCO table till it finishes. This table may be needed by any other batch job that is running or scheduled to run at the time SM65 checks are running.
Jobs stuck in ready status could also be a result of a system shutdown. When a background job is set to ready status it is waiting for something to trigger it. If thesystem shuts down while the job is in ready status, the trigger for it
will never occur. Thus it is stuck and never gets out of ready status. If that is the case with these jobs, you have to delete them and restart them. An easy way to prevent this from happenening in the future is to have more background
WP set up on the time when most of these background jobs are supposed to run and try avoiding background jobs scheduled during your regular maintenance window.

Overflow of the dispatcher queue can also contribute to the problem. Increase the dispatcher queue size by increasing the the parameter value rdisp/elem_per_queue from default to a higher value, say by 50%.

To clean up these hung jobs, select them in transaction SM37 and choose the menu option Job -> Check status. You will be asked if you want to set the job to status Scheduled. You can choose yes, then re-release the job.

Check out SAP note 519059 and other notes referenced by it for more details.


Comments

Post a Comment

Popular posts from this blog

OS/DB Migration - CMD. STR, TOC, EXT, R3load, DDLDBS.TPL and more

Image
With increasing need to improve performance or reduce costs or vanishing support for operating systems/databases it becomes inevitable to migrate to a better OS or DB. We feel take a quick look at the primary ingredients of the tools for OS/DB migration handled by R3SETUP. Tools - R3load, R3ldctl and R3szchk R3ldctl creates STRucture files, TemPLate files by reading the technical settings for table/indexes in SAP data dictionary. R3szchk calculates the database size object sizes (EXTent files) for the target system based on the STR files created by R3ldctl. The EXT and STR files can be later split into smaller groups. The most crucial tool R3load is responsible for unloading and loading data from the database. R3load uses the files created by R3ldctl and R3szchk and dumps the data into compressed binary format as .001, .002 .. files. It uses cmd files to achieve the task. If the cmd files are not present, it creates on its own. Files Command files*.cmd  are creat...
Read more

Fixing Inconsistent Table - Table activation fails due to inconsistency between DD and DB

If you find a table to be available on the database, but not active in ABAP dictionary, try calling SE14 as DDIC user, enter the table name and choose Table > Reconstruct, Execute. If this method fails follow these steps: Call transaction code SE37 and execute the function module  DD_TABL_ACTM with single test On the next screen, do not change any other field except the following and set them as shown below: MODE: 12 NTAB_PUTSTATE: N TABNAME: <enter the correct table name> Click on Execute The export parameter ACT_RESULT should show 0. To verify if the inconsistency is fixed, call transaction SE14 > Extras > Database Object > Check and  SE14 > Extras > Runtime object > Check.
Read more

301 Redirect Using SAP Web Dispatcher

301 redirects are typically used to redirect accesses that include www to non-www or vice-versa. Example, when you call http://blogger.com, the call is redirected to www.blogger.com. An end-user may prefer to call a URL in any manner. You must ensure that all these calls are redirected to relevant URLs with content. SAP web dispatcher can be configured to send a redirect (301) to the client. To enable redirection add icm/HTTP/redirect_<xx> to the web dispatcher's profile file. The parameter uses the following syntax: icm/HTTP/redirect_<xx> = PREFIX=<URL prefix>[, FROM=<pattern for URL>, FROMPROT=<incoming protocol>, FOR=<pattern for host name:port>,TO=<new URL prefix>, PROT=<protocol>, HOST=<host>, PORT=<port number/name>] Let's say you want to redirect all the HTTP requests on mysource.com on 80 port to mytarget.com on HTTPS 443 port icm/HTTP/redirect_0 = PREFIX=/, FROM=*, FROMPROT=http, FOR=mysource.com:80,...
Read more