Oracle Datenbank / Ubuntu

Transkript

1 Oracle Datenbank / Ubuntu Sebastian Gath & Hannes Schwarz Seminar Database Tuning & Administration Universität Konstanz - SS 2007

2 Administration Vorbereitung Zeitmessung Erste Zeitmessung 2 Ausgangssituation & Möglichkeiten Ergebnisse 2 / 32

3 Vorbereitung Zeitmessung Erste Zeitmessung Vorbereitung 1. Installation Ubuntu Installation Oracle (dkpg oracle...) Konfiguration (/etc/init.d/oracle-xe configure) User anlegen (Administrationsoberfläche) 3. Installation TPC (Makefile) Einstellungen: Database DB2 Machine Linux 4. Erstellen der Daten (dbgen scale 1.0) 5. Erstellen/Füllen der Tabellen (sqlplus/sqlldr) 3 / 32

4 Vorbereitung Zeitmessung Erste Zeitmessung Anmerkungen Treiberprobleme bei Ubuntu (Grafikkarte) Libraries für gcc fehlten Datumsformat anpassen alter system set nls date format= YYYY-MM-DD HH24:MI:SS scope=spfile; 4 / 32

5 Vorbereitung Zeitmessung Erste Zeitmessung ShellSkript - Zeitmessung #! /bin/sh echo Jede Anfrage 1000 mal >> zeit.txt for i in *.sql do echo XXXXXXX $i XXXXXXXXX >> zeit.txt for x in seq do sqlplus grep Elapsed >> zeit.txt done done 5 / 32

6 Vorbereitung Zeitmessung Erste Zeitmessung Laufzeiten ohne Optimierungen 6 / 32

7 2 select c count, count(*) as custdist from ( select c custkey, count(o orderkey) c count from customer left outer join orders on c custkey = o custkey and o comment not like %special%requests% group by c custkey ) c orders group c count order by custdist desc, c count desc; 7 / 32

8 2 Ausführungsplan 8 / 32

9 2 Die Tuningidee I Substringsuche Vermeiden von Substringsuche auf Attribut o comment Einfügen und Füllen von neuem Attribut o nonspecial Special request o nonspecial=1 Resultierende Anfrage (gekürzt): select... from ( select c custkey, count(o orderkey) c count from customer left outer join orders on c custkey = o custkey and o nonspecial=1 group by c custkey ) c orders... 9 / 32

10 2 Tuning I die Effekte Einfügen und Füllen von neuem Attribut o nonspecial Speicherverbrauch steigt ABER: Anpassung in Anwendungsprogramm notwendig Laufzeit sinkt von 3.05 sek auf 2.48 sek (ca. um 20% schneller) Weitere Optimierungsschritte: Index auf o nonspecial (Verschlechterung?) Partitionierung der Tabelle (Effekt auf andere Anfragen?) 10 / 32

11 2 Die Tuningidee II Umgehen des left outer join orders on c custkey = o custkey Effekte Tabellen orders und customer geclustered gespeichert (Primärschlüssel) Vereinigungsmenge von Tabelle orders und neu erstelltem Cluster berechnen Speicher durch Cluster effizienter genutzt Schlechtere Performance bei Anfragen auf nicht Clusterparameter Einfügen und Veränderungen langsamer (Hashcluster fixe Größe) Im konkreten Fall drastische Performanceeinbußen 11 / 32

12 2 2 select cntrycode, count(*) numcust, sum(c acctbal) totacctbal from (select substr(c phone, 1, 2) cntrycode, c acctbal from customer where substr(c phone, 1, 2) in ( 13, 31, 23, 29, 30, 18, 17 ) and c acctbal > (select avg(c acctbal) from customer where c acctbal > 0.00 and substr(c phone, 1, 2) in ( 13, 31, 23, 29, 30, 18, 17 )) and not exists (select * from orders where o custkey = c custkey)) custsale group by cntrycode order by cntrycode; 12 / 32

13 2 Ausführungsplan 2 13 / 32

14 2 Die Tuningidee I Substringsuche Definition eines Textindex auf das Attribut c phone Vermeiden von Substringsuche auf Attribut c phone Einfügen und Füllen von neuem Attribut c areacode Kürzen von c phone um die Vorwahl Resultierende Anfrage (gekürzt): select... where (c areacode = 13 or c areacode = 31...) and c acctbal > (select... where c acctbal > 0.00 and (c areacode = 13 or c areacode = 31...)) and not exists (select *...) group by cntrycode / 32

15 2 Die Tuningidee II And not exsists mit anschließendem Subselect durch Mengenoperator minus ausdrücken Resultierende Anfrage (gekürzt): select... from customerac, (select c custkey minkey from customerac minus select o custkey from orders ) ominu where (c areacode = 13 or c areacode = 31...) and c acctbal > (select... where c acctbal > 0.00 and (c areacode = 13 or c areacode = 31...)) group by cntrycode / 32

16 2 Die Effekte Definition eines Textindex auf das Attribut c phone Speicherverbrauch steigt ( Datensätze, Varchar(30)) Anfrage- und Updatepeformance nimmt ab Einfügen und Füllen von neuem Attribut c areacode Speicherverbrauch unverändert ABER: Anpassung in Anwendungsprogramm notwendig Laufzeit sinkt von 1.98 sek auf 1.51 sek (ca. um 25% schneller) And not exsists mit anschließendem Subselect durch Mengenoperator minus ausdrücken Laufzeit steigt von 1.98 sek auf 3.61 sek (ca. Verdoppelung) Customer , Orders Einträge 16 / 32

17 2 select... from part, supplier, partsupp, nation, region where p partkey = ps partkey and s suppkey = ps suppkey and p size = 15 and p type like %BRASS and s nationkey = n nationkey and n regionkey = r regionkey and r name = EUROPE and ps supplycost = ( select min(ps supplycost) from partsupp, supplier, nation, region where p partkey = ps partkey and s suppkey = ps suppkey and s nationkey = n nationkey and n regionkey = r regionkey and r name = EUROPE ) order by s acctbal desc, n name, s name, p partkey; 17 / 32

18 2 Ausführungsplan 18 / 32

19 2 Tuningideen I Idee 1: Selektion p size = 15 and p type like %BRASS beschleunigen Bitmapindex auf p size definieren geht nicht, wahrscheinlich geringer Effekt Textindex auf p type definieren speicherintensiv, Verschlechterung der Performance da führende Wildcard Idee 2: Unteranfrage durch Materialized View und Partitionierung beschleunigen Materialized View mit r name, p partkey und min(ps supplycost) as min supplycost anlegen Partitionierung nach r name Index auf p partkey legen und min supplycost aus Statistik ermitteln 19 / 32

20 2 Tuningideen II Idee 3: Tabellen nation/region geclustered speichern Idee 4: Unteranfrage mit Index auf p partkey; Partionierung materialisieren select p partkey as vtun partkey, min(ps supplycost) as min supplycost from partsupp, supplier, nation, region where p partkey = ps partkey and s suppkey = ps suppkey and s nationkey = n nationkey and n regionkey = r regionkey and r name = EUROPE group by p partkey 20 / 32

21 2 Tuningidee 4 select... from part, supplier, partsupp, nation, region, Vtuning2 where p partkey = ps partkey and p partkey = vtun partkey and s suppkey = ps suppkey and p size = 15 and p type like %BRASS and s nationkey = n nationkey and n regionkey = r regionkey and r name = EUROPE and ps supplycost = min supplycost order by s acctbal desc, n name, s name, p partkey; 21 / 32

22 2 Die Effekte Idee 3 - Cluster Die Auswirkungen sind minimal, da Tabellen sehr klein Idee 4 - Materialized View Speicherverbrauch steigt Refresh-Clause muss angegeben werden (ON COMMIT) Laufzeit sinkt von 0.39 sek auf 0.31 sek (ca. 20% schneller) 22 / 32

23 2 select l orderkey, sum(l extendedprice * (1 - l discount)) revenue, o orderdate, o shippriority from customer, orders, lineitem where c mktsegment = BUILDING and c custkey = o custkey and l orderkey = o orderkey and o orderdate < date and l shipdate > date group by l orderkey, o orderdate, o shippriority order by revenue desc, o orderdate; 23 / 32

24 2 Ausführungsplan 24 / 32

25 2 Die Tuningidee I Laufzeit ohne Tuning 0.95 sek o orderdate < date durch Materialized View und Index beschleunigen 623 orderkeys je o orderdate vorhanden Materialized View mit o orderdate, o orderkey, o custkey, o shippriority Partitionierung nach o orderdate je Jahr; Bitmapindex auf o orderdate je Jahr/Monat nicht erlaubt... Laufzeit mit Tuning I 0.26 sek (ca. um 73% schneller) 25 / 32

26 2 Die Tuningidee II Selektion where c mktsegment = BUILDING beschleunigen table access full auf Einträgen in Tabelle customer davon erfüllen das Selektionskriterium Bitmapindex auf c mktsegment definieren geht nicht... Laufzeit mit Tuning I 0.26 sek (ca. um 73% schneller) 26 / 32

27 2 Ergebnisse im Überblick Laufzeit (sek) Nicht optimiert Optimiert Queryname 27 / 32

28 Ausgangssituation & Möglichkeiten Ergebnisse Ausgangssituation & Möglichkeiten Hauptspeicher den Oracle zur Verfügung hat: 236 MB SGA Alter system set sga max size = 236M Buffer Cache Cache für Datenbanksegmente, z.b. Tabellen, Indexe db 8k cache size = 64 * 1024 * 1024 Byte select * from v$shared pool advice; Shared Pool Ausführungspläne, Data Dictionary Cache Tabellen mit Primary Key versehen Keine Tabelle dauerhaft im Cache alter table tab storage (buffer pool keep); 28 / 32

29 Ausgangssituation & Möglichkeiten Ergebnisse Laufzeiten unter verschiedenen Einstellungen 29 / 32

30 Viele Maßnahmen nicht möglich (Express) Partitionierung Bitmapindex Index auf Materialized View Maximal Datenbankgröße ca. 5 GB SQL Tuning Advisor, Access Advisor... Oracles Anfragenoptimierer optimiert sehr gut Indexe verlangsamen oft Dennoch Performancesteigerungen mit akzeptablen Kosten möglich 30 / 32

31 Literatur Loney, Kevin, Oracle Database 10g. Die umfassende Referenz; Hanser 2005 Haas, Frank; Oracle-Tuning in der Praxis München; Hanser / 32

32 Vielen Dank für die Aufmerksamkeit. 32 / 32