1

Привет всем вместе! Я знаю, что эта проблема обсуждалась несколько раз, но мы сталкиваемся с безумно странной проблемой на нашем новом SQL Server 2014 с пакетом обновления 3 (SP3), и мы просто не можем отстать.

В прошлом году мы перешли с Oracle на MS SQL Server. Наша мэр БД довольно большая, ок. 800 ГБ, большие столы, система PDM. +1000 активных пользователей. 16 ядер, 192 ГБ памяти, SSD SAN Storage. ESX 6.5

Настройки в SQL Server:-> Создать автоматическую статистику включена -> оптимизировать для специальных запросов = true -> Изоляция моментальных снимков включена -> Макс. Параллель = 4 -> Порог 50 -> Асинхронизация обновлений статистики в TempDB, обычно включаемая в наших основных БД.

Как бы то ни было, у нас есть несколько запросов, которые обрабатываются крайне плохо. Все это приводит к тому, что SQl Server Optimizer создает план выполнения, считает, что все в порядке, но при выполнении он выполняет внутреннее соединение (или умножение) с миллионами вместо ожидаемых 1-2 строк. И конечно, миллионы логических прочтений. И я не могу понять, что происходит в этом. Эти заявления побежали минут тогда.

В общем, у нас уже есть 3 базы данных. Все та же версия и оборудование, Prod Test и Dev Environment. Мои тесты могут быть сделаны довольно легко. Все базы данных настроены одинаково и показывают одинаковое поведение, но по разным запросам. Скажем, иногда тестовая среда делает то же самое несколько раз за 47 секунд, а dd всего за секунду. Остальные занимают секунды в Prod, отстаивают в Test. Что, черт возьми, происходит? Я всегда повторяю операторы несколько раз, чтобы гарантировать их кэширование.

Хороший случай

Плохой случай

1с против 47с. Обе эти базы данных используют один и тот же экземпляр SQL.

Есть идеи, что здесь могло быть не так? Как исправить отдельные планы выполнения? Как может быть, что сервер sql извлекает уроки из этого крайне плохого утверждения и исправляет его при следующем запуске?

Спасибо за вашу помощь и идеи.

0