About this blog

As with my website, my blogs espouse the philosophy “not all performance problems are technical” and that in most stable environments user behaviour / usage patterns are typically the source of most correctable performance problems. So if you are into bits, bytes, locks, latches etc this is not the place for you, but if you are after ways to genuinely enhance performance and work with your systems and customers to achieve better, more predictable performance, read on.

Tuesday, May 15, 2012

Health tip #3 – Avoid having too many concurrent managers

Here we go again! After having written and blogged about this topic a fair bit in the past, having too many managers is a problem I still continue to see all too often. A good example is a site I worked with recently; it had 20+ managers just to run the workflow background processes.

Putting aside the need to address the excessive workflow background processes (which is another problem in its own right) there are major issues with the concurrent managers:

Problem #1 – Allowing 20 workflow background processes to run at once competes for the same resources on the same tables.

Problem #2 – Is one of basic queuing theory –i.e. 20 processes all competing for the same CPU and data resources.

In theory, 1 CPU handles 2 concurrent processes so in this case unless the site has 10 CPUs it runs the risk of CPU bottlenecking problems. The sting in the tail is these problems become most evident when you least need them to, like at high processing times such as month end.

What to do? It’s a simple choice. In this case identify why you think you need so many concurrent managers. You need to fix the cause and cut down on the number of managers, not just focus on the symptoms.

Want to know more? Take a look at the paper Concurrent Manager 101 & 202 on the website.  In fact there is heaps of FREE information and tips on all aspects of OEBS Applications Administration at so why not check it out!

Tuesday, March 13, 2012

Concurrent Managers Health Tip #2 – Scheduled Request Issues.

Scheduled requests are one of the mainstays of OEBS concurrent processing.

One of the benefits of recurring scheduled requests is they are “set and forget” they just happily run and resubmit without you having to do a thing.

The biggest issue I’ve found, and this applies to almost all sites, is the “forget” component. I regularly find scheduled requests that have been running for years that are no longer required, and also duplicate scheduled requests which have come about because someone doesn’t know the original request exists. Both these issues are a waste of processing resources.

Another issue with scheduled requests is that I often find resource intensive requests originally set to run overnight now creeping into the working day because the request is resubmitting from the END of the prior run.

You should periodically review your scheduled requests to help avoid these issues.

Want to know more?

Download the simple OEBS scheduled requests report ordered by program - TOAD Reports format report.

Report ID - PRXCMS-002

Using this report you should be able to identify both your duplicates and those requests with a resubmit of END. By multiplying the “Re-submit” value by the “Resub Count” you can get some idea how long the request has been resubmitting.

Refer to PAM tutorial 19 “When Scheduled Requests Go Wrong”

Friday, February 3, 2012

Concurrent Managers Health Tip #1 – Rebuild your indexes!

This is really a simple one and you would be surprised how many companies large and small overlook this.

I have seen examples of sites with over 50 million rows in the fnd_concurrent_requests_u1 indexes; a huge waste of space! More importantly however is the problem of poor performance in such a core OEBS activity e.g. 10 concurrent manager processes running with a 30 second sleep time equates to 28,800 hits on your fnd_concurrent_requests table and its indexes (this does not include your users submitting requests and checking if their requests have completed). Get the picture why this is so important.

As part of regular maintenance practices you should rebuild your indexes on routinely purged objects on a regular basis, especially the indexes on fnd_concurrent_requests.

Want to know if you need to rebuild your indexes? The following article includes everything you need to know together with code and there is also a TOAD report. These can be found on the PIPER-Rx “tips” page:

Rebuilding indexes in an OEBS environment - A guide to rebuilding indexes in an OEBS environment

View and Download associated TOAD report (TRD format) - Report id - FDBA002-10

Also remember some OEBS application monitors provide alerting to remind you when your indexes may need maintenance.

Happy Rebuilding J