引子

数据库升级就像给老房子做装修——表面上换个墙纸就能焕然一新，实际可能遇到承重墙改造、管线老化等隐藏问题。今天我们就以SQL Server 2016升级到2019的真实案例，聊聊那些让DBA们夜不能寐的兼容性陷阱。

一、升级前的"体检报告"有多重要？

某电商系统在凌晨三点升级失败后，值班工程师发现数据库卡在兼容性检查环节。他们犯的典型错误是直接修改数据库兼容级别：

-- 错误示范：暴力修改兼容级别
ALTER DATABASE OrderDB SET COMPATIBILITY_LEVEL = 150; -- 对应SQL Server 2019

结果导致应用出现大量OPTIMIZE FOR UNKNOWN查询异常。正确的做法应该是分三步走：

  1. 生成兼容性评估报告
Start-DmaAssessment -SourceServer "OLD_SQL2016" -TargetVersion "SQL2019" 
-OutputFilePath "C:\Reports\Compatibility.html"
  1. 检查残留的过时语法
-- 查询使用已废弃功能的存储过程
SELECT 
    OBJECT_NAME(object_id) AS ProcName,
    definition
FROM sys.sql_modules 
WHERE definition LIKE '%RAISERROR(%WITH NOWAIT%' -- 旧版RAISERROR语法
   OR definition LIKE '%sp_dboption%'; -- 已移除的系统存储过程
  1. 创建版本沙箱环境
-- 在测试环境克隆生产库
EXEC sp_detach_db @dbname = 'OrderDB_Prod';
COPY FILE 'OrderDB_Prod.mdf' TO 'OrderDB_Test.mdf';
EXEC sp_attach_db @dbname = 'OrderDB_Test', 
   @filename1 = 'C:\Data\OrderDB_Test.mdf';

二、依赖关系排查的三种方案

场景重现：某金融系统升级后，核心对账作业突然报错Invalid object name 'dba_check'。根本原因是某个SSIS包引用了已被重命名的历史表。

排查方案1：系统视图追踪

-- 查询所有对象依赖关系（SQL Server 2016+）
SELECT 
    referencing_entity_name AS 引用对象,
    referenced_entity_name AS 被引用对象 
FROM sys.dm_sql_referenced_entities('dbo.usp_DailyReport', 'OBJECT');

排查方案2：扩展事件捕获

-- 创建实时依赖追踪会话
CREATE EVENT SESSION [DepTracking] ON SERVER 
ADD EVENT sqlserver.object_altered,
ADD EVENT sqlserver.object_renamed
WITH (STARTUP_STATE=ON);

排查方案3：PowerShell自动化扫描

# 扫描整个实例的跨库依赖
$dbs = Invoke-SqlCmd -Query "SELECT name FROM sys.databases WHERE state=0"
foreach ($db in $dbs) {
    Invoke-Sqlcmd -Database $db.name -Query @"
        SELECT 
            OBJECT_NAME(referencing_id) AS SourceObject,
            referenced_entity_name AS TargetObject 
        FROM sys.sql_expression_dependencies
"@ | Export-Csv "Deps_$($db.name).csv" -Append
}

三、踩过的坑

案例1：同义词黑洞 某物流系统升级后，运输调度模块报错，最终定位到跨库同义词引用了已删除的视图：

-- 创建存在隐患的同义词
CREATE SYNONYM dbo.ShipmentView 
FOR LogisticsDB.dbo.vw_ActiveShipments; -- 目标视图在升级后被重构

/* 检测方案 */
SELECT 
    name AS SynonymName,
    base_object_name AS RealObject
FROM sys.synonyms 
WHERE base_object_name NOT IN (
    SELECT QUOTENAME(OBJECT_SCHEMA_NAME(object_id)) + '.' + QUOTENAME(name) 
    FROM sys.objects
);

案例2：CLR程序集版本冲突 某医院系统升级后，医疗影像处理函数集体罢工：

-- 问题程序集注册
CREATE ASSEMBLY ImageProcessor 
FROM 'D:\CLR\v2.0\ImageProc.dll' -- 依赖.NET Framework 3.5

/* 解决方案 */
ALTER ASSEMBLY ImageProcessor 
FROM 'D:\CLR\v4.0\ImageProc_v4.dll' 
WITH PERMISSION_SET = UNSAFE;

四、升级后的二次验证清单

  1. 关键功能冒烟测试
-- 检查所有作业是否正常运行
SELECT 
    name AS JobName,
    CASE enabled 
        WHEN 1 THEN '正常' 
        ELSE '禁用' 
    END AS Status
FROM msdb.dbo.sysjobs;
  1. 性能基线对比
-- 查询升级前后的执行计划差异
SELECT 
    query_hash,
    COUNT(distinct plan_handle) AS PlanCount
FROM sys.dm_exec_query_stats
GROUP BY query_hash
HAVING COUNT(distinct plan_handle) > 1;
  1. 残留兼容性标记检测
-- 查找仍使用旧兼容级别的数据库
SELECT name, compatibility_level 
FROM sys.databases 
WHERE compatibility_level < 150; -- 150对应SQL Server 2019

五、技术选型的平衡艺术

原生工具链 vs 第三方方案：

  • SSDT（SQL Server Data Tools） 优点：完美集成VS生态，支持架构比对 缺点：处理大型数据库时内存消耗高

  • Redgate SQL Compare 优点：差异分析速度快，支持命令行自动化 缺点：商业授权成本较高

版本回退的正确姿势：

# 使用数据库快照快速回滚
$snapshot = Get-DbaDbSnapshot -SqlInstance SQL2019 -Database OrderDB
Restore-DbaDatabase -SqlInstance SQL2019 -Database OrderDB 
-DatabaseSnapshot $snapshot.Name -Confirm:$false

应用场景与技术价值

在金融行业系统升级中，某银行通过系统视图+扩展事件的组合方案，将故障定位时间从平均4小时缩短至15分钟。制造业的ERP系统升级则因忽略CLR依赖，导致产线停机6小时，损失超百万。

避坑指南（注意事项）

  1. 永远保留升级前的数据库备份
  2. 在测试环境验证所有跨实例的链接服务器
  3. 特别注意复制（Replication）相关的元数据
  4. 检查AlwaysOn可用性组的同步状态
  5. 处理数据库邮件配置等外围组件

总结

数据库升级就像精密的外科手术，既需要全面的术前检查（兼容性评估），也要准备完善的手术方案（回滚计划），更离不开术后观察（性能监控）。记住：升级过程中最危险的不是已知的问题，而是那些你以为不存在的依赖。