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

21.9.26

Delayed Durability в SQL Server

Автор: Paul Randal, Delayed Durability in SQL Server 2014

Одна из интересных новых возможностей SQL Server — отложенная устойчивость (delayed durability, доступна во всех редакциях), которая подробно описана в Books Online здесь.

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

18.9.26

Ваш план обслуживания перестраивает индексы, которыми никто не пользуется

Автор: Pinal Dave, Your Index Rebuild Maintenance Plan Is Rebuilding Indexes Nobody Uses

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

15.9.26

Резервные копии снимком на вторичных репликах группы доступности

Автор: Andrew Pruski, T-SQL Snapshot Backups on Availability Group Secondary Replicas

Одной из моих любимых возможностей SQL Server 2022 были резервные копии снимком (Transact-SQL snapshot backup). Возможность использовать снимки современных систем хранения для создания согласованных на уровне приложения снимков наших баз данных — это прорыв для всех, кто имеет дело с очень большими базами данных и изо всех сил пытается уложиться в RPO при заданном RTO.

Однако согласованные на уровне приложения снимки требуют, чтобы запись ввода-вывода базы данных была приостановлена/заморожена/остановлена… и (справедливо) это может заставить администраторов баз данных нервничать.

7.9.26

Уровень совместимости и оценщик кардинальности в SQL Server

Автор: Vivek Johari, Compatibility Level vs. Cardinality Estimator in SQL Server: A Complete Guide;

Если вы когда-либо занимались настройкой производительности SQL Server, вы почти наверняка сталкивались с двумя терминами, которые постоянно путают: уровень совместимости (Compatibility Level, CL) и оценщик кардинальности (Cardinality Estimator, CE). Они звучат так, будто могут быть одним и тем же, поскольку изменение одного часто влияет на поведение другого. Но это два разных понятия в ядре SQL Server, и понимание того, где они пересекаются, а где расходятся, необходимо для всех, кто занимается обновлениями, миграциями или настройкой запросов.

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

2.9.26

Ещё больше ЗОЖ для журнала транзакций

Автор: Paul Randal, Trimming More Transaction Log Fat

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

31.8.26

Использование управляемой учётной записи (MSA) со службой SQL Server

Автор: Sarjen Haque, Using Managed Service Account with SQL Server Service


MSA — это управляемая учётная запись Active Directory, которая автоматически управляется Active Directory (AD). MSA (domain\account$) назначается Windows Server, а управление паролями обрабатывается Windows (не нужно их самим менять и обслуживать).

29.8.26

Проблемы конфигурации журнала транзакций

Автор: Paul Randal, Transaction Log Configuration Issues

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

Примечание переводчика: начиная с SQL Server 2022 описываемое в этой статье поведение журнала транзакций претерпело значительное изменение.

26.8.26

NUMA и soft-NUMA в SQL Server: Получение дополнительных потоков ввода-вывода

Автор: Sarjen Haque, NUMA and soft-NUMA in SQL Server: To get additional I/O threads

Производительность может быть значительно улучшена, если ядро SQL Server обнаруживает физические узлы NUMA в системе Windows. Наряду с аппаратным NUMA, Microsoft также представила архитектуру soft-NUMA (программный NUMA) для создания дополнительных виртуальных узлов NUMA внутри SQL OS. Начиная с SQL Server 2016 (13.x), если ядро базы данных обнаруживает более восьми «физических ядер на узел NUMA» или более восьми «сокетов», узлы soft-NUMA создаются автоматически. Создание узлов soft-NUMA позволяет ядру базы данных SQL Server создавать больше потоков ввода-вывода для повышения производительности требовательных транзакционных рабочих нагрузок SQL Server.

25.8.26

Убивают ли задержки ввода-вывода вашу производительность?

Автор: Paul Randal, Are I/O latencies killing your performance?

В этой статье я объясняю некоторые методы исследования и снижения задержек ввода-вывода для tempdb и журнала транзакций, которые могут серьёзно препятствовать производительности вашей рабочей нагрузки.

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

23.8.26

Строки подключения к SQL Server: Microsoft SqlClient Data Provider for SQL Server

Авторы, SQL Server connection strings

ConnectionStrings.com предоставляет удобный справочник по строкам подключения. База знаний, состоящая из статей и практических руководств по темам, связанным с источниками данных и программными соединениями, а также набор форумов с вопросами и ответами, где разработчики помогают друг другу находить решения, связанные с подключением, для своих систем.

21.8.26

Асинхронная репликация снимков из пода ActiveCluster на ещё одну систему хранения


Автор: Anthony Nocentino, Asynchronous Replication of Snapshots from an ActiveCluster Pod to a Third Array

Я восстанавливал свою трёхсайтовую демонстрационную лабораторию SQL Server и столкнулся с тем, чего давно хотел. Если вы когда-либо проектировали среду SQL Server на ActiveCluster, вам знаком этот сценарий: два FlashArray, работающие с синхронно реплицируемым модулем (pod) для нулевой точки восстановления (RPO) между сайтами, и третья система хранения где-то ещё для более длительного хранения и копии для аварийного восстановления. Проблема была в том, что вы не могли получить данные на эту третью систему хранения напрямую из пода Группы защиты внутри растянутого пода просто не могли иметь целью систему хранения.

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

В этой статье я покажу, как настроить это «от начала до конца» с помощью Pure Storage PowerShell SDK2, чтобы вы могли автоматизировать этот процесс. Поехали.

19.8.26

Устранение задержек перемещения данных между группами доступности AlwaysOn с синхронной фиксацией


Автор: Simon Su, Troubleshooting data movement latency between synchronous-commit AlwaysOn Availability Groups
Технические рецензенты: Pam Lahoud, Sourabh Agarwal, Tejas Shah

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

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

  • SQL Server:Database Replica –> Transaction Delay
  • SQL Server:Database Replica –> Mirrored Write Transactions/sec

Например, предположим, что есть плохо работающие узлы AG, и вы видите, что «SQL Server:Database Replica –> Transaction Delay» составляет 1000 мс, а «SQL Server:Database Replica –> Mirrored Write Transactions/sec» равно 50. Это означает, что в среднем каждая транзакция имеет задержку 1000 мс / 50 = 20 мс.

Учитывая приведённый пример, можем ли мы узнать, откуда берётся задержка в 20 мс? Какие факторы вызывают эту задержку? Чтобы найти ответы на такие вопросы, нам нужно понять, как работает синхронная фиксация: AlwaysOn HADRON Learning Series: How does AlwaysOn process a synchronous-commit request?

18.8.26

Расчёт задержки в сети между репликами группы доступности Always On


Автор: Paul Ou Yang, Calculating Network Latency Between Always On Availability Group Replicas

У нас было бизнес-требование добавить облачную асинхронную реплику к локальной группе доступности SQL Server Always On. После добавления высоконагруженной базы данных в группу доступности мы заметили, что очередь отправки журнала начала быстро расти.

Нашим первоначальным подозрением было, что задержка в сети между локальной первичной репликой и облачной репликой вносит вклад в проблему. Однако прежде чем запрашивать модернизацию сети, нам нужен был способ доказать, что производительность сети действительно влияет на перемещение данных.

Один из полезных подходов — использовать трассировку Extended Events для перемещения данных Always On, описанную в статье Microsoft: Устранение задержек перемещения данных между группами доступности AlwaysOn с синхронной фиксацией

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

17.8.26

Управление кешем планов SQL Server: диагностика и решение проблем

Кеш планов SQL Server — это критически важный компонент, который хранит планы выполнения запросов для повторного использования. Однако неправильное использование этого механизма может привести к серьезным проблемам производительности. В этой статье мы рассмотрим:

  • Как работают корзины (buckets) в кеше планов
  • Как диагностировать проблемы с неравномерным распределением планов
  • Как выявлять проблемные запросы и процедуры
  • Стратегии решения проблем без использования регламентированных запросов

12.8.26

Лучшая пожарная сигнализация — всё равно пожар


Автор: Pinal Dave, A Better Fire Alarm Is Still a Fire

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

11.8.26

Почему большие столбцы могут не влиять на логические чтения


Автор: Brent Ozar, Database Animations: Why Big Columns May Not Affect Logical Reads

Со временем таблицы — как и наша талия — имеют свойство увеличиваться. Мы постоянно добавляем всё новые и новые столбцы, один за другим, чтобы удовлетворить потребности приложений. Добавить «ещё один столбец» проще, чем выносить что-то в отдельную таблицу.

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

Однако, когда вам нужно прочитать много строк, чем больше строк вы читаете, тем сильнее дополнительные столбцы влияют на накладные расходы операции.

10.8.26

SQL Server 2025 показывает высокую загрузку процессоров!

Автор: Rob Farley, SQL 2025 showing crazy-high CPU;

Да, вам стоит подумать о переходе на SQL Server 2025. Но если вы используете учётные записи SQL Server, сначала проверьте это (а если вы здесь, чтобы понять, почему вдруг всё замедлилось, читайте дальше).

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

7.8.26

Полное руководство по xEvents

Автор: Vivek Johari, Extended Events (xEvents) in SQL Server & Azure SQL: Complete Guide;

Каждому администратору баз данных рано или поздно приходится сталкиваться с этим: приходит заявка в службу поддержки с сообщением «приложение работает медленно» и без каких-либо других подробностей, и ваша задача — выяснить, какая из тысячи вещей, происходящих внутри SQL Server, на самом деле является виновником. Это была блокировка? Плохой план? Шквал входов в систему? Чей-то ситуативный запрос, в котором забыли условие WHERE и который сейчас сканирует одиннадцать миллионов строк?

Долгое время ответом на вопрос «давайте посмотрим, что происходит в реальном времени» был SQL Server Profiler, работающий поверх SQL Trace. Он работал, но работал так, как работает прожектор, когда на самом деле вам нужен был фонарик — он захватывал всё без разбора, выполнялся на стороне клиента и мог заметно замедлить загруженный рабочий сервер просто фактом своего включения. Достаточно много администраторов баз данных имеют историю о том, как благонамеренная трассировка Profiler ухудшала состояние и без того перегруженного сервера, что в конечном итоге привело к тому, что Microsoft перестала рекомендовать его вообще.

Расширенные события (Extended Events, xEvents) пришли на смену, и это не просто незначительное обновление, — это принципиально иная архитектура, и это инструмент, который экзамен DP-300 требует знать досконально. Эта статья описывает, что это такое, почему он превосходит старые инструменты и — что действительно важно в повседневной работе — как использовать его для отслеживания блокировок, взаимоблокировок, медленных запросов, таймаутов, высокой загрузки ЦП, сбоев входа в систему и статистики ожиданий.

6.8.26

Почему одни статистики остаются устаревшими, в то время как другие обновляются автоматически

Автор: Jose Manuel Jurado (MICROSOFT), Lessons Learned #547:Some SQL DB Statistics Remain Outdated While Others Are Automatically Updated;

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

  • Более старую дату last_updated.
  • Высокое значение modification_counter.
  • Количество строк, значительно меньшее, чем текущее количество строк в таблице.

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