Uprawnienia użytkownika pomieszane po utworzeniu kopii zapasowej -> Przywróć

Musiałem przenieść kilka baz danych SQL Server 2008 na nasz nowy serwer db, więc utworzyłem ich kopię zapasową (do plików .bak), skopiowałem te pliki do nowej skrzynki i przywróciłem je (wszystko zrobione za pomocą SQL Management Studio).

Wszystko poszło dobrze, ale teraz nie mogę zalogować się do żadnej z baz danych przy użyciu konta SQL Server, które nadal działa na starym RDBMS. Nawiasem mówiąc, moje logowanie uwierzytelnione w systemie Windows nadal działa poprawnie.

Wpadłem na pomysł, że użytkownicy i uprawnienia zostaną bezproblemowo powielone na nowym serwerze bazy danych, ale wygląda na to, że coś poszło nie tak. Byłbym wdzięczny za komentarze / sugestie / oferty pomocy ;-)

Widzę, że już znalazłeś rozwiązanie swojego problemu, zauważyłem w oryginalnym pytaniu, że nadal masz dostęp do starego serwera.

Poniższe pytanie dotyczące SO miało podobny problem i zawiera łącza do artykułu Microsoft ze skryptem do generowania uprawnień użytkownika.

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

(Zasoby wymienione dla tego pytania http://support.microsoft.com/kb/918992 )

Wygląda na to, że zmiana ustawienia serwera z uwierzytelniania systemu Windows na uwierzytelnianie w trybie mieszanym rozwiązała problem, ale na wypadek, gdyby nie rozwiązał on całkowicie problemu, pomyślałem, że może to być przydatne.

Nazywa się to „osieroconymi użytkownikami”. Oto 2 sposoby, aby to naprawić

1. Jeśli możesz, przywróć oryginalną główną bazę danych jako „loginsource”, a sys.server_principals ma wystarczającą ilość informacji, aby wygenerować wszystkie logowania do SQL Server i Windows. Oznacza to, że identyfikatory SID i zaszyfrowane hasło

2. Jeśli używasz tylko loginów systemu Windows, możesz uruchomić tę bazę danych dla wygenerowania skryptu

Scenariusz:

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

Idealnie byłoby wykonać skrypt użytkowników i uprawnień przed przywróceniem. Jeśli tak się nie stało, musisz zająć się naprawą rzeczy po fakcie, a są szanse, że coś zostanie pominięte, ale powinieneś być w stanie uzyskać około 90% drogi.

Pierwszą rzeczą, którą musisz ustalić, jest to, czy te same dane logowania istnieją na nowym serwerze. Jeśli nie, to powinieneś dowiedzieć się, czy logowanie na nowym serwerze jest w porządku. Nigdy nie zakładaj, że powinny zostać stworzone, może istnieć dobry powód, dla którego nie istniały. Następnie możesz zacząć je tworzyć, przeglądając tabelę sysusers.

Możesz naprawić osieroconych użytkowników, uruchamiając coś podobnego do następującego:

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 

Ten kod będzie działał dla SQL2008, ale został napisany jako kompatybilny wstecz dla SQL2000.

Możesz odnieść się do następującego adresu URL, aby naprawić uprawnienia użytkownika bazy danych

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

Oto krótki artykuł wyjaśniający rozwiązanie:

Przywracanie osieroconych loginów w SQL Server po przywróceniu bazy danych