Blocage excessif de la compilation sur sp_procedure_params_90_rowset

14

Une résurgence de cette question sur MSDN: Rapport de processus bloqué: quelle est cette ressource d'attente "OBJET: 32767: 124607697: 0 [COMPILE]"

J'ai pris ces déclarations dans Profiler. Ils ont tous une durée supérieure à 3 secondes. Certains de plus de 10 ans et plus. L'activité de blocage est la même que la liaison depuis MSDN .

Les appels utilisent tous un nom en 3 parties. Tous spécifient un processus différent sous une forme semblable à celle-ci:

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

Que puis-je faire pour réduire ce niveau de blocage?

(modifier) ​​Je vois maintenant la même chose pour:

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'

Il se passe quelque chose de systémique mais je ne sais pas quoi faire d'autre. l'appelant est VB6 via ADO. C'est ADO qui fait ces appels.

Un exemple de rapport de processus bloqué est ci-dessous

 <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
la source
Le dernier Service Pack et les mises à jour cumulatives sont-ils installés pour SQL Server 2008 R2?
Max Vernon
SP2 CU4 Microsoft SQL Server 2008 R2 (SP2) - 10.50.4270.0 (X64)
dan holmes
Quand est-ce que cela a commencé? Avez-vous récemment appliqué le Service Pack ou la mise à jour cumulative? Je soutiens également VB6 / ADO et je me souviens avoir vu ces procs du système apparaître une ou deux fois, mais je ne pense pas qu'il y ait eu un problème de blocage. Je pense qu'ils sont venus parce qu'ils sont appelés si souvent. Je prie pour que ce ne soit pas lié à SP / CU car nous sommes toujours sur 10.50.2500, et ce serait la mort si ces choses commençaient à prendre 3 à 10 secondes chacune.
Jon Seigel
il a mis l'un des nombreux dans pastbin pastebin.com/4wUgzby9 . cela dure depuis environ 2 ou 3 semaines. Nous n'avons pas appliqué d'UC depuis longtemps. Cela s'est produit au début de 2012 la première fois comme daté par le message MSDN.
dan holmes
1
ce pourrait être juste le symptôme. J'ai une activité d'attente régulière sur RESOURCE_SEMAPHORE_QUERY_COMPILE. Voici le meilleur traitement de ce type d'attente que j'ai trouvé: blogs.msdn.com/b/support_sql_france/archive/2012/02/07/…
dan holmes

Réponses:

2

Il existe un excellent article de blog http://blogs.msdn.com/b/support_sql_france/archive/2012/02/07/sql-server-compilation-gateways-and-resource-semaphore-query-compile.aspx qui explique ce qui est événement.

SQL Server permet un nombre défini de compilations en fonction de leur complexité. Il les regroupe en petits, moyens et grands. Pour les grandes compilations, il ne peut y en avoir qu'une seule à la fois, alors disons que tous vos procs sont considérés comme volumineux, alors chacun doit être compilé en série. Cela pourrait expliquer le blocage.
Je pense qu'il peut y avoir plusieurs approches au problème - considérez plus de ressources (plus de processeurs permettront à plus de requêtes petites et moyennes d'être simultanées ou peuvent augmenter le seuil pour ce qui est considéré comme moyen). En outre, davantage de mémoire peut résoudre le problème.

Si vous êtes comme la plupart d'entre nous, cela pourrait ne pas être possible. Une autre option pourrait être de passer en revue les appels ADO et de voir si le nombre d'appels peut être réduit ou réparti de sorte que tous les appels ne se produisent pas en même temps. La réduction du nombre à un moment donné devrait réduire votre temps d'attente.

Si cela ne fonctionne pas, envisagez de corriger la «compilabilité» des proc stockés. Peut-être les décomposer en plus petits morceaux qui pourraient les réduire aux petits ou moyens compartiments et permettre des compilations plus parallèles. Ou déterminez pourquoi les procs doivent être recompilés à chaque fois. Voyez s'ils peuvent être réécrits de sorte qu'ils n'ont pas besoin d'être recompilés. Enfin, j'envisagerais d'utiliser des guides de plan. Ceux-ci permettront de précompiler les procs et de gagner du temps.

J'espère que cela pourra aider

paulbarbin
la source