超时在SQL Azure上过期; 无法在内部部署SQL Server

Question

在我们的业务范围内,我们托管基于REST的API,由Windows Azure托管,SQL Azure作为数据库存储.

Web角色(Windows 2008R2,IIS 7.5,WCF,大型实例)和SQL Azure都托管在北欧地区.

问题是,当我们进行密集的SQL工作时,我们经常会遇到"Timeout expired.在操作完成之前超时时间已过,或者服务器没有响应." .

让我感到困扰的是,无论我们做什么,我们都无法在我们的内部部署SQL服务器(SQL Server 2008R2)上引发这种情况.

任何帮助澄清这个谜团的人都会受到赞赏,因为似乎Web角色实例并不是直接与SQL Azure实例交谈,尽管两者都位于北欧.

更详细的例外:

<SqlException>
    <Message>Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.</Message>
    <StackTrace>
        <Line>at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)</Line>
        <Line>at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning()</Line>
        <Line>at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)</Line>
        <Line>at System.Data.SqlClient.SqlDataReader.ConsumeMetaData()</Line>
        <Line>at System.Data.SqlClient.SqlDataReader.get_MetaData()</Line>
        <Line>at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)</Line>
        <Line>at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)</Line>
        <Line>at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)</Line>
        <Line>at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)</Line>
        <Line>at System.Data.SqlClient.SqlCommand.ExecuteScalar()</Line>
        <Line>at SyncInvokeAddCollaboratorFieldInstance(Object , Object[] , Object[] )</Line>
        <Line>at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]&amp; outputs)</Line>
        <Line>at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc&amp; rpc)</Line>
        <Line>at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc&amp; rpc)</Line>
        <Line>at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31(MessageRpc&amp; rpc)</Line>
        <Line>at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)</Line>
    </StackTrace>
    <UserDefinedInformation>
        <HelpLink.ProdName><![CDATA[Microsoft SQL Server]]></HelpLink.ProdName>
        <HelpLink.ProdVer><![CDATA[11.00.2065]]></HelpLink.ProdVer>
        <HelpLink.EvtSrc><![CDATA[MSSQLServer]]></HelpLink.EvtSrc>
        <HelpLink.EvtID><![CDATA[-2]]></HelpLink.EvtID>
        <HelpLink.BaseHelpUrl><![CDATA[http://go.microsoft.com/fwlink]]></HelpLink.BaseHelpUrl>
        <HelpLink.LinkId><![CDATA[20476]]></HelpLink.LinkId>
    </UserDefinedInformation>
</SqlException>

Answer 1

如果您需要进行SQL密集型工作(例如,规范化OLTP数据库中的大量INSERT语句),则需要在代码中使用故障转移逻辑.

内部部署SQL服务器不会受此影响,因此在切换到SQL Azure之前请考虑这一点.

这两篇文章激发了我的灵感(特别感谢Joachim Isaksson的指导):

http://blogs.msdn.com/b/sqlazure/archive/2010/05/11/10011247.aspx

http://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/7a50985d-92c2-472f-9464-a6591efec4b3/

为了得到结果的总和,我提供了两个结果,这两个结果在结果上是相同的(在没有添加的一些记录之前,对于原始问题缺少故障转移逻辑:Timeout Expired):

内部部署SQL Server:在427秒内创建179.285条记录

SQL Azure w.故障转移逻辑:在2.247秒内有179.285条记录 - 一个高出5.2倍的速度!

我希望这可以帮助其他人与SQL Azure斗争.积极的一面; 你学习(艰难的)你在本土的内部应用程序中幸运和特权:-)

注意:我仍然想要解释这是怎么发生的..似乎很容易责怪延迟,不是吗？