【问题标题】:Why is my database throwing Primary Key violations after migrating to Azure?为什么我的数据库在迁移到 Azure 后会引发主键违规?
【发布时间】:2022-09-29 10:34:11
【问题描述】:

背景:我有一个带有 SQL 和 IIS 的旧 Windows VPS 以及多年来一直为这个 Web 应用程序服务的东西。在此过程中,我偶尔会升级 SQL 和 Windows。

昨晚我将数据库迁移到 SQL Azure Elastic 实例。为了最大限度地减少停机时间,我关闭了所有在用户表之外更改数据的进程,并使用数据迁移助手进行了大约 8 小时的模式和数据移动。几个小时后,我关闭了网站,使用 Visual Studio 的数据工具进行数据比较并赶上天记录(关闭自动流程,任何一张表中的数字都不大)。

不幸的是,我在迁移 Web 应用程序时遇到了一些麻烦,所以最后我只是将现有的 Web 服务器指向 Azure 数据库,并使本地数据库脱机,以确保我不会意外走错路。

因此,Azure 上的数据库在架构和数据方面与我的本地副本相同 - 兼容级别是云中更高的一个版本。

我已将 VPS 的最终备份恢复到 dev 中,它可以完美地工作,正如您所期望的那样。

现在我有一些明显随机的功能不起作用,并抛出违反主键约束异常。让我非常清楚 - 所有涉及的主键都是 IDENTITY(1,1) 列,我从来没有在这些表中发明唯一标识符。

我已经四次检查了我的 Linq2Sql 上下文,它们被正确设置为 AutoGenerated 和 OnInsert,而不是创建自己的。

该代码在本地 SQL 上运行良好,只是 Azure 实例很痛苦。奇怪的是,我已经测试过,发现如果我重新进行迁移,我会在不同的表上得到相同的错误,但它似乎并不一致。

我试过 DBCC CHECKDB。我也有 DBCC CHECKIDENT(\'mytable\', RESEED, 10000) (10,000 比我现有的最大 ID 大一个整数)

有谁知道导致这种情况的 Azure DB 是什么,或者我如何能够更深入地挖掘?

    标签: sql azure linq-to-sql


    【解决方案1】:
    DBCC CHECKIDENT('mytable', RESEED)
    

    在没有指定新 ID 的情况下进行重新播种似乎已经在我看到它发生的表上清除了它。我仍然想了解这是什么原因,所以我可以防止它(或者也许我应该只是 FOREACH TABLE 运行重新种子?)

    因为我不知道原因,所以我不知道如何识别受影响的表而不在生产中绊倒它们:(

    【讨论】:

      猜你喜欢
      • 2019-12-24
      • 1970-01-01
      • 2019-01-27
      • 2020-05-20
      • 2014-12-27
      • 1970-01-01
      • 1970-01-01
      • 2021-08-03
      • 2017-01-11
      相关资源
      最近更新 更多