Для певних користувачів запит повільний

11

У мене є кілька запитів, викликаних із веб-програми C # .NET, які завжди для мене швидкі (я локальний адміністратор на SQL сервері), але для групи користувачів (доменна група з необхідними дозволами) запит неймовірно повільний, момент, який він вичерпує у додатку.

Що може призвести до того, що той самий запит може працювати по-різному для різних користувачів?

Більше інформації:

Запит - це вбудований SQL в код C #, а не збережена процедура
У додатку використовується автентифікація домену, і користувач, і я запускаємо запит через додаток
Здається, випуск має різні плани, і один з них був кешований так, що для різних користувачів це було різним. Щось впливає на кеш, тому що зараз запит повільний для мене через додаток і швидкий у студії управління SQL Server.

— Супергібби
джерело

2

Перевірте наступні питання . Ви можете виявити, що ви в тій же ситуації. Скажімо, спершу спробуйте цю та іншу .

— Мар’ян

3

Які типи очікування (sys.dm_os_waiting_tasks) на повільний запит (а), а також які фактичні плани виконання кожного (ваш швидкий, їх повільний)?

— Thomas Stringer

2

Погодьтеся з попередніми коментарями. Першою моєю думкою буде також нюхати параметри. Першим кроком має стати перевірка того, чи відрізняються плани.

— Мартін Сміт

4

Якщо параметри однакові (я припускаю, що це мається на увазі exact same query), це не повинно бути нюхати за параметрами (користувачі отримують поганий план для неправильних параметрів), а, скоріше, користувачі отримують різні плани для одного і того ж параметра (и). Це може бути через такі параметри, як quoted_identifierі arithabort, з якими ви можете порівнювати sys.dm_exec_sessionsдля швидкого користувача та повільного користувача, або це може бути тому, що вони мають різні схеми за замовчуванням, на які посилаються об'єкти без префікса схеми. Нюхання параметрів все ще може бути залученим (отже, для кого з них поганий план).

— Аарон Бертран

1

RE: У вашій редакції у вас така ж схема за замовчуванням, що й у інших користувачів? Ви ще захопили плани виконання повільних та швидких пробігів?

— Мартін Сміт

5

Якщо параметри однакові (я припускаю, що це мається на увазі exact same query), це не повинно бути нюхати за параметрами (користувачі отримують поганий план для неправильних параметрів), а, скоріше, користувачі отримують різні плани для одного і того ж параметра (и). Це може бути через такі параметри, як quoted_identifierі arithabort, з якими ви можете порівнювати sys.dm_exec_sessionsдля швидкого користувача та повільного користувача, або це може бути тому, що вони мають різні схеми за замовчуванням, на які посилаються об'єкти без префікса схеми. Нюхання параметрів все ще може бути залученим (отже, для кого з них поганий план).

— Аарон Бертран
джерело

3

Я бачив дві причини цього: 1, нюхання параметрів 2, налаштування з'єднання різні. Якщо ви запускаєте whoisactive , він покаже вам різні властивості з'єднання. У мене фактично є повідомлення про це в блозі, але я не очистив від нього конкретної інформації компанії. (я ще не включив свій блог);)

— rottengeek
джерело

0

Спробуйте: Вкажіть схему для кожного посилання на таблицю EXEC та таблиці. Наприклад, EXEC dbo.MyProc

Можуть виникнути конфлікти (як пропонує Мартін Сміт - «та сама схема за замовчуванням»?) Або перекомпілювати

— Кіп Брайан
джерело

0

Здається, це помилка в SQL Server. Я відчуваю цю помилку з SQL Server 2008. Я не перевіряв нові версії. Я можу увійти як адміністратор і запустити цей запит і отримати відповідь за 0 секунд:

select ROUTINE_NAME from INFORMATION_SCHEMA.ROUTINES ORDER BY ROUTINE_NAME

Потім я входжу як користувач з меншою кількістю дозволів, запускаю такий самий запит, і відповідь займає 45 секунд.

Це постійно і знову. Якщо я відхиляюсь назад і назад між двома вікнами запитів, одним для адміністратора і одним для не адміністратора, для не адміністратора завжди потрібно близько 45 секунд, а адміністратору потрібно 0 секунд.

— Роб Крафт
джерело

Як було сказано в коментарях до питання - чи обидва користувачі мають однакову базу даних за замовчуванням, і чи виконуються запити в одній базі даних? І чи можете ви вказати на якусь документацію, яка стверджує, що це помилка, чи це ваша думка? Не кажучи, що ви помиляєтесь, просто шукаєте щось поза анекдотом.

— RDFozz

Проблема, яку ви виявили у своїй відповіді, схоже, не повторюється на SQL Server 2008. select ROUTINE_NAME from INFORMATION_SCHEMA.ROUTINES ORDER BY ROUTINE_NAMEпослідовно негайно повертає дані для входу, який не має SA, який взагалі не надає прав на експліцитність.

— Макс Вернон