Übermäßige Kompilierungssperre für sp_procedure_params_90

Eine Wiederholung dieser Frage auf MSDN: Blocked-Process-Report: Was ist diese Waitresource? "OBJECT: 32767: 124607697: 0 [COMPILE]"

Ich habe diese Aussagen in Profiler abgefangen. Sie haben alle eine Dauer von mehr als 3 Sekunden. Einige über 10+. Die Blockierungsaktivität entspricht der Verknüpfung von MSDN .

Die Anrufe verwenden alle 3-teilige Benennung. Alle geben einen anderen Prozess in der folgenden Form an:

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

Was kann ich tun, um diese Blockierungsstufe zu reduzieren?

(edit) Ich sehe jetzt dasselbe für:

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'

Es ist etwas systemisches im Gange, aber ich weiß nicht, was ich sonst tun soll. Der Anrufer ist VB6 über ADO. Es ist ADO, der diese Anrufe tätigt.

Ein Beispiel für einen Bericht über gesperrte Prozesse finden Sie weiter unten

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

Haben Sie das neueste Service Pack und die neuesten kumulativen Updates für SQL Server 2008 R2 installiert?

— Max Vernon

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

— dan holmes

Wann hat das angefangen? Haben Sie kürzlich das Service Pack oder das kumulative Update angewendet? Ich unterstütze auch VB6 / ADO und erinnere mich, dass diese System-Procs ein- oder zweimal angezeigt wurden, aber ich glaube nicht, dass es ein Blockierungsproblem gab. Ich denke, sie sind aufgetaucht, weil sie so häufig angerufen werden. Ich bete, dass dies nicht mit SP / CU zusammenhängt, da wir immer noch auf 10.50.2500 sind und es wäre der Tod, wenn diese Dinge jeweils 3-10 Sekunden dauern würden.

— Jon Seigel

es legte eine der vielen in pastbin pastebin.com/4wUgzby9 . das geht schon seit 2 oder 3 wochen so. Wir haben eine CU schon lange nicht mehr angewendet. Es geschah Anfang 2012 zum ersten Mal, wie von der MSDN-Post datiert.

— Dan Holmes

Dies könnte nur das Symptom sein. Ich warte regelmäßig auf RESOURCE_SEMAPHORE_QUERY_COMPILE. Hier ist die beste Behandlung dieses Wartetyps, den ich gefunden habe: blogs.msdn.com/b/support_sql_france/archive/2012/02/07/…

— dan holmes

Es gibt einen ausgezeichneten Blog-Beitrag http://blogs.msdn.com/b/support_sql_france/archive/2012/02/07/sql-server-compilation-gateways-and-resource-semaphore-query-compile.aspx , der erklärt, was ist Ereignis.

SQL Server ermöglicht eine festgelegte Anzahl von Kompilierungen, die auf ihrer Komplexität basieren. Es gruppiert sie in kleine, mittlere und große. Bei umfangreichen Kompilierungen kann es immer nur eine Kompilierung geben. Nehmen wir also an, alle Ihre Procs werden als umfangreich betrachtet, und jede muss seriell kompiliert werden. Das könnte für die Sperrung verantwortlich sein.
Ich denke, dass es mehrere Ansätze für das Problem gibt - erwägen Sie mehr Ressourcen (mehr CPUs ermöglichen es, dass mehr kleine und mittlere Abfragen gleichzeitig ausgeführt werden, oder sie können den Schwellenwert für das als mittel eingestufte Problem erhöhen). Außerdem kann das Problem durch mehr Arbeitsspeicher behoben werden.

Wenn Sie wie die meisten von uns sind, ist dies möglicherweise nicht möglich. Eine andere Möglichkeit besteht darin, die ADO-Anrufe zu überprüfen und festzustellen, ob die Anzahl der Anrufe verringert oder verteilt werden kann, damit nicht alle Anrufe gleichzeitig getätigt werden. Das Verringern der Anzahl zu einem bestimmten Zeitpunkt sollte Ihre Wartezeit verringern.

Wenn dies nicht funktioniert, können Sie die Kompilierbarkeit der gespeicherten Prozesse korrigieren. Zerlegen Sie sie möglicherweise in kleinere Teile, um sie auf die kleinen oder mittleren Eimer zu reduzieren und mehr parallele Kompilierungen zu ermöglichen. Oder bestimmen Sie, warum die Procs jedes Mal neu kompiliert werden müssen. Prüfen Sie, ob sie so umgeschrieben werden können, dass sie nicht neu kompiliert werden müssen. Schließlich würde ich die Verwendung von Plan-Handbüchern in Betracht ziehen. Dadurch können die Procs vorkompiliert werden und es kann Zeit gespart werden.

Ich hoffe, das hilft

— paulbarbin
quelle

Übermäßige Kompilierungssperre für sp_procedure_params_90_rowset