Configuring for Powerhouse/Oracle/Unix
Jon.Kvisli@lindorffapplications.com
Jon.Kvisli@lindorffapplications.com
Tue, 19 Feb 2002 16:27:17 +0100
This is a multipart message in MIME format.
--=_alternative 00550BA3C1256B65_=
Content-Type: text/plain; charset="us-ascii"
>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?
We have recently (jan 2002) finished a similar conversion of two large
legacy systems from HP3000/TurboImage to HP9000/HP-UX/Oracle. Together the
two systems have app. 600 concurrent on-line users at day-time. I
understand that this is somewhat more than your applications, but anyway:
Here is some information from our project:
>1. HP9000 vs. IBM e-series?
Our two applications are now running on this configuration:
HARDWARE
2 x HP9000 L2000/360/2-way
each with:
2 x 360 MHz CPU (PA8500)
iCOD 2 extra CPU (These were cold and unactivated, but we had to activate
them the first week we went live)
3 GB RAM (Memory had to be increaced to 9 GB after 1 week in production)
2 x 18 GB internal disk
100 BaseT 4 ports x 2
2 x 2 ports FC adapter
OnlineJFS
Mirrordisk
Glanceplus
Process Resource Manager
Serviceguard OPS
COMMON STORAGE
FC 60 Disk Array 16 x 18,2 GB disks (total of app. 290 GB brutto)
SOFTWARE
PowerHouse 8.23
Oracle 8.1.6 Enterprise edition
One of the HP9000 machines is running as Oracle server, the other is
running PowerHouse run-time and applications. This was recomended by HP
and Oracle, and was done do balance load at day-time, on-line use. This is
probably not relevant for 25-30 users. For night-time batch jobs this may
also not be optimal, as the machines tends to wait for each other when
only one qtp executes at a time. ServiceGuard is configured so that one
machine will take over both Oracle and PH, if the other machine goes down.
>- 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.
We had the same strategy, but ended up doing at lot of optimizing with SQL
and cursors in QTP. The most important lesson we learnt during the
project, was that QTP will perform MUCH slower if you choose to convert
without rewriting using SQL and cursors. On the other hand, using SQL and
cursors may give reduction in execution times down til 10% of what
HP3000/Image were capable of.
>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?
I am not an expert on this, but both HP and Oracle told us that this is
not a big issue any longer, due to HP9000 using "striping". To my
knowledge, this means that HP-UX will spread data on several disks
automaticatly at OS-level, and there is no need for Oracle DBA to place
tablespaces on different physical discs.
>3. Expected use of of memory
Our configuraton for 600 users is probably not comparable to Yours.
>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?
Our experience (as decribed above), was with code moved from TurboImage to
Oracle. Moving from another relational (Interbase) to Oracle, may probably
not give the same results. FILE / ACCESS / LINKs that does not perform
well on relational, are probably avoided already(?)
Regards
Jon Kvisli
----------------------------------------------
Principal consultant
Lindorff Applications as
Hellandtunet research- & businesspark
Postbox 4, NO-3833 Bo in Telemark, Norway
phone: 35 06 15 71
fax: 35 06 15 01
jon.kvisli@lindorffapplications.com
www.lindorffapplications.com
----------------------------------------------
--=_alternative 00550BA3C1256B65_=
Content-Type: text/html; charset="us-ascii"
<br><font size=2 face="Courier New">>Given all of the above, does anyone out there have suggestions for<br>
>configuration based on their experiences with Powerhouse, Oracle, HP<br>
>9000s and IBM RS6000s? <br>
</font>
<br><font size=2 face="Courier New">We have recently (jan 2002) finished a similar conversion of two large legacy systems from HP3000/TurboImage to HP9000/HP-UX/Oracle. Together the two systems have app. 600 concurrent on-line users at day-time. I understand that this is somewhat more than your applications, but anyway: Here is some information from our project:</font>
<br>
<br><font size=2 face="Courier New">>1. HP9000 vs. IBM e-series?<br>
</font>
<br><font size=2 face="Courier New">Our two applications are now running on this configuration:</font>
<br>
<br><font size=2 face="Times New Roman">HARDWARE</font>
<br><font size=2 face="Times New Roman">2 x HP9000 L2000/360/2-way </font>
<br><font size=2 face="Times New Roman">each with:</font>
<br><font size=2 face="Times New Roman">2 x 360 MHz CPU (PA8500)</font>
<br><font size=2 face="Times New Roman">iCOD 2 extra CPU (These were cold and unactivated, but we had to activate them the first week we went live)</font>
<br><font size=2 face="Times New Roman">3 GB RAM (Memory had to be increaced to 9 GB after 1 week in production)</font>
<br><font size=2 face="Times New Roman">2 x 18 GB internal disk</font>
<br><font size=2 face="Times New Roman">100 BaseT 4 ports x 2</font>
<br><font size=2 face="Times New Roman">2 x 2 ports FC adapter</font>
<br>
<br><font size=2 face="Times New Roman">OnlineJFS</font>
<br><font size=2 face="Times New Roman">Mirrordisk</font>
<br><font size=2 face="Times New Roman">Glanceplus</font>
<br><font size=2 face="Times New Roman">Process Resource Manager</font>
<br><font size=2 face="Times New Roman">Serviceguard OPS </font>
<br>
<br><font size=2 face="Times New Roman">COMMON STORAGE</font>
<br><font size=2 face="Times New Roman">FC 60 Disk Array 16 x 18,2 GB disks (total of app. 290 GB brutto)</font>
<br>
<br><font size=2 face="Courier New">SOFTWARE</font>
<br><font size=2 face="Courier New">PowerHouse 8.23</font>
<br><font size=2 face="Courier New">Oracle 8.1.6 Enterprise edition</font>
<br>
<br><font size=2 face="Courier New">One of the HP9000 machines is running as Oracle server, the other is running PowerHouse run-time and applications. This was recomended by HP and Oracle, and was done do balance load at day-time, on-line use. This is probably not relevant for 25-30 users. For night-time batch jobs this may also not be optimal, as the machines tends to wait for each other when only one qtp executes at a time. ServiceGuard is configured so that one machine will take over both Oracle and PH, if the other machine goes down. </font>
<br>
<br><font size=2 face="Courier New">>- as it is a legacy application, no major additional changes to the<br>
>Powerhouse code. For example, at this stage, we are not to go into<br>
>dozens of QUICK, QUIZ, and QTP programs and code cursors.<br>
</font>
<br><font size=2 face="Courier New">We had the same strategy, but ended up doing at lot of optimizing with SQL and cursors in QTP. The most important lesson we learnt during the project, was that QTP will perform MUCH slower if you choose to convert without rewriting using SQL and cursors. On the other hand, using SQL and cursors may give reduction in execution times down til 10% of what HP3000/Image were capable of.</font>
<br><font size=2 face="Courier New"><br>
>It has been recommended by the Oracle DBAs here to spread the database<br>
>over 4 drives if possible (one ea. for the data, indexes, rollback<br>
>segments, and logging). Is it crazy to go with only one or two drives<br>
>for the Oracle portion of the application?<br>
I am not an expert on this, but both HP and Oracle told us that this is not a big issue any longer, due to HP9000 using "striping". To my knowledge, this means that HP-UX will spread data on several disks automaticatly at OS-level, and there is no need for Oracle DBA to place tablespaces on different physical discs.</font>
<br>
<br><font size=2 face="Courier New">>3. Expected use of of memory<br>
Our configuraton for 600 users is probably not comparable to Yours.</font>
<br>
<br><font size=2 face="Courier New">>4. Use of Cursors and imbedded SQL<br>
>As presently coded, the applications's Powerhouse code does not have<br>
>any imbedded SQL such as cursors. Yet it runs decently in the current<br>
>Interbase environment. With the move to Oracle, should we definitely<br>
>pick the critical processes to put cursors in? Or should we be ok<br>
>leaving it all with pure Powerhouse code?<br>
Our experience (as decribed above), was with code moved from TurboImage to Oracle. Moving from another relational (Interbase) to Oracle, may probably not give the same results. FILE / ACCESS / LINKs that does not perform well on relational, are probably avoided already(?)</font>
<br>
<br><font size=2 face="Courier New">Regards</font>
<br><font size=2 face="Courier New">Jon Kvisli<br>
----------------------------------------------<br>
Principal consultant<br>
Lindorff Applications as<br>
Hellandtunet research- & businesspark<br>
Postbox 4, NO-3833 Bo in Telemark, Norway<br>
phone: 35 06 15 71<br>
fax: 35 06 15 01<br>
jon.kvisli@lindorffapplications.com<br>
www.lindorffapplications.com<br>
----------------------------------------------</font>
<br>
<br>
<br>
--=_alternative 00550BA3C1256B65_=--