2

読み取り専用モードのままになっているServerAログ配布をセットアップしたと言う実稼働サーバーがあります。ServerBこのログ シッピングの目的は、一部の高価なクエリ (面倒なレポート) に対する運用サーバーの負荷を軽減することです。

ここで、ドメイン アカウントを使用していくつかのログインを作成する必要があるとします。セカンダリ データベースが にあるため、これを実行できませんstandby mode。

プライマリ サーバーでこれらのログインを作成すると、それがセカンダリ サーバーにコピーされ、そこでログが復元されると思っていましたが、そうではありません。

私はオンラインで多くの調査を行い、これを回避する方法を見つけました。これについては、次のリソースを見つけました。この記事で提案されているすべての方法を試しましたが、どれもうまくいかないようです。

1)Log Shipping in SQL Server 2008 R2 for set BI on replicated database

2)How to transfer logins and passwords between instances of SQL Server

3)Orphaned Users with Database Mirroring and Log Shipping

誰かが同じ問題を経験しましたか? あなたは何をした？この問題を回避する方法はありますか? 任意の提案をお願いします。

4

1 に答える 1

1

アリ、

もちろん、私は狡猾です...

これらの記事をチェックしてください。

http://technet.microsoft.com/en-us/magazine/2006.05.sqlqa.aspx http://blogs.msdn.com/b/reedme/archive/2009/04/24/log-shipping-database-snapshots -bummer-dude.aspx

データベース ミラーリングは、スナップショットを作成してそれをレポートできるため、より優れたソリューションです。

ただし、ミラーリングとログ配布の両方で、データベースは読み取り専用状態になります。したがって、孤立したユーザーを変更することはできません。

最善の方法は、両方のサーバーでのログインが一致していることを確認することです。したがって、オーファンは発生しません。

あなたの場合、ログ配布を削除し、DR サーバーにログインを作成し、データベースを削除し、DR サーバーにバックアップを再シードして、配布を再開する必要がある場合があります。

この分野では、私は常に SAN を使用したクラスタリングを使用していたため、経験に基づく話ではありません。問題が発生した場合は、より低い環境でこれをテストしてください。

今後のプロジェクトでは、Always On (1 つのプライマリ、1 つのセカンダリ) = 同期の場合はミラーリング、非同期の場合はログ配布を使用します。ただし、Always On では、読み取り専用のセカンダリが許可されます。これは優れています。

あなたがどのように理解するかを書き留めてください。気になります。

私の友達の世話をする。

J

于 2014-03-21T13:29:39.997 に答える