Новый администратор базы данных в облаке: управление базой данных SQL Azure после миграции

Применимо к:База данных SQL Azure

На начальном этапе переход от традиционной самостоятельно управляемой, полностью контролируемой среды к среде PaaS может показаться невозможным. Как разработчик или администратор базы данных вы должны знать все основные возможности платформы, что, в свою очередь, позволит обеспечить постоянную доступность, производительность, безопасность и отказоустойчивость приложения. В этой статье в краткой форме представлены все соответствующие сведения. В данной статье приведены ресурсы и полезные рекомендации по эффективному использованию основных возможностей базы данных Azure SQL с отдельными базами данных и базами данных в пуле, а также сведения по обеспечению эффективной работы приложений и оптимальному использованию облака. Целевая аудитория:

• пользователи, планирующие перенос приложений в Базу данных SQL Azure (модернизация приложений);
• пользователи, выполняющие перенос приложений (текущий сценарий переноса);
• пользователи, которые недавно выполнили миграцию в базу данных SQL Azure с новым администратором базы данных в облаке.

В этой статье рассматриваются некоторые из основных характеристик Базы данных SQL Azure как готовой к использованию платформы во время работы с отдельными базами данных и базами данных в пуле в составе эластичного пула. Они следующие:

• Мониторинг баз данных с помощью портала Azure
• Непрерывность бизнес-процессов и аварийное восстановление (BCDR)
• Безопасность и соответствие требованиям
• интеллектуальный мониторинг и обслуживание базы данных;
• Перемещение данных

Примечание.

Идентификатор Microsoft Entra ранее был известен как Azure Active Directory (Azure AD).

Мониторинг баз данных с помощью портала Azure

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

• Процент использования ЦП
• Процент использования DTU
• Процент ввода-вывода данных
• Размер базы данных в процентах

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

Также можно настроить оповещения для метрик производительности. Нажмите кнопку "Добавить оповещение" в окне "Метрика". Следуйте инструкциям мастера для настройки оповещения. Можно настроить предупреждение, информирующее либо о превышении показателями определенного порога, либо о падении показателей ниже определенного порога.

Например, если предполагается, что рабочая нагрузка базы данных будет расти, можно настроить отправку оповещения по электронной почте каждый раз, когда любой из показателей производительности для вашей базы данных достигнет 80%. Это оповещение можно использовать как предварительное предупреждение о том, что необходимо перейти на следующий максимальный объем вычислительных ресурсов.

Метрики производительности также помогут определить, можно ли перейти на более низкий размер вычислительных ресурсов. Предположим, что вы используете базу данных S2 уровня "Стандартный" и все метрики производительности показывают, что база данных в среднем не использует более 10 % в любое время. Скорее всего, база данных будет работать хорошо в standard S1. Однако перед переходом на более низкий уровень производительности следует учитывать скачки и колебания объема вычислительных ресурсов.

Непрерывность бизнес-процессов и аварийное восстановление (BCDR)

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

Как создавать резервные копии в базе данных SQL и управлять ими

Вы не создаете резервные копии на База данных SQL Azure, и это связано с тем, что вам не нужно. Служба "База данных SQL" делает это автоматически, поэтому больше не нужно волноваться о планировании резервного копирования, создании резервных копий и управлении ими. Эта платформа создает полную резервную копию каждую неделю, разностную резервную копию каждые несколько часов и резервную копию журналов каждые 5 минут. Это позволяет гарантировать эффективность аварийного восстановления и минимальную потерю данных. Первая полная резервная копия создается сразу же после создания базы данных. Эти резервные копии доступны для вас в течение определенного периода, называемого периодом хранения, и зависит от выбранного уровня служб. Благодаря возможности восстановления на определенный момент времени служба "База данных SQL" позволяет восстанавливать данные на любой момент времени в пределах этого срока хранения.

Уровень служб	Период хранения в днях
Базовая	7
Стандартные	35
Premium	35

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

Как обеспечить непрерывность бизнес-процессов в случае аварии на уровне центра обработки данных или региональной катастрофы

Резервные копии базы данных хранятся в гео-реплика хранилище, чтобы гарантировать, что во время региональной аварии можно восстановить резервную копию в другом регионе Azure. Это называется геовосстановлением. RPO (цель точки восстановления) для геовосстановление обычно < составляет 1 час, а ERT (предполагаемое время восстановления) — несколько минут до часов.

Для критически важных баз данных База данных SQL Azure предлагает активную геоза реплика, которая создает гео-реплика торичную копию исходной базы данных в другом регионе. Например, если база данных изначально размещена в регионе Azure "Западная часть США" и требуется региональная устойчивость к катастрофам, создайте активную гео реплика базы данных в западной части США на востоке США. Когда бедствие ударяет по западной части США, вы можете выполнить отработку отказа в регионе "Восточная часть США".

Помимо активного геоза реплика, группы отработки отказа предоставляют удобный способ управления реплика и отработкой отказа группы баз данных. Вы можете создать группу отработки отказа, содержащую несколько баз данных в одном или разных регионах. Затем можно инициировать отработку отказа всех баз данных в группе отработки отказа в дополнительный регион. Дополнительные сведения см. в разделе "Группы отработки отказа".

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

Активно отслеживайте приложение для аварии и инициируйте отработку отказа на дополнительный объект. Вы можете создать до четырех таких активных гео-реплика в разных регионах Azure. Это еще лучше. Кроме того, к этим георепликам можно предоставлять доступ только для чтения. Это довольно удобный способ сократить задержку в сценариях с использованием географически распределенного приложения.

Как выглядит аварийное восстановление с помощью База данных SQL

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

Дополнительные сведения см. в разделе База данных SQL Azure аварийного восстановления 101.

Безопасность и соответствие требованиям

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

• Идентификация и проверка подлинности (проверка подлинности и проверка подлинности SQL с помощью идентификатора Microsoft Entra (ранее — Azure Active Directory).
• мониторинг действий (аудит и обнаружение угроз);
• защита фактических данных (прозрачное шифрование данных [TDE] и применение технологии Always Encrypted [AE]);
• управление доступом к конфиденциальным и привилегированным данным (безопасность на уровне строк и динамическое маскирование данных).

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

Какие методы проверки подлинности доступны в службе "База данных SQL"

В службе "База данных SQL" доступны два метода проверки подлинности:

• Проверка подлинности Microsoft Entra
• Проверка подлинности SQL.

проверка подлинности Windows не поддерживается. Идентификатор Microsoft Entra — это централизованная служба управления удостоверениями и доступом. Благодаря ей вы можете очень легко предоставлять возможности единого входа (SSO) сотрудникам организации. Это значит, что одни учетные данные используются в нескольких службах Azure, что упрощает проверку подлинности.

Идентификатор Microsoft Entra поддерживает многофакторную проверку подлинности и может легко интегрироваться с Windows Server Active Directory. Это также позволяет База данных SQL и Azure Synapse Analytics предлагать многофакторную проверку подлинности и гостевые учетные записи пользователей в домене Microsoft Entra. Если вы уже используете локальную среду Active Directory, вы можете настроить ее с идентификатором Microsoft Entra для расширения каталога в Azure.

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

Если вы...	База данных SQL / Azure Synapse Analytics
Использовали AD на локальном сервере SQL Server	Федеративный AD с идентификатором Microsoft Entra и используйте проверку подлинности Microsoft Entra. Федерация позволяет использовать единый вход.
Необходимость принудительного применения многофакторной проверки подлинности	Требовать многофакторную проверку подлинности в качестве политики с помощью условного доступа Майкрософт и использовать многофакторную проверку подлинности Microsoft Entra.
Вход в Windows с помощью учетных данных Microsoft Entra из федеративного домена	Используйте встроенную проверку подлинности Microsoft Entra.
Входите в систему Windows с помощью учетных данных из домена, который не включен в федерацию с Azure	Используйте встроенную проверку подлинности Microsoft Entra.
Используете службы среднего уровня, которые нужно подключить к базе данных SQL или Azure Synapse Analytics	Используйте встроенную проверку подлинности Microsoft Entra.
Иметь техническое требование для использования проверки подлинности SQL	Используйте проверку подлинности SQL.

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

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

• Правила брандмауэра
• Конечные точки службы виртуальной сети
• Зарезервированные IP-адреса

Брандмауэр

Брандмауэр блокирует доступ к серверу из внешних сущностей. Доступ к логическому серверу предоставляется только определенным сущностям. По умолчанию все подключения к базам данных на сервере запрещены, кроме подключений других служб Azure (их можно разрешить при необходимости). С помощью правила брандмауэра вы можете открыть доступ к серверу только к сущностям (например, компьютеру разработчика), который вы утверждаете, разрешая IP-адрес этого компьютера через брандмауэр. Кроме того, можно указать диапазон IP-адресов, которым будет разрешен доступ к серверу. Например, на странице "Параметры брандмауэра" можно указать диапазон IP-адресов всех компьютеров разработчиков в организации.

Правила брандмауэра можно создавать на уровне сервера и базы данных. Правила брандмауэра для IP-адресов на уровне сервера можно создавать с помощью портала Azure или с помощью SSMS. Дополнительные сведения о настройке правил брандмауэра на уровне сервера и базы данных см. в разделе Создание правил брандмауэра для IP-адресов в базе данных SQL.

Конечные точки служб

По умолчанию база данных настроена на "Разрешить службам и ресурсам Azure доступ к этому серверу", что означает, что любая виртуальная машина в Azure может попытаться подключиться к базе данных. Эти попытки по-прежнему должны пройти проверку подлинности. Если вы не хотите, чтобы база данных была доступна любым IP-адресом Azure, вы можете отключить параметр "Разрешить службам и ресурсам Azure доступ к этому серверу". Кроме того, можно настроить конечные точки службы виртуальной сети.

Конечные точки службы позволяют предоставлять важные ресурсы Azure только в собственной частной виртуальной сети Azure. Это позволяет существенно ограничить общий доступ к ресурсам. Трафик между виртуальной сетью и Azure остается в магистральной сети Azure. Без конечной точки службы выполняется маршрутизация пакетов с принудительным туннелированием. Виртуальная сеть принудительно передает интернет-трафик в организацию, а трафик службы Azure проходит через тот же маршрут. Конечные точки службы позволяют оптимизировать это поведение с момента прохождения пакетов из виртуальной сети к службе в магистральной сети Azure.

Зарезервированные IP-адреса

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

Через какой порт устанавливается подключение к службе "База данных SQL"

База данных SQL обменивается данными через порт 1433. Чтобы подключиться из корпоративной сети, в параметрах брандмауэра организации необходимо добавить правило для исходящего трафика. Советуем не предоставлять доступ к порту 1433 за пределами границ Azure.

Как отслеживать и контролировать действия на сервере и в базе данных в службе "База данных SQL"

Аудит базы данных SQL

В службе "База данных SQL" можно включить аудит событий базы данных. Эта функция позволяет отслеживать записи базы данных и записывать их в файл журнала аудита в учетной записи хранения Azure. Аудит особенно полезен, если необходимо получать аналитические сведения о потенциальных нарушениях безопасности и политик, обеспечивать соответствие нормативным требованиям и т. д. Он позволяет определять и настраивать определенные категории событий, требующих аудита, а также просматривать события базы данных с помощью предварительно настроенных отчетов и панелей мониторинга. Эти политики аудита можно применить на уровне базы данных или сервера. Сведения о том, как включить аудит сервера или базы данных, см. в этом разделе.

Обнаружение угроз

Функция обнаружения угроз позволяет легко устранять нарушения безопасности и политик, обнаруженные в процессе аудита. Вам не нужно быть экспертом по безопасности для решения потенциальных угроз или нарушений в вашей системе. Эта функция также предоставляет дополнительные встроенные возможности, такие как обнаружение атак путем внедрения кода SQL. Внедрение кода SQL — это попытка изменить или компрометировать данные. Это довольно распространенный способ атаки на приложения базы данных в целом. Обнаружение угроз выполняет множество наборов алгоритмов, которые обнаруживают потенциальные уязвимости и атаки путем внедрения кода SQL, а также аномальные шаблоны доступа к базе данных (например, доступ из необычного расположения или незнакомым субъектом). Сотрудники службы безопасности или другие назначенные администраторы получают уведомление по электронной почте, если в базе данных обнаружена угроза. Каждое уведомление содержит сведения о подозрительном действии и рекомендации по дальнейшему исследованию и снижению угрозы. Дополнительные сведения о включении обнаружения угроз см. в разделе Включение обнаружения угроз.

Как защитить данные в службе "База данных SQL"

Шифрование обеспечивает надежный механизм защиты конфиденциальных данных от несанкционированного доступа. Злоумышленники не смогут воспользоваться зашифрованными данными без ключа расшифровки. Это добавляет дополнительный уровень защиты поверх встроенных в службе "База данных SQL" уровней. Существует два способа защиты данных в службе "База данных SQL":

• защита неактивных данных в файлах журналов и данных;
• защита активных данных.

По умолчанию неактивные данные в службе "База данных SQL" хранятся в файлах данных и журналов в подсистеме хранения. Эти данные постоянно шифруются с помощью функции прозрачного шифрования. Резервные копии также шифруются. Благодаря прозрачному шифрованию на стороне приложения, которое обращается к данным, не нужно вносить никаких изменений. Шифрование и расшифровка происходит прозрачно (отсюда и название). Защита активных и неактивных конфиденциальных данных в службе "База данных SQL" осуществляется с помощью функции Always Encrypted. AE — это форма шифрования на стороне клиента, которая шифрует конфиденциальные столбцы в базе данных (поэтому они в шифре для администраторов баз данных и несанкционированных пользователей). Сначала сервер получает зашифрованные данные. Ключ постоянного шифрования также хранится на стороне клиента, поэтому только авторизованные клиенты могут расшифровывать конфиденциальные столбцы. Администраторы сервера и данных не могут видеть конфиденциальные данные, так как ключи шифрования хранятся на клиенте. Функция Always Encrypted выполняет сквозное шифрование конфиденциальных столбцов в таблице, что позволяет обеспечить защиту от несанкционированного доступа (от неавторизованных клиентов до физических дисков). Эта функция также поддерживает сопоставления равенства, поэтому администраторы баз данных могут продолжать запрашивать зашифрованные столбцы как часть своих команд SQL. Она может использоваться с различными вариантами хранения ключей, например с Azure Key Vault, хранилищем сертификатов Windows и локальными аппаратными модулями безопасности.

Характеристики	Always Encrypted	прозрачное шифрование данных.
Диапазон шифрования	Законченное решение	Неактивные данные
Сервер базы данных может обращаться к конфиденциальным данным	No	Да, так как шифруются неактивные данные
Разрешенные операции T-SQL	Сравнение на равенство	Доступна вся контактная зона T-SQL
Степень изменения приложения для использования этой функции	Минимальные	Минимальные
Гранулярность шифрования	На уровне столбцов	На уровне базы данных

Как ограничить доступ к конфиденциальным данным в базе данных

Каждое приложение содержит конфиденциальные данные в базе данных, которые необходимо защитить. Некоторые сотрудники организации должны просматривать эти данные, однако другие не должны просматривать эти данные. Рассмотрим пример с данными о зарплате сотрудников. Менеджеру потребуется доступ к информации о заработной плате для их прямых отчетов, однако отдельные члены команды не должны иметь доступа к информации о заработной плате своих сверстников. Рассмотрим еще один пример. На стадии разработки или тестирования разработчики данных взаимодействуют с конфиденциальными данными, например с номерами социального страхования (SSN). Эта информация еще раз не должна быть предоставлена разработчику. В таких случаях конфиденциальные данные либо нужно скрыть или вовсе не предоставлять к ним доступ. Чтобы предотвратить несанкционированный доступ к конфиденциальным данным, в службе "База данных SQL" предусмотрено два подхода:

Динамическое маскирование данных — это функция маскирования данных, которая позволяет ограничить доступ к конфиденциальным данным, маскируя их от непривилегированных пользователей на уровне приложения. Вы определяете правило маскирования, которое может создавать шаблон маскирования (например, показывать только последние четыре цифры номера социального страхования и отмечать остальное как X) и определять, каких пользователей можно исключить из правила. Маскирование выполняется в режиме реального времени. Разные категории данных поддерживают различные возможности маскирования. Функция динамического маскирования данных позволяет автоматически обнаруживать конфиденциальные данные в базе данных и применять к ним маскирование.

Функция Безопасность на уровне строк дает возможность управлять доступом на уровне строк. Это означает, что определенные строки в таблице базы данных скрыты в зависимости от характеристик пользователя, выполняющего запрос (например, членство в группе или контекст выполнения). Ограничение доступа выполняется на уровне базы данных вместо уровня приложения, чтобы упростить логику приложения. Сначала создайте предикат фильтра, отфильтровав строки, которые не предоставляются, и политика безопасности, следующая за тем, кто имеет доступ к этим строкам. Наконец, конечный пользователь выполняет свой запрос и, в зависимости от привилегий пользователя, они либо просматривают эти ограниченные строки, либо не могут видеть их вообще.

Как управлять ключами шифрования в облаке

Существуют возможности управления ключами и для Always Encrypted (шифрование на стороне клиента), и для прозрачного шифрования данных (шифрование при хранении). Рекомендуется регулярно менять ключи шифрования. Частота смены должна соответствовать внутренним правилам организации и нормативным требованиям.

Прозрачное шифрование данных (TDE)

В TDE существует двухключовая иерархия— данные в каждой пользовательской базе данных шифруются симметричным ключом шифрования базы данных AES-256 (DEK), который, в свою очередь, шифруется уникальным серверным асимметричным ключом RSA 2048. Управление главным ключом осуществляется:

• автоматически платформой (службой "База данных SQL");
• с помощью Azure Key Vault в качестве хранилища ключей.

По умолчанию для удобства главным ключом для прозрачного шифрования данных управляет служба базы данных SQL. Если ваша организация хотела бы контролировать главный ключ, есть возможность использовать Azure Key Vault в качестве хранилища ключей. С помощью Azure Key Vault ваша организация берет на себя управление подготовкой, сменой ключей и разрешениями. Смена или изменение типа главного ключа прозрачного шифрования данных выполняется быстро, так как повторно шифруется только ключ шифрования. В организациях, разделяющих роли безопасности и управления данными, администратор безопасности может предоставить материал главного ключа TDE в Azure Key Vault и предоставить идентификатор ключа Azure Key Vault администратору базы данных для использования в режиме шифрования неактивных данных на сервере. Хранилище ключей разработано таким образом, что корпорация Майкрософт не видит или извлекает ключи шифрования. Кроме того, вы можете обеспечить централизованное управление ключами организации.

Always Encrypted

В Always Encrypted также существует двух ключ иерархия — столбец конфиденциальных данных шифруется ключом шифрования AES 256-column (CEK), который, в свою очередь, шифруется главным ключом столбца (CMK). Клиентские драйверы, предоставленные для Always Encrypted, не имеют ограничений на длину CMK. Зашифрованное значение CEK сохраняется в базе данных, а CMK хранится в хранилище доверенных ключей, таком как хранилище сертификатов Windows, Azure Key Vault или аппаратный модуль безопасности.

• CEK и CMK можно менять.
• Замена CEK выполняется на уровне данных. В ​​зависимости от размера таблиц, содержащих зашифрованные столбцы, этот процесс может занимать много времени. Следовательно, разумно планировать смены CEK соответствующим образом.
• Однако смена CMK не влияет на производительность базы данных и может выполняться с разделенными ролями.

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

Как оптимизировать и защитить трафик между организацией и службой "База данных SQL"

Обычно сетевой трафик между организацией и службой "База данных SQL" перенаправляется через публичную сеть. Тем не менее, если вы решили оптимизировать этот путь и сделать его более безопасным, рассмотрите Azure ExpressRoute. ExpressRoute позволяет расширить корпоративную сеть до платформы Azure с помощью частного подключения. Таким образом, вы не перейдете через общедоступный Интернет. Это обеспечивает более высокий уровень безопасности и надежности, а также оптимизирует маршрутизацию, что, в свою очередь, позволяет снизить задержки сети и повысить быстродействие по сравнению с типичными подключениями через общедоступный Интернет. Если вы планируете передать значительный фрагмент данных между вашей организацией и Azure, использование ExpressRoute может повысить затраты. Доступно три разных модели подключения между организацией и Azure:

• совместное размещение в Cloud Exchange;
• подключение "любой к любому";
• подключения "точка — точка".

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

• Обзор ExpressRoute
• Необходимые условия
• Бизнес-процессы

Совместима ли база данных SQL с какими-либо нормативными требованиями и как это помогает соблюдению требований моей собственной организации

База данных SQL соответствует ряду нормативных требований. Чтобы посмотреть актуальный список требований, которым соответствует база данных SQL, перейдите в Центр управления безопасностью Майкрософт, разверните раздел требований, значимых для вашей организации, и проверьте, указана ли база данных SQL в списке совместимых служб Azure. Важно отметить, что хотя База данных SQL могут быть сертифицированы как соответствующая служба, она помогает в соответствии со службой вашей организации, но не гарантирует ее автоматически.

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

После переноса базы данных в База данных SQL вы хотите отслеживать базу данных (например, проверка способ использования ресурсов или dbCC проверка) и выполнять регулярное обслуживание (например, перестроение или реорганизация индексов, статистики и т. д.). База данных SQL — это интеллектуальная служба. Она позволяет выполнять мониторинг и обслуживание базы данных на основе исторических тенденций, записанных метрик и статистических данных. За счет этого приложение постоянно работает наилучшим образом. В некоторых случаях база данных SQL Azure может автоматически выполнять задачи обслуживания в зависимости от настроек конфигурации. Служба "База данных SQL" отслеживает такие три аспекты базы данных:

• мониторинг производительности и оптимизация;
• оптимизация безопасности;
• оптимизация затрат.

Мониторинг производительности и оптимизация

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

Оптимизация безопасности

Служба "База данных SQL" предоставляет действенные рекомендации по защите данных, а обнаружение угроз позволяет определять и исследовать подозрительные активности, которые могут навредить базе данных. Оценка уязвимостей — это служба сканирования и отчетов базы данных, которая позволяет отслеживать состояние безопасности большого количества баз данных, а также определять риски безопасности и отклонения от заданных базовых показателей безопасности. После каждого сканирования предоставляется индивидуальный список практических действий и скрипты исправлений, а также отчет об оценке, который можно использовать для обеспечения соответствия требованиям.

С помощью Microsoft Defender для облака вы определите рекомендации по безопасности на борту и быстро примените их.

Оптимизация затрат

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

Этот анализ также можно просмотреть в разделе "Помощник":

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

Функция Intelligent Insights в службе "База данных SQL" позволяет отслеживать производительность и принимать необходимые меры. Вы можете отслеживать производительность и использование ресурсов в службе "База данных SQL" следующими методами:

Портал Azure

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

Из этой диаграммы можно также настроить оповещения по ресурсам. Эти оповещения позволяют реагировать на состояние ресурсов следующим образом: отправка сообщения электронной почты, запись в конечную точку HTTPS/HTTP или выполнение действия. Дополнительные сведения см. в статье Создание оповещений для базы данных SQL Azure и хранилища данных с помощью портала Azure.

Динамические административные представления

Вы можете запросить динамическое административное представление sys.dm_db_resource_stats для возврата истории о статистике потребления ресурсов за последний час и представления системного каталога sys.resource_stats для возврата истории за последние 14 дней.

Анализ производительности запросов

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

Аналитика SQL Azure (Предварительная версия) в журналах Azure Monitor

Журналы Azure Monitor позволяют собирать и визуализировать ключевые метрики производительности базы данных SQL Azure и поддерживают до 150 000 баз данных SQL и 5000 эластичных пулов SQL в каждой рабочей области. Ее можно использовать для отслеживания и получения уведомлений. Вы можете отслеживать метрики базы данных SQL и эластичных пулов в нескольких подписках Azure и эластичных пулах и использовать их при выявлении проблем на каждом уровне стека приложений.

Чем отличаются методы устранения проблем с производительностью базы данных SQL от SQL Server?

Основная часть методов устранения неполадок, а в частности диагностика проблем с производительностью базы данных и запросов, не изменилась. В облаке используется то же ядро СУБД. Однако платформа — База данных SQL Azure встроена в "аналитику". которые еще больше упрощают диагностику и устранение проблем с производительностью. Эта платформа также выполняет некоторые корректирующие действия от вашего имени и в некоторых случаях заблаговременно автоматически исправляет проблемы.

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

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

Кроме того, при снижении общего уровня производительности базы данных отслеживайте динамические административные представления sys.dm_db_resource_stats и sys.resource_stats, чтобы понимать уровень использования ЦП, операций ввода-вывода и потребления памяти. На снижение производительности может влиять нехватка ресурсов в базе данных. Возможно, потребуется изменить объем вычислительных ресурсов и (или) уровень служб в соответствии с различными требованиями к расширению и сжатию рабочих нагрузок.

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

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

База данных SQL поддерживает разные уровни служб: "Базовый", "Стандартный" и "Премиум". Каждый уровень служб обеспечивает прогнозируемый уровень производительности. В зависимости от рабочей нагрузки у вас могут возникнуть всплески активности, в которых использование ресурсов может привести к потолку текущего размера вычислительных ресурсов, в котором вы находитесь. В таких случаях полезно сначала оценить, может ли любая настройка помочь (например, добавление или изменение индекса и т. д.). Если ресурсов по-прежнему недостаточно, советуем перейти на более высокий уровень служб или объем вычислительных ресурсов.

Уровень служб	Распространенные варианты использования
Базовая	Приложения с несколькими пользователями и базой данных, которая не имеет высоких требований к параллелизму, масштабированию и производительности.
Стандартные	Приложения с высокими требованиями к параллелизму, масштабированию и производительности, а также с небольшими или средними требованиями к операциям ввода-вывода.
Премиум	Приложения с большим количеством одновременно работающих пользователей, высоким уровнем потребления ресурсов ЦП и памяти, а также с высокими требованиями к операциям ввода-вывода. Чувствительные к задержкам приложения с высокими требованиями к параллелизму и пропускной способности, которые могут работать на уровне "Премиум".

Чтобы убедиться, что вы находитесь в правильном размере вычислений, вы можете отслеживать потребление ресурсов запросов и баз данных с помощью одного из описанных выше упоминание способов "Разделы справки отслеживать производительность и использование ресурсов в База данных SQL". Если запросы и (или) базы данных потребляют слишком много ресурсов ЦП или памяти, советуем перейти на более высокий объем вычислительных ресурсов. Аналогичным образом, если вы заметите, что даже во время пиковых часов, вы, кажется, не используете ресурсы столько; рассмотрите возможность масштабирования с текущего размера вычислительных ресурсов.

При использовании шаблона приложения SaaS или в сценарии консолидации базы данных советуем использовать пул эластичных баз данных. Это позволит сократить расходы. Эластичный пул — это отличный способ достижения консолидации базы данных и оптимизации затрат. Дополнительные сведения об управлении несколькими базами данных в эластичном пуле см. в разделе Управление пулами и базами данных.

Как часто нужно проверять целостность базы данных

Служба "База данных SQL" использует некоторые интеллектуальные методы, которые позволяют обрабатывать определенные классы повреждений данных автоматически и без потери. Эти методы встроены в службу и используются при необходимости. Резервные копии базы данных в службе регулярно проверяются за счет восстановления и выполнения DBCC CHECKDB. Если возникают проблемы, служба "База данных SQL" заранее устраняет их. Функция автоматического восстановления страниц позволяет исправлять поврежденные страницы или страницы с проблемами целостности данных. Страницы базы данных постоянно проверяются с помощью параметра CHECKSUM, который анализирует их целостность. Служба "База данных SQL" заранее отслеживает и проверяет целостность данных в базе данных и при возникновении проблем устраняет их (это действие имеет наивысший приоритет). Кроме того, вы можете самостоятельно выполнять эти проверки. Дополнительные сведения см. в записи блога Data Integrity in Azure SQL Database (Целостность данных в службе "База данных SQL Azure").

Перемещение данных после переноса

Как импортировать и экспортировать данные в виде файлов BACPAC из базы данных SQL с помощью портала Azure

• Экспорт. Вы можете экспортировать базу данных SQL Azure в виде файла BACPAC на портале Azure.

  

• Импорт. Данные также можно импортировать в базу данных в виде файла BACPAC на портале Azure.

  

Как синхронизировать данные между службой "База данных SQL" и SQL Server

Это можно сделать несколькими способами:

• Синхронизация данных. Эта функция позволяет синхронизировать данные в двух направлениях между несколькими локальными базами данных SQL Server и базой данных SQL. Чтобы синхронизировать данные с локальными базами данных SQL Server, необходимо установить и настроить агент синхронизации на локальном компьютере и открыть исходящий TCP-порт 1433.
• Репликация транзакций. Функция репликации транзакций позволяет синхронизировать данные SQL Server с базой данных SQL Azure. В этом случае экземпляр SQL Server выступает издателем, а база данных SQL Azure — подписчиком. Сейчас поддерживается только эта конфигурация. Дополнительные сведения о том, как выполнить миграцию данных SQL Server в базу данных SQL Azure с минимальным временем простоя, см. в разделе Использование репликации транзакций.

Следующие шаги

Узнайте больше о службе База данных SQL.