2

パイプライン化された関数のドキュメントには、SQL ステートメント (通常は ) で使用される場合、DML は許可されないと記載されていますSELECT。ほとんどの例では、パイプライン化された関数はデータの生成または変換 (パラメーターとして顧客を受け入れる) に使用されますが、発行は行われません。 DML ステートメント。

現在、技術的には、Oracle からのエラーなしで SELECT を使用できます ( ORA 14551は発生しません)。ただし、選択の再現可能な奇妙な動作を経験しています。PRAGMA AUTONOMOUS_TRANSACTIONが使用されていなくても、によって取得された行は、常に現在のローカル トランザクションを考慮していないSELECTように見えます。これは、私にはバグのように感じます。さらに気がかりなことは、分散トランザクションを使用する場合 (たとえば、ローカル トランザクションではなく ORAMTS を介して)、トランザクションが使用されるという事実です。

編集: 結局のところ、奇妙な効果は、クエリ内のいくつかの WITH ステートメントに関連しているように見えますが、動作する場合と動作しない場合があります (少なくとも 10g では、Oracle オプティマイザーの現在の気分によって異なります)。場合によっては、ORA-32036 が表示されることがありますが、コードをまったく変更しないと発生しません。現在、ORA-32036 で失敗することがあるクエリは、正しいトランザクションの使用にも失敗しているクエリであり、パイプライン関数とは無関係である可能性があります。

したがって、私の具体的な質問は次のとおりです。

  • SELECTパイプライン化されたテーブル関数の s が許可されているかどうか、およびそれらのトランザクションコンテキストは何か、できれば公式の声明はありますか?

  • SQL ステートメントで使用できる一般的に使用されるクエリをモジュール化する別の方法はありますTABLE()か (テーブル関数で使用できるように)。

  • 誰かがそのような行動を経験したことがあり、それについてもっと知っていますか? メタリンクを調べましたが、残念ながらこのトピックに関する特定の情報は見つかりませんでした。

4

1 に答える 1

1

  1. 通常、DML の制限は変更 (UPDATE、DELETE ...) ステートメントのみに関係するため、SELECT は問題ありません。オラクルからの特定の声明を見つけようとします。

  2. ビューは、一般的に使用されるクエリをモジュール化するための最初のツールです。

  3. 関数にはビューに対する欠点があります。別の SELECT から呼び出された場合、メインの SELECT と同じ時点では実行されません。SELECT への各呼び出しは一貫していますが、SELECT はメイン SQL ではなく関数コードにあるため、一貫性のない結果が返される可能性があります。これは、ビューとサブセレクトでは不可能です。大きなステートメントがビューを呼び出す場合、ビューはメイン クエリと同じ時点で構築されます。

更新：パラメータ化されたクエリに関するコメントについて

パラメータ化されたビュー、つまり実行前に設定された変数に依存するビューを作成できます。以下は、 orを使用してどのように実行できるかを示すAskTom の例です。userenv('client_info')dbms_session.set_context

于 2009-10-21T06:46:55.637 に答える