Автоматическое обновление статистики не всегда аннулирует кешированные планы выполнения

Автор: Brent Ozar, Automatic Stats Updates Don’t Always Invalidate Cached Plans

Обычно, когда SQL Server обновляет статистику по объекту, он также аннулирует кешированные планы выполнения, которые полагаются на эту статистику. Именно поэтому вы видите повторную компиляцию после обновления статистики: SQL Server знает, что статистика изменилась, и это хороший момент для построения новых планов выполнения с учётом изменений в данных.

Однако обновление статистики, созданной системой, не обязательно приводит к повторной компиляции планов.

Это действительно странный крайний случай, и вы, вероятно, никогда с ним не столкнётесь, но я сталкиваюсь с ним на каждом занятии, которое провожу. Я каждый раз мимоходом упоминаю об этом в классе и даже не обращаю на это особого внимания. Однако недавно студент спросил меня: «Это где-нибудь задокументировано?», и я подумал, э-э, может быть, но я не уверен, так что лучше задокументировать это здесь, в старом добром блоге.

Сериализация операций удаления из кластерных columnstore-индексов

Автор: Aaron Bertrand , Serializing Deletes From Clustered Columnstore Indexes

На Stack Overflow у нас есть несколько таблиц с кластерными columnstore-индексами, которые отлично работают для большей части нашей нагрузки. Но мы недавно столкнулись с ситуацией, когда «идеальные штормы» — несколько процессов, пытающихся одновременно удалить данные из одного columnstore-индекса — перегружали процессор, поскольку они все запускались с высокой степенью параллелизма и боролись за завершение своей операции.

А может, вам вообще не стоит использовать кластеризацию или группы доступности

Автор: Brent Ozar, Maybe You Shouldn’t Even Be Using Clustering or AGs.

Сандра Делани написала хорошо продуманную запись в блоге под названием Должен ли SQL Server DBA разбираться в Windows Server Failover Clustering? У неё около 20 лет опыта работы администратором баз данных, и она работает консультантом в Straight Path (компании, которую я уважаю). Вы, вероятно, можете догадаться, исходя из её опыта, что да, она считает, что вы должны знать, как настроить, сконфигурировать и устранять неполадки в кластерах Windows. Это хорошая статья, и вам стоит её прочитать.

Но... я не согласен.

Вы задумывались о том, чтобы не использовать высокую доступность SQL Server?

Автор: Chrissy LeMaire, Have You Considered Not Using SQL Server High Availability?

Когда кто-то спрашивает об архитектуре SQL Server, рефлекторным ответом обычно становится «Высокая доступность» (High Availability, HA), будто это требование, а не выбор. Но после 20 лет управления средами SQL Server я обнаружила, что высокая доступность часто создаёт больше проблем, чем решает, особенно в организациях определённого типа.

Миф: Зеркалирование баз данных мгновенно обнаруживает сбои

Автор: Paul Randal, A SQL Server DBA myth a day: (10/30) database mirroring detects failures immediately

Database Mirroring мгновенно обнаруживает сбои

ЛОЖЬ

Маркетинговый ажиотаж вокруг зеркалирования баз данных утверждает, что оно обеспечивает мгновенное обнаружение сбоев и мгновенный переход на резервный сервер.

Это не так. Скорость обнаружения сбоя зависит, среди прочего, от того, что именно вышло из строя.

Миф: Сжатие файла данных не влияет на производительность

Автор: Paul Randal, A SQL Server DBA myth a day: (9/30) data file shrink does not affect performance

Сжатие файла данных не влияет на производительность.

Ха-ха-ха-ха-ха-ха-ха-ха-ха-ха-ха-ха-ха! <фыркает>

<вытирает слёзы с глаз, пытается сфокусироваться на экране ноутбука, убирает слюну с клавиатуры>

ЛОЖЬ

Единственный случай, когда сжатие файла данных не повлияет на производительность, — это если вы используете параметр WITH TRUNCATEONLY и в конце сжимаемого файла есть свободное пространство.

Единороги, радуги и операции с индексами в режиме ONLINE

Автор: Paul Randal, A SQL Server DBA myth a day: (8/30) unicorns, rainbows, and online index operations

Операции с индексами в режиме ONLINE не устанавливают блокировок

ЛОЖЬ

Операции с индексами в режиме ONLINE — это не сплошные единороги и радуги (об информации по единорогам и радугам см. http://whiteboardunicorns.com/ — безопасно для рабочего просмотра).

Миф: Несколько зеркал и задержка применения журналов при доставке журналов

Автор: Paul Randal, A SQL Server DBA myth a day: (7/30) multiple mirrors and log shipping load delays

У базы данных может быть несколько зеркал

ЛОЖЬ

Этот миф довольно однозначен — зеркальное отображение баз данных позволяет создавать только одно зеркало для каждой основной базы данных. Если вам нужно несколько копий основной базы данных, рассмотрите возможность использования доставки журналов. Вы можете иметь столько вторичных серверов доставки журналов, сколько вам нужно.

Ещё одна классная особенность доставки журналов заключается в том, что для одного из вторичных серверов можно установить задержку применения, скажем, в 8 часов. Это означает, что резервные копии журналов, сделанные на основном сервере (не правда ли забавно, что в разных технологиях используется разная терминология:

• зеркалирование баз данных: основной — зеркальный
• доставка журналов: основной — вторичный
• репликация: издатель — подписчик

Ладно… эта вводная часть как-то сама по себе развилась…) не будут восстановлены на вторичном сервере доставки журналов, пока не пройдёт 8 часов. Если кто-то удалит таблицу в рабочей среде, она почти сразу же исчезнет и в зеркале (с какой-то задержкой, зависящей от состояния очередей SEND и WAIT в тот момент — но вы не можете остановить этот процесс), а вот на вторичном сервере доставки журналов с задержкой применения таблица останется нетронутой.

Кстати, команда SQLCAT написала очень хорошую статью, разоблачающую миф (который происходит из документации Books Online) о том, что можно зеркалировать только 10 баз данных на один экземпляр — см. Mirroring a Large Number of Databases in a Single SQL Server Instance. Также взгляните на статью базы знаний, которую я написал для CSS, где обсуждается то же самое: KB 2001270 Предварительные условия, ограничения и рекомендации по зеркальному отображению базы данных.

Крутые возможности в SQL Server, которые я упустил… DATE_BUCKET

Автор: Louis Davidson, Cool features in SQL Server I missed…DATE_BUCKET

Я продолжаю находить или слышать о весьма полезных функциях, которые я просто упустил. Планирую перечитать все записи о «новых возможностях» для SQL Server (ну, по крайней мере, разделы Transact-SQL!) и посмотреть, что ещё я пропустил, а также другие функции, которые я использовал недостаточно, но которые кажутся полезными.

Узнал я об этой функции несколько недель назад из публикации Джована Поповича в LinkedIn.

И я мгновенно понял, что он имел в виду, говоря о том, насколько полезна будет функция DATE_BUCKET (появившаяся в SQL Server 2022)!

Используя эту функцию, вы можете легко группировать данные в различные временные интервалы, такие как год, месяц, день (что, конечно, достаточно стандартно), но также и в интервалы вроде 2 дней, 6,4 недель и т.д. Я не считаю, что это должно заставить вас отказаться от измерения дат в вашем хранилище данных, но она великолепна, когда вы просто исследуете данные и хотите легко поэкспериментировать с разными интервалами.

Миф: Триггеры DDL являются триггерами INSTEAD OF

Автор: Paul Randal, A SQL Server DBA myth a day: (4/30) DDL triggers are INSTEAD OF triggers

Триггеры DDL (введённые в SQL Server 2005) являются триггерами INSTEAD OF

ЛОЖЬ

Триггеры DDL реализованы как триггеры AFTER, что означает, что операция сначала выполняется, а затем перехватывается триггером (и при необходимости откатывается, если в теле триггера есть оператор ROLLBACK).

Это означает, что они не столь легковесны, как можно было бы предположить.

Миф: Мгновенной инициализацией файлов можно управлять изнутри SQL Server

Автор: Paul Randal, A SQL Server DBA myth a day: (3/30) instant file initialization can be controlled from within SQL Server

Мгновенную инициализацию файлов можно a) включить и b) выключить изнутри SQL Server

a) ЛОЖЬ и b) ИСТИНА, соответственно

Мгновенная инициализация файлов — малоизвестная возможность SQL Server, начиная с версии 2005, которая позволяет файлам данных (только им, а не файлам журнала) пропустить обычный процесс инициализации нулями. Это прекрасный способ сократить время простоя при аварии, когда необходимо восстановить базу данных с нуля — поскольку вновь создаваемые файлы данных не тратят (потенциально) часы на заполнение нулями, прежде чем начнется фактическая операция восстановления.

Я уже писал в блоге о заблуждениях, касающихся мгновенной инициализации (см. Заблуждения вокруг мгновенной инициализации файлов), но там не рассматривался этот аспект функции.

Вы не можете включить её изнутри SQL Server. SQL Server выполняет однократную проверку при запуске, обладает ли учетная запись службы SQL Server соответствующим разрешением Windows (Perform Volume Maintenance Tasks, также известным как SE_MANAGE_VOLUME_NAME), и затем мгновенная инициализация файлов включается для этого экземпляра. В отличной статье блога Кимберли Instant Initialization – What, Why and How? есть подробности о том, как включить эту функцию (и многое другое).

Вы можете проверить изнутри SQL Server, работает ли она. Включите флаг трассировки 3004 (и 3605, чтобы вывести результат в журнал ошибок), а затем создайте базу данных. В журнале ошибок вы увидите сообщения, указывающие на то, что файл журнала инициализируется нулями. Если мгновенная инициализация файлов НЕ включена, вы также увидите сообщения об инициализации нулями файла данных.

Вы можете отключить мгновенную инициализацию файлов изнутри SQL Server, хоть и только временно. Включение флага трассировки 1806 отключит мгновенную инициализацию файлов, пока этот флаг активен. Чтобы отключить её навсегда, потребуется удалить разрешение безопасности у учетной записи службы SQL Server.

Эти два флага трассировки  были впервые задокументированы в блоге SQL Server Premier Field Engineer специалистами MCM Синди Гросс и Дензилом Рибейро — см. их статью Как и зачем включать мгновенную инициализацию файлов.

Если у вас есть возможность — включите эту функцию!

Миф: DBCC CHECKDB вызывает блокировки

Автор: Paul Randal, A SQL Server DBA myth a day: (2/30) DBCC CHECKDB causes blocking

DBCC CHECKDB вызывает блокировки, потому что устанавливает их по умолчанию 

ЛОЖЬ

Когда-то давно, в версии 7.0 и ранее DBCC CHECKDB (и остальные команды проверки согласованности) представляли собой неприятную мешанину вложенного циклического кода на C, который устанавливал блокировки таблиц (а вложенные циклы делали алгоритм по сути порядка n-квадрат - это если среди вас есть программисты). Это было нехорошо, и поэтому…