[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference ulysse::rdb_vms_competition

Title:DEC Rdb against the World
Moderator:HERON::GODFRIND
Created:Fri Jun 12 1987
Last Modified:Thu Feb 23 1995
Last Successful Update:Fri Jun 06 1997
Number of topics:1348
Total number of notes:5438

722.0. "Getting closer to a win" by BALDIE::GREER () Mon Aug 27 1990 20:48

The Florida Dept. of Law Enforcement proposal review is moving forward.  At this
time it looks like the short list will be us and Oracle.  We bid two 9000-410s
(with 4000s on the front-end) and they bid 2 Unisys 6000/80s.  These are UNIX
based boxes, each of which contains 16 80386s which supposedly are 5 mips each.
(Hence the /80 is for 80 mips!!!!).

Anyway, we are going to have to defeat the big O in an operational assessment
which will focus on both performance AND availability.  We have some folks who
are working on this here in ALF who have (1) Rdb backgrounds, (2) Unisys back-
grounds, and (3) some UNIX experience.  We also have some Oracle information
(compliments of Mike Booth, Cynthia Therrien, etc.).

What I am looking for is some very specific knock-offs of Oracle in a UNIX 
environment.  Or, better yet, somebody with some experience with the U6000/80
platform.  I have heard that there are MAJOR problems with UNIX in a commercial
environment, but I don't have the particulars.

If anybody has some specifics, or some names to call, I definitely will follow
up.  THANKS in advance for all help.

Rusty.
T.RTitleUserPersonal
Name
DateLines
722.1Start HerePOBOX::BOOTHBo knows MUMPSTue Aug 28 1990 00:436
    Try the BELFST::ORACLE_ON_UNIX notes conference. Most of this type of
    experience is in Europe, but at least you will have some contact names
    as the Europeans have vastly more experience than we do in the UNIX
    environments.
    
    ---- Michael Booth
722.2Follow-up questionsBALDIE::GREERWed Aug 29 1990 23:1311
Thanks Mike.

A couple more questions:
(1)  Are the knock-offs in the Oracle V 6.0 Competitive Fact Sheet true for
	Oracle in a UNIX environment?

(2)  If I am benchmarking against Oracle, what "tricks" should I be sure to
	be alert to so that I can keep the playing field level?  (Not that I
	distrust those guys or anything.....)

Rusty.
722.3DifferentPOBOX::BOOTHBo knows MUMPSThu Aug 30 1990 17:2016
    I'm not sure what you mean about applying the "knock-offs" to Oracle on
    Unix. Databases work differently under Unix. On a proprietary system,
    the operating system generally handles the basic file system, memory
    allocation, disk I/O, memory management, etc. On Unix systems, the
    database software generally supersedes the operating system and does
    the above at the DB level. There was an April, 89 article in Database
    Programming & Design about how high-performance UNIX database vendors
    function. They interviewed engineers at Oracle, AT&T, Sybase, and
    Informix. In the case of Informix (the leader in the Unix market), the
    disk space for the database is literally turned over to the RDBMS
    software, which then bypasses the operating system to access and manage
    the disk. UNIX has no strong native file system. On a UNIX system, the
    RDBMS becomes the file system. So the orginal V6 comparison really
    won't hold for UNIX.
    
    ---- Michael Booth
722.4Some more detailsBALDIE::GREERThu Aug 30 1990 18:1423
Mike, thanks again for your response.  I recall that article and will reread it
to learn some more.

I understand some of the differences between UNIX and VMS and how they affect
databases.  When I referred to "knock-offs", I was looking specifically at
items that an operational assessment might uncover, such as:
	_ 1.  allocation of file space beyond assigned limits (extents);
	_ 2.  recovery from media failures;
	_ 3.  single processes for certain functions;
	_ 4.  multiversionning problem.

From my limited knowledge about Oracle, all of these items could be problems 
that a properly designed operational assessment would expose.  We have the chance
to influence the tests, so I was attempting to determine if these same problems
would exist in the UNIX environment.  It seems like they would, but I was hoping
for some verification.

Finally, I must admit that I don't understand #4 above sufficiently well enough
to design a test scenario that would make it clear to the customer.  Can one of
you Oracle experts please help out by laying out a scenario that would cause
the ORA-1555 error to occur?  (only if this problem also exists in UNIX)

Thanks again for the help.  Rusty.
722.5Try this for ora-1555MAIL::DUNCANGOracle... the one-line databaseSat Sep 01 1990 00:2357
    Two things:

    1.  Watch out for parameter PRE_PAGE_SGA which would be contained in
    the INIT.ORA startup file (probably named the same for both
    environments).  On VMS, this parameter can cause the entire database
    to be paged into each processes memory.  I assume it would/could work
    in a similar manner on U*x.

    2. To have a chance at the ora-1555 error, here's what you have to do.
    
    - establish small rollback segment sizes and only a few.  The rollback
    segment is used to recreate the read consistent view that a program
    needs when repeating a read within the same txn.
    
    - keep the sga as small as possible since it is used in concert with
    the rollback seqments to recreate the record for a read_only (snapshot)
    reader.
    
    - write two programs.  Program A must be designed to run a long time
    and should select a lot of records.  I believe you want to start the
    transaction read_only as well.  Within THE SAME TRANSACTION, repeatedly
    read the same records performing various routines.  For example, read
    all records and sort by name, then read all records and sort by number,
    print reports, etc.  But DO NOT commit or rollback ... keep the txn
    alive.  Program B must be designed to update the majority of the
    records that program A are repeatedly reading.  So, when you start 
    program A, start one or more copies of program B.  In program B, update
    some of the records, delete some, etc.  Commit often.  What should
    happen is this:  
    
    The first time through, program A should select a set of records.  Then
    as program B modifies the records, program A will loop and attempt to
    read the SAME records again.  When this happens, Oracle will recognize
    that the data pages have been changed by program B but will read them
    for program A.  In order to get the pages and records correct, Oracle
    will begin to read back through the rollback segments looking at time
    stamps (and probably dbkeys) until it finds the RUJ type records from
    which it can recreate the records before returning control to program
    A.  After sufficient activity, Oracle will reach the beginning of the
    rollback segments without finding  the appropriate records and thus
    will be unable to recreate Program A's read_only records.  At this
    point, program A should abort with the ora-1555 "rollback segment not
    old enough" message.

    - be sure to run the oracle test over-and-over to be certain you can
    reproduce this condition.  Be aware that Oracle will tell the customer
    to make the rollback segments larger, etc.  So be prepared for that.
    The important thing to note (and would be good to measure) is the
    tremendous CPU and dio load when Oracle is managing read_only txns of
    this nature.
    
    Let us know if you are able to reproduce this condition.
    
    -- gerry
    
	    	
    
722.6Former UnisysSRFSUP::DAYThu Sep 06 1990 21:594
    The Unisys 6000/80 is OEM-ed straight from Sequent, so any knock-offs
    of Sequent also apply to Unisys 6000/80.  The only difference is
    that Unisys does not use the Sequent version of Unix but supplies
    vanilla System V.3.1.