ALTER SEQUENCE on a busy server results in unexpected very high values

Question

Our sequence was at 782,393,232 or so, when I bumped it up by 30,000. Here's the commands I used:
alter sequence OUR_SEQ increment by 30000;
select OUR_SEQ.nextval from dual;
alter sequence OUR_SEQ increment by 1;
commit;
When I queried the sequence's nextval a few minutes later, it had jumped to over 8 billion !?! I quickly reset down to 783 million or so, and it behaved propertly after that. I've seen a couple of posts on the net that infer that resetting a sequence while it is being heavily used can cause "unpredictable results". Has anyone else experienced this or is there a known bug ?
I'm running :
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit, RAC system.
PL/SQL Release 10.2.0.4.0 - Production
"CORE     10.2.0.4.0     Production"
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production

Answer 1

Justin Cave wrote:
Sven,
I'm not sure that I understand what you're clarifying...
In a RAC cluster, a sequence with a cache has a separate cache in each node of the cluster. If the cache was set to 20 (the default), and the increment was set to 30,000, each node would cache 20 values each separated by 30,000. And the caches would be non-overlapping (i.e. node A would get the 20 values from 1 - 570,001, node B would get the 20 values from 600,001 - 1,170,001). I don't see that this is at odds with what I posted.
Obviously, the presence of a cache creates a bit of a wrinkle with when, exactly, you say that a sequence is incremented. The NEXT_VALUE in DBA_SEQUENCES is incremented by cache*interval when any node exhausts its cache. The NEXTVAL of a sequence for connections that are hitting a particular node will increase by interval each time some other session gets the NEXTVAL of a sequence. The NEXTVAL of a sequence for connections on a different node is unaffected by what is happening on the current node. Is that the clarification you're making? If so, I agree.
user11300030,
The discussion on sequence caching may provide some insight into why none of the rows are between 780 million and 1 billion. It's entirely possible that those values were cached on a node other than the node where the inserts were run. Had the caches not been flushed when you altered the sequence, inserts run on those other nodes might have used the values from that range.
JustinWe do have two nodes and the sequence cache size was 100, so what you suggested in your last paragraph makes sense.
Also, I just ran an AWR report and noted that "select our_seq.nextval from dual" was called 280K times (Hibernate is a hungry beast).