Справочник

Критически важная база данных SQL требует SLA 99,995%, зоноизбыточную высокую доступность и возможности масштабирования для чтения.

→Разверните Azure SQL Database, используя уровень обслуживания Business Critical с включенной зоновой избыточностью.

Почему: Уровень Business Critical обеспечивает самый высокий SLA, использует локальные SSD для низкой задержки и включает встроенные доступные для чтения вторичные реплики без дополнительной платы. Уровень General Purpose имеет более низкий SLA и не имеет встроенных реплик для чтения.

Источник↗

База данных имеет непредсказуемые, прерывистые паттерны использования с длительными периодами простоя. Оптимизация затрат имеет решающее значение.

→Разверните Azure SQL Database, используя уровень General Purpose с бессерверной моделью вычислений.

Почему: Бессерверная модель автоматически масштабирует вычисления в зависимости от спроса и может автоматически приостанавливаться во время бездействия, взимая плату только за хранилище. Это более экономично, чем Provisioned compute, для нерерывных рабочих нагрузок.

Источник↗

Миграция локального SQL Server, который сильно зависит от таких функций, как SQL Server Agent, междоменные запросы и Service Broker.

→Мигрируйте в Azure SQL Managed Instance.

Почему: Managed Instance предлагает почти 100% совместимость с локальным SQL Server, сохраняя функции на уровне экземпляра, недоступные в Azure SQL Database.

Источник↗

Приложению требуется доступ на уровне ОС, доступ к файловой системе (например, для Filestream) или функции, не поддерживаемые предложениями PaaS, такие как CLR с EXTERNAL_ACCESS.

→Разверните SQL Server на виртуальной машине Azure (IaaS).

Почему: IaaS предоставляет полный контроль над операционной системой и экземпляром SQL Server, предлагая максимальную совместимость с локальными конфигурациями за счет увеличения накладных расходов на управление.

Ожидается, что база данных вырастет за пределы 4 ТБ, до 100 ТБ, и требует быстрого масштабирования хранилища и быстрого восстановления.

→Разверните Azure SQL Database, используя уровень обслуживания Hyperscale.

Почему: Hyperscale разработан для Very Large Databases (VLDBs), предлагая до 100 ТБ хранилища, которое масштабируется автоматически. Он использует уникальную архитектуру с серверами страниц для быстрого восстановления базы данных с постоянным временем, независимо от размера.

Источник↗

Приложение SaaS размещает множество небольших баз данных с переменными, непредсказуемыми паттернами использования. Необходимо оптимизировать затраты при предоставлении общих ресурсов.

→Сгруппируйте базы данных в Elastic Pool Azure SQL Database.

Почему: Elastic pools позволяют нескольким базам данных совместно использовать набор ресурсов (eDTUs или vCores) по фиксированной цене, что более экономично, чем выделение отдельных баз данных, когда использование не является постоянным для всех клиентов.

Развертывание Azure SQL Managed Instance в виртуальную сеть.

→Создайте выделенную подсеть с минимальным размером /27 (32 адреса) и делегируйте ее Microsoft.Sql/managedInstances.

Почему: Managed Instance требует выделенной, пустой подсети с достаточным количеством IP адресов для своих внутренних компонентов и будущего масштабирования. /27 — это минимальный поддерживаемый размер.

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

→Используйте Azure Database Migration Service (DMS) в режиме онлайн-миграции.

Почему: Онлайн-миграция DMS выполняет начальную загрузку, а затем использует непрерывную синхронизацию данных (передачу журналов) для поддержания синхронизации целевого объекта, что обеспечивает очень короткое окно переключения.

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

→Используйте Premium SSD. Настройте кэширование хоста только для чтения для файлов данных и "None" для файлов журналов.

Почему: Кэширование только для чтения оптимально для больших последовательных чтений, распространенных в хранилищах данных. Для файлов журналов кэширование должно быть отключено для обеспечения долговечности записи и предотвращения потери данных.

Политика безопасности требует, чтобы все подключения к базе данных были зашифрованы и проверяли сертификат сервера.

→Установите минимальную версию TLS на сервере на 1.2. В строках подключения клиента используйте `Encrypt=Strict`.

Почему: Установка минимальной версии TLS на сервере предотвращает небезопасное согласование протоколов. `Encrypt=Strict` (TDS 8.0+) обеспечивает шифрование и полную проверку сертификата, предотвращая атаки типа "man-in-the-middle".

Конфиденциальные данные в определенных столбцах (например, SSN) должны быть зашифрованы, но приложению необходимо выполнять поиск по равенству и объединения по зашифрованным данным.

→Используйте Always Encrypted с детерминированным шифрованием для столбцов, по которым возможен поиск.

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

Требуется шифрование неактивных данных, но организация должна полностью контролировать ключи шифрования.

→Включите Transparent Data Encryption (TDE) с управляемыми клиентом ключами (BYOK), хранящимися в Azure Key Vault.

Почему: Эта конфигурация позволяет организации управлять жизненным циклом ключей (ротация, отзыв) в их собственном Key Vault, обеспечивая контроль и удовлетворяя требованиям соответствия для владения ключами.

Azure SQL Database должна быть доступна только из определенной виртуальной сети Azure, при этом публичный доступ к интернету полностью заблокирован.

→Настройте Private Endpoint для SQL Server и установите "Deny public network access" в положение Yes.

Почему: Private Endpoint предоставляет базе данных SQL приватный IP-адрес внутри вашей VNet. Отключение публичного доступа гарантирует, что это единственный способ подключения, обеспечивая полную сетевую изоляцию.

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

→Реализуйте Row-Level Security (RLS), создав предикат безопасности (встраиваемую табличную функцию) и политику безопасности, которая применяет его к таблице.

Почему: RLS прозрачно фильтрует строки на основе контекста пользователя (например, USER_NAME() или SESSION_CONTEXT), обеспечивая изоляцию данных на уровне движка базы данных без изменений в приложении.

Администраторы баз данных должны управлять базой данных, но не должны иметь возможность просматривать конфиденциальные данные в определенных столбцах.

→Реализуйте Dynamic Data Masking (DDM) для конфиденциальных столбцов. Не предоставляйте разрешение UNMASK администраторам баз данных.

Почему: DDM скрывает данные в результатах запросов для непривилегированных пользователей, не изменяя хранимые данные. Это позволяет администраторам баз данных выполнять свои обязанности, одновременно предотвращая просмотр ими фактической конфиденциальной информации.

Политика безопасности требует отключения аутентификации SQL для обеспечения централизованного управления идентификацией и MFA для Azure SQL DB или Managed Instance.

→Установите администратора Azure AD для сервера и включите свойство "Azure AD-only authentication".

Почему: Эта настройка полностью отключает конечную точку аутентификации SQL, заставляя все подключения использовать Azure AD. Это критически важный шаг для обеспечения современных политик аутентификации.

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

→Включите Microsoft Defender for SQL (ранее Advanced Threat Protection).

Почему: Defender for SQL анализирует журналы базы данных на предмет подозрительной активности и генерирует оповещения безопасности, предоставляя важный уровень обнаружения угроз, выходящий за рамки базовых средств контроля доступа.

Журналы аудита для Azure SQL Database должны храниться в течение нескольких лет и быть доступными для поиска для целей соответствия и расследований безопасности.

→Настройте Azure SQL Auditing для отправки журналов в рабочую область Log Analytics с настроенным необходимым сроком хранения данных.

Почему: Log Analytics обеспечивает долгосрочное хранение и мощные возможности запросов на основе KQL, что делает его превосходящим Blob Storage для поиска и долгосрочных аудиторских данных.

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

→Используйте Azure AD Privileged Identity Management (PIM) для управления правом на членство в группе Azure AD, имеющей доступ к базе данных.

Почему: PIM предоставляет доступ Just-in-Time (JIT), который поддается аудиту, требует обоснования и автоматически истекает, придерживаясь принципа наименьших привилегий.

Система требует проверяемой, защищенной от подделок истории всех модификаций данных для соблюдения строгих нормативных требований.

→Используйте функцию Ledger в Azure SQL Database.

Почему: Таблицы Ledger используют концепции блокчейна для криптографической привязки изменений данных, создавая неизменяемую историю, которая может быть независимо проверена. Это надежнее, чем темпоральные таблицы, которые не защищены от подделок.

База данных испытывает снижение производительности. Необходимо выявить запросы, потребляющие больше всего ресурсов, отслеживать изменения планов и находить регрессии производительности.

→Включите и используйте Query Store.

Почему: Query Store — это встроенный "бортовой самописец" производительности запросов. Он автоматически собирает историю запросов, планы и статистику ожиданий, что делает его основным инструментом для диагностики проблем производительности с течением времени.

Источник↗

Запрос иногда выполняется хорошо, а иногда плохо из-за проблем с перехватом параметров, когда план выполнения оптимизирован для нерепрезентативного значения параметра.

→Используйте Query Store для выявления различных планов и принудительного использования постоянно хорошего плана выполнения.

Почему: Принудительное применение плана в Query Store обеспечивает быстрый и эффективный способ стабилизации производительности для проблемных запросов без изменения кода. Оно переопределяет выбор оптимизатора известным хорошим планом.

Для повышения производительности запросов без изменения кода путем использования таких функций, как пакетный режим для rowstore, обратная связь по выделению памяти и отложенная компиляция табличных переменных.

→Установите уровень совместимости базы данных на 150 (для функций SQL 2019) или выше.

Почему: Набор функций Intelligent Query Processing (IQP) активируется уровнем совместимости базы данных. Уровень 150+ активирует широкий спектр улучшений производительности "без изменения кода" в обработчике запросов.

Команда операций должна получать уведомления, когда ключевые метрики производительности, такие как процент использования ЦП или взаимоблокировки, превышают определенный порог.

→Используйте Azure Monitor для создания оповещений метрик (для ЦП) и оповещений журналов (для взаимоблокировок), которые запускают Action Group.

Почему: Azure Monitor — это централизованная платформа для мониторинга и оповещения о ресурсах Azure. Action Groups предоставляют гибкие каналы уведомлений (электронная почта, SMS, webhook и т. д.).

Повышение производительности записи путем выявления и удаления индексов, которые не используются никакими запросами на чтение.

→Запросите DMV `sys.dm_db_index_usage_stats`.

Почему: Эта DMV отслеживает использование индексов (поиски, сканирования, просмотры) по сравнению с обновлениями. Индексы с большим количеством обновлений, но нулевым или очень низким использованием являются основными кандидатами на удаление, что снижает накладные расходы на обслуживание.

Необходимо собрать подробную информацию о периодических проблемах блокировки, включая операторы и сеансы, участвующие в цепочке блокировки.

→Настройте сеанс Extended Events, который фиксирует событие `blocked_process_report`.

Почему: Это событие предоставляет подробный XML-отчет о цепочках блокировки при превышении `blocked process threshold`, предлагая глубокую диагностическую информацию, недоступную в DMV.

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

→Включите опцию CREATE_INDEX в автоматической настройке Azure SQL Database.

Почему: Эта функция позволяет Azure анализировать рабочую нагрузку, выявлять отсутствующие индексы с высоким влиянием, создавать их и проверять их выгоду для производительности, автоматизируя ключевую задачу DBA.

Перенесите рабочие нагрузки отчетов, интенсивно использующие чтение, с основной базы данных OLTP на уровне Business Critical или Premium.

→Измените строки подключения приложения только для чтения, чтобы включить `ApplicationIntent=ReadOnly`.

Почему: Эти уровни включают бесплатную, встроенную реплику для чтения. Свойство `ApplicationIntent` в строке подключения автоматически направляет соединения только для чтения на эту реплику, изолируя рабочие нагрузки чтения.

Большая таблица фактов в хранилище данных часто используется для запросов агрегации (SUM, COUNT, AVG), которые выполняются медленно.

→Создайте кластеризованный columnstore index на таблице фактов.

Почему: Columnstore indexes хранят данные в столбцовом формате, обеспечивая очень высокую степень сжатия данных и позволяя выполнять пакетный режим, что значительно ускоряет агрегацию и аналитические запросы с интенсивным сканированием.

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

→Включите Read Committed Snapshot Isolation (RCSI) в базе данных.

Почему: RCSI использует управление версиями строк, позволяя читателям видеть последнюю зафиксированную версию данных без установки общих блокировок, тем самым устраняя блокировки от писателей. Писатели не блокируют читателей.

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

→Уменьшите задержку авто-паузы или настройте минимальное значение vCore больше нуля.

Почему: Задержка вызвана возобновлением работы базы данных из приостановленного состояния ("холодный старт"). Установка минимального значения vCore предотвращает полную приостановку работы базы данных, устраняя задержку возобновления за счет некоторой постоянной оплаты вычислений.

Реализуйте конвейер CI/CD для автоматизированного, версионированного и повторяемого развертывания схемы базы данных.

→Используйте SQL Database Project (например, в Visual Studio) для генерации файла DACPAC. Используйте конвейеры Azure DevOps для развертывания DACPAC.

Почему: Это стандартный шаблон Infrastructure as Code (IaC) для схемы SQL. DACPAC является декларативной моделью схемы, а инструменты развертывания обрабатывают генерацию дифференциального скрипта, обеспечивая согласованность.

Azure SQL Database должна автоматически масштабироваться вверх или вниз на основе расписания или пороговых значений метрик (например, высокого использования ЦП).

→Используйте runbook Azure Automation (PowerShell), запускаемый по расписанию или оповещением Azure Monitor.

Почему: Azure SQL Database (уровень Provisioned) не имеет встроенного автомасштабирования. Azure Automation — это стандартный инструмент для оркестровки такого рода операционных задач с использованием скриптов и расписаний.

Скрипт обслуживания (например, перестроение индекса) необходимо выполнить для сотен Azure SQL баз данных.

→Используйте Elastic Jobs.

Почему: Elastic Jobs — это PaaS-сервис, разработанный специально для запуска T-SQL заданий в целевой группе баз данных, централизованно управляющий учетными данными, расписанием и логированием.

Убедитесь, что все вновь созданные Azure SQL Servers в подписке имеют определенную функцию, например TDE или Auditing, включенную по умолчанию.

→Создайте Azure Policy с эффектом `DeployIfNotExists` или `Modify`.

Почему: Azure Policy обеспечивает управление в масштабе. Эффект `DeployIfNotExists` автоматически настроит отсутствующую настройку во время создания ресурса, обеспечивая соответствие без ручного вмешательства.

Запланируйте повторяющийся T-SQL скрипт или задачу обслуживания на Azure SQL Managed Instance.

→Используйте встроенный SQL Server Agent.

Почему: Managed Instance включает полный SQL Server Agent, предоставляя те же привычные возможности планирования заданий, что и локальный SQL Server, без необходимости использования внешнего сервиса автоматизации.

Контролируйте, когда Azure выполняет плановое обслуживание Azure SQL Database или Managed Instance, чтобы минимизировать влияние на бизнес-операции.

→Настройте Maintenance Window для ресурса.

Почему: Эта функция позволяет выбрать предопределенный временной интервал (например, выходные) для применения обновлений Azure, обеспечивая предсказуемость в отношении обслуживания, влияющего на работу сервиса.

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

→Настройте Auto-Failover Group между основной и вторичной базами данных/экземплярами.

Почему: Failover groups предоставляют конечные точки прослушивателей для чтения-записи и только для чтения. Эти конечные точки автоматически перенаправляют трафик на текущий основной/вторичный сервер после отработки отказа, делая процесс прозрачным для приложения.

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

→Настройте политику Long-Term Backup Retention (LTR).

Почему: Стандартные резервные копии Point-in-Time Restore (PITR) хранятся максимум 35 дней. LTR хранит полные резервные копии в отдельном Azure Blob Storage до 10 лет, специально для нужд соответствия.

База данных должна оставаться доступной во время сбоя центра обработки данных (Availability Zone) в одном регионе Azure.

→Включите зоноизбыточную конфигурацию для базы данных уровня Business Critical или Premium.

Почему: Зоновая избыточность развертывает синхронные вторичные реплики в разных физических центрах обработки данных в пределах одного региона, обеспечивая автоматическое переключение с RPO близким к нулю для сбоев на уровне зоны.

Azure SQL Managed Instance требует решения для аварийного восстановления в парном регионе Azure с возможностью автоматического переключения.

→Настройте Auto-Failover Group для Managed Instance.

Почему: Это канонический паттерн DR для Managed Instance, обеспечивающий асинхронную репликацию, конечные точки прослушивателей для прозрачного переключения приложения и опцию автоматического переключения.

Необходимо иметь возможность восстановить базу данных до любой конкретной секунды из прошедшего месяца.

→Настройте период краткосрочного хранения резервных копий (PITR) на 30-35 дней.

Почему: Azure SQL автоматически создает полные, дифференциальные и частые резервные копии журнала транзакций. Настройка срока хранения PITR (1-35 дней) определяет, как долго эти резервные копии хранятся, определяя окно для восстановления на определенный момент времени.

Настройка Windows Server Failover Cluster для SQL Server Always On Availability Group на виртуальных машинах Azure.

→Используйте Cloud Witness в качестве свидетеля кворума.

Почему: Cloud Witness использует Azure Blob Storage и является рекомендуемым, наиболее устойчивым вариантом для кластеров в Azure. Он устраняет необходимость в третьей виртуальной машине для свидетеля файлового ресурса или сложных конфигураций общего диска.

Реализация SQL Server Failover Cluster Instance (FCI) на виртуальных машинах Azure, который требует общего хранилища.

→Используйте Azure Shared Disks (подключение управляемого диска к нескольким виртуальным машинам).

Почему: Azure Shared Disks — это нативное решение Azure для предоставления блочного хранилища, доступ к которому могут получить несколько виртуальных машин, что является необходимым условием для традиционного FCI.

Процесс аварийного восстановления для группы отработки отказа необходимо протестировать без влияния на основную производственную базу данных.

→Инициируйте плановое (ручное) переключение во время окна обслуживания с низким воздействием, проверьте подключение приложения, а затем выполните обратное переключение.

Почему: Плановое переключение обеспечивает отсутствие потери данных и является наиболее тщательным способом проверки всего процесса DR, включая распространение DNS и повторное подключение приложения. Это краткое, контролируемое событие в производстве.