Wednesday, November 5, 2003, 9:14:34 AM, Hemant K Chitale ([EMAIL PROTECTED]) wrote:
HKC There are times when you cannot afford to lose CACHed values, as John
HKC Kanagaraj has pointed out
HKC in Oracle Applications when generating Cheque numbers. Such sequences
HKC required a patch in
HKC
Jonathan Gennick scribbled on the wall in glitter crayon:
Would NOCACHE really prevent loss of sequence values? It
seems to me that you could still find yourself in a
situation where you grab NEXTVAL from a sequence, causing it
to increment, and then you rollback your transaction. The
.
Regards
Daid Lord
-Original Message-
From: Thater, William [mailto:[EMAIL PROTECTED]
Sent: 06 November 2003 14:49
To: Multiple recipients of list ORACLE-L
Subject: RE: Re[2]: ORDER -- was Re[2]: Sequences in OPS/RAC
Jonathan Gennick scribbled on the wall in glitter crayon
ORDER isn't strictly necessary when all you want are unique numbers.
There are times when you cannot afford to lose CACHed values, as John
Kanagaraj has pointed out
in Oracle Applications when generating Cheque numbers. Such sequences
required a patch in
Oracle Apps 10.7 and 11 and/or creation
Jonathan,
Here's the text of the article [I can't find it on the WebSite, it
is in the regular Oracle emails that I
receive from Builder.Com]
Understand SYS_GUID and sequences as primary
keys
Oracle8i introduced the concept of SYS_GUID, which had several advantages
over a conventional sequence
I have always been comfortable with the idea that Sequences continue to
guarantee
uniqueness even in OPS / RAC environments.
However, a recent Builder.Com article by Scott Stephens on the SYS_GUID
function has these lines :
Sequence generator numbers are guaranteed to be unique only for a
Hemant,
I would guess that this is true if you are caching values for the sequence.
Each database instance might cache the same set of values.
Turn sequence caching off, and I would think that the problem goes away.
Havn't tried this in awhile, but it makes sense.
Tom Mercadante
Oracle
me don't think so.
Raj
Rajendra dot Jamadagni at nospamespn dot com
All Views expressed in this email are strictly personal.
QOTD: Any clod can have facts, having an opinion is an art !
-Original Message-
In the Oracle9i Real Application Clusters Administration manual, there is a chapter
about sequence numbers generator. Before believing to the snake oil sellers, read
the fine manual. Sequence numbers are guaranteed to be unique PER DATABASE. What
they're
not guaranteed is to come in ordered
Sequences are mastered by the single SYS.SEQ$ table in each
database. Cached or uncached, RAC or non-RAC, OPS or
non-OPS, sequence numbers generated by this mechanism are
unique across a database, not by instance. Each instance
updates SEQ$ as individual numbers (noncached) or ranges of
numbers
Yes, I've been aware of the difference between ORDERED and CACHED.
However, the Builder.Com article quite explicity asserts
Sequence generator numbers are guaranteed to be unique only for a single
instance, which is unsuitable for use as a primary key in parallel or
remote environments, where a
Hello Hemant,
Monday, November 3, 2003, 11:29:26 AM, you wrote:
HKC However, the Builder.Com article quite explicity asserts
HKC Sequence generator numbers are guaranteed to be unique only for a single
HKC instance, which is unsuitable for use as a primary key in parallel or
HKC remote
On 11/03/2003 12:04:26 PM, Jonathan Gennick wrote:
Can you point us to the article? My guess is that the author
is not familiar with Oracle,
That shouldn't be considered enough of a reason not to write articles
about oracle, should it?
Mladen Gogala
Oracle DBA
Note:
This message is
Hi,
I have RAC and I always use ORDER when I create SEQUENCE. The following information
is from Oracle Manual:
ORDER is necessary only to guarantee ordered generation if you are using Oracle with
Real Application Clusters. If you are using exclusive mode, sequence numbers are
always
The problem is that the ORDER clause comes at the expense of
CACHE. You can use SQL tracing to verify that each use of
the sequence causes an update of SYS.SEQ$ when ORDER is set,
effectively rendering the CACHE setting a no-op. So,
especially in an OPS/RAC environment, the use of ORDERED
, 2003 10:29 AM
To: Multiple recipients of list ORACLE-L
Subject: RE: Re[2]: Sequences in OPS/RAC
The problem is that the ORDER clause comes at the expense of
CACHE. You can use SQL tracing to verify that each use of
the sequence causes an update of SYS.SEQ$ when ORDER is set,
effectively rendering
16 matches
Mail list logo
