带条带化的Ola备份作业无法运行问题求助

这种情况我之前帮不少朋友踩过坑，看似是引号没闭合的语法错误，实则大概率是SQL Server作业的一些细节设置或者参数传递的小问题在搞鬼，咱们一步步来排查解决：

• 先确认作业步骤的命令类型是否正确
  很多人容易犯这个低级错误：如果你的作业是要执行T-SQL调用存储过程，一定要把步骤的「命令类型」选为Transact-SQL脚本(T-SQL)，别误选成「操作系统(CmdExec)」或者其他类型。要是选成了CmdExec，SQL代理会把整个T-SQL脚本当成操作系统命令解析，自然会报引号不闭合的错误，而你手动在SSMS里执行T-SQL是正常的。

• 检查条带化备份的参数写法，重点关注引号与动态拼接
  条带化备份通常会用到@NumberOfFiles和@BackupFile这类参数，要确保所有参数的单引号都是成对的。如果是动态拼接脚本调用存储过程，记得SQL里转义单引号要用两个连续的单引号，比如：

  -- 正确的动态拼接写法
  DECLARE @BackupCmd NVARCHAR(MAX)
  SET @BackupCmd = 'EXEC [dbo].[DatabaseBackup] @Databases = ''AVAILABILITY_GROUP_DATABASES'', 
                    @BackupFile = ''D:\Backup\AGDB_*.bak'', 
                    @NumberOfFiles = 4'
  EXEC sp_executesql @BackupCmd
  

  要是拼接时少写了一个单引号，或者路径里有空格却没正确包裹引号，就会触发Msg105错误。

• 检查作业步骤的「替换变量」设置
  进入作业步骤的「高级」标签页，看看有没有开启「替换」功能。如果作业里用了类似$(BackupPath)这类代理变量，而变量值里包含单引号，就会破坏原脚本的引号结构。可以暂时关闭替换功能测试，或者确保变量值里的单引号已经转义（比如把'改成''）。

• 查看作业的完整执行日志，对比手动执行的脚本
  有时候Msg105的提示只是表面现象，作业实际执行的脚本可能因为环境变量或者参数传递被修改了。你可以：

  1. 在作业步骤里加入PRINT语句输出最终执行的脚本（如果是动态脚本的话）；
  2. 右键作业→「查看历史记录」，双击具体执行步骤查看详细日志，把实际执行的T-SQL和你手动运行的脚本对比，就能快速找到差异点。

• 关于报50000错误但备份仍完成的解释
  50000是SQL的自定义错误码，大概率是DatabaseBackup存储过程里的TRY/CATCH块捕获了某些非致命警告（比如某个数据库不在可用性组中、备份路径的权限警告等），抛出了自定义错误，但核心的备份逻辑已经执行完成。你可以查看存储过程的错误处理部分，确认具体触发的警告内容。

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