Чтение заголовков файлов SQL Server с помощью DBCC FILEHEADER

Автор: Anthony Nocentino, Reading SQL Server File Headers with DBCC FILEHEADER

Недавно я глубоко погрузился в изучение дисковых структур SQL Server, и одно из моих любимых направлений — это перечитывание серии статей Пола Рэндала (Paul Randal) о страницах заголовков файлов. Если вы её не читали, сделайте это прямо сейчас. В ней рассказывается о том, что такое страницы заголовков файлов, что они содержат и что происходит при их повреждении. Эта статья развивает эту концепцию. Я буду использовать DBCC FILEHEADER для чтения заголовка каждого файла пользовательской базы данных на сервере и отвечу на вопрос, который возникает чаще, чем можно подумать: можно ли определить, какие файлы принадлежат одной базе данных, исключительно по заголовку файла, без обращения к sys.databases?

Короткий ответ — да, и поле, которое делает это возможным, называется BindingId. Давайте разбираться.

"Все" мифы о резервном копировании

Автор: Paul Randal, A SQL Server DBA myth a day: (30/30) backup myths

Пришло время грандиозного финала!

Хотя было весело развенчивать все эти мифы, это было немного напряжённо — каждый день находить интересный и полезный миф для разоблачения.

В завершение я представляю вам 30 мифов о резервном копировании — по одному на каждый день апреля. Вчера вечером я сел писать эту статью и не добрал несколько мифов, поэтому обратился за помощью к великолепному сообществу SQL в Twitter — слишком много людей, чтобы перечислять (вы знаете, кто вы) — я благодарю вас!

Я очень надеюсь, что вам понравилась эта серия, и что множество мифов и заблуждений были развеяны раз и навсегда — я знаю, что многие из вас используют эти объяснения в качестве аргументов против сторонних поставщиков, разработчиков и других администраторов баз данных, которые настаивают на неправильных практиках.

Итак, поехали, последний выпуск…

Мифы о модели восстановления BULK_LOGGED

Автор: Paul Randal, A SQL Server DBA myth a day: (28/30) BULK_LOGGED recovery model

Модель восстановления BULK_LOGGED продолжает сбивать людей с толку…

Миф об использовании BACKUP WITH CHECKSUM для замены DBCC CHECKDB

Автор: Paul Randal, A SQL Server DBA myth a day: (27/30) use BACKUP WITH CHECKSUM to replace DBCC CHECKDB

Сегодня короткая статья, так как я занят работой с клиентами и сортировкой заявок на выступления для SQL Connections!

Двадцать шесть мифов о восстановлении

Автор: Paul Randal, A SQL Server DBA myth a day: (24/30) twenty six restore myths

Одна область, которую я ещё не затронул в этой серии, — это RESTORE (восстановление), и здесь существует тонна заблуждений (так много, на самом деле, что я не могу охватить их все в одной статье!). В одной статье было разоблачено 6 мифов о контрольных суммах страниц, а в другой — 5 мифов о FILESTREAM, так что сегодня мне нужно их превзойти.

Миф о том, что повреждение базы можно исправить перезапуском SQL Server

Автор: Paul Randal, A SQL Server DBA myth a day: (21/30) corruption can be fixed by restarting SQL Server

Этот миф (и его производные) очень распространены среди не-администраторов баз данных, поскольку многие проблемы в Windows можно исправить перезагрузкой компьютера (да, я до сих пор вижу это на серверах, Windows 10 и т.д. — попробуйте изменить номер порта служб терминалов без перезагрузки).

Миф о том, что для перезапуска цепочки восстановления журнала требуется полная копия базы

Автор: Paul Randal, A SQL Server DBA myth a day: (20/30) restarting a log backup chain requires a full database backup

Этот миф — один из самых распространённых, и я встречал очень мало людей, которые знают правду.

Миф №20: после разрыва цепочки резервного копирования журнала для её перезапуска требуется полная резервная копия базы данных.

ЛОЖЬ!

Как оптимизировать переключение реплик групп доступности SQL Server

Автор: Aaron Bertrand , Serializing Deletes From Clustered Columnstore Indexes

Мы часто выполняем плановые переключения реплик в группах доступности SQL Server для обслуживания, установки исправлений, обновлений и даже ротации оборудования. Обычно наши переключения выполняются быстро, но иногда они занимают больше времени — и не всегда интуитивно понятно почему, поскольку нет очевидной связи со временем суток, размером базы данных или объёмом транзакций.

Сокращение даже нескольких секунд из этого процесса может улучшить взаимодействие с приложением и конечным пользователем; это также может значительно снизить количество оповещений или, по крайней мере, сократить время, в течение которого оповещения должны быть отключены. Существует множество материалов о том, как правильно выполнять переключения в AG (без потери данных), но гораздо меньше тех, которые сосредоточены на сокращении окна прерывания доступности. Разница обычно заключается в некоторой комбинации объёма повторного выполнения (redo), поведения контрольных точек, открытых транзакций и готовности вторичной реплики.

Я хотел поделиться некоторыми методами, которые я использую, чтобы сделать плановые переключения более быстрыми и предсказуемыми. Некоторые из этих методов хорошо документированы, другие выпестованы из реальных шаблонов, которые я наблюдал во многих средах с SQL Server. Я расскажу о том, что я делаю до, во время и после переключения первичной реплики, чтобы минимизировать прерывания работы пользователей и повысить вероятность того, что они не заметят, что что-то произошло.

Журнал транзакций SQL Server, Часть 2: Архитектура журналирования

Автор: Paul Randal, The SQL Server Transaction Log, Part 2: Log Architecture

В первой части этой серии я познакомил вас с основной терминологией, касающейся журналирования, поэтому рекомендую прочитать её, прежде чем продолжать чтение этой части. Всё остальное, что я расскажу в серии, требует знания некоторой архитектуры журнала транзакций, так что именно это я и собираюсь обсудить на этот раз. Даже если вы не собираетесь следить за серией, некоторые концепции, которые я объясню ниже, полезно знать для повседневных задач, с которыми сталкиваются в своей работе администраторы баз данных.

Журнал транзакций SQL Server, Часть 1: Основы журналирования

Автор: Paul Randal, The SQL Server Transaction Log, Part 1: Logging Basics

(Эта статья впервые появилась на SQLperformance.com четыре года назад как часть серии публикаций, до того как этот сайт был законсервирован в конце 2022 года и серия была прервана. Переопубликована здесь с разрешения, с небольшими правками.)

За всю мою карьеру в сфере данных, как внутри Microsoft, так и в качестве консультанта, я обнаружил, что одна из самых непонятых частей SQL Server — это журнал транзакций. Недостаток знаний о том, как работает журнал транзакций и как им нужно управлять, или просто распространённые заблуждения, могут привести к различным проблемам в производственной среде, включая:

• Неуправляемый рост журнала транзакций и потенциальное исчерпание свободного места.
• Проблемы с производительностью из-за повторяющихся операций сжатия журнала транзакций.
• Проблемы с производительностью из-за явления, известного как фрагментация виртуальных файлов журнала (VLF), о котором я писал в этой статье.
• Невозможность восстановить базу данных до желаемой точки во времени с использованием резервных копий журнала транзакций.
• Невозможность выполнить резервное копирование заключительного фрагмента журнала (tail-log backup) во время аварийного восстановления (см. здесь объяснение таких копий).
• Различные проблемы, связанные с переключением при отказе (failover) и производительностью восстановления.

С этой статьи я начинаю серию публикаций (теперь уже здесь, в моём блоге SQLskills) о журнале транзакций: как он работает и как им следует управлять, и в её рамках я затрону все перечисленные выше проблемы. В этой статье я объясню, что такое журналирование и почему оно необходимо.

Миф: Переход на зеркальный сервер при зеркалировании баз данных происходит мгновенно

Автор: Paul Randal, A SQL Server DBA myth a day: (11/30) database mirroring failover is instantaneous;

Переход на реплику при зеркальном отображении баз данных происходит мгновенно

ЛОЖЬ

Переход на зеркальный сервер (failover) может происходить автоматически или быть инициирован вручную.

Автоматический переход выполняется зеркальным сервером (да, именно зеркальным сервером, а не сервером-свидетелем), если зеркальный сервер и сервер-свидетель приходят к согласию, что не могут связаться с основным сервером (этот процесс называется формированием кворума), и состояние сеанса зеркалирования — SYNCHRONIZED (т.е. на основном сервере не было непереданных записей журнала).

Ручной переход выполняете вы — либо потому, что сервер-свидетель отсутствовал (и, следовательно, зеркальный сервер никогда не сможет сформировать кворум, необходимый для автоматического перехода), либо потому, что состояние сеанса зеркалирования на момент выхода из строя основного сервера было отличным от SYNCHRONIZED.

А может, вам вообще не стоит использовать кластеризацию или группы доступности

Автор: Brent Ozar, Maybe You Shouldn’t Even Be Using Clustering or AGs.

Сандра Делани написала хорошо продуманную запись в блоге под названием Должен ли SQL Server DBA разбираться в Windows Server Failover Clustering? У неё около 20 лет опыта работы администратором баз данных, и она работает консультантом в Straight Path (компании, которую я уважаю). Вы, вероятно, можете догадаться, исходя из её опыта, что да, она считает, что вы должны знать, как настроить, сконфигурировать и устранять неполадки в кластерах Windows. Это хорошая статья, и вам стоит её прочитать.

Но... я не согласен.

Вы задумывались о том, чтобы не использовать высокую доступность SQL Server?

Автор: Chrissy LeMaire, Have You Considered Not Using SQL Server High Availability?

Когда кто-то спрашивает об архитектуре SQL Server, рефлекторным ответом обычно становится «Высокая доступность» (High Availability, HA), будто это требование, а не выбор. Но после 20 лет управления средами SQL Server я обнаружила, что высокая доступность часто создаёт больше проблем, чем решает, особенно в организациях определённого типа.

Миф: Зеркалирование баз данных мгновенно обнаруживает сбои

Автор: Paul Randal, A SQL Server DBA myth a day: (10/30) database mirroring detects failures immediately

Database Mirroring мгновенно обнаруживает сбои

ЛОЖЬ

Маркетинговый ажиотаж вокруг зеркалирования баз данных утверждает, что оно обеспечивает мгновенное обнаружение сбоев и мгновенный переход на резервный сервер.

Это не так. Скорость обнаружения сбоя зависит, среди прочего, от того, что именно вышло из строя.

Миф: Несколько зеркал и задержка применения журналов при доставке журналов

Автор: Paul Randal, A SQL Server DBA myth a day: (7/30) multiple mirrors and log shipping load delays

У базы данных может быть несколько зеркал

ЛОЖЬ

Этот миф довольно однозначен — зеркальное отображение баз данных позволяет создавать только одно зеркало для каждой основной базы данных. Если вам нужно несколько копий основной базы данных, рассмотрите возможность использования доставки журналов. Вы можете иметь столько вторичных серверов доставки журналов, сколько вам нужно.

Ещё одна классная особенность доставки журналов заключается в том, что для одного из вторичных серверов можно установить задержку применения, скажем, в 8 часов. Это означает, что резервные копии журналов, сделанные на основном сервере (не правда ли забавно, что в разных технологиях используется разная терминология:

• зеркалирование баз данных: основной — зеркальный
• доставка журналов: основной — вторичный
• репликация: издатель — подписчик

Ладно… эта вводная часть как-то сама по себе развилась…) не будут восстановлены на вторичном сервере доставки журналов, пока не пройдёт 8 часов. Если кто-то удалит таблицу в рабочей среде, она почти сразу же исчезнет и в зеркале (с какой-то задержкой, зависящей от состояния очередей SEND и WAIT в тот момент — но вы не можете остановить этот процесс), а вот на вторичном сервере доставки журналов с задержкой применения таблица останется нетронутой.

Кстати, команда SQLCAT написала очень хорошую статью, разоблачающую миф (который происходит из документации Books Online) о том, что можно зеркалировать только 10 баз данных на один экземпляр — см. Mirroring a Large Number of Databases in a Single SQL Server Instance. Также взгляните на статью базы знаний, которую я написал для CSS, где обсуждается то же самое: KB 2001270 Предварительные условия, ограничения и рекомендации по зеркальному отображению базы данных.

Мифы для DBA: незавершённые транзакции продолжаются после отработки отказа

Автор: Paul Randal, A SQL Server DBA myth a day: (1/30) in-flight transactions continue after a failover

Миф: После отработки отказа любые незавершённые транзакции продолжаются.

ЛОЖЬ

Каждый раз, когда происходит отработка отказа, должно произойти какое-то восстановление после сбоя. Если транзакция не была зафиксирована на сервере, к которому было подключение, когда сервер/база данных перестал работать, нет способа, чтобы SQL Server автоматически воссоздал весь контекст транзакции и восстановил незавершённую транзакцию на сервере, принимающем отказ — независимо от того, использовалась ли для отработки отказа кластеризация, зеркалирование, доставка журналов или репликация SAN.

Загадочный случай… усечения журнала в распределённой группе доступности

Автор: Paul Randal, The Curious Case of… log truncation in a distributed availability group

Это вопрос, который пришёл по электронной почте от бывшего студента, и я резюмирую его так: каковы семантика усечения журнала в распределённой группе доступности?

Поскольку я не эксперт по группам доступности (я просто знаю достаточно, чтобы быть опасным, ха-ха), я попросил Джонатана подключиться, так как он определённо эксперт по группам доступности! Я буду сокращать до AG термин группа доступности и DAG для распределённой группы доступности в объяснении ниже. Для предстоящего обсуждения неважно, имеют ли рассматриваемые AG синхронные или асинхронные реплики.

Обновление до SQL Server 2025: три извлечённых урока

Автор: Aaron Bertrand , Upgrading to SQL Server 2025: Three Lessons Learned

Мы недавно обновили несколько систем до SQL Server 2025. Само обновление ядра прошло гладко, но в наших контурах предварительной подготовки, когда мы планировали переход в прод, возникли три неожиданные проблемы. Ни одна из них не помешала завершению обновления, но все три могли легко сорвать в остальном плавное обновление на месте до SQL Server 2025. Что это были за проблемы и как можно избежать их возникновения?

Новое в SQL Server 2022: снимки баз и интеграция с S3

Автор: Chetna Bhalla, SQL Server 2022: Transforming Storage with Snapshots and S3 Integration

В SQL Server 2022 появились снимки на уровне хранилища для почти мгновенного восстановления и встроенную поддержку совместимых с S3 хранилищ объектов для масштабируемых и экономичных резервных копий и запросов к внешним данным.

Microsoft SQL Server уже давно является одним из лидеров корпоративного управления данными, обеспечивая работу критически важных приложений в самых разных отраслях. С выпуском SQL Server 2022 компания Microsoft сделала смелый шаг к модернизации взаимодействия баз данных с подсистемами хранения. Новшества сосредоточены на мгновенном восстановлении с помощью снимков и на нативной интеграции с хранилищами объектов, совместимыми с S3, — обе возможности призваны удовлетворить растущие потребности гибридных облачных сред, аналитики по большим данным и систем высокой доступности.

В этой статье подробно рассматриваются эти инновации — не только то, что они делают, но и почему это важно для администраторов баз данных, разработчиков и организаций, работающих в современном мире, где всем управляют данные.

Новое в SQL Server 2025: Always On, AG и FCI

Автор: David Levy, Announcing General Availability of the mssql-python Driver

Дата релиза SQL Server 2025: 18 ноября 2025 г.

В этой статье собран подробный обзор нововведений Always On в SQL Server 2025: быстрый фейловер при устойчивых проблемах, ускорение синхронизации при переключениях, улучшения отказоустойчивости после кратковременной потери кворума, усиление безопасности соединений (TLS 1.3 и TDS 8.0), гибкость управления прослушивателями и маршрутизацией трафика, а также поддержка полноценных резервных копий на вторичных репликах. Материал ориентирован на проектирование, внедрение и эксплуатацию HA/DR решений. Подготовлено с помощью GPT5.