Миф №23: эскалация блокировок происходит сначала с уровня строки на уровень страницы, а затем с уровня страницы на уровень таблицы.
ЛОЖЬ
Нет, никогда. Эскалация блокировок в SQL Server всегда переходит непосредственно к блокировке таблицы.
Показаны сообщения с ярлыком Configuration. Показать все сообщения
Показаны сообщения с ярлыком Configuration. Показать все сообщения
10.4.26
Миф о том, что эскалация блокировок происходит сначала с уровня строки на уровень страницы, а затем с уровня страницы на уровень таблицы
9.4.26
Углублённая диагностика и информативные панели мониторинга
Большинство инструментов мониторинга баз данных созданы не для той аудитории. Панели мониторинга предназначены для успокоения руководителей, оповещения откалиброваны для удовлетворения контрольных списков соответствия требованиям, а отчёты отформатированы для ежеквартальных обзоров. Ничто из этого не полезно в 10 часов вечера, когда приложение возвращает тайм-ауты, а дежурный разработчик просит обновлений каждые три минуты. То, что нужно администратору баз данных в этот момент, — это инструмент, который уже имеет контекст. Не сырые данные, которые нужно собирать в условиях стресса. Не список превышенных порогов. А реальный контекст: что выполнялось, что находилось в ожидании, что изменилось и как это сравнивается с тем, что является нормальным для данного конкретного экземпляра в это время суток. Это более сложная задача, чем кажется, и большинство инструментов мониторинга её не решают. Давайте поговорим об углублённой диагностике и информативных панелях мониторинга.
7.4.26
Миф о том, что регулятор ресурсов позволяет управлять активностью ввода-вывода
Регулятор ресурсов (Resource Governor) — это замечательная возможность с SQL Server 2008, но существуют некоторые заблуждения относительно того, что он может делать…
2.4.26
SQL Server Deprecated Features: 25-летняя хронология и руководство по обеспечению совместимости с будущими версиями
За последние 25 лет Microsoft SQL Server значительно эволюционировал, внедряя мощные инструменты и функциональные возможности, одновременно отказываясь от других. В рамках этой эволюции многие возможности были помечены как устаревшие — они по-прежнему работают в текущих версиях, но планируются к удалению в будущих выпусках. Понимание этих устаревших возможностей имеет решающее значение для администраторов баз данных и разработчиков, чтобы обеспечить долгосрочную совместимость и избежать потенциальных сбоев в своих системах.
Объявление возможности устаревшей служит сигналом от Microsoft о необходимости перехода от устаревших или менее эффективных технологий к современным альтернативам. От изменений синтаксиса до целых компонентов — в каждой версии SQL Server появлялись возможности, которые выходили из употребления по мере адаптации платформы к новым отраслевым стандартам и потребностям пользователей. Этот непрерывный процесс помогает поддерживать надёжную, безопасную и высокопроизводительную среду баз данных, но требует проактивного планирования, чтобы избежать зависимости от инструментов, которые вскоре станут неактуальными.
В этой статье мы рассмотрим подробную хронологию устаревших возможностей в различных версиях SQL Server, начиная с SQL Server 2000 и заканчивая последними выпусками. Изучив эти изменения, вы сможете лучше подготовиться к обновлениям, реорганизовать устаревший код и принять рекомендуемые практики, чтобы сохранить вашу инфраструктуру баз данных готовой к будущему. Давайте углубимся в ключевые возможности, которые были исключены за эти годы, и разберёмся с их заменами.
31.3.26
Мифы о контрольных суммах страниц
Несколько человек предложили разобрать некоторые мифы, связанные с контрольными суммами страниц, так что сегодня у нас очередной экстравагантный «многомифобойный» день! Ну, по крайней мере, я в восторге :-)
Я подробно описывал контрольные суммы страниц в статье блога How to tell if the IO subsystem is causing corruptions?
26.3.26
Десять лучших практик настройки производительности SQL Server
Существует огромное количество лучших практик по настройке производительности SQL Server — я мог бы легко написать целую книгу на эту тему, особенно учитывая множество различных настроек базы данных, настроек сервера, практик написания кода, типов ожидания и так далее, которые могут влиять на производительность. Для этой статьи я решил немного отступить от списка конкретных деталей и дать несколько общих рекомендаций о том, как подходить к настройке производительности, чтобы максимизировать усилия и минимизировать отвлекающие факторы.
25.3.26
Прекратите дефрагментировать индексы! Доступна для предварительного изучения функция Auto Index Compaction
В предыдущей статье мы проанализировали улучшения производительности в SQL Server 2025 CU3 и обнаружили скрытые оптимизации, о которых никто не говорит.
👉 Если вы пропустили, посмотрите здесь:
SQL Server 2025 CU3 – Скрытое улучшение производительности, о котором никто не говорит
В этой же статье мы представим удивительную новость в мире SQL Server, которую я называю функцией автоматического уплотнения индексов (Auto Index Compaction).
15.3.26
Всё ещё о Batch Mode… Параметры совместимости и опции запросов (Часть 6)
Назад к серии: Как указать Batch Mode для Rowstore, если его нет в плане (Часть 5)
Мы всё ещё говорим о пакетном режиме, потому что понимание того, когда он работает, так же важно, как и знание того, как его принудительно включить.
Сегодня мы углубимся: мы рассмотрим уровни совместимости, выделение памяти, оценку количества строк и флаги трассировки.
Приятного чтения, и пусть ваш CPU остаётся холодным при тяжёлых агрегатах!
6.3.26
Анатомия задания очистки CDC в SQL Server (и как поддерживать его в рабочем состоянии)
Система отслеживания изменений данных (Change Data Capture, CDC) замечательна, пока не перестаёт ей быть. При высокой интенсивности изменений задание очистки CDC может начать отставать. Когда это происходит, таблицы изменений (Change Tables, CT) быстро разрастаются, а задание очистки может блокировать задание записи (capture job), что, в свою очередь, может задерживать или останавливать нижестоящие системы-потребители.
Эта статья объясняет: как быстро оценить рост таблиц изменений, как задание очистки на самом деле удаляет строки и три основных «рычага» настройки для поддержания стабильности CDC.
4.3.26
Устранение ошибок включения CDC — Часть 2
В предыдущей статье блога я рассказывал о сбое CDC из-за отключённого пользователя guest в MSDB. Тогда же мой заказчик столкнулся и с другой проблемой:
Msg 22832, Level 16, State 1, Procedure sp_cdc_enable_table_internal, Line 622 Could not update the metadata that indicates table [dbo].[Table_Name] is enabledfor Change Data Capture. The failure occurred when executing the command'insert into [cdc].[change_tables]'. The error returned was 515:'Cannot insert the value NULL into column 'has_drop_pending',table 'LLCProduction.cdc.change_tables'; column does not allow nulls.INSERT fails.'. Use the action and error to determine the cause of the failureand resubmit the request.
Они обошли её, включив параметр ANSI_NULL_DEFAULT на уровне базы данных:
ALTER DATABASE DB_Name SET ANSI_NULL_DEFAULT ON;После этого CDC включился успешно.
Вопрос в том, какова первопричина этой проблемы и как мы можем избежать её в будущем?
3.3.26
Устранение ошибок включения CDC — Часть 1
Недавно мой заказчик столкнулся с двумя интересными проблемами, связанными с CDC, и сегодня я хотел бы поделиться процессом их диагностики и первопричинами.
Проблема:
В выходные заказчик попытался перенести некоторые изменения на производственный сервер. При попытке включить CDC на производственном сервере сначала возникла ошибка безопасности:
#1: Ошибка безопасности:
Msg 22832, Level 16, State 1, Procedure sp_cdc_enable_table_internal, Line 622 Could not update the metadata that indicates table [dbo].[Table_Name] is enabled forChange Data Capture. The failure occurred when executing the command'[sys].[sp_cdc_add_job] @job_type = N'capture''.The error returned was 916: 'The server principal "S-1-9-3-1293060401-1231192665-3834407059-1208013724."is not able to access the database "msdb" under the current security context.'.Use the action and error to determine the cause of the failure and resubmit the request
25.2.26
Как оптимизировать переключение реплик групп доступности SQL Server
Мы часто выполняем плановые переключения реплик в группах доступности SQL Server для обслуживания, установки исправлений, обновлений и даже ротации оборудования. Обычно наши переключения выполняются быстро, но иногда они занимают больше времени — и не всегда интуитивно понятно почему, поскольку нет очевидной связи со временем суток, размером базы данных или объёмом транзакций.
Сокращение даже нескольких секунд из этого процесса может улучшить взаимодействие с приложением и конечным пользователем; это также может значительно снизить количество оповещений или, по крайней мере, сократить время, в течение которого оповещения должны быть отключены. Существует множество материалов о том, как правильно выполнять переключения в AG (без потери данных), но гораздо меньше тех, которые сосредоточены на сокращении окна прерывания доступности. Разница обычно заключается в некоторой комбинации объёма повторного выполнения (redo), поведения контрольных точек, открытых транзакций и готовности вторичной реплики.
Я хотел поделиться некоторыми методами, которые я использую, чтобы сделать плановые переключения более быстрыми и предсказуемыми. Некоторые из этих методов хорошо документированы, другие выпестованы из реальных шаблонов, которые я наблюдал во многих средах с SQL Server. Я расскажу о том, что я делаю до, во время и после переключения первичной реплики, чтобы минимизировать прерывания работы пользователей и повысить вероятность того, что они не заметят, что что-то произошло.
20.2.26
Журнал транзакций SQL Server, Часть 2: Архитектура журналирования
В первой части этой серии я познакомил вас с основной терминологией, касающейся журналирования, поэтому рекомендую прочитать её, прежде чем продолжать чтение этой части. Всё остальное, что я расскажу в серии, требует знания некоторой архитектуры журнала транзакций, так что именно это я и собираюсь обсудить на этот раз. Даже если вы не собираетесь следить за серией, некоторые концепции, которые я объясню ниже, полезно знать для повседневных задач, с которыми сталкиваются в своей работе администраторы баз данных.
15.2.26
Разнообразные мифы о контрольных суммах страниц
Несколько человек предложили некоторые мифы о контрольных суммах страниц, так что сегодня ещё одно мульти-разоблачительное представление! Ну, по крайней мере, я взволнован :-)
Я подробно описал контрольные суммы страниц в посте в блоге «How to tell if the IO subsystem is causing corruptions?»
14.2.26
Контрольная точка записывает только страницы из зафиксированных транзакций?
Контрольная точка записывает только страницы из зафиксированных транзакций
ЛОЖЬ
Этот миф существует целую вечность и связан с непониманием того, как работает общая система журналирования и восстановления. Контрольная точка всегда записывает все страницы, которые были изменены (так называемые «грязные» страницы) с момента последней контрольной точки или с момента считывания страницы с диска. Не имеет значения, зафиксирована транзакция, изменившая страницу, или нет – страница записывается на диск в любом случае. Единственным исключением является tempdb, где страницы данных не записываются на диск в рамках контрольной точки.
13.2.26
Очистка журнала обнуляет записи журнала?
Очистка журнала обнуляет записи журнала.
ЛОЖЬ
Журнал транзакций всегда инициализируется нулями при первом создании, ручном расширении или автоматическом расширении. Не путайте это с процессом очистки (clearing) журнала во время обычных операций. Очистка просто означает, что один или несколько VLF (виртуальных файлов журнала) помечаются как неактивные и доступные для перезаписи. Когда происходит очистка журнала, ничего не стирается и не перезаписывается. «Очистка журнала» — это очень сбивающее с толку неправильное название. Оно означает ровно то же самое, что и «усечение журнала», что является ещё одним неудачным термином, потому что размер журнала при этом вообще не меняется.
12.2.26
Можно ли использовать динамические административные представления в режиме совместимости 80 (MSSQL 2000)?
Нельзя выполнять динамические административные представления (DMV) в режиме совместимости 80.
ЛОЖЬ
Для начала, существует большая путаница относительно того, что означает режим совместимости. Означает ли это, что базу данных можно восстановить/присоединить к серверу SQL Server 2000? Нет. Это означает, что некоторые аспекты синтаксического разбора T-SQL, поведения планов запросов, подсказки и некоторые другие вещи ведут себя так же, как в SQL Server 2000 (или 2005, если вы устанавливаете значение 90 на экземпляре 2008).
11.2.26
У tempdb всегда должно быть по одному файлу данных на ядро процессора?
Этот миф я слышу снова, и снова, и снова…
У tempdb всегда должно быть по одному файлу данных на каждое ядро процессора.
ЛОЖЬ
Это один из самых разочаровывающих мифов, потому что существует так много «официальной» информации от Microsoft и других записей в блогах, которые увековечивают этот миф.
9.2.26
Оптимизация базы данных для нерегламентированных запросов
SQL Server предоставляет параметр оптимизации для нерегламентированных рабочих нагрузок (ad-hoc workloads), действующий в рамках всего сервера, который используется для уменьшения объёма памяти, занимаемого одиночными ad-hoc пакетами и связанными с ними планами. Когда этот параметр включён на уровне экземпляра SQL Server, при первом выполнении пакета ad-hoc для любой базы данных на экземпляре сохраняется «заглушка» скомпилированного плана с уменьшенным потреблением памяти. Эта опция сервера OPTIMIZE_FOR_AD_HOC_WORKLOADS доступна начиная с SQL Server 2019, и имет область действия на уровне базы данных.
8.2.26
Большое количество планов выполнения для одного запроса
Я работал над запросом в службу поддержки, в котором наш клиент обнаружил большое количество планов выполнения, потребляющих ресурсы в кэше планов для одного запроса. Я хотел бы поделиться своими выводами и опытом по предотвращению подобных проблем.
Подписаться на:
Комментарии (Atom)