Tiempo de espera caducado en SQL Azure; no se puede reproducir SQL Server local

En nuestra línea de negocio, estamos alojando una API REST basada en Windows Azure y con SQL Azure como almacenamiento de base de datos.Tiempo de espera caducado en SQL Azure; no se puede reproducir SQL Server local

Tanto el rol web (Windows 2008R2, IIS 7.5, WCF, instancia grande) como SQL Azure se alojan en la región del norte de Europa.

El problema es que cuando hacemos un trabajo SQL intensivo a menudo obtenemos un "Tiempo de espera caducado. El tiempo de espera transcurrido antes de la finalización de la operación o el servidor no responde"..

Lo que me preocupa aquí es que no importa lo que hagamos, no podemos provocar esto en nuestros servidores SQL locales (SQL Server 2008R2).

Se agradece cualquier ayuda para aclarar este misterio, ya que parece que la instancia de Web Role no está hablando directamente con la instancia de SQL Azure, aunque ambas están ubicadas en el norte de Europa.

Una excepción más detallada:

<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>

Fuente

2012-09-25 Michael Mortensen

Índices idénticos en las dos bases de datos? Sí, es más probable que Azure SQL sea más lento para consultas simples debido a la latencia, pero 8-15 veces suena bastante pronunciado para el mismo esquema de base de datos. –

Sí, esquemas "idénticos" donde SSMS 2012 genera el script para SQL Azure. "Idéntico" porque el script generado no es 1-1 con SQL Server 2008R2. Puedo, en algún momento, entender la latencia, pero ¿no debería "eliminarse" cuando tanto la Web como SQL están en la misma región? –

Y tienes razón; el 8-15 fue exagerado ... es más de 4 a 8 veces más lento (diferentes escenarios, para este es "solo" 4-5 veces más lento), pero con los registros que faltan hacen que se agote el tiempo de espera. –

Si usted tiene que hacer un trabajo intensivo de SQL (por ejemplo, una gran cantidad de instrucciones INSERT en una base de datos OLTP normalizado) es necesario tener conmutación por error de lógica en el código .

El servidor SQL local no sufrirá esto, así que ten esto en cuenta antes de cambiar a SQL Azure.

Estos dos artículos me inspiraron (gracias especiales a Joachim Isaksson para guía):

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/

En suma del resultado, me han proporcionado los dos resultados, que es ahora Idéntico en el resultado (donde antes algunos registros no agregados hacen falta la lógica de conmutación por error con respecto a la pregunta original: Tiempo de espera caducado):

Servidor SQL en las instalaciones: 179.285 registros en 427 segundos

SQL Azure w. lógica de conmutación por error: 179.285 registros en 2.247 segundos: ¡una alarma sonora 5.2 veces más lenta!

Espero que esto pueda ayudar a otros que luchan con SQL Azure. En una nota positiva; usted aprende (de la manera difícil) que ha tenido la suerte y el privilegio en sus aplicaciones internas nativas :-)

Nota: todavía me gustaría una explicación de cómo puede suceder esto ... parece ser fácil culpar a la latencia, ¿no?

Fuente

2012-09-25 17:44:44

Tiempo de espera caducado en SQL Azure; no se puede reproducir SQL Server local

Respuesta

Cuestiones relacionadas