数据库架构升级清单

前端之家收集整理的这篇文章主要介绍了数据库架构升级清单前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
必须升级数据库模式才能使安装新版本的软件变得更加棘手.这样做最好的做法是什么?

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

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

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

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

特别感兴趣.

解决方法

我有很多经验.我的应用程序是高度迭代的,模式更改频繁发生.我大概每2到3周进行一次生产发布,每个产品从我的FogBugz清单中清除50-100个产品.过去几年我们所做的每一个版本都需要架构更改来支持功能.

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

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

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

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

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

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

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

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

原文链接:https://www.f2er.com/mssql/75721.html

猜你在找的MsSQL相关文章