Re: TPC-A and -B Benchmarks

In <21dk8rINNhjm_at_emory.mathcs.emory.edu> mrichardso_at_shl.com writes:

>In a recent append, gainer_at_almaden.ibm.com
 

>>In a recent append, alexk_at_infmuc.informix.com writes...
>>>To run TPC-C benchmarks a certain isolation level is required (as far as
>>>I heard). This isolation level is not yet supported by Oracle...
>>>Any comments on this??
 

>>The TPC-C benchmark, as I was given to understand, runs 4 of its 5
>>transactions using the Repeatable Read isolation level and the fifth
>>(the stocklevel transaction) using the Cursor Stability isolation level.
 

>>Repeatable Read implies row locks are held until a commit point is
>>encountered. I don't really know what Oracle supports as regards row
>>locking. Could someone from Oracle enlighten us?
 

>I know that Oracle 7 (and 6) supports repeatable read (which means one can
>repeatably read any row encountered in a transaction, no matter how many
>tables are involved in the transaction). However repeatable read is enabled
>in one of two ways. For all user of a database RR can be enables by
>specifying a parameter in the init*.ora file. However this changes locking
>level from Oracle's exemplary row level to an absymal table level. The other
>enabling technique has the same result, table level locking, although it is
>specified on a per transaction basis. This probably explains the lack of
>published benchmark results!
 

>I believe cursor stability implies the maintenance of cursor positioning
>across commits and/or rollbacks. Note that in some cases this could violate

No, that is what is known as a HOLD CURSOR. CURSOR STABILITY means that the current row of your cursor is stable while it remains the current row - ie no-one else can update it while you are looking at it.

>ANSI standards. Oracle supports the ANSI mode and (I think) a more complete
>implementation of cursor stability. Note that I said "I believe" at the

More complete than what? The only way I can think of to implement CURSOR STABILITY under Oracle (6 or 7) is to SELECT ... FOR UPDATE, but this is overkill, as it does not release the lock until the commit, whereas CURSOR STABILITY allows it to be released on the next FETCH.

>start of this paragraph and the relevant information is book knowledge, not
>practical experience.
 

>Regards, Marv
>mrichardso_at_shl.com

graeme

--
Disclaimer:	The author's opinions are his own, and not necessarily
		those of Pyramid Technology Ltd. or Pyramid Technology Inc.
---------------------------------------------------------------------------
      -m------- Graeme Sargent                 Voice: +44 (0)252 373035
    ---mmm----- Senior Database Consultant     Fax  : +44 (0)252 373135
  -----mmmmm--- Pyramid Technology Ltd.        Telex: Tell who???
-------mmmmmmm- Farnborough, Hants  GU14 7PL   Email: graeme_at_pyra.co.uk
---------------------------------------------------------------------------
    We have the technology.  The tricky bit is learning how to use it.