entwicklungsgedanken » Datenbank

WITH-Klausel

clausbajor — Thu, 15 Apr 2010 09:52:00 +0000

In der Praxis trifft man von Zeit zu Zeit auf aufgeblaehte SQL-Queries, die ausserordentlich kostenintensiven und langwierigen Ausfuehrungsplaenen folgen.
Zeigt eine weitergehende Analyse, dass die komplexe Abfrage eine oder mehrere Subqueries enthaelt, die mehrfach ausgefuehrt werden, dann besteht eine sehr
gute Chance durch Verwendung der sogenannten WITH-Klausel, die Performance der Abfrageausfuehrung erheblich zu steigern.

Im Kern wird die schnellere Ausfuehrung der Query dadurch realisiert, dass mittels der WITH-Klausel die Ergebnismenge der Subquery vorab materialisiert, mit einem Namen versehen und schliesslich in der Hauptquery abgegriffen wird.
Hier lohnt sich auch ein Vergleich und Gebrauch von "global temporary tables", die in Ihrer Funktions- und Wirkungsweise durchaus ähnlich sind:
Durch Entkopplung geeigneter Subqueries, die urspruenglich als Bestandteile einer komplexen Abfrage fungierten, wird dieses SQL-Statement vereinfacht.

WITH   SQ1 AS (SELECT...FROM...WHERE...),
       SQ2 AS (SELECT...FROM...WHERE...)
SELECT...
  FROM Q1, SQ1, SQ2 WHERE…

Interessanter Nebeneffekt:

Durch die Verwendung der WITH-Klausel wird anscheinend in einer Systemumgebung mit voreingestelltem CURSOR_SHARING=FORCE offensichtlich fuer die Query-Ausfuehrung diese systemweit gueltige Einstellung auf CURSOR_SHARING=EXACT zurueckgenommen (vergleichbar dem Einsatz des Hint /*+ cursor_sharing_exact */).

Zeigen die QEPs vorher noch eine allgemeine Ersetzung von Konstanten durch Parameter, so weisen die QEPs nachher die direkte Verwendung der Konstanten auf.

Somit orientiert sich der Optimizer auch grundsaetzlich an anderen Zugriffsstrategien.

Was in einer Umgebung mit problematischem Parseverhalten per Bindvariablen-Peeking einen "flüssigen" Anwendungsbetrieb ermöglichen kann, wird im Einzelfall einer komplexen Query unter Verwendung von Attributen mit stark ungleicher Werteverteilung zu relativ kostenintensiven QEPs führen.

Es empfiehlt sich dann für alle entsprechenden Konstanten/Parameter einen separaten und speziellen QEP zu erzwingen.

Vorraussetzung:

SQL-99 Standard bzw. Oracle9i Release 2

Links:

SQLStandards.html

to be continued….

MIN, MAX innerhalb eines SELECT-Statement

Sven Thämar — Mon, 05 Apr 2010 08:01:00 +0000

Manchmal benötigten man sowohl den kleinsten (min) als auch den größten (max) Wert einer indizierten Spalte gleichzeitig.

SELECT MIN(id)
     , MAX(id)
  FROM big_table

Bei diesem SELECT kommt zwar das richtige Ergebnis, dennoch kann die Antwortzeit sehr lange dauern. Der Grund liegt in einem FAST FULL INDEX SCAN.

Besser ist folgendes:

SELECT MIN(id) min_value
  FROM big_table
 UNION ALL
SELECT MAX(id) max_value
  FROM big_table

oder

SELECT (SELECT MIN(id) from big_table) min_value
      ,(SELECT MAX(id) from big_table) max_value
  FROM dual

Bei beiden alternativen wird ein FULL INDEX SCAN durchgeführt und liefert das Ergebnis (fast) sofort zurück.
Den Umweg sollte man bei großen Tabellen und wo es auf Geschwindigkeit ankommt wählen.

Blockierende SQL-Session

Sven Thämar — Mon, 05 Apr 2010 07:59:00 +0000

Folgendes SQL-Statement kann man verwenden wenn man prüfen möchte ob es blockierende Sitzungen gibt.

SELECT
     , b.username blocking_username
     , b.osuser blocking_osuser
     , b.machine blocking_machine
     , b.program blocking_program
     , w.sid waiting_sid
     , w.username waiting_username
     , w.osuser waiting_osuser
     , w.machine waiting_machine
     , w.seconds_in_wait
  FROM v$SESSION w
     , v$SESSION b
 WHERE w.blocking_session is not NULL
   AND b.sid = w.blocking_session
 ORDER BY w.sid

Das Statement kann jederzeit um weitere Spalten erweitert werden.

Before-Insert/Update Trigger (Performance)

Sven Thämar — Fri, 27 Mar 2009 11:22:39 +0000

Bei der Verwendung von Before-Insert / Update Triggern sollte man bezüglich performance immer prüfen ob eine Wertzuweisung erfolgen muss oder ob der Wert bereits vorhanden ist. Z.b. bei den Feldern create_on bzw. create_by ist eine Zuweisung nur Sinnvoll, wenn die Werte wirklich NULL sind. Ansonsten ist der Performanceverlust bei einer permanenten Zuweisung sehr hoch.

check constraint vs. trigger

Sven Thämar — Fri, 27 Mar 2009 10:15:34 +0000

Steht bei der Verarbeitung die Geschwindigkeit im Vordergrund, sollte man generell auf die Verwendung von Triggern auf Row-Level Ebene verzichten. Sofern dies möglich ist. Hier ist die Verwendung von check constraints auf alle Fälle vorzuziehen. Wird hingegen von vornherein ein Trigger (Before-Insert / Update) verwendet, kann die Prüfung im Trigger selber erfolgen. Wird ein Trigger verwendet sollte man die zusätzlich Prüfung via check constraint nicht verwendet.

Komplette Ausarbeitung: QT-check-constraint-vs-trigger

Oracle 10g Enterprise Manager: Voraussetzung zur Definition der HOST-ID

Tom Haesevoets — Wed, 03 Dec 2008 09:50:22 +0000

Bei der Definition des Benutzernamens und des Passworts zum Host muss unter Windows der Host-User folgende Berechtigung besitzen:

"Anmelden als Stapelverarbeitungsauftrag"

Ist dies nicht der Fall bekommt man folgende Fehlermeldung:

"RemoteOperationException: ERROR: wrong password for user"

Einstellen der Berechtigung:

- Öffnen: Programme > Systemsteuerung > Verwaltung > "Lokale Sicherheitsrichtlinien"

- Unter "Lokale Richtlinien" > "Zuweisen von Benutzerrechten" der Host-User unter "Anmelden als Stapelverarbeitungsauftrag" eintragen.