将SQL Server数据库部署到Azure失败的问题排查求助

这种之前能成功部署、突然报错的情况确实挺闹心的，结合我帮别人排查这类问题的经验，给你列几个最可能的方向，你挨个排查试试：

毕竟之前成功过，大概率是最近数据库的架构或数据出现了Azure不兼容的内容：

• 检查新增的对象：有没有用SQL Server独有的特性？比如FILESTREAM、CLR集成、分布式事务、或者调用xp_cmdshell这类高权限系统存储过程，这些在Azure SQL Database里都是受限的。
• 核对数据量级：如果部署时选择迁移数据，最近有没有新增超大表或者数据量暴增？Azure SQL DB的目标服务层（比如Basic、Standard）有没有足够的DTU/存储配额？资源不够的话部署会直接失败。
• 权限依赖问题：数据库里有没有用到本地Windows登录？Azure SQL DB只支持SQL登录或Azure AD身份，这类本地依赖会导致部署时权限验证失败。

有时候是SSMS图形化向导的bug：

• 先把SSMS更到最新版本：旧版本的SSMS对Azure SQL DB的新特性支持不足，很多奇怪的部署bug在更新后会自动解决。
• 用SqlPackage.exe命令行试试：这个是SSMS向导底层用的工具，能输出更详细的错误日志。命令大概是这样的（替换成你的信息）：

  SqlPackage.exe /Action:Publish /SourceServerName:"你的本地SQL实例名" /SourceDatabaseName:"要部署的数据库名" /TargetServerName:"你的Azure SQL服务器名.database.windows.net" /TargetDatabaseName:"Azure端目标库名" /TargetUser:"Azure SQL登录账号" /TargetPassword:"登录密码"
  

  运行后看输出的错误信息，能精准定位到底是哪一步出问题。

说不定是Azure那边的设置被改了：

• 防火墙规则：是不是最近调整过Azure SQL服务器的防火墙，导致你本地SSMS所在的IP被拦截了？哪怕之前成功过，防火墙规则变了就会连不上。
• 目标库兼容级别：虽然你本地是140，但Azure端的目标库如果被改成了更低的级别（比如120），也会导致部署失败，去Azure Portal里找目标库的“配置”选项核对一下。
• 资源状态：去Azure Portal的监控面板看看目标Azure SQL DB的CPU、内存、存储是不是占满了？资源耗尽的话，部署操作会被强制终止。

• 检查本地备份：如果是通过备份还原的方式部署，看看本地数据库的备份文件是不是完整？有没有备份过程中报错的日志，或者备份文件损坏的情况？
• 存储配额：确认Azure目标库的最大存储容量是不是大于本地数据库的大小？比如本地库已经100GB，但你选的Azure服务层是Basic（最大2GB），这肯定会失败。

内容的提问来源于stack exchange，提问作者blizz