我刚刚继承了一个相对较小的SQL Server数据库。我们有一个分散的系统，在大约十个站点上运行，每个站点全天由六十到一百个客户端进行攻击。在检查系统时，我发现了一些事情：没有定义维护计划或密钥。
我有许多已经访问数据库的不同应用程序。其中大部分都是用C语言编写的内联SQL。我所做的部分工作是编写所有内容的存储过程，让我们的应用程序转向它。然而，在我这样做之前，我真的认为我应该关注这些看似明显的问题。
另外，我们最终会考虑复制到中心网站，所以我真的认为这些事情应该在我们想到之前解决。
确定重新设计方案和维护计划将耗时但不成问题 - 我之前在单个站点完成了这项工作。但是，我如何在十个（或更多）生产站点上实现对数据库的这些重大更改，同时确保数据完整性并且不破坏应用程序？
答案 0 :(得分：4)
我怀疑没有正式定义的密钥，这个数据库可能存在大量的数据完整性问题。幸运的你。
对于复制，您将需要GUID。我会这样做，在开发环境中添加GUID和PK定义并测试测试。你可能会发现人们选择*的很多废话，并且添加列会导致问题或导致事情出现在你不想要的报告上。找到并解决所有这些问题。确保编写对数据的所有更改的脚本，并将它们放在源代码管理中，以及需要对应用程序进行的任何代码更改。然后在最低使用时间内安排维护数据库的停机时间。让用户知道应用程序将提前关闭。在停机期间，让应用程序显示关闭消息，将数据库更改为单用户模式，因此除了进行此更改的团队之外没有人可以影响数据库，进行完全备份，运行脚本以对数据库进行更改，运行用于更改应用程序，测试，使数据库退出单用户模式并重新打开应用程序的代码。
在任何情况下，如果不进入单用户模式，我都会尝试更改此专业。
答案 1 :(得分：2)
首先确保您拥有每个数据库的有效备份，然后对其进行测试还原以确保它们恢复正常。
如果您需要为所有网站部署相同，一致的脚本解决方案，请考虑使用Ola Hallengren的维护与维护计划（Ola Hallengren's site）
然后我会说看一下基本的索引，首先从重击手表开始。您可以使用各种方法识别它们 - 假设您知道如何，但只是抛出一些想法：代码审查，SQL跟踪，查询计划分析，然后有第三方工具，例如，Idera SQLdm，Confio Ignite，Quest's Spotlight on SQL Server的SQL Server或Foglight性能分析。
我认为这会让你滚动。
答案 2 :(得分：1)
其他一些想法。
我要检查的第一件事是：就数据库对象而言，所有数据库实例都是一样的吗？它们是否都具有完全相同的表，列（以及它们在表中的顺序），可空性等。确保检查sys.objects中列出的几乎所有内容。一旦您知道数据库结构全部同步，那么您就知道您生成的任何数据库修改脚本都适用于所有实例。
使用计划的更改修改测试环境后，必须确保它们不会破坏现有功能。您是否可以在测试环境中准确模拟“......整天被60到100个客户端捣乱”？如果你做不到，那么你当然不知道你的改变是否会在他们上线之前破坏任何东西。 （我要避免的假设：仅仅因为给定的实例在您希望构建主键的列中没有没有重复项并不意味着从不任何重复项本...）