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

8.9.25

Новое в SQL Server 2025: Кардинальность и REGEXP_LIKE

Автор: Louis Davidson, Cardinality and REGEXP_LIKE

Я читал пост Брента Озара о регулярных выражениях в SQL Server 2025 (T-SQL Has Regex in SQL Server 2025. Don’t Get Too Excited) и о том, почему они работают так, как работают. В комментариях кто-то упомянул несколько подсказок (hints), которые якобы должны улучшить ситуацию. О них написано немного, поэтому я решил сам проверить, как они себя ведут. Речь идёт о: ASSUME_FIXED_MAX_SELECTIVITY_FOR_REGEXP и ASSUME_FIXED_MIN_SELECTIVITY_FOR_REGEXP. Они работают, корректируя ожидаемое количество строк, возвращаемых условием с оператором REGEXP.

4.9.25

Что нового для columnstore-индексов в SQL Server 2025

Автор: SQLYARD. What’s New for Columnstore Indexes in SQL Server 2025

Columnstore-индексы прошли длинный путь с момента появления в SQL Server 2012. В каждом новом выпуске они становились быстрее, гибче и удобнее в обслуживании. В SQL Server 2025 Microsoft добавила очередную порцию улучшений — теперь упор сделан на производительность и непрерывность работы.

Три ключевых изменения

  • Упорядоченные некластеризованные columnstore-индексы
  • Онлайн-перестроение упорядоченных columnstore-индексов
  • Более эффективный shrink при наличии столбцов с MAX-типами

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 быстро откатывать незавершённые транзакции без сканирования всего журнала. Результат — значительно более быстрое восстановление после сбоя, мгновенный откат и общая улучшенная доступность базы данных, особенно в высоконагруженных средах.

25.8.25

Улучшения Columnstore-индексов в SQL Server 2025

Автор: Edward Pollack. Columnstore Index Improvements in SQL Server 2025

Columnstore-индексы – это мощный инструмент для хранения аналитических данных прямо в SQL Server. Эта функция улучшалась в каждой версии SQL Server за последние десять лет, и SQL Server 2025 не стал исключением.

Новые улучшения сосредоточены на обеспечении непрерывности бизнеса и повышении производительности. Упорядоченные (ordered) кластерные и некластерные columnstore-индексы, а также операции сжатия базы данных и файлов получили значительные улучшения.

30.6.25

Новое в SQL Server 2025: Оптимизация Halloween Protection

Автор: Dimitri Furman, MICROSOFT, 19 мая 2025г. SQL Server 2025: introducing optimized Halloween protection

Оптимизированная в SQL Server 2025 (начиная с CTP 2.0) защита «Halloween Protection», сокращает потребление места в tempdb и повышает производительность запросов, снижает потребление ресурсов, а также решает саму проблему Хэллоуина. При этом не требуется вносить какие-либо изменения в запросы пользователей. Тестирование ряда выбранных для примера приложений показали что утилизация процессоров и время исполнения таких запросов сократились примерно наполовину, а также полностью исчезло использование места в базе данных tempdb.

23.6.25

Новое в SQL Server 2025: ограничение использования tempdb добавлено в Resource Governor

Автор: Dimitri Furman, MICROSOFT, 19 мая 2025г. SQL Server 2025: introducing tempdb space resource governance

С начала существования SQL Server администраторам баз данных приходилось сталкиваться с распространённой проблемой — нехваткой места в базе данных tempdb.

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

- Erland Sommarskog, независимый консультант по SQL Server и Data Platform MVP

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

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

За свою карьеру я потратил больше времени, чем поддаётся подсчёту, на создание решений для управления местом в tempdb. Даже несмотря на то, что я потратил много времени и сил, всё равно возникали проблемы и сложности, особенно в многопользовательских приложениях с большим количеством баз данных и с проблемой «шумных соседей».

- Edward Pollack, работает в Transfinder архитектором данных и является Data Platform MVP

17.6.25

Новое в SQL Server 2025: Сжатие резервных копий алгоритмом Zstandard

В SQL Server 2025 добавлена ​​новая функция резервного копирования, позволяющая использовать для сжатия алгоритм Zstandard (ZSTD), который, как было анонсировано, будет работать лучшие, чем стандартный MS_XPRESS, и при этом его будет проще настраивать, чем Intel QAT. Алгоритм сжатия ZSTD доступен начиная с предварительной версии SQL Server 2025 (17.x).

25.4.25

Неявные преобразования (Implicit Conversions)

Автор: Craig Freedman Implicit Conversions

В нескольких статьях я уже показывал, как явные преобразования могут приводить к ошибкам. В этой статье рассмотрим некоторые проблемы, связанные с неявными преобразованиями. SQL Server добавляет неявные преобразования, когда в одном выражении запроса используются колонки, переменные и/или параметры с разными (но совместимыми) типами данных. Например, если нужно сравнить колонки с типами INT и FLOAT, INT необходимо преобразовать в FLOAT. Если вы напишете "C_INT = C_FLOAT", SQL Server перепишет это выражение как "CONVERT (FLOAT, C_INT) = C_FLOAT".

18.2.25

Подразумеваемые (Implied) предикаты

Автор: Craig Freedman Implied Predicates and Query Hints

В этой статье будут рассмотрены некоторые странности с предикатами в планах запросов. Рассмотрим следующую тривиальную схему и запрос:

CREATE TABLE T1 (A INT, B INT)

CREATE TABLE T2 (A INT, B INT)

 

SELECT *

FROM T1 INNER JOIN T2 ON T1.A = T2.A

WHERE T1.B = 0

OPTION (HASH JOIN)

Как и задумывалось, этот запрос будет выполняться со следующим планом:

  |--Hash Match(Inner Join, HASH:([T1].[A])=([T2].[A]), RESIDUAL:([T2].[A]=[T1].[A]))

       |--Table Scan(OBJECT:([T1]), WHERE:([T1].[B]=(0)))

       |--Table Scan(OBJECT:([T2]))

На самом деле, этот запрос получит такой план с подсказкой или без нее. Теперь давайте внесем небольшое изменение в предложение WHERE и посмотрим, что произойдет:

SELECT *

FROM T1 INNER JOIN T2 ON T1.A = T2.A

WHERE T1.A = 0

OPTION (HASH JOIN)

Теперь этот запрос выдает сообщение об ошибке:

Msg 8622, Level 16, State 1, Line 1

Query processor could not produce a query plan because of the hints defined in this query. Resubmit the query without specifying any hints and without using SET FORCEPLAN.

6.2.25

OPTIMIZED Nested Loops Joins

Автор: Craig Freedman OPTIMIZED Nested Loops Joins

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

3.2.25

Optimizing I/O Performance by Sorting – Part 2

Автор: Craig Freedman Optimizing I/O Performance by Sorting – Part 2

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

27.1.25

Новое в SQL Server 2022: Improved RCSI Ghost Cleanup

Автор: Paul White https://www.sql.kiwi/2024/12/improved-ghosts-2022/

Уровень изоляции моментального снимка с фиксированным чтением (Read Committed Snapshot Isolation, далее: RCSI) даёт много преимуществ. Главное из них в том, что читатели не будут блокировать писателей (и наоборот). Каждый оператор видит снимок данных на определенный момент времени (за исключением некоторых случаев, таких как использование non-inlined функций, которые оптимизатор не может развернуть внутри запроса). С другой стороны, появляются затраты на поддержание версий строк, необходимых для реализации RCSI.

Речь идет не только о том, чтобы убедиться, что база данных tempdb (или пользовательская база данных (если используется ADR - ACCELERATED_DATABASE_RECOVERY) достаточно велика и может справиться с дополнительной параллельной активностью:

  • Писатели, изменяющие (а иногда и добавляющие) данные, должны создавать версии строк.
  • Система должна уметь проверять и поддерживать компактность хранилища версий в фоновом режиме.
  • Читателям необходимо найти правильную для них версию каждой строки выборки.

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

26.11.24

Bookmark Lookup

Автор: Craig Freedman Bookmark Lookup

Перевод Ирины Наумовой

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

25.11.24

Sequential Read Ahead

Автор: Craig Freedman Sequential Read Ahead

Балансировка загрузки процессоров и ввода-вывода очень важна для обеспечения лучшей производительности и оптимизации обслуживания нагрузки сервера. В SQL Server реализованы два механизма асинхронного ввода-вывода: последовательное упреждающее чтение (sequential read ahead) и случайная упреждающая выборка (random prefetching). Оба они предназначены для балансировки нагрузки в многопроцессорных системах.

15.11.24

Scans vs Seeks

Автор: Craig Freedman Scans vs. Seeks

Scan и Seek — это итераторы, которые SQL Server использует для чтения данных из таблиц и индексов. Эти итераторы являются одними из самых фундаментальных, которые можно встретить почти в каждом в плане запроса. Так в чем разница между Scan (просмотром) и Seek (поиском)?

14.10.24

CASE Subqueries in BETWEEN and CASE Statements

Автор: Craig Freedman Subqueries in BETWEEN and CASE Statements

Рассмотрим следующий запрос:

CREATE TABLE T1 (A INT, B1 INT, B2 INT)

CREATE TABLE T2 (A INT, B INT)


SELECT *

FROM T1

WHERE (SELECT SUM(T2.B) FROM T2 WHERE T2.A = T1.A) BETWEEN T1.B1 AND T1.B2

26.9.24

Новое в SQL Server 2022: улучшения в sys.dm_exec_query_statistics_xml

Автор: Vivek Janakiraman Unleashing SQL Server 2022: Enhancements to sys.dm_exec_query_statistics_xml

Одним из улучшений в SQL Server 2022 является дальнейшее совершенствование динамического административного представления (DMV)  sys.dm_exec_query_statistics_xml. Этот DMV предоставляет подробную статистику выполнения запросов, что очень полезно для повышения их производительности и для оптимизации.