Описание: KB5132747
Скачать: SQLServer2022-KB5132747-x64.exe
Дата выпуска: 10 ноября 2026 г.
SQL Server 2022 — Версия: 16.0.1220.3
11.11.26
Исправление безопасности для SQL Server 2019 CU32 - KB5132745
Описание: KB5132745
Скачать: SQLServer2019-KB5132745-x64.exe
Дата выпуска: 10 ноября 2026 г.
SQL Server 2019 — версия: 15.0.4510.2
Исправление безопасности для SQL Server 2019 GDR - KB5132751
Описание: KB5132751
Скачать: SQLServer2019-KB5132751-x64.exe
Дата выпуска: 10 ноября 2026 г.
SQL Server 2019 — версия: 15.0.2210.4
Исправление безопасности для SQL Server 2017 CU31 - KB5132746
Скачать: SQLServer2017-KB5132746-x64.exe
Дата выпуска: 10 ноября 2026 г.
SQL Server 2017 — версия: 14.0.3570.2
Исправление безопасности для SQL Server 2017 GDR - KB5132749
Скачать: SQLServer2017-KB5132749-x64.exe
Дата выпуска: 10 ноября 2026 г.
SQL Server 2017 — версия: 14.0.2150.2
10.11.26
Добавление базы данных в группу доступности AG (автоматическая инициализация) и контроль хода инициализации
Автор: Dr. Hasan Dalmaz, Añadir una base de datos a un AG (automatic seeding) y monitorear el progreso del seeding
В этой статье вы узнаете, как добавляется база данных в группу доступности AG, и происходит передача её на вторичные реплики через конечную точку (VDI), без необходимости вручную создавать резервную копию и восстанавливать её. Также, вы узнаете, как отслеживать производительность инициализации, расчётное время её завершения и причину возможного сбоя.
9.11.26
AG Direct Seeding: расширенные события и динамические административные представления
Меня эта возможность чрезвычайно заинтересовала, поэтому отсутствие документации на момент написания статьи меня не остановило. С тех пор как появились группы доступности, регулярно возникают вопросы о том, как автоматизировать присоединение (seeding) новых баз данных. Все предлагавшиеся решения сводились к довольно неуклюжим сценариям: создать резервную копию, восстановить её, присоединить базу к группе и так далее. Описываемая тут функциональность призвана избавить нас от всей этой возни.
6.11.26
VLF: когда журнал транзакций превращается в коммуналку
VLF — это виртуальные файлы журнала. Пока их немного, они тихо делают свою работу. Но стоит им расплодиться, как журнал транзакций начинает напоминать коммунальную квартиру с бесконечными чуланами: нужную коробку вроде бы видно, а чтобы до неё добраться, приходится открывать дверь за дверью.
Чем больше VLF, тем заметнее просадка производительности. Страдают, причём дружно, почти все участники процесса:
- резервное копирование журнала — вместо одного крупного блока приходится перебирать гору мелких;
- восстановление базы данных — и без того не мгновенное, с массой VLF превращается в марафон;
- очистка журнала и его усечение — буксует из-за фрагментации;
- репликация — агент чтения журнала пробирается через дебри VLF, доставка изменений замедляется;
- восстановление после сбоя — система приходит в себя дольше;
- откаты транзакций — процедура становится ещё томительнее;
- обычные операции изменения данных — даже они ощущают на себе тяжесть раздробленного журнала;
- запуск базы данных — при миллионах мелких VLF старт может затянуться.
Порогом тревоги обычно считают тысячу VLF, хотя некоторые умудряются довести журнал до полутора миллионов. Это уже не повод для гордости, а повод взяться за настройки.
5.11.26
2NF и BCNF: весь ключ и ничего, кроме ключа
«Нормальные формы» — это правила нормализации баз данных, предназначенные для предотвращения дублирования данных и аномалий при изменении информации в реляционных базах данных.
Вторая нормальная форма (2NF) требует, чтобы каждый столбец зависел от всего ключа таблицы, а не только от его части. Нормальная форма Бойса — Кодда (BCNF) ужесточает это требование: никакой столбец не должен зависеть ни от чего, кроме ключа.
Классическая мнемоническая фраза «ключ, весь ключ и ничего, кроме ключа» объединяет все три нормальные формы в одной строке. В этом руководстве мы подробно разберём, что именно означает каждое правило, и рассмотрим практические примеры, которые можно применить при проектировании собственных структур данных.
3.11.26
Влияние CPU Ready на ожидания SOS_SCHEDULER_YIELD
Однажды мы с Полом обсуждали ожидания SOS_SCHEDULER_YIELD и пытались разобраться, могут ли показатели этих ожиданий в SQL Server искажаться из-за проблем с планированием выполнения виртуальной машины гипервизором.
Я провёл первые эксперименты в своей лаборатории виртуальных машин, используя как Hyper-V, так и VMware. В результате удалось воспроизвести именно ту ситуацию, о которой говорил Пол и которую он описал в своей статье.
2.11.26
Увеличение количества ожиданий SOS_SCHEDULER_YIELD на виртуальных машинах
Автор: Paul Randal, Increased SOS_SCHEDULER_YIELD waits on virtual machines
Во время обучения работе со статистикой ожиданий, меня спросили, существуют ли какие-либо ожидаемые различия в этой статистике при работе SQL Server внутри виртуальной машины.
Я ответил утвердительно: время ожиданий может оказаться больше, если что-то мешает виртуальной машине выполнять работу. Дело в том, что продолжительность ожидания определяется разницей значений счётчика __rdtsc (по сути, счётчика тактов процессора) в момент начала и окончания ожидания.
30.10.26
Структуры хранения #8 — векторные индексы
Это восьмая часть серии статей, посвящённой внутреннему устройству структур хранения данных. Рассмотрев стандартные типы хранения, традиционные построчные структуры данных, колоночные индексы, структуры с оптимизацией для работы в памяти и колоночные структуры с оптимизацией для работы в памяти, я перешёл к более специализированным структурам хранения. В пятой, шестой и седьмой частях речь шла об индексах XML, JSON и пространственных данных. Теперь настала очередь типа индексов, который появился в продукте совсем недавно — векторные индексы.
Подписаться на:
Сообщения (Atom)