| �� I have a customer running Oracle on the MV3400 with extremely poor
�� performance.
Gosh, except for the local account with a Cray, I've never seen a system where
the customer was happy with Oracle performance.
Need to define what "poor" means in reference to a previous point when the
system performed OK. For example, did the MV3400 start performaing bad AFTER
Oracle was loaded, after 50 users logged on, after ______ ??? Also, how was the
"poor" performance measured ? Batch throughput, terminal response time, VAX
monitor, etc.
�� Is there anyway of convincing the customer that it is the Oracle rather then
our hardware that is giving the problem.
Only with numbers from VPA, SPM, or VMS monitor. Anything else is likely to be
emotional and/or higly inaccurate.
Why should we have to convince them it is Oracle or the MV3400 at fault ? Is it
possible that the mv3400 is sized wrong ? Why do they think it is the hardware ?
What can't the problem be Oracle ? Can they justify their statements with
numbers ?
�� Any help will be appreciated.
I can probably help you but need to know a lot more detail. Start with getting
the customer to tell you how the system (hardware and software) was sized and
what assumptions they used. Then get them to tell you EVERYTHING they have done
to improve performance, what kind of discussions they have had with Oracle, with
Digital, and with themselves. Then give me a call or send Email and I'll try to
help.
-- gerry
|
| What I usually do is to check the VMS performance without Oracle
running. After I establish the baseline, we fire up Oracle and
measure some more.
It's been my observation that whether Oracle was installed by the
customer or by the Oracle reps, all of the default installation
parameters were taken. Worse yet, the database gets squeezed
onto a couple of drives which were hard hit prior to Oracle.
The Oracle folks usually are more application-oriented and it seems
like they get nervous around the potential sizing of machines and
VMS performance. So the finger pointing about machine sizes and
platforms and VMS. It's VERY EASY to say "VMS can't do it" or "That
VAX is too small." If Oracle has entrenched itself onto your site,
it makes it very difficult. .1 is correct. Why should we have to
prove that it's not our hardware or operating system? If the customer
is upset, have them request a performance study from both Digital
and Oracle. Make sure that you go face to face with the Oracle
reps. We have more experience with VMS and our hardware, we can
certainly establish our credibility. Keep calm, stay technical and
challenge them.
Once, an Oracle rep said to me, "we have to reduce the number of direct
I/Os to that drive. The customer needs a faster drive. It's a
bottleneck. The application will run better if the databse is on
a faster drive instead of the two drives which it's on."
I said, "The drives are not fragmented, there is only one file, your
database. There are no split-ios, so the XQP is able to satisfy
the requests. I think the problem is with the application design and
how you've set up the read/write requests.
Making this customer buy a faster drive is the wrong move because
unless there is something really wrong (like fragmentation or lots
of other requests), the performance really won't improve."
I should mention that the data base was on 2 RA90s (not shadowed),
isolated on their own HSC requestor. The problem was in the way Oracle
wrote the SQL requests, not in the hardware performance. Also, it
didn't help that they didn't load the database with the customer's
newest data, so basically, the jobs were infinitely looping, looking
for data which didn't exist!
In this war story, we came out ahead. Future development with
Oracle is on hold and the customer is writing an Rdb -Oracle position
paper. It has been noted that performance problems were not evident
with the use of RDB based applications.
Also, in 2 of this company's divisions, future development will be
RDB based. The reason was that they believed that Digital was in
a better position to provide support for applications and future
capacity planning for the platforms.
Regards,
Kathy
|