Upgrade Albtraum. Lothar Flatz Senior Principal Consultant Dr. Markus Eberling Managing Consultant. Diso AG Der Schweizer Daten- und Cloud-Experte

Transkript

1 Upgrade Albtraum Lothar Flatz Senior Principal Consultant Dr. Markus Eberling Managing Consultant

2 Ich stelle mich vor... Wer bin ich?» Über 25 Jahre Oracle Database Erfahrung (beginnend mit Version 5)» 15 Jahre Oracle Mitarbeiter» Oak Table Mitglied» Ex-Real World Performance Group» Oracle ACE» Signatur Project: PVSS (CERN)» Patent US B2 zusammen mit Björn Engsig 2

3 Über die Diso AG» Gründung 1996, 36 Mitarbeiter» Sitz in Gümligen (Bern), Schweiz» Portfolio: Cloud-Computing Entwicklung IT-Beratung Managed Services Projektumsetzung Systemoptimierung 3

4 Der Vorstellung Dr. Markus Eberling Studium der Information von in Paderborn Wissenschaftlicher Mitarbeiter an der Uni Paderborn von im Fachbereich Wissensbasierte System Promotion in 2011 Seit 10/2011 Mitarbeiter der S&N AG; Managing Consultant und Head of Software Design & Engineering der Region West Copyright 2015 S&N Invent GmbH All rights reserved. 4

5 Der S&N Invent GmbH 2014 Gründung der S&N Invent als Joint Venture und Shared Service Gesellschaft der S&N AG und der A:gon Solutions GmbH. 350 Mitarbeiterinnen und Mitarbeiter, davon 230 fest angestellt und zusätzlich ca. 120 externe Consultants. 38 Millionen Euro Gesamtumsatz in 2015, davon ca. 70% in der Finanz- und Versicherungswirtschaft. 7 Standorte in Deutschland, damit sind wir stets kundennah und flexibel. 3 Strategische Säulen: Consulting, Lösungen, Services für die umfassende Betreuung im IT-Lifecycle Copyright 2015 S&N Invent GmbH All rights reserved. 5

6 Der Ausgangsposition: Zunahme von Laufzeiten Mit leichter zeitlicher Verzögerung sind die Laufzeiten dramatisch gestiegen Mehrere Batchprogramme betroffen Analysen wurden durchgeführt, ohne nennenswerte Informationen an den Tag zu bringen Copyright 2015 S&N Invent GmbH All rights reserved. 6

9 Einsatz Übersicht» Der Einsatz dauerte insgesamt 45 Arbeitstage» Er begann Mitte September 2016 und endete im Mai 2017» In der ersten Phase bis Anfang Dezember 2016 ging es vor allem darum, den Grund der Laufzeitverschlechterung zu finden» Dies war besonders wichtig, weil der Monatslauf November (im Gegensatz zu den Monaten vorher) Mitten in der Woche stattfand» Diese Präsentation berichtet von der ersten Phase 9

10 Interpretation AWR - Top Statements» Zum Glück gab es die Baselines der Monatsend batches noch» Mittels Abfragen auf die DBA Hist Tabellen konnten die Läufe vor und nach dem Upgrade verglichen werden» Der letzte Lauf vor dem Upgrade war das Monatsende April» Es wurde ein batch herausgegriffen, der sich besonders signifikant verändert hatte 11

11 Vergleich Logical Reads per Second Monatsende Monatsende Hour April Oktober , , , , , , , , , , , , ,79 Total , ,68 Buffergets: der Aktivitätsmassstab , , , , ,00 0, Monthend October Monthend April 13

12 Vergleich auf Statement Ebene Monthend April Monthend October Elapsed Sec Cpu Sec IO Wait Sec Calls Buffer gets Rows Processed Elapsed Sec Cpu Sec IO Wait Sec Calls Buffer gets Rows Processed aa1wwcxa13qc aa1wwcxa13qc bvcyz9w9cvavn bvcyz9w9cvavn chkm477ptzq1p chkm477ptzq1p da3vznaf3w3hd d7hwd0qqgp38a d7hwd0qqgp38a d9c3jx56j3hmy d9c3jx56j3hmy fdwv58w0yk8yh fdwv58w0yk8yh gmmbma98kx70n gmmbma98kx70n g3s17jqd9an2b g3s17jqd9an2b aamr6fwhnnxa aamr6fwhnnxa ra4u4ak1uc jfrynu4mp6x jfrynu4mp6x ua1yfy7tutg ua1yfy7tutg d4mh2rktwpk d4mh2rktwpk cdrmkf6up03v cdrmkf6up03v c888t8cgqy c888t8cgqy j9b2js4fzh j9b2js4fzh h874urqj2mff jza15j jza15j xf7q750j4st xf7q750j4st vj504f580c vj504f580c vy4k5t73a x330rjpw6wf Total Seconds Total Hours 1,36 0,78 0,58 2,03 0,73 1,29 15

13 Vergleich auf Statement Ebene» Wir sehen eindeutig eine Verschlechterung der Pläne mit Version 12» Die Laufzeiten der Top Statements addieren sich aber nicht annähernd auf die Gesamtlaufzeit des Batches -> In diesem Bild fehlt etwas» Um auch das feinste Detail zu untersuchen haben wir auf der Abnahmeumgebung einen Lauf getraced 16

14 Auswertung des Traces auf der Abnahme Overall runtime: select toid from type$ where package_obj#=:1 order by typ_name ; select count(*) from type$ where package_obj#=:1 8388,28 Seconds 4861,87 Seconds 2044,58 Seconds» Die Laufzeit dominiert von rekursiven Statements» Der Lauf war schnell, nicht unbedingt repräsentativ» dennoch: die rekursiven Statements müssen jetzt angegangen werden 17

15 Woher kommen die rekursiven Statements? rekursiv, aber es fehlt der Parentcursor 18

16 Event V8 Bundled Exec Call» Dank an Stefan Köhler, für den Hinweis es mit Event zu versuchen» Jetzt wird der Parent cursor sichtbar» Die Antwort: Es war gar kein SQL oder PL/SQL 19

17 V8 Bundled Exec Call in ASH» Oracle Program Interface (OPI) calls.» for each OCI call in the client side (like, OCIStmtExecute, OCIStmtFetch, etc) there s a corresponding server side OPI function (like opiexe(), opifch2() etc). 20

18 Erzeugt vom Framework» Anscheinend werden die Aufrufe über das Framework Rouge Wave erzeugt, welches OCI describe aufruft» Mit Version 12c werden bei describe auch die genannten rekursiven Statements erzeugt 21

19 Zwei Statements SQL_ID 7avz6006nq0yj SELECT toid FROM type$ WHERE package_obj#=:1 ORDER BY typ_name ; SQL_ID 9zstv91ddy78q SELECT COUNT(*) FROM type$ WHERE package_obj#=:1;» Index Skip Scan (trotz unique Spalte am Anfang), 2/3 der Zeit» Full Index scan, 1/3 der Zeit Kein passender Index INDEX "sys"."i_type6" ON "sys"."type$ ("toid","version#", "package_obj#" ); 22

20 Bestehender Bug» Der Kunde fragte den richtigen Index nach» Oracle Support s Vorschlag: Erweiterung des bestehenden Indexes um eine Spalte vor» Tests ergaben, dass es danach schneller lief (??)» Development übernahm den Vorschlag von Support ohne Überprüfung an (as you already tested it) 23

21 Kontakt mit Oracle Support» Anhand des Testcases konnte die Situation endlich geklärt werden» Ein Testcase kann die Kommunikation schon sehr vereinfachen und bringt eine neue Qualität» Hardnäckigkeit hilft» Eskalation nicht scheuen» Support entgegen kommen (Arbeitsüberlastung, Zeitdruck, Leistungsziele) -> Dank an Mike Dietrich» Für mich eine positive Überraschung 24

25 Der Erster Versuch der Problemlösung Anhand des ausgeführten Statements wurde auf die Filterund Zugriffsprädikate geschaut. Auffällig: RAWTOHEX(NLSSORT("TAB_A_C1" TO_CHAR("TAB_A_C2"),'nls_sort=''GERMAN'''))>= :B3 AND RAWTOHEX(NLSSORT("TAB_A_C1" TO_CHAR("TAB_A_C2"),'nls_sort=''GERMAN'''))<= :B Copyright 2015 S&N Invent GmbH All rights reserved. 28

26 Der Mögliche Lösungen Virtuelle Spalte Belegt keinen Speicherplatz; Berechnung zur Laufzeit Spalte ist grundsätzlich im Dictionary vorhanden und setzt saubere Programmierung voraus Hidden column (Function-based Index ) Hidden column belegt Speicherplatz Spalte muss explizit benannt werden in Selektionen Expression Statistik Statement umschreiben Ggfs. nicht möglich bei Fremdsoftware Durchlaufzeit der Umsetzung zu lange Copyright 2015 S&N Invent GmbH All rights reserved. 29

27 Der Entscheidung: virtuelle Spalte alter table TABLE_A add ( V_COL_A generated always as (RAWTOHEX(NLSSORT("TAB_A_C1" TO_CHAR("TAB_A_C2"), 'NLS_SORT = GERMAN' )) ) virtual ); Copyright 2015 S&N Invent GmbH All rights reserved. 30

28 Der Schätzung kritischer Zugriff Schritt 1 select count(*) from TABLE_A A where ((:B5 IS NULL OR "A"."TAB_A_C3"=:B5) AND "A"."TAB_A_C4" ' '='OK ' AND "A"."TAB_A_C5"=:B6 AND RAWTOHEX(NLSSORT("TAB_A_C1" TO_CHAR("TAB_A_C2"),'nls_sort=''GERMAN'''))>=:B3 AND RAWTOHEX(NLSSORT("TAB_A_C1" TO_CHAR("TAB_A_C2"),'nls_sort=''GERMAN'''))<=:B2) / Id Operation Name Starts E-Rows A-Rows A-Time Buffers SELECT STATEMENT :00: SORT AGGREGATE :00: * 2 FILTER 1 247K 00:00: * 3 TABLE ACCESS FULL TABLE_A K 00:00: Predicate Information (identified by operation id): filter(:b2>=:b3) 3 - filter(((:b5 IS NULL OR "A"."TAB_A_C3"=:B5) AND "A"."TAB_A_C4" ' '='OK ' AND "A"."TAB_A_C5"=:B6 AND RAWTOHEX(NLSSORT("TAB_A_C1" TO_CHAR("TAB_A_C2"),'nls _sort=''german'''))>=:b3 AND RAWTOHEX(NLSSORT("TAB_A_C1" TO_CHAR("TAB_A_C2"), 'nls_sort=''german'''))<=:b2)) Copyright 2015 S&N Invent GmbH All rights reserved. 31

29 Der Alter Null-Transformation Trick select count(*) from TABLE_A A where ((:B5 IS NULL OR "A"."TAB_A_C3"=:B5) AND "A"."TAB_A_C4" ' '='OK ' AND "A"."TAB_A_C5"=:B6 AND RAWTOHEX(NLSSORT("TAB_A_C1" TO_CHAR("TAB_A_C2"),'nls_sort=''GERMAN'''))>=:B3 AND RAWTOHEX(NLSSORT("TAB_A_C1" TO_CHAR("TAB_A_C2"),'nls_sort=''GERMAN'''))<=:B2) Sollte vermieden und umgeschrieben werden: select count(*) from TABLE_A A where ((:B5 IS NULL OR "A"."TAB_A_C3"=:B5) AND "A"."TAB_A_C4"='OK' AND "A"."TAB_A_C5"=:B6 AND RAWTOHEX(NLSSORT("TAB_A_C1" TO_CHAR("TAB_A_C2"),'nls_sort=''GERMAN'''))>=:B3 AND RAWTOHEX(NLSSORT("TAB_A_C1" TO_CHAR("TAB_A_C2"),'nls_sort=''GERMAN'''))<=:B2) Copyright 2015 S&N Invent GmbH All rights reserved. 32

30 Der Schätzung kritischer Zugriff Schritt 2 select count(*) from TABLE_A where ((:B5 IS NULL OR "A"."TAB_A_C3"=:B5) AND "A"."TAB_A_C4"='OK' AND "A"."TAB_A_C5"=:B6 AND RAWTOHEX(NLSSORT("TAB_A_C1" TO_CHAR("TAB_A_C2"),'nls_sort=''GERMAN'''))>=:B3 AND RAWTOHEX(NLSSORT("TAB_A_C1" TO_CHAR("TAB_A_C2"),'nls_sort=''GERMAN'''))<=:B2) / Id Operation Name Starts E-Rows A-Rows A-Time Buffers SELECT STATEMENT :00: SORT AGGREGATE :00: * 2 FILTER 1 247K 00:00: * 3 TABLE ACCESS FULL TABLE_A K 00:00: Predicate Information (identified by operation id): filter(:b2>=:b3) 3 - filter(((:b5 IS NULL OR "A"."TAB_A_C3"=:B5) AND "A"."TAB_A_C4"='OK' AND "A"."TAB_A_C5"=:B6 AND RAWTOHEX(NLSSORT("TAB_A_C1" TO_CHAR("TAB_A_C2"),'nls_sort= ''GERMAN'''))>=:B3 AND RAWTOHEX(NLSSORT("TAB_A_C1" TO_CHAR("TAB_A_C2"),'nls_sort Copyright 2015 S&N Invent GmbH All rights reserved. 33

31 Der Mutter aller SQL-Antipatterns select count(*) from TABLE_A A where ((:B5 IS NULL OR "A"."TAB_A_C3"=:B5) AND "A"."TAB_A_C4"='OK' AND "A"."TAB_A_C5"=:B6 AND RAWTOHEX(NLSSORT("TAB_A_C1" TO_CHAR("TAB_A_C2"),'nls_sort=''GERMAN'''))>=:B3 AND RAWTOHEX(NLSSORT("TAB_A_C1" TO_CHAR("TAB_A_C2"),'nls_sort=''GERMAN'''))<=:B2) Im vorliegenden Fall ist :B5 immer null Kondition entfernen Copyright 2015 S&N Invent GmbH All rights reserved. 34

32 Der Mutter aller SQL-Antipatterns Man versucht ein Problem zu lösen durch einen Trick und macht es noch schlimmer Typische Formen: (:B5 IS NULL OR "A"."TAB_A_C3"=:B5) "A"."TAB_A_C3" = nvl(:b5, "A"."TAB_A_C3") Ausführungsplan zerfällt in zwei Teile und macht es dem Optimizer schwer eine korrekte Schätzung zu liefern Ausführungszeit verlängert sich dramatisch Beide Formen sollten vermieden werden und durch konditionale Programmierung ersetzt werden Weitere Informationen finden sich in einem Artikel von Iggy Fernandez: Copyright 2015 S&N Invent GmbH All rights reserved. 35

33 Der Schätzung kritischer Zugriff Schritt 3 select count(*) from TABLE_A A where ( "A"."TAB_A_C4"='OK' AND "A"."TAB_A_C5"=:B6 AND RAWTOHEX(NLSSORT("TAB_A_C1" TO_CHAR("TAB_A_C2"),'nls_sort=''GERMAN'''))>=:B3 AND RAWTOHEX(NLSSORT("TAB_A_C1" TO_CHAR("TAB_A_C2"),'nls_sort=''GERMAN'''))<=:B2) / Id Operation Name Starts E-Rows A-Rows A-Time Buffers SELECT STATEMENT :00: SORT AGGREGATE :00: * 2 FILTER 1 247K 00:00: * 3 TABLE ACCESS FULL TABLE_A 1 247K 247K 00:00: Predicate Information (identified by operation id): filter(:b2>=:b3) 3 - filter(("a"."tab_a_c4"='ok' AND "A"."TAB_A_C5"=:B6 AND RAWTOHEX(NLSSORT("TAB_A_C1" TO_CHAR("TAB_A_C2"),'nls_sort=''GERMAN'''))>=:B3 AND RAWTOHEX(NLSSORT("TAB_A_C1" TO_CHAR("TAB_A_C2"),'nls_sort=''GERMAN'''))<=:B2 )) Copyright 2015 S&N Invent GmbH All rights reserved. 36

34 Der Aber: es ist immer noch etwas im Argen Id Operation Name Starts E-Rows A-Rows A-Time Buffers Reads SELECT STATEMENT :09: M SORT ORDER BY :09: M UNION-ALL 1 182K 00:09: M * 3 FILTER :00: K NESTED LOOPS OUTER :00: K * 5 HASH JOIN OUTER :00: K * 6 HASH JOIN :00: K NESTED LOOPS :01: K NESTED LOOPS M 00:01: K * 9 HASH JOIN K 00:01: K MERGE JOIN K 00:01: K * 11 TABLE ACCESS BY INDEX ROWID TABLE_B K 00:01: K * 12 INDEX FULL SCAN IX_TABLE_B_ K 00:00: K 2093 * 13 SORT JOIN 289K K 00:00: VIEW index$_join$_ :00: * 15 HASH JOIN :00: INDEX FAST FULL SCAN IX_TABLE_C_ :00: INDEX FAST FULL SCAN IX_TABLE_C_ :00: * 18 TABLE ACCESS FULL TABLE_A 1 247K 247K 00:00: * 19 INDEX RANGE SCAN IX_TABLE_D 289K 1 10M 00:00: K 0 * 20 TABLE ACCESS BY INDEX ROWID TABLE_D 10M :00: K 0 21 TABLE ACCESS FULL TABLE_F 1 981K 981K 00:00: TABLE ACCESS FULL TABLE_G 1 222K 222K 00:00: TABLE ACCESS BY INDEX ROWID TABLE_E :00: K 1881 * 24 INDEX UNIQUE SCAN IX_TABLE_E :00: K Copyright 2015 S&N Invent GmbH All rights reserved. 37

36 Der Funktion in der where-clause FUNCTION F_USED_IN_STATEMENT( ninput1 IN TABLE_H.TAB_H_C1%TYPE, sinput2 IN TABLE_H.TAB_H_C2%TYPE ) RETURN NUMBER IS BEGIN DECLARE nok NUMBER; BEGIN SELECT COUNT(*) INTO nok FROM TABLE_H WHERE TAB_H_C1 = ninput1 AND TAB_H_C2 = sinput2; IF nok > 1 THEN nok := 1; END IF; RETURN nok; END; END F_USED_IN_STATEMENT; Copyright 2015 S&N Invent GmbH All rights reserved. 39

38 Der Finaler Ausführungsplan Id Operation Name Starts E-Rows A-Rows A-Time Buffers Reads SELECT STATEMENT :06: M SORT ORDER BY :06: M UNION-ALL 1 182K 00:06: M 4820 * 3 FILTER :00: K NESTED LOOPS OUTER :00: K 4820 * 5 HASH JOIN OUTER :00: K 4820 * 6 HASH JOIN :00: K NESTED LOOPS :00: K NESTED LOOPS M 00:00: K 4820 * 9 HASH JOIN K 00:00: * 10 HASH JOIN RIGHT ANTI K 00:00: * 11 INDEX SKIP SCAN IX_TABLE_H :00: * 12 HASH JOIN 1 413K 448K 00:00: VIEW index$_join$_ :00: * 14 HASH JOIN :00: INDEX FAST FULL SCAN IX_TABLE_C_ :00: INDEX FAST FULL SCAN IX_TABLE_C_ :00: * 17 TABLE ACCESS FULL TABLE_B 1 472K 448K 00:00: * 18 TABLE ACCESS FULL TABLE_A 1 247K 247K 00:00: * 19 INDEX RANGE SCAN IX1_TABLE_D 289K 1 10M 00:00: K 0 * 20 TABLE ACCESS BY INDEX ROWID TABLE_D 10M :00: K 0 21 TABLE ACCESS FULL TABLE_F 1 981K 981K 00:00: TABLE ACCESS FULL TABLE_G 1 222K 222K 00:00: TABLE ACCESS BY INDEX ROWID TABLE_E :00: K 0 * 24 INDEX UNIQUE SCAN IX_TABLE_E :00: K Copyright 2015 S&N Invent GmbH All rights reserved. 41

39 Zwischenfazit» Es muss eine Planänderung gegeben haben» Warum sieht man dann kein einzelnes Statement, dass sehr viel langsamer geworden ist?» Wenn kurz laufende Statements langsamer geworden sind, müssen es viele gewesen sein» Warum verändern viele kurz laufende Statements gleichzeitig den Execution Plan? 42

40 Überblick Laufzeit Testen mit Trace bis Wir haben Glück, es kommen zwei ungleich schnelle Läufe: Lauf Start: 09:51:21 End : 12:11:20 Laufzeit : 2:18 Datenbankzeit: 5060 seconds = 1:14 Lauf Start: 10:57:00 End : 17:02:16 Laufzeit: 6:05 Datenbankzeit : seconds = 5:12 Differenz 3:58 Minuten, warum? 43

41 Wo ist der Unterschied? Zwei Hilfstabellen, für den und für den Beide traces in die Datenbank importieren Vergleichen und nach Differenz sortieren SELECT T2511.EXE_QUERY, T2311.EXE_QUERY, T2511.EXE_QUERY- T2311.EXE_QUERY difference, T2511.SQL_TEXT FROM TKPROF_TABLE_2511 T2511, TKPROF_TABLE_2311 T2311 WHERE T2511.SQL_TEXT=T2311.SQL_TEXT ORDER BY difference DESC; 45

42 Unterschiede EXE_QUERY EXE_QUERY_1 DIFFERENCE SQL_TEXT SELECT TB2.TB2TAUXCALC FROM TABLE2 TB2 WHERE TB2.ID = :B1 AND TB2.TB2COL1 = (SELECT MAX(TB2COL1) FROM TABLE2 WHERE ID = :B1 AND TB3ID IN (SELECT TB3.TB3ID FROM TABLE3 TB3, TABLE4 TB4 WHERE TB3.TB3CODE = TB4.TB4CODE AND TB4.TUSNOM = 'GROUPE')) SELECT TO_DATE(SUBSTR(TB1COL,INSTR(TB1COL,'- b')+2,8),'yyyymmdd') FROM TABLE1 WHERE TB1ID = (SELECT MIN(TB1ID) FROM TABLE5 WHERE ID = ) SELECT TO_DATE(SUBSTR(TB1COL,INSTR(TB1COL,'- b')+2,8),'yyyymmdd') FROM TABLE1 WHERE TB1ID = (SELECT MIN(TB1ID) FROM TABLE5 WHERE ID = ) SELECT TO_DATE(SUBSTR(TB1COL,INSTR(TB1COL,'- b')+2,8),'yyyymmdd') FROM TABLE1 WHERE TB1ID = (SELECT MIN(TB1ID) FROM TABLE5 WHERE ID = )

43 Statement 1 SELECT TB2.TB2TAUXCALC FROM TABLE2 TB2 WHERE TB2.ID = :B1 AND TB2.TB2COL1 = (SELECT MAX(TB3COL1) FROM TABLE3 WHERE ID = :B1 AND TB4ID IN (SELECT TB4.TB4ID FROM TABLE4 TB4, TABLE5 TB5 WHERE TB4.TB4CODE = TB5.TB5CODE AND TB5.TB5COL2 = 'GROUPE')) call count cpu elapsed disk query current rows Parse Execute Fetch total Kann man tunen, bringt maximal 30 Sekunden -> vergessen wir s 47

44 Statement 2 SELECT TO_DATE(SUBSTR(TB1COL, INSTR(TB1COL,'-b')+2,8),'YYYYMMDD') FROM Table1 WHERE TB1ID = (SELECT MIN(TB1ID) FROM Table5 WHERE ID = ) Potentiel viele Statements Unterschiedliche Sql Id durch Literal 48

45 Laufzeit? SELECT TO_CHAR(A1.FORCE_MATCHING_SIGNATURE), COUNT(a1.sample_time) * 10 AS sec FROM dba_hist_active_sess_history a1 WHERE a1.sample_time BETWEEN to_date('11/25/16 10:57:00','MM.DD.YY HH24:MI:SS') AND to_date('11/25/16 17:02:16','MM.DD.YY HH24:MI:SS') AND program LIKE 'batchxxx%' AND sql_id is not null GROUP BY A1.FORCE_MATCHING_SIGNATURE ORDER BY sec DESC; TO_CHAR(A1.FORCE_MATCHING_SIGNATURE) SEC FORCE_MATCHING_SIGNATURE = cursor_sharing simuliert Sekunden sind 3 Stunden 51 Minuten Q.E.D. 49

46 Gegenprobe SQL> select sql_text from v$sql where FORCE_MATCHING_SIGNATURE= ; SQL_TEXT SELECT TO_DATE(SUBSTR(TB1COL,INSTR(TB1COL,'-b')+2,8),'YYYYMMDD') FROM Table1 WHERE TB1ID = (SELECT MIN(TB1ID) FROM Table5 WHERE ID = ) SELECT TO_DATE(SUBSTR(TB1COL,INSTR(TB1COL,'-b')+2,8),'YYYYMMDD') FROM Table1 WHERE TB1ID = (SELECT MIN(TB1ID) FROM Table5 WHERE ID = ) SELECT TO_DATE(SUBSTR(TB1COL,INSTR(TB1COL,'-b')+2,8),'YYYYMMDD') FROM Table1 WHERE TB1ID = (SELECT MIN(TB1ID) FROM Table5 WHERE ID = ) SELECT TO_DATE(SUBSTR(TB1COL,INSTR(TB1COL,'-b')+2,8),'YYYYMMDD') FROM Table1 WHERE TB1ID = (SELECT MIN(TB1ID) FROM Table5 WHERE ID = ) SELECT TO_DATE(SUBSTR(TB1COL,INSTR(TB1COL,'-b')+2,8),'YYYYMMDD') FROM Table1 WHERE TB1ID = (SELECT MIN(TB1ID) FROM Table5 WHERE ID = ) SELECT TO_DATE(SUBSTR(TB1COL,INSTR(TB1COL,'-b')+2,8),'YYYYMMDD') FROM Table1 WHERE TB1ID = (SELECT MIN(TB1ID) FROM Table5 WHERE ID = ) SELECT TO_DATE(SUBSTR(TB1COL,INSTR(TB1COL,'-b')+2,8),'YYYYMMDD') FROM Table1 WHERE TB1ID = (SELECT MIN(TB1ID) FROM Table5 WHERE ID = ) SELECT TO_DATE(SUBSTR(TB1COL,INSTR(TB1COL,'-b')+2,8),'YYYYMMDD') FROM Table1 WHERE TB1ID = (SELECT MIN(TB1ID) FROM Table5 WHERE ID = ) SELECT TO_DATE(SUBSTR(TB1COL,INSTR(TB1COL,'-b')+2,8),'YYYYMMDD') FROM Table1 WHERE TB1ID = (SELECT MIN(TB1ID) FROM Table5 WHERE ID = ) SELECT TO_DATE(SUBSTR(TB1COL,INSTR(TB1COL,'-b')+2,8),'YYYYMMDD') FROM Table1 WHERE TB1ID = (SELECT MIN(TB1ID) FROM Table5 WHERE ID = ) 50

47 Planwechsel Guter Plan Id Operation Name Rows Bytes Cost (%CPU) Time SELECT STATEMENT 2 (100) 1 TABLE ACCESS BY INDEX ROWID Table (0) 00:00:01 * 2 INDEX UNIQUE SCAN PK_Table1 1 1 (0) 00:00:01 3 SORT AGGREGATE TABLE ACCESS BY INDEX ROWID BATCHED Table (0) 00:00:01 * 5 INDEX RANGE SCAN FK_Table (0) 00:00: Predicate Information (identified by operation id): access("tb1id"=) 5 - access("id"=262914) Schlechter Plan Id Operation Name Rows Bytes Cost (%CPU) Time SELECT STATEMENT 2 (100) 1 TABLE ACCESS BY INDEX ROWID Table (0) 00:00:01 * 2 INDEX UNIQUE SCAN PK_Table1 1 1 (0) 00:00:01 3 SORT AGGREGATE FIRST ROW (8) 00:00:01 * 5 INDEX FULL SCAN (MIN/MAX) PK_Table (8) 00:00: Predicate Information (identified by operation id): access("tb1id"=) 5 - filter("id"=262914) 51

48 Lösung Der beste Index wäre: INDEX FK_Table52 ON Table5 (ID, TB1ID) Das ergibt Id Operation Name Rows Bytes Cost (%CPU) Time SELECT STATEMENT 2 (100) 1 TABLE ACCESS BY INDEX ROWID Table (0) 00:00:01 * 2 INDEX UNIQUE SCAN PK_Table1 1 1 (0) 00:00:01 3 SORT AGGREGATE FIRST ROW (0) 00:00:01 * 5 INDEX RANGE SCAN (MIN/MAX) FK_Table (0) 00:00: Massgeschneiderter Index Index wird sofort automatisch verwendet Kosten sind gesunken -> Plan stabil 52

49 Ergebnis» Zwei Tage vor dem entscheidenden Monatslauf konnte das Hauptproblem beseitigt werden» Die Laufzeiten waren grosso modo wieder auf Version 11 Niveau 53

51 Zusammenfassung Lassen Sie sich keine Märchen erzählen: Glauben Sie gemessene und überprüfbaren Fakten 55

52 Vielen Dank für Ihre Aufmerksamkeit! Für Rückfragen stehen wir Ihnen gerne zur Verfügung. Lothar Flatz Diso AG Morgenstrasse Gümligen Tel.: info@diso.ch 56

53 Kontakt Vielen Dank für Ihre Aufmerksamkeit! Dr. Markus Eberling Managing Consultant Head of Software Design and Engineering Telefon S&N Invent GmbH (zusätzlich Agon/S&N) Klingenderstraße Paderborn Copyright 2016 S&N Invent GmbH All rights reserved. 57