【问题标题】:Best practices in making schema changes to large production databases对大型生产数据库进行架构更改的最佳实践
【发布时间】:2012-05-05 15:00:33
【问题描述】:
我们有时必须对基于 mysql 或 mssql 的生产数据库进行架构更改。我对这通常是多么严峻的考验感到震惊。技术人员使用各自平台的浏览器(例如 Sql server Management Studio)进行更改,我观察到此过程存在几个问题:
- 对数据库的每次更改都会花费大量时间,从而导致技术人员不满意并导致数据库停机时间延长。
- 技术人员不知道数据库引擎在进行更改时所取得的进展。问题的出现是因为技术人员在过程中不知道在尝试进行更改时是否存在某种故障,或者只是执行此更改需要很长时间。
有没有更好的方法来做到这一点?通过命令行脚本更改表是否被认为是最佳实践?执行架构更改时是否可以监控进度?
谢谢,
艾略特
【问题讨论】:
标签:
database
sql-server-2008
database-schema
mysql-management
【解决方案1】:
Elliott,从您的 cmets 看来,您正在使用客户支持而不是支持开发人员来对数据库进行更改。如果我错了,请纠正我。如果您使用 Support Developer,他们应该运行脚本来进行更改,这始终是最好的方式。通过阅读您的问题,您的数据库看起来确实有大量记录。要获取脚本,您可以使用 Microsoft VisualStudio DB 版本。它将比较数据库源项目和您要将其部署到的数据库。然后,您可以查看创建的脚本并在服务器上运行它。
关于需要很长时间的更改问题,正如我所说,取决于数据量和您正在执行的架构更改。为了防止长时间停机,您需要找到对客户影响最小的时间,并在此期间进行。如果您是 24x7 系统,则必须安排停机时间。
另外,试着研究你的变化模式。是否有可能您可以将所有更改分组到单个版本,以便减少停机时间。另外,看看为什么要进行如此多的数据库更改,您可以在设计中做些什么来减轻更改。例如。每次进行架构更改时,可能都会重新构建索引。可能您可以在架构更改期间禁用索引。完成架构更改,然后使用数据库作业安排索引重建
关于您关于监控架构更改的问题,我认为没有任何视觉指标可以说明已经完成了这么多。您只需要等待命令完成即可。
【解决方案2】:
实际上,您可以更改架构并在生产环境中保持数据库在线。
1.alter table 添加新列并设置默认值为null
2.创建一个SP来更新一小块chunk数据中的值,比如10K
3. 用正确的默认值修改表格