Microsoft SQL Server 2016 実践シリーズ （HTML 版）
「SQL Server 2016 への移行とアップグレードの実践」

5.13　ログイン アカウントの移行（DB ユーザー、オブジェクト権限）

データベース ユーザーは、ログイン アカウントと紐付いている（マッピングされている）ので、ログイン アカウントの移行を行わないと、データベース ユーザーを利用することができません。また、データベース ユーザーに紐付いたオブジェクト権限（テーブルやビューに対する SELECT 権限や INSERT 権限、ストアド プロシージャに対する EXECUTE 権限など）も無力になってしまいます。

ログイン アカウントとのマッピングが切れたデータベース ユーザーは、「不明なデータベース ユーザー」や「孤立ユーザー」と呼ばれ、次のように表示されます。

これは、SQL Server 認証用のログイン アカウントである「sqllogin1」に対応したデータベース ユーザーのプロパティを開いている画面で、［ユーザーの種類］が「ログインを持たない SQL ユーザー」になっています。データベース ユーザーに対応したログイン アカウントが存在しない場合（マッピングが切れている場合）には、このように表示されます。この状態では、sqllogin1 ユーザーはデータベースにアクセスすることができません。

Windows 認証用のログイン アカウント（Active Directory ドメイン ユーザーや Windows ローカル ユーザーに対応したログイン アカウントの場合）は、次のように［ユーザーの種類］が「Windows ユーザー」と表示されて、［ログイン名］が "空" で表示されるものが、不明なデータベース ユーザーとなっていて、利用することができません。

なお、SQL Server 認証用のログイン アカウントとのマッピングが切れたユーザー（不明なデータベース ユーザー）は、次のように sp_change_users_login というシステム ストアド プロシージャを利用して、リストアップすることもできます。

このような不明なデータベース ユーザーを正しく利用できるようにするには、移行元と移行先で、同一のログイン アカウントを作成しておく必要があります。作成方法／注意点は、Windows認証用のログイン アカウントである Active Directory ユーザーまたは Windows のローカル ユーザーの場合と、SQL Server 認証用のログイン アカウントの場合で異なるので、それぞれごとに説明します。

◆ Active Directory ユーザー（ドメイン ユーザー）の場合

ログイン アカウントが Windows 認証用で、かつ Active Directory ドメイン ユーザー、移行元と移行先が同じドメインに所属している場合には、同一のログイン アカウントを簡単に作成することができます。標準の「スクリプト生成」機能や、後述の「sp_help_revlogin ストアド プロシージャ」、「データベース コピー ウィザード」、「Integration Services のログイン転送タスク」などを利用して、ログイン アカウントを再作成または転送すれば、同一のログイン アカウントを作成できるので、不明なデータベース ユーザーを簡単に解消することができます（データベース ユーザーを移行元とまったく同じように利用できるようになります）。

標準の「スクリプト生成」機能を利用する場合

標準の「スクリプト生成」機能を利用する場合は、次のように、移行元の Management Studio で、スクリプト化をしたいログイン アカウントを右クリックして、［名前を付けてログインをスクリプト化］の［CREATE］から［新しいクエリ エディタ ウィンドウ］をクリックします（画面は SQL Server 2008 の場合ですが、他のバージョンでも同じように操作できます）。

これで CREATE LOGIN ステートメントが生成されるので、このスクリプトを移行先（SQL Server 2016 上）で実行すれば、同じログイン アカウントを作成することができます。

移行先に同じログイン アカウントを作成しておけば、次のようにデータベース ユーザーとログイン アカウントのマッピング（紐付け）が復活して、データベース ユーザーおよびオブジェクト権限を移行元と同じように利用できるようになります。

このように、ログイン アカウントが Active Directory ユーザーで、同じドメイン内の別マシンへ移行する場合には、同一のログイン アカウントを作成するだけで、データベース ユーザーとオブジェクト権限を利用できるようになります。

もし、移行元と移行先が異なるドメインに所属していたり、別のワークグループ環境の別マシンに復元したりする場合には、次のように CREATE LOGIN ステートメントの実行時にエラーになります。

ドメイン ユーザーに対応したログイン アカウントの作成は、あくまでも同じドメイン内に所属している場合にのみ行うことができます。

Tips： 複数のログイン アカウントをまとめてスクリプト化したい場合
移行元で、複数のログイン アカウントをまとめてスクリプト化したい場合は、Management Studio で［表示］メニューから［オブジェクト エクスプローラーの詳細］をクリックして、詳細ページを表示し、次のように複数のログイン アカウントを Ctrl キーを押しながら選択／右クリックします。


これでまとめてスクリプト化できるので、ログイン アカウントが多い場合に便利です。
なお、SQL Server 2005 の SP1 以前を利用している場合は、［表示］メニューから［概要］をクリックして、概要ページを表示することで、同様の操作ができます。

◆ Windows のローカル ユーザーの場合

ログイン アカウントが Windows のローカル ユーザーの場合は、移行先（SQL Server 2016 上）でデータベース ユーザーを再作成する必要があります。これには、復元したデータベース ユーザーをいったん削除して、手動で同じデータベース ユーザーを作り直さなければなりません。したがって、データベース ユーザーへ設定したオブジェクト権限についても再設定しなければなりません。

この理由は、Windows のローカル ユーザーの場合は、同じ Windows ユーザー（OS 上のユーザー アカウント）を作り直しても、内部的に生成される SID（OS 上のユーザーを識別する Security ID）が異なるものが割り当てられるためです。

このように、データベース ユーザーは、内部的には、ログイン アカウントの名前とではなく、SID とマッピングされているので、Windows のローカル ユーザーの場合は、復元後のデータベース ユーザーとログイン アカウントをマッピングすることができません（SID が異なる場合には、不明なデータベース ユーザーを解消することができません）。

なお、前述の Active Directory ユーザー（ドメイン ユーザー）の場合に、同一のログイン アカウントを作成するだけで、簡単に再マッピングできたのは、SID が同じものを利用できるためです。同じドメインに所属していれば、共通（同一の SID）のドメイン ユーザーを利用することができます。

したがって、Windows ローカル ユーザーを利用していて、移行先でも同じ名前の Windows ローカル ユーザーを利用したい場合には、手動ですべてを再作成するか、データベース ユーザーやオブジェクト権限を移行元でスクリプト化しておくようにします（詳しくは後述します）。

復元したデータベース ユーザーの削除

再作成にあたっては、移行先（SQL Server 2016 上）で、復元したデータベース ユーザーをいったん削除する必要がありますが、これは Management Studio で［表示］メニューから［オブジェクト エクスプローラーの詳細］をクリックして「詳細」ページを表示することで、次のように複数のデータベース ユーザーをまとめて削除することができるので便利です。

データベース ユーザーとオブジェクト権限のスクリプト化（スクリプト生成ウィザード）

移行元で、ログイン アカウントやデータベース ユーザー、オブジェクト権限をスクリプト化するには、スクリプト生成ウィザードを利用すると便利です。このウィザードを利用するには、次のようにデータベースを右クリックして、［タスク］メニューの［スクリプトの生成］をクリックします（画面は SQL Server 2008 ですが、他のバージョンでも同じように操作できます）。

スクリプト生成ウィザードでは、次のように［スクリプト オプションの選択］ページで、［オブジェクト レベル権限のスクリプトを作成］と［スクリプト ログイン］を「True」へ変更することで、データベース ユーザーとオブジェクト権限、データベース ユーザーに対応したログイン アカウントをスクリプト化することができます（SQL Server 2005 と 2008 の場合）。

SQL Server 2008 R2 と 2012、2014 の場合は、次のように操作します。

次の［オブジェクトの種類を選択］ページでは、データベース ユーザーをスクリプト化するために［ユーザー］をチェックし、テーブルに対するオブジェクト権限をスクリプト化する場合には［テーブル］をチェックします。ビューやストアド プロシージャに対するオブジェクト権限をスクリプト化するには、それらもチェックしておきます。

［テーブルの選択］ページでは、オブジェクト権限をスクリプト化したいテーブルをチェックします（画面は Products テーブルをチェック。［すべて選択］ボタンをクリックした場合は、すべてのテーブルを選択することができます）。これらの画面は、SQL Server 2005／2008 の場合ですが、SQL Server 2008 R2／2012／2014 の場合は、ウィザードの最初のページで、ユーザーやテーブルを選択することができます。

SQL Server 2005／2008 の場合は、次の［ユーザーの選択］ページで、スクリプト化したいデータベース ユーザーを選択します。

［出力オプション］ページで、［スクリプトを新しいクエリ ウィンドウに保存］を選択すれば、クエリ エディターにスクリプトを生成することができます。あとは、次のように［完了］ボタンをクリックすれば、スクリプト生成が開始されます。

テーブルを作成するスクリプト（CREATE TABLE）などが余分に出力されてしまいますが、ログイン アカウントを作成するスクリプト（CREATE LOGIN）や、データベース ユーザーを作成するスクリプト（CREATE USER）、オブジェクト権限を設定するスクリプト（GRANT、DENY など）が生成されていることを確認できると思います。Windows のローカル ユーザーの場合は、「サーバー名\ユーザー名」形式の名前になるので、サーバー名の部分を移行先のサーバー名へ変更すれば、移行先で同じユーザー、同じオブジェクト権限を再設定できるようになります。

◆ SQL Server 認証用のログイン アカウントの場合

ログイン アカウントが SQL Server 認証用の場合は、SQL Server 標準のツール（スクリプト生成機能や、データベース コピー ウィザード、ログイン転送タスク ツールなど）では、同一のログイン アカウントを作成することができないことに注意する必要があります。標準ツールでは、パスワードと SID（SQL Server 認証用のログイン アカウントに内部的に割り当てられた Security ID）を生成／複製することができません（パスワードとSIDは、移行元と移行先で異なるものが生成されてしまいます）。

SQL Server 認証用のログイン アカウントの場合にも、Windows 認証用と同様、データベース ユーザーは、SIDとマッピングされているので、SID が異なる場合には、不明なデータベース ユーザーを解消することができません。

不明なデータベース ユーザーを解消するには（データベース ユーザーとログイン アカウントを再マッピングするには）、移行先（SQL Server 2016 上）で、同じ名前／パスワードのログイン アカウントを作成した後に、次のように ALTER USER ステートメントを実行します。

このように、ALTER USER ステートメントを実行すると、移行先で作成した新しいログイン アカウントと、復元したデータベース ユーザーを再マッピングすることができます（移行元の古い SID に紐付いていたものを、移行先の新しい SID へ紐付くように更新することができます）。

再マッピングが成功すると、データベース ユーザーのプロパティは、次のように表示されます。

なお、ALTER USER ステートメントの代わりに、次のように sp_change_users_login ストアド プロシージャを実行しても、再マッピングを行うことができますが、このストアド プロシージャは将来のバージョンでは削除される予定です。

ALTER USER ステートメントで不明なデータベース ユーザーの再マッピングを行う方法は、データベース ユーザーごとに実行する必要があるので、データベース ユーザーの数が多い場合には、大変になります（同じパスワードのログイン アカウントを作成する手間もかかります）。これらを解決してくれる方法が、次に説明する sp_help_revlogin ストアド プロシージャになります。これを利用すれば、同じ名前／パスワード かつ、同じ SID のログイン アカウントを一括で作成することができます。

同じ名前／パスワードで、同じ SID のログイン アカウントの作成： sp_help_revlogin

sp_help_revlogin は、同じ名前／パスワードで、同じSIDのログイン アカウントを一括で作成することができる大変便利なストアド プロシージャです。移行元と移行先で、同じ SID のログイン アカウントを移行先で作成すれば、前述の ALTER USER ステートメントを実行しなくても、不明なデータベース ユーザーを解消することができるからです。

sp_help_revlogin ストアド プロシージャは、マイクロソフトのサポート技術情報（KB：Knowledge Base）の文書番号 918992 で提供されています。

SQL Server 2005 のインスタンス間でログインおよびパスワードを転送する方法
http://support.microsoft.com/kb/918992

この文書で提供されるスクリプトを、次のように丸ごとコピーして（手順２ の USE master からスクリプトの最後までを選択してコピー）、移行元の SQL Server のクエリ エディターから実行すれば、sp_help_revlogin ストアド プロシージャを作成することができます。

上の画面は SQL Server 2008 の場合ですが、このスクリプトは SQL Server 2005 や 2008 R2、2012、2014 でも同じように利用することができます。

これにより、master データベース内に sp_help_revlogin ストアド プロシージャが作成されるので、次のように実行すれば、同一のパスワード／SIDのログイン アカウントを作成するためのスクリプトを生成することができます。

実行結果には、CREATE LOGIN ステートメントが生成されて、WITH PASSWORD= や SID= 付きのスクリプトが生成されて、同じパスワードおよび同じ SIDのログイン アカウントを作成できるようになります。

なお、このスクリプトには、Windows 認証用のログイン アカウントを作成するものや、SQL Server の内部ユーザー（NT AUTHORITY\SYSTEM や NT SERVICE\MSSQLSERVER、NT SERVICE\SQLSERVERAGENT、##MSPolicyEvent～、SQL Server 2005 の場合は SQLServer2005MSSQLUser～ や、SQLServer2005SQLAgetUser～ など）、グループなどを作成するための CREATE LOGIN ステートメント（SQL Server 2005 なら BUILTIN\Administrators など）も生成されるので、それらの不要なログイン アカウントはコメントアウトして、必要なログイン アカウントのみを移行先（SQL Server 2016 上）で実行／再作成するようにします。

このように、移行元と移行先で、同じ SID のログイン アカウントを作成すれば、不明なデータベース ユーザーが解消されて、データベースの復元後にも、データベース ユーザーやオブジェクト権限をそのまま利用することができます。

◆ データベース ロールのスクリプト化

データベース ロールを利用して、データベース ユーザーをグループ化している場合には、データベース ロールの設定もスクリプト化しておく必要があります。

前述のスクリプト生成ウィザードでは、SQL Server 2008／2008 R2 の場合は、データベース ロールの設定をスクリプト化することができないので、データベース ロールのメンバー情報を参照できる database_role_members システム ビューとデータベース ユーザーの情報を参照できる database_principals システム ビューを、次のように利用します。

これで、データベース ロールへメンバーを追加することできる sp_addrolemember を生成することができるので、これを新規マスター側で実行すれば、同じ設定にすることができます。

SQL Server 2012 以降を利用している場合は、スクリプト生成ウィザードが ALTER ROLE ステートメントを生成してくれるので、これを移行先で実行すれば、データベース ロールの設定を同じように利用することができます。