Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Применимо к: База данных SQL Azure
В этой статье описываются требования к проверке подлинности для настройки и управления активными группами георепликации и отработки отказа. Здесь также приведены шаги, необходимые для настройки доступа пользователей к базе данных-получателю. И наконец, здесь описано, как включить доступ к восстановленной базе данных после геовосстановления. Дополнительные сведения о вариантах восстановления см. в статье "Непрерывность бизнес-процессов" в базе данных SQL Azure.
Аварийное восстановление с поддержкой автономных пользователей
В отличие от традиционных пользователей, которые должны быть сопоставлены с именами входа в master
базе данных, автономный пользователь полностью управляется самой базой данных. Это имеет два преимущества. При аварийном восстановлении пользователи могут по-прежнему подключаться к новой базе данных-источнику или к базе данных, восстановленной с помощью геовосстановления. Для этого не потребуется никаких дополнительных настроек, так как пользователями управляет база данных. Кроме этого, с точки зрения входа такая конфигурация потенциально может иметь преимущества масштабируемости и производительности. Дополнительные сведения см. в статье Пользователи автономной базы данных — создание переносимой базы данных.
Основной недостаток — управление процессами аварийного восстановления усложняется при росте масштаба. Если у вас есть несколько баз данных, которые используют один и тот же логин, поддержание данных учётной записи с использованием содержащихся пользователей в нескольких базах данных может свести на нет преимущества этих пользователей. Например, политика смены паролей требует последовательного изменения в нескольких базах данных, а не изменения пароля для входа один раз в master
базе данных. Поэтому, если у вас есть несколько баз данных с одинаковыми именами пользователей и паролями, мы не рекомендуем использовать автономных пользователей.
Настройка имен для входа и пользователей
Если вы используете имена входа и пользователи (а не содержащиеся пользователи), необходимо выполнить дополнительные действия, чтобы убедиться, что те же имена входа существуют в master
базе данных. В следующих разделах описаны необходимые действия и приведены дополнительные рекомендации.
Примечание.
Кроме того, для управления базами данных можно использовать имена входа, созданные с помощью идентификатора Microsoft Entra (ранее Azure Active Directory). Дополнительные сведения см. в разделе "Авторизация доступа к базе данных".
Настройка доступа пользователей к базе данных-получателю или восстановленной базе данных
Чтобы база данных-получатель использовалась как база данных-получатель только для чтения, и чтобы обеспечить надлежащий доступ к новой базе данных-источнику или базе данных, восстановленной с помощью геовосстановки, master
база данных целевого сервера должна иметь соответствующую конфигурацию безопасности перед восстановлением.
Подготовку доступа пользователей к базе данных-получателю георепликации следует выполнять в рамках настройки георепликации. Подготовка доступа пользователей к геовосстановлимой базе данных должна выполняться в любое время, когда исходный сервер находится в сети (в рамках теста аварийного восстановления).
Примечание.
Если вы выполните отработку отказа или геовосстановление на сервер, для которого доступ не настроен должным образом, войти на него можно будет только с учетной записью администратора сервера.
Настройка имен входа на целевом сервере включает три шага.
1. Определение учетных записей с доступом к базе данных-источнику
Первым шагом процесса является определение того, какие учетные записи следует дублировать на целевом сервере. Это достигается с помощью пары инструкций SELECT, одной в логической master
базе данных на исходном сервере и одной в самой базе данных-источнике.
Только администратор сервера или член роли сервера LoginManager может определить имена входа на исходном сервере с помощью следующей SELECT
инструкции.
SELECT [name], [sid]
FROM [sys].[sql_logins]
WHERE [type_desc] = 'SQL_Login'
Только учетные записи базы данных с ролью db_owner, пользователь dbo или администратор сервера могут определять всех субъектов-пользователей базы данных в базе данных-источнике.
SELECT [name], [sid]
FROM [sys].[database_principals]
WHERE [type_desc] = 'SQL_USER'
2. Поиск ИД безопасности для учетных записей, определенных на шаге 1
Сравнивая выходные данные запросов из предыдущего раздела с соответствующими ИД безопасности, можно сопоставить учетные записи на сервере с пользователями базы данных. Учетные записи пользователей базы данных с соответствующими ИД безопасности имеют пользовательский доступ к базе данных в качестве субъекта-пользователя.
Следующий запрос можно использовать для просмотра всех субъектов-пользователей и их ИД безопасности в базе данных. Этот запрос могут выполнять только учетные записи базы данных с ролью db_owner или администратор сервера.
SELECT [name], [sid]
FROM [sys].[database_principals]
WHERE [type_desc] = 'SQL_USER'
Примечание.
У пользователей INFORMATION_SCHEMA
и sys
имеются идентификаторы безопасности NULL
, а идентификатор безопасности guest
равен 0x00
.
dbo
Идентификатор безопасности может начинаться на 0x01060000000001648000000000048454
в том случае, если создатель базы данных был администратором сервера, а не членом DbManager.
3. Создание имен для входа на целевом сервере
Последним шагом является переход к целевому серверу или серверам и создание учетных записей с соответствующими ИД безопасности. Базовый синтаксис выглядит так.
CREATE LOGIN [<login name>]
WITH PASSWORD = '<login password>',
SID = 0x1234 /*replace 0x1234 with the desired login SID*/
На целевом сервере не создавайте новое имя входа с идентификатором безопасности администратора сервера из источника. Вместо этого администратор сервера целевого объекта войдет субъект базы данных в базу данных, например db_owner или пользователя.
Примечание.
Чтобы предоставить пользователю доступ на сервер-получатель (но не на сервер-источник), измените учетную запись пользователя на сервере-источнике с помощью следующего синтаксиса.
ALTER LOGIN [<login name>] DISABLE
DISABLE не изменяет пароль, поэтому при необходимости его всегда можно включить.