In diesem Artikel soll es einmal nicht um coole, neue Features gehen sondern für die zu Unrecht
vernachlässigten, alten Features eine Lanze gebrochen werden. Diese betreffen vor allem Entwickler,
Datenmodellierer und DBAs im Entwicklungs-Umfeld.
Wir betrachten dabei u.a.
• zwei Geheimwaffen im Grabenkampf zwischen Befürwortern und Gegnern von Integrity
Constraints; Achtung: Der Autor ist parteiisch und zeigt auf, warum Constraints auch bei
großen Datenmengen für die Performance förderlich statt hinderlich sind.
• ein ANSI-SQL-Feature, das nicht nur Kompatibilität sondern vor allem Codeersparnis und
Performancegewinne bringt;
• eine ANSI-SQL-Funktion, die den Umgang mit NULLs komfortabler und dabei auch noch
schneller gestaltet und
• warum die böse, alte Cursor-FOR-LOOP doch gar nicht so lahm ist.
Einige ausgewählte Oracle PL/SQL Packages aus Version 11g und 12c werden kurz beschrieben und an Beispielen illlustriert. In Teil 2 handelt es sich dabei um:
DBMS_QOPATCH
DBMS_SPACE
DBMS_SERVICE
DBMS_FLASHBACK_ARCHIVE
Zusätzliche werden ein paar grundsätzliche Frage beantwortet wie zum Beispiel: wie finde ich einfach und schnell bestimmte PL/SQL Packages oder welche PL/SQL Packages sind obsolet.
Einige ausgewählte Oracle PL/SQL Packages aus Version 11g und 12c werden kurz beschrieben und illustriert an Beispielen. In Teil 3 handelt es sich dabei um:
DBMS_XPLAN
DBMS_ASSERT
DBMS_RESUMABLE
DBMS_UTILITY
Mehr sichere Herkunftsländer, weniger Leistungen für Asylbewerber
in Deutschland: Das Asylpaket, das am Donnerstag in erster
Lesung im Bundestag beraten wurde, trägt klar die Handschrift
der CSU-Landesgruppe. „Es braucht zügig Signale der Ordnung“,
sagte CSU-Landesgruppenvorsitzende Gerda Hasselfeldt. Denn:
„Wir sind uns einig, dass wir den Zustrom begrenzen müssen.“
(Bewegt-)Bildeinsatz in der Online-Kommunikation oder Wie setze ich Bild & Fi...Nacona
Visuelle Plattformen oder "Wie setze ich Bild & Film bei meiner Online Kommunikation ein"? Visual Platforms sind in aller Munde, doch WAN setze ich Bilder & Video WIE ein um den Kunden WO abzuholen? Positionierung, Basismarketing und aktiver Vertrieb
THEMIS ist DIE Software für Dokumentation und Beweissicherung im Brandschutz,...GRID-IT GmbH
THEMIS ist die Software für eine effiziente, planbasierte Datenerfassung und lückenlose Dokumentation bei Begehungen. THEMIS kann in jeder Branche eingesetzt werden, in der Ausführungs- und Fortschrittskontrollen, regelmäßige Kontrollbegehungen und Mängelverfolgung sowie die strukturierte Dokumentation unerlässlich sind.
Aktuell nutzen unsere Kunden THEMIS in ganz unterschiedlichen Bereichen: Im Brandschutz und in der Isoliertechnik, für die Bauleitung und Arbeitssicherheit oder in der Gebäudeverwaltung und Haustechnik, um nur einige Beispiele zu nennen.
Mit THEMIS haben Sie Ihre Dokumentation sicher im Griff und alle Informationen immer einfach abrufbereit. So haben Sie mit Sicherheit mehr Zeit – und mehr Zeit mit Sicherheit!
smartTHEMIS ist eine Dokumentations-App für das Android-Smartphone, die ebenso wie die Windows Tablet- und Desktop-Version von THEMIS der Dokumentation bei Begehungen dient.
Die Software THEMIS sowie smartTHEMIS werden von der Firma GRID-IT GmbH in Kooperation mit Experten und Instituten aus dem Brandschutz, der Bauleitung sowie der Arbeits- und Sicherheitstechnik explizit für Mängelmanagement und regelmäßige Eigenkontrollen entwickelt. Starke Partner wie VdS unterstützen beim Vertrieb.
http://www.themis-software.com/
Einige ausgewählte Oracle PL/SQL Packages aus Version 11g und 12c werden kurz beschrieben und an Beispielen illlustriert. In Teil 2 handelt es sich dabei um:
DBMS_QOPATCH
DBMS_SPACE
DBMS_SERVICE
DBMS_FLASHBACK_ARCHIVE
Zusätzliche werden ein paar grundsätzliche Frage beantwortet wie zum Beispiel: wie finde ich einfach und schnell bestimmte PL/SQL Packages oder welche PL/SQL Packages sind obsolet.
Einige ausgewählte Oracle PL/SQL Packages aus Version 11g und 12c werden kurz beschrieben und illustriert an Beispielen. In Teil 3 handelt es sich dabei um:
DBMS_XPLAN
DBMS_ASSERT
DBMS_RESUMABLE
DBMS_UTILITY
Mehr sichere Herkunftsländer, weniger Leistungen für Asylbewerber
in Deutschland: Das Asylpaket, das am Donnerstag in erster
Lesung im Bundestag beraten wurde, trägt klar die Handschrift
der CSU-Landesgruppe. „Es braucht zügig Signale der Ordnung“,
sagte CSU-Landesgruppenvorsitzende Gerda Hasselfeldt. Denn:
„Wir sind uns einig, dass wir den Zustrom begrenzen müssen.“
(Bewegt-)Bildeinsatz in der Online-Kommunikation oder Wie setze ich Bild & Fi...Nacona
Visuelle Plattformen oder "Wie setze ich Bild & Film bei meiner Online Kommunikation ein"? Visual Platforms sind in aller Munde, doch WAN setze ich Bilder & Video WIE ein um den Kunden WO abzuholen? Positionierung, Basismarketing und aktiver Vertrieb
THEMIS ist DIE Software für Dokumentation und Beweissicherung im Brandschutz,...GRID-IT GmbH
THEMIS ist die Software für eine effiziente, planbasierte Datenerfassung und lückenlose Dokumentation bei Begehungen. THEMIS kann in jeder Branche eingesetzt werden, in der Ausführungs- und Fortschrittskontrollen, regelmäßige Kontrollbegehungen und Mängelverfolgung sowie die strukturierte Dokumentation unerlässlich sind.
Aktuell nutzen unsere Kunden THEMIS in ganz unterschiedlichen Bereichen: Im Brandschutz und in der Isoliertechnik, für die Bauleitung und Arbeitssicherheit oder in der Gebäudeverwaltung und Haustechnik, um nur einige Beispiele zu nennen.
Mit THEMIS haben Sie Ihre Dokumentation sicher im Griff und alle Informationen immer einfach abrufbereit. So haben Sie mit Sicherheit mehr Zeit – und mehr Zeit mit Sicherheit!
smartTHEMIS ist eine Dokumentations-App für das Android-Smartphone, die ebenso wie die Windows Tablet- und Desktop-Version von THEMIS der Dokumentation bei Begehungen dient.
Die Software THEMIS sowie smartTHEMIS werden von der Firma GRID-IT GmbH in Kooperation mit Experten und Instituten aus dem Brandschutz, der Bauleitung sowie der Arbeits- und Sicherheitstechnik explizit für Mängelmanagement und regelmäßige Eigenkontrollen entwickelt. Starke Partner wie VdS unterstützen beim Vertrieb.
http://www.themis-software.com/
zdi Netzwerk IST. Bochum @MINT:Barcamp 2015MINT:Barcamp
Am 24. September 2015 fand im KörberForum das erste MINT:Barcamp statt. Klaus Trimborn vom zdi Netzwerk IST. Bochum stellte eine Session zum Thema Techniktalente mit Migrationshintergrund vor.
zdi Netzwerk Rhein Kreis Neuss @MINT:Barcamp 2015MINT:Barcamp
Am 24. September 2015 fand im KörberForum das erste MINT:Barcamp statt. Frank Heidemann vom zdi Netzwerk Rhein Kreis Neuss stellte eine Session zum Thema KMUs erfolgreich in die Netzwerkarbeit einbinden vor.
Die Mütterrente kommt.
In dieser Woche wurde das Rentenpaket der Bundesregierung in den Deutschen Bundestag eingebracht. Der Gesetzentwurf mit dem Titel „Rentenversicherung-Leistungsverbesserungsgesetz“ stand zur ersten Lesung an.
Komprimierung in der Oracle Datenbank (Stand 11gR2, 12c)Ulrike Schwinn
Schon seit vielen Jahren ist die Komprimierung von Daten ein wichtiger Bestandteil der Oracle Datenbank und wird beständig weiterentwickelt. Dies zeigte sich besonders auch im Datenbankrelease 11g mit der Einführung von neuen Techniken im Zusammenhang mit der neuen Option Advanced Compression. Die Komprimierung ist nun beispielsweise unabhängig vom Anwendungs– Workload und zusätzlich um die Bereiche unstrukturierte Daten, Backup Daten und Netzwerk (im Data Guard Umfeld) Komprimierung erweitert worden.
In Oracle Database 12c sind sogar Eigenschaften zur Verbesserung des Storage Management ergänzt worden. DieSlides geben einen Übernlick über den Stand der Komorimierung in der Oracle datenabnk bis zum aktuellen Release Stand
Norbert Rieger – IT-Tage 2015 – Optimierung der Performance bei Oracle-Datenb...Informatik Aktuell
Da bei vielen Kunden nur die Oracle Standard Edition zur Verfügung steht, stehen dem DBA einige wirksame Werkzeuge wie das Automatic Workload Repository nicht zur Verfügung. In dem Vortrag wird der Referent an konkreten Beispielen aufzeigen, wie die Performance von Datenbanken auch mit der Standard Edition analysiert und optimiert werden kann. Besonderen Raum wird die Vorstellung von automatisierten Optimierungsskripten einnehmen.
Oracle SQL*Plus
Übersicht über das Werkzeug für die Oracle Datenbank
Arbeiten mit SQL*Plus
Quickconnect mit SQL*Plus 10g
Die SQL*Plus-Editier-Befehle
Erweiterte Funktionalität von SQL*Plus
Die Präsentation gibt einen kurzen Überblick über die neuen Oracle Text Features in Oracle Database 12c. Die Beispiele basieren auf dem OTN Sample Code (siehe Präsentation) bzw. auf den Oracle Text Böog Einträgen und illustrieren die neuen Features.
zdi Netzwerk IST. Bochum @MINT:Barcamp 2015MINT:Barcamp
Am 24. September 2015 fand im KörberForum das erste MINT:Barcamp statt. Klaus Trimborn vom zdi Netzwerk IST. Bochum stellte eine Session zum Thema Techniktalente mit Migrationshintergrund vor.
zdi Netzwerk Rhein Kreis Neuss @MINT:Barcamp 2015MINT:Barcamp
Am 24. September 2015 fand im KörberForum das erste MINT:Barcamp statt. Frank Heidemann vom zdi Netzwerk Rhein Kreis Neuss stellte eine Session zum Thema KMUs erfolgreich in die Netzwerkarbeit einbinden vor.
Die Mütterrente kommt.
In dieser Woche wurde das Rentenpaket der Bundesregierung in den Deutschen Bundestag eingebracht. Der Gesetzentwurf mit dem Titel „Rentenversicherung-Leistungsverbesserungsgesetz“ stand zur ersten Lesung an.
Komprimierung in der Oracle Datenbank (Stand 11gR2, 12c)Ulrike Schwinn
Schon seit vielen Jahren ist die Komprimierung von Daten ein wichtiger Bestandteil der Oracle Datenbank und wird beständig weiterentwickelt. Dies zeigte sich besonders auch im Datenbankrelease 11g mit der Einführung von neuen Techniken im Zusammenhang mit der neuen Option Advanced Compression. Die Komprimierung ist nun beispielsweise unabhängig vom Anwendungs– Workload und zusätzlich um die Bereiche unstrukturierte Daten, Backup Daten und Netzwerk (im Data Guard Umfeld) Komprimierung erweitert worden.
In Oracle Database 12c sind sogar Eigenschaften zur Verbesserung des Storage Management ergänzt worden. DieSlides geben einen Übernlick über den Stand der Komorimierung in der Oracle datenabnk bis zum aktuellen Release Stand
Norbert Rieger – IT-Tage 2015 – Optimierung der Performance bei Oracle-Datenb...Informatik Aktuell
Da bei vielen Kunden nur die Oracle Standard Edition zur Verfügung steht, stehen dem DBA einige wirksame Werkzeuge wie das Automatic Workload Repository nicht zur Verfügung. In dem Vortrag wird der Referent an konkreten Beispielen aufzeigen, wie die Performance von Datenbanken auch mit der Standard Edition analysiert und optimiert werden kann. Besonderen Raum wird die Vorstellung von automatisierten Optimierungsskripten einnehmen.
Oracle SQL*Plus
Übersicht über das Werkzeug für die Oracle Datenbank
Arbeiten mit SQL*Plus
Quickconnect mit SQL*Plus 10g
Die SQL*Plus-Editier-Befehle
Erweiterte Funktionalität von SQL*Plus
Die Präsentation gibt einen kurzen Überblick über die neuen Oracle Text Features in Oracle Database 12c. Die Beispiele basieren auf dem OTN Sample Code (siehe Präsentation) bzw. auf den Oracle Text Böog Einträgen und illustrieren die neuen Features.
Einige ausgewählte Oracle PL/SQL Packages aus Version 11g und 12c werden kurz beschrieben und an Beispielen erklärt. In Teil 1 handelt es sich dabei um folgende Packages:
DBMS_XDB_CONFIG
DBMS_COMPRESSION
DBMS_REDEFINITION
DBMS_SQL_MONITOR
DBMS_PARALLEL_EXECUTE
SQL Tuning Sets sind seid jeher ein wichtiges Mittel in der Datenbank um SQL Workloads in der Datenbank zu speichern. Sie geben schnell Aufschluss über das verwendete SQL und bieten eine gute Grundlage zum Tuning oder für Advisors.
racle 11g verspricht interessante Neuerungen. Rund vierhundert neue Features haben die Entwickler aus Redwood Shores im neuesten Release implementiert.
Der Hersteller hebt Erleichterungen für Datenbankadministratoren und Verbesserungen der Datenverwaltung hervor. So lassen sich Aktualisierungen der Serversoftware im laufenden Betrieb einspielen. Hochverfügbare Standby-Systeme können nun standardmäßig für ein Reporting genutzt werden. Automatic Storage Management, eine Art integrierter Volume Manager, unterstützt bei der Datenspeicherung. Nicht zu vergessen: Flashback Data Archive erlaubt eine automatische Historisierung von Daten - und das ohne Aufwände für zusätzliche Eigenentwicklungen. Der "Partition Advisor" schlägt geeignete Partitionen für Datentabellen vor; wahlweise kann er diese Zerlegungen auch automatisch durchführen. Mit Real Application Testing können Transaktionen aufgezeichnet und für Lasttests genutzt werden.
Die Liste ließe sich nahezu endlos fortführen. Doch welche der Neuerungen sind tatsächlich sinnvoll und nützlich? Lohnt sich der Wechsel? Welche Migrationspfade gibt es?
Übersicht der wichtigsten Neuerungen in Oracle DB 11g
Was bringen die "New Features" wirklich?
Wie stabil ist das neueste Release?
Welche Migrationspfade gibt es?
Lang ersehnt und endlich verfügbar: Mit Oracle Database 18c gibt es jetzt auch private temporäre Tables (engl. private temporary tables). Wie funktionieren diese? Was muss man berücksichtigen? Welche Anwendungsfälle gibt es? Antworten auf diese Fragen gibt es zusätzlich auch in unserem Blog unter https://apex.oracle.com/pls/apex/germancommunities/dbacommunity/tipp/6581/index.html
In PostgreSQL kann man sich mit "explain" ansehen, welchen Execution Plan PostgreSQL für eine Query verwendet. Das hilft beim Suchen von Performance Problemen und hilft, den Durchsatz der Database zu steigern.
Markus Winand – IT-Tage 2015 – Den Suchraum des Optimizers gestaltenInformatik Aktuell
Auf seiner Suche nach dem optimalen Ausführungsplan ist der Optimizer in einen Käfig gesperrt, der von den SQL-Abfragen und dem physischen Datenbank-Design vorgegeben ist. Per Definition kann der Optimizer nur den besten Ausführungsplan innerhalb dieses Käfigs finden – auch wenn außerhalb bessere Ausführungspläne sind. In diesem Vortrag werden wir sehen, wie Indizierung diesen Käfig beeinflusst und lernen, wie man durch kluge Indizierung den Käfig so gestaltet, dass der absolut beste Ausführungsplan in der Reichweite des Optimizers liegt.
http://www.opitz-consulting.com
Nicht immer stehen einem DBA GUI-basierte (und oftmals teure) Tools zur Verfügung, um ein Performance-Problem in der Datenbank zu analysieren. Mit den vorhandenen "Bordmitteln" der Datenbank kann man jedoch auch eine gute Diagnose stellen. Dieser Vortrag widmet sich einer Auswahl dieser Werkzeuge und legt einen Schwerpunkt auf die Möglichkeiten, die einem in der Standard Edition und ohne Tuning Pack zur Verfügung stehen.
Unser Experte Uwe Küchler hat beim DOAG Community Webcast am 8.4.2016 eine Auswahl von Werkzeugen vorgestellt.
--
Über uns:
Als führender Projektspezialist für ganzheitliche IT-Lösungen tragen wir zur Wertsteigerung der Organisationen unserer Kunden bei und bringen IT und Business in Einklang. Mit OPITZ CONSULTING als zuverlässigem Partner können sich unsere Kunden auf ihr Kerngeschäft konzentrieren und ihre Wettbewerbsvorteile nachhaltig absichern und ausbauen.
Besuchen Sie unsere Homepage: http://www.opitz-consulting.com
MySQL Performance Tuning für Oracle-DBA'sFromDual GmbH
MySQL Performance Tuning
* Was ist Performance?
* Was kostet Performance?
* Tuning Massnahmen
* MySQL Konfiguration
* Wo schauen?
* Langsame Abfragen finden
* Optimiere das Query!
* Monitoring
Oracle-DB: Beeinflussen der Ausführungspläne von SQL-Statements ohne Code-Anp...Peter Ramm
Zur Beeinflussung der Laufzeit von SQL-Statements gibt es diverse Verfahren, Optimierung der SQL-Syntax, Nutzung von Optimizer-Hints etc. .
Diese erfordern aber oftmals ein Ausrollen der geänderten Software mit dem entsprechenden Zeit- und Prozessaufwand bis zur produktiven Aktivierung.
In kritischen Produktions-Szenarien ist oft eine schnellere Lösung von Problemen mit SQL-Ausführung nötig.
Dieser Vortrag demonstriert, mit welchen Verfahren der Oracle-DB sich SQL-Ausführungen auch ohne Ausrollen von Software-Änderungen ad hoc beeinflussen lassen.
Das Tool Panorama erlaubt dabei über GUI die Identifikation der kritischen SQL und Generierung der für ihre schnelle Optimierung nötigen komplexen DB-Kommandos.
2. Zur Person
Generation C=64
Seit über 25 Jahren in der IT tätig
1997-2000 bei Oracle
Seither durchgehend Oracle-Berater, im DBA-
und Entwicklungs-Umfeld
Seit 2001: Valentia GmbH, Frankfurt am Main
3. Agenda
Vernachlässigte Features seit Oracle 8.0
Alt, aber bezahlt: Integrity Constraints
Warum wir sie (doch) brauchen
Geheimwaffe 1: RELY
Geheimwaffe 2: DEFERRABLE
Gefahrenherde
ANSI 1: WITH anstatt Temp-Tabellen
ANSI 2: COALESCE() vs. NVL()
4. Constraints: Contra
Eine unendliche Geschichte:
„Wir setzen keine Constraints in unserer [großen Datenbank|
DWH-DB|...] ein, weil die Performance dann zu schlecht ist“
Es folgen einige Gegenbeweise!
5. Constraints: Rückblick
Schützen Integrität der Daten, sowohl
Inhalte als auch
Beziehungen
Information über den Aufbau der Daten
Essentiell für den Optimizer
Weil er den Aufbau der Daten nicht erraten kann!
6. Constraints: Rückblick
Primärschlüssel
Inhalte der zugehörigen Spalten identifizieren einen
Datensatz eindeutig
NULL ist im Schlüssel nicht erlaubt
Eindeutigkeitsschlüssel
Eindeutigkeit über die gewählten Spalten
NULL ist im Schlüssel erlaubt
7. Constraints: Rückblick
NOT NULL und Check-Constraints
beschränken die Inhalte einer Spalte
NOT NULL → Pflichtfeld
Check-C. begrenzen Inhalte auf Wertelisten →
Optimizer „weiß” dadurch, ohne LIO, ob Prädikate
leere Mengen zurück liefern.
Design-Entscheidung, ob Check-C. die Wartbarkeit
beeinträchtigen oder nicht.
8. Constraints: Rückblick
Foreign Key Constraints (Fremdschlüssel)
Konsistenz zwischen abhängigen Tabellen
Dokumentation der Zusammenhänge im
Datenmodell
Aussage für den Optimizer, daß zu einem (NOT
NULL-) Wert in einer Kind-Tabelle definitiv ein Wert
in der Eltern-Tabelle existiert.
9. Constraints: Auswirkungen
CREATE TABLE demo
(
id NUMBER NOT NULL
, name VARCHAR2(50)
, typ VARCHAR2(1)
, CONSTRAINT demo_typ_cc CHECK ( typ IN ('a','b') )
);
INSERT INTO demo VALUES( 1, 'Asterix', 'a' );
INSERT INTO demo VALUES( 2, 'Oraculix', 'b' );
SET AUTOTRACE TRACEONLY
SELECT count(*) FROM demo WHERE name IS NULL;
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
7 consistent gets
0 physical reads
10. Constraints: Auswirkungen
Die vorausgegangene Abfrage auf eine Spalte ohne NOT NULL-
Constraint führte zu einem Table Scan, also logischem I/O (LIO).
Fragen wir nun eine Spalte mit Constraint ab:
SELECT count(*) FROM demo WHERE id IS NULL;
----------------------------------------------------
| Id | Operation | Name | Rows | Bytes |
----------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 13 |
| 1 | SORT AGGREGATE | | 1 | 13 |
|* 2 | FILTER | | | |
| 3 | TABLE ACCESS FULL| DEMO | 2 | 26 |
----------------------------------------------------
11. Constraints: Auswirkungen
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter(NULL IS NOT NULL)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
0 consistent gets
0 physical reads
Die Abfrage wurde nun ohne LIO durchgeführt.
Die etwas eigenartige Filteroperation “NULL IS NOT NULL” zeigt,
daß der Optimizer die Möglichkeit zur Vereinfachung der Abfrage
wahrgenommen hat.
12. Constraints: Auswirkungen
Nun zur Spalte mit dem Check-Constraint:
SELECT count(*) FROM demo WHERE typ='c';
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
0 consistent gets
0 physical reads
Auch hier erkennt der Optimizer, daß aufgrund des „unmöglichen“
Prädikats kein Tabellenzugriff benötigt wird.
13. Constraints: Auswirkungen
Kommen wir nun zu den Fremdschlüsseln. Dazu bauen wir zu der
Tabelle „demo“ noch eine Tabelle mit Details zur Spalte „typ“, aber
zunächst ohne Fremdschlüssel:
CREATE TABLE demo_typ
(
typ VARCHAR2(1) NOT NULL
, detail VARCHAR2(50) NOT NULL
, CONSTRAINT typ_pk PRIMARY KEY ( typ )
);
INSERT INTO demo_typ VALUES( 'a', 'Gallier' );
INSERT INTO demo_typ VALUES( 'b', 'Informatiker' );
14. Constraints: Auswirkungen
Wenn wir nun die Tabellen „demo“ und „demo_typ“ mit einem Join
abfragen, so wird dieser Join auch dann ausgeführt, wenn gar
keine Informationen aus „demo_typ“ verlangt waren:
SELECT name FROM demo NATURAL JOIN demo_typ;
-----------------------------------------------------
| 0 | SELECT STATEMENT | | 2 | 62 |
| 1 | NESTED LOOPS | | 2 | 62 |
| 2 | TABLE ACCESS FULL| DEMO | 2 | 58 |
|* 3 | INDEX UNIQUE SCAN| TYP_PK | 1 | 2 |
-----------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - access("DEMO"."TYP"="DEMO_TYP"."TYP")
filter("DEMO_TYP"."TYP"='a' OR "DEMO_TYP"."TYP"='b')
15. Constraints: Auswirkungen
Nun fügen wir einen Fremdschlüssel von „demo“ zu „demo_typ“
hinzu und führen die Abfrage erneut aus:
ALTER TABLE demo ADD
CONSTRAINT dem_demtyp_fk FOREIGN KEY ( typ ) REFERENCES demo_typ ( typ );
SELECT name FROM demo NATURAL JOIN demo_typ;
--------------------------------------------------
| Id | Operation | Name | Rows | Bytes |
--------------------------------------------------
| 0 | SELECT STATEMENT | | 2 | 58 |
|* 1 | TABLE ACCESS FULL| DEMO | 2 | 58 |
--------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("DEMO"."TYP" IS NOT NULL)
16. Constraints: Auswirkungen
Table Elimination / Join Elimination
Optimizer erkennt, daß ein Join nicht benötigt wird,
weil die Spalten einer der Tabellen gar nicht
abgefragt werden.
Sehr praktisch bei Abfragen über Views.
Dazu muß er wissen, daß es in der Eltern-Tabelle
mindestens eine und höchstens eine Entsprechung
gibt.
Genau diese Information beinhaltet ein
Fremdschlüssel.
17. Constraints: Auswirkungen
Prüfen wir abschließend, was passiert, wenn Check-Constraints zu
Table Elimination führen müssten:
SELECT name, detail
FROM demo d, demo_typ t
WHERE d.typ = t.typ
AND d.typ = 'c';
-------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |
-------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 58 |
|* 1 | FILTER | | | |
| 2 | MERGE JOIN CARTESIAN | | 1 | 58 |
|* 3 | TABLE ACCESS FULL | DEMO | 1 | 29 |
| 4 | BUFFER SORT | | 2 | 58 |
| 5 | TABLE ACCESS BY INDEX ROWID| DEMO_TYP | 2 | 58 |
|* 6 | INDEX UNIQUE SCAN | TYP_PK | 1 | |
-------------------------------------------------------------------
Sieht zunächst nicht gut aus, aber:
18. Constraints: Auswirkungen
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter(NULL IS NOT NULL AND NULL IS NOT NULL)
3 - filter("D"."TYP"='c')
6 - access("D"."TYP"="T"."TYP")
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
0 consistent gets
0 physical reads
0 redo size
344 bytes sent via SQL*Net to client
408 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
0 rows processed
Der Optimizer kombiniert beide Möglichkeiten und liefert die leere
Menge ohne LIO und CPU-Last für Joins zurück.
19. Constraints: Contra, die 2.
„Das ist ja alles schön und gut, aber die Zeit, um diese
Constraints alle aufzubauen und aufrecht zu erhalten, haben
wir einfach nicht“
Es folgen einige Gegenmaßnahmen!
20. Constraint-Tuning: NOVALIDATE
ALTER CONSTRAINT … ENABLE NOVALIDATE
Wenn Konsistenz der Daten bekannt ist
Prüft die vorhandenen Daten nicht, nur die
nachfolgenden.
Nachteile:
Es werden nur Non-Unique Indizes angelegt
Vorteile von NOT NULL- und Check-
Constraints werden nicht genutzt
s.u., bei Deferrable Constraints.
21. Constraint-Tuning: RELY
Seit Oracle 8i
Ein RELY-Constraint wird nicht „enforced“
Oracle vertraut der Angabe des Designers
Nur informativ im Data Dictionary
Alle Arten von Constraints, außer NOT NULL
RELY auf Fremdschlüssel erfordert RELY auf
Primärschlüssel im Ziel.
Praktisch im DWH-Umfeld, wenn Integrität
bereits durch Beladeprozesse gewährleistet ist.
22. Constraint-Tuning: RELY
Können auch auf Views angewandt werden
Und zwar nur RELY-Constraints!
Ermöglicht Query Rewrite durch den Optimizer.
Kann beim Abfragen nutzen, schadet nicht
beim Schreiben
Anwendung auch zur Dokumentation
z.B. per Reverse Engineering in ein Modellierungs-
Tool
23. Constraint-Tuning: Beispiele
CREATE TABLE demo
(
id NUMBER NOT NULL ENABLE NOVALIDATE
, name VARCHAR2(50)
, typ VARCHAR2(1)
, CONSTRAINT demo_typ_cc CHECK ( typ IN ('a','b') ) RELY ENABLE NOVALIDATE
);
INSERT INTO demo VALUES( 1, 'Asterix', 'a' );
INSERT INTO demo VALUES( 2, 'Oraculix', 'b' );
CREATE TABLE demo_typ
(
typ VARCHAR2(1) NOT NULL
, detail VARCHAR2(50) NOT NULL
, CONSTRAINT typ_pk PRIMARY KEY ( typ ) RELY
);
INSERT INTO demo_typ VALUES( 'a', 'Gallier' );
INSERT INTO demo_typ VALUES( 'b', 'Informatiker' );
ALTER TABLE demo ADD
CONSTRAINT dem_demtyp_fk FOREIGN KEY ( typ ) REFERENCES demo_typ ( typ )
RELY ENABLE NOVALIDATE;
24. Constraints: Query Rewrite
Rewrite: SQL wird im Hintergrund umgeschrieben, so daß z.B.
anstelle der Tabellen im SQL auf eine Materialized View
zugegriffen wird.
Dazu bauen wir uns eine Mview auf die Demo-Tabellen:
CREATE MATERIALIZED VIEW demo_mv
BUILD IMMEDIATE
REFRESH ON DEMAND
ENABLE QUERY REWRITE
AS
SELECT t.detail, count (*)
FROM demo d, demo_typ t
WHERE d.typ = t.typ
GROUP BY t.detail;
25. Constraints: Query Rewrite
Einfachste Variante des Query Rewrite: Es wird dieselbe Abfrage
wie in der Materialized View verwendet:
SELECT t.detail, count (*)
FROM demo d, demo_typ t
WHERE d.typ = t.typ
GROUP BY t.detail;
DETAIL COUNT(*)
-------------------------------------------------- ----------
Gallier 1
Informatiker 1
--------------------------------------------------------
| Id | Operation | Name | Rows |
--------------------------------------------------------
| 0 | SELECT STATEMENT | | 2 |
| 1 | MAT_VIEW REWRITE ACCESS FULL| DEMO_MV | 2 |
--------------------------------------------------------
26. Constraints: Query Rewrite
Query Rewrite kann aber noch mehr:
ALTER SESSION set query_rewrite_integrity='TRUSTED';
SELECT count(*) FROM demo;
---------------------------------------------------------
| Id | Operation | Name | Rows |
---------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 |
| 1 | SORT AGGREGATE | | 1 |
| 2 | MAT_VIEW REWRITE ACCESS FULL| DEMO_MV | 2 |
---------------------------------------------------------
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
3 consistent gets
0 physical reads
0 redo size
27. Constraints: Query Rewrite
Der Optimizer hat auch diese Abfrage umgeschrieben, da er über
folgende Sachverhalte informiert ist:
„typ“ ist der Primärschlüssel von „demo_typ“, d.h., jeder
Datensatz in „demo“ passt zu maximal einem Datensatz in
„demo_typ“.
„typ“ in der Tabelle „demo“ hat eine Fremdschlüsselbeziehung
zu „demo_typ“.
„typ“ in der Tabelle „demo“ ist NOT NULL. Gemeinsam mit dem
Fremdschlüssel bedeutet das: Es gibt nicht nur höchstens
sondern auch mindestens eine Entsprechung zu jedem
Datensatz von „demo“ in „demo_typ“. Im Umkehrschluss heißt
das, daß der COUNT in der Materialized View verwendet
werden kann, da durch den Join keine Datensätze aus „demo“
ausgelassen werden.
28. Constraint-Tuning: DEFERRABLE
Seit Oracle 8.0
Wird erst beim COMMIT geprüft
Dadurch Reihenfolge der Beladung von Tabellen
mit Fremdschlüsselbeziehungen unerheblich
Geschwindigkeitsvorteil bei Massenbeladungen
Bei Fehlern wird ROLLBACK ausgeführt
Zweistufiges Prinzip:
Wird mit deferrable initally [immediate | deferred] angelegt
In der Session: set constraint all deferred
29. Constraint-Tuning: DEFERRABLE
ALTER TABLE demo DROP CONSTRAINT demo_typ_cc;
ALTER TABLE demo DROP CONSTRAINT dem_demtyp_fk;
ALTER TABLE demo ADD
CONSTRAINT dem_demtyp_fk FOREIGN KEY ( typ ) REFERENCES demo_typ ( typ )
DEFERRABLE INITIALLY DEFERRED;
Das folgende UPDATE würde bei einem herkömmlichen Fremdschlüssel
fehlschlagen. Da es aber erst nach dem COMMIT geprüft wird, können die
Tabellen in beliebiger Reihenfolge geändert werden:
UPDATE demo SET typ = 'g' WHERE typ = 'a';
1 row updated.
UPDATE demo_typ SET typ = 'g' WHERE typ = 'a';
1 row updated.
COMMIT;
Commit complete.
30. Constraint-Tuning: DEFERRABLE
Achtung: Mit dem deferrable FK geht nun die Table Elimination
von oben nicht mehr:
SELECT name FROM demo NATURAL JOIN demo_typ;
---------------------------------------------
| Id | Operation | Name | Rows |
---------------------------------------------
| 0 | SELECT STATEMENT | | 2 |
| 1 | NESTED LOOPS | | 2 |
| 2 | TABLE ACCESS FULL| DEMO | 2 |
|* 3 | INDEX UNIQUE SCAN| TYP_PK | 1 |
---------------------------------------------
Außerdem: Wenn Deferrable Constraints vorliegen, können
Operationen auf den betroffenen Tabellen nicht parallelisiert
werden.
32. NVLst Du noch oder COALESCEt
Du schon?
Das gute, alte NVL()
Ist eine Oracle-spezifische Funktion
Vermutlich immer noch die beliebteste Methode
zum Vergleichen und Ersetzen von NULLs
Nachteile:
Kann nur genau einen Ausdruck mit einem anderen
ersetzen; muß ansonsten kaskadiert werden
Der zweite Ausdruck wird immer ausgewertet, auch
dann, wenn der erste Ausdruck bereits NOT NULL
ist.
33. NVL() vs. COALESCE()
Bsp.: Zur Aufbereitung der Tabelle “employees” sollen alle NULLs
durch die Zahl 0 ersetzt werden. Sollte es sich jedoch um einen
Verkäufer handeln, soll die standardmäßige Provision von 0,25 %
verwendet werden:
CREATE OR REPLACE FUNCTION get_comm( job_id IN employees.job_id%TYPE )
RETURN NUMBER AS
BEGIN
DBMS_OUTPUT.PUT_LINE( 'Aufruf get_comm()' );
RETURN DECODE( job_id, 'SA_REP', 0.25, 0 );
END;
/
SELECT employee_id
, NVL( commission_pct, get_comm( job_id )) comm
FROM employees;
Aufruf get_comm()
Aufruf get_comm()
Aufruf get_comm()
… (viel mehr Aufrufe als NULLs in der Tabelle sind)
34. COALESCE()
Gibt es seit Oracle 9i
ermöglicht die Auswertung von mehr als zwei
Ausdrücken; der erste, der NOT NULL ist, wird
zurückgeliefert.
„Short Circuit”:
Funktion wird beendet, sobald der erste Nicht-
NULL-Ausdruck gefunden wurde.
Entscheidender Geschwindigkeitsvorteil!
COALESCE ist ANSI-SQL-konform.
35. COALESCE()
Das Beispiel von oben in umgeschriebener Form:
SELECT employee_id
, COALESCE( commission_pct, get_comm( job_id )) comm
FROM employees;
Aufruf get_comm()
Aufruf get_comm()
(Nur so viele Aufrufe, wie NULLs in der Tabelle sind)
Ein vollständiger Umstieg von NVL auf COALESCE ist vielleicht
Geschmackssache, bringt aber auf jeden Fall keine Nachteile.
36. Materialisieren mit WITH
Seit Oracle 9i
Ideal für mehrfach verwendete Unterabfragen
Abfrage wird dann einmalig materialisiert und diese
Menge dann wiederverwendet
Aufwendige Scans und Joins werden daher auch
nur einmal statt mehrfach ausgeführt
Macht SQL-Code übersichtlicher
Spart außerdem noch Tipparbeit. :-)
37. Materialisieren mit WITH
Beispielszenario
Wir wollen aus einer Tabelle „depot_kunde“ Daten
anzeigen, und zwar gefiltert über zwei Listen in den
Tabellen „tmp_uid“ und „tmp_dep“.
Sind Schlüssel aus dem Datensatz in einer der
beiden Listen enhalten, soll der Datensatz
angezeigt werden.
Sind Schlüssel aus dem Datensatz in beiden Listen
enhalten, soll der Datensatz nicht angezeigt
werden.
38. Materialisieren mit WITH
Aufbau des Testszenarios:
CREATE TABLE depot_kunde
(
kunde_uid NUMBER NOT NULL
, depot_nr NUMBER NOT NULL
, CONSTRAINT depot_kunde_pk PRIMARY KEY ( kunde_uid, depot_nr )
);
CREATE TABLE tmp_uid
(
kunde_uid NUMBER NOT NULL
);
CREATE TABLE tmp_dep
(
depot_nr NUMBER NOT NULL
);
...
39. Materialisieren mit WITH
INSERT INTO depot_kunde VALUES( 1, 10 );
INSERT INTO depot_kunde VALUES( 2, 20 );
INSERT INTO depot_kunde VALUES( 3, 30 );
INSERT INTO tmp_dep VALUES( 10 );
INSERT INTO tmp_dep VALUES( 20 );
INSERT INTO tmp_uid VALUES( 2 );
INSERT INTO tmp_uid VALUES( 3 );
SET AUTOT TRACEONLY
Ein möglicher Lösungsansatz vor Oracle 9i:
SELECT *
FROM depot_kunde v
WHERE v.kunde_uid IN( SELECT a.kunde_uid
FROM depot_kunde a
LEFT OUTER JOIN tmp_uid b ON a.kunde_uid = b.kunde_uid
LEFT OUTER JOIN tmp_dep c ON a.depot_nr = c.depot_nr
WHERE b.kunde_uid IS NULL
OR c.depot_nr IS NULL )
OR v.depot_nr IN( SELECT a.depot_nr
FROM depot_kunde a
LEFT OUTER JOIN tmp_uid b ON a.kunde_uid = b.kunde_uid
LEFT OUTER JOIN tmp_dep c ON a.depot_nr = c.depot_nr
WHERE b.kunde_uid IS NULL
OR c.depot_nr IS NULL );
41. Materialisieren mit WITH
Mit der WITH-Clause kann das doppelt verwendete Subselect nun
ausgelagert und vorab materialisiert werden:
WITH sub AS
( SELECT a.kunde_uid
, a.depot_nr
FROM depot_kunde a
LEFT OUTER JOIN tmp_uid b ON a.kunde_uid = b.kunde_uid
LEFT OUTER JOIN tmp_dep c ON a.depot_nr = c.depot_nr
WHERE b.kunde_uid IS NULL
OR c.depot_nr IS NULL )
SELECT *
FROM depot_kunde v
WHERE v.kunde_uid IN( SELECT kunde_uid FROM sub )
OR v.depot_nr IN( SELECT depot_nr FROM sub );
42. Materialisieren mit WITH
----------------------------------------------------------------
| Id | Operation | Name |
----------------------------------------------------------------
| 0 | SELECT STATEMENT | |
| 1 | TEMP TABLE TRANSFORMATION | |
| 2 | LOAD AS SELECT | SYS_TEMP_0FD9D6651_27592C |
|* 3 | FILTER | |
|* 4 | HASH JOIN OUTER | |
|* 5 | HASH JOIN OUTER | |
| 6 | INDEX FAST FULL SCAN | DEPOT_KUNDE_PK |
| 7 | TABLE ACCESS FULL | TMP_UID |
| 8 | TABLE ACCESS FULL | TMP_DEP |
|* 9 | FILTER | |
| 10 | INDEX FAST FULL SCAN | DEPOT_KUNDE_PK |
|* 11 | VIEW | |
| 12 | TABLE ACCESS FULL | SYS_TEMP_0FD9D6651_27592C |
|* 13 | VIEW | |
| 14 | TABLE ACCESS FULL | SYS_TEMP_0FD9D6651_27592C |
----------------------------------------------------------------
Statistics
----------------------------------------------------------
2 recursive calls
8 db block gets
37 consistent gets
1 physical reads
600 redo size
43. Materialisieren mit WITH
Betrachten wir hier einmal auch die Prädikaten-Info näher:
Predicate Information (identified by operation id):
---------------------------------------------------
3 - filter("B"."KUNDE_UID" IS NULL OR "C"."DEPOT_NR" IS NULL)
4 - access("A"."DEPOT_NR"="C"."DEPOT_NR"(+))
5 - access("A"."KUNDE_UID"="B"."KUNDE_UID"(+))
9 - filter( EXISTS (SELECT 0 FROM (SELECT /*+ CACHE_TEMP_TABLE ("T1")
*/ "C0" "KUNDE_UID","C1" "DEPOT_NR" FROM
"SYS"."SYS_TEMP_0FD9D6651_27592C" "T1") "SUB" WHERE
"KUNDE_UID"=:B1) OR EXISTS (SELECT 0 FROM (SELECT /*+
CACHE_TEMP_TABLE ("T1") */ "C0"
"KUNDE_UID","C1" "DEPOT_NR" FROM
"SYS"."SYS_TEMP_0FD9D6651_27592C" "T1") "SUB" WHERE
"DEPOT_NR"=:B2))
11 - filter("KUNDE_UID"=:B1)
13 - filter("DEPOT_NR"=:B1)
44. Materialisieren mit WITH
Caveats
Nicht immer automatische Materialisierung, z.B.,
wenn WITH-Block nur einmal referenziert wird.
Aber auch bei weiteren Szenarien (und Bugs)
Hint /*+ MATERIALIZE */ innerhalb des WITH-
Blocks erzwingt Materialisierung.
Optimizer geht gelegentlich nicht mehr alle
Optimierungsansätze durch. Es kann dann
gegenüber dem ursprünglichen SQL zu längeren
Laufzeiten kommen.
→ Testen, testen und nochmals testen!
46. Oracle Old Features
Herzlichen Dank für Ihre Aufmerksamkeit!
Uwe M. Küchler, Valentia GmbH
oraculix.wordpress.com www.valentia.eu
Hinweis der Redaktion
Ist ein Check-C. Business-Logik oder nicht?
Bsp. 1: Ein Ja-Nein-Feld
Bsp. 2: häufig geänderte Wertelisten
Ist ein Check-C. Business-Logik oder nicht?
Bsp. 1: Ein Ja-Nein-Feld
Bsp. 2: häufig geänderte Wertelisten
Abfragen über Views: Wenn in den Views bereits ein Join wie im Bsp. verwendet wird.
Nur einer von vielen Fällen, in denen der Ausführungsplan noch nicht der Weisheit letzter Schluss ist.
EXPLAIN PLAN liegt oft falsch
AUTOTRACE EXPLAIN kann manchmal verwirren
Sicherheit nur mit Statistiken oder Trace
Übertragen Sie dieses Wissen von der Laborsituation auf sehr große Fakten- mit vielen, großen Dimensionstabellen, die womöglich mit leistungshungrigen Hash- oder Merge-Joins durchgeführt werden, dann können Sie sich das Potential von Constraints ausmalen!
Abfragen über Views: Wenn in den Views bereits ein Join wie im Bsp. verwendet wird.
Abfragen über Views: Wenn in den Views bereits ein Join wie im Bsp. verwendet wird.
Abfragen über Views: Wenn in den Views bereits ein Join wie im Bsp. verwendet wird.
Diese Constraints sind alle innerhalb von Millisekunden angelegt, auch wenn die Tabellen Milliarden von Rows enthalten würden. Die weiter oben demonstrierten Optimizer-Features wie Table Elimination oder Filterung über Check-Constraints können sofort genutzt werden. Noch einmal sei hier erwähnt, daß die Datenkonsistenz nun nicht mehr geprüft wird – im Falle inkonsistenter Daten können dann falsche Ergebnisse geliefert werden!
TODO: Erläuterung ”TRUSTED”
Obwohl der Count scheinbar nur für die Detail-Spalte in der MV angelegt wurde, kann er auch für andere Zählungen verwendet werden.
Überträgt man dieses Beispiel auf große Tabellen in einem DWH, dann sollte nun endgültig belegt sein, welches riesige Potential bei vergleichsweise geringen Kosten in Constraints steckt.
TODO: Erläuterung ”TRUSTED”
Obwohl der Count scheinbar nur für die Detail-Spalte in der MV angelegt wurde, kann er auch für andere Zählungen verwendet werden.
Das ist nur eine simple Funktion. Schon alleine der stetige Kontextwechsel zwischen SQL und PL/SQL kostet Zeit, aber wäre hier noch eine komplizierte Logik, kann man sich die Ressourcenverschwendung vorstellen.
Der Ausführungsplan zeigt, daß die Unterabfrage mit ihren Joins und Scans mehrfach ausgeführt wird.
Der Ausführungsplan zeigt nun, daß die Anweisung der With-Clause vorab in eine temporäre Tabelle hinein materialisiert wird. Anschließend greifen die Unterabfragen jeweils auf diese temporäre Tabelle zu.
Die Informationen über die Prädikate im Ausführungsplan zeigen übrigens noch eine Besonderheit: Das hier gezeigte Beispiel hätte sich auch gut mit der EXISTS- anstelle der IN-Klausel realisieren lassen. Der Optimizer hat dies erkannt und in Schritt 9 das SQL dementsprechend umgeschrieben.
Die Verringerung der Full Scans gegenüber dem ersten Beispielcode zeigt sich auch in den I/O-Statistiken