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

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

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

Основные характеристики базы данных SQL Azure:

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

Примечание.

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

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

Сведения о метриках и оповещениях Azure Monitor, включая рекомендуемые правила генерации оповещений, см. в статье "Мониторинг База данных SQL Azure с помощью метрик и оповещений". Дополнительные сведения о уровнях служб см. в обзоре модели покупки на основе DTU и модели покупки на основе vCore.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как выглядит аварийное восстановление с базой данных SQL?

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

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

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

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

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

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

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

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

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

проверка подлинности Windows не поддерживается. Идентификатор Microsoft Entra — это централизованная служба управления удостоверениями и доступом. Идентификатор 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 записывает события базы данных и записывает их в файл журнала аудита в учетной записи хранения Azure. Аудит особенно полезен, если вы планируете получить представление о потенциальных нарушениях безопасности и политике, поддержании соответствия нормативным требованиям и т. д. Он позволяет определять и настраивать определенные категории событий, которые, по вашему мнению, требуют аудита, и на основе этого можно получить предварительно настроенные отчеты и панель мониторинга, чтобы получить общие сведения о событиях, происходящих в базе данных.

Эти политики аудита можно применить на уровне базы данных или сервера. Дополнительные сведения см. в параметре "Включить аудит базы данных SQL".

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

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

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

Как защитить данные в целом в базе данных SQL?

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

• Ваши данные в состоянии покоя в файлах данных и журналах
• Ваши данные в тестовом режиме

По умолчанию в базе данных SQL данные неактивных данных и файлов журналов в подсистеме хранения полностью шифруются с помощью прозрачного шифрования данных [TDE]. Резервные копии также шифруются. При использовании TDE никаких изменений на стороне приложения, обращающегося к этим данным, не требуется. Шифрование и расшифровка происходит прозрачно (отсюда и название).

Для защиты конфиденциальных данных во время полета и неактивных данных база данных SQL предоставляет функцию Always Encrypted. Always Encrypted — это форма шифрования на стороне клиента, которая шифрует конфиденциальные столбцы в базе данных (поэтому они в шифре для администраторов баз данных и несанкционированных пользователей). Сначала сервер получает зашифрованные данные.

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

Always Encrypted поддерживает сравнения равенства, поэтому базы данных могут продолжать запрашивать зашифрованные столбцы в рамках своих команд SQL. Она может использоваться с различными вариантами хранения ключей, например с Azure Key Vault, хранилищем сертификатов Windows и локальными аппаратными модулями безопасности.

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

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

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

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

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

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

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

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

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

• Автоматически с помощью базы данных SQL Azure
• Или при использовании Azure Key Vault в качестве хранилища ключей

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

Всегда зашифровано

В 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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Наблюдатель за базами данных

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

Дополнительные сведения о наблюдателе за базами данных см. в следующих статьях:

• Мониторинг рабочих нагрузок SQL Azure с помощью наблюдателя за базами данных (предварительная версия)
• Краткое руководство. Создание наблюдателя для мониторинга SQL Azure (предварительная версия)
• Создание и настройка наблюдателя (предварительная версия)
• Сбор и наборы данных наблюдателя за базами данных (предварительная версия)
• Анализ данных мониторинга наблюдателя за базами данных (предварительная версия)
• Вопросы и ответы наблюдателя за базами данных

Портал Azure

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

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

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

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

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

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

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

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

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

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

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

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

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

База данных SQL предлагает две разные модели приобретения: старую модель DTU и более адаптируемую модель приобретения виртуальных ядер. Дополнительные сведения см. в статье "Сравнение моделей приобретения на основе виртуальных ядер и DTU" базы данных SQL Azure.

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

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

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

База данных SQL может автоматически обрабатывать определенные классы повреждения данных и без потери данных. Эти встроенные методы используются службой при возникновении необходимости. Резервные копии базы данных в службе регулярно проверяются путем их восстановления и запуска DBCC CHECKDB на них. Если возникают проблемы, служба "База данных SQL" заранее устраняет их.

Автоматическое восстановление страниц используется для исправления страниц, которые повреждены или имеют проблемы с целостностью данных. Страницы базы данных всегда проверяются с параметром по умолчанию CHECKSUM , который проверяет целостность страницы. База данных SQL заранее отслеживает и проверяет целостность данных базы данных и устраняет проблемы, возникающие при их возникновении. При необходимости можно выполнять собственные проверки целостности. Дополнительные сведения см. в разделе " Целостность данных" в базе данных SQL.

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

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

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

  

• Импорт. Вы также можете импортировать данные в качестве BACPAC-файла в базу данных в базе данных SQL Azure с помощью портала Azure:

  

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

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

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

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

Связанный контент

• Мониторинг и настройка производительности в База данных SQL Azure и Управляемый экземпляр SQL Azure