Користувацькі дозволи відключили після резервного копіювання -> Відновлення операції

Мені довелося перенести кілька баз даних SQL Server 2008 на наш новий сервер db, тому я створив резервну копію їх усіх (у .bak файли), скопіював ці файли у нове поле та відновив їх (усе це робиться за допомогою SQL Management Studio).

Все пішло нормально, але тепер я вважаю, що не можу увійти до жодної бази даних за допомогою облікового запису SQL Server, який продовжує працювати на старій RDBMS. Мій вхід із аутентифікацією Windows все одно працює добре.

У мене була така ідея, що всі користувачі та дозволи будуть безперебійно дублюватися на новому сервері баз даних, але, здається, десь щось пішло не так. Буду вдячний за коментарі / пропозиції / пропозиції допомоги ;-)

Я бачу, ви вже знайшли рішення своєї проблеми. Одне, що я помітив у вашому первісному запитанні, було те, що ви все ще мали доступ до старого сервера.

Наступне запитання щодо SO мало подібну проблему і включає посилання на статтю Microsoft із сценарієм для створення прав користувача.

/programming/461385/restoring-a-backup-to-a-different-server-user-permissions

(Ресурс, вказаний для цього питання http://support.microsoft.com/kb/918992 )

Це здається, що зміна налаштування сервера з автентифікації Windows на автентифікацію змішаного режиму виправила вашу проблему, але про всяк випадок, якщо вона не повністю вирішила проблему, я подумав, що це може бути корисним.

Це відомо як "осиротілі користувачі". Ось два способи виправити це

1. Якщо ви можете, відновіть початкову головну базу даних як "loginsource", а sys.server_principals має достатньо інформації для створення всіх входів у систему SQL Server та Windows. Тобто SID та зашифрований пароль

2. Якщо ви використовуєте лише входи в систему Windows, ви можете запустити це для кожної бази даних для створення сценарію

Сценарій:

SELECT
    'CREATE LOGIN [' + SUSER_SNAME(sid) + '] FROM WINDOWS'
FROM
    sys.database_principals
WHERE
    [type] IN ('G', 'U')

В ідеалі вам слід викреслити користувачів та дозволи перед відновленням. Якщо цього не сталося, то вам слід зайнятися виправленням речей після факту, і шанси на те, що щось буде пропущено, але ви повинні мати змогу пройти близько 90% шляху туди.

Перше, що вам потрібно встановити, це те, що ті ж входи існують на новому сервері. Якщо цього немає, то слід з’ясувати, чи нормально створювати входи на новому сервері. Ніколи не припускайте, що вони повинні бути створені, це може бути вагомою причиною того, чому вони не існували в першу чергу. Потім ви можете зайнятися їх створенням, перекопавши таблицю систематизаторів.

Ви можете виправити осиротілих користувачів, виконавши щось подібне до наступного:

DECLARE @username varchar(25), @loginsid varbinary(85)
DECLARE fixusers CURSOR
FOR
SELECT UserName = name 
    FROM sysusers
    WHERE issqluser = 1 
    and (sid is not null and sid <> 0x0)
    and suser_sname(sid) is null
    and name in (select name from master..syslogins)
    ORDER BY name
OPEN fixusers
FETCH NEXT FROM fixusers
INTO @username
WHILE @@FETCH_STATUS = 0
BEGIN
    EXEC sp_change_users_login 'update_one', @username, @username

    FETCH NEXT FROM fixusers
    INTO @username
END CLOSE fixusers
DEALLOCATE fixusers 

Цей код буде працювати для SQL2008, але він був написаний для зворотної сумісності для SQL2000.

Ви можете вказати наступну URL-адресу, щоб виправити дозволи користувачів бази даних

http://mywindowsblog.com/?p=287

Ось коротка стаття, яка пояснює рішення:

Відновлення осиротілих входів на SQL Server після відновлення бази даних