首先,如果我在 DBA 领域的知识非常有限,我想说声抱歉,因为我和其他几个团队成员刚刚获得这个项目,因为我们的资源非常有限。
给出的任务是从 2014 年到 2017 年升级多个 SQL Server 实例,并将一些实例升级到 2022 年,因为明年 EOS 即将到来。该范围还将多个数据库合并到一个实例中。我们已经制定了如何执行它的计划,但我们需要一些验证来确定此步骤是否正确,并获取一些有关部署的意见和建议。
预升级
- 备份我们首先备份所有要升级为.bak 格式的数据库。我们还将保存快照,以防 .bak 失败。
- 测试所述备份备份完成后,我们将创建一个虚拟机来恢复备份,以确保在升级过程中出现问题时能够使用.bak或快照(此步骤是强制性的,因为客户端很谨慎,因为之前的快照都失败了)
- 我们将生成数据迁移助手 (DMA) 报告,以便找出升级后哪些 SP 和功能不兼容。
- 这一切都将首先在开发阶段完成,如果一切成功,那么我们将在生产阶段进行。
升级
- 我们将修复 DMA 报告中的 SP 和功能,这些功能在升级后会出现问题
- 创建一个停机时间段,我们还将与运营团队协调,停止所有进出数据库的作业(例如 Talend 和 Microstrategy 等)。
升级后
- 确保没有弃用 SP 和函数
- 检查数据和可访问性
- 检查所有正在使用数据库的应用程序。
- 记录对 SP 和功能所做的所有更改
可能使用的替代方法
- 在产品中,创建另一个实例并升级该实例。如果成功,所有应用程序将重新路由到新实例并禁用旧实例。
局限性
- dev 中的数据明显较小,没有资源可复制
- 由于资源限制,创建与产品具有相同规格的虚拟机/服务器来测试或尝试制作可能会很困难
这就是目前的游戏计划,有什么建议或建议吗?有什么我们错过的吗?有什么需要注意的吗?有更好的方法吗?
我们处理此类任务的经验非常有限,因此我们非常担心事情会向南发展。当然,我们会事先测试这一点,甚至在升级开发之前,以确保一切都尽可能顺利。
非常非常感谢你。
支持 Peter 关于Query Store的建议。我什至会在升级之前启用它,并在可能的情况下从当前实例保存该数据(在运行 SQL Server 2016 或更高版本的适用实例上,如果有的话)。
您可能遇到的最大问题是某些查询的性能回归。这在升级时很常见,而且你们也在更改服务器设置/将多个数据库合并到单个实例中。而且您会跳过多个版本,尤其是升级到 2022 年的实例,自 2014 年以来发生了巨大的变化(甚至在 2019 年)。同时发生了很多事情,一些性能下降是不可避免的。
而且您将无法在开发环境中进行有保证的测试,特别是因为数据不相同。数据的数量和统计质量直接影响生成的查询计划。
Finally, I'd recommend that you upgrade all of the instances to the same version, of either 2019 or 2022 (2022 is still fairly new and potentially bug prone). For one, it'll be easier to manage all of them in regards to new features, when they're are all consistent in version. But also because 2017 already ended mainstream support and you don't want to be going through the upgrade process again in a few years, if you don't have to.
Sorry if this answer sounds like a downer, but it's the reality of how upgrades go.
Your best bet is to mimic the following as close as possible:
I don't expect you'll be able to follow this perfectly, but as close as you can will get you closer to the ideal way to upgrade.