web-dev-qa-db-ja.com

スタンバイを使用した復元後のDBユーザー/ログインの再マッピング

これは私の以前の投稿に関連しています。

差分バックアップの問題-なぜですか？これは可能ですか？

基本的に、私が今持っている問題は、（ETLの一部として）復元プロセスで、dbユーザーをログインに再マッピングするタスクがあることです（サーバーAのSQL Authユーザーであるため、サーバーに復元するとマッピングが失われます） B）。 STANDBYを使用した復元では、読み取り専用のデータベースになるため、これは許可されません。どうすればこれを回避できますか？

sql-serverrestoreloginsstandby
2
iKnowNothing

サーバーAのdbからのユーザーは、バックアップと共にサーバーBのデータベースに移動されます。次に、必要なのは、同じsidでログインを再作成することだけです。これは、WITH SIDオプションを使用して行います。

CREATE LOGIN My_login WITH SID = 0x14585E90117152449347750164BA00A7

sidは明らかにsys.database_principalsにあるユーザーsidです。

select name, sid
from sys.database_principals
where type_desc = 'SQL_USER';
3
sepupic

PowerShellがオプションの場合は dbatools.io Copy-SQLLogin cmdlet を使用し、そうでない場合は sp_help_revlogin を使用してログインを転送する方が簡単だと思います。

Copy-SQLLoginコマンドレットははるかに簡単なアプローチであり、そのリンクにはプロセスをステップごとに進めるのに役立つビデオもありますが、PowerShellがオプションではなく、sp_help_revloginルートに移動する必要がある場合は、保存されている手順（リンクされた記事で作成した後）をServerAで実行して、ログインステートメントをServerBにコピーし、そこでステートメントを実行します。

エラーが発生した場合は、最初にServerBから既存のユーザーを削除して、SIDを同期できるようにする必要があります。

最後に、SQL 2012以降を実行している場合は、データベースを 部分的に含まれているデータベース に設定できます。これにより、セキュリティがインスタンスレベルではなくデータベースレベルで処理されるため、バックアップと共にセキュリティが転送されます。部分的に含まれているデータベースの使用には 制限 があるため、これが代わりに使用したいアプローチであると思われる場合は、まずそれらを確認してください。

0
John Eisbrener