《Windows Azure Platform 系列文章目录》
今天遇到一个Case，客户在使用Azure Automation，执行Azure SQL Database 存储过程的时候，超过3个小时造成超时Runbook超时。
https://docs.azure.cn/zh-cn/automation/automation-runbook-execution
为了在云中的所有 Runbook 之间共享资源，Azure 自动化在任何作业运行三小时后都会将其暂时卸载。 在此期间，基于 PowerShell 的 Runbook 作业都将停止且不能重新启动。 作业状态显示“已停止”。 此类型的 Runbook 始终从头开始重新启动，因为它们不支持检查点。
基于 PowerShell 工作流的 Runbook 会从上一个检查点进行恢复。 运行三小时后，Runbook 作业将由服务挂起，且其状态显示为“正在运行等待资源”。 沙盒变为可用时，Runbook 将通过自动化服务自动重新启动，并从上一个检查点恢复。 这是实现挂起/重新启动的正常 PowerShell 工作流行为。 如果 Runbook 再次超过三小时的运行时，将重复该过程，最多三次。 在第三次重新启动后，如果 Runbook 仍未在三小时内完成，则 Runbook 作业将失败，且作业状态显示为“失败，正在等待资源”。 在此情况下，会收到以下异常和失败。
因为客户的存储过程的逻辑很复杂，执行时间超过3个小时且无法短期内修改。
我换了一个思路，可以通过客户自己本地IDC的SQL Server VM，通过增加本地Linked Server，链接云端的Azure PaaS SQL Database。
然后在本地IDC的Azure SQL VM的SQL Agent执行SQL Job。步骤如下：
1.在本地的PC上，安装SQL Server management Studio，链接到云端Azure SQL Database
2.在本地PC的SSMS，在Master库里，增加Linked Server。命令如下：
EXEC sp_addlinkedserver @server='AzureSQL', @srvproduct='', @provider='sqlncli', @datasrc='tcp:你的云端数据库Server Name.database.chinacloudapi.cn,1433', @location='', @provstr='', @catalog='你的云端数据库DBName' exec sp_addlinkedsrvlogin 'AzureSQL', 'FALSE', NULL, '登录云端数据库的用户名','登录云端数据库的密码';
这里的sp_addlinkedsrvlogin，第一个参数是Linked Server的别名
3. 执行成功后，可以看到本得SQL Server，有Linked Server信息。如下图：
4.可以测试执行脚本，比如：
select * from AzureSQL.[LeiSQLDB].[SalesLT].[Customer];
注意，第一个参数是linkedDB的别名。我们在步骤2里面指定好了。
第2个参数是Database Name。
第3个参数是Schema and Table
5.执行结果
6.然后我们可以通过本地的SQL Agent，执行SQL Job
7.下面的步骤略
