私は、2億2500万件を超えるレコードを含む非常に大規模なデータベース (250 GB 以上) を扱っています。データベースは、その巨大なサイズのため、操作が困難です。このデータベースは読み取り専用としてのみ使用されます。
より高速なハードウェアの導入を検討していますが、いずれにしてもデータベースを操作する最も効率的な方法を見つけようとしています。このデータベースはマスター データベースから夜間に更新する必要があり、ダウンタイムは最小限に抑える必要があります。マスター データベースはサード パーティによって保守されています。
夜間にデータベースを効率的に更新する最善の方法を見つけようとしていますが、うまくいきません。差分バックアップとトランザクション ログ バックアップを検討しましたが、これらのいずれかを適用するには、まずデータベースの完全バックアップを復元する必要があります。私の場合、これでは差分バックアップの目的が完全に達成されません。[ダウン] タイムを節約できないからです。マスター データベースで夜間に完全バックアップを実行してから、完全バックアップを復元するだけで、より高速になります。
私は、フル バックアップを 1 回 (または月に 1 回) 実行し、その後は、元のフル バックアップに基づいて、相互に構築される何らかの増分バックアップを適用するだけのソリューションを見つけたいと考えていました。これにより、最初のフル バックアップが完了したら、増分バックアップを夜間のみ適用するため、ダウンタイムを最小限に抑えることができます。速度を上げるために、各「増分」バックアップの後にインデックスを再構築するだけです。このような本当に実用的なソリューションは、まだ見つけていません。
テスト データベースで STANDBY を使用した完全復元を試みましたが、この方法ではデータをクエリしてから、後でトランザクション ログのみを適用できました。技術的にはデータベースへの書き込みであるため、インデックスの追加などの操作は実行できないため、これはある程度限定的な成功でした。ただし、データ自体は読み取り専用になるため、これは私が求めているものに非常に近いものです。このように機能するソリューションはありますか? STANDBY オプションはこのような使用方法を想定していないため、使用は避けたいと思います。
私は現在、データベースのバックアップとパフォーマンスについて徹底的に調べており、MSDN を常に読んでいますが、この解決策は選択肢ではないようです。最後の手段として質問しようと思いました。きっと、夜間に復元を行うのは非現実的である大規模なデータベースを管理している人もいるはずです。
何か提案はありますか? これほど大きなデータベースを扱ったことがないので、パフォーマンスに関するページへの提案やリンクも歓迎します。
残念ながら、複製が唯一の答えかもしれません。
答え1
ログ シッピングは、別のサーバーのスタンバイ コピーにログを転送することで、メイン (300 GB) データベースを使用可能に保つというニーズを満たします。トランザクション ログは 15 分ごとに適用されます。レポートではスタンバイ コピーが利用されます。