MS SQL Server дело тонкое...: Engine

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

26.3.26

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

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

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

Дальше »

24.3.26

Мифы для администратора SQL Server о повреждениях и восстановлении

Автор: Paul Randal, A SQL Server DBA myth a day: (16/30) corruptions and repairs

Существует множество вещей, которые я постоянно слышу о том, что может и что не может восстановление (repair), что может вызывать повреждения и могут ли повреждения исчезать. Некоторые из них я уже описывал в постах за последние несколько лет, поэтому вместо того, чтобы повторять то же самое, этот пост-разоблачитель представляет собой несколько интересных ссылок, чтобы порадовать вас.

Дальше »

22.3.26

Самая распространённая ошибка индексирования в SQL Server (и как её исправить)

Автор: Luca Biondi, The Most Common SQL Server Indexing Mistake (And How to Fix It)

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

Дальше »

20.3.26

Использование Claude Code с SQL Server

Автор: Brent Ozar, Using Claude Code with SQL Server and Azure SQL DB

Эта статья не для тех, кто уже использует Claude Code. Я не хочу слышать жалобы от пользователей Code в комментариях о том, что я не осветил ту или иную функцию или сценарий. Это общий обзор на ~2000 слов о том, что это такое, почему вы можете этого захотеть, что вам нужно будет обсудить с вашей командой, и куда обращаться за дополнительной информацией.

Я также должен упомянуть, что я использую множество маркированных списков в своих обычных текстах. Как и во всех моих постах, ничего из этого не написано с помощью ИИ, точка. Эти слова исходят непосредственно из моего затуманенного алкоголем мозга, написаны в марте 2026 года, и, несомненно, со временем эта информация потеряет актуальность.

Дальше »

18.3.26

Журнал транзакций SQL Server. Часть 3: Циклическая природа

Автор: Paul Randal, The SQL Server Transaction Log, Part 3: The Circular Nature of the Log

(Эта статья впервые появился на SQLperformance.com четыре года назад как часть серии блогов, до того как этот сайт был закрыт позднее в 2022 году, а серия была прервана. Переопубликовано здесь с разрешения, с небольшими правками.)

Во второй части этой серии я описал структурную иерархию журнала транзакций. Поскольку эта статья в основном касается описанных мной виртуальных файлов журнала (VLF), я рекомендую вам прочитать вторую часть, прежде чем продолжить.

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

Дальше »

17.3.26

Как удалось убрал 32 секунды из запроса без добавления индекса

Автор: Luca Biondi, I Removed 32 Seconds From This SQL Server Query ...Without Adding an Index! Part 7

Это не теория.
Это не лабораторная настройка.
Это произошло с реальной рабочей нагрузкой.

Исходное время выполнения: 42 секунды.
После оптимизации: 9.8 секунды.

Никакого нового индекса.
Никакого изменения схемы.
Никакого обновления оборудования.

Просто понимание того, как работает движок.

Приятного чтения — давайте заставим SQL Server летать.

Продолжение серии статей, вот предыдущая: Всё ещё о Batch Mode… Параметры совместимости и опции запросов (Часть 6)

Дальше »

16.3.26

Стратегии индексирования для производительности SQL Server

Автор: Paul Randal, SQL101: Indexing Strategies for SQL Server Performance

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

Дальше »

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 остаётся холодным при тяжёлых агрегатах!

Дальше »

13.3.26

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

Автор: Luca Biondi, Part 5 – How to Force Batch Mode on Rowstore When SQL Server Doesn’t Choose It

Предыдущая статья: Без новых индексов или изменений схемы - запросы быстрее в 10 раз с Batch Mode для Rowstore (Часть 4)

Давайте пристально изучим Actual Execution Plan, и углубимся в изучение пакетного режима для строчного хранения.

Дальше »

Накопительный пакет обновлений для SQL Server 2022 CU24 - KB5080999

Описание: KB5080999

Скачать: SQLServer2022-KB5080999-x64.exe

Дата выпуска: 12 марта 2026 г.

SQL Server 2022 — Версия: 16.0.4245.2

12.3.26

Без новых индексов или изменений схемы - запросы быстрее в 10 раз с Batch Mode для Rowstore (Часть 4)

Автор: Luca Biondi, SQL Server: No New Index. No Schema Changes. 10x Faster Queries – SQL Server Batch Mode on Rowstore Deep Dive!! Part 4!

Надеюсь, вам нравится эта серия. Я искренне верю, что она может быть очень полезной для тех, кто профессионально использует SQL Server, как это делаю я уже более 20 лет (как летит время!).

Сегодня мы поговорим о пакетном режиме для строчного хранения (Batch Mode on Rowstore) и о том, как сделать ваш запрос в 10 раз быстрее без добавления каких-либо индексов.

Что ж... в Части 3 мы представили колоночные индексы и увидели, как выполнение в пакетном режиме может кардинально улучшить аналитические запросы.

Если вы пропустили предыдущую часть, вы можете прочитать её здесь:

👉 Фильтрованный индекс против индексированного представления и индекса с хранением в колонках (Часть 3)

Но вот в чём поворот.

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

SQL Server может активировать пакетный режим для строчного хранения.

И иногда... как я сказал вам в начале этой статьи... ваш запрос становится в 5 или 10 раз быстрее без добавления ни одного индекса. Поэтому я предлагаю вам продолжить чтение...

Дальше »

11.3.26

Логические чтения не повторяемы на колоночных индексах (эх...)

Автор: Brent Ozar, Logical Reads Aren’t Repeatable on Columnstore Indexes. (sigh)

Иногда я действительно ненавижу свою работу.

Вечно, ВЕЧНО, я мог утверждать: «Когда вы измеряете производительность хранилища во время настройки индексов и запросов, вы всегда должны использовать логические чтения, а не физические, потому что логические чтения повторяемы, а физические — нет. Физические чтения могут меняться в зависимости от того, что находится в кэше, какие другие запросы выполняются в данный момент, от редакции вашего SQL Server и от того, используются ли упреждающие чтения. Логические чтения просто отражают точное количество прочитанных страниц, независимо от того, откуда пришли данные (с диска или из кэша), так что пока это число уменьшается, вы делаете свою работу хорошо».

Дальше »