Bloqueo de compilación excesivo en sp_procedure_params_90_rowset

14

Un resurgimiento de esta pregunta en MSDN: Informe de proceso bloqueado: ¿qué es este recurso de espera "OBJETO: 32767: 124607697: 0 [COMPILAR]"

He captado estas declaraciones en Profiler. Todos tienen duraciones de más de 3 segundos. Algunos mayores de 10 años. La actividad de bloqueo es la misma que el enlace de MSDN .

Todas las llamadas usan nombres de 3 partes. Todos especifican un proceso diferente en forma similar a la siguiente:

exec [db1].[sys].sp_procedure_params_90_rowset N'proc1', 1, NULL, NULL
exec [db2].[sys].sp_procedure_params_90_rowset N'proc2', 1, NULL, NULL
exec [db3].[sys].sp_procedure_params_90_rowset N'proc3', 1, NULL, NULL
exec [db4].[sys].sp_procedure_params_90_rowset N'proc4', 1, NULL, NULL

¿Qué puedo hacer para reducir este nivel de bloqueo?

(editar) Ahora estoy viendo lo mismo para:

exec [db1].[sys].sp_primary_keys_rowset N'view1', N'dbo'
exec [db2].[sys].sp_primary_keys_rowset N'view1', N'dbo'
exec [db3].[sys].sp_primary_keys_rowset N'view1', N'dbo'
exec [db4].[sys].sp_primary_keys_rowset N'view1', N'dbo'

Está sucediendo algo sistémico pero no sé qué más hacer. la persona que llama es VB6 a través de ADO. Es ADO haciendo estas llamadas.

Un ejemplo de informe de proceso bloqueado está debajo

 <blocked-process-report>
    <blocked-process>
        <process
            id="process5bc1288"
            taskpriority="0"
            logused="0"
            waitresource="OBJECT: 32767:124607697:0 [COMPILE]"
            waittime="28887"
            ownerId="11638114050"
            transactionname="sqlsource_transform">
            <executionStack>
                <frame
                    line="1"
                    sqlhandle="0x000000000000000000000000000000000000000000000000">
                    <sqltext>EXEC [dbo].[spAlertDetectByPoll] ':V:^RMAlert^:Z:^&amp;N&amp;#RMAlert#&amp;S&amp;#L#&amp;UID&amp;#19#&amp;AGN&amp;#1#&amp;DFC&amp;#103#^', 1</sqltext>
                </frame>
            </executionStack>
            <inputbuf>
SET NO_BROWSETABLE OFF   </inputbuf>
        </process>
    </blocked-process>
    <blocking-process>
        <process
            status="suspended"
            waitresource="OBJECT: 32767:124607697:0 [COMPILE]"
            waittime="35693"
            spid="1121"
            sbid="0"
            ecid="0"
            priority="0"
            trancount="0"
            lastbatchstarted="2013-12-16T14:45:48.960">
            <executionStack>
                <frame
                    line="1"
                    sqlhandle="0x000000000000000000000000000000000000000000000000" />
            </executionStack>
            <inputbuf>
SET NO_BROWSETABLE OFF   </inputbuf>
        </process>
    </blocking-process>
</blocked-process-report>
sql-server-2008-r2 blocking dan holmes
fuente
¿Tiene el service pack más reciente y las actualizaciones acumulativas instaladas para SQL Server 2008 R2?
Max Vernon
SP2 CU4 Microsoft SQL Server 2008 R2 (SP2) - 10.50.4270.0 (X64)
dan holmes
¿Cuándo comenzó a suceder esto? ¿Recientemente aplicó el Service Pack o la Actualización acumulativa? También estoy apoyando VB6 / ADO y recuerdo haber visto aparecer estos procs del sistema una o dos veces, pero no creo que haya un problema de bloqueo. Creo que surgieron porque se les llama con tanta frecuencia. Rezo para que esto no esté relacionado con SP / CU porque todavía estamos en 10.50.2500, y sería mortal si estas cosas comenzaran a tomar de 3 a 10 segundos cada una.
Jon Seigel
puso uno de los muchos en pastbin pastebin.com/4wUgzby9 . Esto ha estado sucediendo durante aproximadamente 2 o 3 semanas. No hemos aplicado una CU en mucho tiempo. Sucedió a principios de 2012 la primera vez que data de la publicación de MSDN.
dan holmes
1
Esto podría ser solo el síntoma. Tengo actividad de espera regular en RESOURCE_SEMAPHORE_QUERY_COMPILE. Aquí está el mejor tratamiento de este tipo de espera que he encontrado: blogs.msdn.com/b/support_sql_france/archive/2012/02/07/…
dan holmes

Respuestas:

2

Hay una excelente publicación de blog http://blogs.msdn.com/b/support_sql_france/archive/2012/02/07/sql-server-compilation-gateways-and-resource-semaphore-query-compile.aspx que explica qué es sucediendo.

SQL Server permite un número determinado de compilaciones en función de su complejidad. Los agrupa en pequeños, medianos y grandes. Para compilaciones grandes, solo puede haber una compilada a la vez, por lo que digamos que todos sus procesos se consideran grandes, luego cada uno debe compilarse en serie. Eso podría explicar el bloqueo.
Creo que puede haber varios enfoques para el problema: considere más recursos (más CPU permitirán que más consultas pequeñas y medianas sean concurrentes o que aumenten el umbral de lo que se considera medio). Además, más memoria puede resolver el problema.

Si eres como la mayoría de nosotros, eso podría no ser posible. Otra opción podría ser revisar las llamadas de ADO y ver si la cantidad de llamadas puede reducirse o extenderse para que no todas las llamadas se realicen al mismo tiempo. Reducir el número en cualquier momento dado debería reducir su tiempo de espera.

Si eso no funciona, considere la posibilidad de arreglar la 'compibilidad' de los procesos almacenados. Tal vez descomponerlos en trozos más pequeños que podrían reducirlos a los cubos pequeños o medianos y permitir compilaciones más paralelas. O determine por qué los procs necesitan ser recompilados cada vez. Vea si pueden reescribirse de tal manera que no necesiten volver a compilarse. Finalmente, consideraría usar las Guías de Plan. Esto permitirá que los procs sean precompilados y puede ahorrar algo de tiempo.

Espero que ayude

paulbarbin
fuente