Ідентичні машини (?) SQL Server 2005; запит займає 2 сек на одному, 15 хв на іншому

Середовище:

У нас є два 32-розрядні машини Windows Server 2003 R2, на яких працює SQL Server 2005. Апаратні конфігурації - це однакові сервери з процесором Xeon 5160, 4 Гб оперативної пам’яті та 13 ГБ RAID0. Прапор AWE та / 3 Гб не ввімкнено.

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

Кожен параметр встановлення SQL-сервера та рівень патча, який ми знаємо, щоб перевірити, є однаковими. Одна відмінність полягає в тому, що TEMPDB - це 400 Мб на швидкій машині, а на повільній - 1,2 ГБ. Однак в обох випадках ми не бачимо жодного розподілу TEMPDB.

Проблема:

Існує збережена процедура, яка працює на 2 секунди на одній, але на 15 хвилин на іншій. Протягом додаткових 15 хвилин дискової активності майже немає, не змінюється використання пам'яті, але одне ядро ​​CPU закріплюється на 100% весь час.

Така поведінка зберігається навіть тоді, коли резервні копії баз даних від однієї і відновлені до іншої.

Оскільки це збережена процедура, монітор активності та профілер не показують нам деталей про те, де в збереженій процедурі відбувається ця висока активність процесора.

Питання:

На що ще ми повинні дивитися?

Слідувати:

Уповільнення виникає в операторах FETCH NEXT для наступного визначення курсору:

DECLARE C CURSOR FOR
    SELECT X, Y
    FROM dbo.A
    WHERE X NOT IN (SELECT X FROM dbo.B)
    AND Z <=0
...
<snip>
...
FETCH NEXT FROM C INTO @X, @Y
FETCH NEXT FROM C INTO @X, @Y
...

Кожен з тверджень FETCH - у таблиці, що містить лише близько 1000 рядків - вимагає приблизно 7,25 хвилин. (Ні, я не знаю, чому це два підряд, потрібно запитати у розробників, але він працює правильно на обох серверах).

Мені трохи підозріло те, що "НЕ В (ВИБІР ...)", оскільки, схоже, віртуальні читання дійсно великі.

Використовуючи методологію усунення несправностей, таких як Waits and Queues, ідентифікують причину великого споживання процесора, то після виявлення вузького місця можна рекомендувати відповідні дії.

SQL Server вибирає інший план в іншому полі.

Відновлення, як правило, видаляє проблеми на основі статистики, тому я б розглядав відмінності сервера.

Деякі грубі перевірки спочатку. Не припускайте: перевірити

• Перевірте, чи налаштування SQL Server однакові в sys.configuration, наприклад, максимальна ступінь або паралелізм
• Запустіть DBCC USEROPTIONS, щоб побачити, чи будь-які параметри ANSI відрізняються під час виконання (настройки ANS можуть впливати на вибраний план)
• Перевірте журнали Windows та SQL Server, щоб перевірити, чи є проблеми

Потім стрибайте в глибокий кінець, відповідно до відповіді Ремуса.

Якщо всі інші речі рівні, напевно (відповідно до відповіді @ gbn) на кожному сервері створюється інший план виконання. Як академічну вправу було б цікаво побачити обидва плани, тому захопіть їх із кешу плану на кожному сервері та додайте їх до свого питання, якщо можливо. Тоді ми можемо виявити відмінності в планах, які спричиняють такі великі розбіжності у виконанні.

Щоб швидко виправити, подивіться на підказку USE PLAN . Це дає змогу приєднати гарний план від швидкого сервера до збереженої процедури на повільному сервері.

Редагувати: Після повторного курсору оновлення

Ще одна варіація вашого запиту, щоб спробувати те, що я не бачу згаданих в інших відповідях:

DECLARE C CURSOR FOR
    SELECT X, Y
    FROM dbo.A
    WHERE NOT EXISTS (SELECT 1 FROM dbo.B WHERE dbo.B.X = dbo.A.X)
    AND Z <=0
...
<snip>
...
FETCH NEXT FROM C INTO @X, @Y
FETCH NEXT FROM C INTO @X, @Y

Намани мене та спробуйте замінити:

DECLARE C CURSOR FOR
SELECT X, Y
FROM dbo.A
WHERE X NOT IN (SELECT X FROM dbo.B)
AND Z <=0

з цим:

DECLARE C CURSOR FOR
SELECT 
    X, 
    Y
FROM dbo.A

    LEFT OUTER JOIN dbo.B
        ON dbo.A.X = dbo.b.X

WHERE dbo.B.X IS NULL
AND Z <=0

Я не думаю, що це має проявлятись як проблема з продуктивністю в частині ВЗАЄМОГО НАЙКЛЮЧЕНОГО від частини вашого коду, але мені ще не було ін'єкції кофеїну. Спробуйте свою пропозицію, і дайте мені знати.

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

Метт

Перевірте свої індекси та оновіть всі свої статистичні дані. У мене дуже виникла проблема, і виявилося, що статистика на одній машині була хиткою.

Я двічі переживав таку саму поведінку, і я розповім, що це виправляло щоразу:

1.) Я додав підказку З RECOMPILE до збереженої процедури, оскільки кешований план був жахливим.

2.) Я змінив збережену процедуру, щоб використовувати тимчасові таблиці замість змінних таблиць.

Я сподіваюся, що будь-яка з цих допоможе. Удачі.