Parameter sniffing в SQL Server: сначала диагностика
Практическое руководство по поиску планов, чувствительных к параметрам, доказательству причины и выбору наименее рискованного решения.
Читать статьюПрактические статьи о ClickHouse, SQL Server, архитектуре аналитики, производительности, миграциях и эксплуатации баз данных.
Практическое руководство по поиску планов, чувствительных к параметрам, доказательству причины и выбору наименее рискованного решения.
Читать статьюJob может завершиться успешно, пропустив базы, не обработав строки или опоздав для следующих процессов. Финальный статус не подтверждает требуемый результат.
Читать статьюОба варианта хранят промежуточные строки, но статистика, компиляция, индексы и транзакции могут создавать совершенно разные планы.
Читать статьюRow и page compression сокращают хранилище и I/O, но требуют CPU и неодинаково полезны для таблиц. Решение зависит от данных и нагрузки.
Читать статьюПартиционирование часто считают автоматическим ускорением. Наибольшую пользу оно дает для жизненного цикла, sliding window, архивации и границ обслуживания.
Читать статьюДинамический SQL полезен для необязательных фильтров и разных форм запроса, но конкатенация создает риск injection, ошибки кавычек, плохое повторное использование планов и сложную диагностику.
Читать статьюСбои хранилища, памяти, firmware и ПО могут повредить страницы без немедленной остановки приложения. Резервные копии способны сохранить незамеченную коррупцию.
Читать статьюПри lock-based Read Committed читатели и писатели блокируют друг друга. RCSI снижает блокировки версиями строк, но меняет использование ресурсов и поведение.
Читать статьюИндекс не поможет, если предикат скрывает столбец внутри функции или вычисления. SQL Server может просканировать все строки вместо перехода к диапазону.
Читать статьюПри несовместимых типах SQL Server может преобразовать индексированный столбец во время выполнения. Это приводит к scan, плохим оценкам и лишнему CPU.
Читать статьюНеожиданный рост журнала может заполнить диск, замедлить транзакции, задержать реплики и увеличить восстановление. Shrink устраняет только симптом.
Читать статьюСтандартный max server memory может оставить Windows и соседние службы без памяти. Слишком низкое значение вызывает лишние чтения, компиляции и давление grants.
Читать статьюЗначения по умолчанию редко отражают осознанный дизайн нагрузки. Избыточный параллелизм усиливает давление на CPU и workers, а чрезмерное ограничение замедляет аналитику.
Читать статьюДлинный список заблокированных сеансов делает каждый запрос подозрительным. Обычно одна транзакция в начале цепочки определяет длительность и масштаб инцидента.
Читать статьюУспешный job подтверждает запись резервной копии. Он не доказывает, что базы, ключи, цепочка журнала и зависимости будут восстановлены вовремя.
Читать статьюГруппа доступности может показывать здоровые реплики, хотя цели восстановления остаются под угрозой. Очереди, listener, резервные копии и готовность к failover требуют контроля.
Читать статьюОптимизатор выбирает соединения, доступ и память по оценочному числу строк. Если оценка далека от факта, разумный план становится дорогим.
Читать статьюTempDB обслуживает сортировки, хеширование, версии строк, временные объекты, spills и внутренние таблицы. Плохая конфигурация превращает ее в общий узкий участок.
Читать статьюDeadlock возникает, когда сеансы удерживают ресурсы, необходимые друг другу. SQL Server завершает один сеанс, но выбранная жертва не обязательно является причиной.
Читать статьюМногие сбои производительности заканчиваются до сохранения плана. Query Store хранит историю запросов, планов, времени выполнения и ожиданий.
Читать статьюПерестроение всех индексов по фиксированному расписанию расходует CPU, ввод-вывод, журнал и окно обслуживания без гарантированной пользы.
Читать статью