Configuring for Powerhouse/Oracle/Unix
Kim.Bjorn.Jensen@lindorffapplications.com
Kim.Bjorn.Jensen@lindorffapplications.com
Tue, 19 Feb 2002 16:15:24 +0100
Hi Rick
We've just recently moved a major PH-application (quick, quiz and qtp) from
HP3000 and Turbo/Image to HP9000 (HP-UX) and Oracle 8i. The application has
some 500 users. The database consists of approx. 200 tables holding round
32 GB of data (indexes and constraints not included).
We have 1 appl.server and 1 databaseserver with a 100 Mbps connection.
We have experienced that extracting large volumes of data - big
recordcomplex's - is most effisient when using cursors, in particular if
sorting is required. Sorting in Oracle may though turn out to be a
bottleneck if you have too little RAM or too slow disc-access. In general
it seems as if data-extracting is most effective when done inside the
database.
Best regards
Kim Bjørn Jensen
Principal Consultant
Lindorff Applications
Norway
rmhill@core.com
Sent by: To: powerh-l@lists.swau.edu
powerh-l-admin@cub cc:
e.swau.edu Subject: Configuring for Powerhouse/Oracle/Unix
19.02.02 15:22
I am currently working with a customer to migrate their Powerhouse
application to work with Powerhouse 8.23, Oracle, and either HP-UX or
IBM AIX.
This is a fairly substantial Powerhouse application, with a database
of anywhere from a 1/2 million to 1-1/2 million rows of data
(depending on the site), about 1200 quick screens, quite a bit of
procedure code, 150 tables in the database, tons of triggers in the
database, and many multi-pass quiz reports that are typically run as
background processes. The application will be installed at many
sites.
At this stage, the decisions that are somewhat firm are:
- the database will be Oracle
- the hardware and O/S will either be HP with HP-UX or IBM with AIX.
(apparently Sun/Solaris is not an option.)
- as it is a legacy application, no major additional changes to the
Powerhouse code. For example, at this stage, we are not to go into
dozens of QUICK, QUIZ, and QTP programs and code cursors.
Given all of the above, does anyone out there have suggestions for
configuration based on their experiences with Powerhouse, Oracle, HP
9000s and IBM RS6000s? Areas being scrutinized include the following:
1. HP9000 vs. IBM e-series
We have tested with 15-20 QUICK users on both platforms. The HP has
not performed as well as the IBM, and at times the users have appeared
to lock up. All other things equal, do the HP 9000's require more
horsepower? Are there some basic setup things to know to optimize it?
The IBM seemed to perform pretty well without much manual tuning - in
fact it seemed to tune itself quite well. I won't bore anyone with
all the I/O, memory, and CPU statistics.
2. # of Disk Drives
It has been recommended by the Oracle DBAs here to spread the database
over 4 drives if possible (one ea. for the data, indexes, rollback
segments, and logging). Is it crazy to go with only one or two drives
for the Oracle portion of the application?
3. Expected use of of memory
Given that the application has fairly procedure-intensive QUICK
programs, and that Oracle will be the database, and that there could
be as many as 15-25 users at a site, what minimum amount of memory
should we be considering per server? Is 1 gig enough? 2 gig? The
tests so far have been done with 512mb.
4. Use of Cursors and imbedded SQL
As presently coded, the applications's Powerhouse code does not have
any imbedded SQL such as cursors. Yet it runs decently in the current
Interbase environment. With the move to Oracle, should we definitely
pick the critical processes to put cursors in? Or should we be ok
leaving it all with pure Powerhouse code?
Any other suggestions for configuration are also welcome!
Rick Hill
Powerhouse Consultant
440-354-6950
rmhill@core.com
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Mailing list: powerh-l@lists.swau.edu
Subscribe: "subscribe" in message body to powerh-l-request@lists.swau.edu
Unsubscribe: "unsubscribe" in message body to
powerh-l-request@lists.swau.edu
http://lists.swau.edu/mailman/listinfo/powerh-l
This list is closed, thus to post to the list you must be a subscriber.