Чому запити викликають розлив tempdb?

Фон

Я переношу 160 Гбітну базу даних з MSSQL 2008 (стандартно) на сервер Win 2008 з 48 Гб оперативної пам’яті на новий сервер під керуванням MSSQL 2012 (64-розрядне веб-видання) на Win 2012 з 64 ГБ оперативної пам’яті. Старий сервер працює і перебуває під навантаженням; новий сервер не виробляється. Новий сервер має 8 темпдб-файлів (по 4 ГБ кожен).

Проблема

Під час тестування на новому сервері я бачу, що кроки в численних запитах викликають сповіщення про згадування про те, що "оператор використовував tempdb для передачі даних під час виконання". Мені вдалося уникнути сортування, переписавши деякі запити, але це не дуже вирішує проблему. Ті самі запити на старому сервері не викликають розливів. Я читав, що розливи трапляються, коли MSSQL не може завершити операцію в пам'яті і має пролити / сторінку в tempdb. Чи варто турбуватися про розливи?

Приклади

введіть тут опис зображення

Я запустив sp_updatestats в базі даних, тому статистика повинна бути актуальною, але ви зауважте, що між розрахунковою та фактичною кількістю рядків є деякі розбіжності.

Турбота про пам’ять

Я встановив максимальну настройку пам'яті для MSSQL 58 із 64 Гб. В даний час MSSQL споживає близько 35 Гб цієї пам'яті, але має робочий набір всього 682 Мб. Старий сервер (хоча у виробництві, обробці навантаження) має 44 Гб пам'яті, відданої MSSQL, з яких 43,5 Гб знаходиться у своєму робочому наборі.

введіть тут опис зображення

Я не знаю, чи розливи можуть бути пов’язані з налаштуванням пам’яті - хтось має ідеї? Наразі MSSQL має акри оперативної пам’яті для запасного, тому чому він розливається в tempdb для якихось різновидів і хеш-відповідностей?

sql-server sql-server-2012

— Енді У.
джерело

Попередження в плані виконання є новим у 2012 році. Ви перевірили, чи не проливались всі на старий сервер? Ви спостерігали за цим моніторингом?

— Мартін Сміт

@MartinSmith ах, не зрозумів, що попередження було новим. Я не спостерігав за розливом на старому сервері. Буде розслідувати це.

Злегка дотична точка, але я сиджу перед 10 таблицею приєднання, яка за замовчуванням здебільшого використовує об'єднання об'єднань з дуже хорошими оцінками рядків, що спричиняє рівень tempdb 0 розливів та час виконання 25s. Примусовий приєднання хешу (і замовлення) видаляє розливи та працює через 9 с. Мені залишається цікаво, чи спричинення різниці викликає злиття проти хешу чи розлив та чи правильно оптимізатор зважує ефект, здавалося б, відомого майбутнього розливу (адже оцінки рядків дуже хороші).

— крокусек

Новий сервер має апаратну нумеру?

— stacylaray

Тут є кілька різних питань:

З: Чому раніше запити не проливались?

Вони були, але SQL Server Management Studio не сприйняв це як явну помилку до SQL 2012. Це чудовий приклад того, чому, коли ви робите налаштування продуктивності, вам доведеться заглибитись, ніж графічний план виконання.

З: Чому запити розливаються на диск?

Оскільки SQL Server не надав їм достатньої кількості пам'яті для завершення своїх операцій. Можливо, у плані виконання занижена кількість необхідної пам’яті, або, можливо, вікно знаходиться під тиском пам’яті, або вони просто великі запити. (Пам'ятайте, що SQL Server використовує пам'ять для трьох речей - кешування сторінок із необробленими даними, кешування планів виконання та робочої області для запитів. Ця пам’ять робочої області виявляється досить маленькою.)

З: Як я можу зменшити розливи?

Записуючи зручні висловлювання T-SQL, оновлюючи статистику, розміщуючи достатньо пам’яті на сервері, будуючи правильні індекси та інтерпретуючи плани виконання, коли все не працює так, як ви очікували. Ознайомтеся з настройкою SQL Server у програмі Grant Fritchey для детальних роз'яснень усіх цих питань.

— Брент Озар
джерело