Sp_procedure_params_90_rowset üzerinde aşırı derleme engelleme

Bu sorunun yeniden canlandırılması MSDN: Engellenen işlem raporu: bu waitresource nedir "NESNE: 32767: 124607697: 0 [DERLEME]"

Bu açıklamaları Profiler'de yakaladım. Hepsinin süresi 3 saniyeden fazladır. Bazıları 10'dan fazla. Engelleme etkinliği MSDN'deki bağlantıyla aynıdır .

Tüm aramalar 3 bölümlü adlandırma kullanır. Hepsi, aşağıdaki gibi göründükleri farklı bir işlemi belirtirler:

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

Bu engelleme seviyesini azaltmak için ne yapabilirim?

Şimdi aynı şeyi görüyorum:

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'

Sistemik bir şey oluyor ama başka ne yapacağımı bilmiyorum. arayan, ADO üzerinden VB6'dır. Bu çağrıları ADO yapıyor.

Engellenen bir işlem raporu örneği aşağıdadır

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

SQL Server 2008 R2 için en son hizmet paketini ve toplu güncelleştirmeleri yüklediniz mi?

— Max Vernon

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

— dan holmes

Bu ne zaman başladı? Son zamanlarda Hizmet Paketi'ni veya Toplu Güncelleştirmeyi uyguladınız mı? Ayrıca VB6 / ADO'yu destekliyorum ve bu sistem işlemlerinin bir veya iki kez geldiğini görüyorum, ancak engelleme sorunu olduğunu düşünmüyorum. Bence çok sık çağrıldıkları için ortaya çıktılar. Bunun SP / CU ile ilgili olmadığı için dua ediyorum çünkü hala 10.50.2500'deyiz ve bu şeylerin her biri 3-10 saniye sürmeye başlarsa ölüm olurdu.

— Jon Seigel

o pastbin içine birçok birini koymak pastebin.com/4wUgzby9 . bu yaklaşık 2 ya da 3 haftadır sürüyor. Uzun süredir CU uygulamıyoruz. İlk kez MSDN postasına göre 2012'nin başlarında oldu.

— dan holmes

bu sadece belirti olabilir. RESOURCE_SEMAPHORE_QUERY_COMPILE üzerinde düzenli bekleme etkinliğim var. İşte bulduğum bu waittype en iyi tedavi: blogs.msdn.com/b/support_sql_france/archive/2012/02/07/…

— dan holmes

Mükemmel bir blog yazısı var http://blogs.msdn.com/b/support_sql_france/archive/2012/02/07/sql-server-compilation-gateways-and-resource-semaphore-query-compile.aspx ne olduğunu açıklayan olay.

SQL Server karmaşıklıklarına göre belirli sayıda derlemeye izin verir. Onları küçük, orta ve büyük olarak gruplandırır. Büyük derlemeler için, aynı anda yalnızca bir tane derlenebilir, bu yüzden tüm proc'larınızın büyük olarak kabul edildiğini, ardından her birinin seri olarak derlenmesi gerektiğini varsayalım. Bu engellemeyi açıklayabilir.
Soruna birkaç yaklaşım olabileceğini düşünüyorum - daha fazla kaynak düşünün (daha fazla CPU, daha küçük ve orta düzey sorguların eşzamanlı olmasına izin verir veya ortam olarak kabul edilenin eşiğini yükseltebilir). Ayrıca, daha fazla bellek sorunu çözebilir.

Eğer çoğumuz gibiyseniz, bu mümkün olmayabilir. Başka bir seçenek de ADO çağrılarını incelemek ve tüm çağrıların aynı anda yapılmaması için çağrı sayısının azaltılabileceğini veya dağıtılabileceğini görmek olabilir. Herhangi bir zamanda sayıyı azaltmak bekleme sürenizi azaltmalıdır.

Bu işe yaramazsa, saklanan procs'un 'uygunluğunu' düzeltmeyi düşünün. Belki de onları küçük veya orta kovalara indirgeyen ve daha paralel derlemelere izin veren daha küçük parçalara ayırın. Veya proc'ların neden her seferinde yeniden derlenmesi gerektiğini belirleyin. Yeniden derlenmeleri gerekmeyecek şekilde yeniden yazılabilir olup olmadıklarına bakın. Son olarak, Plan Kılavuzlarını kullanmayı düşünürüm. Bunlar, proc'ların önceden derlenmesini sağlar ve biraz zaman kazandırabilir.

umarım yardımcı olur

— paulbarbin
kaynak