Показаны сообщения с ярлыком Configuration. Показать все сообщения
Показаны сообщения с ярлыком Configuration. Показать все сообщения

30.4.26

Проверка нагрузки на память за 45 секунд

Автор: Luca Biondi, Check Memory Pressure in 45 Seconds. The "45 Seconds DBA Series" – What Real DBAs Check First | Part 4

В этой статье я покажу вам свой диагностический план из 5 шагов для выявления губительной нагрузки на память SQL Server менее чем за 45 секунд. Перестаньте гадать и начните точно определять, что именно лишает ваш буферный пул памяти, прежде чем производительность полностью деградирует!

В двух словах

  • ✔️ Уровень ОС: Проверьте доступную физическую память – внешнее давление опасно 🛠️
  • ✔️ PLE (Page Life Expectancy – ожидаемая продолжительность жизни страницы): Высокое значение – это хорошо, но внезапные падения означают активное перемещение данных в памяти (churn) 📉
  • ✔️ Распределения памяти (Memory Grants): Долгие ожидания и огромные объёмы выделенной памяти – чистые убийцы параллелизма ⏳
  • ✔️ Менеджеры памяти (Memory Clerks): Найдите, какой именно кэш (CACHESTORE, USERSTORE) ворует вашу оперативную память 🧠

29.4.26

Автоматическое исправление планов (Automatic Plan Correction) в SQL Server

Автор: theSQLSith, Query plan regressions got you down? Here's how can Automatic Plan Correction turns it around

Регрессии планов запросов донимают? Вот как автоматическое исправление планов (Automatic Plan Correction) может всё изменить.

Автоматическое исправление планов (Automatic Plan Correction, APC) — это одна из тех функций, о которой я довольно часто беседую с заказчиками, инженерами поддержки и широким сообществом SQL. Она входит в семейство автоматической настройки (Automatic Tuning) и незаметно выполняет свою работу, начиная с SQL Server 2017, обнаруживая регрессии планов запросов и автоматически принудительно применяя ранее известный хороший план для восстановления производительности. Но один из частых вопросов звучит так: как же APC на самом деле решает, произошла ли регрессия? И насколько оно уверено в этом решении?

Начиная с SQL Server 2022 CU4 и продолжая в SQL Server 2025, мы внесли значительные улучшения в статистическую модель, которую APC использует для обнаружения регрессий. В этой статье мы рассмотрим, что изменилось, почему это важно и как вы можете этим воспользоваться.

28.4.26

Проверка узких мест ввода-вывода за 45 секунд

Автор: Luca Biondi, Check IO Bottlenecks in 45 Seconds. The "45 Seconds DBA Series" – What Real DBAs Check First | Part 5

В этой статье я покажу вам, как выявить узкие места ввода-вывода SQL Server менее чем за 45 секунд с помощью специализированных динамических административных представлений (DMV). Перестаньте гадать между задержкой и пропускной способностью и начните исправлять реальные очереди к системе хранения!

24.4.26

Работают ли многоядерные процессоры лучше, чем одноядерные?

Автор: Paul Randal, Search Engine Q&A #5: Do multi-core CPUs perform better than single-core CPUs?

Вот интересный вопрос, который прислал мне мой друг Стив Джонс из SQL Server Central — будет ли один процессор с двумя ядрами работать лучше, чем два одноядерных процессора? Оба варианта имеют два вычислительных ядра, но аппаратная архитектура разная — какой из них обеспечит лучшую производительность SQL Server? Что ж, однозначного ответа нет — всё зависит от многих факторов! Я обсуждал эту тему с Джеромом Халмансом, бывшим коллегой по команде Storage Engine в SQL Server, и с его разрешения я основываю эту статью на нашем обсуждении.

23.4.26

Проверка состояния TempDB за 45 секунд

Автор: Luca Biondi, SQL Server Parameter Sniffing: The Bug That Isn’t a Bug (But Breaks Everything)

В этой статье я покажу вам, как обнаружить нагрузку на TempDB менее чем за 45 секунд и, что ещё важнее, — как правильно её интерпретировать.
Потому что выявление истинного узкого места — это то, что отличает реактивных администраторов баз данных от инженеров по производительности.

Когда сервер работает медленно, но метрики CPU и ввода-вывода выглядят нормально. Когда планы выполнения выглядят приемлемо, но что-то всё равно не так. Когда запросы нестабильны — то быстры, то еле ползут — и пользователи жалуются, хотя вы не видите ничего очевидного...

Вот где многие администраторы баз данных тратят часы.

👉 Помните: TempDB часто оказывается замешана, но почти никогда не является первопричиной.

21.4.26

Индексы под всеми углами: Как определить, используется ли индекс?

Автор: Paul Randal, Indexes From Every Angle: How can you tell if an index is being used?

Когда бы я ни обсуждал обслуживание индексов, и в частности фрагментацию, я всегда подчёркиваю: «Прежде чем что-либо делать с фрагментацией, убедитесь, что индекс используется».

Если индекс используется не очень активно, но при этом имеет очень низкую плотность страниц (много свободного места на страницах индекса), то он будет занимать гораздо больше дискового пространства, чем мог бы, и, возможно, его стоит уплотнить (с помощью перестроения или реорганизации), чтобы вернуть это дисковое пространство. Однако обычно нет особого смысла тратить ресурсы на устранение какой бы то ни было фрагментации, когда индекс не используется. Это особенно верно для тех, кто перестраивает все индексы каждую ночь или каждую неделю.

20.4.26

Чтение заголовков файлов SQL Server с помощью DBCC FILEHEADER

Автор: Anthony Nocentino, Reading SQL Server File Headers with DBCC FILEHEADER

Недавно я глубоко погрузился в изучение дисковых структур SQL Server, и одно из моих любимых направлений — это перечитывание серии статей Пола Рэндала (Paul Randal) о страницах заголовков файлов. Если вы её не читали, сделайте это прямо сейчас. В ней рассказывается о том, что такое страницы заголовков файлов, что они содержат и что происходит при их повреждении. Эта статья развивает эту концепцию. Я буду использовать DBCC FILEHEADER для чтения заголовка каждого файла пользовательской базы данных на сервере и отвечу на вопрос, который возникает чаще, чем можно подумать: можно ли определить, какие файлы принадлежат одной базе данных, исключительно по заголовку файла, без обращения к sys.databases?

Короткий ответ — да, и поле, которое делает это возможным, называется BindingId. Давайте разбираться.

19.4.26

"Все" мифы о резервном копировании

Автор: Paul Randal, A SQL Server DBA myth a day: (30/30) backup myths

Пришло время грандиозного финала!

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

В завершение я представляю вам 30 мифов о резервном копировании — по одному на каждый день апреля. Вчера вечером я сел писать эту статью и не добрал несколько мифов, поэтому обратился за помощью к великолепному сообществу SQL в Twitter — слишком много людей, чтобы перечислять (вы знаете, кто вы) — я благодарю вас!

Я очень надеюсь, что вам понравилась эта серия, и что множество мифов и заблуждений были развеяны раз и навсегда — я знаю, что многие из вас используют эти объяснения в качестве аргументов против сторонних поставщиков, разработчиков и других администраторов баз данных, которые настаивают на неправильных практиках.

Итак, поехали, последний выпуск…

13.4.26

Мифы о коэффициенте заполнения (fill factor)

Автор: Paul Randal, A SQL Server DBA myth a day: (24/30) twenty six restore myths

Я выдохся после прошлой статьи с мифами о восстановлении, так что сегодня короткая статья, разоблачающая некоторые мифы о коэффициенте заполнения (fill factor), которые я развенчал ещё в SQL Server 2005 в Books Online.

10.4.26

Миф о том, что эскалация блокировок происходит сначала с уровня строки на уровень страницы, а затем с уровня страницы на уровень таблицы

Автор: Paul Randal, A SQL Server DBA myth a day: (23/30) lock escalation

Миф №23: эскалация блокировок происходит сначала с уровня строки на уровень страницы, а затем с уровня страницы на уровень таблицы.

ЛОЖЬ

Нет, никогда. Эскалация блокировок в SQL Server  всегда переходит непосредственно к блокировке таблицы.

9.4.26

Углублённая диагностика и информативные панели мониторинга

Автор: Pinal Dave, Deeper Diagnostics and Actionable Dashboards

Большинство инструментов мониторинга баз данных созданы не для той аудитории. Панели мониторинга предназначены для успокоения руководителей, оповещения откалиброваны для удовлетворения контрольных списков соответствия требованиям, а отчёты отформатированы для ежеквартальных обзоров. Ничто из этого не полезно в 10 часов вечера, когда приложение возвращает тайм-ауты, а дежурный разработчик просит обновлений каждые три минуты. То, что нужно администратору баз данных в этот момент, — это инструмент, который уже имеет контекст. Не сырые данные, которые нужно собирать в условиях стресса. Не список превышенных порогов. А реальный контекст: что выполнялось, что находилось в ожидании, что изменилось и как это сравнивается с тем, что является нормальным для данного конкретного экземпляра в это время суток. Это более сложная задача, чем кажется, и большинство инструментов мониторинга её не решают. Давайте поговорим об углублённой диагностике и информативных панелях мониторинга.

2.4.26

SQL Server Deprecated Features: 25-летняя хронология и руководство по обеспечению совместимости с будущими версиями

Автор: Steve Stedman, SQL Server Deprecated Features: A 25-Year Timeline and Future-Proofing Guide

За последние 25 лет Microsoft SQL Server значительно эволюционировал, внедряя мощные инструменты и функциональные возможности, одновременно отказываясь от других. В рамках этой эволюции многие возможности были помечены как устаревшие — они по-прежнему работают в текущих версиях, но планируются к удалению в будущих выпусках. Понимание этих устаревших возможностей имеет решающее значение для администраторов баз данных и разработчиков, чтобы обеспечить долгосрочную совместимость и избежать потенциальных сбоев в своих системах.

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

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

31.3.26

Мифы о контрольных суммах страниц

Автор: Paul Randal, A SQL Server DBA myth a day: (17/30) page checksums

Несколько человек предложили разобрать некоторые мифы, связанные с контрольными суммами страниц, так что сегодня у нас очередной экстравагантный «многомифобойный» день! Ну, по крайней мере, я в восторге :-)

Я подробно описывал контрольные суммы страниц в статье блога How to tell if the IO subsystem is causing corruptions?

26.3.26

Десять лучших практик настройки производительности SQL Server

Автор: Paul Randal, SQL101: Top Ten SQL Server Performance Tuning Best Practices

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

25.3.26

Прекратите дефрагментировать индексы! Доступна для предварительного изучения функция Auto Index Compaction

Автор: Luca Biondi, Stop Defragmenting indexes: Auto Index Compaction feature preview in SQL Server – This Feature will Kills Index Maintenance Jobs!

В предыдущей статье мы проанализировали улучшения производительности в SQL Server 2025 CU3 и обнаружили скрытые оптимизации, о которых никто не говорит.

👉 Если вы пропустили, посмотрите здесь:
SQL Server 2025 CU3 – Скрытое улучшение производительности, о котором никто не говорит

В этой же статье мы представим удивительную новость в мире SQL Server, которую я называю функцией автоматического уплотнения индексов (Auto Index Compaction).

15.3.26

Всё ещё о Batch Mode… Параметры совместимости и опции запросов (Часть 6)

Автор: Luca Biondi, Still on Batch Mode… – Part 6: Compatibility & Query Settings That Influence Execution

Назад к серии: Как указать Batch Mode для Rowstore, если его нет в плане (Часть 5)

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

Сегодня мы углубимся: мы рассмотрим уровни совместимости, выделение памяти, оценку количества строк и флаги трассировки.

Приятного чтения, и пусть ваш CPU остаётся холодным при тяжёлых агрегатах!

6.3.26

Анатомия задания очистки CDC в SQL Server (и как поддерживать его в рабочем состоянии)

Автор: Paul Ou Yang, Anatomy of a SQL Server CDC Cleanup Job (and How to Keep It Healthy)

Система отслеживания изменений данных (Change Data Capture, CDC) замечательна, пока не перестаёт ей быть. При высокой интенсивности изменений задание очистки CDC может начать отставать. Когда это происходит, таблицы изменений (Change Tables, CT) быстро разрастаются, а задание очистки может блокировать задание записи (capture job), что, в свою очередь, может задерживать или останавливать нижестоящие системы-потребители.

Эта статья объясняет: как быстро оценить рост таблиц изменений, как задание очистки на самом деле удаляет строки и три основных «рычага» настройки для поддержания стабильности CDC.

4.3.26

Устранение ошибок включения CDC — Часть 2

Автор: Brass Contributor, Troubleshooting CDC enabling failure - Part 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 enabled 
for 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 failure 
and resubmit the request.

Они обошли её, включив параметр ANSI_NULL_DEFAULT на уровне базы данных:

ALTER DATABASE DB_Name SET ANSI_NULL_DEFAULT ON;

После этого CDC включился успешно.

Вопрос в том, какова первопричина этой проблемы и как мы можем избежать её в будущем?