2 つのサーバー間でいくつかの SQL Server 2008 R2 データベースを移行することを計画しています。
この記事の方法 3 ( http://support.microsoft.com/kb/918992 ) に従って、データベースの移行後にログインを転送することをお勧めします。
これはほとんど問題ないように見えますが、1 つの懸念事項は、これらのログインのいずれかがターゲット サーバーに既に存在するかどうかです。この場合、何か追加の作業を行う必要がありますか?
[私の理解はここでは少し曖昧です - 復元されたデータベースのユーザーは、参照したログインが新しいサーバー上で異なる SID を持っているため、孤立したままになる可能性がありますか?]
そのスクリプトは、ステートメントを直接実行するのではなく、ログイン スクリプトを生成するため、それらを確認して、ターゲットにまだ存在しないユーザーのスクリプトを実行するだけです。
スクリプトは、新しいログインに新しい SID が必要かどうかに応じて、新しい SID を生成します。これは、ログインの種類によって異なります。
件名に関するMSDNから：
SID のソースは、ログインの作成方法によって異なります。ログインが Windows ユーザーまたはグループから作成された場合、ソース プリンシパルの Windows SID が与えられます。Windows SID はドメイン内で一意です。SQL Server ログインが証明書または非対称キーから作成された場合、公開キーの SHA-1 ハッシュから派生した SID が割り当てられます。ログインが、パスワードを必要とするレガシー スタイルの SQL Server ログインとして作成された場合、サーバーは SID を生成します。
特別な用途でない限り、気にする必要はないと思いますsys.server_principals。
以下のコメントから、Steve はスクリプトでログインを作成し、新しいサーバーでデータベースを切り離して再接続したいと考えました。問題は、これらのログインが孤立することでした。つまり、新しいサーバーのログインと同じ名前で元のサーバーのログインに関連付けられますが、SID は異なります。
はい、これは問題になります。これを並べ替えるには、この MSDN の記事にアクセスする必要があります。要約すると：
孤立したユーザーを検出するには、次の Transact-SQL ステートメントを実行します。
USE <database_name>;
GO;
sp_change_users_login @Action='Report';
GO;
出力には、SQL Server ログインにリンクされていない現在のデータベース内のユーザーと対応するセキュリティ識別子 (SID) が一覧表示されます。詳細については、「sp_change_users_login (Transact-SQL)」を参照してください。
孤立したユーザーを解決するには、次の手順を使用します。
次のコマンドは、 で指定されたサーバー ログイン アカウントを、指定されたデータベース ユーザーに再リンクします。
USE <database_name>;
GO
sp_change_users_login @Action='update_one', @UserNamePattern='<database_user>',
@LoginName='<login_name>';
GO
スティーブが指摘するように、sp_change_users_loginは減価償却されており、推奨される代替手段は次を使用することALTER USERです。
ALTER USER <database_user>
WITH LOGIN <login_name>