2

SQL Server 2000 にデータベースがあり、時々切り詰める必要があります。最も簡単な解決策は、複製データベースを作成し、そこにプライマリ データベースをコピーすることです。その後、プライマリ データベースは、特別に調整されたストアド プロシージャによって安全に切り捨てられます。

一方向のレプリケーションでは、バックアップ データベースにプライマリ データベースからのすべての更新が含まれることが保証されます。

レポートにはバックアップデータベースを使用し、運用データにはプライマリを使用する予定です。プライマリ データベースは、2 日に 1 回夜間に切り詰められます。データベースは数ギガバイトです。いくつかのテーブルのみが非常に大きい (1 ～ 200 万行)

考えられる落とし穴は何ですか？そのようなソリューションはどれほど信頼できるでしょうか? プライマリ データベースの速度が低下しますか?

更新:コピーを行うための DTS を使用するバリアントは良さそうに聞こえますが、独自の欠点もあります。更新された行をコピーするには、約 1 時間実行される非常に堅牢なスクリプトが必要です。プライマリ データベースの整合性制約にも問題があり、切り捨てが重要なタスクになります。このレプリケーション コールドのおかげで、状況はかなり改善されます。

ユニオン VIEW を使用することも可能ですが、完全に良い方法ではありません。これは関連する問題ですが、技術的ではありません。

4

2 に答える 2

4

レプリケーションは通常堅牢ですが、破損して更新が必要になる場合があります。レプリケーションの管理と維持は複雑になる可能性があります。プライマリ データベースが切り詰められたら、アクションが複製されないようにする必要があります。また、プライマリ データベース テーブルを数回切り捨てた後でも、セカンダリ データベースに完全な履歴が残っているため、行識別システムの改善が必要になる場合があります。

トランザクション ログを読み取るために追加のスレッドを実行する必要があるため、パブリッシャー (プライマリ) でパフォーマンス ヒットが発生します。現時点で大きな負荷がかかっていない限り、この効果に気付かない可能性があります。トランザクション ログの管理もより重要になる可能性があります。

代わりに、あなたの問題に対する別の解決策を検討します。たとえば、切り詰める前に、データベースのバックアップを取り、それを新しいデータベース名として復元できます。次に、切り捨て前のデータベースのコピーを取得し、3 部構成の名前を使用して一度に両方をクエリできます。

二次データの目的はレポートをオフにすることだとおっしゃいました。この場合、SELECT * FROM Primary.dbo.Table UNION ALL SELECT * FROM SecondaryDBJune2008.dbo.Table UNION ALL SELECT * FROM SecondaryDBOctober2008.dbo.Table のようなビューを作成できます。切り捨てを実行するたびに、このビューを最新の状態に保つ必要があります。

もう 1 つの方法は、切り捨てる前に現在のデータのスナップショットを取得し、それを単一のレポート データベースに挿入することです。そうすれば、プライマリ データベースと履歴データベースだけを使用できます。ビューを作成したら、ビューを変更する必要はありません。

GBで話しているデータ量はどれくらいですか?

切り捨てを 2 日に 1 回実行する予定であるため、2 番目の方法として、切り捨て前にデータのスナップショットを作成して単一の履歴データベースにすることをお勧めします。これは、SQL エージェント ジョブを使用して簡単に実行できます。2 つのデータ セットの同期を維持するレプリケーションについて心配する必要はありません。

于 2008-12-03T00:41:59.657 に答える
2

これにはレプリケーションを使用しません。いくつかのテーブルを 1 つの中央データベースにレプリケートする 80 以上のブランチで実行されている、かなり複雑なレプリケーション セットアップがあります。接続が数日間ダウンすると、データ管理の問題が発生します。

古いデータをアーカイブする場合は、代わりに DTS を使用してください。次に、データのコピーと切り捨て/削除を同じ DTS パッケージに組み込み、コピーが成功した場合にのみ削除が行われるように設定できます。

于 2008-12-03T01:26:35.120 に答える