| Clive,
According to the CRA report, each user can read from the database
himself, but writes to the database have to go through a single
server process. So, it would suggest that a read intensive application
will benefit from SMP, a write intensive application will not.
I should say I'm just taking this from the book; I have no direct
experience with Oracle the product, though plenty with Oracle the
company.
PDB
|
| According to the Oracle V6/TPO documentation:
"... An instance refers to the detached processes that provide Oracle
users with read and write access to the database and the area of
shared VMS memory where data is cached for quick access."
"... an instance can access only one database at a time..."
"An instance of Oracle consists of:
o an area of shared memory where data is buffeed while it is
read or modified
o background processes that execute the actual read and write
routines from the Oracle code"
"When Oracle is used by multiple users, as is usually the case,
Oracle invokes up to five asynchronous server processes to perform
tasks that facilitate concurrent access of the database my multiple
users. These detached or background processes perform the read
and write operations required to copy data to and from the SGA and
to and from the database and redo log files. .....
The reading MAY be a possibility but I doubt it given this wording.
I know that writing is controlled by the BWR (buffer writer V5)
or DBWR (database writer V6).
Since all VMS processes DO NOT write their own pages to the database,
Oracle writers will only perform as good as a single CPU in the
SMP machine. For example, the 6240 (approx 11.2 VUPS) will probably
not perform as well as an 8820 (approx 11.4 VUPS). This is because
the 6240 engine (2.8 VUPS) is slower than the 88xx engine (6.0 VUPS).
It is important to note that Oracle has a direct mail piece with
a return card where VAX users can get their V6 benchmark information.
This reports basically says how much better and faster a 6240 is
than ANY 88xx machine. Oracle also has a good time telling any
and all customers how they returned the 88xx systems for 62xx systems
because the 6000 XMI bus was so much faster than that "doggy" 88xx
bus.
All of you should be aware that this benchmark used memory resident
tables and did not run long enough to force DIOs. Also, there is
strong indication that they used special benchmark parameters. (See my
previous entry in this notesfile re: Benchmark Parameters.)
Finally, Oracle would have NO advantage over Rdb when reading.
In fact, assuming each Oracle user does his own reads, this would
mean additional overhead to write to the global sections/cache his
fetched pages. If the cache is fragmented by lots of users with
different relations and/or rows, Oracle could (and DOES) become
very CPU intensive. There are also many other reasons why Oracle
could become CPU intensive as well .... row level locking is one.
Since each Rdb user has his own buffers and their sizes can be
different, the amount of CPU utilization (VMS lock manager) is kept to
a minimum and each application can be tuned for optimum performance.
--gerry
|
| First, let's define some terms. When you mention CPU, I assume you
mean a CPU board(s) in an SMP machine which is one DECnet node.
Our sales force (and Oracle's) try to make more of SMP than they
should. I've seen discussion between Oracle and Digital folks ramble
on for extended periods with topics like "taking advantage of SMP"
"SMP is fully supported", etc. Oracle will tell the customer that
they do not "take advantage of SMP" in their version 5.1. The truth
or the matter is that Oracle V5.1 runs just fine under SMP. What
causes the poor performance in Oracle V5.1 is TABLE LOCKING !!!
They are very clever in moving the responsibility for poor performance
away from themselves.
Oracle V6.1 too runs just fine in SMP but it is NOT optimized for
SMP machine. Oracle would like to have your customer believe that
but in fact the performance gains achieved (if any) are a direct
result of ROW LEVEL LOCKING .... nothing more.
Basically, everyone is trying to make Oracle and SMP more complicated
than it is. As far as I know, there is nothing in the Oracle read/write
processes (detached processes) OR in Oracle application programs that
require them to execute on the same CPU in an SMP machine. Nor
do I know of any parallel code features within Oracle. (Hell, they
can barely get the bugs out of V6 much less add VAXcluster AND parallel
support !!!)
This works the same as multiple COBOL programs accessing common data
files or global sections. Basically, the Oracle program (or RMS
program) does some sort of I/O request and, for all intents, goes to
hibernation waiting for I/O. (Whether the programs I/O buffers are
filled from global memory (SGA) or from RMS QIOs does not enter into
the picture.) After the buffers have filled and the program is ready
to run, VMS will put it on a CPU (within the SMP machine) which
VMS decides is least utilized.
By the way, this same VMS scheduling applies to the Oracle detached
processes as well.
In summary, yes the SGA can be accessed by more than one CPU within
an SMP machine at a time. Remember, the SGA is nothing more than
global VMS memory and global sections. As far as I know, Oracle
does not have parallel processing implemented in their V6.x.
Also, Oracle, so far, CANNOT provide support for SHARED databases
between VAXcluster nodes in Version 6.1
Does this help ?
--gerry
|