Bloqueio excessivo de compilação em sp_procedure_params_90

Um ressurgimento dessa pergunta no MSDN: Relatório de processo bloqueado: o que é esse recurso de espera "OBJECT: 32767: 124607697: 0 [COMPILE]

Eu peguei essas declarações no Profiler. Todos eles têm durações superiores a 3 segundos. Alguns com mais de 10 anos. A atividade de bloqueio é igual ao link do MSDN .

Todas as chamadas usam nomes de três partes. Todos especificam um processo diferente na forma com a seguinte aparência:

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

O que posso fazer para reduzir esse nível de bloqueio?

(editar) Agora estou vendo a mesma coisa 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'

Há algo sistêmico acontecendo, mas não sei mais o que fazer. o chamador é VB6 via ADO. É a ADO fazendo essas chamadas.

Um exemplo de relatório de processo bloqueado está abaixo

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

Você tem o service pack mais recente e as atualizações cumulativas instaladas no SQL Server 2008 R2?

Max Vernon

SP2 CU4 Microsoft SQL Server 2008 R2 (SP2) - 10.50.4270.0 (X64)

dan holmes

Quando isso começou a acontecer? Você aplicou recentemente o Service Pack ou a atualização cumulativa? Também estou apoiando o VB6 / ADO e lembro de ver esses procs do sistema surgir uma ou duas vezes, mas não acho que houve um problema de bloqueio. Eu acho que eles surgiram porque são chamados com tanta frequência. Rezo para que isso não esteja relacionado ao SP / CU porque ainda estamos em 10.50.2500, e seria morte se essas coisas começassem a levar de 3 a 10 segundos cada.

precisa

colocou um dos muitos em pastbin pastebin.com/4wUgzby9 . isso já dura cerca de 2 ou 3 semanas. Não aplicamos uma UC há muito tempo. Foi o que aconteceu no início de 2012, pela primeira vez na data da publicação do MSDN.

Dan holmes

esse pode ser apenas o sintoma. Tenho atividade de espera regular em RESOURCE_SEMAPHORE_QUERY_COMPILE. Aqui está o melhor tratamento desse tipo de espera que encontrei: blogs.msdn.com/b/support_sql_france/archive/2012/02/07/…

dan holmes

Existe uma excelente publicação no 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 o que é acontecendo.

O SQL Server permite um número definido de compilações com base em sua complexidade. Ele os agrupa em pequenos, médios e grandes. Para compilações grandes, pode haver apenas um compilado de cada vez; portanto, digamos que todos os seus procs são considerados grandes, então cada um deve ser compilado em série. Isso pode explicar o bloqueio.
Eu acho que pode haver várias abordagens para o problema - considere mais recursos (mais CPUs permitirão que mais consultas pequenas e médias sejam simultâneas ou podem aumentar o limite para o que é considerado médio). Além disso, mais memória pode resolver o problema.

Se você é como a maioria de nós, isso pode não ser possível. Outra opção pode ser revisar as chamadas ADO e verificar se o número de chamadas pode ser reduzido ou distribuído para que nem todas as chamadas ocorram ao mesmo tempo. Reduzir o número a qualquer momento deve reduzir o tempo de espera.

Se isso não funcionar, considere corrigir a 'compilabilidade' dos procs armazenados. Talvez divida-os em pedaços menores, o que pode reduzi-los aos baldes pequenos ou médios e permitir mais compilações paralelas. Ou determine por que os procs precisam ser recompilados a cada vez. Veja se eles podem ser reescritos de forma que não precisem ser recompilados. Finalmente, eu consideraria o uso de Guias de Plano. Isso permitirá que os procs sejam pré-compilados e pode economizar algum tempo.

espero que ajude

paulbarbin
fonte

Bloqueio excessivo de compilação em sp_procedure_params_90_rowset

Respostas: