В списке рассылки MCM возникла интересная проблема с повреждением, и после того, как я её разобрал, подумал, что из этого получится хорошая статья в блоге на случай, если кто-то столкнётся с подобной проблемой.
В двух словах, проблема заключалась в таком повреждении, что простой запрос SELECT * завершался ошибкой, а запрос SELECT * с предложением ORDER BY работал.
Давайте разбираться!
Я уже много писал в блоге о недокументированной функции fn_dblog, в написании которой я помогал (и мне ещё многое предстоит :-)), но вот одна функция, которую я ранее не упоминал в блоге: fn_dump_dblog (хотя я рассказывал о ней на конференциях).
Рассмотрим сценарий: кто-то удалил таблицу, и вы хотите выяснить, когда это произошло и, возможно, кто это сделал. Трассировка по умолчанию также переполнилась, поэтому вы больше не можете получить оттуда информацию об операции DDL.
В рассылке MVP появилось предложение ввести временные некластерные индексы на читаемых вторичных репликах AG — по аналогии с временной статистикой. Я ответил, что, на мой взгляд, реализовать это чрезвычайно трудно, и пообещал объяснить почему. Ниже — моя аргументация. Замечу: это не исчерпывающий перечень, а лишь основные проблемы, которые я вижу.
Ещё в 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.
