我们的服务器上有几个数据库。
我们想将这些数据库升级到 SQL 2008。
是否有可能某些应用程序功能在 2005 上可以运行,但在 2008 上却无法运行?
我听说 SQL 2008 与 2005 100% 向后兼容。
答案1
没有哪个版本的 SQL 是 100% 向后兼容的。每个版本都有一份详尽的弃用和停用功能列表,SQL Server 2008 也不例外。该列表发布于SQL Server 数据库引擎向后兼容性。这包含 SQL 2008 不再支持的功能列表,例如:
- sp_addalias
- DUMP 和 LOAD 语句
- 使用 NOLOG 备份日志/使用 TRUNCATEONLY 备份日志
- 备份交易
- DBCC 并发冲突
- 组名/组名称/组名称/组名称
- 执行以下任一操作:
- 示例:sp_enumcodepages
此外,SQL Server 的任何功能停用之前都会发出充分的警告。SQL 2008 中停用的所有功能均列在 SQL 2005 中已弃用的功能列表中。您可以使用 SQL Profiler 来监视 SQL 2005 应用程序并观察以下事件:
每次您的应用程序使用“濒危”列表中的功能时,都会触发第一个事件。当您使用将在下一版本中停止使用的功能时,会触发第二个事件。
最后,还有针对已弃用功能的 SQL 性能计数器,请参阅我正在使用哪些已弃用的功能?:
select instance_name as [Deprecated Feature]
, cntr_value as [Frequency Used]
from sys.dm_os_performance_counters
where object_name = 'SQLServer:Deprecated Features'
and cntr_value > 0
order by cntr_value desc
在所有可用的文档和基础设施之间监控已弃用的功能,您有足够的方法来确定您的应用程序是否正在使用任何已停用的功能。
话虽如此,除非您使用 SQL Server 6.0 黑暗时代的功能,否则您的应用程序很可能不会在 SQL Server 2008 上运行。升级的理由有很多,主要是我总是引用页面压缩,这实际上是在不增加成本的情况下实现了巨大的性能提升(我为了达到戏剧效果而夸大了一点,但只是稍微夸大了一点)。
您应该继续进行升级,但要明智地进行:
- 跑过升级顾问,阅读其建议
- 拥有一个测试环境,首先在测试中部署你的应用程序
- 进行全面的功能测试,验证您的产品是否仍能像宣传的那样工作。如果您可以测量测试代码覆盖率,请尝试达到 85-90% 的覆盖率
- 如果出现问题,要制定退出策略。请记住,升级后的数据库可能会绝不降级。因此,请妥善保存 SQL 2005 数据库文件副本,以防被迫降级。制定技术计划,说明如何在需要时将升级后的交易应用回 2005,或者制定业务计划来解释交易丢失的原因(我不是在开玩笑,这可能是一个完全可以接受的解决方案)。
因此,根据你的数据有多珍贵,你可以选择全部、部分或不采用上述任何一种方法。我可以说,如果你属于“全部”情况,你可能一开始就不会问这个问题了 ;) 所以可能一些上述建议适用于您。
答案2
我们无法告诉你什么你的应用程序就可以了。
我认为最好的做法是拥有第二台运行 SQL Server 2008 的服务器,将数据库迁移到该服务器(也许一次迁移一个,慢慢地),如果有任何问题,则切换回 SQL Server 2005 服务器。
这确实需要两台服务器(物理的或虚拟的),但无论哪种情况都能提供完美的可恢复性。
答案3
一个很好的测试方法是运行 Microsoft SQL Server 2008 升级顾问。Microsoft SQL Server 2008 升级顾问会分析 SQL Server 2000 和 SQL Server 2005 的实例,为升级到 SQL Server 2008 做准备。升级顾问会识别可能影响升级的功能和配置更改,并提供描述每个已识别问题及其解决方法的文档链接。
您可以在生产中运行它,但如上所述,测试环境始终是最好的。