Performance-Problem mit Oracle

Guten Morgen

Wie im Titel schon erwähnt, habe ich hier ein Performance-Problem mit Oracle.

Ausgangslage
Eine Oracle Datenbank (10g) und C+±Clients, die per OCI darauf zugreifen. Das ganze läuft unter Red Hat Enterprise Linux ES4 und ist eine verteilte und replizierte Applikation. Der Datenzugriff erfolgt per Views. Damit das Lesen und das Schreiben von Daten per Views möglich ist, werden INSTEAD OF TRIGGER (INSERT; UPDATE; DELETE) eingesetzt.

Problem
Der Datenzugriff erfolgt bei einem bestimmten View, beim aller ersten Mal, sehr langsam. Das heisst, wurden Daten neue geschrieben erfolgt der erste Zugriff auf dieselben sehr langsam. Jede nachfolgende Abfrage ist annehmbar schnell. Dieser Vorgang wiederholt sich jeweils beim Neustart eines C+±Clients für denselben.
Derselbe Effekt kann bei dem Konsolentool sqlplus und dem DB-Manager-Tool Tora beobachtet werden.

Beschreibung des Views
Was den langsamen View von anderen unterscheidet, ist die Anzahl Joins (Inner und Outer/Left Joins). Der View basiert auf einer Tabelle, die einen Zusammenzug von Fremdschlüsseln abbildet. Diese Tabelle verweisst achtmal, per CONSTRAINT, auf eine hierarchisch übergeordnete Tabelle. Kurz gesagt, der View soll eine Matrix von Abhängigkeiten darstellen; wer gehört zu wem (SQL Source, siehe unten).

Tuning versuche
Folgendes habe ich bereits versucht:

  • Zusätzliche Indexes (CREATE UNIQUE INDEX)
  • MERGE JOIN /*+ USE_MERGE ( t1, t2 ) */
  • NESTED LOOPS /*+ INDEX (t) */
  • HASH JOIN /*+ USE_HASH (t) */

Die bringen auch eine Verbesserung, aber leider nur ab dem zweiten Datenzugriff.

Was muss ich tun, um den ersten Datenzugriff schneller zu machen?

Vielen Dank für die Hilfe
Olli

CREATE OR REPLACE VIEW 
( )
AS
SELECT FROM 
(
 table\_8 T8
-- join 0 ---------------------------------------------------
 JOIN table\_7 T7
 ON T7.pk = T8.fk0\_t7 -- FK0 T7 (PK)
 JOIN table\_6 T6
 ON T6.pk = T7.fk\_t6 
 LEFT JOIN table\_5 T5
 ON T5.pk = T6.fk\_t5 
 JOIN table\_4 T4
 ON T4.pk = T5.fk\_t4 
 JOIN table\_3 T4
 ON T3.pk = T4.fk\_t3 
-- join 1 ---------------------------------------------------
 LEFT JOIN table\_7 T7\_1
 ON T7\_1.px = T8.fk1\_t7 -- FK1 T7
 LEFT JOIN table\_6 T6\_1
 ON T6\_1.pk = T7\_1.fk\_t6 
 LEFT JOIN table\_5 T5\_1
 ON T5\_1.pk = T6\_1.fk\_t5 
 LEFT JOIN table\_4 T4\_1
 ON TT4\_1.pk = T5\_1.fk\_t4 
 LEFT JOIN table\_3 T3\_1
 ON T3\_1.pk = T4\_1.fk\_t3 
-- join 2 ---------------------------------------------------
 LEFT JOIN table\_7 T7\_2
 ON T7\_2.pk = T8.fk2\_t7 -- FK2 T7
 LEFT JOIN table\_6 T6\_2
 ON T6\_2.pk = T7\_2.fk\_t6 
 LEFT JOIN table\_5 T5\_2
 ON T5\_2.pk = T6\_2.fk\_t5 
 LEFT JOIN table\_4 T4\_2
 ON T4\_2.pk = T5\_2.fk\_t4 
 LEFT JOIN table\_3 T3\_2
 ON T3\_2.pk = T4\_2.fk\_t3 
-- join 3 ---------------------------------------------------
 LEFT JOIN table\_7 T7\_3
 ON T7\_3.pk = T8.fk3\_t7 -- FK3 T7
 LEFT JOIN table\_6 T6\_3
 ON T6\_3.pk = T7\_3.fk\_t6 
 LEFT JOIN table\_5 T5\_3
 ON T5\_3.pk = T6\_3.fk\_t5 
 LEFT JOIN table\_4 T4\_3
 ON T4\_3.pk = T5\_3.fk\_t4 
 LEFT JOIN table\_3 T3\_3
 ON T3\_3.pk = T4\_3.fk\_t3 
-- join 4 ---------------------------------------------------
 LEFT JOIN table\_7 T7\_4
 ON T7\_4.pk = T8.fk4\_t7 -- FK4 T7
 LEFT JOIN table\_6 T6\_4
 ON T6\_4.pk = T7\_4.fk\_t6 
 LEFT JOIN table\_5 T5\_4
 ON T5\_4.pk = T6\_4.fk\_t5 
 LEFT JOIN table\_4 T4\_4
 ON T4\_4.pk = T5\_4.fk\_t4 
 LEFT JOIN table\_3 T3\_4
 ON T3\_4.pk = T4\_4.fk\_t3 
-- join 5 ---------------------------------------------------
 LEFT JOIN table\_7 T7\_5
 ON T7\_5.pk = T8.fk5\_t7 -- FK5 T7
 LEFT JOIN table\_6 T6\_5
 ON T6\_5.pk = T7\_5.fk\_t6 
 LEFT JOIN table\_5 T5\_5
 ON T5\_5.pk = T6\_5.fk\_t5 
 LEFT JOIN table\_4 T4\_5
 ON T4\_5.pk = T5\_5.fk\_t4 
 LEFT JOIN table\_3 T3\_5
 ON T3\_5.pk = T4\_5.fk\_t3 
-- join 6 ---------------------------------------------------
 LEFT JOIN table\_7 T7\_6
 ON T7\_6.pk = T8.fk6\_t7 -- FK6 T7
 LEFT JOIN table\_6 T6\_6
 ON T6\_6.pk = T7\_6.fk\_t6 
 LEFT JOIN table\_5 T5\_6
 ON T5\_6.pk = T6\_6.fk\_t5 
 LEFT JOIN table\_4 T4\_6
 ON T4\_6.pk = T5\_6.fk\_t4 
 LEFT JOIN table\_3 T3\_6
 ON T3\_6.pk = T4\_6.fk\_t3 
-- join 7 ---------------------------------------------------
 LEFT JOIN table\_7 T7\_7
 ON T7\_7.pk = T8.fk7\_t7 -- FK6 T7
 LEFT JOIN table\_6 T6\_7
 ON T6\_7.pk = T7\_7.fk\_t6 
 LEFT JOIN table\_5 T5\_7
 ON T5\_7.pk = T6\_7.fk\_t5 
 LEFT JOIN table\_4 T4\_7
 ON T4\_7.pk = T5\_7.fk\_t4 
 LEFT JOIN table\_3 T3\_7
 ON T3\_7.pk = T4\_7.fk\_t3 
);

Hi,

würde evtl. ein materialized view gehen ?
mit fast refresh on commit…

Grüße

Chris

Hallo,

der Join ist für jede Datenbank tödlich.

Da er beim ersten MAl sehr lange dauert und dann halbwegs schnell geht, vermute ich mal, dass der Buffer-Speicher zu klein ist. Auf der Admin-Oberfläche sollte es ein Tool geben, um dessen Idealgröße zu finden. Ansonsten gehts ganz einfach zu Fuß per TKPROF und die IOs reduzieren.
Dann solltest du den Quatsch mit den Hints in den Selects lassen. Das taugt nichts. Lass lieber mal ein Analyze Table über die DB laufen. Das ist besser.
Den Select kannst du mit EXPLAIN PLAN genauer anschauen und dann siehst du auch den Ausführungsplan. Da siehst du dann auch, welche Zugriffe Indizes benötigen.

Gruß

Peter

Hi,
die Idee mit den Matview klingt vielversprechend.

Wenn das Problem wie du schreibst beim ersten select auftritt, habe ich zwei Vermutungen, wo deine Performance hingeht:

a) Die Daten werden beim ersten Select erst in den Buffer-Cache geladen und die physikalischen Zugriffe kosten nun mal Zeit.

b) Beim ersten Select werden noch unsaubere Blöcke weggeschrieben. (Ich bekomme das genaue Scenario nicht mehr auf die Reihe, wann so was geschah)

Beides müsstest du in den Griff bekommen, wenn du ein entsprechendes Select Statement einfach automatisch nach dem laden einmal ausführst.

Ansonsten bleibt die Frage, ob sich das Statement als solches tunen läßt. Dafür bräuchte man aber:

  • Komplette Tabellenstruktur, inklusive sämtlicher Indizes.
  • Das komplette select statement (insbesondere auch welche Spalten selektiert werden)
  • Aktuelle Statistiken auf den Tabellen
  • Die Ausgabe von Autotrace oder TKPROF
  • Eine Aussage, ob die dort angegebenene Cardinalitäten die Wirklichkeit angemessen wiederspiegeln, bzw. in welcher Weise sie davon abweichen.

Wenn ich davon ausgehe, dass du alle oder sehr viele der vorhandenen Spalten auch ausgibst, bringen Indizes recht wenig, bis gar nichts, da nirgends die Datenmenge eingeschränkt wird. Dementsprechen sind Nested_loop-Joins vermutlich auch eher suboptimal.

Jens

Hallo

Erst mal vielen Dank für wertvollen Tipps.

Das mit den Hints habe ich aus dem Buch „ORACLE DATABASE 19g, Die umfassende Referenz“. Ich bin kein Oracle-Spezialist und habe zuvor mehr mit MS SQL und MySQL zu tun gehabt, deshalb habe ich es einfach mal ausprobiert. Die Hints werde ich natürlich weglassen, wenn sie nichts taugen.

EXPLAIN PLAN, TKPROF und MATERILIZED VIEWS werde ich mal ausprobieren. Braucht vermutlich etwas Zeit, ich melde mich aber wieder.

Grüsse
Olli

Hi Olli,
das Hints nichts taugen ist so nicht richtig.

Oracle versucht über den Cost Based Optimizer den günstigsten Zugriffspfad zu wählen. Damit das eine Chance auf Erfolg hat braucht man aktuelle Statistiken. Aber selbst wenn die da sind, kann Oracle sich verschätzen.

Ein Klassiker sind z.B. Like Bedingungen, da kann die Datenbank meist keine Aussage darüber treffen, wieviele Datensätze die Bedingung erfüllen und nimmt daher irgendeinen Default Prozentsatz. Wenn der daneben liegt macht sie einen Indexzugriff, obwohl ein Full Table Scan schneller wäre oder andersrum, oder oder oder.

Daher das generelle Vorgehen bei Oracle:

  • erst sicherstellen, dass die Statistiken angemessen aktuell sind (Was immer das im Einzelfall heisst)
  • und erst dann, wenn nötig über Hints geziehlt den Ausführungsplan manipulieren

Jens

PS: Such auch mal auf asktom.oracle.com suchen (englisch)
Jens

Hi!

Da er beim ersten MAl sehr lange dauert und dann halbwegs
schnell geht, vermute ich mal, dass der Buffer-Speicher zu
klein ist.

Oder aber, das die Daten mitsamt Execution-Plan noch immer im Cache sind …

Ansonsten gehts ganz einfach
zu Fuß per TKPROF und die IOs reduzieren.

Ich würde ein Tool bevorzugen (TOAD oder OraSpeed - zweiteres gibt es als Testversion einen Monat kostenlos)

Dann solltest du den Quatsch mit den Hints in den Selects
lassen. Das taugt nichts.

Das wäre mir komplett neu - auch wenn die 10er bereits außerordentlich Parsed, so lautet meine Erfahrung aus den letzten drei Jahren mit 10er Datenbanken: Hints, Hints, Hints, … auch wenn nachts die Statistiken aufgebaut wurden, spätestens am Nachmittag sind diese auf den Transaktionstabellen veraltet und Oracle parsed sich einen Wolf …

Den Select kannst du mit EXPLAIN PLAN genauer anschauen und
dann siehst du auch den Ausführungsplan. Da siehst du dann
auch, welche Zugriffe Indizes benötigen.

Und welche Optimizer Hints man verwenden soll (ORDERED, FIRST_ROWS, INDEX, …)

Grüße,
Tomh

Hi
Was sind denn das für Datenbanken, bei denen Statistiken innerhalb eines halben Tages unbrauchbar werden?

Jens

Hi

Was sind denn das für Datenbanken, bei denen Statistiken
innerhalb eines halben Tages unbrauchbar werden?

Oracle-Datenbanken …

Tabellen, bei denen zu Mittag 90% der Sätze des Vormittags gelöscht sind und es den restlichen Tag es so weitergeht …

Tabellen, bei denen stündlich ein paar zehntausend Sätze per Batch kommen und gehen …

Oder bei denen ein Nachtbatch eine Spur zu spät begann und somit nur unbrauchbare Stastistiken existieren (passiert mir wöchentlich 2-3 Mal mit einem Datawarehouse-Job)

Im Normallfall sind die Statistiken aktuell, aber hie und da gibt’s halt - teilweise ständige - „Ausreißer“ …

Grüße,
Tomh

Hallo Tomh,

aber das kann doch die 10g jetzt alles. Da kann man das Statistiksammeln im Hintergrund entsprechend einstellen.

Gruß

Peter

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

Hi!

aber das kann doch die 10g jetzt alles. Da kann man das
Statistiksammeln im Hintergrund entsprechend einstellen.

Sie „könnte“ es - allerdings _darf_ ich derzeit als „Nur-Entwickler“ nur Vorschläge machen, da die DBA’s der Meinung sind, daß die 10er genauso wie die 8er definiert sein muß, weil so hat unter der 8er alles halbwegs funktioniert :frowning:

Grüße,
Tomh

Das problem an sich erinnert mich
and den Thread SQL-Group-By fragen,
etwas weiter unten.
Es ist ja nicht klar, wieviele
Begegnungen es gibt, bei dir
werden max 7 unterstellt.
Vieleicht gibts es in Oracle
auch so ein cross/table/query
construct.
So’n Join (gerade outer)
über 7 Tabllen dauert eben.
Ich nehm mal an, dass der Optimizer
sich entschieden hat,
eirstmal zu sortieren,
aufgrund fehlender/ungeeigneter indizes,
und er honoriert auch nicht, dass
die Joins selbstreflexiv sind.
Deslab dauerts auch so lande beim
ersten mal, danach die Versuche
kommen wohl aus dem Cache.

Da bin ich wieder
Hallo

Okay, „EXPLAIN PLAN“ und „tkprof“, das musste ich nachlesen und habe
es gemäss folgenden links ausgeführt:

Was ich jetzt mit den Daten tun soll weiss ich nicht so recht. Was
auffällig ist, ist die Tatsache, dass „Parse cpu“ und „Parse elapsed“
beim ersten Datenzugriff höher sind als beim zweiten Datenzugriff
(siehe unten).

Ein „Select“ nach jedem Einfügen habe ich versucht. Dadurch wird das
Problem in meinem Fall nur verschoben, aber nicht wirklich gelöst.

MATERIALIZED VIEW machen in mienem Fall auch nicht wirklich Sinn. Da
der Problem-View auf eine Tabelle zugreift die am Ende der
(Klassen)-Hierarchie ist, kann ich auch gleich eine normale Tabelle
verweden. Ist designtechnisch gesehen nicht super schön, funktioniert
aber sehr viel schneller. Na ja, manchmal muss man eben Kompromisse
eingehen. Oder seht ihr das nicht auch so?

Grüsse
Olli

Erster Datenzugriff
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 1.23 1.39 0 74 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.07 0.07 0 202 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 3 1.30 1.46 0 276 0 0


Zweiter Datenzugriff
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.06 0.06 0 202 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 3 0.06 0.07 0 202 0 0


EXPLAIN PLAN (\*.csv)
"#";"STATEMENT\_ID";"TIMESTAMP";"REMARKS";"OPERATION";"OPTIONS";"OBJECT\_NODE";"OBJECT\_OWNER";"OBJECT\_NAME";"OBJECT\_INSTANCE";"OBJECT\_TYPE";"OPTIMIZER";"SEARCH\_COLUMNS";"ID";"PARENT\_ID";"POSITION";"COST";"CARDINALITY";"BYTES";"OTHER\_TAG";"PARTITION\_START";"PARTITION\_STOP";"PARTITION\_ID";"OTHER";"DISTRIBUTION"
"1";"{null}";"2007-02-12 06:31:11";"{null}";"SELECT STATEMENT";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"ALL\_ROWS";"{null}";"0";"{null}";"80";"80";"202500";"397710000";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"2";"{null}";"2007-02-12 06:31:11";"{null}";"HASH JOIN";"RIGHT OUTER";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"1";"0";"1";"80";"202500";"397710000";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"3";"{null}";"2007-02-12 06:31:11";"{null}";"TABLE ACCESS";"FULL";"{null}";"APP";"TABLE\_3";"40";"TABLE";"{null}";"{null}";"2";"1";"1";"3";"8";"272";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"4";"{null}";"2007-02-12 06:31:11";"{null}";"HASH JOIN";"RIGHT OUTER";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"3";"1";"2";"74";"202500";"390825000";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"5";"{null}";"2007-02-12 06:31:11";"{null}";"TABLE ACCESS";"FULL";"{null}";"APP";"TABLE\_2";"38";"TABLE";"{null}";"{null}";"4";"3";"1";"3";"5";"330";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"6";"{null}";"2007-02-12 06:31:11";"{null}";"HASH JOIN";"RIGHT OUTER";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"5";"3";"2";"67";"202500";"377460000";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"7";"{null}";"2007-02-12 06:31:11";"{null}";"TABLE ACCESS";"FULL";"{null}";"APP";"TABLE\_5";"36";"TABLE";"{null}";"{null}";"6";"5";"1";"3";"34";"5066";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"8";"{null}";"2007-02-12 06:31:11";"{null}";"HASH JOIN";"RIGHT OUTER";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"7";"5";"2";"61";"202500";"347287500";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"9";"{null}";"2007-02-12 06:31:11";"{null}";"TABLE ACCESS";"FULL";"{null}";"APP";"TABLE\_4";"34";"TABLE";"{null}";"{null}";"8";"7";"1";"3";"15";"1575";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"10";"{null}";"2007-02-12 06:31:11";"{null}";"HASH JOIN";"RIGHT OUTER";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"9";"7";"2";"54";"13500";"21735000";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"11";"{null}";"2007-02-12 06:31:11";"{null}";"TABLE ACCESS";"FULL";"{null}";"APP";"TABLE\_3";"30";"TABLE";"{null}";"{null}";"10";"9";"1";"3";"8";"272";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"12";"{null}";"2007-02-12 06:31:11";"{null}";"HASH JOIN";"RIGHT OUTER";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"11";"9";"2";"51";"13500";"21276000";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"13";"{null}";"2007-02-12 06:31:11";"{null}";"TABLE ACCESS";"FULL";"{null}";"APP";"TABLE\_2";"28";"TABLE";"{null}";"{null}";"12";"11";"1";"3";"5";"330";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"14";"{null}";"2007-02-12 06:31:11";"{null}";"HASH JOIN";"RIGHT OUTER";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"13";"11";"2";"47";"13500";"20385000";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"15";"{null}";"2007-02-12 06:31:11";"{null}";"TABLE ACCESS";"FULL";"{null}";"APP";"TABLE\_5";"26";"TABLE";"{null}";"{null}";"14";"13";"1";"3";"34";"5066";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"16";"{null}";"2007-02-12 06:31:11";"{null}";"HASH JOIN";"RIGHT OUTER";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"15";"13";"2";"43";"13500";"18373500";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"17";"{null}";"2007-02-12 06:31:11";"{null}";"TABLE ACCESS";"FULL";"{null}";"APP";"TABLE\_4";"24";"TABLE";"{null}";"{null}";"16";"15";"1";"3";"15";"1575";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"18";"{null}";"2007-02-12 06:31:11";"{null}";"HASH JOIN";"RIGHT OUTER";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"17";"15";"2";"40";"900";"1130400";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"19";"{null}";"2007-02-12 06:31:11";"{null}";"TABLE ACCESS";"FULL";"{null}";"APP";"TABLE\_3";"20";"TABLE";"{null}";"{null}";"18";"17";"1";"3";"8";"272";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"20";"{null}";"2007-02-12 06:31:11";"{null}";"HASH JOIN";"RIGHT OUTER";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"19";"17";"2";"36";"900";"1099800";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"21";"{null}";"2007-02-12 06:31:11";"{null}";"TABLE ACCESS";"FULL";"{null}";"APP";"TABLE\_2";"18";"TABLE";"{null}";"{null}";"20";"19";"1";"3";"5";"330";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"22";"{null}";"2007-02-12 06:31:11";"{null}";"HASH JOIN";"RIGHT OUTER";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"21";"19";"2";"33";"900";"1040400";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"23";"{null}";"2007-02-12 06:31:11";"{null}";"TABLE ACCESS";"FULL";"{null}";"APP";"TABLE\_5";"16";"TABLE";"{null}";"{null}";"22";"21";"1";"3";"34";"5066";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"24";"{null}";"2007-02-12 06:31:11";"{null}";"HASH JOIN";"RIGHT OUTER";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"23";"21";"2";"29";"900";"906300";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"25";"{null}";"2007-02-12 06:31:11";"{null}";"TABLE ACCESS";"FULL";"{null}";"APP";"TABLE\_4";"14";"TABLE";"{null}";"{null}";"24";"23";"1";"3";"15";"1575";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"26";"{null}";"2007-02-12 06:31:11";"{null}";"HASH JOIN";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"25";"23";"2";"26";"60";"54120";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"27";"{null}";"2007-02-12 06:31:11";"{null}";"TABLE ACCESS";"FULL";"{null}";"APP";"TABLE\_1";"42";"TABLE";"{null}";"{null}";"26";"25";"1";"3";"2";"152";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"28";"{null}";"2007-02-12 06:31:11";"{null}";"HASH JOIN";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"27";"25";"2";"22";"60";"49560";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"29";"{null}";"2007-02-12 06:31:11";"{null}";"TABLE ACCESS";"FULL";"{null}";"APP";"TABLE\_3";"10";"TABLE";"{null}";"{null}";"28";"27";"1";"3";"8";"272";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"30";"{null}";"2007-02-12 06:31:11";"{null}";"HASH JOIN";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"29";"27";"2";"19";"60";"47520";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"31";"{null}";"2007-02-12 06:31:11";"{null}";"TABLE ACCESS";"FULL";"{null}";"APP";"TABLE\_2";"8";"TABLE";"{null}";"{null}";"30";"29";"1";"3";"5";"465";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"32";"{null}";"2007-02-12 06:31:11";"{null}";"HASH JOIN";"RIGHT OUTER";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"31";"29";"2";"15";"60";"41940";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"33";"{null}";"2007-02-12 06:31:11";"{null}";"TABLE ACCESS";"FULL";"{null}";"APP";"TABLE\_5";"6";"TABLE";"{null}";"{null}";"32";"31";"1";"3";"34";"5066";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"34";"{null}";"2007-02-12 06:31:11";"{null}";"HASH JOIN";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"33";"31";"2";"12";"60";"33000";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"35";"{null}";"2007-02-12 06:31:11";"{null}";"NESTED LOOPS";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"34";"33";"1";"8";"4";"1780";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"36";"{null}";"2007-02-12 06:31:11";"{null}";"NESTED LOOPS";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"35";"34";"1";"8";"4";"1672";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"37";"{null}";"2007-02-12 06:31:11";"{null}";"NESTED LOOPS";"OUTER";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"36";"35";"1";"7";"1";"351";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"38";"{null}";"2007-02-12 06:31:11";"{null}";"NESTED LOOPS";"OUTER";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"37";"36";"1";"6";"1";"297";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"39";"{null}";"2007-02-12 06:31:11";"{null}";"NESTED LOOPS";"OUTER";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"38";"37";"1";"5";"1";"243";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"40";"{null}";"2007-02-12 06:31:11";"{null}";"NESTED LOOPS";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"39";"38";"1";"4";"1";"189";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"41";"{null}";"2007-02-12 06:31:11";"{null}";"TABLE ACCESS";"FULL";"{null}";"APP";"TABLE\_8\_1";"1";"TABLE";"{null}";"{null}";"40";"39";"1";"3";"1";"108";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"42";"{null}";"2007-02-12 06:31:11";"{null}";"TABLE ACCESS";"BY INDEX ROWID";"{null}";"APP";"TABLE\_7";"2";"TABLE";"{null}";"{null}";"41";"39";"2";"1";"1";"81";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"43";"{null}";"2007-02-12 06:31:11";"{null}";"INDEX";"UNIQUE SCAN";"{null}";"APP";"TABLE\_7\_PK";"{null}";"INDEX (UNIQUE)";"{null}";"1";"42";"41";"1";"0";"1";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"44";"{null}";"2007-02-12 06:31:11";"{null}";"TABLE ACCESS";"BY INDEX ROWID";"{null}";"APP";"TABLE\_7";"12";"TABLE";"{null}";"{null}";"43";"38";"2";"1";"1";"54";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"45";"{null}";"2007-02-12 06:31:11";"{null}";"INDEX";"UNIQUE SCAN";"{null}";"APP";"TABLE\_7\_PK";"{null}";"INDEX (UNIQUE)";"{null}";"1";"44";"43";"1";"0";"1";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"46";"{null}";"2007-02-12 06:31:11";"{null}";"TABLE ACCESS";"BY INDEX ROWID";"{null}";"APP";"TABLE\_7";"22";"TABLE";"{null}";"{null}";"45";"37";"2";"1";"1";"54";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"47";"{null}";"2007-02-12 06:31:11";"{null}";"INDEX";"UNIQUE SCAN";"{null}";"APP";"TABLE\_7\_PK";"{null}";"INDEX (UNIQUE)";"{null}";"1";"46";"45";"1";"0";"1";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"48";"{null}";"2007-02-12 06:31:11";"{null}";"TABLE ACCESS";"BY INDEX ROWID";"{null}";"APP";"TABLE\_7";"32";"TABLE";"{null}";"{null}";"47";"36";"2";"1";"1";"54";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"49";"{null}";"2007-02-12 06:31:11";"{null}";"INDEX";"UNIQUE SCAN";"{null}";"APP";"TABLE\_7\_PK";"{null}";"INDEX (UNIQUE)";"{null}";"1";"48";"47";"1";"0";"1";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"50";"{null}";"2007-02-12 06:31:11";"{null}";"TABLE ACCESS";"BY INDEX ROWID";"{null}";"APP";"TABLE\_2\_0";"44";"TABLE";"{null}";"{null}";"49";"35";"2";"1";"4";"268";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"51";"{null}";"2007-02-12 06:31:11";"{null}";"INDEX";"UNIQUE SCAN";"{null}";"APP";"TABLE\_2\_0\_PK";"{null}";"INDEX (UNIQUE)";"{null}";"1";"50";"49";"1";"0";"1";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"52";"{null}";"2007-02-12 06:31:11";"{null}";"INDEX";"UNIQUE SCAN";"{null}";"APP";"TABLE\_2\_2\_PK";"{null}";"INDEX (UNIQUE)";"{null}";"1";"51";"34";"2";"0";"1";"27";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"
"53";"{null}";"2007-02-12 06:31:11";"{null}";"TABLE ACCESS";"FULL";"{null}";"APP";"TABLE\_4";"4";"TABLE";"{null}";"{null}";"52";"33";"2";"3";"15";"1575";"{null}";"{null}";"{null}";"{null}";"{null}";"{null}"

Sie „könnte“ es - allerdings _darf_ ich derzeit als
„Nur-Entwickler“ nur Vorschläge machen, da die DBA’s der
Meinung sind, daß die 10er genauso wie die 8er definiert sein
muß, weil so hat unter der 8er alles halbwegs funktioniert :frowning:

Grüße,
Tomh

  • Werde dies DBA’s so schnell wie möglich los. Wenn ich meine Job so machen würde, wäre ich schon lange nicht mehr im Geschäft.

Hi

Was ich jetzt mit den Daten tun soll weiss ich nicht so recht.
Was
auffällig ist, ist die Tatsache, dass „Parse cpu“ und „Parse
elapsed“
beim ersten Datenzugriff höher sind als beim zweiten
Datenzugriff
(siehe unten).

Das ist so auch zu erwarten, da Oracle ein neues Statement erstmal ‚hard parsen‘ muss, unter anderem wird dabei der Ausführungsplan erstellt und das ganze wird gecachet, so dass dann folgende Abfragen nur noch ein ‚soft parse‘ benötigen und schneller sind.

In deinem Fall braucht er für das parsen ne gute Sekunde und für die Ausführung dann 0.07 Sekunden.

Für mich bleiben da zwei Fragen: Eine gute Sekunde klingt nicht nach dem Performanceproblem, das du ursprüngliche beschrieben hast. Wo ist denn die restliche Zeit hin?

Warum parst die Maschine neu, wenn sich ‚nur‘ die Daten verändert haben. Wird da mit Create Table as Select gearbeitet, oder sonst irgend etwas gemacht, dass den Ausführungsplan ungültig machen könnte?

Den Ausführungsplan hab ich so nicht wirklich entziffern können.

  • Ein wenig mißtrauisch machen mich die Nested Loops. Prüf da mal ob die angegebenen Kardinalitäten mit den realen Werten übereinstimmen.
    Aber wenn das Problem wirklich beim Parsen liegt, wird der Ausführungsplan schon halbwegs in Ordnung sein.

Jens