5

四半期ごとに約数億のレコードで埋め尽くされた非常に大きなテーブルがあります。

このスクリプトを使用して、既存のテーブルから別のデータベースにデータを手動で移動し、バックアップ サイズを最小限に抑え、クエリの実行時に運用データベースの負荷を軽減します。

たとえば、本番データベースから他のデータベースにデータを移動し、ソースデータベースから毎日または毎週効率的にレコードを削除するスケジュールされたスクリプトなど、より良い方法はありますか?

このテーブルへの INSERT の数が多いため、ログ ファイルが急速に大きくなっていることに注意してください。また、データをアーカイブ データベースに移動すると、DELETE がログに記録されます。

ありがとう

4

4 に答える 4

7

要件を要約します。

  1. バックアップ サイズを減らす
  2. アーカイブしてデータベース内のレコード数を減らす
  3. 過度のロギングなしでデータをアーカイブする

バックアップ サイズを小さくするには、データを別のデータベースに移動する必要があります。

ロギングに関する限り、最小限のロギングのルールに目を通し、それらに従っていることを確認する必要があります。挿入先のデータベースの復旧モデルが単純復旧モデルまたは一括ログ復旧モデルであることを確認してください。

アーカイブされたデータを挿入するには、非クラスター化を無効にし (挿入が完了した後にそれらを再構築し)、クラスター化インデックスがある場合はトレース フラグ 610 を使用し、宛先テーブルにテーブル ロックを設定します。リンクにはチェックしたいルールが他にもたくさんありますが、これらは基本的なものです。

削除の最小限のログ記録はありませんが、top 句を使用してチャンクで削除することにより、ログ ファイルの増大を最小限に抑えることができます。基本的な考え方は次のとおりです（ファイルの増加を制限するために、削除中は単純な復旧モデルに切り替えます）：

SELECT NULL;

WHILE @@ROWCOUNT > 0

     DELETE TOP (50000) FROM TABLE WHERE Condition = TRUE;

上部の数値を調整して、削除ごとに行われるログの量を調整します。また、意図したものだけを削除するように、述語条件が正しいことを確認する必要があります。これにより 50000 が削除され、行数が返された場合は、返された行数が 0 になるまで繰り返されます。

すべてのログを最小限に抑える必要がある場合は、ソース テーブルを週ごとにパーティション分割し、ソース テーブルのクローンを (同じパーティション関数と同一のインデックス構造で) 作成し、パーティションをソース テーブルからクローン テーブルに切り替え、挿入します。クローン表からアーカイブ表に移動し、クローン表を切り捨てます。これの利点は、削除ではなく切り捨てです。欠点は、セットアップ、保守、およびクエリがはるかに複雑になることです (パーティションごとに 1 つのヒープまたは B ツリーを取得するため、すべてのクエリでパーティションの削除を使用しない場合、クラスター化されたインデックス/テーブル スキャンで複数の b をスキャンする必要があります)。 -1 つだけではなく、ツリー/ヒープ)。

于 2012-10-24T01:30:11.073 に答える
3

これを行うために SSIS を使用することを考えたことがありますか。SSIS を使用して、アーカイブとバックアップを順番に実行します。tsql タスクで同じスクリプトを使用し、エージェントを使用してスケジュールすることもできます。または、エージェントを使用してスクリプトを貼り付けることもできます。

于 2012-10-23T15:16:54.027 に答える
2

データを移動する代わりに、テーブルのパーティション分割を使用できます

http://technet.microsoft.com/en-us/library/dd578580(v=sql.100).aspx

http://msdn.microsoft.com/en-us/library/ms345146(v=sql.90).aspx

定期的にデータを移動するには、SQL Server のジョブ スケジューリング機能を使用して SSIS パッケージを実行します。

おそらく、データ変換サービス (DTS) も使用できます。

于 2012-10-23T15:49:15.487 に答える