Oracle Sequence nextval是来回跳转的数字

时间:2022-03-23 07:43:50

I created a new table and a new sequence, I have two C# web services trying to insert records into this table using same query utilizing mySequence.nextval (and yes I checked it many times, they both use mySequence.nextval).

我创建了一个新表和一个新序列,我有两个C#Web服务尝试使用mySequence.nextval使用相同的查询将记录插入此表(是的,我检查了很多次,它们都使用mySequence.nextval)。

The two web services are inserting rows to the table, but the mySequence.nextval is returning numbers out of sequence

两个Web服务正在向表中插入行,但mySequence.nextval不按顺序返回数字

Here is how the records were created, showing PrimaryKey which gets its value from mySequence.nextval

以下是创建记录的方式,显示了从mySequence.nextval获取其值的PrimaryKey

1 21 22 23 2 3 24 25 4 27 28 5

1 21 22 23 2 3 24 25 4 27 28 5

So far no duplicates but why is mySequence.nextval jumping back and forth? and should I worry about it

到目前为止没有重复,但为什么mySequence.nextval来回跳跃?我应该担心吗

Update: The sequence is created with cache_size = 20

更新:使用cache_size = 20创建序列

2 个解决方案

#1


12  

I will wager that your database is running RAC (Real Application Clusters). Assuming that is the case and that you create the sequence with all the default settings, that's the expected behavior.

我会打赌您的数据库正在运行RAC(Real Application Clusters)。假设是这种情况,并且您使用所有默认设置创建序列,那就是预期的行为。

The default setting is to cache 20 values. Each node in the RAC cluster, by default, will have a separate cache. Assuming that you have a cluster with two nodes A and B, the first time a nextval is requested on A, A will cache values 1-20 and return a value of 1. If the next request for a nextval is made on B, B will cache values 21-40 and return a value of 21. From there, the value you get will depend on the node that your connection happens to be running on.

默认设置是缓存20个值。默认情况下,RAC群集中的每个节点都有一个单独的缓存。假设您有一个具有两个节点A和B的集群,第一次在A上请求nextval,A将缓存值1-20并返回值1.如果下一个请求是在B,B上进行的将缓存值21-40并返回值21.从那里,您获得的值将取决于您的连接正在运行的节点。

Generally, this shouldn't be a problem. Sequences generate unique numbers. The numbers generally need not be consecutive. If you really need values to be returned sequentially because you are doing something like ordering by the sequence-generated value to determine the "first" or "last" row, you can use the ORDER clause when you create the sequence to force values to be returned in order. That has a negative performance implication in a RAC database, however, because it increases the amount of communication that needs to go on between the nodes to synchronize the values being returned. If you need to determine the "first" or "last" row, it's generally better to add a date or a timestamp column to the table and order by that rather than assuming that the primary key is generated sequentially.

一般来说,这应该不是问题。序列生成唯一的数字。数字通常不需要是连续的。如果您确实需要按顺序返回值,因为您正在通过序列生成的值进行排序来确定“第一行”或“最后”行,则可以在创建序列时使用ORDER子句强制值为按顺序返回。但是,这在RAC数据库中具有负面的性能影响,因为它增加了节点之间需要进行的通信量,以同步返回的值。如果您需要确定“第一行”或“最后一行”,通常最好向表中添加日期或时间戳列并按顺序排序,而不是假设主键是按顺序生成的。

#2


1  

From the docs...

来自文档......

Sequence numbers are generated independently of tables, so the same sequence can be used for one or for multiple tables. It is possible that individual sequence numbers will appear to be skipped, because they were generated and used in a transaction that ultimately rolled back. Additionally, a single user may not realize that other users are drawing from the same sequence.

序列号是独立于表生成的,因此相同的序列可用于一个或多个表。单个序列号可能会被跳过,因为它们是在最终回滚的事务中生成和使用的。另外,单个用户可能没有意识到其他用户正在从相同的序列中绘制。

http://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_6015.htm#SQLRF01314

http://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_6015.htm#SQLRF01314

#1


12  

I will wager that your database is running RAC (Real Application Clusters). Assuming that is the case and that you create the sequence with all the default settings, that's the expected behavior.

我会打赌您的数据库正在运行RAC(Real Application Clusters)。假设是这种情况,并且您使用所有默认设置创建序列,那就是预期的行为。

The default setting is to cache 20 values. Each node in the RAC cluster, by default, will have a separate cache. Assuming that you have a cluster with two nodes A and B, the first time a nextval is requested on A, A will cache values 1-20 and return a value of 1. If the next request for a nextval is made on B, B will cache values 21-40 and return a value of 21. From there, the value you get will depend on the node that your connection happens to be running on.

默认设置是缓存20个值。默认情况下,RAC群集中的每个节点都有一个单独的缓存。假设您有一个具有两个节点A和B的集群,第一次在A上请求nextval,A将缓存值1-20并返回值1.如果下一个请求是在B,B上进行的将缓存值21-40并返回值21.从那里,您获得的值将取决于您的连接正在运行的节点。

Generally, this shouldn't be a problem. Sequences generate unique numbers. The numbers generally need not be consecutive. If you really need values to be returned sequentially because you are doing something like ordering by the sequence-generated value to determine the "first" or "last" row, you can use the ORDER clause when you create the sequence to force values to be returned in order. That has a negative performance implication in a RAC database, however, because it increases the amount of communication that needs to go on between the nodes to synchronize the values being returned. If you need to determine the "first" or "last" row, it's generally better to add a date or a timestamp column to the table and order by that rather than assuming that the primary key is generated sequentially.

一般来说,这应该不是问题。序列生成唯一的数字。数字通常不需要是连续的。如果您确实需要按顺序返回值,因为您正在通过序列生成的值进行排序来确定“第一行”或“最后”行,则可以在创建序列时使用ORDER子句强制值为按顺序返回。但是,这在RAC数据库中具有负面的性能影响,因为它增加了节点之间需要进行的通信量,以同步返回的值。如果您需要确定“第一行”或“最后一行”,通常最好向表中添加日期或时间戳列并按顺序排序,而不是假设主键是按顺序生成的。

#2


1  

From the docs...

来自文档......

Sequence numbers are generated independently of tables, so the same sequence can be used for one or for multiple tables. It is possible that individual sequence numbers will appear to be skipped, because they were generated and used in a transaction that ultimately rolled back. Additionally, a single user may not realize that other users are drawing from the same sequence.

序列号是独立于表生成的,因此相同的序列可用于一个或多个表。单个序列号可能会被跳过,因为它们是在最终回滚的事务中生成和使用的。另外,单个用户可能没有意识到其他用户正在从相同的序列中绘制。

http://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_6015.htm#SQLRF01314

http://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_6015.htm#SQLRF01314