| I have a customer who is running ORACLE 5.6 (and are going to move to V6.02
soon) on a VAXcluster and are having all kinds of problems. So they called
ORACLE and ORACLE support is blaming their problems on our disks.
��� It is possible that we had a disk failure that cause a corruption of
an Oracle data structure. But... if the customer is having trouble
running Oracle V5 in SHARED mode from two nodes (or more) in a
VAXcluster, that is DEFINATELY Oracle's problem ONCE our disks
have been given a clean bill of health. (BTW, if you could
describe the problem, you may be able to get a better answer.)
Are you sure about the version number ? The last number I have
for version 5 is 5.1.22 and 6.0.33 for TPO.
Go figure. So they will not help the customer resolve their problem.
��� If the customer is on Oracle support, Oracle should help the
customer restore and recover a corrupt database file. If
Oracle can't help the customer, I don't know how we can either.
If the customer on Oracle support ?
So our customer has come to us for help. We have strongly recommended many
times that they migrate to Rdb, but unfortunatly their hands are tied with
ORACLE right now due to financial and political constraints.
��� Migration off Oracle to anything else really doesn't have anything to
do with Oracle's ability to support a customer who is in a down
condition.
First of all we told them that Oracle doesn't run in a clustered environment...
And we recommend that they run it on one VAX only.
��� Be careful with your words. I have written about the cleaver words Oracle
uses when describing their ability to run in clusters. Those comments
are in other topics in this notesfile. Technically, Oracle runs in
a cluster just fine. What Oracle DOES NOT do is allow the same PHYSICAL
database to be accesed by Oracle from more the one node in a SHARED
mode. They ARE able to run one database per node just fine. There's
a big difference in these two statements and I suggest you read my
previous notes for a more detail explanation of Oracle in SHARED mode
in VAXclusters. And oh by the way, Oracle ALSO recommends one database
per node too.
So they have some questions for us that I don't have answers for... maybe
someone can help.
��� I understand your desire to help the customers but, honestly, Oracle
should answer questions about their ability to run in our
operating systems.... but I know the answers to what the heck !
1. Is there any other customers out there that are running ORACLE V6.0x
on one VAX in a cluster. ARe they having any problems with this?
��� Yes ... many customers. No they are not having any problems other and
poor performance in certain situations which are due to Oracle's
poor architecture for handling complex transactions. Certainly
there are NO problems that belong to Digital not matter what
Oracle would have your customer think. I can think of one
customer who has two clusters (8840/6460 and 8550/6420) who has
been doing this exact thing for two years. They're still in
business !
Does anyone out there that know of any problems of running ORACLE V6.0x
on one machine in a cluster, will you please let me know?
��� No problems .... Oracle is just another VMS, privileged application
that's chewing up cpu cycles like crazy !!
2. My customer is going to ORACLE 6.02 and have purchased locking options.
Both table locking and row locking are a concern. Does anyone know of
any problems with either table locking and row locking with ORACLE?
��� Table locking which was a severe problem for Oracle V5 is, for the
most part, solved in Oracle v6. I don't understnd why row locking
would worry the customer. As with most database systems, there
are bound to be a few bugs along the way but your customer
(who appears to be very paranoid) really should not worry about this.
For sure, though, they MUST read the Oracle release notes and follow
Oracle's suggestions for migrating from v5 to v6. They have done a
pretty good job describing the issues surrounding table vs. row level
locking. One thing to be aware of is the fact that row level locking is
much more cpu intensive than v5's table locking .... so watch the cpu
meter after they install. You may get an upgrade order !!!
|
| Watch this customer closely!
Since ORACLE is blaming the customer's problems on DEC disks, chances
are that they might suggest that they switch to HP or Sequent, etc.
Especially if they start experiencing performance problems. ORACLE's
price/performance on an HP is a lot better than on a VAX.
|