I am amazed how often I see the very same piece of code used
by many different bloggers, often with very little thought as to the quality of
the code or the audience it’s going to. We all want to get the most out of free
code and avoid the pitfalls, so here’s some things to consider for bloggers and
users alike. Full article http://www.piper-rx.com/pages/tips/think_global.pdf
Gary Piper
A Practical Approach To Oracle E-Business Suite
www.piper-rx.com
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, July 23, 2013
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 www.piper-rx.com website. In fact there is heaps of FREE information
and tips on all aspects of OEBS Applications Administration at PIPER-Rx.com 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: http://www.piper-rx.com/pages/tips.html
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
Friday, December 9, 2011
Improving the business efficiency of OEBS workflow. Part 2: Validating e-mail addresses
This paper is the second of a two (2) part
series. Part 2 covers e-mail address validation using a 12 point PLSQL e-mail
addresses validation function.
Using the PLSQL function we cover e-mail
validation of addresses in both the wf_local_roles and wf_local_users objects
and in a number of base application objects that populate the workflow roles
and users objects.
The paper and the PLSQL function can be viewed or downloaded at the following addresses
PDF document, 500 Kb
http://www.piper-rx.com/pages/papers/email_validation_part_two.pdf
PLSQL, 8 Kb
http://www.piper-rx.com/pages/papers/piper_rx_email_validation.sql
-Gary
Sunday, November 20, 2011
Improving the business efficiency of OEBS workflow. Part 1: Missing e-mail addresses
This paper is part one (1) of a two (2)
part series. Part 1 covers null e-mail addresses in your workflow roles objects
and in part 2 we covers e-mail address validation including a free 12 point PLSQL function
for validating e-mail addresses.
In this paper we cover the issue of missing
(null) workflow e-mail addresses:
v The importance of a SYSADMIN e-mail address
The paper can be viewed or downloaded at the following address:
Part 1: Missing e-mail addresses
PDF document, 300 Kb
In part 2 of the “Improving the business efficiency of OEBS workflow” series we will cover email address validation. Part 2 also includes an 12 point email address validation function.
v What happens when an invalid
e-mail address is encountered?
v Assessing the damage in your instance ( Free SQL )
v And how to rectify the issue
The paper can be viewed or downloaded at the following address:
Part 1: Missing e-mail addresses
PDF document, 300 Kb
In part 2 of the “Improving the business efficiency of OEBS workflow” series we will cover email address validation. Part 2 also includes an 12 point email address validation function.
-Gary
Monday, February 28, 2011
Did you know you can change an apps user’s account name?
First and foremost this is done via the normal apps Security > User > Define screen.
Whilst the account name (user_name) has to be unique which is enforced by the fnd_user_u2 index, the internal application key is based on the account ID (user_id) not the name
So why would you change an account name?
Of course you will need to get this approach signed off by Oracle support and internal audit first. Usually, as long as there is consistent documented evidence of the change audit are generally ok
You are not doing anything dodgy here, this is all done via the standard Oracle application screens (Security > User > Define) just select the user, change the users name and commit.
Note: If you change the name of an active account, you will need to reset that user's password and let them know the password you have set and that they will be required to change their password on first connecting with the new name.
Of course you wouldn’t even attempt to do this without checking with Oracle support and you’re your audit team before changing application user names and then testing, testing etc…..
Whilst the account name (user_name) has to be unique which is enforced by the fnd_user_u2 index, the internal application key is based on the account ID (user_id) not the name
So why would you change an account name?
- A name change by deed poll or marriage
- A new employee has the same name as an ex-employee
- The user name was entered incorrectly
- You want to implement a user naming standard
Of course you will need to get this approach signed off by Oracle support and internal audit first. Usually, as long as there is consistent documented evidence of the change audit are generally ok
You are not doing anything dodgy here, this is all done via the standard Oracle application screens (Security > User > Define) just select the user, change the users name and commit.
Note: If you change the name of an active account, you will need to reset that user's password and let them know the password you have set and that they will be required to change their password on first connecting with the new name.
Of course you wouldn’t even attempt to do this without checking with Oracle support and you’re your audit team before changing application user names and then testing, testing etc…..
Subscribe to:
Posts (Atom)