1. 迁移前的准备工作跨平台迁移数据库就像搬家前的打包工作需要提前确认好物品清单和运输工具。我经历过多次SQL Server从Windows到Linux的迁移发现90%的问题都出在准备阶段。以下是必须检查的关键点Windows端必备条件确保源数据库版本在SQL Server 2017及以上这是官方支持跨平台迁移的最低版本安装最新版SQL Server Management Studio建议18.0以上检查数据库兼容性级别SELECT compatibility_level FROM sys.databases WHERE name YourDB特别提醒如果使用TDE加密的数据库需要提前备份证书和密钥Linux端环境配置# 以Ubuntu为例的安装命令 sudo apt-get update sudo apt-get install -y mssql-server sudo /opt/mssql/bin/mssql-conf setup安装完成后务必验证服务状态systemctl status mssql-server --no-pager重要提示建议Windows和Linux端的SQL Server版本完全一致。我遇到过因小版本差异导致备份文件无法识别的情况最终不得不重新搭建环境。2. Windows端数据库备份实战备份是迁移过程中最关键的步骤这里分享两种经过验证的备份方法以及我踩坑后总结的优化方案。2.1 图形化界面备份SSMS新手推荐使用SSMS的图形界面操作直观且不易出错右键目标数据库 → 任务 → 备份备份类型选择完整备份目标选择磁盘点击添加指定备份路径建议使用.bak扩展名在介质选项中勾选验证备份这是很多教程忽略的关键步骤备份优化技巧大型数据库超过50GB建议启用压缩BACKUP DATABASE YourDB TO DISKC:\backup\YourDB.bak WITH COMPRESSION超大型数据库1TB考虑使用文件组分批备份2.2 T-SQL命令备份对于需要自动化的场景T-SQL命令更灵活。这是我优化过的备份脚本DECLARE backupPath NVARCHAR(255) C:\backup\ DECLARE dbName NVARCHAR(255) YourDB DECLARE fileName NVARCHAR(255) backupPath dbName _ REPLACE(CONVERT(NVARCHAR, GETDATE(), 112) CONVERT(NVARCHAR, GETDATE(), 108), :, ) .bak BACKUP DATABASE dbName TO DISK fileName WITH NAME N完整数据库备份, STATS 10, CHECKSUM, CONTINUE_AFTER_ERROR GO关键参数解析STATS10每完成10%显示进度CHECKSUM验证页校验和强烈建议开启CONTINUE_AFTER_ERROR遇到错误仍继续适用于有损坏的数据库3. 跨系统文件传输方案备份文件传输是Windows到Linux迁移的特有挑战这里提供三种经过实战检验的方案。3.1 SCP安全传输推荐这是最可靠的传输方式我在生产环境多次使用# Windows PowerShell执行 scp C:\backup\YourDB.bak usernamelinux_server:/tmp/如果遇到连接问题按这个顺序排查确认Linux端SSH服务运行sudo systemctl status sshd检查防火墙规则sudo ufw allow 22/tcp测试网络连通性ping linux_server_ip3.2 共享文件夹方案对于超大备份文件100GB建议使用Samba共享# Linux端安装Samba客户端 sudo apt-get install -y cifs-utils sudo mkdir /mnt/win_share sudo mount -t cifs //windows_ip/share /mnt/win_share -o usernamewin_user3.3 传输完整性验证无论采用哪种方式传输后务必验证# Linux端检查文件完整性 md5sum /tmp/YourDB.bak与Windows端生成的MD5对比Get-FileHash C:\backup\YourDB.bak -Algorithm MD54. Linux端数据库还原4.1 备份文件预处理SQL Server在Linux上有严格的权限要求需要将备份文件移动到特定目录sudo mkdir -p /var/opt/mssql/backup sudo chown mssql:mssql /var/opt/mssql/backup sudo mv /tmp/YourDB.bak /var/opt/mssql/backup/4.2 使用sqlcmd还原这是最基础的还原方法适合大多数场景sqlcmd -S localhost -U sa -Q RESTORE DATABASE YourDB FROM DISK/var/opt/mssql/backup/YourDB.bak WITH MOVE YourDB TO /var/opt/mssql/data/YourDB.mdf, MOVE YourDB_log TO /var/opt/mssql/data/YourDB_log.ldf高级还原场景处理包含多个数据文件的情况RESTORE DATABASE YourDB FROM DISK/path/to/backup.bak WITH MOVE datafile1 TO /var/opt/mssql/data/file1.mdf, MOVE datafile2 TO /var/opt/mssql/data/file2.ndf, MOVE logfile TO /var/opt/mssql/data/log.ldf4.3 验证还原结果执行这些检查命令确保数据库完整-- 检查数据库状态 SELECT name, state_desc FROM sys.databases; -- 验证表数据 USE YourDB SELECT COUNT(*) FROM sys.objects; -- 检查文件路径 SELECT name, physical_name FROM sys.master_files;5. 常见问题排查手册根据我的实战经验这些问题最高频出现问题1备份文件无法识别Error: The media family on device /var/opt/mssql/backup/YourDB.bak is incorrectly formed解决方案检查备份时是否启用了压缩但Linux端未安装压缩功能尝试在Windows端重新备份并禁用压缩问题2权限不足Error: Cannot open backup device /var/opt/mssql/backup/YourDB.bak解决方案sudo chown mssql:mssql /var/opt/mssql/backup/YourDB.bak问题3磁盘空间不足Error: There is insufficient free space on disk volume /var to create the database解决方案使用WITH MOVE重定向到其他分区清理日志文件sudo /opt/mssql/bin/mssql-conf traceflag 1806 on问题4字符集冲突Error: Cannot resolve the collation conflict between SQL_Latin1_General_CP1_CI_AS and Latin1_General_CI_AS解决方案RESTORE DATABASE YourDB FROM DISK/path/to/backup.bak WITH MOVE ..., COLLATE SQL_Latin1_General_CP1_CI_AS6. 性能优化建议迁移完成后这些优化能让数据库在Linux上跑得更快内存配置调整sudo /opt/mssql/bin/mssql-conf set memory.memorylimitmb 8192 sudo systemctl restart mssql-serverTempDB优化-- 根据CPU核心数添加TempDB文件 ALTER DATABASE tempdb MODIFY FILE (NAME tempdev, SIZE 4GB); GO DECLARE i INT 1; WHILE i 4 -- 根据核心数调整 BEGIN EXEC(ALTER DATABASE tempdb ADD FILE (NAME tempdev i , FILENAME /var/opt/mssql/data/tempdb i .ndf, SIZE 4GB)); SET i 1; ENDLinux内核参数调优# 编辑/etc/sysctl.conf vm.swappiness 1 vm.dirty_ratio 3 vm.dirty_background_ratio 2记得每次修改配置后都要重启服务sudo systemctl restart mssql-server7. 迁移后的验证清单为确保迁移成功建议执行以下验证步骤基础验证检查所有表数量是否一致验证关键存储过程是否正常执行测试应用程序连接数据一致性检查-- 在源库执行 SELECT OBJECT_NAME(object_id), rowcnt FROM sys.dm_db_partition_stats WHERE index_id 2; -- 在目标库执行相同查询对比结果性能基准测试记录关键查询在原环境的执行时间在新环境执行相同查询对比使用以下DMV检查等待统计SELECT wait_type, wait_time_ms/1000 as wait_time_sec FROM sys.dm_os_wait_stats ORDER BY wait_time_ms DESC;日志监控# 查看错误日志 sudo cat /var/opt/mssql/log/errorlog | grep -i error8. 进阶技巧与注意事项对于复杂迁移场景这些经验可能帮到你超大数据库迁移方案使用WITH STANDBY选项创建热备用数据库考虑使用Always On可用性组实现最小停机迁移对于TB级数据库先迁移架构再使用BCP导出数据特殊对象处理链接服务器需要重新创建SQL Agent作业需要手动迁移数据库邮件配置需重新设置监控建议# 实时监控还原进度另开终端执行 watch -n 5 sudo grep Processed /var/opt/mssql/log/errorlog | tail -n 1回退方案保留原环境至少48小时准备快速回退脚本记录所有配置变更迁移完成后建议运行DBCC检查USE YourDB DBCC CHECKDB WITH NO_INFOMSGS;记得在业务低峰期执行最终切换并提前通知相关团队。根据我的经验完善的沟通计划比技术方案更能确保迁移成功。