诸如创建新表或添加新列之类的操作对性能的影响应该很小并且是透明的,特别是如果应用程序应用了处理瞬态故障的推荐模式(例如通过利用Enterprise Library)。
大规模更新或重新索引可能会导致争用并影响应用程序的性能,甚至会导致错误。根据具体情况,瞬态故障处理也可以解决这个问题。
对正在升级的数据的并发修改可能会导致更难以处理的问题。这些是一些可能的方法:
维护窗口
最简单和安全的方法是使应用程序脱机、备份数据库、升级数据库、更新应用程序、测试并使应用程序重新联机。
只读模式
这种方法通过保持应用程序在线但禁用任何更改数据库的功能来避免使应用程序完全不可用。在应用程序更新时,用户仍然可以查询和查看数据。
分阶段升级
这种方法基于对数据库结构和数据以及应用程序代码的精心计划的更改序列,以便在任何给定阶段,在线应用程序版本与当前数据库结构兼容。
例如,假设我们需要在客户记录中引入“最后购买日期”字段。可以使用此序列:
- 将新字段添加到数据库中的客户记录(不更新应用程序)。将新字段默认值设置为 NULL。
- 更新应用程序,以便为每次新销售更新最后一次购买日期字段。对于旧销售,该字段保持不变,此时应用程序不会查询或显示新字段。
- 在数据库上执行批处理作业,为仍然为 NULL 的所有客户更新此字段。可以在更新之间引入延迟,以便系统不会过载。
- 更新应用程序以开始查询和显示新信息。
这种方法有多种变体,例如零停机数据库部署中描述的“扩展脚本”和“收缩脚本”的概念。这可以与功能切换一起使用,以在执行升级阶段时动态地更改应用程序的行为。
可以将新列添加到记录中以指示它们已被转换。应用程序逻辑可以适应同时处理旧版本和新版本中的记录。
实体框架可能会在选项中施加一些额外的限制,因为它代表应用程序生成 SQL 语句,因此您在规划阶段时必须考虑到这一点。
暂存环境
更改生产数据库结构和执行大量数据更改是有风险的业务,尤其是在用户输入和更改数据时必须按特定顺序完成时。您恢复错误的选择可能会受到严重限制。
在生产环境上执行升级过程之前,有必要在单独的临时环境中进行广泛的测试和模拟。