PostgreSQL optimieren · INFO: free space map contains 1368 pages in 117 relations DETAIL: A total of 2912 page slots are in use (including overh ead). 2912 page slots are required

PostgreSQL optimierenCLT 2010 – 13.-14.03.2010

Andreas ’ads’ Scherbaum

Web: http://andreas.scherbaum.la/

E-Mail: andreas[at]scherbaum.biz

PGP: 9F67 73D3 43AA B30E CA8F 56E5 3002 8D24 4813 B5FE

13.-14.03.2010

Intro Konfiguration Performance Transaktionen Informationen VACUUM Fragen & Antworten

Was ist PostgreSQL?

Relationale Datenbank unter BSD Lizenz

Weltweit aktive Community

Zahlreiche Features und Funktionen (Foreign Keys,Transaktionen, Trigger)

Lauft auf zahlreichen Betriebssystemen und diverser Hardware

Weitgehendes Einhalten der SQL-Standards – Dokumentationder Abweichungen

Im Schnitt pro Jahr ein Minor-Release mit neuen Features

Version 9.0 wird derzeit fleißig entwickelt

Andreas ’ads’ Scherbaum PostgreSQL optimieren


Der Dozent

Der Dozent

Name: Andreas Scherbaum

Selbststandig im Bereich Datenbanken, Linux aufKleingeraten, Entwicklung von Webanwendungen

Arbeit mit Datenbanken seit 1997, mit PostgreSQL seit 1998oder 1999

Grundungsmitglied der Deutschen und der EuropaischenPostgreSQL User Group

Board of Directors – European PostgreSQL User Group



.la

Was bedeutet dieses komische .la?

http://andreas.scherbaum.la/

.la ist die TLD von Laos

.la wird von Los Angeles genutzt und verwaltet

LA ist das KFZ-Kennzeichen von Landshut/Niederbayern

Dort habe ich langere Zeit gewohnt und meine Frau fand dieDomain schon



Ziele dieses Workshops


Konfiguration: (Installation,) Speichernutzung einstellen,Logdateien konfigurieren, Zugriff aus dem Netzwerk ermoglichen.der Planer und seine Statistiken

Performance: grundlegende Details, Partitionierung, Tablespaces

Analyse: von Anfragen, Auffinden langsamer Queries, Anfrageplaneim Detail

Informationen: was die Datenbank alles mitteilen kann

VACUUM: der Staubsauger, Sinn, Nutzen und Konfiguration

Transaktionen: Wozu braucht man so etwas?

SQL-Injections: Was ist das? Warum ist das wichtig?




Skripts zum Workshops

http://andreas.scherbaum.la/writings/clt-2010-skripts.zip



Konfiguration

Konfiguration – Ubersicht

Alle Konfigurationen fur PostgreSQL werden in der Dateipostgresql.conf vorgenommen

Alle Einstellungen fur Zugangsberechtigungen werden in derDatei pg hba.conf vorgenommen

Nach Anderungen mittels pg ctl reload die Konfigurationneu laden

Ein Neustart ist nur selten notwendig und ist in derKonfiguration vermerkt



Konfiguration

Konfiguration – Speichernutzung

shared buffers: Verfugbarer Speicher fur alle PostgreSQLProzesse

Ev. /etc/sysctl.conf anpassen (kernel.shmmax undkernel.shmall)

http://www.postgresql.org/docs/current/static/kernel-resources.html

work mem: Speicher fur Sortieroperationen und HashingTabellen

maintenance work mem: Speicher fur VACUUM undANALYZE

temp buffers: Speicher fur temporare Tabellen



Konfiguration


max fsm pages: bestimmt die Verwaltung von Disk Pages

max fsm relations: bestimmt die Anzahl von Tabellen undIndizes

VACUUM VERBOSE Ausgabe beachten

Neu in PostgreSQL 8.4: FSM konfiguriert sich selbst

max stack depth: Große des nutzbaren Stacks (ulimitbeachten)



Konfiguration


Beispiel (VACUUM VERBOSE Ausgabe)

INFO: free space map contains 1368 pages in 117 relations

DETAIL: A total of 2912 page slots are in use (including overhead).

2912 page slots are required to track all free space.

Current limits are: 153600 page slots, 1000 relations, using 965 kB.

2912 Speicherseiten (a 8kB) und 117 Objekte verwendet

153.600 Speicherseiten und 1000 Objekte kann die Datenbankverwalten

kostet weniger als 1 MB RAM



Konfiguration

Konfiguration – Logdateien

log filename: Format fur Logdateien in pg log (siehestrftime())

log rotation age: Logfiles nach Zeit rotieren

log rotation size: Logfile nach Große rotieren

log error verbosity: PostgreSQL wird gesprachiger(verbose)

log min error statement: minimaler Loglevel (Default:info)



Konfiguration

Konfiguration – Logdateien

log min duration statement: Ausfuhrungszeit vonAnfragen loggen (Default: -1)

bis 8.3: redirect stderr: leitet Ausgaben in eine Logdateium

ab 8.4: log destination: leitet Ausgaben in stderr,csvlog, syslog oder eventlog um

ab 8.4: logging collector: aktiviert das Umleiten derFehler in das Log



Konfiguration

Konfiguration – Netzwerk

listen addresses: genutzte Netzwerkinterfaces (’*’,’localhost’, IP-Adressen)

port: Netzwerkport (Default: 5432)

max connections: maximale Anzahl Netzwerkverbindungen

superuser reserved connections: Reserve fur den Admin+ VACUUM



Konfiguration

Konfiguration – Netzwerk

unix socket directory: Verzeichnis fur denUnix-Domain-Socket

unix socket group: Gruppenname fur Domainsocket File

unix socket permissions: Integer Wert fur Zugriffsrechteauf Domainsocket File



Konfiguration

Shared Memory – SHMMAX

Maximale Große eines einzelnen Shared Memory Segments

Auf 32-Bit Systemen maximal 4 GB – jedoch effektiv weniger

Aktuellen SHMMAX Wert abfragen: cat/proc/sys/kernel/shmmax

Neuen Wert setzen: sysctl -w kernel.shmmax=220000000

Hinweis: SUSE/OpenSUSE und Red Hat nutzen bereits dengesamten Hauptspeicher als Shared Memory.



Konfiguration

Shared Memory – SHMMAX – Berechnung

Gesucht: Shared Memory mit einer Große von 200 MB

Beispiel (Berechnung von SHMMAX)

200 MB = 1024 Bytes * 1024 kB * 200 MB

= 209715200

aufgerundet: 220000000 (220.000.000)



Konfiguration

Konfiguration – Ubung

PostgreSQL an alle Netzwerkinterfaces binden

42 maximale Verbindungen zulassen

1024 MB Shared Memory einstellen

Speicher fur Sortieroperationen auf 3 MB einstellen

Logfiles taglich neu erstellen, der Wochentag erscheint imDateinamen

Anfragen mit einer Laufzeit uber 5 Sekunden protokollieren



Konfiguration

Konfiguration – Losung der Ubung

listen addresses = ’*’

max connections = 42

shared buffers = 1024MB

kernel.shmmax und kernel.shmall anpassen

work mem = 3MB

log directory = ’/pfad/zum/verzeichnis’ (ggf. außerhalbdes Datenverzeichnis)

log filename = ’postgresql-%a.log’

log min duration statement = 5000



Konfiguration

Konfiguration – Planer

enable bitmapscan, enable hashagg, enable hashjoin,enable indexscan, enable mergejoin, enable nestloop,enable seqscan, enable sort, enable tidscan

Alle Werte sind per Default on und beeinflussen den Planer

Zur Laufzeit umschaltbar: SET enable seqscan = off

effective cache size: ungefahre Große des Caches imBetriebssystem

geqo: Generic Query Optimizer ein- oder ausschalten



Konfiguration

Konfiguration – Planer

seq page cost: Kosten fur das Lesen eines Blocks wahrendeiner laufenden Leseoperation (1.0)

random page cost: Kosten fur das Lesen eines zufalligenBlocks (4.0)

cpu tuple cost: Kosten fur das Bearbeiten einer Zeile (row)(0.01)

cpu index tuple cost: Kosten fur das Bearbeiten einesEintrags im Index (0.005)

cpu operator cost: Kosten fur den Aufruf eines Operatorsoder einer Funktion (0.0025)



Konfiguration

Konfiguration – Statistiken

track activities: in 8.3, aktiviere Statistiken furausgefuhrte Befehle

stats start collector: in 8.2, aktiviere Statistiken

stats block level: in 8.2, aktiviere Statistiken furblockbasierte Operationen

stats row level: in 8.2, aktiviere Staristiken furzeilenbasierte Operationen

track counts: in 8.3, aktiviere Statistiken furDatenbankaktivitaten (Autovacuum)



Konfiguration

Konfiguration – Statistiken loggen

log statement stats: Statistiken uber den ausgefuhrtenBefehl

log parser stats: Statistiken uber die Parser Operationen

log planner stats: Statistiken uber die Planer Operationen

log executor stats: Statistiken uber die effektivausgefuhrten Operationen

Hinweis: log statement stats kann nicht zusammen miteiner anderen Option aktiviert werden



Konfiguration

Konfiguration – Write Ahead Log (WAL)

fsync: aktiviert oder deaktiviert synchrones Schreiben. offkann zu Datenverlusten und einer beschadigten Datenbankfuhren!

synchronous commit: bei off wird nicht auf das Beendendes Schreibens gewartet. Datenverluste sind moglich, aberkeine beschadigte Datenbank.

wal buffers: Große des Speicherbereichs zum Schreibeneines Eintrags in das WAL.

checkpoint segments: Anzahl WAL-Logfiles, die rotiertwerden



Grunde fur schlechte Performance

Die Moglichkeiten sind fast unbegrenzt ...

Falsche (oder gar fehlende) Konfiguration

Anwendung stellt Anfragen falsch

Datenbank Layout ist falsch oder ungenugend (fehlendeIndizies, fehlende Normalisierung)

Anwendungen fragen zu viele (unnotige) Daten ab (z.B.:SELECT *, fehlendes WHERE)

Latenzzeiten (z.B. Netzwerk, Zugriffszeiten der Festplatten)

Ungenugende Hardware

...



Ungenugende Hardware

Performance – Ungenugende Hardware

Mehr RAM, mehr RAM, noch mehr RAM

Daten die im Speicher vorgehalten werden, mussen nicht vonder Platte gelesen werden

Langsame Festplatten gegen schnellere ersetzen, ggf. einRAID oder Tablespaces nutzen

Es gilt:

die Performance verbessert sich mit der Anzahl derSpindeln

Schwachstellen im I/O-System herausfinden

SSD-Platten in Betracht ziehen: sehr schnell beim Lesen,jedoch derzeit noch Probleme beim Schreiben



Performancesteigerung durch Hardware

Performancesteigerung durch Hardware

Soviel RAM wie notwendig: die wichtigen Tabellen/Datensollen komplett im RAM liegen

RAID kann Plattenzugriffe verteilen – aber nur unabhangigvon der tatsachlichen Nutzung

Mittels Tablespaces kann man Zugriffe gezielt aufverschiedene Platten verteilen - z. B. Tabelle und Index aufzwei Spindeln legen

Wenig genutzte Daten konnen auf langsame (und gunstige)Datentrager ausgelagert werden



Performancesteigerung durch Konfiguration

Performance – falsche Konfiguration

Hinweis: die standardmaßige PostgreSQL Konfiguration ist aufgeringen Ressourcenverbrauch ausgelegt.

shared buffers zu gering

FSM – Free-Space-Map nicht angepasst

Bei umfangreichen Operationen work mem erhohen

maintenance work mem kann mehr Speicher fur VACUUMbereitstellen

temp buffers: bei Uberschreiten werden Daten auf dieFestplatte ausgelagert




Performance – Anwendung stellt Anfragen falsch

Mittels log min duration statement langlaufende Anfragenermitteln

Anfragen mittels EXPLAIN und EXPLAIN ANALYZE uberprufen

Gleiche Anfragen mittels Prepared Statement aufrufen:erspart den Parser Schritt

Zahlreiche INSERT-Operationen mittels PreparedStatement oder besser COPY durchfuhren




Performance – Datenbank Layout ist falsch oderungenugend

Testweise prufen, ob ein Index auf einer Spalte eineVerbesserung der Laufzeit bewirkt

Wichtig: ANALYZE fur die Tabelle nicht vergessen

Tabellen normalisieren – in der Regel ergeben sich dadurch furdie Datenbank besser handhabbare Anfragen




Performance – BG-Writer

Der Background-Writer schreibt normalerweise verteilt uberdie halbe Zeit

Parameter: checkpoint completion target (Default: 0.5)

Bei kontinuierlicher Schreiblast Anpassung bis 0.9 sinnvoll




Performance – Transaktionen zusammenfassen

commit delay verzogert abgeschlossene Transaktionenkurzzeitig (0 bis 10 Sekunden, Default: 0)

Dadurch konnen mehrere Transaktionen in einem Durchganggeschrieben werden

Nur ein sync() ist notwendig

Wird ab commit siblings (Default: 5) offenenTransaktionen aktiviert




Performance – großere Statistiken

default statistics target legt die Anzahl der haufigstenEintrage in der Statistik fest

Bis PostgreSQL 8.3: 10 Eintrage

Ab PostgreSQL 8.4: 100 Eintrage

Von 1 bis 1000 Eintrage moglich

Vorteil: die Datenbank kennt mehr haufig vorkommendeEintrage und kann den Ausfuhrungsplan anpassen

Nachteil: kostet mehr Platz fur die Statistiken




Performance – Prefetching

Posix-Feature, ab PostgreSQL 8.4 vorhanden

Gibt die voraussichtliche Anzahl paralleler Zugriffe bekannt

Parameter: effective io concurrency (1 bis 1000, 0deaktiviert das Feature, Default: 1)



Partitionierung

Partitionierung – Vorteile

Daten werden ausgehend von der tatsachlichen Situationgespeichert

Sequentielle Scans durchlaufen nicht den gesamtenDatenbestand

Bestimmte Verwaltungsarbeiten lassen sich effizientdurchfuhren

Daten konnen auf unterschiedliche Medien aufgeteilt werden

Die Partitionierung kann anhand jedes beliebigen Kriteriumserfolgen – solange dieses voraussagbar ist



Partitionierung

Partitionierung bei PostgreSQL

Tabellen werden durch Inheritance (Vererbung) von einerMastertabelle erstellt:

Beispiel (Mastertabelle erstellen)

CREATE TABLE log_data (

id SERIAL NOT NULL

PRIMARY KEY,

insert_at TIMESTAMP NOT NULL,

data VARCHAR(100) NOT NULL

);

Hinweis: TIMESTAMPTZ ist hier nicht anwendbar!



Partitionierung


Beispiel (Abgeleitete Tabellen erstellen)

CREATE TABLE log_data_200901 ( ) INHERITS (log_data);


INSERT INTO log_data_200902 (insert_at, data)

VALUES (’2009-02-12’, ’data set 42’);

INSERT INTO log_data_200901 (insert_at, data)

VALUES (’2009-01-23’, ’data set 23’);



Partitionierung


Beispiel (Daten in Tabelle 200901)

SELECT * FROM log_data_200901;

id | insert_at | data

----+------------------------+-------------

2 | 2009-01-23 00:00:00+01 | data set 23

(1 Zeile)

Beispiel (Daten in Tabelle 200902)

SELECT * FROM log_data_200902;


----+------------------------+-------------

1 | 2009-02-12 00:00:00+01 | data set 42

(1 Zeile)



Partitionierung


Beispiel (Daten in Master Tabelle)

SELECT * FROM log_data;


----+------------------------+-------------

2 | 2009-01-23 00:00:00+01 | data set 23

1 | 2009-02-12 00:00:00+01 | data set 42

(2 Zeilen)



Partitionierung

Korrekte Timestamps erzwingen

Beispiel (Abgeleitete Tabellen mit CONSTRAINTs erstellen)


CREATE TABLE log_data_200902 (

CHECK (insert_at >= DATE ’2009-02-01’ AND

insert_at < DATE ’2009-03-01’)

) INHERITS (log_data);



Partitionierung

Nutzung des Timestamp bei einer Anfrage

Wenn PostgreSQL einen Contraint auf der vererbten Tabellevorfindet, wird dieser dazu genutzt, die komplette Tabelle gf.aus der Abfrage auszuschließen

Hinweis: Alle abgeleiteten Tabellen wurden neu mitConstraints erstellt.

Beispiel (CONSTRAINTs nutzen)

-- bis PostgreSQL Version 8.3:

SET constraint_exclusion = on;

EXPLAIN SELECT * FROM log_data

WHERE insert_at=’2008-10-11’;



Partitionierung


Beispiel (CONSTRAINTs in einer Anfrage nutzen)



QUERY PLAN

-----------------------------------------------------

Result (...)

-> Append (...)

-> Seq Scan on log_data (...)

Filter: (insert_at = ’2008-10-11

00:00:00’::timestamp

without time zone)

(4 Zeilen)



Partitionierung


Beispiel (CONSTRAINTs in einer Anfrage nutzen)



QUERY PLAN

-----------------------------------------------------

Result (...)

-> Append (cost=0.00..27.75 rows=4 width=230)

-> Seq Scan on log_data (...)



without time zone)

-> Seq Scan on log_data_200901 log_data ()



without time zone)

(6 Zeilen)



Partitionierung

Partitionierung – Nachteile und Wartung

Der partitionierte Schlussel muss in den (meisten) Anfragenverwendet werden

Andernfalls kann PostgreSQL nicht herausfinden, welcheTabellen ein- oder auszuschließen sind

Daten mussen entweder in die partitionierte Tabelle eingefugtoder mittels Trigger/Rules von der Master Tabelle umgeleitetwerden

Das Loschen alter Daten geht schnell: nur die entspechendeTabelle loschen

Hinweis: Rules mussen entfernt bzw. Trigger umgeschriebenwerden



Partitionierung

Partitionierung – Ubung

Eigene partitionierte Tabellen erstellen

Testdaten erstellen

Daten aus partitionierten Tabellen und der Mastertabelleauslesen



Tablespaces

Tablespaces – Vorteile gegenuber RAID

Tabellen und Indexes konnen gezielt (und getrennt) aufverschiedene Datentrager verteilt werden

Verschiedene Datenbanken oder Tabellen konnen sich aufverschieden schnellen Datentragern befinden



Tablespaces

Tablespace erstellen

Beispiel (Tablespace anlegen)

CREATE TABLESPACE ts_neu LOCATION ’/mnt/db_neu’;

Der Name des Tablespace muss eindeutig sein und darf bishernicht vergeben sein

Das Verzeichnis ”/mnt/db neu” muss ”postgres” gehoren undleer sein, der absolute Pfad wird verlangt

Tablespaces konnen nur von einem Admin angelegt werden

Das Zuweisen an einen anderen User ist moglich (OWNER)



Tablespaces

Tablespace nutzen

Tablespaces werden mit Hilfe der Option ”TABLESPACE”beim Erstellen eines Objekts angewandt:

Beispiel (Index auf Tablespace erstellen)

CREATE INDEX test1_index ON test1(id)TABLESPACE ts_neu;

Eine nachtragliche Zuweisung zu einem anderen Tablespace istmoglich:

Beispiel (Index nachtraglich verschieben)

ALTER INDEX test1_index SET TABLESPACE ts_neu;



Tablespaces

Tablespace per Datenbank angeben

Eine Datenbank kann komplett auf einem anderen Tablespaceerzeugt werden:

Beispiel (Tablespace fur Datenbank angeben)

CREATE DATABASE neue_db TABLESPACE = ts_neu;

Der Default Tablespace fur neue Objekte lasst sich andern:

Beispiel (Default Tablespace andern)

SET default_tablespace = ts_neu;



Tablespaces

Neu in PostgreSQL 8.4!

Eine ganze Datenbank kann nachtraglich auf einen anderenTablespace umgezogen werden:

Beispiel (Datenbank auf anderen Tablespace umziehen)

ALTER DATABASE neue_db SET TABLESPACE ts_neu;



Tablespaces

Tablespaces – Ubung

Eigenen Tablespace anlegen

Eine Tabelle im neuen Tablespace anlegen

Tabelle ohne Tablespace anlegen

Index in neuen Tablespace verschieben



Analyse von Anfragen

Analyse von Anfragen – Warum?

Langsame Anfragen schneller gestalten

Performance-Schwachstellen entdecken

Ungenutzte Indexes herausfinden

...




Analyse von Anfragen – Wie

EXPLAIN: liefert den Queryplan fur eine Anfrage

EXPLAIN ANALYZE: fuhrt die Anfrage zusatzlich aus und misstdie Laufzeiten




Analyse von Anfragen – Ubung

Die pg tables Tabelle mit EXPLAIN und EXPLAIN ANALYZEanalysieren

Bonus: Verwendung von Indexes erzwingen und die Analysewiederholen




Analyse von Anfragen – Losung

Beispiel (System-View pg tables)

EXPLAIN SELECT * FROM pg_tables;

EXPLAIN ANALYZE SELECT * FROM pg_tables;

SET enable_seqscan = off;

EXPLAIN SELECT * FROM pg_tables;

EXPLAIN ANALYZE SELECT * FROM pg_tables;



Der Planer

Der Planer im Detail

Jede Anfrage wird vom Planer bearbeitet und in einenQueryplan ubersetzt

Zu einzelnen Teilen der Anfrage werden statistischeInformationen aus den Tabellen geholt

Aufgrund dieser Informationen wird entschieden, ob z.B. einIndex genutzt wird

Der Planer kann ggf. Anfragen intern umschreiben (JOINsauflosen, RULEs anwenden)

Der Datentyp spielt ebenfalls eine Rolle



Der Planer

Beispiel Tabelle

Beispiel (Beispiel Tabelle)

CREATE TABLE planer_test (

id SERIAL NOT NULL UNIQUE,

inhalt VARCHAR NOT NULL

);

INSERT INTO planer_test (inhalt) VALUES (’Inhalt 001’);





Beispiel (Statistiken up to date)

VACUUM ANALYZE VERBOSE planer_test;



Der Planer


Beispiel (EXPLAIN Ausgabe)

postgres=# EXPLAIN SELECT id, inhalt FROM planer_test WHERE id=1;

QUERY PLAN

------------------------------------------------------------

Seq Scan on planer_test (cost=0.00..1.06 rows=1 width=18)

Filter: (id = 1)

(2 Zeilen)



Der Planer


Seq Scan on planer test (cost=0.00..1.06 rows=1width=18)

Sequentieller Scan auf die Tabelle

Gesamtkosten: 1.06

Kosten bis zum Lesen des ersten brauchbaren Wertes: 0.00

Erwartete Anzahl Spalten: 1



Der Planer


Frage: Warum ein sequentieller Scan, wenn wir doch einenIndex auf id haben?

Erzwingen wir die Nutzung des Index:

SET enable seqscan=0;

Einschatzung: Was wird passieren?



Der Planer


Beispiel (EXPLAIN Ausgabe)

postgres=# EXPLAIN SELECT id FROM planer_test WHERE id=1;

QUERY PLAN

---------------------------------------------------------

Index Scan using planer_test_id_key on planer_test

(cost=0.00..3.01 rows=1 width=4)

Index Cond: (id = 1)

(2 Zeilen)

Was ist passiert?

Index wird gelesen: Kosten 1-2

Da sich alle Daten in einem Block befinden, muss dieser Blockdanach sowieso gelesen werden

Resultat: Kosten 3



Der Planer

Analyse von Anfragen – Erkentnisse

PostgreSQL erstellt jeden Queryplan dynamisch und abhangigvom Zustand der Daten

Zwei Anfragen auf die gleiche Tabelle, bei unterschiedlichenDatenmengen, konnen anders ausgefuhrt werden

Daraus resultiert: PostgreSQL sollte gute Informationen uberdie Daten in den Tabellen haben

Das wichtigste Hilfsmittel ist ANALYZE (bzw. VACUUMANALYZE)

Der Autovacuum Daemon ubernimmt die meiste Arbeit



Der Planer

Analyse von Anfragen – Ausfuhrungszeit messen

Beispiel (EXPLAIN ANALYZE Ausgabe)

postgres=# EXPLAIN ANALYZE SELECT id FROM planer_test WHERE id=1;

QUERY PLAN

-------------------------------------------------------------------


(actual time=0.017..0.025 rows=1 loops=1)

Filter: (id = 1)

Total runtime: 0.066 ms

(3 Zeilen)

EXPLAIN ANALYZE fuhrt die Anfrage aus und misst die Zeit

Die gemessenen Zeiten bewegen sich innerhalb der vorabgeschatzten Werte

Sollte es hier grobe Abweichungen geben, hat der Planerfalsche Daten!

Vorsicht: Es werden Daten verandert!



Der Planer

Analyse von Anfragen – Negativbeispiel

Beispiel (EXPLAIN ANALYZE Ausgabe)

postgres=# EXPLAIN ANALYZE SELECT id FROM planer_test WHERE id=10;

QUERY PLAN

-------------------------------------------------------------------



Filter: (id = 10)


(3 Zeilen)

Eine sequentielle Suche nach einem nicht vorhandenen Wert

Die Datenbank muss die gesamte Tabelle lesen (minimal0.022 gleich 0.022)

Ein Index hatte hier womoglich schneller Auskunft gegeben



Der Planer

Analyse von Anfragen – großere Tabelle

Beispiel (Tabelle mit vielen Inhalten erzeugen)

CREATE TABLE planer_test2 (

id INTEGER NOT NULL PRIMARY KEY,

inhalt FLOAT NOT NULL

);

INSERT INTO planer_test2 (id, inhalt)

SELECT generate_series (1, 10000000), RANDOM();

Beispiel (Statistiken up to date)

VACUUM ANALYZE VERBOSE planer_test2;



Der Planer


Beispiel (einen bestimmten Wert suchen)

postgres=# EXPLAIN SELECT id, inhalt FROM planer_test2

WHERE id=800000;

QUERY PLAN

----------------------------------------------------

Index Scan using planer_test2_pkey on planer_test2

(cost=0.00..9.14 rows=1 width=12)


(2 Zeilen)



Der Planer


Beispiel (Laufzeit messen)

postgres=# EXPLAIN ANALYZE SELECT id, inhalt FROM planer_test2

WHERE id=800000;

QUERY PLAN

----------------------------------------------------

Index Scan using planer_test2_pkey on planer_test2

(cost=0.00..9.14 rows=1 width=12) (actual time=0.029..0.032 rows=1 loops=1)



(3 Zeilen)



Der Planer


Beispiel (Nutzung der Indicies verbieten)

SET enable_indexscan = off;

SET enable_bitmapscan = off;



Der Planer


Beispiel (Laufzeit messen)

postgres=# EXPLAIN ANALYZE SELECT id, inhalt FROM planer_test2

WHERE id=800000;

QUERY PLAN

----------------------------------------------------

Seq Scan on planer_test2

(cost=0.00..174020.00 rows=1 width=12)


Filter: (id = 800000)


(3 Zeilen)



Transaktionen?

Transaktionen

Transaktionen kapseln beliebig viele Aktionen in derDatenbank zu einer einzelnen Aktion nach außen

Beispiel: Bankuberweisung

Schritt 1: Geld wird von Ihrem Konto abgebucht

Schritt 2: Geld wird auf das andere Konto gebucht

Was passiert, wenn zwischen Schritt 1 und 2 ein Fehlerauftritt?



Transaktionen?

Transaktionen – ACID

A C I D

A: Atomaritat (Atomicity) – ganz oder gar nicht

C: Konsistenz (Consistency) – Datenbestand ist vor und nachder Transaktion konsistent

I: Isolation (Isolation) – alle Aktionen (Transaktionen) sindvoneinander abgekapselt

D: Dauerhaftigkeit (Durability) – bestatigte Anderungenbleiben erhalten



Wie werden Transaktionen genutzt?

Transaktionen nutzen

Beispiel (Transaktion starten)

BEGIN;

START TRANSACTION;

Beispiel (Transaktion abschließen)

COMMIT;

Beispiel (Transaktion zuruckrollen)

ROLLBACK;

Hinweis: PHP bietet keine eingebauten Funktionen furTransaktionen

Perl DBI kennt begin work(), commit() und rollback()



Isolation von Transaktionen


Beispiel:

Transaktion 1 startet mit eigener aktueller Ansicht derDatenbank (I – Isolation)

Transaktion 2 startet

Transaktion 2 andert einen Wert in einer Tabelle

Transaktion 2 committed ihre Anderungen, diese werdensichtbar

Aber: Transaktion 1 muss weiterhin den alten Wert sehenkonnen, da dieser beim Start der Transaktion gultig war




Isolation von Transaktionen – Ubung

Zwei Verbindungen zur Datenbank offnen

Eine Tabelle erstellen

In beiden Verbindungen eine Transaktion starten

Den Inhalt der Tabelle in beiden Verbindungen anzeigen lassen

In einer Transaktion einen Datensatz einfugen

Den Inhalt der Tabelle in beiden Verbindungen anzeigen lassen





Beispiel (Beispieltabelle erstellen)

CREATE TABLE transaktion_test (

id SERIAL NOT NULL

PRIMARY KEY,

wert VARCHAR NOT NULL

);





Beispiel (Beispiel)

T1: BEGIN;

T2: BEGIN;

T1: SELECT * FROM transaktion_test;


T1: INSERT INTO transaktion_test (wert) VALUES (’etwas Inhalt’);



T1: COMMIT;



T2: COMMIT;





Beispiel (Beispiel)

T1: BEGIN;

T2: BEGIN;

T1: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

T2: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

-- Ubung von vorheriger Folie ab SELECT ... wiederholen




Isolation von Transaktionen – die Nachteile

Das notwendige Vorhalten alterer Versionen eines Datensatzeswird Multiversion Concurrency Control (kurz: MVCC)genannt

Diese alten Versionen belegen Platz auf der Festplatte und imIndex

Diese Uberreste konnen mit dem Befehl VACUUM aufgeraumtwerden, Syntax:

Beispiel (VACUUM fur eine Tabelle aufrufen)

VACUUM ANALYZE tabelle;

Hinweis: VACUUM kann nicht innerhalb einer Transaktion aufgerufenwerden




Isolation von Transaktionen – mogliche Probleme

Innerhalb von Transaktionen kann es zu vielfaltigen Problemenkommen:

Dirty Read: Andere Transaktionen konnen Daten deraktuellen Transaktion lesen, obwohl die Anderungen noch nichtcommitted wurdenNon-Repeatable Read: Bei mehrfachen, gleichenLesezugriffen innerhalb einer Transaktion gibt esunterschiedliche ErgebnissePhantom Read: Durch Einfugen, Andern oder Loschen gibt esin anderen Transaktionen bei gleichen Bedingungenunterschiedliche Ergebnisse




Isolation von Transaktionen – Transaktionslevel

SQL definiert 4 verschiedene Transaktionslevel:

READ UNCOMMITTED: Anderungen innerhalb einer Transaktionsind von außerhalb zu sehen (in PG: READ COMMITTED)READ COMMITTED: Anderungen sind nur nach einem COMMIT zusehenREPEATABLE READ: Die Datenbank merkt sich den Zeitpunktdes ersten Lesens eines Datensatzes, dies trifft jedoch nicht aufzwischenzeitlich eingefugte Datensatze zu (in PG:SERIALIZABLE)SERIALIZABLE: Die Transaktionen sind vollig gekapselt

PostgreSQL nutzt nur READ COMMITTED und SERIALIZABLE




Isolation von Transaktionen – Probleme und Isolationslevel

Level Dirty Read Non-Repeatable Read Phantom ReadRead Uncommitted Moglich Moglich Moglich

Read Committed Unmoglich Moglich MoglichRepeatable Read Unmoglich Unmoglich Moglich

Serializable Unmoglich Unmoglich Unmoglich





Unterschiede zwischen READ COMMITTED und SERIALIZABLE:

READ COMMITTED: Daten, die vor dem Beginn des Query, abernach Beginn der Transaktion sichtbar waren, werden angezeigt

SERIALIZABLE: Nur Daten, die vor Beginn der Transaktionsichtbar waren, werden angezeigt

Hinweis: bei SERIALIZABLE kann es zuTransaktionsabbruchen kommen, die Applikation muss diesabfangen!





PostgreSQL Default: READ COMMITTED

Andern mit: SET TRANSACTION ISOLATION LEVELSERIALIZABLE

Befehl muss nach START TRANSACTION/BEGIN aufgerufenwerden

Die Einstellung kann nach der ersten Daten-anderndenAnweisung (inkl. SELECT) nicht mehr geandert werden




Transaktionen – Savepoints

Ein Savepoint ist ein Punkt innerhalb einer Transaktion, biszu dem zuruckgerollt werden kann

Mehrere Savepoints sind moglich

Savepoints sind nur in einer Transaktion moglich

Ein ROLLBACK zerstort auch alle spateren Savepoints




Transaktionen – Savepoints

Beispiel (Savepoint erstellen)

SAVEPOINT bis_hierhin;

Beispiel (Zu einem Savepoint zuruckkehren)

ROLLBACK TO bis_hierhin;

Beispiel (Einen Savepoint freigeben)

RELEASE SAVEPOINT bis_hierhin;




Transaktionen – Savepoints – Ubung

Eine Transaktion starten

Einen Savepoint erstellen

Eine Tabelle loschen

Zum Savepoint zuruckkehren



Information Schema

information schema

Das Information Schema stellt einen standardisierten Wegbereit, Informationen uber die Struktur der Datenbankauszulesen

Dazu gibt es Views im Schema information schema

Z.B. Tabellen, Spalten, Views, User, Sequencen, Trigger,Privilegien u.v.m.

http://www.postgresql.org/docs/current/static/information-schema.html



Information Schema

information schema

tables: Enthalt Tabellen und Views

columns: Enthalt alle Spalten jeder Tabelle

schemata: Enthalt alle Schemata

routines: Enthalt alle Funktionen

sql features: Unterstutzte (oder nicht unterstutzte) SQLFunktionalitaten



Information Schema

information schema – Ubung

Herausfinden wie man alle Spalten einer Tabelle anzeigen kann



Information Schema

information schema – Beispiel

Beispiel (Alle Spalten von allen Tabellen)

SELECT table_schema,table_name,column_name,data_type

FROM information_schema.columns

ORDER BY table_schema, table_name;

Beispiel (Alle Spalten von einer Tabelle)

SELECT table_schema,table_name,column_name,data_type

FROM information_schema.columns

WHERE table_schema=’<schema name>’

AND table_name=’<tabellenname>’;



Systemtabellen

pg * Systemtabellen

Nicht SQL-konform, eine PostgreSQL-Erweiterung

Seit vielen Versionen vorhanden

Struktur kann sich verandern

Wesentlich weitreichendere Informationen als iminformation schema

Anderungen konnen die Datenbank unbrauchbar werdenlassen!



Systemtabellen

pg * Systemtabellen

pg tables: Listet alle Tabellen auf

pg views: Listet alle Views auf

pg attribute: Enthalt Informationen uber alleTabellenspalten

pg namespace: Enthalt Schemata

pg proc: Enthalt Funktionen

pg statistics: Enthalt Planer Statistiken

pg stat * und pg statio *: Views mit aufbereitetenStatistikdaten

...



Systemtabellen

pg * Systemtabellen – Ubung

Herausfinden wie man alle Spalten einer Tabelle anzeigen kann



Systemtabellen

pg * Systemtabellen – Losung

Beispiel (Alle Spalten einer Tabelle)

psql mit den Optionen -eE starten

\d <tabelle>

Ausgabe des Queries nutzen



Was ist VACUUM?

VACUUM – ein Staubsauger?

Durch MVCC bleiben alte Daten nach Abschluss einerTransaktion in einer Tabelle zuruck

VACUUM gibt diesen Platz wieder frei

ANALYZE aktualisiert die Statistiken fur den Planer

Shortcut: VACUUM ANALYZE

Der Autovacuum Daemon kann die Arbeit automatisierterledigen

Neu in PG 8.3: HOT – Heap-Only-Tuples

quasi ein kleines Vacuum innerhalb des Blocks

Voraussetzung: kein Wert im Index wird geandert



Was ist VACUUM?

HOT – Beispiele

Beispiel (Beispieltabelle fur HOT)

CREATE TABLE hot_test (id INTEGER PRIMARY KEY, daten TEXT);

INSERT INTO hot_test (id, daten) VALUES (1, ’Datensatz’);

Beispiel (HOT – Ja)

UPDATE hot_test SET daten = ’etwas anderes’;

Beispiel (HOT – Nein)

UPDATE hot_test SET id = 2;



Autovacuum

VACUUM automatisiert

PostgreSQL besitzt einen eingebauten Daemon namensautovacuum

Dieser uberpruft regelmaßig alle Datenbanken und enthalteneTabellen

Die Zeit zwischen zwei Laufen wird mittelsautovacuum naptime eingestellt

Der Daemon selbst wird mittels autovacuum ein- undausgeschaltet

Einzelne Tabellen in einer Datenbank konnen uber diepg autovacuum Tabelle konfiguriert werden



Autovacuum

Konfiguration – kostenbasiertes VACUUM

vacuum cost delay: Anzahl Millisekunden fur die Ruhephasedes VACUUM-Befehls, 0 zum Deaktivieren (Default)

vacuum cost page hit: erwartete Kosten fur das VACUUMeines Blocks, der sich im Shared RAM befindet (1)

vacuum cost page miss: erwartete Kosten fur das VACUUMeines Blocks auf der Festplatte (10)

vacuum cost page dirty: erwartete Kosten, wenn ein vorhersauberer Block geschrieben werden muss (20)

vacuum cost limit: Kostenlimit fur eine Runde (200)



Autovacuum

Konfiguration – kostenbasiertes Auto-VACUUM

autovacuum und track counts mussen aktiviert sein

autovacuum max workers: Anzahl gleichzeitiger VACUUMProzesse (3)

autovacuum naptime: Zeit zwischen Beenden einer und demPrufen der nachsten Datenbank (1min)

autovacuum vacuum cost delay: Anzahl Millisekunden furdie Ruhepause. Der Wert -1 fuhrt zur Nutzung vonvacuum cost delay (20)

autovacuum vacuum cost limit: Kostenlimit fur eineRunde, wird uber alle aktiven Worker verteilt. -1 fuhrt zurNutzung von vacuum cost limit (-1)



Autovacuum

Konfiguration – kostenbasiertes Auto-VACUUM

autovacuum vacuum threshold: Anzahl der notwendigengeanderten Tuples fur VACUUM (50)

autovacuum analyze threshold: Anzahl der notwendigengeanderten Tuples fur ANALYZE (50)

autovacuum vacuum scale factor: Prozentwert uber dieTabellengroße, der zu autovacuum vacuum thresholdaddiert wird (0.2 – 20%)

autovacuum analyze scale factor: Prozentwert uber dieTabellengroße, der zu autovacuum analyze thresholdaddiert wird (0.1 – 10%)



Autovacuum

VACUUM – Ubung

Die Datenbank mittels VACUUM ANALYZE VERBOSE aufraumen

Auf die Ausgaben (am Ende) fur die Anzahl benotigterEintrage fur die Free-Space-Map achten

Hinweis: In PostgreSQL 8.4 sind die FSM Einstellungen entfallen.



Wichtiger Termin

Wichtiger Termin

FrOSCon 2010

21./22. August 2010

St. Augustin (bei Bonn)

Webseite: http://www.froscon.de/



Wichtiger Termin

Wichtiger Termin

PGDay 2010

irgendwann im 2. Halbjahr (wahrscheinlich Septemter)

irgendwo in den Niederlanden (wahrscheinlich Amsterdam)

Webseite: http://www.pgday.eu/



PostgreSQL Buch

PostgreSQL – Datenbankpraxisfur Anwender, Administratorenund Entwickler

Erschien im Juli 2009 imVerlag Open Source PressUmfang: ca. 520 Seiten



Ende

http://andreas.scherbaum.la/

Fragen?

Andreas ’ads’ Scherbaum <[email protected]>PostgreSQL User Group GermanyEuropean PostgreSQL User Group

PostgreSQL Service & Support


Documents

PostgreSQL optimieren · INFO: free space map contains 1368 pages in 117 relations DETAIL: A total of 2912 page slots are in use (including overh ead). 2912 page slots are required