Столкнуться с ошибкой при работе с базой данных 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
