数据库架构升级清单

我正在寻找一个行动项目的清单或时间表,如

> 8:30关闭应用程序
> 8:45修改模式
> 9:15安装新的应用程序
> 9:30 restart db

等等,显示如何最大限度地减少风险和停机时间.问题如：

如果出现问题,退出升级
尽量减少对现有应用的影响
>数据库运行时的“热”更新
从开发到测试到生产服务器的推广

特别感兴趣.

解决方法

这样做的关键是在测试环境中进行多次修改,然后才能在实时服务器上实现.

我保留一个从模板复制的部署清单文件,然后对每个版本进行大量编辑,其中任何不符合规定的.

我有两个在数据库上运行的脚本,一个用于模式更改,一个用于可编程性(过程,视图等).更改脚本是手动编码的,具有procs的脚本通过Powershell脚本编写.更改脚本在关闭所有操作时运行(您必须选择一个使用最少量的用户的时间),并且手动运行命令,以防任何事情发生.我遇到的最常见的问题是添加一个由于重复的行而失败的唯一约束.

在准备集成测试周期时,我将在测试服务器上查看我的清单,就像该服务器是否生产一样.然后,除此之外,我得到一个生产数据库的实际副本(这是一个很好的时间去掉你的异地备份),并且我在一个恢复的本地版本上运行脚本(这也是很好的,因为它证明了我的最新的备份是声音).我在这里用一块石头杀死了很多鸟.

所以这是4个数据库总数：

> Dev：所有更改都必须在变更脚本中进行,从不与工作室进行.
>测试：集成测试发生在这里
>生产副本：最后一刻的部署实践
>生产

你真的真的需要在生产时做到正确.备份模式更改很难.

至于修补程序,我只会修复程序,而不是模式,除非它是一个非常孤立的变化,对于业务至关重要.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!