Azure 数据传输身份列种子跃升 10,000答案

【问题标题】：Azure data transfer Identity Column Seed Jumped by 10,000Azure 数据传输身份列种子跃升 10,000
【发布时间】：2013-09-10 02:49:47
【问题描述】：

通过sql脚本插入数据后有

SET IDENTITY_INSERT [dbo].[table] ON
...
SET IDENTITY_INSERT [dbo].[table] OFF

身份种子增加了10,000

我尝试过运行 reseed

dbcc CHECKIDENT ('vendors', 'reseed', 57439)

但我收到错误消息，指出此版本的 SQL Server 不支持 DBCC 命令“CHECKIDENT”。

以后如何制止这个问题？

【问题讨论】：

这个问题在这里得到解答：social.msdn.microsoft.com/Forums/windowsazure/en-US/…
弗兰克，在您提供的链接中并没有真正看到任何解决方案。讨论确实提到了在 Azure 上不起作用的相同问题和相同解决方案。我在导入数据时执行了 SET IDENTITY_INSERT OFF 和 ON，并且我确实选择了 SQL Azure 作为要在高级选项中生成的 sql 类型。仍在寻找解决方案来解决它并在将来避免。
SQL SERVER 2012 存在问题。这是为了提高性能而设计的。我不关心其他所有人，但每隔几天让记录跃升 1000 是非常不方便的。 connect.microsoft.com/SQLServer/feedback/details/739013/…
每次 SQL 服务重新启动时都会发生这种情况。如果 Azure 允许序列，它可以修复，但由于它不允许，我猜唯一的解决方法是使用当前数字创建一个表（为每个身份），以及一个插入读取该数字的元素的过程，增量和然后插入表中...

标签： sql azure sql-server-2012

【解决方案1】：

我在网上找到了this post。

行为（重新设置）是设计使然，但已被确认内部不是最佳的，并且已提出请求（再次，内部）来改变行为。这可能会发生，也可能不会发生。

reseed 由实例反弹触发，这些反弹由服务水平协议。它们主要是操作系统或 SQL Azure 本身的补丁。

最重要的一点是，很可能，我们永远不会击中整数限制。我想我们都忘记了（至少我忘记了） SQLAzure 与 SQL Server 不同；有非常实际的限制，特别是总数据库大小（150 gigs）。他还说有一个最大行每张表有 1000 万条记录的限制，但我没有找到在网络上的文档。假设这是正确的，即使 1000k 的跳跃，我们仍然是安全的。是的，你也可以切换如果您在总 db 大小限制之前达到 int 限制，则为 bigint。他的意思很简单，就是在我们到达终点之前，我们会用完空间。整数限制。

SQL Azure 的限制可能会改变，但我想关键是如果 SQL 实例崩溃，您可能会遇到很大的差距。

【讨论】：