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

11.11.25

Потребление памяти запросами в SQL Server 2025

Автор: SQLYARD, SQL Query Memory Consumption in SQL Server 2025

Распределение памяти (memory grants) под запросы — один из ключевых и при этом часто недооцениваемых аспектов настройки производительности SQL Server. Если запрос просит больше памяти, чем ему нужно, падает параллелизм. Если слишком мало — происходят проливы в tempdb.

В SQL Server 2025 Microsoft улучшила обратную связь по распределению памяти запроса (query memory grant feedback) и оптимизацию планов выполнения, благодаря чему движок управляет памятью заметно эффективнее, чем в SQL Server 2022. В этой статье мы рассмотрим, как эти изменения влияют на производительность запросов, сравним уровни совместимости 160 и 170.

6.11.25

Должен ли SQL Server DBA разбираться в Windows Server Failover Clustering?

Автор: Sandra Delany, Should a SQL Server DBA Know Windows Clustering?

Должен ли SQL Server DBA понимать, как устроен кластер Windows Server Failover Clustering (WSFC), уметь создавать его или диагностировать проблемы? Или нам, DBA, лучше не выходить за рамки своей зоны? В некоторых организациях проведена чёткая граница между тем, что можно и чего нельзя DBA, а роли инфраструктуры отданы системным администраторам (SA). Это нормально, но это не означает, что DBA не должен уметь разбираться с проблемами FCI (Failover Cluster Instance) или AG (Availability Group) после непланового отказа на уровне кластера. (Да, AG можно создать и без кластера, но здесь мы этот вариант не рассматриваем.)

5.11.25

Hyper‑V и SQL Server: лучшие практики, о которых нам хочется, чтобы вы знали

Автор: Mike Walsh, Hyper-V and SQL Server Best Practices: What We Wish You Knew

Если вы когда‑нибудь задавались вопросом: «Почему SQL Server на Hyper‑V работает медленнее, чем должен?!», эта заметка может помочь. И да, если бы десять лет назад вы спросили меня о Hyper‑V, я бы, вероятно, лишь усмехнулся. Может, и раньше. Но суть в том, что эта платформа масштабируется, работает, и на фоне «весёлых» нововведений Broadcom/VMware (с соответствующей монетизацией), всё больше клиентов переходят на Hyper‑V. Как и с VMware, здесь важно внимательно отнестись к ряду ключевых настроек.

Спасибо Jeff Iannucci за совместную работу над этой статьёй и за его идеи. Он слишком долго напоминал мне подготовить этот пост и чек‑лист для клиентов — в итоге решил помочь и с написанием.

Мы в Straight Path в основном команда DBA, но нас часто просят помочь с развёртыванием SQL Server на виртуальных машинах Hyper‑V и спрашивают: «Каковы лучшие практики?». Многие (если не большинство) системных администраторов это всё и так знают. Но если вдруг нет, или если в вашей компании «все шляпы» приходится носить вам одному, мы собрали ключевые рекомендации, которые помогут обеспечить высокую доступность и стабильную производительность SQL Server на Hyper‑V.

Это не тайные знания. Но это те вещи, упущенные настройки и неверные решения, которые мы продолжаем встречать на практике, работая с новыми клиентами. И как в нашей статье «VMware and SQL Server best practices» нескольких лет назад, мне гораздо приятнее, когда вы сами находите и исправляете эти моменты, а уж потом зовёте нас для действительно интересных и нетривиальных задач!

31.10.25

Accelerated Database Recovery для tempdb в SQL Server 2025

Автор: Andrew Pruski, Accelerated Database Recovery for tempdb in SQL Server 2025

Ускоренное восстановление базы данных (Accelerated Database Recovery, ADR) появилось в SQL Server 2019 и обеспечивает быстрое восстановление, мгновенный откат транзакций и агрессивное усечение журнала. Полный обзор того, как ADR этого добивается, приведён в документации.

Теперь в SQL Server 2025 можно включить ADR для tempdb! Быстрое восстановление к tempdb не применимо, но вот мгновенный откат транзакций и агрессивное усечение журнала — на все 100%. Посмотрим, что происходит после включения ADR для tempdb в SQL Server 2025.

29.10.25

SQL Server и большие страницы: подробное объяснение

Автор: Bob Ward, SQL Server and Large Pages Explained

В на Europe PASS Summit я читал доклад о диагностике памяти. В нём упомянул, что SQL Server будет использовать большие страницы (Large Pages), если включён trace flag 834. На конференции Кристиан Болтон, хорошо известный MVP из Великобритании, заметил, что видел в ERRORLOG сообщения о «large pages», хотя trace flag у него был выключен. Тогда я ответил, что не представляю, как такое возможно. Что ж, Кристиан, вы ничего не выдумали.

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

28.10.25

TempDB: призрак Version Store

Автор: SWYS SQL, TEMPDB: The Ghost of VersionStore

Ближе к 30 октября некоторые серверы баз данных начинают вести себя странно, словно хотят поддержать атмосферу Хэллоуина. На этой неделе один из моих серверов вёл себя именно так. Последние месяцы он работал без проблем, но сегодня его TempDB начала стремительно заполняться. Разумеется, это потребовало расследования — и я обнаружил, что причиной неожиданного роста TempDB стал Version Store. Самое странное было в том, что одна база данных занимала почти всё пространство TempDB в Version Store, хотя в ней не было открытых транзакций. Действительно жуткая история!

Хранилище версий не очищается, если хоть в одной базе есть открытые транзакции

Автор: Brent Ozar, The Version Store Won’t Clear If ANY Database Has Open Transactions

Это особенно болезненно для тех, кто обслуживает несколько баз данных на одном сервере. Достаточно одному приложению вести себя плохо и оставлять транзакции открытыми — и внезапно остальные базы начинают расширять TempDB за пределы доступного места. Причём та транзакция в злосчастном приложении может даже ничего не менять, и раньше сама по себе проблем не вызывала, — но как только она делит TempDB с другими приложениями, начинаются каскадные эффекты.

22.10.25

TempDB переполняется? Попробуйте Resource Governor и SQL Server 2025

Автор: Brent Ozar, TempDB Filling Up? Try Resource Governor

TempDB — одна из моих неизменных головных болей.

Любой, любой, кто может выполнять запросы на вашем сервере, способен за считанные секунды устроить отказ в обслуживании, просто заполнив TempDB простейшим запросом:

DROP TABLE IF EXISTS #big_problem;
CREATE TABLE #big_problem
    (filler VARCHAR(8000));
WHILE 1 = 1
    INSERT INTO #big_problem
    SELECT REPLICATE('X', 8000)
    FROM GENERATE_SERIES(1, 100000);

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

Вам уж точно не стоит запускать такое в свой последний рабочий день, выходя за дверь: даже если ваш логин отключат, уже запущенные запросы продолжат выполняться, пока не завершатся, или, как в этом случае, пока не нанесут «добивающий удар» по вашему хранилищу, и файлы TempDB не начнут раздуваться, как брюки Sansabelt, пытающиеся справиться с шведским столом «ешь сколько сможешь». И уж точно не стоит гонять это в цикле. (Если всё же решитесь, убедитесь, что в начале скрипта удаляете таблицу, если она существует).

Если вы ещё не на SQL Server 2025, ваша основная линия обороны — заранее задать файлам данных TempDB нужный максимальный размер и отключить авторасширение. Это... слабая защита. Плохо ведущие себя запросы всё равно могут выгрызть TempDB до нуля, создавая проблемы для остальных.

10.10.25

Контроль состояния распределённой группы доступности: T-SQL и Zabbix

Автор: Pablo Echeverria, Distributed Availability Group Health: T-SQL and Zabbix

После создания распределённой группы доступности по шагам из моей статьи «SQL Server 2022: Распределённая группа доступности без кластера», как проверить, что синхронизация между дата-центрами в порядке?

В SQL Server Management Studio, если щёлкнуть правой кнопкой по распределённой группе доступности, вы заметите, что нет панели мониторинга, подтверждающей корректную синхронизацию данных между дата-центрами:

Даже если проверять панели первичного и вторичного дата-центров по отдельности, вы не увидите, есть ли проблема «между ними».

Повреждения баз данных SQL Server: обнаружение, причины и некоторые подробности о DBCC CHECKDB

Автор: MSFTPawelM, SQL Server Database Corruption: Causes, Detection, and some details behind DBCC CHECKDB

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

  • распространённые причины повреждений;
  • как «под капотом» работает DBCC CHECKDB;
  • рекомендации по настройке производительности при запуске CHECKDB;
  • типовые сообщения об ошибках и их смысл;
  • лучшие практики предотвращения и восстановления.

1.10.25

Включаем умный параллелелизм вставки с помощью OPTIMIZE_FOR_SEQUENTIAL_KEY

Автор: Chandan Shukla, Unlocking High-Concurrency Inserts in SQL Server with OPTIMIZE_FOR_SEQUENTIAL_KEY

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

Но картина меняется, как только вы начинаете нагружать систему сотнями параллельных вставок. Внезапно вся вычислительная мощь перестаёт иметь значение, потому что каждый поток бьётся за одно крошечное место в памяти: последнюю страницу кластерного индекса. Это классическая проблема «last-page insert contention problem». Она возникает всякий раз, когда ключ кластерного индекса последовательный — типичные IDENTITY, DATETIME или NEWSEQUENTIALID(). Каждая новая строка естественным образом «тянется» в конец B-дерева. Это звучит упорядоченно и эффективно, но при конкуренции — это ловушка. Вместо распределения вставок по нескольким страницам все они наваливаются на одну «горячую» страницу.

30.9.25

Интеграция SQL Server 2025 с S3

Автор: Anthony Nocentino, Setting up SQL Server S3 Object Storage Integration using MinIO with Docker Compose (Updated for SQL Server 2025)
Эта статья и репозиторий GitHub были обновлены для SQL Server 2025 RC1 и Ubuntu 24.04.
Новое в SQL Server 2025: Вам больше не нужно устанавливать службу PolyBase для работы с файлами Parquet в S3. Ранее, с SQL Server 2022, приходилось создавать пользовательский контейнер или вручную устанавливать PolyBase. Теперь интеграция с объектами S3 и поддержка Parquet работают прямо из коробки!

16.9.25

Новое в SQL Server 2025: REST API и переосмысливание резервного копирования снимков

Автор: Anthony Nocentino, T-SQL REST API Integration in SQL Server 2025: Streamlining T-SQL Snapshot Backups

В этой статье я покажу, как с помощью T-SQL-скрипта создавать согласованные с приложениями моментальные снимки на Pure Storage FlashArray прямо из SQL Server, без использования внешних инструментов. В SQL Server 2025 появилась мощная новая возможность: хранимая процедура sp_invoke_external_rest_endpoint. Она значительно облегчает вызов REST API напрямую из T-SQL. В сочетании с API Pure Storage эта функция позволяет полностью автоматизировать процесс создания снимков без внешних скриптов и инструментов.

Если вы следили за моей серией публикаций Using T-SQL Snapshot Backup, вы знаете, что данная технология особенно полезна в крупных базах данных. Сегодня мы рассмотрим, как реализовать её непосредственно в T-SQL, используя возможность SQL Server обращаться к REST API. PowerShell не потребуется.

15.9.25

Оптимизация чувствительных к параметрам планов исполнения в SQL Server 2022

Автор: Deepam Ghosh, Parameter Sensitive Plan Optimization in SQL Server 2022

SQL Server 2022 включает множество усовершенствований и новых возможностей по сравнению с предыдущими версиями. Среди них новые роли сервера, улучшенный Query Store, повышение производительности TempDB, интеллектуальная обработка запросов, автономные группы доступности, Database Ledger и многое другое.

В сегодняшней статье мы рассмотрим практическую демонстрацию одной из таких возможностей — оптимизации планов, чувствительных к параметрам (Parameter Sensitive Plan Optimization, PSPO). Мы увидим, какие трудности создают параметризованные хранимые процедуры в старых версиях и как оптимизация PSPO решает эти проблемы и улучшает планы выполнения запросов в новой версии.

Эта статья посвящена только практической части, для изучения подробной теории об оптимизации планов, чувствительных к параметрам, обратитесь к официальной документации Microsoft.

6.9.25

Развёртывание SQL Server одним скриптом (dbatools)

Автор: David Seis. Deploy SQL Server With This One Script (dbatools)

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

28.8.25

SQL Server 2025: параметр Availability Group Commit Time

Автор: Nathan Courtine. SQL Server 2025 – AG Commit Time

В этом материале я хочу выделить одну функцию движка для высокой доступности (HA) — Availability Group Commit Time.

Функция Always On Availability Group (AG) появилась в SQL Server 2012. За годы эта технология HA получила множество улучшений, особенно в SQL Server 2016 (автоматическая инициализация, реплики только для чтения, поддержка DTC, проверка состояния БД, распределённые AG и т. д.).

Для решения проблем с производительностью в SQL Server 2016 был введён параметр AG Commit Time. Для узлов в синхронном режиме он уменьшает задержку, задавая время, после которого транзакция должна быть отправлена на реплики.

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

Однако в некоторых сценариях значение по умолчанию (10 мс) может быть слишком большим и не соответствовать бизнес-требованиям. В SQL Server 2025 этот параметр теперь можно настроить на уровне сервера через конфигурацию availability group commit time.

27.8.25

SQL Server 2025: что нового в конфигурации экземпляра

Автор: Stéphane Haby. SQL Server 2025: What news on the instance configuration

Как и при выходе каждой новой версии SQL Server, полезно посмотреть, какие новые возможности конфигурации мы получаем для управления экземпляром. Для этого я сравнил SQL Server 2022 и SQL Server 2025 с помощью системного представления sys.configurations.

Начал с простого count(*), чтобы узнать количество различий:

В SQL Server 2022 — 95 параметров конфигурации, в SQL Server 2025 — 105. Похоже, у нас появилось 10 новых параметров.

Перехожу к деталям с запросом на обеих инстанциях:

SELECT * FROM sys.configurations;

Сохранил результаты в CSV, чтобы увидеть, какие значения дублируются, а какие — новые.

В итоге я получил 10 новых параметров конфигурации SQL Server 2025.

26.8.25

Ускоренное восстановление базы данных в SQL Server 2025

Автор: Jordan Boich. Accelerated Database Recovery in SQL Server 2025

Ускоренное восстановление базы данных (Accelerated Database Recovery, ADR) появилось в SQL Server 2019. Его основная цель — обеспечить более быстрое восстановление базы данных в случае сбоя или неожиданного выключения. Традиционно процесс восстановления включал несколько фаз — анализ, повторное выполнение (redo) и откат (undo). Этот подход мог быть неэффективным и долгим, особенно при наличии длительных транзакций.

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

22.8.25

AlwaysOn Availability Groups – пошаговая настройка гибридной конфигурации

Автор: SQLYARD. SQL Always On Availability Groups – Hybrid Setup Steps

Это руководство описывает настройку отказоустойчивого кластера AlwaysOn Availability Group (AG) с двумя обычными узлами, одним узлом в Azure и использованием Azure Cloud Witness для кворума. В итоге вы получите продакшн‑кластер с автоматическим переключением на локальном уровне и DR‑репликой в облаке.

18.8.25

MSSQL - Workgroup and Multi-domain clusters

Автор: John Marlin. Workgroup and Multi-domain clusters in Windows Server 2016

До появления Windows Server 2016, кластер можно было создать только для компьютеров в одном домене. Начиная с Windows Server 2016 появилась возможность создания отказоустойчивого кластера без зависимостей от Active Directory. Таким образом, отказоустойчивые кластеры теперь можно создавать в следующих конфигурациях:

  • Однодоменные кластеры: кластеры, в которых все узлы присоединены к одному домену.
  • Мульти-доменные кластеры: кластеры с узлами из разных доменов.
  • Workgroup кластеры: кластеры с узлами, которые являются участниками рабочей группы (не присоединены к домену).