Conference ulysse::rdb_vms_competition

4.0. "ORACLE 5.1 info" by BISTRO::WATSON (this must be the place) Fri Jun 12 1987 15:56

    I've extracted this from the RDB conference. It's just the sort
    of information I'd like to see in this one.
    
    	Andrew.
    
                  <<< BANZAI::$222$DUA16:[NOTES$LIBRARY]RDB.NOTE;1 >>>
                           -<  Rdb/Whatever Notes  >-
================================================================================
Note 1148.0              ORACLE Competitive Information               No replies
NEWVAX::BOLLINGER "Alan Bollinger"                  330 lines   9-JUN-1987 15:55
--------------------------------------------------------------------------------

			ORACLE Competitive Information		1-Jun-1987

My district supports a number of government customers, prime contractors, and
large proposal efforts and we are running into a number of competitive
situations against ORACLE. ORACLE does a tremendous marketing job and are
tough competition in the relational data base marketplace. A number of 
customers who favor a RDB/VIA approach have asked for information or ammo to 
combat the ORACLE hype.

I have performed an analysis of ORACLE using their manuals (latest released
software 5.1) and included some of my own experiences using the product to
produce the the following report. If anyone has information that contradicts
my statements, or any additional competitive tidbits please post to the notes
file or send me mail at NEWVAX::BOLLINGER. 

Some thoughts when considering ORACLE for data base management under VAX/VMS.

			VAXCLUSTER SUPPORT

ORACLE does not support after image journaling in clusters (reference ORACLE
for VAX/VMS installation and User's Guide page 37).  Thus, DBA cannot
rollforward database in case of failure resulting in possible loss of 
productive work.

Currently ORACLE has a very limited number of sites running in a cluster thus 
no extensive user base or performance data available for cluster processing.
The ORACLE documentation provides very little information about running in a
cluster. There is no information to help the DBA , ie. What happens when a
node in the cluster goes down, does every database user on the cluster stop?
Does ORACLE have to be "warm booted" or started over from scratch? What 
happens to the before image journal file? The only information provided is 
about how the DBA must assign segments of the before image journal file to each 
node in the cluster (see more about this in the space allocation section below).

RDB takes full advantage of the VAXcluster environment by providing concurrent 
use for all users as well as clusterwide journaling with automatic recovery in 
the event of a node failure. RDB provides complete documentation for running in 
the cluster environment.


		CAPABILITY FOR LARGE NUMBER OF FIELDS IN RECORD 

ORACLE databases are restricted to 254 fields (columns) per relation (SQL*PLUS
User's guide, page 1-9). Joining tables together doesn't solve this because
ORACLE cannot update through a join. This can be a hard stop for certain
applications. For example CENSUS Bureau requirements for to 1,000 to 2,000
fields per relation was the primary reason for excluding ORACLE from a major
procurement. RDB has no architectural limitations for such "large record 
capability".


			PRECOMPILER SUPPORT

ORACLE precompilers are not as well integrated into the VAX/VMS environment as
is RDB. As stated in the ORACLE for VAX/VMS installation and User's Guide,
page 138:
    "You should use the /NOOPTIMIZE option when compiling for the following
reason. Compilers in VAX/VMS optimize code by default, and such optimizations
may result in program variables being placed in registers or other temporary
locations for efficiency. If ORACLE tries to use variables which no longer
reside in the locations ORACLE expects them to, the program will behave
unpredictably when executed". 

RDB through the RDBPRE precompiler has no such restriction and thus generates
fully optimized code. 

ORACLE sells their precompilers separately requiring purchase (and subsequent
maintenance fees) for each language in a multi-language programming shop.
ORACLE does not have a precompiler for BASIC, which for some organizations can
be a hard stop (programming through the ORACLE calling sequence is quite
difficult). RDBPRE is included with RDB and provides language precompiler
support for COBOL, FORTRAN, BASIC, PASCAL and C. Each release of RDB provides
an updated version of RDBPRE to accommodate changes and enhancements in the
VAX/VMS language compilers. It is a totally integrated programming environment
versus the "generic" precompilers offered by ORACLE. 

ORACLE provides no means of record level data manipulation as does RDB with 
the GET * syntax. Given a sample application of creating an RMS sequential
file from say a 30 field relation requires SQL statements to retrieve all 30
fields. In addition, ORACLE provides no means of extracting the entire 
database record definition into the host language as does RDB through the CDD.
So for the sample application, the RDB program would contain a statement like
COPY "PERSONNEL.RDB$RELATIONS.EMPLOYEES" FROM DICTIONARY to define a file
record layout. The equivalent ORACLE precompiled program would have to custom
code the 30 field layout and of course have to be updated anytime the 
relation changed. The RDB program would merely be recompiled with the latest
definition pulled from the dictionary.

The ORACLE syntax for the precompilers is somewhat more complicated, messy,
and requires more effort of the programmer then the equivalent RDB precompiler
statements. For example all host language variables that the program will use
for any of its database operations MUST BE defined in an ORACLE DECLARE 
section. There are a number of restrictions on what and how variables can be
defined. For example in COBOL, any field to be accessed by an SQL statement
must be explicitly declared in the DECLARE SECTION ie.
	
    EXEC SQL BEGIN DECLARE SECTION END-EXEC
    01  PENAME			PIC X(9).
    .
    .  All other fields used by any query
    .
    EXEC SQL END   DECLARE SECTION END-EXEC

The variable must be declared at either an 01, 77 or 05 level and must be
restricted to a selected set of datatypes (PRO*COBOL user's guide, 2.1.1.2).

The programmer also needs to define an SQL communications area, provide
statements for the program to CONNECT to the ORACLE database system specifying
usernames and passwords in some cases and provide different syntax for queries
that return one row or multiple rows. 

RDB provides a single invoke statement to attach to a database, security
is handled by via ACL and UIC processing as is normally done with VMS 
requiring no user "logons" to the database. Multiple record
queries are more easily handled with the START_STREAM syntax and the 
precompiler code notation of &RDB& is simpler than having to define
EXEC SQL <SQL code...> END EXEC for all database commands. 

Also the single integrated RDBPRE command which performs precompilation and 
compilation using all specified compiler switches is faster and easier than
the two step ORACLE pre-compile and than the system compile. Also linking 
with RDB is much more straightforward (LINK <program>) whereas with ORACLE
additional libraries and parameters need be specified. From ORACLE for
VAX/VMS Installation and User's Guide, page 138) "To link a program on
VAX/VMS, use the following command, subsituting your program's filename for
xxx:

@SYS$ORACLE:LOUTL EXE$:xxx OBJ$:xxx,SYS$ORACLE:SQLLIB/LIB MAP$:xxx S

This assumes that the following logicals have been assigned: EXE$, OBJ$,
and MAP$. The "S" stands for shared link. If you want to use the debugger,
use SD instead of "S". If you want a link map, use "SM" or "SMD".".

			   SPACE ALLOCATION

ORACLE's architecture for data base files as well as before and after image
journal files are all based on static file allocation. ORACLE provides no
dynamic allocation or expansion as with RDB. Thus the DBA has considerably
more work since constant monitoring of the database and the image files is
necessary to prevent program aborts due to exceeding the staticly defined 
file size. The DBA can extend files once created but it is not dynamic and it
must occur during a quiet point of database activity. This static methodology
requires that disk space be left unused to allow for potential future growth
and when it fills up, add a new unused disk partition (ORACLE Database
Administrator's Guide, page 100.  Contrast this with RDB which allows for
AUTOMATIC dynamic allocation of disk space and thus grows as the database
grows (same for journaling files). 

In addition to static file allocation, each table (relation) and its indexes
are also allocated fixed amounts of space within the file. For example, when a
relation and is defined an initial chunk of the total allocated
space is set aside for data that may be inserted into the relation. As the
number of records in the relation grows and uses up the initial chunk, another
chunk of space is allocated within the fixed "partition" if it exists. When
records are deleted from the relation the SPACE IS NOT RETURNED FOR GENERAL
DATABASE USE but is still reserved for that relation. The same scenario exists
for every index defined, fixed initial allocation, as index structure grows
allocate more fixed chunks if index size shrinks space is not recovered for 
general use. Think of the DBA who must monitor not only physical file size
limits being exceeded but also not enough internal space for a relation or
index to grow and trying to allocate space for relations to not consume
more space than actually necessary.

Contrast this with RDB which does not preassign space and when records are
erased the space is available for use by all relations or indexes. 

In the cluster environment, ORACLE requires that the DBA pre-allocate sections
of the before image journal file to specific nodes in the cluster. So if 
100,000 blocks have been allocated for the before image file, then contiguous
sections of this file must be allocated to specific VAXes (say 25,000 blocks
to each of four nodes). Problems arise when a specific node performs more work
than its allocated size, and thus data base processing aborts for lack of
space to write out before images. Also when a new node is added to the cluster
the DBA must then resize and reallocate the image file (of course shutting
down the database to do this). 

Since RDB was carefully designed to run in the cluster environment, none of
these problems exist. Before image files are allocated per run-unit, after 
images (which are not supported by ORACLE in clusters) are handled as in 
single node environments with dynamic allocation of space. There are no
additional tasks for the DBA to perform in the cluster environment.

		         DBA ACTIVITIES

Running ORACLE databases requires considerably more work and sophistication
on the part of the DBA. Not only the file and space monitoring mentioned above
but also with regards to controlling user access to the database(s). Under 
ORACLE each user requiring access to a database must be "enrolled" as a valid
user in the ORACLE authorization file. The user can either be given an ORACLE
userid and password or allowed to use his same VAX/VMS username. ORACLE does
not use the ACL approach like RDB or have the concept of "groups" for easy
authorization of common groups of users like finance or personnel. So in 
addition to the normal system manager functions of authorizing system users, 
this information needs to be transmitted to the DBA so he can add the USERNAME
to the ORACLE authorization list. This can be an administrative headache 
in a large environment (hundreds of users) adding each new user, granting read 
or write access to each specific database and all the relations. The username
password approach is used to allow users to access data they may not normally
be allowed to see. For example if user ADAMS wants to see user SCOTT's data
he must CONNECT to the database as user SCOTT and KNOW SCOTT's password. The
programming examples given by ORACLE show hard coding username/passwords in
programs or prompting the user for this info (with echoing of passwords to
the screen). This certainly bypasses the many C2 security features already
provided by the centralized, controlled functions provided by VMS that RDB
takes advantage of including the general rights identifiers (ie DATAENTRY,
PAYROLL, FINANCE) but also system defined indentifiers like BATCH, NETWORK,
DIALUP, and INTERACTIVE. It is more effective and secure to make security
assignments from one central point with appropriate auditing and alarms than
an additional layer of passwords to remember.

Installing and establishing ORACLE on a system and defining databases is quite 
complicated compared with RDB. There are a number of ORACLE parameters to
be concerned with for an ORACLE "sysgen". There are a number of utilities for
booting ORACLE or either warm or cold, starting the 4 system processes that 
control ORACLE operations, and creating the preallocated database and journal 
files.

The RDB monitor is started when the first database command is issued, and 
defining a database file is as simple as DEFINE DATABASE XYZ.


			OPERATING SYSTEM INTEGRATION

ORACLE is a multi-vendor database management system and as such has been
architecturally defined to the lowest common denominator. Some of these
design constraints can be easily seen in the way databases are defined, 
the primitive precompiler support, the amount of DBA intervention required,
and the lack of support for enhanced operating system capabilities (ie,
clustering, dynamic allocation, security, etc.). Even though ORACLE is
DEVELOPED on VAX's first and then ported to other systems they have not
added features to the VMS version that may conflict with the broad base
of machines that are supported. Thus ORACLE will never fully utilize the 
features of a particular operating system because of commonalty requirements
and of course maintenance problems.

Because VAX RDB/VMS runs only on the VAX under VMS it is optimized for that
environment (languages, security, clusters, allocation) and will take
advantage of the processor, mass storage, and operating system enhancements of
the future. 

			APPLICATION INTEGRATION

ORACLE provides a set of very tightly integrated products for application 
development (REPORT, FORMS, CALC, GRAPH). This can be good if these products
meet all of the user requirements and there is no need to do something outside
of the product set. It is bad if you are developing a large or complex set of
applications which require capabilities beyond those provided. Again, remember
that ORACLE is developing for a broad product base and must provide features
that can be used in all environments. Thus the FORMS product may not provide
all the features that your terminal or hardware provides or the GRAPH product
only works with a limited set of equipment, or more commonly, what if you needed
to use data not in an ORACLE database. This integrated product set is designed
to work with ORACLE databases only, not as is often required to interact with
the native file system (ie sequential, indexed sequential, or even other 
databases). So if you like the query language but dislike the report writer
too bad your stuck with it.

RDB is provided as a general purpose database management system. The user 
can select the tools best suited to the task:

   forms management   - FMS, TDMS 
   query language/4GL - SQL, DATATRIEVE
   report writer      - DATATRIEVE, DECREPORTER
   end user tools     - TEAMDATA, INTELLECT
   application devel. - ACMS, RALLY, COBOL CODE GENERATOR

ORACLE does not support capabilities such as the Data Distributor or interface
fully with ACMS, ALL-IN-1 or provide capabilities provided by RALLY or
INTELLECT. In addition to DIGITAL's offering there are a number of third party
packages that can be used and will be many more in the future. Because RDB is
DSRI (DIGITAL Standard Relational Interface) compliant it can access data in
other DSRI compliant databases. The product is based on an established,
published interface that provides an architecture to base future DIGITAL (and
third party) products on. The DIGITAL philosophy of defining an architecture
and then building on it (as with the VAX hardware architecture, VMS operating
systems, Digital Networking Architecture, DSA, MSCP, etc) has been recently
recognized by the industry and of course DIGITAL's customers as the way to do
it. The same is true for DSRI. Compare this methodology with ORACLE and other
vendors packages where the are no published standards or base architecture. 

			PRODUCT QUALITY AND SUPPORT

From my own personal experience ORACLE software and documentation has a lot to 
be desired. There seem to be a number of rough edges in various ORACLE 
products which are too numerous to go into here and will probably be fixed in
future releases. But ORACLE has a tendency to rush products to market without
adequate testing and then do major sales and marketing efforts based on these
capabilities. A number of examples come to mind related to SQL*FORMS, SQL*NET,
and SQL*CALC where their marketing makes extravagant claims which are not 
backed up by product performance. ORACLE is often selling futures (beta 
versions) as the real thing compared to DIGITAL which is very conservative
about new releases and product announcements. 

ORACLE is experiencing stratospheric growth right now and as such is having a
hard time supporting its existing customer base as well as new product
development for its broad vendor base. The regional sales offices are
understaffed technically and this places big demands on its California offices
to answer technical questions and resolve problems. Even though it is an
established organization (over 10 years old) it is experiencing many of the
same problems as small startup firms. 

The documentation has improved quite a bit from earlier versions but still
does not compare to DIGITAL quality and still has many holes in important 
areas not only for the DBA but for programmers and users as well (a set of
Guide to ... type books would be useful).


			MISCELLANEOUS NITS

The ORACLE report writer is similar in style to the document processing
languages under UNIX (ie. ROFF, NROFF, etc.) and as such is somewhat complex
for the novice/technical user to develop reports. It is much more a
programmers language than suited for a general technical user. Compare the
syntax and style of a DATATRIEVE and ORACLE report procedure and decide for
yourself which is easier to read and understand. (ORACLE REPORT WRITER'S
USER GUIDE)

Text output files created by ORACLE (such as SQL*PLUS query results or 
reports) are of type StreamLF rather than Variable Length and as such cannot 
be mailed unless they are first edited. (ORACLE for VAX/VMS installation and
User Guide page 87).

SQL*CALC was purchased by a third party, ported to the ORACLE environment, and
subsequently has a number of problems.  It appears to need PDP-11
compatability mode to run (although their market literature does not identify
it as such - perhaps it will be rewritten for native mode in a future
release). It has a number of problems with memory management (ie. 1 VMS block
required per cell and no release of allocated memory for deleted cells) which
are possibly fixed in a new beta version. It also claims to be a LOTUS like 
interface but very few functions or commands actually perform like LOTUS.

    Below are some additional notes on Oracle; they may be of use
    
    
    
    -------------------------------------------------------------
    
    			Database Structure
			------------------

An Oracle database structure is given diagrammatically below:

			----------------
			:   database   :
			:   structure  :
			:              :
			----------------
                                :
                                :
      ---------------------------------------------------	
      :                :                  :               etc
  ---------        ---------          ---------
  : System:        :       :          :       :
  : p'tion:        :       :          :       :
  :       :        :       :          :       :
  ---------        ---------          ---------
      :
      :------------------------------------ etc
      :           :           :
  ---------   ---------   ---------
  : file  :   : file  :   : file  : 
  :   A   :   :   B   :   :   C   :
  ---------   ---------   ---------

The database is split into partions. The SYSTEM partion holds the 
metadata definitions. Use the 'CREATE PARTITION' SQL (Oracle extension)
command to create new partitions. Partitions cannot be removed from the 
database. Partitions are made up of files. Use the 'ADD FILE' SQL 
(Oracle extension) command to add new files to a partition. A file
once added cannot be removed without unload/load sequence. When the
Database is first initialised the system partition is created with a
single file. 

When creating a table (relation) you must specify a 'Space
definition'. A space definition is a record stating the initial number
of pages required, increment amount, and number of increments (or no
limit to number of increments) and the partition for both data and
index. Increments are not returned to the system. To reclaim space you
must export then import using Oracle utilities (like RDO BACKUP
RESTORE for a relation); but first you have to drop (delete) the table
then respecify before importing. 

The data and index are held in the same file; you have to specify index 
pages, so if there is no index needed then specify a low number of index 
pages.Increments for data or index pages are taken out when needed.
A column (field) can only be in one index definition (unlike Rdb where
columns can be in as many index definitions as required). 

Column definitions are stored in both the SYSTEM partition and in the 
actual table definition area (of its file) for faster access reasons. 
The Oracle software maintains consistency of the definitions.

When creating 'space definitions' you have to specify the % usage to 
allow for expansion eg new columns, extending fields etc.

Records are chained together in the table space per page. Deletions of 
rows (records) cause gaps in the chain; space is only reclaimed if a 
complete block is emptied. New records are added to end of chain in
the page. 

Unused columns are not stored as 'missing'.

There is limited data compression in that no trailing spaces stored; no 
other compression done. Numbers are stored to a base of 100 with maximum 
size of 22 bytes per number.

Indexes are held as B-trees with optional compression (the default) 
using Oracle's own sort algorithm.

The table area (Space) contains the column definitions & index 
definitions, and pointers ie the table map, to any extents of the
relation. Oracle uses 2048 bytes per 'Oracle block'. All definitions use
'Oracle blocks'. 

			Oracle Utilities
			----------------


IOR	DBA utility
-------------------

The Oracle DBA has the IOR utility which includes the following 
commands:

1)	I

This initialises a database (like RDO DEFINE DATABASE). The DBA in 
effect adds a file to the database which causes the system partition to 
be created. A 'warm start' is also performed -- see 2) below.

2)	W

This is the 'warm start' to an existing database; its a mixture of 
system startup and invoke. This command causes Oracle to do any 
necessary recover of the database eg by applying the BIJ files for 
failed user processes etc. Oracle then starts up the 4 detached 
processes as follows:

	ARH	Aysnchronous read ahead process;

		This tries to anticipate user requirements by doing
		read aheads and buffers the data; attempts to improve 
		performance.

	CLN	Clean up process;

		This detects user failures; does rollback; tidies up 
		etc.

	BWR	Buffer writer process;

		Does database writes.

	BIW	Before Image Writer process;

		There is one process that writes to the BI file for all 
		users of the database. There is one BI file per 
		database. The BI file size is about 1/3 to 1/2 database 
		size but depends on the number of writers to the 
		database. The size has to be defined by the DBA when 
		using IOR to initialise (and warm-start) the database.

Note that these 4 processes are per actively used database. For example 
if you had a live and test environment running side by side then there 
would be 8 processes running; 4 per database. The actual process name 
take the format for example, ORACLEn$BIW where BIW is the Before Image 
Writer process and 'n' is the database identifier. This is a single 
letter, defined by the logical name ORACLE$SID.

3)	S

This is the shutdown process. When all users off the database then the 4 
detached processes are run-down.

4)	C

This is the quick shutdown. It basically stops the detached processes
immediately. Note that it is possible that a user still has the
database files open so that the database cannot be 'warm started'
until that user quit his program. The database is not corrupted as the
user onl has read access. 

SGI	System Global Information
---------------------------------

This utility gives system global information. The System Global Area 
is useed for communication between process, global data buffers, table 
definition cahce, lock information etc. When Oracle is 'warm started' 
the size of the SGA is calculated and taken out of the SGA Pad. The
size of the SGA Pad is fixed at link time. The default is 512K bytes.
Its used by all the Oracle utilities and pre-compiler process
(actually when linking). 

Because the Oracle internals don't use transfer vectors, then if you
have to change this area size then you have to effectively re-install
Oracle and relink all Oracle utilities and all your programs. 

When Oracle release an upgrade, you also have to relink everything.

The default SGA pad is usually enough to cater for 2 databases.

CCF	Create Oracle File
--------------------------

This utility creates an empty 'Oracle' formatted file that can then be 
added to an Oracle database partition.

AIJ	After Image Journalling
-------------------------------

This is optional (as it is under Rdb). The AIJ file is defined by 
parameters used in the IOR utility. There are two modes of using AIJ. 
The first mode is to let Oracle write to an AIJ file and when that 
becomes full, let it write to a new file, and so on. The second mode is 
to let Oracle cycle between a preset number of AIJ files. When one 
becomes full, it moves onto the next. The user must backup the AIJ then 
run AIJZ to re-initialise the AIJ file in time for the next usage in the 
cycle. There are messages to the operator terminal to say when files 
become full and AIJZ needed.

AIJ is switched on as part of IOR W command.

AIJ is not supported across clusters.

ODS	Oracle Display system
-----------------------------

This enables one to look at the detached Oracle processes. One can 
monitor locking, BI file & usage, users, etc.

Pre-compiler
------------

For Oracle extensions to SQL, one uses 'EXEC ORACLE' to indicate these 
extensions; similar to 'EXEC SQL'.
    

    Notes 4.0 and 4.1 contain some excellent information regarding ORACLE.
    I would just like to clarify a few points based upon my experience
    using ORACLE.
    
    re: .0
    
    "ORACLE provides no means of record level data manipulation as does RDB
    with the GET * syntax. Given a sample application of creating an RMS
    sequential file from say a 30 field relation requires SQL statements to
    retrieve all 30 fields. "
    
    I am not yet familiar with Rdb (and therefore the GET statement)
    but you can manipulate individual records using SQL or IAF (now
    known as SQL*Forms) by specifying the search criterion in a SQL 
    statement.  
    
    
    "...In addition, ORACLE provides no means of extracting the entire
    database record definition into the host language as does RDB through
    the CDD. So for the sample application, the RDB program would contain a
    statement like COPY "PERSONNEL.RDB$RELATIONS.EMPLOYEES" FROM DICTIONARY
    to define a file record layout. The equivalent ORACLE precompiled
    program would have to custom code the 30 field layout and of course
    have to be updated anytime the relation changed. "
    
    I know that through using the ORACLE procedural call "ODESC" one can
    dynamically describe a table (relation) within an ORACLE database. I
    don't know if this facility is available with the Precompiler
    interface.  If this is not available, users could select values from
    the dictionary tables to describe a user's table. 
    
    In regards to space allocation, the argument that will be used by
    ORACLE is that a database will not be able to consume a disk, and
    grow "out of control".  I would be careful and make sure that the
    customer would prefer dynamic database file growth.  Also, space
    allocation for individual tables and their indexes increases their
    performance, so I would not consider this a negative trait of ORACLE's.
    
    
    "...The username password approach is used to allow users to access
    data they may not normally be allowed to see. For example if user ADAMS
    wants to see user SCOTT's data he must CONNECT to the database as user
    SCOTT and KNOW SCOTT's password. "
    
    This is certainly a way for one user to look at another user's data,
    but the more common approach is for a user to grant access privileges
    to other users.
    
    " The programming examples given by ORACLE show hard coding
    username/passwords in programs or prompting the user for this info
    (with echoing of passwords to the screen). "
    
    This is an example of their poor documentation.  One certainly
    can code an application so that user passwords are not echoed. 
    The screens generated with SQL*Forms do not echo the user password.

    
        
    "From my own personal experience ORACLE software and documentation has
    a lot to be desired. There seem to be a number of rough edges in
    various ORACLE products which are too numerous to go into here and will
    probably be fixed in future releases. But ORACLE has a tendency to rush
    products to market without adequate testing and then do major sales and
    marketing efforts based on these capabilities. A number of examples
    come to mind related to SQL*FORMS, SQL*NET, and SQL*CALC where their
    marketing makes extravagant claims which are not backed up by product
    performance. ORACLE is often selling futures (beta versions) as the
    real thing compared to DIGITAL which is very conservative about new
    releases and product announcements. " 


    How true!  I don't think this can be emphasized enough.  I understand
    the ORACLE has now centralized their support in California but their
    response times still leave much to be desired.  The also have a
    track record of talking about futures as if they are existing products.
    Their delivery schedules are consistently late and not to be trusted.

    
    re: .1
    
    DATABASE STRUCTURE:  "...A column (field) can only be in one index
    definition"
    
    I don't believe that this is true.  I've had columns indexed
    individually and then combined in other indexes to form a concatenated
    key.

    ORACLE's space allocation has even more problems.  If one fills
    a block with records it is marked "full" by the DBMS.  Subsequently,
    if one deletes all of the records from the block, the flag indicating
    a full block is not changed and is therefore wasted.  My experience
    indicates that this happens in system space as well and ORACLE
    eventually eats it's own space up and has to either be reinitialized
    or the database has to be added to.

    SYSTEM GLOBAL INFORMATION 
    "Because the ORACLE internals don't use transfer vectors, then if
    you have to change this area size then you have to effectively
    re-install ORACLE and relink all ORACLE utilities and all of your
    programs."
    
    The only thing that you must do to increase the size of the SGA
    is to bring down the database and then bring it back up (after you 
    have changed the INIT.ORA parameters). You don't have to relink your
    programs or other applications.  One point to mention, though, is that 
    the SGA has a based address. If you have to move it because of conflicts 
    with other software, the procedure can be messy.  If this has to be done, 
    I believe that all of the ORACLE utilities must be relinked and any user 
    application that has been written must be relinked as well. 


    

IOR under 5.1.17 of ORACLE RDBMS also allows a parameter to start up
    ORACLE as a single detached process instead of 4.  It is not
    reccommended to do this.
    
    Warmstarts in a a VAXcluster when ORACLE is a shared database (ORACLE
    CLUSTER) is something else.  There is a known problem.  The first
    instance to warmstart ORACLE locks the .BI file (Before Image file).
    If another node is warmstarting and at the right point its warmstart
    will fail as will any others.  We've had only one,two or three of four nodes
    come up as a result of this collision sometimes.  To recover an
    IOR CLEAR SHARED performed on each of the nodes not warmstarted
    then an IOR WARM SHARED on that node.
    
    Here's another interesting tidbit I gleaned form Richard Barker, Executive
    Director of ORACLE UK.
    
    $ assign tt: oracle$dmp
    
    then when in SQLPLUS, ORACLE's interactive facility
   SQL> select trace('ACCESS',1) from sys.dual;
    
    This turns on trace information to the terminal. Now you can check out
    what indexes etc. are being used in the query path.  This is not
    documented and I've never been able to get another ORACLE consultant
    to talk aabout it.
    
    the sys.dual can be anything, the table does not have to exist,
    it just satisfies syntax, ignore the errors about existence.
   ('ACCESS',0) for the function turns the trace off. 
  
    
    It works under 5.0.20 and 5.1.17 production (not beta), and
    if I remember correctly under 4.1.14 as well.
    
    --Tim

    Does Oracle have an optimiser? I had heard that it didn't.
    
    Richard

Yes they do.  But from the information I have it is less sophisticated
than that in Rdb/VMS.  I don't believe they maintain cardinality.  They
simply try to see which indexes are available for use and apply rather
straightforward rules.  There really is no way (without cardinality)
that they can optimize join order.

    On the FROM clause list the tables in order of most rows to fewest
    rows, eg. FROM max_rows_table, 100_rows_table, fewest_rows_table.
    ORACLE parses lines from end to beginning.  Now it will be a little
    more efficient.
    
    --Tim