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….

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.

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.

Folgendes Beispiel soll die einfache Lösung aufzeigen:

SELECT a.id
     , a.parent_id
     , a.label
     , a.sort
  FROM menu_tree a
 ORDER BY 2 nulls first,1

(Abbildung 1: Unsortierte Basistabelle)

SELECT LEVEL
     , rpad(' ',LEVEL) || label
  FROM menu_tree a
 START WITH a.parent_id IS NULL
       CONNECT BY PRIOR a.id= a.parent_id
 ORDER siblings BY sort

(Abbildung 2: Sortiertes Ergebnis)

Here comes trouble…

Both environments (production and dev/test-system) connect to the same Oracle database. Inside the production environment all data received from the Oracle database is corrupt due to wrong encoding. A simple mb_detect_encoding shows ‘UTF8′ which cannot be. The whole web-application “is” utf-8. There is no implicit or explicit conversion of encodings performed. So the problem must be caused by the Oracle drivers themselves.

Fixme

setlocale did not work. The encoding option in the dsn (connection string) did not work. What did work was setting the NLS_LANG in the registry. The key can be found inside HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\{SomeInstance}. In this case the NLS_LANG was set to GERMAN_GERMANY.UTF8.

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

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

Oracle stellt die Dateien webutil_demo.zip und webutil_106.zip zum herrunterladen bereit. In diesen Dateien ist die Installation gut erklärt. Generell sollte aber immer geprüft werden, ob nicht bereits Dateien von webutil.jar / frmwebutil.jar oder jacob.dll in unterschiedlichen Verzeichnissen existieren.

JAR-Dateien
Generell sollten JAR-Dateien immer im Verzeichnis /forms/java liegen.

DLL-Dateien
Die Standard Einstellung für den Ort der DLL-Dateien lautet /forms/webutil. Es sind dies die Dateien jacob.dll, d2kwutil.dll und JNIsharedstubs.dll. Diese Dateien müssen auch auf dem Application-Server vorhanden sein. Diese Datei werden beim Starten der Java-Umgebung auf dem Client automatisch runtergeladen. Sollte dies nicht der Fall sein, muss der Inhalt der Datei webutil.cfg geprüft werden.

webutil.cfg
In der webutil.cfg sind folgende Einträge wichtig:

1.) Pfadangabe für die DLL-Dateien
install.syslib.location=/webutil

2.) Registrierung der DLL’s
install.syslib.0.7.1=jacob.dll|94208|1.0|true install.syslib.0.9.1=JNIsharedstubs.dll|65582|1.0|true install.syslib.0.9.2=d2kwut60.dll|192512|1.0|true

Die vorgegebenen Dateigrößen müssen mit den tatsächlichen Dateigrößen übereinstimmen.

Versionen
webutil / frmwebutil liegt in drei verschiedenen Versionen vor.

1.) Oracle Forms 10g (9.0.4) or Oracle9i Forms (9.0.2) –> webutil.jar
2.) Oracle Forms 10g (10.1.2.0) –> frmwebutil.jar (293 KB)
3.) Oracle Forms 10g (10.1.2.2) (Patch) –> frmwebutil.jar (272 KB)

jacob.dll darf ausschließlich in der Version 1.8 Verwendet werden. Alle neueren Versionen sind nicht kompatible.

Ab der Version Oracle Forms 10g (10.1.2.0) werden die Dateien für webutil (frmwebutil) bereits mitgeliefert. Diese Dateien sollten auch verwendet werden. Insbesondere dann, wenn Forms 10g gepatch worden ist. Nach dem Patch darf nur die frmwebutil.jar (273 KB)  der gepatchten Version verwendet werden. Andere Versionen frmwebutil.jar (293KB) laufen zum größten Teil nicht mehr. Leider werden auch keine Fehler protokolliert.

Vorgehensweise:
Die eigentliche Vorgehensweise wird bei Oracle und in diversen Foren ganz gut beschrieben. Zum signieren beider JAR-Dateien mit dem selben Zertifikat wird die Batchdatei sign_webutil.bat benötigt. Allerdings kann es passieren, das die Dateien auf einen Fehler laufen und die Datei .keystore kann nicht erzeugt werden. In der Regel liegt es daran, dass die Systemvariable HOME auf DOS-Ebene nicht gesetzt ist. In der Systemvariablen HOME sollte der Pfad für das Homeverzeichnis des Users stehen.