DBMS_JOB と DBMS_SCHEDULER の違いは何ですか?
4 に答える
他のフォーラムから:
dbms_job は 10g および 11g にも存在しますが、リリース 10g 以降では dbms_scheduler を使用することをお勧めします。dbms_job には新しい機能が追加されていないため、すぐにその制限に直面する可能性があります。
dbms_scheduler は dbms_job よりも堅牢で完全な機能を備えており、dbms_job にはない次の機能が含まれています。
- ジョブ実行のロギング (ジョブ履歴)
- シンプルだが強力なスケジューリング構文 (cron 構文に似ていますが、より強力です)
- オペレーティング システム上のデータベース外でのジョブの実行
- 異なるクラスのジョブ間のリソース管理
- ストアド プロシージャへのオブジェクトの受け渡しを含むジョブ引数の使用
- ジョブの特権ベースのセキュリティ モデル
- ジョブの命名とジョブ内のコメント
- 保存された再利用可能なスケジュール
10g リリース 1 以降のリリースの機能は次のとおりです。
- ジョブユニット間の依存関係 (10gR2 以降)
- 財務カレンダーと会計四半期に基づくスケジューリング (10gR2 以降)
- イベントの受信時に実行されるイベントベースのジョブ (10gR2 以降)
- リモート マシンでのジョブの実行 (11gR1 以降)
- 関心のあるジョブ イベントに関する電子メール通知 (10gR2 以降)
- ファイルの到着に基づいてジョブを開始する (10gR2 以降)
注意すべき違いの 1 つは、DBMS_JOB とは異なり、DBMS_SCHEDULER はコミットを実行するため、一部の用途には適さないことです。また、要件が単純な場合はかなり面倒です。DBMS_JOB は拡張されなくなりますが、サポートが終了する可能性はほとんどありません。これを使用し、呼び出されたトランザクションの暗黙的なコミットを実行しないなど、その動作方法に依存しているシステムが数千あるはずです。
詳細については、この Ask Tom スレッドを参照してください。
次にリストされているのは、DBMS_SCHEDULER が cron に勝る利点の一部です。
• ジョブの実行を別のジョブの完了に依存させることができます
• 堅牢なリソース バランシングと柔軟なスケジューリング機能
• データベース イベントに基づいてジョブを実行できます
• DBMS_SCHEDULER 構文は、オペレーティング システムに関係なく同じように機能します。
• データ ディクショナリを使用してステータス レポートを実行できます
• クラスター環境で作業している場合、クラスター内の各ノードの複数の cron テーブルを同期することを心配する必要はありません
次にリストされているのは、cron を使用する利点の一部です。
• 使いやすく、シンプルで、実証済みの真実
• すべての Linux/Unix ボックスでほぼ普遍的に利用可能。ほとんどの場合、Linux/Unix プラットフォームに関係なくほぼ同じように動作します (はい、小さな違いがあります)。
• データベースに依存しない。データベースとは独立して動作し、データベースのベンダーやデータベースのバージョンに関係なく同じように動作します
• データベースが利用可能かどうかに関係なく動作します