PQ70364: PERFORMANCE PROBLEMS WHILE USING 64-BIT ORACLE 9 R1 FOR THE ADMIN REPOSITORY ON WAS AE 4.0.4.

 A fix is available

4.0.6: WebSphere Application Server Version 4.0 Fix Pack 6



APAR status
Closed as documentation error.

Error description
Performance problems while using 64-bit Oracle 9 R1 for
the Admin Repository on WAS AE 4.0.4.
.
Noticed intermittent delays (approx 30s) for some
database calls to complete on a remote 64-bit Oracle 9 R1 Admin
Repository Database (On Solaris).  For example the Adminserver
would make a call to retrieve repository data used to fill the
adminconsole tree or for an xmlconfig export and would wait 30s
for a response from the remote 64-bit Oracle 9 database server
.
Thus when starting up the AdminConsole we have seen times
ranging from 10 to 30 minutes as well as when performing
XMLConfig administrative tasks
.
Pat Fruth (IBM  Software Technical preSales - WebSphere) was
able to successfully recreate this problem using the following
configuration/environment:
- Sun Ultra 10 - 440 MHz uni-processor, 1GB RAM, 20GB disk
- Solaris 8 + Nov 2002 patch cluster
(http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-ac
cess)
- WAS 4.0.4
- WPS 4.1.4
- SecureWay LDAP 3.2.2 (mine is on Windows)
- Oracle 9i R1 (64-bit for Solaris)
- Oracle 9i R1 JDBC thin driver
.
The good news is... this can be recreated on a single server...
don't need 2 servers Probably the most important factor, the
significance of which I did not realize at the time, is the use
of the 64-bit Oracle 9i R1.
.
Until this exercise, I was not sensitive to the fact that Oracle
has two variants of 9i for Solaris... a 32-bit implementation,
and a 64-bit implementation.
.
I had been trying to recreate the problem using the 32-bit
variant of Oracle 9i R1.  32-bit 9i R1seems to work fine.
Upon closer examination of the system, I learned that
they are using the 64-bit variant of 9i R1.  Sure enough, as
soon as I installed the 64-bit variant of 9i R1 on my
test system, the problem immediately started to show up.
.
One way you can tell the difference between the 32-bit 9i and
the 64-bit 9i is to look at the messages emitted by sqlplus.
9i R1 (32-bit) will report a version number of 9.0.1.0
9i R1 (64-bit) will report a version number of 9.0.1.1
I feel confident that this is indeed what was causing the
problem , and not something else (i.e. WAS, WPS, etc.).
.
Anyhow, just wanted to pass this information along.
I don't know that there is really anything further to be done
about it, except to document the fact that this particular
software combination should be avoided.
.
After further testing was performed, the following conclusion
was reached:
.
1. WAS 4.0.4/WPS 4.1.4 and Oracle 9i r1 32-bit variant works
fine both local and remote.
2. WAS 4.0.4/WPS 4.1.4 and Oracle 9i r2 32-bit and 64-bit
variants work fine both local and remote.
3. WAS 4.0.4/WPS 4.1.4 and Oracle 9i r1 64-bit variant produces
the performance degradation.
.
From these results it appears that there is an issue with Oracle
9i r1 64-bit variant being used as the Admin Repository.
Local fix
Workaround is to use Oracle 9i r2 64-bit variant instead of
Oracle 9i r1 vairant for the Admin Repository.
.
The 32-bit versions of Oracle 9i do not experience the
performance problems.  Performance problems only experienced
while using Oracle 9i r1 64-bit variant for the Admin
Repository.
Problem summary
****************************************************************
* USERS AFFECTED: Users of WebSphere Application Server,       *
*                 Advanced Edition Version 4.0.4.              *
****************************************************************
* PROBLEM DESCRIPTION: When starting up the administrative     *
*                      console or performing XMLConfig         *
*                      administrative tasks, the duration      *
*                      ranges from 10 to 30 minutes.           *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
When starting up the administrative console or performing
XMLConfig administrative tasks, the duration ranges from 10 to
30 minutes. The reason for this is that when the
administrative server makes a call to retrieve the repository
data used to fill the administrative console tree or for an
XMLConfig export, the server waits 30 seconds for a response
from the remote 64-bit Oracle 9 database server.

To workaround the problem in the administrative repository or
to avoid performance problems with your application, either
use 32-bit Oracle 9i R1 or Oracle 9i R2 (64-bit or 32-bit).
Problem conclusion
Close this APAR as a documentation change.
WebSphere Application Server Version 4.0.6
Release Notes will be avaialbe by the end
of May, 03.
Temporary fix Comments
APAR information
APAR number PQ70364
Reported component name WEBSPHERE AE SO
Reported component ID 5630A2202
Reported release 400
Status CLOSED DOC
PE NoPE
HIPER NoHIPER
Submitted date 2003-01-28
Closed date 2003-02-28
Last modified date 2003-02-28

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:

Modules/Macros

SRLS

Fix information

Applicable component levels


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > General
Operating system(s):
Software version: 400
Software edition:
Reference #: PQ70364
IBM Group: Software Group
Modified date: Feb 28, 2003