Oracleの記事を翻訳した後： Steven Feuersteinのdeterministicとresult_cacheの違いについて、デバイスの非常に重要な詳細を補足したいと思います。これらのトピックに関する一連の記事がありますが、ここではすべてを要約し、最も重要なものを残しておきたいと思います。
1. PL / SQL関数のクエリは、それらを呼び出すクエリ自体と一致していません
実際のところ、関数内のリクエストは、呼び出し元のリクエストではなく、起動時にデータ（一貫性/一貫性）を「参照」します。また、関数自体がどのように定義されていても、クエリのWITH句で宣言された関数でも、同じ方法で一貫性のないデータを受け取ります。つまり、メインリクエストの開始から関数内のリクエストまでの間にデータが変更された場合、関数は他のデータを返します。こことここの例。
このことから、関数内にクエリを含めるべきではないこと、またはそのためのSQL演算子を作成する必要があることは明らかです。たとえば、f1関数のf1_op演算子は次のとおりです。
CREATE OPERATOR f1_op
BINDING (INT)
RETURN INT
USING F1;
さらに、SQLマクロはOracle 21に正式に登場します。まだかなりバグがありますが、将来的には多くの場合、関数を放棄できるようになります。これにより、コンテキストスイッチの削減によるパフォーマンスの向上と、データの整合性からの保護が実現します。問題。
2.リクエストの変換により、関数呼び出しの数が増える可能性があります
次のような単純なクエリについて考えてみます。
select *
from (
select xf(t10.id) a
from t10
)
where a*a >= 25;
-- t10:
/*
SQL> select id from t10;
ID
----------
1
2
3
4
5
6
7
8
9
10
10 rows selected.
*/
xf関数は何回実行されると思いますか？
答えは、オプティマイザーがどのように機能するかによって異なります。サブクエリがマージされるかどうか、およびフィルタープッシュダウンが発生するかどうかです。プランの例：
--------------------------------------------------
-- Plan 1:
Plan hash value: 2919944937
--------------------------------------------------
| Id | Operation | Name | Rows | Bytes |
--------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 3 |
|* 1 | TABLE ACCESS FULL| T10 | 1 | 3 |
--------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("XF"("T10"."ID")*"XF"("T10"."ID")>=25)
--------------------------------------------------
-- Plan 2:
Plan hash value: 2027387203
---------------------------------------------------
| Id | Operation | Name | Rows | Bytes |
---------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 13 |
| 1 | VIEW | | 1 | 13 |
|* 2 | TABLE ACCESS FULL| T10 | 1 | 3 |
---------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter("XF"("T10"."ID")*"XF"("T10"."ID")>=25)
---------------------------------------------------
-- Plan 3:
---------------------------------------------------
| Id | Operation | Name | Rows | Bytes |
---------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 13 |
|* 1 | VIEW | | 1 | 13 |
| 2 | TABLE ACCESS FULL| T10 | 1 | 3 |
---------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - filter("A"*"A">=25)
Column Projection Information
------------------------------
1 - "A"[NUMBER,22]
2 - "A"[NUMBER,22]
3.SQLでの決定論的関数のキャッシュ
3.1決定論的関数のキャッシングでは、ハッシュテーブルと関数、およびスカラーサブクエリキャッシングを使用します
Scalar Subquery Caching( SSC) Deterministic Functions Caching , , hash-.
3.2 fetch-call'a
, fetch size (arraysize sql*plus) Fetch call . : -. SSC . , SSC : hash-.
3.3 - "_query_execution_cache_max_size"
SSC.
3.4 -
"_plsql_minimum_cache_hit_percent". SSC : - , , .
:
http://orasql.org/2013/02/10/deterministic-function-vs-scalar-subquery-caching-part-1/
http://orasql.org/2013/02/11/deterministic-function-vs-scalar-subquery-caching-part-2/
http://orasql.org/2013/02/11/deterministic-function-vs-scalar-subquery-caching-part-3/
deterministic + result cache, operator + deterministic + result cache:
http://orasql.org/2014/03/31/deterministic-functions-result_cache-and-operators/
4. deterministic PL/SQL
deterministic :
PLSQL_OPTIMIZE_LEVEL
>= 2
(implicit conversions)
-"" ( to_date, to_char, nvl)
5. Result cache
SSC and Deterministic functions caching, CGA, Result cache - shared cache ( shared pool), . Fine-grained dependency tracking c (, ), (RC latches). v$result_cache_objects
(type=dependency) v$result_cache_dependency
. "" ( ), select for update c . . "".
Result Cache , deterministic , deterministic, RC, . , SQL Macro 5-10.