SQL Tuning · ASPICON Newsarchiv

SQL Tuning Tipp: Bindevariablen

Thilo Solbrig, Oracle Certified Master — Sun, 24 Oct 2021 06:00:38 +0000

Home → SQL Tuning

SQL Tuning Tipp: Bindevariablen

Verfasst von Thilo Solbrig, Oracle Certified Master
24 Oktober 2021
08:00
Datenbank, DBA Tipp, Oracle Database, Performance Tuning, SQL Tuning

Die Nutzung von Literalen führt dazu, dass an sich gleiche (d.h. sich nur durch Literale unterscheidende) Statements nicht als solche erkannt, sondern jeweils einzeln behandelt. Und dann werden sie auch jeweils im Shared Pool gepuffert. Daraus ergeben sich folgende Nachteile:

Es fällt für jedes Statement CPU-Aufwand für Hard Parsing an, das im Ergebnis aber nur zu bereits bekannten Ausführungsplänen führt.
Die Pufferung dieser Statements und Ausführungspläne im Shared Pool bringt keinen Mehrwert, da die Wiederverwendung der Statements unwahrscheinlich ist.
Im Regelfall sind Oracle-Datenbanken auf Automatisches (Shared) Memory Management konfiguriert. Daher geht verschwendeter Shared Pool zu Lasten des Buffer Caches. Das zieht wiederum erhöhten I/O‑Aufwand zum Nachladen verdrängter Datenblöcke nach sich.
Diagnosetools wie AWR, Statspack oder Spotlight übertragen Statements, Ausführungspläne und ‑statistiken aus dem Shared Pool in ihr Repository. Ein mit unnötigen Statements gefüllter Shared Pool führt damit zu

* überproportional längeren Laufzeiten für die Diagnosesnapshots,

* überproportional höherem Platzbedarf in den Diagnoserepositories,

* überproportional höherem Verdrängen von Applikationsdaten aus dem Buffer Cache durch das Übertragen von Diagnosedaten in die Repositories.
Im Extremfall kann die so mittelbar von Diagnosetools verursachte Last erhebliche Performanceprobleme nach sich ziehen. Die eigentliche Überwachung der Performance wird so zum Problem für die Performance.
Sofern eine Verbesserung der Applikation nicht (mehr) oder nicht mit vertretbarem Aufwand möglich ist, kann die Ersetzung von Literalen durch Bindevariablen datenbankseitig erzwungen werden.

Hier findest du weitere Posts zu den Themen SQL Tuning bzw. Performance Tuning aus unserem News Bereich.

Share this article

Der Beitrag SQL Tuning Tipp: Bindevariablen erschien zuerst auf ASPICON.

SQL Tuning Tipp: Subquery in SELECT-Klausel

Thilo Solbrig, Oracle Certified Master — Fri, 10 Sep 2021 06:00:26 +0000

Home → SQL Tuning

SQL Tuning Tipp: Subquery in SELECT-Klausel

Verfasst von Thilo Solbrig, Oracle Certified Master
10 September 2021
08:00
Datenbank, DBA Tipp, Oracle Database, Performance Tuning, SQL Tuning

Im Rahmen von SQL-Tuning-Maßnahmen sieht man zuweilen, dass Subqueries zur Ermittlung von Spaltenwerten direkt in der SELECT-Klausel verwendet werden. Obwohl syntaktisch korrekt, ist das regelmäßig ein Stolperstein für den Optimizer. Er kommt offenkundig mit der Abschätzung “echter” Joins besser zurecht.

Da der Rückgabewert der Subquery nur ein einzeiliger Skalar oder NULL sein kann (da andernfalls die Query fehlschlagen würde), erreicht man mit Umstellung auf LEFT OUTER JOIN das selbe Ergebnis. Aus dem genannten Grund sind weder mehr als eine Zeile auf der “rechten” Seite des Joins zu erwarten noch besteht die Gefahr der Eliminierung von Ergebniszeilen der “linken” Seite durch den Join, da es sich ja um einen OUTER Join handelt.

Subquery in der SELECT-Klausel

SELECT first_name, last_name,
  (SELECT department_name
  FROM departments
  WHERE department_id = e.department_id)
FROM employees e;

-------------------------------------------------------------------------------------------
| Id  | Operation                   | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |             |   107 |  1926 |    14   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| DEPARTMENTS |     1 |    16 |     1   (0)| 00:00:01 |
|*  2 |   INDEX UNIQUE SCAN         | DEPT_ID_PK  |     1 |       |     0   (0)| 00:00:01 |
|   3 |  TABLE ACCESS FULL          | EMPLOYEES   |   107 |  1926 |     3   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------

Die ursprüngliche Query wird ähnlich einem NESTED LOOP ausgeführt. Für jede der 107 Zeilen aus EMPLOYEES wird über je einen INDEX UNIQUE SCAN der Indexeintrag des zugehörigen Departments gesucht und über je einen weiteren ROWID-Zugriff der department_name aus der DEPARTMENTS-Tabelle ermittelt. Das kann bei ausreichend großer “äußerer” Tabelle ein sehr unperformanter Zugriffspfad sein. NESTED LOOPs performen nur bei geringer Kardinalität der “äußeren” Tabelle gut.

Ersetzung durch einen Join

SELECT first_name, last_name, department_name
FROM employees e 
  LEFT JOIN departments d using (department_id);

----------------------------------------------------------------------------------
| Id  | Operation          | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |             |   107 |  3638 |     6   (0)| 00:00:01 |
|*  1 |  HASH JOIN OUTER   |             |   107 |  3638 |     6   (0)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| EMPLOYEES   |   107 |  1926 |     3   (0)| 00:00:01 |
|   3 |   TABLE ACCESS FULL| DEPARTMENTS |    27 |   432 |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------------

Der LEFT OUTER JOIN hingegen wird über einen (outer) HASH JOIN abgewickelt, der insbesondere bei großer “äußerer” Tabelle viel besser performt, als ein NESTED LOOP. Das spiegelt sich im angegebenen Beispiel vor allem in der Cost-Schätzung wider.

Hier findest du weitere Posts zu den Themen SQL Tuning bzw. Performance Tuning aus unserem News Bereich.

Share this article

Der Beitrag SQL Tuning Tipp: Subquery in SELECT-Klausel erschien zuerst auf ASPICON.

SQL Tuning Tipp: NOT IN vs NOT EXISTS

Thilo Solbrig, Oracle Certified Master — Fri, 27 Aug 2021 06:00:45 +0000

Home → SQL Tuning

SQL Tuning Tipp: NOT IN vs NOT EXISTS

Verfasst von Thilo Solbrig, Oracle Certified Master
27 August 2021
08:00
Datenbank, DBA Tipp, Oracle Database, Performance Tuning, SQL Tuning

Der Query Optimizer wandelt den NOT-IN-Operator intern in einen NOT-EXISTS-Operator um und legt eine interne NVL()-Funktion um die generierte WHERE-Klausel in der Subquery. Bedingt durch die NVL()- Funktion wird somit eine Indexnutzung unterbunden und ein Full Table Scan ausgeführt. Weitere Einzelheiten hierzu findet man in My Oracle Support, Doc ID 28934.1.

Schauen wir uns nun also an, wie sich die Operatoren NOT-IN und NOT-EXISTS in einer Query verhalten.

Query mit NOT-IN-Operator

SELECT *
FROM departments d
WHERE department_id NOT IN (
  SELECT department_id
  FROM job_history h);

-----------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |             |    21 |   525 |     6  (17)| 00:00:01 |
|   1 |  MERGE JOIN ANTI NA                   |             |    21 |   525 |     6  (17)| 00:00:01 |
|   2 |   SORT JOIN                           |             |    27 |   567 |     2   (0)| 00:00:01 |
|   3 |    TABLE ACCESS BY INDEX ROWID BATCHED| DEPARTMENTS |    27 |   567 |     2   (0)| 00:00:01 |
|   4 |     INDEX FULL SCAN                   | DEPT_ID_PK  |    27 |       |     1   (0)| 00:00:01 |
|*  5 |   SORT UNIQUE                         |             |    10 |    40 |     4  (25)| 00:00:01 |
|   6 |    TABLE ACCESS FULL                  | JOB_HISTORY |    10 |    40 |     3   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------

Gleiche Query mit NOT-EXISTS-Operator

SELECT *
FROM departments d
WHERE NOT EXISTS (
  SELECT department_id
  FROM job_history h
  WHERE h.department_id=d.department_id);

------------------------------------------------------------------------------------------
| Id  | Operation          | Name                | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                     |    21 |   525 |     3   (0)| 00:00:01 |
|   1 |  NESTED LOOPS ANTI |                     |    21 |   525 |     3   (0)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| DEPARTMENTS         |    27 |   567 |     3   (0)| 00:00:01 |
|*  3 |   INDEX RANGE SCAN | JHIST_DEPARTMENT_IX |     2 |     8 |     0   (0)| 00:00:01 |
------------------------------------------------------------------------------------------

Hier findest du weitere Posts zu den Themen SQL Tuning bzw. Performance Tuning aus unserem News Bereich.

Share this article

Der Beitrag SQL Tuning Tipp: NOT IN vs NOT EXISTS erschien zuerst auf ASPICON.

SQL Tuning Tipp: NVL() oder andere Funktionen in WHERE-Klauseln

Thilo Solbrig, Oracle Certified Master — Fri, 13 Aug 2021 06:00:48 +0000

Home → SQL Tuning

SQL Tuning Tipp: NVL() oder andere Funktionen in WHERE-Klauseln

Verfasst von Thilo Solbrig, Oracle Certified Master
13 August 2021
08:00
Datenbank, DBA Tipp, Oracle Database, Performance Tuning, SQL Tuning

Funktionen um Spalten verhindern, dass dieser Teil der Klausel einen (konventionellen) Index verwenden kann. Zudem ist es dem Optimizer (ohne weiteres) nicht möglich, die Kosten für die Funktionswerte zu ermitteln. Er geht an dieser Stelle von festen Standardwerten aus. Grundsätzlich kann man diesen Limitierungen durch function-based Indexes und/oder Extended Statistics begegnen. Beides zieht aber in jedem Fall Mehraufwand (Verwaltung, höherer DML-Aufwand etc) nach sich.

Häufig lassen sich bessere Alternativen finden.

NVL() in der WHERE Klausel

SELECT *
FROM employees e
WHERE nvl(first_name,'unknown') = 'unknown';

-------------------------------------------------------------------------------
| Id  | Operation         | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |           |     1 |    69 |     3   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| EMPLOYEES |     1 |    69 |     3   (0)| 00:00:01 |
-------------------------------------------------------------------------------

Eine saubere Alternative

SELECT *
FROM employees e
WHERE (first_name='unknown' or first_name is null);

---------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name            | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |                 |     2 |   266 |     3   (0)| 00:00:01 |
|   1 |  VIEW                                 | VW_ORE_38F5D95B |     2 |   266 |     3   (0)| 00:00:01 |
|   2 |   UNION-ALL                           |                 |       |       |            |          |
|   3 |    TABLE ACCESS BY INDEX ROWID BATCHED| EMPLOYEES       |     1 |    69 |     2   (0)| 00:00:01 |
|*  4 |     INDEX SKIP SCAN                   | EMP_NAME_IX     |     1 |       |     1   (0)| 00:00:01 |
|   5 |    TABLE ACCESS BY INDEX ROWID BATCHED| EMPLOYEES       |     1 |    69 |     1   (0)| 00:00:01 |
|*  6 |     INDEX SKIP SCAN                   | EMP_NAME_IX     |     1 |       |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------------------

TO_CHAR()-Funktion um eine Tabellenspalte

SELECT *
FROM employees e
WHERE to_char(hire_date,'YYYY-MM-DD') > '2019-01-01';

-------------------------------------------------------------------------------
| Id  | Operation         | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |           |     5 |   345 |     3   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| EMPLOYEES |     5 |   345 |     3   (0)| 00:00:01 |
-------------------------------------------------------------------------------

Eine saubere Alternative

SELECT *
FROM employees e
WHERE hire_date > to_date('2019-01-01','YYYY-MM-DD');

--------------------------------------------------------------------------------------------------------
| Id  | Operation                           | Name             | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |                  |     1 |    69 |     2   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID BATCHED| EMPLOYEES        |     1 |    69 |     2   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN                  | EMP_HIRE_DATE_IX |     1 |       |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------------

Hier findest du weitere Posts zu den Themen SQL Tuning bzw. Performance Tuning aus unserem News Bereich.

Share this article

Der Beitrag SQL Tuning Tipp: NVL() oder andere Funktionen in WHERE-Klauseln erschien zuerst auf ASPICON.

SQL Tuning Tipp: „SELECT 0“ in einer [NOT] EXISTS-Subquery

Thilo Solbrig, Oracle Certified Master — Sun, 25 Jul 2021 10:41:45 +0000

Home → SQL Tuning

SQL Tuning Tipp: „SELECT 0“ in einer [NOT] EXISTS-Subquery

Verfasst von Thilo Solbrig, Oracle Certified Master
25 Juli 2021
12:41
Datenbank, DBA Tipp, Oracle Database, Performance Tuning, SQL Tuning

Der aktuelle SQL Tuning Tipp beschäftigt sich mit der Optimierung einer Subquery. Wenn nur die Existenz der Ergebniszeile in einer Subquery von Interesse ist, ist es nicht erforderlich (teils sogar schädlich), konkrete Tabellenspalten oder gar Aggregate zu selektieren.

Das Selektieren einer konkreten Spalte ist schadlos, wenn diese Spalte Bestandteil eines in der Subquery sowieso verwendeten Indexes ist. Auch aktuelle Optimizerversionen bügeln diesen faux-pax bereits im Hintergrund aus. Andernfalls muss zum Ermitteln des Spaltenwertes unnötigerweise zusätzlich zum Index- noch ein Tabellenzugriff erfolgen.

Aggregate ( z.B. count() ) in einer Subquery, die für den Test auf Enthaltensein genutzt wird, ist unperformanter als EXISTS / IN, da das Aggregat in jedem Fall errechnet wird. Unabhängig davon, gegen welchen Wert es letztendlich verglichen wird.

Gutes Beispiel

SELECT *
FROM employees m
WHERE EXISTS (
  SELECT 0 --oder e.manager_id
  FROM employees e
  WHERE e.manager_id = m.employee_id);

-----------------------------------------------------------------------------------------
| Id  | Operation              | Name           | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |                | 31250 |  3448K|  4798   (1)| 00:00:58 |
|*  1 |  HASH JOIN             |                | 31250 |  3448K|  4798   (1)| 00:00:58 |
|   2 |   SORT UNIQUE          |                |  1000K|    12M|     9   (0)| 00:00:01 |
|   3 |    INDEX FAST FULL SCAN| EMP_MANAGER_IX |  1000K|    12M|     9   (0)| 00:00:01 |
|   4 |   TABLE ACCESS FULL    | EMPLOYEES      |  1000K|    95M|    38  (24)| 00:00:01 |
-----------------------------------------------------------------------------------------

Schlechtes Beispiel

SELECT *
FROM employees m
WHERE (
  SELECT count(*)
  FROM employees e
  WHERE m.manager_id = e.employee_id) > 0;

-------------------------------------------------------------------------------------
| Id  | Operation           | Name          | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |               |  1000K|    95M|   855K  (1)| 02:51:02 |
|*  1 |  FILTER             |               |       |       |            |          |
|   2 |   TABLE ACCESS FULL | EMPLOYEES     |  1000K|    95M|    40  (28)| 00:00:01 |
|   3 |   SORT AGGREGATE    |               |     1 |    13 |            |          |
|*  4 |    INDEX UNIQUE SCAN| EMP_EMP_ID_PK |     1 |    13 |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------

Hier findest du weitere Posts zu den Themen SQL Tuning bzw. Performance Tuning aus unserem News Bereich.

Share this article

Der Beitrag SQL Tuning Tipp: „SELECT 0“ in einer [NOT] EXISTS-Subquery erschien zuerst auf ASPICON.

SQL Tuning Tipp: ANY- und ALL- Operator

Thilo Solbrig, Oracle Certified Master — Tue, 04 May 2021 07:00:03 +0000

Home → SQL Tuning

SQL Tuning Tipp: ANY- und ALL- Operator

Verfasst von Thilo Solbrig, Oracle Certified Master
04 Mai 2021
09:00
Datenbank, DBA Tipp, Oracle Database, Performance Tuning, SQL Tuning

Der heutige SQL Tuning Tipp beschäftigt sich mit den Operatoren ANY und ALL und deren Auswirkungen auf das Thema Performance.

ALL vs. ANY

Der Performancegewinn ist bei ALL nicht wirklich erheblich, weil hier ähnlich der adäquaten Formulierung (max() in Subquery) ein Maximum ermittelt werden muss. Deutlicher zum Tragen kommt der Vorteil beim ANY-Operator, da hier im Gegensatz zum adäquaten min() von einem Abbruchkriterium profitiert werden kann.

In beiden Fällen ist jedoch die Cardinality-Schätzung bei Verwendung von ANY / ALL besser als bei der Verwendung von Aggregaten in den Subqueries, da hier wiederum der Fakt greift, dass Statistiken auf Funktionswerten nicht per se vorhanden sind. Je exakter die Cardinality-Schätzung ist, desto besser können auf dieser Query aufbauende weitere Schritte bewertet werden.

Beispiel ohne ANY-Operator (Mitarbeiter in München, die mehr verdienen als irgendein Mitarbeiter in Seattle)

SELECT first_name, last_name, salary
FROM employees JOIN departments using (department_id) JOIN locations using (location_id)
WHERE city='Munich'
AND salary > (
  SELECT min(salary)
  FROM employees JOIN departments using (department_id) JOIN locations using (location_id)
  WHERE city='Seattle');

Adäquates Beispiel mit ANY-Operator

SELECT first_name, last_name, salary
FROM employees JOIN departments using (department_id) JOIN locations using (location_id)
WHERE city='Munich'
AND salary > ANY (
  SELECT salary
  FROM employees JOIN departments using (department_id) JOIN locations using (location_id)
  WHERE city='Seattle');

Beispiel ohne ALL-Operator (Mitarbeiter in München, die mehr verdienen als alle Mitarbeiter in Seattle)

SELECT first_name, last_name, salary
FROM employees JOIN departments using (department_id) JOIN locations using (location_id)
WHERE city='Munich'
AND salary > (
  SELECT max(salary)
  FROM employees JOIN departments using (department_id) JOIN locations using (location_id)
  WHERE city='Seattle');

Adäquates Beispiel mit ALL-Operator

SELECT first_name, last_name, salary
FROM employees JOIN departments using (department_id) JOIN locations using (location_id)
WHERE city='Munich'
AND salary > ALL (
  SELECT salary
  FROM employees JOIN departments using (department_id) JOIN locations using (location_id)
  WHERE city='Seattle');

Hier findest du weitere Posts zu den Themen SQL Tuning bzw. Performance Tuning aus unserem News Bereich.

Share this article

Der Beitrag SQL Tuning Tipp: ANY- und ALL- Operator erschien zuerst auf ASPICON.

Oracle Database 21c verfügbar!

Marcel Heinrich — Tue, 02 Feb 2021 05:44:00 +0000

Home → SQL Tuning

Oracle Database 21c verfügbar!

Verfasst von Marcel Heinrich
02 Februar 2021
06:44
Blockchain, Oracle, Oracle Cloud, Oracle Database, SQL Tuning

Ende 2020 veröffentlichte Oracle das neue Database Release 21c. Dabei handelt es sich um ein sogenanntes Innovation Release der Oracle Datenbank, welches zum aktuellen Zeitpunkt in der Oracle Cloud zur Verfügung steht. Oracle liefert Innovation Releases zwischen den sogenannten Long Term Releases (aktuell 19c) und stellt damit seine neuesten Entwicklungen in Sachen Datenbanktechnologie vor und zum Testen bereit.

Durch die eher kurze Supportlaufzeit von nur zwei Jahren – ohne Aussicht auf Verlängerung via Extended Support – wird dieses Release bei bestehenden Datenbank-Infrastrukturen wohl eher nicht produktiv zum Einsatz kommen. Es sei denn, es sollen unbedingt die mehr als 200 neuesten DB Features genutzt werden, u.a.:

native Blockchain Tables
erweiterte Update-Fähigkeit und ‑Indizierung
automatische SQL Tuning Sets
erweitertes Object Activity Tracking
automatische MAVs
neuer Oracle Text Search Index
Graph-Visualisierung und User-definierte Algorithmen
u.v.m

Einen Überblick über alle Features findet ihr unter https://apex.oracle.com/database-features

Wie immer stehen wir dir gern für Rückfragen und weiteren Informationen rund um die Oracle Datenbank zur Verfügung.
Und solltest du Unterstützung bei der Konzeptionierung und Realisierung von Datenbank-Infrastrukturen oder Datenbankmigrationen benötigen, zögere nicht, dich gleich mit uns in Verbindung zu setzen.

Share this article

Der Beitrag Oracle Database 21c verfügbar! erschien zuerst auf ASPICON.

SQL Tuning Tipp: Entfernen überflüssiger Indizes

Thilo Solbrig, Oracle Certified Master — Thu, 14 Nov 2019 08:00:00 +0000

Home → SQL Tuning

SQL Tuning Tipp: Entfernen überflüssiger Indizes

Verfasst von Thilo Solbrig, Oracle Certified Master
14 November 2019
09:00
Datenbank, DBA Tipp, Oracle Database, Performance Tuning, SQL Tuning

Indizes beschleunigen auf der einen Seite zwar selektive Datenzugriffe. Auf der anderen Seite verursachen sie aber auch Overhead bei DML-Operationen, belegen Platz in der Datenbank und im Backup sowie verursachen zum Teil signifikante Ladezeiten beim Importieren von Dumps. Wenn gleich die Einsparung von Indizes in der Regel keinen Performance-Boost verursacht, sollte mit Indizierung so sparsam wie möglich umgegangen werden.

Beispiel: Die Tabelle EMPLOYEES enthält zwei Indizes

EMP_NAME_IX auf den Spalten LAST_NAME und FIRST_NAME und
EMP_LAST_NAME_IDX auf der Spalte LAST_NAME

Eine Query auf LAST_NAME und FIRST_NAME würde natürlich ideal bedient vom Index EMP_NAME_IX. Die komplette WHERE-Klausel kann über den Index abgehandelt werden:

SELECT * 
FROM employees
WHERE last_name = 'Gates' AND first_name = 'Timothy';
-------------------------------------------------------------------------------------------
| Id  | Operation                   | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |             |     1 |    69 |     2   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| EMPLOYEES   |     1 |    69 |     2   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | EMP_NAME_IX |     1 |       |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("LAST_NAME"='Gates' AND "FIRST_NAME"='Timothy')

Verzichtet man jedoch auf den Index EMP_NAME_IX, der eine Obermenge von EMP_LAST_NAME_IDX ist, kann immer noch von der Indizierung profitiert werden – auf Kosten eines etwas höheren CPU-Aufwandes für das nun zusätzlich erforderliche Filtern von

FIRST_NAME:
SELECT * 
FROM employees
WHERE last_name = 'Gates'
AND first_name = 'Timothy';
-------------------------------------------------------------------------------------------------
| Id  | Operation                   | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |                   |     1 |    69 |     2   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS BY INDEX ROWID| EMPLOYEES         |     1 |    69 |     2   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | EMP_LAST_NAME_IDX |     1 |       |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("FIRST_NAME"='Timothy')
   2 - access("LAST_NAME"='Gates')

Hier findest du weitere Posts zu den Themen SQL Tuning bzw. Performance Tuning aus unserem News Bereich.

Share this article

Der Beitrag SQL Tuning Tipp: Entfernen überflüssiger Indizes erschien zuerst auf ASPICON.