問題タブ [log-shipping]

このシナリオでのデータベース ミラーリングとログ配布の長所と短所について、人々の意見を聞きたいと思っています。データベース バックアップの状況をセットアップする必要があり、プライマリに障害が発生したときに自動的にピックアップする必要のないセカンダリ サーバーが 1 つだけ存在する必要があります。ただし、セカンダリを回復して開始するのに時間がかかりすぎる必要はありません。

同じインスタンスで各サイズが約 10 GB の 8 つのデータベースでミラーリングとログ配布の両方をセットアップしましたが、別のデータベースをミラーリングする場合、[データベース プロパティ] ページを表示するのに非常に時間がかかります。この問題に対する提案。

ログ配布を構成する場合、送信先サーバーから送信元サーバーへのファイアウォールも開く必要がありますか?

SQL 2000 - SQL 2008 からアップグレード中です。サーバー A (SQL 2000 データベースを搭載) からサーバー B (SQL 2008 インスタンスを搭載) へのログ配布をセットアップすることは可能 (または実現可能) でしょうか?

または、アップグレードするより良い方法はありますか?

もちろん、新しい SQL 2008 インスタンスを使用してアプリケーションをテストする必要があります....

SQL Server 2005 環境でログ配布を使用することを検討しています。アイデアは、セカンダリ サーバーへの頻繁なログ配布を設定することでした。目的: セカンダリ サーバーを使用してレポート クエリを提供し、それによってプライマリ データベース サーバーの負荷を軽減します。

私はsqlservercentral フォーラムのスレッドでこれに出くわしました:

ログ配布を作成する場合、2 つの選択肢があります。norecovery オプションまたはスタンバイ オプションを使用して、ログの復元操作を実行するように構成できます。norecovery オプションを使用する場合、select ステートメントを発行することはできません。norecovery の代わりにスタンバイ オプションを使用すると、データベースで選択クエリを実行できます。ログ ファイルの復元が発生した場合、スタンバイ オプションを使用すると、ユーザーは復元プロセスによって警告なしに追い出されることに注意してください。スタンバイ オプションを使用してログ配布を構成する場合、セカンダリ データベースのすべてのプロセスを強制終了してログの復元を実行するか、データベースが使用されている場合はログの復元を実行しないかの 2 つの選択肢から選択することもできます。もちろん、2 番目のオプションを選択した場合、誰かがデータベースへの接続を開き、それを閉じないと、復元操作が実行されない可能性があります。

だから私の質問は：

• 上記は本当ですか？私の意図した方法でログ配布を本当に使用できないでしょうか?
• 本当なら、トランザクション ログの復元中にデータベースに対して SELECT ステートメントを実行できない理由を誰か説明してもらえますか?

編集：

最初の質問は、この serverfault questionの複製です。しかし、2 番目の質問に答えていただきたいと思います。トランザクション ログの復元中に SELECT ステートメントを実行できないのはなぜですか?

誰かが私にWAL配送とウォームスタンバイの問題を手伝ってくれることを願っています。私のスタンバイシステムは何週間も問題なく動作し、その後突然、存在しない.historyファイルを探し始めます。その後、クラップスアウトし、スタンバイを再構築せずに正常に再起動することはできません。

どちらのシステムもCentOS4.5とpostgres8.4.1を実行しています。NFSを使用して、本番環境からのWALファイルをスタンバイに保存します。

私のコメントとともに、ログの関連するチャンク：

何か案は？.historyファイルが何であるかさえわかりません。また、（ほとんどの場合優れた）ドキュメントはこれについてあまり明確ではありません。

PS。リンクテキストを使用でき、このアプリケーションレベルのHAナンセンスについて心配する必要がないようにVMを実行していればよかったです:-)

更新：この時点でのスタンバイサーバーからのログの一部を次に示します。サーバーの回復が停止してオンラインになったようですが、何が原因かわかりません。トリガーファイルを作成できたものは何もないと確信しています。

最初に 65 GB のデータが読み込まれる新しいファイルストリーム データベースがあり、リモート (別の大陸) の場所へのログ配布を構成したいと考えています。

ログ配布の初期設定について、プライマリのバックアップとセカンダリへの復元の間の時間のしきい値はありますか? ログ配布を構成するまで、新しいデータベースは基本的にオフラインになります。データベースのサイズが原因で、データベースが最初にバックアップされてからターゲットに復元されるまでに、数日 (数日) かかる場合があります。これは問題になりますか？

SQL Server 2005 Standard 64x、現在300以上の小さなデータベース（それぞれ5MB）、ユーザーベースは必要に応じてデータベースを追加します。ウォームスタンバイ用にログ配布を実装したいが、ウィザードを介してではなく、ログ配布されたデータベースごとに3つのジョブ（プライマリに1つ、セカンダリに2つ）を追加するように見えるためです。

自分で書いたり、QuestのLiteSpeedのようなものを使用したりしようとしていますか？それとも、何百ものSQL Serverエージェントジョブがあり、それらすべてが起動することについてあまりにもきしむのでしょうか（さらに悪いことに、それらの時間を計る必要があります）？

すべてのアドバイスを歓迎します。

約 10 個のデータベースのログ配布をセットアップする必要があります。プライマリ サーバーは当社の Web サイトからアクセスされ、セカンダリ サーバーは BI サーバーです。現時点で把握するのに苦労しているのは、フェイルオーバーが発生した後の「フェイルバック」状況を処理する最善の方法です。プライマリ サーバーを Web サイトのメイン サーバーに戻すにはどうすればよいですか?

フェイルバックを処理するための提案やベスト プラクティスはありますか?

SQL Server 2008 を使用しています。