1

これにSybaseASE15を使用する-定期的にテーブルから削除する行が約大量（最大10 mil）ありますが、テーブルに追加された最新のデータの選択を保持したいので、ルールテーブル上で直接切り捨てを使用します。

delete from master_table where...

上記の削除の使用は非常に遅いので、私の戦略は、保持したいデータを一時テーブルに移動し、マスターテーブルを切り捨てて、データを一時テーブルから再度移動することです。

1) select * into #temp_table from master_table where date_updated > dateadd(mi, -15, getdate()) and node_type != 'X'
2) truncate table master_table
3) insert into master_table select * from #temp_table

これでほぼ十分です。1と2のパフォーマンスは優れていますが、マスターへの挿入が遅すぎます。

したがって、私の質問は、次のいずれかをすばやく実行する方法があるかどうかに要約されます。

delete from master_table where...
insert into xyz select * from...

または、私は別のアプローチを受け入れています！

4

3 に答える 3

1

おそらく最善の解決策は、パーティショニングを使用することです。

Sybase でのパーティショニングの詳細はわかりませんが、時間ベースのパーティションを作成できる場合は、パーティションを変更することで削除できる可能性があります。

ただし、将来のパーティションを作成し、古いパーティションを削除するものが必要になります。これは、維持する必要があるソフトウェアの一部です (データベースサーバーまたは「cron」ジョブなどの他の場所で実行されるストアドプロシージャまたはスクリプトである可能性があります)。 ）。

また、node_type='X' のものが正しく削除されていることを確認する必要があります。

1 つは node_type='X' 用、もう 1 つはその他の node_type 用の 2 つの日次パーティション セットを作成し、毎日 (明日、場合によっては翌日用に) 新しいパーティションを作成し、不要な古いパーティションを削除することができます。または、データが必要な場合はそれらをマージします。

于 2010-09-10T14:33:01.537 に答える
1

master_table から (temp_table に) コピーするのは高速ですが、これらの行を master_table にコピーして戻すのは低速です。したがって、master_table にはインデックス、制約、およびトリガーがあります。それらを調べて、「定期的に」一括挿入および削除で使用されるテーブルに本当に必要かどうかを確認し、ビジネス ニーズに基づいて代替手段を見つける必要がある場合があります。

以下のソリューションでは、master_table に依存関係や制約がないことを前提としています。これを「定期的に」行っており、とにかく master_table 行のほとんどを削除しているため、永続的な temp_table を使用する方が高速です。

-- Create the copy table, for the first run
-- if not exists
create table master_table_copy         -- This is your permanent temp_table
as select * from master_table where 1=2

-- Copy rows you want to keep
insert into master_table_copy
select * from master_table
where date_updated > dateadd(mi, -15, getdate())
and node_type != 'X'

truncate table master_table

-- Rename the tables
exec sp_rename 'master_table', 'master_table_orig'
exec sp_rename 'master_table_copy', 'master_table'
exec sp_rename 'master_table_orig', 'master_table_copy'   -- use for next time
于 2011-01-18T18:10:39.103 に答える
0

状況によっては、挿入をすばやく実行するために高速 bcp が機能する場合があります。これにより、全体的な設計が変更され、シェル スクリプト (またはバッチ ファイル) が必要になりますが、動作する可能性があります (テーブルが高速 BCP を許可するように設計されている場合)。

もう 1 つ注目すべき点は、挿入が遅い理由です。ディスクの問題ですか？更新が必要なインデックスが多すぎますか? データベース構造を微調整すると、速度が向上する場合があります。

于 2010-09-11T04:45:59.340 に答える