Ещё в 2009 году я писал о том, как работают контрольные точки (см. How do checkpoints work and what gets logged), и недавно получил по почте вопрос, который, как мне показалось, стоит оформить в короткую статью.
Вопрос (пересказ): Что произойдёт, если контрольная точка начнётся, но не успеет завершиться до сбоя? Будет ли она использована при восстановлении после сбоя?
После выхода SQL Server 2014 ходили разговоры об изменениях в количестве VLF, создаваемых при увеличении или автоувеличении журнала (далее буду говорить «автоувеличение», так как это самый распространённый сценарий). Я немного поэкспериментировал и решил, что разгадал изменение алгоритма. Оказалось, нет. В рассылке MVP вопрос вспыхнул с новой силой, и мы коллективно пришли к выводу, что алгоритм ведёт себя недетерминированно… иначе говоря, мы не понимали, что он делает. Я написал друзьям в CSS, которые изучили код (спасибо, Bob Ward и Suresh Kandoth!) и объяснили изменение.
Изменение весьма существенное: оно нацелено на то, чтобы многочисленные автоувеличения не создавали гигантские количества VLF. Это здорово, потому что слишком много VLF (зависит от размера журнала, но многие тысячи — это слишком много) способны вызвать целый ворох проблем с производительностью при резервном копировании, восстановлении, очистке журнала, репликации, восстановлении после сбоя, откатах и даже при обычных операциях DML.
Разберёмся с вопросом, возникшем в рассылке MCM. Речь шла о быстром восстановлении (подробно я объяснял его в заметке «Логирование блокировок и быстрое восстановление»), а если кратко — это возможность редакции Enterprise предоставить доступ к базе данных после завершения фазы REDO (повторное применение зафиксированных транзакций) восстановления после сбоя и до завершения фазы UNDO (отмена незавершённых транзакций) восстановления после сбоя. Идея в том, что UNDO может занимать намного больше времени, чем REDO, поэтому ранний доступ к базе — благо; именно поэтому это возможность редакции Enterprise (начиная с SQL Server 2005).
Суть вопроса: когда используется быстрое восстановление?
Это вопрос, который всплыл на нашем курсе IE1, и я решил оформить ответ в виде статьи в блоге, потому что в нём есть пара тонкостей.
Первые 8 страниц, выделяемые для единицы распределения, — это смешанные страницы из смешанных экстентов, если не включён флаг трассировки 1118.
В SQL Server 2022 появились снимки на уровне хранилища для почти мгновенного восстановления и встроенную поддержку совместимых с S3 хранилищ объектов для масштабируемых и экономичных резервных копий и запросов к внешним данным.
Microsoft SQL Server уже давно является одним из лидеров корпоративного управления данными, обеспечивая работу критически важных приложений в самых разных отраслях. С выпуском SQL Server 2022 компания Microsoft сделала смелый шаг к модернизации взаимодействия баз данных с подсистемами хранения. Новшества сосредоточены на мгновенном восстановлении с помощью снимков и на нативной интеграции с хранилищами объектов, совместимыми с S3, — обе возможности призваны удовлетворить растущие потребности гибридных облачных сред, аналитики по большим данным и систем высокой доступности.
В этой статье подробно рассматриваются эти инновации — не только то, что они делают, но и почему это важно для администраторов баз данных, разработчиков и организаций, работающих в современном мире, где всем управляют данные.
Давненько я не писал о чистой «внутренней кухне», но меня время от времени спрашивают, как вычисляется идентификатор единицы распределения по полям m_objId и m_indexId, которые хранятся в заголовке каждой страницы.
Когда DBCC PAGE выводит содержимое заголовка страницы, она выполняет необходимые вычисления и обращения к метаданным, чтобы показать идентификатор единицы распределения, идентификатор секции (partition), идентификатор табличного объекта и идентификатор индекса.
В SQL Server 2012 в вывод различных динамических представлений управления (DMV), функций и команд добавили множество небольших, но полезных сведений.
Одно из новшеств, которое я обнаружил и которому очень рад (да, мне бы почаще выбираться из пещеры :-), — это появление в выводе fn_dblog идентификатора родительской транзакции. Благодаря этому можно видеть, какая транзакция является родительской для вложенных системных транзакций и других подтранзакций.
Зачем это вообще нужно? Мы можем увидеть иерархию и точный порядок транзакций во время выполняемых нами операций с SQL Server, чтобы понимать, как всё устроено «под капотом», без догадок и предположений.
Поскольку на этой неделе проходят Microsoft Ignite и PASS Summit, я решил, что стоит написать быстрый пост о RegEx. Буду удивлён, если SQL Server 2025 не выйдет на этой неделе, а с этим релизом появится функция, которую я жду больше всего — RegEx в SQL Server.
Одно из практических применений RegEx — это более мощная фильтрация. Один из проектов, над которыми я работаю (очень медленно) — это размещение некоторых SQL-утилит на GitHub. Утилиты для просмотра метаданных таблицы, поиска столбцов, размеров баз данных и так далее. Обычно я использую LIKE для фильтрации данных, что позволяет мне просто использовать поиск по равенству, или я также могу выполнять поиск по частичному значению, когда не знаю точно, что ищу.
Дата релиза SQL Server 2025: 18 ноября 2025 г.
В этой статье собран подробный обзор нововведений Always On в SQL Server 2025: быстрый фейловер при устойчивых проблемах, ускорение синхронизации при переключениях, улучшения отказоустойчивости после кратковременной потери кворума, усиление безопасности соединений (TLS 1.3 и TDS 8.0), гибкость управления прослушивателями и маршрутизацией трафика, а также поддержка полноценных резервных копий на вторичных репликах. Материал ориентирован на проектирование, внедрение и эксплуатацию HA/DR решений. Подготовлено с помощью GPT5.
Мы рады сообщить, что драйвер mssql-python стал общедоступен! 🎉 Это важный шаг к современному, высокопроизводительному и удобному для разработчиков опыту для специалистов на Python, работающих с SQL Server, Azure SQL и базами данных SQL в Fabric.
Столкнуться с ошибкой при работе с базой данных SQL Server для администратора БД — всё равно что кошмар наяву. Одна из таких ошибок — SQL Server error 1813 при присоединении базы данных: она напрямую затрагивает саму базу, не давая пользователям получить доступ к ней и к хранимым данным. В этом техническом материале мы подробно разберём эту ошибку, её причины и решения, которые помогут её устранить.
Как-то я опубликовал заметку в нашем блоге журнала "SQL Server Pro" о ложных срабатываниях проверки на повреждения, которые вы гарантированно увидите, если восстановите резервную копию базы master как пользовательскую базу и запустите DBCC CHECKDB на её копии. Это может быть частью переноса проверок целостности на другой сервер или валидации того, что ваши бэкапы корректно восстанавливаются и содержат неповреждённую базу. Впервые увидев такие ложные срабатывания, вы наверняка испугаетесь и решите, что ваш настоящий master повреждён!
