Надмірне блокування компіляції на sp_procedure_params_90_rowset


14

Породження цього питання MSDN: Заблокований процес-звіт: що це за ресурс очікування "ОБ'ЄКТ: 32767: 124607697: 0 [КОМПЛЕКТ]"

Я зловив ці заяви в 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?
Макс Вернон

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

Коли це почалося? Нещодавно ви застосовували пакет оновлень або накопичувальне оновлення? Я також підтримую VB6 / ADO, і я пам'ятаю, як ці системні програми з’являються один-два рази, але я не думаю, що виникла проблема блокування. Я думаю, що вони придумали, тому що їх так часто називають. Я молюся, що це не стосується СП / КС, тому що ми все ще перебуваємо в 10.50.2500, і це була б смерть, якби ці речі почали займати 3-10 секунд кожен.
Джон Сейгель

він поклав один з багатьох в pastbin pastebin.com/4wUgzby9 . це тривало близько 2 або 3 тижнів. Ми давно не застосовували МС. Це сталося на початку 2012 року вперше, як датується повідомленням MSDN.
dan holmes

1
це може бути лише симптомом. Я регулярно працюю в очікуванні на RESOURCE_SEMAPHORE_QUERY_COMPILE. Ось найкраще лікування цього типу очікування, яке я знайшов: blogs.msdn.com/b/support_sql_france/archive/2012/02/07/…
dan

Відповіді:


2

Є чудова публікація в блозі 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 і перевірити, чи можна зменшити чи поширити кількість викликів, щоб не всі дзвінки відбувалися одночасно. Скорочення кількості в будь-який момент часу повинно скоротити час очікування.

Якщо це не працює, розгляньте можливість виправити 'комбінуемость' збережених програм. Можливо, розбийте їх на більш дрібні шматки, що може зменшити їх до маленьких чи середніх відрізків та дозволить отримати більше паралельних компіляцій. Або визначте, чому потрібно кожен раз перекомпілювати документи. Подивіться, чи можна їх переписати таким чином, що їх не потрібно перекомпілювати. Нарешті, я б подумав про використання посібників із плану. Це дозволить попередньо скомпілювати програми та може заощадити деякий час.

Сподіваюся, що це допомагає

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.