首先,如果我在 DBA 领域的知识非常有限,我想说声抱歉,因为我和其他几个团队成员刚刚获得这个项目,因为我们的资源非常有限。
给出的任务是从 2014 年到 2017 年升级多个 SQL Server 实例,并将一些实例升级到 2022 年,因为明年 EOS 即将到来。该范围还将多个数据库合并到一个实例中。我们已经制定了如何执行它的计划,但我们需要一些验证来确定此步骤是否正确,并获取一些有关部署的意见和建议。
预升级
- 备份我们首先备份所有要升级为.bak 格式的数据库。我们还将保存快照,以防 .bak 失败。
- 测试所述备份备份完成后,我们将创建一个虚拟机来恢复备份,以确保在升级过程中出现问题时能够使用.bak或快照(此步骤是强制性的,因为客户端很谨慎,因为之前的快照都失败了)
- 我们将生成数据迁移助手 (DMA) 报告,以便找出升级后哪些 SP 和功能不兼容。
- 这一切都将首先在开发阶段完成,如果一切成功,那么我们将在生产阶段进行。
升级
- 我们将修复 DMA 报告中的 SP 和功能,这些功能在升级后会出现问题
- 创建一个停机时间段,我们还将与运营团队协调,停止所有进出数据库的作业(例如 Talend 和 Microstrategy 等)。
升级后
- 确保没有弃用 SP 和函数
- 检查数据和可访问性
- 检查所有正在使用数据库的应用程序。
- 记录对 SP 和功能所做的所有更改
可能使用的替代方法
- 在产品中,创建另一个实例并升级该实例。如果成功,所有应用程序将重新路由到新实例并禁用旧实例。
局限性
- dev 中的数据明显较小,没有资源可复制
- 由于资源限制,创建与产品具有相同规格的虚拟机/服务器来测试或尝试制作可能会很困难
这就是目前的游戏计划,有什么建议或建议吗?有什么我们错过的吗?有什么需要注意的吗?有更好的方法吗?
我们处理此类任务的经验非常有限,因此我们非常担心事情会向南发展。当然,我们会事先测试这一点,甚至在升级开发之前,以确保一切都尽可能顺利。
非常非常感谢你。