Чрезмерная блокировка компиляции в sp_procedure_params_90

Возникновение этого вопроса на MSDN: Blocked-process-report: что это за ресурс ожидания "OBJECT: 32767: 124607697: 0 [COMPILE]"

Я поймал эти заявления в Profiler. Все они имеют продолжительность более 3 секунд. Некоторые старше 10 лет. Активность блокировки такая же, как и у ссылки из MSDN .

Все звонки используют 3 части именования. Все они указывают другой процесс в форме, они выглядят следующим образом:

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

Что я могу сделать, чтобы уменьшить этот уровень блокировки?

(изменить) Теперь я вижу то же самое для:

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'

Что-то происходит системно, но я не знаю, что еще делать. звонящий VB6 через ADO. Это ADO делает эти звонки.

Пример отчета о заблокированном процессе ниже

 <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

— Дэн Холмс
источник

У вас установлены самые последние пакеты обновления и накопительные обновления для SQL Server 2008 R2?

— Макс Вернон

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

— дан холмс

Когда это начало происходить? Вы недавно применяли пакет обновления или накопительное обновление? Я также поддерживаю VB6 / ADO и вспоминаю, как эти системные процы появлялись один или два раза, но я не думаю, что была проблема блокировки. Я думаю, что они пришли, потому что их так часто называют. Я молюсь, чтобы это не было связано с SP / CU, потому что мы все еще на 10.50.2500, и было бы смерть, если бы эти вещи начали занимать 3-10 секунд каждый.

— Джон Зигель

это поместило один из многих в pastbin pastebin.com/4wUgzby9 . это продолжалось около 2 или 3 недель. Мы давно не применяли ТС. Произошло это в начале 2012 года впервые по сообщению MSDN.

— Дэн Холмс

это может быть только симптом. Я регулярно ожидаю RESOURCE_SEMAPHORE_QUERY_COMPILE. Вот лучшее лечение этого waittype я нашел: blogs.msdn.com/b/support_sql_france/archive/2012/02/07/...

— дан холмс

Существует отличное сообщение в блоге http://blogs.msdn.com/b/support_sql_france/archive/2012/02/07/sql-server-compilation-gateways-and-resource-semaphore-query-compile.aspx, в котором объясняется, что происходит.

SQL Server допускает заданное количество компиляций в зависимости от их сложности. Он группирует их на маленькие, средние и большие. Для больших компиляций может быть только один скомпилированный за раз, так что, скажем, все ваши процессы считаются большими, тогда каждый должен компилироваться последовательно. Это может объяснить блокировку.
Я думаю, что может быть несколько подходов к проблеме - рассмотреть больше ресурсов (большее количество процессоров позволит выполнять больше мелких и средних запросов или может повысить порог для того, что считается средним). Кроме того, больше памяти может решить проблему.

Если вы похожи на большинство из нас, это может быть невозможно. Другой вариант может состоять в том, чтобы просмотреть вызовы ADO и посмотреть, можно ли уменьшить или распределить количество вызовов, чтобы не все вызовы происходили одновременно. Сокращение числа в любой момент времени должно сократить время ожидания.

Если это не сработает, попробуйте исправить «скомпилируемость» хранимых процедур. Возможно, разбейте их на более мелкие фрагменты, которые могут уменьшить их до небольших или средних сегментов и разрешить больше параллельных компиляций. Или определите, почему нужно каждый раз перекомпилировать процы. Посмотрите, можно ли их переписать так, чтобы их не нужно было перекомпилировать. Наконец, я хотел бы рассмотреть возможность использования Руководства по плану. Это позволит предварительно скомпилировать процесс и сэкономить время.

надеюсь, это поможет

— paulbarbin
источник

Чрезмерная блокировка компиляции в sp_procedure_params_90_rowset