| See notes 295, 207, and 259. They provide additional details which
may be helpful. Oracle is great a creating confusion and those rumors
will get you every time !
------------------------------------------------------------------------------
Oracle 5.1.22 Information
------------------------------------------------------------------------------
- Runs under VMS 4.7 and 5.x. Install procedure links Oracle to VMS.
- Runs under SMP but not very well. My testing indicates that, under
certain conditions, 6230 runs no better than 6210. The biggest
drawback is lack of row level locking and a single VMS process
to read and write to the database. Generally, your performance
is only as good as the power of a single processor (2.8 VUPS).
- Runs in a VAXcluster as follows:
- Shared (Oracle term) Database uses same physical database and
causes significant DIO. Both nodes read and write to
to a segmented BI file. AIJ is not supported. Depending
on design, performance can be four times worse than single
node.
- Networked is where SQL*net (extra charge with Oracle, free with
Rdb) on node A handles DB requests from node B over DECnet
or TCP/IP. If node A fails, node B cannot get to the DB.
Performance is probably only as good as node A processor
load. It would seem that Ethernet would eventually become
a bottleneck.
Other V5 Comments
-----------------
- Watch yourself with terminology. Oracle will tell the customer it runs just
fine in a VAXcluster. However, I have checked these claims and have found
that in several instances, the customer has a VAXcluster BUT Oracle is only
used on one node. The reasons often cited by the customer are license costs
and performance.
- Depending on the application, table locking can cause significant performance
throughput. In a batch environment, our throughput with concurrent programs
updating the same table was no better than single threaded batch jobs.
- If running in a VAXcluster, insist on SHARED database.
------------------------------------------------------------------------------
Oracle V6.0.26.x Information
------------------------------------------------------------------------------
- Runs under VMS 4.7 and 5.x. Install procedure links Oracle to VMS.
Sub-directories and process names are tied to DECnet node name
making it difficult to move from one processor to another in
a VAXcluster.
- Runs under SMP. No problems here but remember, Oracle uses detached
VMS processes to read and write to the database and the journal
files. In an environment where there is significant table
sharing between updaters, Oracle V6 will probably perform better
on large uni-processors (8550) than smaller SMP processors (6320).
(I have numbers to prove this !)
- More CPU intensive (because of row level locking) than V5.
- Runs in a VAXcluster as follows:
- Oracle V6/TPO DOES NOT support an Oracle SHARED DATABASE !!!
- Oracle V6/TPO will run on a single node in a VAXcluster. I have
a customer with 8840/8550 VAXcluster. They have five
databases on 8840 and four on 8550. If 8840 goes down,
they have to run some .COM files to bring up 8840 databases
on 8550.
- There is no announced date for V6/TPO VAXcluster support. I know
for a fact that they left out VAXcluster support on purpose
so they could get the product out the door. As of xxx
they had the code figured out but have yet to test it in
any fashion.
Other V6 Comments
-----------------
- Our tests of Oracle V5 vs V6 show little, if any, base line performance
gains in V6. We had a program which only ran 1 minute faster under V6 than
V5. When you take away the performance gain achieved with the finer locking
(row level V6) which allows programs to continue to do work instead of
waiting for table locks, I'm not sure there is much "true" performance gain
in V6.
- As of a week ago, V6 STILL had bugs. One that has yet to be fixed is an
index corruption bug that can be created using SQL*plus.
Any other questions or need to discuss, give me a call at DTN 452-3445.
--gerry
|