2

少しのアプリケーション設計に必要なアドバイス/提案。

私は2つのテーブルを使用するアプリケーションを持っています.1つはステージングテーブルで、多くの別々のプロセスが書き込みます.プロセスの「グループ」が終了すると、別のジョブが来て、結果をまとめて最終テーブルに集約し、それを削除します.グループ」をステージング テーブルから削除します。

私が抱えている問題は、ステージング テーブルがクリアされると、大量の REDO が生成され、データベースで多くの「ログ ファイルの同期」待機が発生することです。これは他の多くのアプリケーションとの共有データベースであり、これがいくつかの問題を引き起こしています。

集計を適用すると、ステージング テーブルの 20 行ごとに最終テーブルの行が約 1 行に減ります。

単一の「ステージング」テーブルではなく、「グループ」ごとにテーブルを作成することで、これを回避することを考えています。完了したら、このテーブルを削除するだけで済みます。これにより、再実行が大幅に少なくなるはずです。

私は SE しか持っていないので、パーティション分割されたテーブルはオプションではありません。また、やり直し用のより高速なディスクも、短期的にはおそらくオプションではありません。

これは悪い考えですか？提供されるより良いソリューションはありますか？

ありがとう。

4

4 に答える 4

2

プロセスに論理的な削除を実行させ（つまりDELETE_FLAG、テーブルの列を「Y」に設定する）、その後、テーブルを切り捨てる夜間処理を行うことで問題を解決できますか（削除されていない行を別の行に書き込む可能性があります）切り捨ての前にテーブルをコピーし、テーブルが切り捨てられた後にコピーして戻します)?

ログ ファイルの同期待機の原因は、ディスクが I/O に追いついていないことだと確信していますか? もちろん、それは確かに可能ですが、過剰なコミットなど、過剰なログ ファイルの同期待機の他の原因が考えられます。Pythian ブログには、ログ ファイルの同期イベントの調整に関する優れた記事があります。

于 2009-11-28T17:34:37.673 に答える
1

過剰なログ ファイルの同期の最も一般的な原因は、コミットが頻繁に行われることです。コミットは、ロックによるシステム負荷を軽減するための誤った試みで意図的にコーディングされることがよくあります。ビジネス トランザクションが完了したときにのみコミットする必要があります。

于 2009-11-29T10:07:01.940 に答える
0

私はジャスティンの提案 (「論理削除」) を好みますが、EE ライセンスを持っている場合は、パーティション分割されたテーブルを検討することもできます。集計プロセスは、行を削除する代わりにパーティションを削除する可能性があります。

于 2009-11-29T07:47:43.327 に答える
0

各グループを個別のテーブルにロードすることは、やり直しを減らすための良い計画のように思えます。各集計に続いて、個々のグループ テーブルを切り詰めることができます。

もう 1 つの (おそらくもっと悪いと思いますが) オプションは、集計されていないグループで新しいステージング テーブルを作成し、元のテーブルを削除して新しいテーブルの名前を変更し、ステージング テーブルを置き換えることです。

于 2009-11-27T23:27:50.270 に答える