SlideShare ist ein Scribd-Unternehmen logo
Oracle-DB
Effiziente Nutzung von
Function-based Indizes
Peter Ramm Oktober 2023
Otto Group Solution Provider
(OSP)
Gründung:
März 1991
Muttergesellschaft:
Otto Group
Standorte:
Dresden, Hamburg, Altenkunstadt, Madrid, Valencia, Malaga, Taipei
Anzahl Mitarbeitende:
> 500
Geschäftsführer:
Dr. Stefan Borsutzky, Norbert Gödicke
Zur Person
Mail: Peter.Ramm@ottogroup.com
Peter Ramm
Software Architekt / Teamleiter bei OSP in Dresden
> 30 Jahre Historie in IT-Projekten
Schwerpunkte:
• Entwicklung von OLTP-Systemen auf Basis von Oracle-Datenbanken
• Architektur-Beratung bis Trouble-Shooting
• Performance-Optimierung bestehender Systeme
Function-based Indizes in Oracle-DB
§ Was sind function-based Indizes
§ Was passiert bei Index-Maintenance
§ Warum deterministische Funktionen
§ Anwendungsbeispiel Zugriff auf kleine Anteile großer Tabellen (z.B. Queue-Verarbeitung)
§ Alternative zu unique Index für nicht deterministische Funktionen
Was sind function-based Indizes
§ Indizierung erfolgt auf Basis von Funktionsergebnissen statt nativer Tabellenspalten.
§ Die Funktionen transformieren i.d.R. Werte der indizierten Tabelle.
D.h., sie haben Spalten der indizierten Tabelle als Funktionsparameter.
§ Erlaubt damit die zielgenaue Indizierung der für eine Abfrage relevanten Bedingungen (WHERE-Klausel)
§ Die genutzten Funktionen müssen determistisch sein.
§ Es können sowohl interne als auch benutzerdefinierte Funktionen verwendet werden.
§ Mehrspaltige Indizes können Funktionen und Spalten der indizierten Tabelle kombinieren.
§ Anstelle der konkreten Funktionsausdrücke können auch virtuelle Spalten indiziert werden.
§ Neben Funktionsergebnissen können auch die Ergebnisse von CASE-Ausdrücken indiziert werden
Was passiert bei Index Maintenance
§ INSERT:
- Suchen des in Sortierfolge passenden Leaf-Blocks entsprechend den indizierten Werten des Records durch
Traversieren des B-Baums
- Einfügen eines neuen Record an entsprechender Position im Leaf-Block mit den indizierten Werten und
Verweis auf Record in Tabelle (ROWID)
§ DELETE:
- Suchen des Records im Index entsprechend den indizierten Werten und der ROWID des Records
- Entfernen des gefundenen Records aus dem Leaf-Block des Index
§ UPDATE:
- Finden und Entfernen des Index-Records entsprechend den alten Werten (analog DELETE)
- Einsetzen eines neuen Index-Records entsprechend den neuen Werten (analog INSERT)
Warum deterministische Funktionen
§ Durch Deklarieren der Funktion mit Schlüsselwort DETERMINISTIC beglaubigt der Ersteller,
dass die Funktion für identische Aufrufparameter immer identische Ergebnisse liefert
§ Ob die deklarierte Funktion wirklich deterministisch ist, wird durch DB nicht geprüft
§ Nicht deterministisch sind z.B. Funktionen:
- mit Abhängigkeit des Ergebnisses von in der Funktion ausgeführten SELECT-Statements
- Mit Abhängigkeit von der Systemzeit
§ Problem nicht wirklich deterministischer Funktionen:
- INSERT funktioniert
- Bei UPDATE oder DELETE wird der vorhandene Index-Record nicht gefunden ->
ORA_08102: index key not found
- SELECT liefert unterschiedliche Ergebnisse bei FULL SCAN oder INDEX SCAN, da INDEX SCAN auf Werten
zum Zeitpunkt des INSERT basiert, während FULL SCAN auf aktuellem Funktionsergebnis basiert
Problembeispiel nicht deterministischer Funktionen
CREATE TABLE Log(Creation DATE);
CREATE OR REPLACE FUNCTION AgeSecs(creation DATE) RETURN NUMBER DETERMINISTIC IS
BEGIN
RETURN (SYSDATE - creation)*86400;
END;
/
CREATE INDEX Log_Age ON Log(AgeSecs(Creation));
INSERT INTO Log VALUES(SYSDATE);
-- Scheitert mit ORA-08102
DELETE FROM LOG;
INSERT INTO Log VALUES(SYSDATE);
INSERT INTO Log VALUES(SYSDATE);
-- Uses FULL TABLE SCAN, age based on current time
SELECT AgeSecs(creation), Creation FROM LOG;
-- Uses INDEX RANGE SCAN on function-based index, age based on time at creation as stored in index
SELECT AgeSecs(creation), Creation FROM LOG WHERE AgeSecs(creation) < 1;
Anwendungsbeispiel Zugriff auf kleine Anteile großer Tabellen
Einsichten unter Nutzung des freien Analyse-Tools „Panorama“ (https://github.com/rammpeter/panorama)
Ausgangspunkt:
• SQL mit 6000 Ausführungen/Tag und 3 Sekunden Laufzeit
• Selektiert je Ausführung im Schnitt 5 Records aus Tabelle mit 27 Mio. Records
• Sucht nach wenigen neu hinzugekommenen Records, die noch nicht versendet wurden (Sent=N)
• Zwei weitere Filter auf „Event_Context“ und Liste von Werten für „Event_Type“
• Aktuelle Indizierung ist suboptimal (Spalte „Sent“ an letzter Position im Index), Größe des Index ca. 3 GB
Alternative 1: Verschieben der Spalte „Sent“ als führende Spalte des Index
• Reduktion der Laufzeit auf < 100µs (Faktor 20000++), Größe des Index bleibt vergleichbar (1,5 GB neu)
• 4 Buffer-Gets im Index / Execution
Anwendungsbeispiel Zugriff auf kleine Anteile großer Tabellen
Alternative 2: Nutzung eines function-based Index der nur die Records mit Sent=N indiziert
§ Alle Records mit Sent != N werden nicht indiziert (Indizierter Ausdruck = NULL)
§ Der Indexwert enthält weitere Attribute außer der Spalte „Sent“.
Diese Spalte „Sent“ muss nicht Bestandteil des Index sein, da bereits Index-Wert != NULL implizit „Sent“=N enthält.
§ Unterstellt, die 5 Bedingungen für „Event-Type“ sind immer fix und der Filter auf „Event_Context“ variiert, dann
würde ein optimaler function-based Index so aussehen
§ CREATE INDEX IX_Min ON Test(CASE WHEN Sent='N' AND Event_Type IN ('DeliveryCreated',
'DeliveryUpdated', 'DeliveryDeleted', 'OrderApproved', 'PurchaseOrderApproved') THEN
Event_Context END);
§ Wird die Filterbedingung im SQL jetzt exakt wie der indizierte Ausdruck formuliert, damit wird der minimale function-
based Index nutzbar für die Abfrage
§ Reduktion der Laufzeit auf < 100µs (Faktor 20000++), Indexgröße = 64K (initial extent, 4% der vorherigen Größe)
1 Buffer-Get im Index / Execution
§ Für mehrspaltige Indizes müssen alle Spalten das NULL-Verhalten aufweisen, um die Größenreduktion zu realisieren
Alternative zu unique Index für nicht deterministische Funktionen
§ Es gab eine Anforderung, Eindeutigkeit einer Tabelle abzusichern inklusive einer zusätzlichen Spalte einer n:1-Relation
§ Implementiert wurde dies über:
- eine Funktion, die die zusätzliche Spalte aus der n:1-Relation per Select liefert
- einen unique function-based Index der als weitere Spalte den Return-Wert dieser Funktion enthält
§ Funktionierte genau so lange, bis sich Daten in der verbundenen Tabelle änderten
§ Delete in der mit unique Index abgesicherten Tabelle führte danach zu ORA-08102
§ Dieser Blog-Post beschreibt eine alternative Lösung für Garantie von Eindeutigkeiten über Tabellengrenzen hinweg
- Basis der Lösung sind Compound-Trigger
- Beispiel für Optimierung der im Trigger verwendeten SQLs
Vielen Dank für Ihr Interesse
Otto Group Solution Provider (OSP) Dresden GmbH
Freiberger Str. 35 | 01067 Dresden
T +49 (0)351 49723 0 | F +49 (0)351 49723 119
osp.de

Weitere ähnliche Inhalte

Ähnlich wie Oracle-DB: Effizient Nutzung von function-based Indizes

Oracle Datenbank-Architektur
Oracle Datenbank-ArchitekturOracle Datenbank-Architektur
Oracle Datenbank-Architektur
Markus Flechtner
 
Amazon Redshift
Amazon RedshiftAmazon Redshift
Amazon Redshift
AWS Germany
 
Markus Winand – IT-Tage 2015 – Den Suchraum des Optimizers gestalten
Markus Winand – IT-Tage 2015 – Den Suchraum des Optimizers gestaltenMarkus Winand – IT-Tage 2015 – Den Suchraum des Optimizers gestalten
Markus Winand – IT-Tage 2015 – Den Suchraum des Optimizers gestalten
Informatik Aktuell
 
Domino Statistiken verstehen und nutzen (Teil 1) - 41. DNUG Konferenz
Domino Statistiken verstehen und nutzen (Teil 1) - 41. DNUG KonferenzDomino Statistiken verstehen und nutzen (Teil 1) - 41. DNUG Konferenz
Domino Statistiken verstehen und nutzen (Teil 1) - 41. DNUG Konferenz
panagenda
 
PostgreSQL News
PostgreSQL NewsPostgreSQL News
PostgreSQL News
Peter Eisentraut
 
Heterogene Daten(-strukturen) in der Oracle Datenbank
Heterogene Daten(-strukturen) in der Oracle DatenbankHeterogene Daten(-strukturen) in der Oracle Datenbank
Heterogene Daten(-strukturen) in der Oracle Datenbank
Ulrike Schwinn
 
Real Application Testing - DOAG SIG Database 2010 - Simon Dickmeiß
Real Application Testing - DOAG SIG Database 2010 - Simon DickmeißReal Application Testing - DOAG SIG Database 2010 - Simon Dickmeiß
Real Application Testing - DOAG SIG Database 2010 - Simon Dickmeiß
OPITZ CONSULTING Deutschland
 
Content Inventur von großen Seiten - Barcamp 2014
Content Inventur von großen Seiten - Barcamp 2014Content Inventur von großen Seiten - Barcamp 2014
Content Inventur von großen Seiten - Barcamp 2014
Marketing Factory
 
Adxis Produkt Beschreibung
Adxis Produkt BeschreibungAdxis Produkt Beschreibung
Adxis Produkt Beschreibung
Andreas Wolf
 
Datenbanken - Eine Übersicht (WPMeetUP München)
Datenbanken - Eine Übersicht (WPMeetUP München)Datenbanken - Eine Übersicht (WPMeetUP München)
Datenbanken - Eine Übersicht (WPMeetUP München)
Dietmar Leher
 
Oracle Performance-Analyse mit frei verfügbaren Mitteln
Oracle Performance-Analyse mit frei verfügbaren Mitteln Oracle Performance-Analyse mit frei verfügbaren Mitteln
Oracle Performance-Analyse mit frei verfügbaren Mitteln
OPITZ CONSULTING Deutschland
 
Relevantes schneller finden – mit-Lucene und Solr
Relevantes schneller finden – mit-Lucene und SolrRelevantes schneller finden – mit-Lucene und Solr
Relevantes schneller finden – mit-Lucene und Solr
SHI Search | Analytics | Big Data
 
OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...
OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...
OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...
AWS Germany
 
MongoDB - Riesige Datenmengen schemafrei verwalten
MongoDB - Riesige Datenmengen schemafrei verwaltenMongoDB - Riesige Datenmengen schemafrei verwalten
MongoDB - Riesige Datenmengen schemafrei verwalten
Tobias Trelle
 
LAIK: A Library for Fault Tolerant Distribution of Global Data
LAIK: A Library for Fault Tolerant Distribution of Global DataLAIK: A Library for Fault Tolerant Distribution of Global Data
LAIK: A Library for Fault Tolerant Distribution of Global Data
Dai Yang
 
Erfahrungsbericht über die Aktualisierung einer Consumer Mailplattform mit UC...
Erfahrungsbericht über die Aktualisierung einer Consumer Mailplattform mit UC...Erfahrungsbericht über die Aktualisierung einer Consumer Mailplattform mit UC...
Erfahrungsbericht über die Aktualisierung einer Consumer Mailplattform mit UC...
Univention GmbH
 
MYSQL in large environments - CeBIT 2012
MYSQL in large environments - CeBIT 2012MYSQL in large environments - CeBIT 2012
MYSQL in large environments - CeBIT 2012
NETWAYS
 
20171121_DOAGKonferenz_JSON_OracleNoSQL_KPatenge
20171121_DOAGKonferenz_JSON_OracleNoSQL_KPatenge20171121_DOAGKonferenz_JSON_OracleNoSQL_KPatenge
20171121_DOAGKonferenz_JSON_OracleNoSQL_KPatenge
Karin Patenge
 
The Lotus Code Cookbook
The Lotus Code CookbookThe Lotus Code Cookbook
The Lotus Code Cookbook
Ulrich Krause
 
Dokumentenorientiere Datenbanken am Beispiel CouchDB
Dokumentenorientiere Datenbanken am Beispiel CouchDBDokumentenorientiere Datenbanken am Beispiel CouchDB
Dokumentenorientiere Datenbanken am Beispiel CouchDB
Mario Müller
 

Ähnlich wie Oracle-DB: Effizient Nutzung von function-based Indizes (20)

Oracle Datenbank-Architektur
Oracle Datenbank-ArchitekturOracle Datenbank-Architektur
Oracle Datenbank-Architektur
 
Amazon Redshift
Amazon RedshiftAmazon Redshift
Amazon Redshift
 
Markus Winand – IT-Tage 2015 – Den Suchraum des Optimizers gestalten
Markus Winand – IT-Tage 2015 – Den Suchraum des Optimizers gestaltenMarkus Winand – IT-Tage 2015 – Den Suchraum des Optimizers gestalten
Markus Winand – IT-Tage 2015 – Den Suchraum des Optimizers gestalten
 
Domino Statistiken verstehen und nutzen (Teil 1) - 41. DNUG Konferenz
Domino Statistiken verstehen und nutzen (Teil 1) - 41. DNUG KonferenzDomino Statistiken verstehen und nutzen (Teil 1) - 41. DNUG Konferenz
Domino Statistiken verstehen und nutzen (Teil 1) - 41. DNUG Konferenz
 
PostgreSQL News
PostgreSQL NewsPostgreSQL News
PostgreSQL News
 
Heterogene Daten(-strukturen) in der Oracle Datenbank
Heterogene Daten(-strukturen) in der Oracle DatenbankHeterogene Daten(-strukturen) in der Oracle Datenbank
Heterogene Daten(-strukturen) in der Oracle Datenbank
 
Real Application Testing - DOAG SIG Database 2010 - Simon Dickmeiß
Real Application Testing - DOAG SIG Database 2010 - Simon DickmeißReal Application Testing - DOAG SIG Database 2010 - Simon Dickmeiß
Real Application Testing - DOAG SIG Database 2010 - Simon Dickmeiß
 
Content Inventur von großen Seiten - Barcamp 2014
Content Inventur von großen Seiten - Barcamp 2014Content Inventur von großen Seiten - Barcamp 2014
Content Inventur von großen Seiten - Barcamp 2014
 
Adxis Produkt Beschreibung
Adxis Produkt BeschreibungAdxis Produkt Beschreibung
Adxis Produkt Beschreibung
 
Datenbanken - Eine Übersicht (WPMeetUP München)
Datenbanken - Eine Übersicht (WPMeetUP München)Datenbanken - Eine Übersicht (WPMeetUP München)
Datenbanken - Eine Übersicht (WPMeetUP München)
 
Oracle Performance-Analyse mit frei verfügbaren Mitteln
Oracle Performance-Analyse mit frei verfügbaren Mitteln Oracle Performance-Analyse mit frei verfügbaren Mitteln
Oracle Performance-Analyse mit frei verfügbaren Mitteln
 
Relevantes schneller finden – mit-Lucene und Solr
Relevantes schneller finden – mit-Lucene und SolrRelevantes schneller finden – mit-Lucene und Solr
Relevantes schneller finden – mit-Lucene und Solr
 
OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...
OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...
OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...
 
MongoDB - Riesige Datenmengen schemafrei verwalten
MongoDB - Riesige Datenmengen schemafrei verwaltenMongoDB - Riesige Datenmengen schemafrei verwalten
MongoDB - Riesige Datenmengen schemafrei verwalten
 
LAIK: A Library for Fault Tolerant Distribution of Global Data
LAIK: A Library for Fault Tolerant Distribution of Global DataLAIK: A Library for Fault Tolerant Distribution of Global Data
LAIK: A Library for Fault Tolerant Distribution of Global Data
 
Erfahrungsbericht über die Aktualisierung einer Consumer Mailplattform mit UC...
Erfahrungsbericht über die Aktualisierung einer Consumer Mailplattform mit UC...Erfahrungsbericht über die Aktualisierung einer Consumer Mailplattform mit UC...
Erfahrungsbericht über die Aktualisierung einer Consumer Mailplattform mit UC...
 
MYSQL in large environments - CeBIT 2012
MYSQL in large environments - CeBIT 2012MYSQL in large environments - CeBIT 2012
MYSQL in large environments - CeBIT 2012
 
20171121_DOAGKonferenz_JSON_OracleNoSQL_KPatenge
20171121_DOAGKonferenz_JSON_OracleNoSQL_KPatenge20171121_DOAGKonferenz_JSON_OracleNoSQL_KPatenge
20171121_DOAGKonferenz_JSON_OracleNoSQL_KPatenge
 
The Lotus Code Cookbook
The Lotus Code CookbookThe Lotus Code Cookbook
The Lotus Code Cookbook
 
Dokumentenorientiere Datenbanken am Beispiel CouchDB
Dokumentenorientiere Datenbanken am Beispiel CouchDBDokumentenorientiere Datenbanken am Beispiel CouchDB
Dokumentenorientiere Datenbanken am Beispiel CouchDB
 

Mehr von Peter Ramm

AWR und ASH lizenzfrei für alle Editionen der Oracle-DB
AWR und ASH lizenzfrei für alle Editionen der Oracle-DBAWR und ASH lizenzfrei für alle Editionen der Oracle-DB
AWR und ASH lizenzfrei für alle Editionen der Oracle-DB
Peter Ramm
 
Docker-Images mit vorinstallierter Instanz einer Oracle-DB
Docker-Images mit vorinstallierter Instanz einer Oracle-DBDocker-Images mit vorinstallierter Instanz einer Oracle-DB
Docker-Images mit vorinstallierter Instanz einer Oracle-DB
Peter Ramm
 
Oracle-DB: Performance Analysis with Panorama
Oracle-DB: Performance Analysis with PanoramaOracle-DB: Performance Analysis with Panorama
Oracle-DB: Performance Analysis with Panorama
Peter Ramm
 
Oracle-DB: Root-Cause-Analyse nach "unable to extent temp segment"
Oracle-DB: Root-Cause-Analyse nach "unable to extent temp segment"Oracle-DB: Root-Cause-Analyse nach "unable to extent temp segment"
Oracle-DB: Root-Cause-Analyse nach "unable to extent temp segment"
Peter Ramm
 
Oracle-DB: Beeinflussen der Ausführungspläne von SQL-Statements ohne Code-Anp...
Oracle-DB: Beeinflussen der Ausführungspläne von SQL-Statements ohne Code-Anp...Oracle-DB: Beeinflussen der Ausführungspläne von SQL-Statements ohne Code-Anp...
Oracle-DB: Beeinflussen der Ausführungspläne von SQL-Statements ohne Code-Anp...
Peter Ramm
 
Oracle-DB: Sicheres Identifizieren von nicht relevanten indizes
Oracle-DB: Sicheres Identifizieren von nicht relevanten indizesOracle-DB: Sicheres Identifizieren von nicht relevanten indizes
Oracle-DB: Sicheres Identifizieren von nicht relevanten indizes
Peter Ramm
 

Mehr von Peter Ramm (6)

AWR und ASH lizenzfrei für alle Editionen der Oracle-DB
AWR und ASH lizenzfrei für alle Editionen der Oracle-DBAWR und ASH lizenzfrei für alle Editionen der Oracle-DB
AWR und ASH lizenzfrei für alle Editionen der Oracle-DB
 
Docker-Images mit vorinstallierter Instanz einer Oracle-DB
Docker-Images mit vorinstallierter Instanz einer Oracle-DBDocker-Images mit vorinstallierter Instanz einer Oracle-DB
Docker-Images mit vorinstallierter Instanz einer Oracle-DB
 
Oracle-DB: Performance Analysis with Panorama
Oracle-DB: Performance Analysis with PanoramaOracle-DB: Performance Analysis with Panorama
Oracle-DB: Performance Analysis with Panorama
 
Oracle-DB: Root-Cause-Analyse nach "unable to extent temp segment"
Oracle-DB: Root-Cause-Analyse nach "unable to extent temp segment"Oracle-DB: Root-Cause-Analyse nach "unable to extent temp segment"
Oracle-DB: Root-Cause-Analyse nach "unable to extent temp segment"
 
Oracle-DB: Beeinflussen der Ausführungspläne von SQL-Statements ohne Code-Anp...
Oracle-DB: Beeinflussen der Ausführungspläne von SQL-Statements ohne Code-Anp...Oracle-DB: Beeinflussen der Ausführungspläne von SQL-Statements ohne Code-Anp...
Oracle-DB: Beeinflussen der Ausführungspläne von SQL-Statements ohne Code-Anp...
 
Oracle-DB: Sicheres Identifizieren von nicht relevanten indizes
Oracle-DB: Sicheres Identifizieren von nicht relevanten indizesOracle-DB: Sicheres Identifizieren von nicht relevanten indizes
Oracle-DB: Sicheres Identifizieren von nicht relevanten indizes
 

Oracle-DB: Effizient Nutzung von function-based Indizes

  • 1. Oracle-DB Effiziente Nutzung von Function-based Indizes Peter Ramm Oktober 2023
  • 2. Otto Group Solution Provider (OSP) Gründung: März 1991 Muttergesellschaft: Otto Group Standorte: Dresden, Hamburg, Altenkunstadt, Madrid, Valencia, Malaga, Taipei Anzahl Mitarbeitende: > 500 Geschäftsführer: Dr. Stefan Borsutzky, Norbert Gödicke
  • 3. Zur Person Mail: Peter.Ramm@ottogroup.com Peter Ramm Software Architekt / Teamleiter bei OSP in Dresden > 30 Jahre Historie in IT-Projekten Schwerpunkte: • Entwicklung von OLTP-Systemen auf Basis von Oracle-Datenbanken • Architektur-Beratung bis Trouble-Shooting • Performance-Optimierung bestehender Systeme
  • 4. Function-based Indizes in Oracle-DB § Was sind function-based Indizes § Was passiert bei Index-Maintenance § Warum deterministische Funktionen § Anwendungsbeispiel Zugriff auf kleine Anteile großer Tabellen (z.B. Queue-Verarbeitung) § Alternative zu unique Index für nicht deterministische Funktionen
  • 5. Was sind function-based Indizes § Indizierung erfolgt auf Basis von Funktionsergebnissen statt nativer Tabellenspalten. § Die Funktionen transformieren i.d.R. Werte der indizierten Tabelle. D.h., sie haben Spalten der indizierten Tabelle als Funktionsparameter. § Erlaubt damit die zielgenaue Indizierung der für eine Abfrage relevanten Bedingungen (WHERE-Klausel) § Die genutzten Funktionen müssen determistisch sein. § Es können sowohl interne als auch benutzerdefinierte Funktionen verwendet werden. § Mehrspaltige Indizes können Funktionen und Spalten der indizierten Tabelle kombinieren. § Anstelle der konkreten Funktionsausdrücke können auch virtuelle Spalten indiziert werden. § Neben Funktionsergebnissen können auch die Ergebnisse von CASE-Ausdrücken indiziert werden
  • 6. Was passiert bei Index Maintenance § INSERT: - Suchen des in Sortierfolge passenden Leaf-Blocks entsprechend den indizierten Werten des Records durch Traversieren des B-Baums - Einfügen eines neuen Record an entsprechender Position im Leaf-Block mit den indizierten Werten und Verweis auf Record in Tabelle (ROWID) § DELETE: - Suchen des Records im Index entsprechend den indizierten Werten und der ROWID des Records - Entfernen des gefundenen Records aus dem Leaf-Block des Index § UPDATE: - Finden und Entfernen des Index-Records entsprechend den alten Werten (analog DELETE) - Einsetzen eines neuen Index-Records entsprechend den neuen Werten (analog INSERT)
  • 7. Warum deterministische Funktionen § Durch Deklarieren der Funktion mit Schlüsselwort DETERMINISTIC beglaubigt der Ersteller, dass die Funktion für identische Aufrufparameter immer identische Ergebnisse liefert § Ob die deklarierte Funktion wirklich deterministisch ist, wird durch DB nicht geprüft § Nicht deterministisch sind z.B. Funktionen: - mit Abhängigkeit des Ergebnisses von in der Funktion ausgeführten SELECT-Statements - Mit Abhängigkeit von der Systemzeit § Problem nicht wirklich deterministischer Funktionen: - INSERT funktioniert - Bei UPDATE oder DELETE wird der vorhandene Index-Record nicht gefunden -> ORA_08102: index key not found - SELECT liefert unterschiedliche Ergebnisse bei FULL SCAN oder INDEX SCAN, da INDEX SCAN auf Werten zum Zeitpunkt des INSERT basiert, während FULL SCAN auf aktuellem Funktionsergebnis basiert
  • 8. Problembeispiel nicht deterministischer Funktionen CREATE TABLE Log(Creation DATE); CREATE OR REPLACE FUNCTION AgeSecs(creation DATE) RETURN NUMBER DETERMINISTIC IS BEGIN RETURN (SYSDATE - creation)*86400; END; / CREATE INDEX Log_Age ON Log(AgeSecs(Creation)); INSERT INTO Log VALUES(SYSDATE); -- Scheitert mit ORA-08102 DELETE FROM LOG; INSERT INTO Log VALUES(SYSDATE); INSERT INTO Log VALUES(SYSDATE); -- Uses FULL TABLE SCAN, age based on current time SELECT AgeSecs(creation), Creation FROM LOG; -- Uses INDEX RANGE SCAN on function-based index, age based on time at creation as stored in index SELECT AgeSecs(creation), Creation FROM LOG WHERE AgeSecs(creation) < 1;
  • 9. Anwendungsbeispiel Zugriff auf kleine Anteile großer Tabellen Einsichten unter Nutzung des freien Analyse-Tools „Panorama“ (https://github.com/rammpeter/panorama) Ausgangspunkt: • SQL mit 6000 Ausführungen/Tag und 3 Sekunden Laufzeit • Selektiert je Ausführung im Schnitt 5 Records aus Tabelle mit 27 Mio. Records • Sucht nach wenigen neu hinzugekommenen Records, die noch nicht versendet wurden (Sent=N) • Zwei weitere Filter auf „Event_Context“ und Liste von Werten für „Event_Type“ • Aktuelle Indizierung ist suboptimal (Spalte „Sent“ an letzter Position im Index), Größe des Index ca. 3 GB Alternative 1: Verschieben der Spalte „Sent“ als führende Spalte des Index • Reduktion der Laufzeit auf < 100µs (Faktor 20000++), Größe des Index bleibt vergleichbar (1,5 GB neu) • 4 Buffer-Gets im Index / Execution
  • 10. Anwendungsbeispiel Zugriff auf kleine Anteile großer Tabellen Alternative 2: Nutzung eines function-based Index der nur die Records mit Sent=N indiziert § Alle Records mit Sent != N werden nicht indiziert (Indizierter Ausdruck = NULL) § Der Indexwert enthält weitere Attribute außer der Spalte „Sent“. Diese Spalte „Sent“ muss nicht Bestandteil des Index sein, da bereits Index-Wert != NULL implizit „Sent“=N enthält. § Unterstellt, die 5 Bedingungen für „Event-Type“ sind immer fix und der Filter auf „Event_Context“ variiert, dann würde ein optimaler function-based Index so aussehen § CREATE INDEX IX_Min ON Test(CASE WHEN Sent='N' AND Event_Type IN ('DeliveryCreated', 'DeliveryUpdated', 'DeliveryDeleted', 'OrderApproved', 'PurchaseOrderApproved') THEN Event_Context END); § Wird die Filterbedingung im SQL jetzt exakt wie der indizierte Ausdruck formuliert, damit wird der minimale function- based Index nutzbar für die Abfrage § Reduktion der Laufzeit auf < 100µs (Faktor 20000++), Indexgröße = 64K (initial extent, 4% der vorherigen Größe) 1 Buffer-Get im Index / Execution § Für mehrspaltige Indizes müssen alle Spalten das NULL-Verhalten aufweisen, um die Größenreduktion zu realisieren
  • 11. Alternative zu unique Index für nicht deterministische Funktionen § Es gab eine Anforderung, Eindeutigkeit einer Tabelle abzusichern inklusive einer zusätzlichen Spalte einer n:1-Relation § Implementiert wurde dies über: - eine Funktion, die die zusätzliche Spalte aus der n:1-Relation per Select liefert - einen unique function-based Index der als weitere Spalte den Return-Wert dieser Funktion enthält § Funktionierte genau so lange, bis sich Daten in der verbundenen Tabelle änderten § Delete in der mit unique Index abgesicherten Tabelle führte danach zu ORA-08102 § Dieser Blog-Post beschreibt eine alternative Lösung für Garantie von Eindeutigkeiten über Tabellengrenzen hinweg - Basis der Lösung sind Compound-Trigger - Beispiel für Optimierung der im Trigger verwendeten SQLs
  • 12. Vielen Dank für Ihr Interesse Otto Group Solution Provider (OSP) Dresden GmbH Freiberger Str. 35 | 01067 Dresden T +49 (0)351 49723 0 | F +49 (0)351 49723 119 osp.de