web-dev-qa-db-ja.com

スタンバイデータベースへのユーザーマッピング

ベンダーのsFTPサイトから毎日ダウンロードされるログ配布のトランザクションファイルを使用してスタンバイモードで復元されているスタンバイデータベースがあります。

今、私はこのデータベースへの読み取り専用アクセスを、ドメイン外の誰かに与える必要があります。スタンバイ状態のため、ユーザーを作成できず、読み取りアクセスを許可できません。また、プライマリデータベースでこれを実行できるかどうかをベンダーに尋ねましたが、そうではありませんでした。

だから私はこの問題を解決する方法があるかどうかここに尋ねていますか？

データベースをオンラインステータスに変更し、データベースにマッピングされたユーザーを作成した場合、データベースを再度スタンバイに戻し、手間をかけずに復元プロセスを続行しても問題ありませんか？

sql-serversql-server-2012log-shippingloginsstandby
2
Lilly

データベースをオンラインステータスに変更し、データベースにマッピングされたユーザーを作成した場合、データベースを再度スタンバイに戻し、手間をかけずに復元プロセスを続行しても問題ありませんか？

いいえ、それはログ配布を壊します。

残念ながら、 SQL Server 2014まで 他のオプションはあまりありません。

ストアドプロシージャによるアクセスを許可 または別のデータベースのビュー。これには、クロスデータベースの所有権の連鎖を有効にする必要があります。また、テーブルが追加、変更、削除されると、時間の経過とともに多くの問題が発生する可能性があります。

関連するデータベースユーザーを使用してログ配布プライマリインスタンスでログインを作成し、ログ配布プライマリインスタンスでログインを無効にします。 SQL認証を使用している場合 すべてを機能させるには、特別なスクリプトを使用してSIDをログ配布セカンダリに転送する必要がある場合があります 。

2014以降では、CONNECT ANY DATABASEおよびSELECT ALL USER SECURABLES IN SQL SERVER読み取り専用アクセスを許可します。

3
Erik Darling

私は、ベンダーのsFTPサイトから毎日ダウンロードされたログ配布のトランザクションファイルを使用してスタンバイモードで復元されているスタンバイデータベースを持っています。

このデータベースへの読み取り専用アクセスを、ドメイン外の他のユーザーに与える必要があります。

ログ配送

log shipping でDBがスタンバイモードに留まると、プライマリからの新しいトランザクションがコミットするのを待ちます。 トランザクションログチェーン を壊さずにセカンダリDBに変更を加えることはできません。つまり、正確なレプリカではないため、ログ配布を完全に壊します。

スタンバイモードでログ配布を使用してセカンダリDBを変更するには

変更は最初にプライマリDBで発生する必要があり、次にそれらの変更はトランザクションログにある必要があります。トランザクションログは、セカンダリDBで変更が有効になる前にセカンダリDBに適用されます。

実行する手順

基本的に、トランザクションログをSFTPメールボックスに送信するプロセスを維持するSQL DBを維持するベンダーのMS SQL DBAと協力して、次のことを行う必要があります。

  1. SQL Server [プライマリ]インスタンスに新しいSQLログインを作成します
  2. 新しいログインを許可 db_datareader そのDBのデータベースロールを修正（または必要なテーブルのみへの明示的なSELECTアクセス（またはEXECへのEXECUTEなど））それらにアクセス権を与える）
  3. ユーザー名とパスワードをあなたと共有する
  4. ログインSID値をあなたと共有する

ベンダーから必要なすべての情報を取得し、ログインがMicrosoft SQL Serverのプライマリインスタンスで定義されていることを確認したら、次を実行できます CREATE LOGIN ステートメントを実行し、その情報を渡して、プライマリサーバーでの定義と一致するログインを作成します。

T-SQLの例

CREATE Login NewLogin WITH password = 'newpassword', SID = 0x90A672109A57D24585FEE4BF99E9BE19

注：すべてが一致するセカンダリインスタンスでログインを作成した場合、セキュリティの変更は引き続き行われることに注意してくださいプライマリからのこれらの変更を含むSFTP経由で取得するトランザクションログの次のラウンドが実際にセカンダリDBにコミットされるまで効果がないため、タイミングを考慮して、使用状況を外部に公開する前にテストする必要があります。

SIDを取得する

SQLログインが作成されたら、単純に sp_helplogins を使用してそのSIDの値を取得し、SQLログイン名を引数として渡すと、そのプリンシパルのSID値が返されます。

T-SQLの例

EXEC sp_helplogins 'John';

構文

sp_helplogins [ [ @LoginNamePattern = ] 'login' ]

結果セット

最初のレポートには、次の表に示すように、指定された各ログインに関する情報が含まれています。

  • 列名：ログイン名

  • データタイプ：sysname

  • 説明：ログイン名

ソース

その他のリソース

3
Pimp Juice IT

プライマリにログインを作成し、対応するユーザーをログ配布データベースに作成し、このユーザーがセカンダリで「フロー」するまで待機する必要があります。この時点で、ログインをプライマリにドロップできます。 Windows認証を使用している場合は、これで完了です。 SQL Server認証を使用する場合は、ドロップする前に新しく作成したログインのsidを覚えておいてください。セカンダリでは、このsidを使用してログインを再作成する必要があります。構文は次のとおりです。

create login yourLogin
    with password = 'yourPassword',
    sid = 0xC10434A5BE32CE4E85EA71E6B04C068F -- the sid assigned to the login on primary
2
sepupic