Столкнуться с ошибкой при работе с базой данных SQL Server для администратора БД — всё равно что кошмар наяву. Одна из таких ошибок — SQL Server error 1813 при присоединении базы данных: она напрямую затрагивает саму базу, не давая пользователям получить доступ к ней и к хранимым данным. В этом техническом материале мы подробно разберём эту ошибку, её причины и решения, которые помогут её устранить.
Как-то я опубликовал заметку в нашем блоге журнала "SQL Server Pro" о ложных срабатываниях проверки на повреждения, которые вы гарантированно увидите, если восстановите резервную копию базы master как пользовательскую базу и запустите DBCC CHECKDB на её копии. Это может быть частью переноса проверок целостности на другой сервер или валидации того, что ваши бэкапы корректно восстанавливаются и содержат неповреждённую базу. Впервые увидев такие ложные срабатывания, вы наверняка испугаетесь и решите, что ваш настоящий master повреждён!
Описание: KB5068450
Скачать: SQLServer2022-KB5068450-x64.exe
SQL Server 2022 — Версия: 16.0.4225.2
Analysis Services — Версия: 16.0.43.252
Дата выпуска: 13 ноября 2025г.
Сегодня в рассылке MVP задали вопрос о том, как SQL Server ведёт учёт изменений по каждому столбцу таблицы.
Начиная с версии 2008, скрытая системная таблица sys.sysrscols отслеживает изменения столбцов таблицы с помощью столбца rcmodified. Скрытые системные таблицы (появившиеся в 2005 году, когда мы полностью переписали систему управления метаданными) доступны только при подключении через соединение администратора (DAC), о чём я уже много раз писал. Это означает подключение с помощью SQLCMD -A или префикса admin: в строке подключения.
Эти данные также доступны во представлении каталога sys.system_internals_partition_columns, для которого DAC не требуется. (Я об этом подзабыл — спасибо моему другу Remus Rusanu за напоминание!)
Имейте в виду: всё ниже — выведенное поведение, основанное на моих знаниях и наблюдениях, и в будущих версиях оно может полностью измениться. Всё это не документировано, поэтому не стоит строить на этом программные решения. Если я этого не скажу, мой хороший друг Conor Cunningham при встрече меня отшлёпает :-)
Одним из крупнейших потребителей места в tempdb может быть DBCC CHECKDB. Эта команда генерирует всевозможные сведения о том, что она видит в базе данных (они называются фактами), и складывает их в большую рабочую таблицу. Фактами могут быть, к примеру, сообщения вроде «мы прочитали страницу F» или «запись X на странице Y указывает на выведённый за пределы строки столбец LOB в записи A на странице B», или даже целая битовая карта IAM‑страницы. Обычно объём памяти, требуемый для рабочей таблицы, превышает доступный объём, поэтому рабочая таблица проливается в tempdb.
DBCC CHECKDB вынуждена использовать такой механизм генерации фактов, потому что она читает страницы файлов данных не в логическом порядке и не в глубину, а в порядке распределения (allocation order), что быстрее всего. Более того, создаются несколько потоков, и каждый из них читает свой набор страниц, отчего во время работы I/O‑подсистема загружается по максимуму — специальный readahead выполняет упреждающее чтение, выжимая из диска всё, что можно. По мере того как каждый поток генерирует факты, он передаёт их процессору запросов, который сортирует их по ключу, заданному DBCC CHECKDB (идентификаторы страницы, объекта, индекса и т. п.), и вставляет в рабочую таблицу.
Мы проводим двухнедельное корпоративное обучение у финансового клиента в Нью‑Йорке, и на сегодняшней сессии по архитектуре журнала транзакций меня спросили, почему номера последовательностей VLF (virtual log file) в новой базе не начинаются с единицы.
Сегодня утром в Twitter развернулась интересная дискуссия (её начал мой хороший друг Erin Stellato) о «встроенных» обновлениях (in‑place updates) записей индекса, когда значение ключа меняется, но запись остаётся на той же странице. Разные источники, включая книгу SQL Server 2008 Internals (стр. 361 — этот фрагмент я не писал и не рецензировал :-) ), описывают процесс — увы, неверно. Там говорится, что запись останется ровно в той же позиции на странице и изменятся лишь байты, хранящие ключ.
Это не так. Настоящие in‑place‑обновления значений ключей индекса не выполняются, начиная с версии 2005. Давайте нырнём в кроличью нору…
Миф №29: исправить фрагментацию кучи можно, создав и затем удалив кластерный индекс.
Неееееет!!!
Это одно из худших действий, которые только можно совершить, если не считать сжатия базы данных.
Это короткая статья о мифах вокруг коэффициента заполнения (fill factor) — тему, которую я настойчиво прояснял ещё в Books Online для SQL Server 2005.
Миф №25: разные заблуждения о коэффициенте заполнения.
Все ложные
Описание: KB5068406
Скачать: SQLServer2022-KB5068406-x64.exe
SQL Server 2022 — версия: 16.0.4212.1
Дата выпуска: 11.11.2025
Скачать: SQLServer2022-KB5068407-x64.exe
SQL Server 2022 — версия: 16.0.1160.1
Дата выпуска: 11.11.2025
Описание: KB5068405
Скачать: SQLServer2019-KB5068405-x64.exe
SQL Server 2019 — версия: 15.0.2155.2
Дата выпуска: 11.11.2025
Скачать: SQLServer2019-KB5068404-x64.exe
SQL Server 2019 — версия: 15.0.4455.2
Дата выпуска: 11.11.2025
Скачать: SQLServer2017-KB5068403-x64.exe
SQL Server 2017 — версия: 14.0.2095.1Дата выпуска: 11.11.2025
Описание: KB5068402
Скачать: SQLServer2017-KB5068402-x64.exe
SQL Server 2017 — версия: 14.0.3515.1
Дата выпуска: 11.11.2025
Скачать: SQLServer2016-KB5068400-x64.exe
SQL Server 2016 — версия: 13.0.7070.1
Дата выпуска: 11.11.2025
Описание: KB5068401
Скачать: SQLServer2016-KB5068401-x64.exe
Дата выпуска: 11.11.2025
Распределение памяти (memory grants) под запросы — один из ключевых и при этом часто недооцениваемых аспектов настройки производительности SQL Server. Если запрос просит больше памяти, чем ему нужно, падает параллелизм. Если слишком мало — происходят проливы в tempdb.
В SQL Server 2025 Microsoft улучшила обратную связь по распределению памяти запроса (query memory grant feedback) и оптимизацию планов выполнения, благодаря чему движок управляет памятью заметно эффективнее, чем в SQL Server 2022. В этой статье мы рассмотрим, как эти изменения влияют на производительность запросов, сравним уровни совместимости 160 и 170.
Разумнее всего ожидать, что общедоступный релиз SQL Server 2025 состоится в этом месяце. На следующей неделе пройдут две крупные конференции в экосистеме данных Microsoft — Microsoft Ignite и PASS Summit. Почти все последние версии выходили как раз под такие мероприятия, а раз они проходят в одну неделю, то очень вероятно, что именно тогда и прозвучат анонсы.
Поэтому Стив Джонс предложил нам написать, что именно в новой версии нас радует. Возможно, слово «восторг» здесь не совсем уместно, но Стив явно хочет понять, какие функции облегчат нам жизнь. Он перечисляет несколько вариантов, а для меня главным событием становится, пожалуй, новый набор функций для нечёткого сравнения строк.
Мы начали использовать новый тип данных JSON в SQL Server для хранения JSON в таблице. При выполнении запросов с функциями вроде JSON_VALUE видим, что каждый раз выполняется полный просмотр таблицы. Хорошо бы индексировать JSON, чтобы повысить производительность. Поскольку JSON всё шире применяется в мире данных (например, REST‑API обычно возвращают наборы данных в формате JSON), SQL Server расширяет поддержку JSON прямо в ядре СУБД. В начале 2025 года в предварительной версии SQL Server 2025 появилось несколько новых функций для работы с JSON. Ещё одно дополнение — новый тип индекса: JSON‑индекс.
