将主键添加到生产数据库答案

【问题标题】：Adding primary keys to a production database将主键添加到生产数据库
【发布时间】：2011-03-24 15:26:58
【问题描述】：

我只是继承了一个相对较小的 SQL Server 数据库。我们有一个分散的系统在大约 10 个站点上运行，每个站点整天都被 60 到 100 个客户捣毁。在检查系统时，我突然想到了几件事：没有定义维护计划或密钥。

我有几十个不同的应用程序已经在访问数据库。它们中的大多数是用 C 语言编写的，带有内联 SQL。我被带进来做的部分工作是为所有内容编写存储过程，并让我们的应用程序移动到那里。然而，在我这样做之前，我真的认为我应该专注于这些看似明显的问题。

此外，我们最终会考虑复制到一个中心站点，所以我真的认为这些事情应该在我们考虑之前就解决。

制定重新设计方案和维护计划会很耗时，但不会有问题 - 我以前在单个站点上做过。但是，我将如何在十个（或更多）生产站点中对数据库实施这些重大更改，同时确保数据完整性并且不破坏应用程序？

【问题讨论】：

与答案相关：如果没有定义键，复制是如何完成的？（就此而言，如果没有密钥，您如何更新任何记录？）
此时没有复制。此外，还有逻辑键——例如客户编号。但是，数据库中没有定义主键，所以更新只是使用这些类型的值对数据库运行。
当您说逻辑时，您的意思是唯一键？您是否也有这些表上的聚集索引？
我的意思是，虽然记录在应用程序层中是唯一的（例如，随着客户 ID 的增加），但数据库中没有定义任何东西来强制完整性 - 没有主键，没有唯一约束等. 因此，虽然我知道由于应用程序层发生的事情，记录通常是唯一的，但我在数据库级别没有强制执行。

标签： sql-server database-design database-schema production-environment

【解决方案1】：

我怀疑如果没有正式定义密钥，该数据库可能存在大量数据完整性问题。祝你好运。

对于复制，您将需要 GUID。我会这样做，在开发环境中添加 GUID 和 PK 定义并测试测试测试。您可能会在人们选择 * 的地方发现很多废话，并且添加列会导致问题或导致您不想要的报告中出现问题。查找并修复所有这些问题。请务必编写对数据的所有更改的脚本，并将它们与您需要对应用程序进行的任何代码更改一起放入源代码管理中。然后在最低使用时间安排停机时间以维护数据库。让用户知道应用程序将提前关闭。在停机期间，让应用程序显示停机消息，将数据库更改为单用户模式，这样除了进行此更改的团队之外没有人可以影响数据库，进行完整备份，运行脚本以对数据库进行更改，运行更改应用程序、测试、将数据库退出单用户模式并重新打开应用程序的代码。

在任何情况下，我都不会在不进入单用户模式的情况下尝试更改这个专业。

【讨论】：

为了帮助缓解SELECT * 或字段编号更改的一些应用程序问题，他可以使用旧表的名称创建一个视图，重命名源表，并且仅将原始字段包含在视图。

【解决方案2】：

首先确保您拥有每个数据库的有效备份，并测试恢复它们以确保它们恢复正常。

如果您需要为所有站点部署相同、一致、脚本化的解决方案，请考虑使用 Ola Hallengren 的维护与维护计划 (Ola Hallengren's site)

然后我会说看看建立一些基本的索引，首先从重击表开始。您可以使用各种方法识别它们 - 假设您知道如何，但只是抛出一些想法：代码审查、SQL 跟踪、查询计划分析，然后还有 3rd 方工具，例如 Idera SQLdm、Confio Ignite、Quest 的 Spotlight on SQL Server 或 SQL Server 的 Foglight 性能分析。

我认为这会让你滚动。

【讨论】：

【解决方案3】：

一些额外的想法。

我要检查的第一件事是：就数据库objects 而言，所有数据库实例都相似吗？它们是否都具有完全相同的表、列（以及它们在表中的顺序）、可空性等。请务必检查 sys.objects 中列出的几乎所有内容。一旦您知道数据库结构都是同步的，那么您就知道您生成的任何数据库修改脚本都将适用于所有实例。

使用计划更改修改测试环境后，您必须确保它们不会破坏现有功能。您能否在您的测试环境中准确地模拟“......整天被 60 到 100 个客户敲打”？如果您不能，那么您当然无法知道您的更改是否会破坏任何内容，直到它们生效。（我要避免的假设：仅仅因为给定实例在您希望在其上构建主键的列中没有重复项并不意味着从不任何重复项现在...）

【讨论】：