Conference ulysse::rdb_vms_competition

 
>>>Standards Compliance
>>> 
>>>ORACLE V7.0 is 100% compliant with level 2 of the SQL89 standard
>>>(ISO 9075-1989, ANSI X3.135-1989) as measured by the U.S.
>>>Government's National Institute of Science and Technology (NIST)
>>>SQL Test Suite.  ORACLE Version 7.0 achieved this result on
>>>official NIST tests in March of 1991.  In September 1991, Version
>>>7.0 also passed the NIST test suite on three UNIX platforms. An
>>>ORACLE Precompiler (V1.5) option is provided to flag the use of SQL
>>>extensions as required by FIPS 127.  In addition, ORACLE Version
>>>7.0 is designed to comply with Orange Book C2 level requirements. 
>>>Version 7.0 is currently being evaluated by the U.S. Government
>>>National Computer Security Center (NCSC) for compliance with the
>>>C2 rating.  Trusted ORACLE is being evaluated by the NCSC at the
>>>B1 level.

  -  I see a contraction here.
     We, DIGITAL, are claiming, that Rdb/VMS V4.1 is the and only first
     RDMS which is certificate to 100% by NIST. Including FIPS Falggering,
     SQL-Module Language and all embedded Language.
     This was in late May 1992. (After my knowledge is May later in the year  
     then March :-))
  - I have my doubts, that ORACLE does have implemented SQLMOD now.
   
    R�diger

The standard does not require that an implementation provide all of the
defined methods of entering SQL in order to be 100% compliant.  Only one
method need actually be present.  Thus, ORACLE can be 100% compliant and
not provide SQL Module Language.

Hal

Article: 101688
Newsgroups: comp.databases
Path: tkou02.enet.dec.com!jrdzzz.jrd.dec.com!pa.dec.com!decwrl!elroy.jpl.nasa.gov!ames!haven.umd.edu!darwin.sura.net!convex!news.utdallas.edu!corpgate!bnrgate!nrcnet0!cunews!cognos!nigelc
From: nigelc@%[email protected] (Nigel Campbell)
Subject: Re: Oracle V7 is here
Message-ID: <1992May7.005916.10255@%[email protected]>
Organization: Cognos Incorporated, Ottawa CANADA
References: <[email protected]>
Date: Thu, 7 May 1992 00:59:16 GMT
 
In article <[email protected]> [email protected] (Stephanie Teahan) writes:
>
>
>Now available on VAX VMS, and many other platforms by the end of the month.
>
>ORACLE RDBMS Version 7.0 
>
>ORACLE Version 7.0 represents a major milestone in the evolution
>of RDBMS technology.  Version 7.0 provides extensive and robust new
>functionality in the areas of server enforced integrity,
>distributed database, support for large numbers of users, security
>management, query optimization, database administration and
>standards compliance.
 
tongue in cheek flame on.
 
Well first of all, thanks for the long ad ;-) . So,finally Oracle gets
what InterBase, Rdb/Vms, Hp/Allbase, DG/SQL, Sybase, Ingres et al
have been able to offer to various levels for many years. InterBase
for example had triggers and 2pc since version 1.0 which was 1986.
I guess it just will make selling against you a little more challenging
than in the past :-)
 
[ mega lines deleted]
 
>
>*******************************************
>*** Not an official statement of Oracle ***
>*******************************************
 
 
But a pretty good ad non the less.
ps. Did you cross post to comp.database.ingres and informix ?
 
tongue in cheek flame off.
-- 
Nigel Campbell          Voice: (613) 738-1338 ext 3016    P.O. Box 9707
Cognos Incorporated       FAX: (613) 738-0002             3755 Riverside Dr.
uucp: cognos!nigelc       MCI: nigel campbell 307-4729    Ottawa, Ontario
inet: nigelc%[email protected]                  CANADA  K1G 3Z4

Article: 101689
Xref: tkou02.enet.dec.com comp.databases.informix:975 comp.databases:101689
Path: tkou02.enet.dec.com!jrdzzz.jrd.dec.com!pa.dec.com!decwrl!oracle!unrepliable!bounce
Newsgroups: comp.databases.informix,comp.databases
From: [email protected] (Dennis Moore)
Subject: Re: Informix support: Where are you?
Message-ID: <[email protected]>
Sender: [email protected] (Oracle News Poster)
Nntp-Posting-Host: hqsun4.us.oracle.com
Organization: not an official statement of Oracle Corporation, Redwood Shores CA
References: <[email protected]> <[email protected]> <[email protected]>
Date: Thu, 7 May 1992 02:25:41 GMT
X-Disclaimer: This message was written by an unauthenticated user
              at Oracle Corporation.  The opinions expressed are those
              of the user and not necessarily those of Oracle.
 
See below for previous discussion.  I work for Oracle.
 
This week's ComputerWorld (May 4, 1992) has a "Buyer's Scorecard" feature on
pp. 80-81, where users of various Unix and Mini databases were asked to rate
their products on a number of features (interestingly enough, availability,
price, documentation, and portability were not considered!).  The survey was
conducted by some small market research company for ComputerWorld.  The
results for support-related questions were:
 
	Responsiveness of	Quality of
	vendor service:		vendor support:
Rdb:		8.0		7.5
ORACLE:		6.8		6.9
INGRES:		6.6		6.8
SYBASE:		6.5		6.5
INFORMIX:	5.9		5.9
 
There were also some support-related comments.  Of the Oracle users who
would buy Oracle again, the reason given was "Good support/service."  The
most frequently stated dislike of Ingres is "Poor Support: 'The vendor is
not responsive when we cannot get the upgrade to work.'"  The most
frequently stated dislike of Informix users is "Poor Support: 'Technical
support from the vendor is very poor.'"
 
As far as I can tell, I didn't leave out any support-related comment from
the article.  I doubt anyone would call this survey scientific and
statistically valid (at least not the portion of it that was printed),
but it is independent and I'm sure indicative of something ;-) .
 
-- Dennis Moore, my own opinions, etcetcetc
 
In article <[email protected]> [email protected] (William C. "Spike" White) writes:
>>With all of the problems with INFORMIX being reported here,  I was wondering
>>how ORACLE and SYBASE treat their customers.
>>
[stuff deleted]
>Spike White
>e-mail: [email protected] uunet!sci34hub!tybrin4!tybse1!swhite

Article: 101691
Xref: tkou02.enet.dec.com comp.databases.informix:976 comp.databases:101691
Path: tkou02.enet.dec.com!jrdzzz.jrd.dec.com!pa.dec.com!decwrl!oracle!pyramid!infmx!neilw
From: [email protected] (Neil Williams)
Newsgroups: comp.databases.informix,comp.databases
Subject: Re: Informix support: Where are you?
Message-ID: <[email protected]>
Date: 6 May 92 20:45:19 GMT
References: <[email protected]> <[email protected]> <[email protected]>
Sender: [email protected] (Usenet News)
Organization: Informix Software, Inc.
Lines: 51
 
In article <[email protected]> [email protected] (William C. "Spike" White) writes:
>In article <[email protected]> [email protected] (3030 ) writes:
>>With all of the problems with INFORMIX being reported here,  I was wondering
>>how ORACLE and SYBASE treat their customers.
>>
>My group is exactly in the same situation (we have to give a recommendation 
>next month) and I'm following this discussion very closely.  I'm interested in 
>the customer satisfaction with INFORMIX, ORACLE, SYBASE and INTERBASE and with 
>UNIFACE, JAM, ADS, FOCUS or ORACLE as a 4-GL front-end.
 
Alright, let me do some obligatory Oracle bashing.  I worked at
Oracle in support for over a year, first in the International
Division, then later in the newly formed Worldwide Support.
 
Oracle does not notify customers when patches are available.
A problem with database corruption in conjunction with large
rollback segments in version 6.0.3x springs to mind, that
really p*ssed customers off when they called in to find that
it was a known problem and they could get a patch, but sorry, 
you have to recover from a backup first.
 
The mythical v7 has been in development for about 4 years
now.  Quite a long development cycle there....
 
Recently the VP of support told support reps to let old calls
"expire" and to concentrate on new calls.  No wonder, since
there are over 1,000 outstanding calls in the current queue.
 
Not surprisingly, Oracle support is understaffed and underpaid.
I think the last survey done there revealed that about 50% were
actively seeking other jobs, and another 30% were thinking about
leaving.
 
Interestingly, Oracle support uses Aspect, a telephone routing
system which uses Informix for data storage!
 
As far as bugs, last I heard the Oracle bug database was at
something like 70,000.  I believe Informix's is about 1/10 of
that.  I could go on, but I'll stop here.
 
Anyway, on a positive note, you can use Uniface, Jam, and Focus as
front ends to Informix servers.  Of course, INFORMIX-4GL is the 
best :-)  Uniface, JYACC, and Info Builders are marketing partners
of Informix and we work closely with them to make sure their 
products are compatible with our latest releases in a timely
fashion.
 
And yes, I'm obviously very biased since I'm an employee of 
Informix.
 
--Neil

Article: 101693
Newsgroups: comp.databases
Path: tkou02.enet.dec.com!jrdzzz.jrd.dec.com!pa.dec.com!decwrl!mips!darwin.sura.net!Sirius.dfn.de!th-ilmenau.RZ.TH-Ilmenau.DE!PrakInf.TH-Ilmenau.DE!weik
From: [email protected] (Thomas Weik)
Subject: Re: Oracle V7 is here
Message-ID: <[email protected]>
Sender: [email protected] (Newsserver)
Nntp-Posting-Host: venus.prakinf.th-ilmenau.de
Reply-To: [email protected] (Thomas Weik)
Organization: Technische Hochschule Ilmenau
References:  <[email protected]>
Date: Thu, 07 May 92 06:20:42 GMT
 
In article <[email protected]>, [email protected] (Stephanie Teahan) writes:
|> ORACLE RDBMS Version 7.0 
|> 
|> ORACLE Version 7.0 represents a major milestone in the evolution
|> of RDBMS technology.  Version 7.0 provides extensive and robust new
|> 
[some commercial stuff deleted]
|>
|> Declarative Database Enforced Integrity
|> 
|> Version 7.0 supports the full complement of ISO/ANSI SQL standard
|> declarative data integrity rules for both entity and referential
|> integrity.
 
This ISO/ANSI standard is from 1989, now we have 1992! :-)
-- 
Thomas Weik
TH Ilmenau
Germany

    Reply to .2)

	Hal,
	    I know that you can claim conformance, even you do not have,
	    for instance, implemented all bindings.
	
	    I am refering to the dates.
	    Rdb/VMS T4.1 was successfully tested by NIST last May.
	    Rdb/VMS T4.1 passed __ALL__ NIST tests by 100%.
	    We, then claimed to have the first product which passed the
	    tests.
	    ORACLE is comig along, now, almost a year later and is 
	    implicitliy pretending to be the first and the only who
	    passed the Tests. By pointing out the 100%, ORACLE
	    is insinuating that they are conformant to the complete
	    Standard, which is wrong.

	    Here is the contradiction.
	    
	    I think we, should point out in __EVERY__ situation, that
	    Rdb/VMS V4.1 is far ahead of the rest of the world, regarding
	    Standards Conformance.


    R�diger

As V4.1 isn't shipping yet, I'm not quite sure that claiming we beat
ORACLE to conformance is particularly smart.  ORACLE will no doubt shove
such a statement down our throat by claiming that V7 shipped before V4.1!

Also, does anyone know if "now available" means that the real version is
now available.  Or was this an announcement of availability for beta
testing????  Previous ORACLE statements seemed to imply that the schedule
for V7 was beta around now with full release late this year.

Hal

    Re: .5
    
    	"Also, does anyone know if 'now available' means that the real
    	version is now available.  Or was this an announcement of availability
    	for beta testing????  Previous ORACLE statements seemed to imply that
    	the schedule for V7 was beta around now with full release late this
    	year."
    
    I, too, was surprised and skeptical of the words "now available."  Last
    week in Atlanta I attended a DECUS session given by ORACLE, where they
    talked about version 7, but would not give a specific availability
    date.
    
Lew Lasher

From:	DECPA::"[email protected]" "Daniel Druker" 13-MAY-1992 23:03:57.81
To:	cookie::berenson
CC:	 
Subj:	Re: Oracle V7 is here

In article <[email protected]> you write:
>
>In article <[email protected]>, [email protected] (Stephanie Teahan) writes...
>> 
>> 
>>Now available on VAX VMS, and many other platforms by the end of the month.
>> 
>
>Could you define "Now available".  At DECUS last week (after you posted
>this) ORACLE reps were talking about V7 but refusing to give an
>availability date.
>
>.............................................................................

Hope this helps !!

ORACLE SHIPS V.7 DEVELOPERS RELEASE; V.7 DATABASE MEETS QUALITY EXPECTATIONS

  REDWOOD SHORES, Calif.--(BUSINESS WIRE) via First! -- Oracle Corporation
today announced the immediate availability and shipment of the Developers
Release for ORACLE V.7.  The product is available on Digital VAX/VMS, Sun
SunOS, HP HP-UX, Sequent DYNIX/ptx and Pyramid DC/OSx to third-party
developers and customers.

  The V.7 Developers Release offers all of the features that will be
available in the production release of ORACLE V.7, along with full
documentation and the related software development tools.  With this early
release, independent database developers can begin building V.7
applications.  Additionally, Oracle customers can migrate existing
applications to begin using the advanced functionality of V.7.

  ``Oracle is delighted to make this software available to all of our
licensed customers free of charge to give them a head start on V.7
application development,'' said Ken Jacobs, vice president of RDBMS
marketing for Oracle Corporation.  ``Oracle has set high standards for the
quality of this product.  Feedback based on V.7's reliability, functionality
and performance from our customers in the V.7 Alliance Program reinforces
that this product is ready for the next phase in its roll out.''

  ``I am impressed,'' said John Black, a system architect in the New Vector
Group, a cellular-communications subsidiary of US WEST, Inc. in Bellevue,
Wash.  ``Oracle's corporate policies concerning product quality have paid
off.  The first time that we turned the system on, we were up and running.''

  In August 1991, the initial V.7 testing began with Oracle customers
participating in the company's V.7 Alliance Program.  With this program,
companies from around the world have been working with a pre-release version
of ORACLE V.7 in a variety of industries including financial services,
aerospace, petrochemicals, manufacturing, insurance and telecommunications.

  ``Our V.7 Alliance Program members are exploiting the new features in core
business applications,'' said Jacobs.  ``One site has developed an
application for insurance claim tracking that stores business rules directly
in the DBMS -- utilizing both the V.7 stored procedures and declarative
integrity capabilities.  This is just one instance of the real world tests
our customers have been conducting.''

  Technical Support and Training

  Oracle began V.7 training and education classes for third-parties in the
first quarter of 1992.  The V.7 Developer's Release will be supported by
Oracle's Worldwide Support Organization.

  ``Support has been preparing for this phase of the roll out program for
the past six months,'' said Ian Thacker, Oracle's vice president customer
services, Worldwide Distribution.  ``This massive training and support
mobilization is imperative to our quality program.  We are all excited about
V.7 and will continue to incorporate feedback into the production product.''


% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======
% Received: by mts-gw.pa.dec.com; id AA22831; Wed, 13 May 92 22:03:50 -0700
% Received:  from wrpyr.us.oracle.com by gatekeeper.oracle.com (Oracle 1.12/37.7)id AA08787; Wed, 13 May 92 22:02:30 PDT
% Received:  by wrpyr.us.oracle.com (5.59.11/37.7)id AA22097; Wed, 13 May 92 22:03:02 PDT
% Message-Id: <[email protected]>
% Date: Wed, 13 May 92 22:03:02 PDT
% From: Daniel Druker <[email protected]>
% To: cookie::berenson
% Subject: Re: Oracle V7 is here
% Newsgroups: comp.databases
% In-Reply-To: <[email protected]>
% Organization: Oracle Corporation, Redwood Shores, CA 94065
% Cc: 

See note 1168 for a description of ORACLE's new Discrete Transactions,
the primary means by which they achieve good performance in V7.  In
particular see note 1168.11 for a description of how this feature is
merely a benchmark special, useless for real customer applications.

Hal

	Re. .8

	TPC, at its most recent meeting earlier this month, discussed this
	issue of benchmark specials. This was brought up specifically due
	to Oracle's discrete transaction implementation. 

	TPC voted for the *intent* of a proposal that will prohibit any such
	specials. Look for the TPC to bring out a concrete policy over the 
	next few months. 

	In the meantime, please ensure that this feature of Oracle gets the
	maximum publicity it deserves. 

�    <<< Note 1146.9 by TPSYS::SHAH "Amitabh Shah - Just say NO to decaf." >>>
�                     -< TPC action on benchmark specials >-

I don't know why ORACLE should be singled out for doing 'benchmark specials'.
The whole UNIX industry is reshaping it's compilers to get better SPEC figures,
including DEC. The TPC benchmark was supposed to be representative of a
'real-world' application. If Oracle can 'cheat' by designing specific
high-performance mechanisms to get good results in this supposed real-world
benchmark then either:

a. The benchmark is real-world, hence ORACLE will fly on similar applications,
   -OR-
b. The benchmark is hokey, and TPC numbers do not in any way reflect real
   performance to be expected.

So, were saying (b) is true. The answer is obvious (to us) - TPC should be made
more representative of actual applications. Maybe it needs to be an avg of a
series of applications (much like what is done with the SPEC figures). These
applications should range from DC type, to maybe CAD/engineering applications,
etc.

However, customers don't look this deep, and are understandably suspicious
when you remind them of this fact, especially when a competitor has just come
out with some great numbers.

John.

The compiler situation is somewhat different in that the mechanisms are
automatic.  The user doesn't rewrite the code to take advantage of them.

Its not that ORACLE added some limited use feature that speeds TPC, it's
that they really broke ORACLE to do it.  If you look carefully you see
that:

1) You can't really run a non-discrete transaction against any table
which has discrete transactions running against it.

2) You can't even really run discrete transactions against the same table
where any conflicts are possible.

There is an argument that TPC-A and TPC-B are obsolete, and ORACLE's
ability to create this "benchmark special" is the final nail in the
coffin.  It has been our internal position for the last couple of years
that TPC-C would replace A/B as the primary benchmark of interest.  We
believe that realistically having TPC-C accepted by customers as the
primary benchmark is still 12-18 months out.  The hardware people may be
reluctant to accept TPC-C becuase it gives them lower absolute numbers,
and they *LOVE* high numbers.

The major point from a competitive standpoint is that if a customer is
concerned that ORACLE beats Rdb (or others) on TPC-A or TPC-B then we
need to deflect that concern.  ORACLE only does that using discrete
transactions, and unless discrete transactions apply to your application
(very unlikely) ORACLE doesn't have a performance story to tell.

Of course, we have a separate question to answer.  Should we drop doing
some general purpose features and concentrate on our own benchmark
special to get better numbers than ORACLE?  You tell us.  Can you sell
against ORACLE V7's reported performance numbers?  Can you sell better
against it knowing that they only achieve such performance by using a
nearly useless benchmark special?  If the answer is yes,
then we can concentrate on useful features.  If the answer is no, then we
will divert resources to do whatever it takes to get better numbers.

Hal

	Re. .11 (Hal)

	> The hardware people may be reluctant to accept TPC-C becuase it gives 
	> them lower absolute numbers, and they *LOVE* high numbers.

	Umm, Hal, in that case the hardware people gotta love TPC-C; we 
	specifically designed TPC-C to produce higher absolute numbers than A.  
	That's why we require that the reported throughput be in 
	transactions per MINUTE, and not per SECOND! I call this the 
	"lure of large numbers" :-). 

	(Actually, in the case of TPC-C, it did not make sense to report
	tps, since it does not report all the transactions being done against
	the database as its throughput, only about 40% of them. Coupled with 
	the fact that an average TPC-C transaction is roughly 10-12 times
	larger than a TPC-A transaction, reporting tps would have implied
	that most of the reported numbers would be in single digits with 
	hardly any spread to distinguish different implementation. From the 
	business application modeled by TPC-C also, it did not make sense to 
	report tps.)

	As for Oracle7, in the next note, I post an article by Charles Levine
	of Tandem, who is their rep to the TPC. He posted the article to 
	Usenet groups of interest. Since it was posted to Usenet, it is a
	public document, and hence is freely distributable. Some of you might
	be able to at least make your customers THINK about the performance
	of Oracle7, if not outright convince them that Oracle7 will not
	perform as well in their applications. 

	-amitabh.

	

Newsgroups: comp.benchmarks,comp.databases,comp.databases.oracle,comp.databases.theory
Path: pa.dec.com!decwrl!mips!darwin.sura.net!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!pacbell.com!tandem!levine_charles@tandem.com
From: [email protected] (Charles Levine)
Subject: Oracle TPC Benchmarks and "discrete transactions"
Message-ID: <[email protected]>
Sender: [email protected]
Nntp-Posting-Host: 130.252.169.32
Organization: Tandem Computers
Date: Fri, 28 Aug 1992 16:58:09 GMT
Lines: 218

Note cross-posting.
---------------------------------------------------------------

Two months ago Oracle announced version 7 of the Oracle database
system (Oracle7).  At the same time, Oracle (and others using Oracle7)
produced TPC-A and TPC-B benchmark results to demonstrate Oracle7
performance.  The benchmark results show dramatically higher
performance than previous results run with Oracle version 6.  (For
example, with TPC-B on a VAX 6000-560, the tps rate more than doubled
from 153 tpsB to 315 tpsB.)  Some performance changes probably
resulted from internal improvements in Oracle.  In addition, though,
significant changes were made in the way the benchmark was implemented
between Oracle 6 and 7.  For example, the ACCOUNT table was changed
from b-tree to hashed-key access.  A more interesting change was the
use of a new feature in Oracle7 called "discrete transactions".

Oracle documentation explains discrete transactions as follows:

  *  Discrete transactions improve the performance of short,
     non-distributed transactions and streamline transaction processing
     so short transactions can execute more rapidly.

  *  Discrete transactions are useful for transactions that:
     * modify only a few database blocks
     * change each database block only once per transaction
     * do not modify data likely to be requested by long-running queries
     * do not need to see the old value of data before modifying the data

  *  Discrete transactions can only be used for a limited subset of
     all transactions.  However, for sophisticated users with large
     databases, where speed is the most critical factor, the performance
     improvements can make working within the design constraints
     worthwhile.

It seems that discrete transactions are very well suited to the TPC-A
and TPC-B transaction!  Discrete transactions have many limitations
which do not apply to regular Oracle transactions.  Some of these are:

1. Discrete transactions cannot see their own changes.  A discrete
transaction fails if it attempts to access the same row twice.

2. Discrete transactions cannot do "select for update".  This is a
fundamental requirement to support repeatable reads in the Oracle
model.  Consequently, discrete transactions cannot be used with
buried updates.

3. Discrete transactions incapacitate Oracle's ability to do
read-consistent queries without locking.  Oracle normally achieves
read consistency by looking at the roll back segment for the previous
version of a row in the event it has changed since the start of the
query.  One of the optimizations of discrete transactions is that no
undo information is generated.  Consequently, a query which tries to
read a row which has been modified by a discrete transaction at any
time since the query began will fail with a "snapshot too old" error.
This is a fatal error causing the transaction to be aborted.
Effectively, this breaks a key advantage and selling point of
Oracle -- the ability to mix long running queries with update
transactions.

4. Because of #2 & #3, the two primary mechanisms for achieving
read consistency in Oracle don't work with discrete transactions.
The only way to prevent inconsistent reads is to abort conflicting
transactions.

5. Discrete transactions cannot modify both tables involved in a
referential integrity constraint.  (see below in "Usage Notes" for
more explanation of this)

6. Discrete transactions cannot be distributed.

7. Discrete transactions require that the end-user understand how
records are physically arranged in the database to know that a
transaction will not change more than one record in any given database
block.  This requires a highly sophisticated understanding of the 
database internals.

8. Discrete transactions require "creativity" to do even simple
transactions:  in TPC-A, a trigger was used to retrieve the account
balance after updating it because it was not possible to use a select
statement.  (see point #1 above)

This raises many interesting questions, which I've broken out as they
may apply to the different net groups.

comp.databases & comp.databases.theory:
---------------------------------------
- Are discrete transactions a good idea?
- Is this an innovation that other database vendors should pursue?
- Given their limited nature and the user sophistication required,
  do discrete transactions make sense in the relational model?

comp.benchmarks:
----------------
- Should discrete transactions be used in benchmarks?
- Will the performance improvements achieved on TPC-A and TPC-B
  benchmarks (2x) from Oracle 6 to 7 be seen by typical Oracle users?
- If not, does this undermine the usefulness of TPC-A and TPC-B as a
  meaningful metric across hardware and software platforms?
- Are discrete transactions a database innovation or a performance
  gimmick?

comp.databases.oracle:
----------------------
- Will Oracle users use discrete transactions?
- Is the performance achieved using discrete transactions representative
  of the performance improvements typical users will see moving from
  Oracle 6 to 7?
- Do real world applications work within the restrictions of discrete
  transactions?

======================================================================
======================================================================

   Additional information from Oracle manual
   ("Application Developer's Guide"):

+  How Discrete Transactions Work
+  ------------------------------
+
+  During a discrete transaction, all changes made to any data are
+  deferred until the transaction commits.  Note that other concurrent
+  transactions are unable to see the uncommitted changes of a
+  transaction during normal transaction processing or during the
+  processing of discrete transactions.
+
+  Redo information is generated, but is stored in a separate location in
+  memory.  When the transaction issues a commit request, the redo
+  information is written to the redo log file (along with other group
+  commits) and the changes to the database block are applied directly to
+  the block.  Control is returned to the application, once the commit
+  completes.  This eliminates the need to generate undo information
+  since the block is not actually modified until the transaction is
+  committed, and the redo information is stored in the redo log buffers.
+
+  Undo information generated by regular transactions is used to
+  re-create old versions of data for queries that require a consistent
+  view of the data.  Because no undo information is generated for
+  discrete transactions, a discrete transaction that starts and
+  completes during a long query can cause the query to receive the
+  "snapshot too old" error if the query requests data changed by the
+  discrete transaction.
+
+  In order to use the BEGIN_DISCRETE_TRANSACTION procedure, the
+  DISCRETE_TRANSACTION_ENABLED initialization parameter must be set to
+  TRUE.  If this parameter is set to FALSE, all calls to
+  BEGIN_DISCRETE_TRANSACTION are ignored and transactions requesting
+  this service are handled as regular transactions.  Refer to Appendix E
+  of the ORACLE7 Server Administrator's Guide for more information about
+  setting initialization parameters.
+
+  Errors During Discrete Transactions
+  -----------------------------------
+
+  Any errors encountered during processing of a discrete transaction
+  cause the pre- defined exception DISCRETE_TRANSACTION_FAILED to be
+  raised.  These errors include the failure of a discrete transaction to
+  comply with the usage notes outlined below.  (For example, calling
+  BEGIN_DISCRETE_TRANSACTION after a transaction has begun, or
+  attempting to modify a database block more than once during a
+  transaction, raises the exception.)
+
+  Usage Notes
+  -----------
+
+  The BEGIN_DISCRETE_TRANSACTION procedure must be called before the
+  first statement in a transaction.  The call to this procedure is
+  effective only for the duration of the transaction (that is, once the
+  transaction is committed or rolled back, the next transaction is
+  processed as a normal transaction).
+
+  Transactions that use this procedure cannot participate in distributed
+  transactions.
+
+  Because discrete transactions cannot see their own changes, a discrete
+  transaction cannot perform inserts or updates on both tables involved
+  in a referential integrity constraint.  For example, assume the EMP
+  table has a foreign key constraint on the DEPTNO column that refers to
+  the DEPT table.  A discrete transaction cannot attempt to add a
+  department into the DEPT table and then add an employee belonging to
+  that department because the department is not added to the table until
+  the transaction commits and the integrity constraint requires that the
+  department exist before an insert into the EMP table can occur.  These
+  two operations must be performed in separate discrete transactions.
+
+  Since discrete transactions can change each database block only once,
+  certain combinations of data manipulation statements on the same table
+  are better suited for discrete transactions than others.  One INSERT
+  statement and one UPDATE statement used together are the least likely
+  to affect the same block.  Multiple UPDATE statements are also
+  unlikely to affect the same block depending on the size of the
+  affected tables.  Multiple INSERT statements (or INSERT statements
+  that use queries to specify values), however are likely to affect the
+  same database block.
+
+  Multiple DML operations performed on separate tables are highly
+  unlikely to affect the same database blocks, unless the tables are
+  clustered.
+
+  Because a discrete transaction cannot see its own changes nor modify
+  the same block twice, a SELECT FOR UPDATE statement and the subsequent
+  update statement is not supported for discrete transactions.  If you
+  are using the BEGIN_DISCRETE_TRANSACTION procedure and want to ensure
+  that the data does not change between the time it is read and when it
+  is updated, you must either lock the table being accessed in share
+  mode, or you must be certain that concurrent transactions do not
+  attempt to modify data read by the discrete transaction.
+
+
======================================================================
======================================================================

Charles Levine
email: [email protected]

The opinions expressed are my own and
not necessarily those of my employer.
----------------------------------------------------------------------