Johannes Ahrends Geschäftsführer CarajanDB GmbH

Größe: px

Ab Seite anzeigen:

Download "Johannes Ahrends Geschäftsführer CarajanDB GmbH"

Monika Kruse
vor 5 Jahren
Abrufe

1 Johannes Ahrends Geschäftsführer CarajanDB GmbH

2 Vorstellung CarajanDB Ein Beispiel aus der Praxis und wer ist schuld? Index oder nicht Index das ist doch keine Frage, oder? Was kann der DBA tun? Was kann der Entwickler tun? 2

3 Experten mit über 30 Jahren Oracle Erfahrung Spezialisten für Backup & Recovery Hochverfügbarkeit Healthchecks Performance Optimierung Einsatz von Oracle Standard Edition Oracle in virtuellen Umgebungen und in der Cloud Oracle Migrationen (HW, Unicode, Konsolidierung, Standard Edition) Monitoring (Grid / Cloud Control, HLMM, Foglight, Spotlight) Schulung und Workshops (Oracle, Toad) 3

4 4

5 Forrester Research: Root of Database Performance Impact 90% Tuningpotential durch Optimierung einzelner Befehle 10% durch Anpassung der Hardware, OS und Datenbank! 30 % 60 % 6

6 7 Was fällt auf?

7 jawin11. db_cache_size= jawin11. java_pool_size= jawin11. large_pool_size= jawin11. pga_aggregate_target= jawin11. sga_target= jawin11. shared_io_pool_size=0 jawin11. shared_pool_size= jawin11. streams_pool_size=0 *.memory_target=4g 8

8 Mindestens setzen: db_cache_size shared_pool_size Shared Pool kann im laufendenden Betrieb kaum freigegeben werden ALTER SYSTEM FLUSH SHARED_POOL 9

9 10

10 Ist dieser Index sinnvoll? CREATE INDEX idx_name ON personen (anrede, vorname, nachname); Abfrage 1: SELECT anrede, vorname, nachname FROM tuk.personen pe WHERE pe.nachname LIKE 'Wei_' AND pe.vorname = 'Martin' AND pe.anrede = 'Herr'; 1_select_index.sql 11

11 12

12 Abfrage 2: SELECT anrede, vorname, nachname FROM tuk.personen pe WHERE pe.nachname LIKE 'Wei_' AND pe.vorname = 'Martin' -- AND pe.anrede = 'Herr'; 13

13 14

14 SQL> SELECT anrede, vorname, nachname 2 FROM tuk.personen pe 3 WHERE pe.nachname LIKE 'wei_' 4 AND pe.vorname LIKE 'Martin'; ANRED VORNAME NACHNAME Herr Martin Weiß Herr Martin Weis Herr Martin Weiz 3 Zeilen ausgewählt. 2_abfrage_ls.bat 15

15 16 Warum Full-Table-Scan?

16 17

17 Versuch einer Analyse: SQL> SELECT anrede, vorname, nachname 2 FROM tuk.personen pe 3 WHERE pe.nachname LIKE 'wei_' 4 AND pe.vorname LIKE 'Martin'; ANRED VORNAME NACHNAME Herr Martin Weiß Herr Martin Weis Herr Martin Weiz 3 Zeilen ausgewählt. 18

18 19 ALTER SESSION SET nls_sort=binary_ci; Sortierung ist unabhängig von Groß- / Kleinschreibung aber abhängig von Akzenten Alternativen: binary_ai Case und Akzent insensitiv german_ai Deutsche Sortierung, Case und Akzent insensitiv ALTER SESSION SET nls_comp=linguistic; Filter verwenden die gleiche Funktion wie NLS_SORT, d.h. in diesem Fall ist die WHERE-Clausel unabhängig von Groß- / Kleinschreibung und von Akzenten Alternativen: BINARY oder ANSI

19 Entweder Linguistische Suche ausschalten oder Index auf Linguistische Suche CREATE INDEX idx_name2 ON personen (NLSSORT (vorname, 'nls_sort=binary_ci'), NLSSORT (nachname, 'nls_sort=binary_ci')); Aber jetzt sind z.b. keine Bitmapped Indizes auf den Spalten möglich 2c_nls_index.sql 20

nachname = 'Ortmann' AND a.aufstatus = 'G'; SELECT FROM personen p, auftraege a WHERE p.persid = a.

20 Initialisierungsparameter: Cursor_sharing = FORCE SIMILAR)* EXACT Wandelt Literale in Bindevariablen um SELECT FROM personen p, auftraege a WHERE p.persid = a.persid AND p.vorname = 'Horst' AND p.nachname = 'Ortmann' AND a.aufstatus = 'G'; SELECT FROM personen p, auftraege a WHERE p.persid = a.persid AND p.vorname = :"SYS_B_0" AND p.nachname = :"SYS_B_1" AND a.aufstatus = :"SYS_B_2" 21 )* Nicht verwenden! Zu fehleranfällig

21 Was passiert, wenn ein Wert nicht gleich verteilt ist? Z.B. AUFTRAGSSTATUS Geliefert hoffentlich über 90% Storniert hoffentlich nur 1 2 % SELECT FROM personen p, auftraege a WHERE p.persid = a.persid AND a.aufstatus = 'G'; Wenn l_aufstatus = G ist, dann besser Full-Tables Scan Wenn l_aufstatus = S ist, dann besser Index Range Scan 22

Aber was ist mit Bindevariablen? SELECT FROM personen p, auftraege a WHERE p.persid = a.persid AND a.aufstatus = :l_aufstatus; Optimizer analysiert die Abfrage und erstellt u.

22 Aber was ist mit Bindevariablen? SELECT FROM personen p, auftraege a WHERE p.persid = a.persid AND a.aufstatus = :l_aufstatus; Optimizer analysiert die Abfrage und erstellt u.u. einen anderen Ausführungsplan Beispiel von Christian Antognini, Autor des Buches Troubleshooting Oracle Performance) 3_chris_bind1.bat 23

23 SELECT anrede, vorname, nachname, geburtstag FROM tuk.personen pe WHERE pe.nachname like 'Weisse%' and pe.anrede = 'Herr'; 4_abfrage_mb1.bat 4_abfrage_mb8.bat 24

24 25

25 26

26 db_file_multiblock_read_count Anzahl Blöcke die mit einem I/O beim table oder index scan gelesen werden Default 128 (ev. 64) Je höher der Wert umso wahrscheinlicher ein Full-Table-Scan optimizer_index_cost_adj Verhältnis zwischen Full-Table-Scan und Index Benutzung Default 100 Je geringer der Wert umso wahrscheinlicher ein Index Zugriff Schlecht bei hohen Clustering Faktoren! 27

SELECT p.persid, p.vorname, p.nachname, m.email FROM personen p, mail m WHERE p.persid = m.

27 SELECT p.persid, p.vorname, p.nachname, m. FROM personen p, mail m WHERE p.persid = m.persid AND p.persid = :l_persid; Beide Tabellen persid als Primary Key! 5_select_mail.sql (TUK3) 28

28 29

CREATE TABLE MAIL ( PERSID VARCHAR2(10 BYTE), EMAIL

29 CREATE TABLE MAIL ( PERSID VARCHAR2(10 BYTE), VARCHAR2(50 BYTE), BEMERKUNG VARCHAR2(200 BYTE) ) TABLESPACE USERS; 30

30 SELECT DISTINCT anrede, vorname, nachname, geburtstag FROM tuk.kunden WHERE nachname LIKE 'Wei_' AND vorname = 'Martin' AND anrede = 'Herr'; 6_personen.sql 6_kunden.sql 31

31 32

32 33

33 34 SELECT DISTINCT anrede, vorname, nachname, geburtstag FROM tuk.kunden WHERE nachname LIKE 'Wei_' AND vorname = 'Martin' AND anrede = 'Herr';

34 Views sind gut um komplexe Befehle zu verstecken Kaskadierende Views sollten vermieden werden 35

35 Abhängige Spalten SELECT pe.anrede, pe.vorname, pe.nachname, ad.plz, ad.ort, ad.strasse FROM adressen ad, personen pe WHERE pe.persid = ad.persid AND pe.nachname = :nachname AND ad.plz = :plz AND ad.ort = :ort; 7_extended_stat1.sql (TUK3) 36

36 37

37 38

38 Erstellen von erweiterten Statistiken SELECT dbms_stats.create_extended_stats ( OWNNAME => 'TUK3', TABNAME => 'ADRESSEN', EXTENSION => '(PLZ,ORT)') FROM DUAL; BEGIN dbms_stats.gather_table_stats ( OWNNAME => 'TUK3', TABNAME => 'ADRESSEN',ESTIMATE_PERCENT => 100,METHOD_OPT => 'FOR ALL COLUMNS SIZE SKEWONLY',DEGREE => NULL,CASCADE => TRUE,NO_INVALIDATE => FALSE); END; 39

39 Löschen von erweiterten Statistiken BEGIN dbms_stats.drop_extended_stats( OWNNAME => 'TUK2', TABNAME => 'ADRESSEN', EXTENSION => '(PLZ,ORT)'); END; 40

40 41 Automatic Memory Management Fluch und Segen Mindestgrößen definieren! Serverparameter: cursor_sharing immer wieder gern genommen aber besser, der Entwickler benutzt Bindevariablen Bind Peeking beachten db_file_multiblock_read_count kleiner Wert optimizer_index_cost_adj nur Ausnahmsweise verändern Besser: Systemstatistiken regelmäßig aktualisieren Statistiken Histogramme auf kritische Spalten Ev. Extended Statistiken für abhängige Spalten

41 Benutzung von Bindevariablen Dadurch kein cursor_sharing = FORCE notwendig Literale verwenden, wo es sinnvoll ist Änderungen an der Umgebung protokollieren und dem DBA mitteilen Z.B. NLS_SORT bzw. NLS_COMP Verwendung von Funktionen vermeiden Besser BETWEEN als TO_CHAR bei Datumssuche Nicht zu viel verstecken spielen Keine View auf View auf View Datentypen beachten Keine unterschiedlichen Datentypen mit gleichem Namen 42

42 bis 22. November: DOAG Konferenz in Nürnberg

43 Johannes Ahrends

Ähnliche Dokumente

Johannes Ahrends Geschäftsführer CarajanDB CarajanDB GmbH

Johannes Ahrends Geschäftsführer CarajanDB Historie Voraussetzung bei Linux Vergleich Version 10.2 / 11.2 Beispiel 2 Experten mit über 30 Jahren Oracle Erfahrung Spezialisten für Backup & Recovery Hochverfügbarkeit