1

Oracle ウェアハウスで古いデータを廃棄することを検討しています。

概要を非常に単純化するために、PL SQL ストアド プロシージャを使用してプロセスを開発する提案が提案されました。このプロセスでは、ソース テーブルや宛先テーブルなどを指定して、Oracle の ALL_TAB_COLUMNS ビューを使用して、ソース テーブルをミラーリングするターゲット テーブルを作成します。

前の実行からの dest テーブルが存在する場合、提案されたソリューションには、ソース テーブルの現在のスキーマをターゲット (アーカイブ) テーブルと比較し、違いが見つかった場合はテーブルを同期させることが含まれます。提案された機能に制限が存在することは確かですが、仕様はこの分野ではかなり野心的であるように見えましたが、Red Gate の SQL Compare ユーティリティを PL-SQL で書き直すかどうかは疑問です。

2つの質問があると思います。

1) PL/SQL は、そのようなタスクに使用するのに本当に適切な言語ですか。私にとって、ストアド プロシージャはクイック インおよびクイック アウトのデータ操作に使用され、複雑なロジックは、C# やその他の .NET 言語など、より完全に機能するクライアント言語と見なされるものに属します。10,000 行の、インデントが不十分な単一のストアド プロシージャを予想しているので、それを確認しなければならないことにうんざりしています。Oracle SP/Pkgs がそのようである必要がないことはわかっていますが、何らかの理由で、開発者は PL\SQL を使用するときは .NET で記述するときよりもモジュール性が低くなる傾向があります。おすすめと選んだ理由を教えてください。

2) アーカイブ目的で利用できる Oracle ユーティリティ (10g を使用していると思います) はありますか? 誰かアドバイスをお勧めしますか？

コメントが提供されている間、繰り返されない価値がある場合は投票します。

どうも。

4

5 に答える 5

4

PL/SQL は、「クイックインおよびクイックアウト」データ操作のためだけのものではありません。その上に構築された非常に充実したアプリがあります。この種のタスクでは、PL/SQL に本質的な問題はありません。つまり、PL/SQL で不適切に作成された 10K 行のプロシージャが予想される場合は、使用しないでください。あなたのプログラマーに彼らが最も得意とすることをさせてください。

于 2009-09-24T22:52:10.123 に答える
3

まず、これは PL-SQL のタスクのように聞こえます。モジュール化されていないコードの問題を強制することができ、PL-SQL を使用すると、より良い結果が得られ、記述が容易になります。

概念自体に関しては、スキーマが更新される場合、どのソリューションでも問題が発生します。同期が失敗するか、さらに悪いことに、同期が行われず、データが破損します。

メインサーバーから「古いレコードの削除」を追加し、オフラインサーバーでのみ挿入/更新を実行するレプリケーションサーバーを持つことはどうですか? これにより、すべてのデータを保持しながら、ライブ データを小さく保つことができます。

于 2009-09-24T22:49:21.587 に答える
3

どのように「実行」しても、手動で実行する必要があります。

RDBMS でのデータの廃棄には危険が伴います。通常、1 つのテーブルだけをアーカイブすることはできないためです。従属テーブルもすべてアーカイブする必要があります。

次に、スキーマ変更の問題があります。アーカイブを進化するスキーマと同期させるのではなく、ツールを古いスキーマと同期させます。現在のアプリケーションを「古いデータ」に向けて、それが必ず機能すると期待できるわけではありません。アプリを現在のデータで最新の状態に保つのは非常に難しく、ましてや古いデータで適切に動作させることはできません。

データのサブセットを選択している場合は、不自然なツールに頼るよりも、手動で選択ステートメントと挿入ステートメントを作成し、整合性を確保し、値をチェックする方が安全であり、実際には簡単です。前もって難しいように見えるかもしれませんが、実際には退屈です。

しかし、いったん完了すると、何のデータをどのようにエクスポートおよびマージするかをより詳細に制御できるようになります。

これはデータベース操作であるため、PL/SQL で記述するのが賢明です。サーバーに戻すためだけに、すべてのデータをサーバーからドラッグする必要はありません。これがすべて完了した場合、PL/SQL の全体的なパフォーマンスが向上する可能性があります。

モジュール性、くぼみなどを確保することに関しては、まあ、それが野球のバットが発明された理由です.

于 2009-09-24T22:58:43.580 に答える
1

これはデータ ウェアハウスだとおっしゃっています。パーティショニングを使用していますか? その場合、パーティショニング スキームは、アーカイブする行を識別しますか? 両方の質問に対する答えが「はい」の場合、パーティション交換が探している機能である可能性があります。

于 2009-09-25T06:07:08.313 に答える
0

要件を正しく読んでいないかもしれませんが、単純ではありません

create <dest_table> as select * from <source_table>;

十分ですか？dest_table が既に存在する場合、最初にドロップしますか?

于 2009-09-24T22:59:15.240 に答える