Oracle: Deterministische Funktionen, result_cache und Operatoren

Nach der Übersetzung des Oracle- Artikels : Der Unterschied zwischen deterministischem und result_cache von Steven Feuerstein möchte ich ihn mit wirklich wichtigen Details ihres Geräts ergänzen. Ich habe eine Reihe von Artikeln zu diesen Themen, aber hier möchte ich nur alles zusammenfassen und das Wichtigste belassen.





1. Abfragen in PL / SQL-Funktionen stimmen nicht mit der Abfrage selbst überein, die sie aufruft

Tatsache ist, dass Anforderungen innerhalb einer Funktion die Daten (konsistent / konsistent) zum Zeitpunkt ihres Starts "sehen" und nicht die Anforderung des Anrufers. Unabhängig davon, wie die Funktion selbst definiert ist, erhält auch die in der WITH-Klausel der Abfrage deklarierte Funktion auf dieselbe Weise inkonsistente Daten. Das heißt, wenn sich die Daten während des Intervalls zwischen dem Start der Hauptanforderung und der Anforderung innerhalb der Funktion geändert haben, gibt die Funktion andere Daten zurück. Beispiele hier und hier .





Daraus ergibt sich, dass entweder die Funktionen keine Abfragen enthalten sollten oder dass Sie einen SQL-Operator dafür erstellen müssen, zum Beispiel: den Operator f1_op für die Funktion f1:





CREATE OPERATOR f1_op
   BINDING (INT) 
   RETURN INT
   USING F1;
      
      



Darüber hinaus werden SQL-Makros offiziell in Oracle 21 angezeigt: Sie sind immer noch ziemlich fehlerhaft, aber in Zukunft können Sie in vielen Fällen Funktionen aufgeben, was aufgrund reduzierter Kontextwechsel zu Leistungssteigerungen führt und Sie vor Datenkonsistenz bewahrt Probleme.





2. Die Anzahl der Funktionsaufrufe kann aufgrund der Transformation der Anforderung höher sein

Stellen Sie sich eine einfache Abfrage wie diese vor:





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.
*/
      
      



Wie oft wird die xf-Funktion Ihrer Meinung nach ausgeführt?





Die Antwort hängt davon ab, wie das Optimierungsprogramm funktioniert: ob die Unterabfrage zusammengeführt wird oder nicht und ob ein Filter-Pushdown durchgeführt wird: Beispiele für Pläne:





--------------------------------------------------
-- 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]
      
      



Mehr Details





3. Deterministische Funktionen in SQL zwischenspeichern

3.1 Caching deterministische Funktionen verwendet Hash-Tabellen und -Funktionen sowie skalares Caching von Unterabfragen

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 :





  1. PLSQL_OPTIMIZE_LEVEL



    >= 2









  2. (implicit conversions)





  3. -"" ( 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.








All Articles