安全修复生产数据库数据

会发生错误，有时必须在生产中修复数据。从大公司的角度来看，最安全的方法是什么？有没有可以帮助的工具？以下是推动此要求的一些注意事项...

1. 我们需要记录谁运行了查询以及他们运行了什么
2. 理想情况下，我们需要授予该人员访问权限，使其只能在短时间内针对感兴趣的表运行查询
3. 无论正在运行什么查询，都需要对此有一些技巧，以防止长时间运行和锁定SQL未经明确许可而运行
4. 此过程需要与DB无关，或者至少了解DB2，Oracle和SQL Server。

我们正在努力减少因执行“错误的事情”而进行临时产品修正查询的风险，同时在此过程中增加一些安全性/听觉性。有想法还是想法？

永远不要手动更新生产数据库。

编写脚本。

仔细检查一下，让多个人这样做，而不仅仅是一个人做三遍。

在这些脚本中包括变更后验证查询。

只要情况允许，在更改后验证运行后，测试事务中的整个更改，该事务最终会回滚。对结果确信后，将回滚更改为提交。

针对测试数据库测试这些脚本。

在生产数据库上运行脚本之前，请先进行备份。

运行脚本。

使用更改后验证脚本检查，验证并三重检查更改的数据。

无论如何都要进行目视检查。

如果一切正常，请退出并还原备份。

在绝对确定一切正常并且您已从相关的（业务）经理处签字之前，请勿将更改后的数据作为生产数据进行处理。

Marjan Venema的回答在技术上是有效的，应尽可能遵循。jan，Marjan是从理论家或纯粹的数据库管理员的角度回答的，他喜欢简单地做事。实际上，有时由于业务限制，不可能以干净的方式做事。

想象以下情况：

1. 该软件产品中存在一个错误，当它检测到认为数据库中的数据不一致时，便导致其停止工作，

2. 所有可能修复应用程序错误的开发人员都无法访问，

3. 该公司目前每小时损失数千美元（比如说6000美元，这意味着每分钟100美元），

4. 该错误会影响多个表，其中一个表非常大，并且仅涉及数据本身，而不涉及架构，

5. 为了规避错误，您应该对数据进行一些试验，包括删除和更改数据，

6. 数据库很大，需要花费三个小时来进行或还原备份，

7. 上次完整备份是在三周前完成的。还有每日增量备份，最后一次每日增量备份是在14个小时前完成的，

8. 假定数据库备份可靠；他们经过了严格的测试，包括最近

9. 丢失14小时的数据是不可接受的，但是丢失一到两个小时的数据是可以接受的，

10. 暂存环境最后在六个月前使用。看来它不是最新的，可能要花几个小时才能完成设置，

11. 该数据库是Microsoft SQL Server 2008 Enterprise。

做事的干净方法是：

1. 在登台环境中还原备份，

2. 在那做实验

3. 两次检查最终脚本，

4. 在生产服务器上运行脚本。

仅第一步将为您的公司花费$ 18 000。如果您完美地执行第三步，则风险会很低，但是由于您承受的压力很大，因此风险会更高。您可能会得到一个脚本，该脚本在登台时效果很好，然后破坏了生产数据库。

相反，您可以这样做：

1. 创建快照（Microsoft SQL Server支持该快照，还原（无需创建任何内容）数据库快照需要花费几秒钟，而备份需要一个小时；我想其他数据库产品也支持快照），

2. 直接在生产数据库上进行实验，如果出现问题，将还原为快照。

尽管纯粹主义者会以一种干净的方式修复数据库，并且在浪费时间花费超过2万美元的公司的情况下，仍然存在着浪费时间的风险，但是考虑到业务约束的数据库管理员将以某种方式修复数据库。这样可以在快速进行操作的同时最大程度地降低风险（由于快照）。

结论

我自己是一个纯粹主义者，我讨厌以一种不干净的方式做事。作为开发人员，我重构所修改的代码，评论无法重构的困难部分，对代码库进行单元测试，并进行代码审查。但是，我还考虑了以下情况：要么干净利落地做事，第二天被解雇，要么通过进行有效的快速黑客攻击，将风险和财务影响最小化。

如果某些IT员工只是为了干净起见而想要干净地做事，而这却给公司造成数千美元的损失，那么这个IT员工对他的工作会有深刻的误解。

安全修复生产数据库数据。从大公司的角度来看，最安全的方法是什么？有没有可以帮助的工具？

这是一个不好的做法，并且会引起更多数据问题。甚至有一个短语将这种方法描述为“ 快速与肮脏 ”。

直接在生产服务器上继续进行修复/更新是非常危险的，因为这将使您/您的公司损失一笔巨款（诉讼，不良/肮脏的数据，丢失的业务等）。

但是，错误将在那里并且需要修复。在事实上的工业标准，是在应用补丁/（部署脚本）分段（预生产环境与督促数据库的最新副本），并让数据分析师/ QA验证修复。相同的脚本应进行版本控制，并应用于Prod环境，以避免出现问题。

此相关文章“ 登台数据库良好做法”中提到了许多良好做法。

值得一看的参考集如下：

• 您可以多快的时间将固定的错误投入生产？
• 软件开发成本金字塔
• 应该为测试和错误修复分配多少时间

在大多数组织中，我一直致力于在实时环境中更新数据，通常是由一小部分具有访问权限的人员完成的，通常具有DBA之类的职位。由于更新只能由少数几个人完成，因此至少有机会使他们熟悉数据，从而减少（但不能消除）出现问题的风险。

编写更新脚本的人会在测试中这样做（根据其他答案），并且会从非技术人员（了解系统的人员以及具有高级权限的人员）那里得到认真的批准，认为该功能似乎在“正确”了。除了自己的偏执测试。脚本和数据将在投入生产之前由另一位技术人员（通常是我提到的DBA角色）在测试中进行独立验证。将根据预期值检查结果（每种情况下都是唯一的，但通常是行数等）

在我工作过的一家公司中，进行备份不是一个现实的选择，但是所有要更新的行在更新之前都会写到文本文件中以供参考，然后在更新后再次有人需要引用它时使用。脚本和此数据保存在正确组织的数据更改日志中。

每个业务都是唯一的，并且更新某些数据的风险显然比其他业务更大。

通过具有使人们不得不跳过去来进行这些更新的过程，希望您可以促进一种使人们希望将其视为最后手段的文化，并围绕这种东西建立健康的“三重检查，三重检查”的态度。

有时您必须修复Prod上其他服务器上不存在的数据。这不仅是由于错误，还可能是由于客户端发送的文件中的数据导入不正确，或者是由于有人入侵您的系统而导致的问题。还是由于错误的数据输入引起的问题。如果数据库很大或时间紧迫，则您可能没有时间还原最新的备份并修复dev。

您的第一道防线（这是任何企业数据库都无法缺少的！）是审计表。您可以使用它们来备份错误的数据更改。此外，您可以编写脚本以将数据返回到之前的状态，并在需要还原审核的数据之前很长时间在其他服务器上对其进行测试。这样唯一的风险就是您确定了要还原的正确记录。

接下来，所有用于更改生产数据的脚本应包括以下内容：

它们应处于显式事务中并具有TRY Catch块。

他们应该具有测试模式，可以在看到更改后将其回滚。在进行更改之前，您应该有一个选择陈述，在更改之后应该有一个陈述，以确保更改正确。该脚本应确保显示已处理的行数。我们在模板中预先设置了一些内容，以确保完成所有工作。更改模板也有助于节省编写修补程序的时间。

如果要更改或更新大量数据，请考虑编写脚本以批量运行，并为每个批次提交。修复一百万条记录时，您不想锁定整个系统。如果要修复的数据量很大，请确保dba或用于性能调整的人员在运行之前检查脚本，并在可能的情况下在非工作时间运行。

接下来，对所有在生产中进行任何更改的脚本进行代码审查，并置于源代码控制中。所有这些-无一例外。

最后，开发人员不应运行这些脚本。它们应由dbas或配置管理组运行。如果您都没有，那么只有技术领先或更高水平的人才有权在产品上运行产品。生产产品的人越少，发现问题就越容易。编写脚本时，应使其简单运行，不突出显示部分并一次运行一个步骤。当人们忘记突出显示where子句时，突出显示的内容经常使他们感到麻烦。

我在运行生产数据库中多次更新数据。我同意上面的回答，这绝不是标准的操作程序。

这也将是昂贵的（我们会互相注视并讨论2或3个问题）

黄金法则：在执行更新/删除/插入语句之前，请始终执行选择语句以显示将要执行的操作

团队中其他两个人正在执行的黄金法则！

回复：MainMa的回答...

该软件产品中存在一个错误，当它检测到认为数据库中的数据不一致时，便导致其停止工作，

• 您怎么知道这是“虫子”？根据软件产品开发人员制定的规则，数据不一致。

所有可能修复应用程序错误的开发人员都无法访问，

该公司目前每小时损失数千美元（比如说6000美元，这意味着每分钟100美元），

• 显然，每分钟100美元的损失对公司管理层来说并不重要，因为对于他们而言，他们无法定位并确保有能力的开发人员返回以纠正他们的错误并帮助您恢复数据库。

该错误会影响多个表，其中一个表非常大，并且仅涉及数据本身，而不涉及架构，

• 所有数据库问题都“关注”模式。模式的设计方式将决定您如何解决此问题。

为了规避错误，您应该对数据进行一些试验，包括删除和更改数据，

• 这就是您的登台数据库的用途。在进行完整的生产在线备份之后，您可能需要立即使用生产数据库中的“损坏”数据重新填充它。

数据库很大，需要花费三个小时来进行或还原备份，

• 然后，最好立即开始，以便在分析问题，开发更正脚本，测试和完善它们以及开发人员和其他帮助您的DBA时使其运行。

上次完整备份是在三周前完成的。还有每日增量备份，最后一次每日增量备份是在14个小时前完成的，

• 您每天至少没有完整的在线备份吗？你完蛋了。但是您可能已经习惯了。不错，您在上面启动的完整备份正在运行。确保管理层在每天的在线备份中避免每分钟可以避免的成本。

假定数据库备份可靠；他们经过了严格的测试，包括最近

• 优秀！然后，您可能不必多次还原数据库。

丢失14小时的数据是不可接受的，但是丢失一到两个小时的数据是可以接受的，

• 在您描述的情况下，所有赌注都没有了。这是“信息灾难管理”情况。在整个过程中，管理层要做的一件好事是记录下将来可以通过适当的备份，恢复过程和资源避免的成本。

暂存环境最后在六个月前使用。似乎它不是最新的，可能要花几个小时才能完成设置，

• 如果您的备份系统支持联机备份（即，数据库在备份过程中可以完全正常运行），那么如果您有足够的硬件资源来避免减慢备份速度，则可以同时执行提取以重新填充临时数据库。

该数据库是Microsoft SQL Server 2008 Enterprise。

• 很难做到这一切，但并非没有可能。祝好运！