2

1時間ごとに挿入/更新する必要がある非正規化テーブルを作成しました。このプロセスはデータの観点からはかなり複雑なので、ユーザーを混乱させることなくテーブルを更新するための推奨される方法を探しています。

プロセスが挿入/更新する別のテーブルを用意することを考えています。完了したら、それらの変更をライブの本番テーブルにプッシュする方法が必要です。

どんな助けでも素晴らしいでしょう！

4

2 に答える 2

4

別の解決策は、複数のスキーマを使用して、switch-a-rooを再生することです。私は仕事でこのトリックを行っていたので、この方法だけを好みます。オブジェクトの名前変更に関する警告メッセージ（抑制できません）が履歴ログをいっぱいにしていました。基本的に、2つの追加スキーマが必要です（1つはテーブルのコピーを一時的に保持するためのもので、もう1つはキャッシュされたコピーを保持するためのものです）。

CREATE SCHEMA cache AUTHORIZATION dbo;
CREATE SCHEMA hold  AUTHORIZATION dbo;

次に、キャッシュスキーマにテーブルの模倣を作成します。

SELECT * INTO cache.table FROM dbo.table WHERE 1 = 0;
-- then create any indexes etc.

データを更新するときが来たら、次のようにします。

-- step 1:
TRUNCATE TABLE cache.table;
-- (if you need to maintain FKs you may need to delete)
INSERT INTO cache.table SELECT ...

-- step 2:
-- this transaction will be almost instantaneous, 
-- since it is a metadata operation only: 

BEGIN TRANSACTION;
  ALTER SCHEMA hold  TRANSFER dbo.table;
  ALTER SCHEMA dbo   TRANSFER cache.table;
  ALTER SCHEMA cache TRANSFER hold.table;
COMMIT TRANSACTION;

理論的には、最後の転送をトランザクションから移動できます。これは、ユーザーが2回目の転送後にdbo.tableの新しいコピーのクエリを開始できるためですが、前述のように、これはほぼ瞬時に行われるため、違いが見られる場合は驚きます。並行して。

オプションでここで再度切り捨てることもできますがcache.table、データの変更を比較したり、問題が発生した場合にトラブルシューティングしたりできるように、常にデータを入力したままにしました。手順1にかかる時間によっては、最初から再入力するよりも、逆方向に転送を実行する方が速い場合があります。

名前の変更と同様に、統計が実際のテーブルと一緒に移動するときに失われるなど、このプロセスから奇妙なことが発生する可能性があります。統計は名前に固執しません。また、名前の変更と同様に、これをテストして、レポートテーブルにアクセスするためのRCSIなどの分離レベルを試してみることができます。

于 2012-02-08T02:29:58.313 に答える
2

1つの解決策は、前述の一時テーブルを使用してそれを実行し、その名前を本番テーブル名に変更することです（ただし、最初に、本番テーブルの名前を別の名前に変更します）。その後、以前の生産テーブルをドロップするだけです。もちろん、トランザクション内ですべてを行う必要があります。

したがって、次のようになります。

-- Fill tmpTable
--

-- Do renaming
begin tran t1;
execute sp_rename 'productionTable', 'productionTableBackup';
execute sp_rename 'tmpTable', 'productionTable';
commit tran t1;
于 2012-02-08T01:41:38.050 に答える