лучший бесплатный инструмент для настройки запросов — это SolarWinds Plan Explorer
В базе данных tempdb всегда должно быть несколько файлов данных. К сожалению, конфигурация по умолчанию, которая создается во время установки SQL Server, неоптимальна, особенно в старых версиях
базу данных tempdb стоит размещать на самом быстром диске. В общем случае этому диску не требуется резервное копирование или другие меры предохранения данных: tempdb создается заново при каждом запуске SQL Server, так что для нее вполне подойдет локальный SSD-накопитель или облачное хранилище. Но помните, что если база данных tempdb будет недоступна, то SQL Server перестанет работать
Стоит также отметить, что, начиная с SQL Server 2016 SP1, многие функции, ранее предназначенные только для Enterprise Edition, появились и в более дешевых версиях. Некоторые из них — например, сжатие данных — позволяют SQL Server кэшировать больше данных в буферном пуле, что повышает производительность
Каждый раз, когда SQL Server увеличивает размер файлов или журналов транзакций — будь то автоматически или в рамках команды ALTER DATABASE, — он заполняет свежевыделенную часть файла нулями. Этот процесс блокирует все сеансы, которые пытаются записывать в соответствующий файл, а в случае журнала транзакций в нем прекращается создание записей. Также при этом может произойти всплеск нагрузки на систему ввода/вывода.
Для файлов журналов транзакций это поведение нельзя изменить: SQL Server всегда заполняет их нулями. Однако для файлов данных его можно отключить, если активировать мгновенную инициализацию файлов (IFI, instant file initialization). Она ускоряет разрастание файла данных и сокращает время создания или восстановления баз данных.
К примеру, я перерабатываю запросы, когда вижу большую загруженность диска, блокировки или высокую нагрузку ЦП. Но если данные кэшируются в буферном пуле, а нагрузка ЦП приемлема, то я предпочитаю сперва сосредоточиться на других очагах проблем.
К примеру, я перерабатываю запросы, когда вижу большую загруженность диска, блокировки или высокую нагрузку ЦП. Но если данные кэшируются в буферном пуле, а нагрузка ЦП приемлема, то я предпочитаю сперва сосредоточиться на других очагах проблем.
Теоретически все выглядит очень просто, но, к сожалению, жизнь устроена сложнее. Многие проблемы тесно связаны друг с другом, отчего становится труднее обнаружить настоящие причины узких мест. Вот распространенный пример: чрезвычайно долгие ожидания диска часто вызваны не плохой производительностью ввода/вывода, а плохо оптимизированными запросами, которые постоянно очищают буферный пул и перегружают дисковую подсистему.
На рис. 2.5 показаны примеры высокоуровневых зависимостей, с которыми вы можете столкнуться. Эта схема не охватывает всех возможных ситуаций, но иллюстрирует, как важен широкий взгляд на систему при устранении неполадок.