PostgreSQL optimieren

Transkript

1 CLT Web: andreas[at]scherbaum.biz PGP: 9F67 73D3 43AA B30E CA8F 56E D B5FE

2 Was ist PostgreSQL? Relationale Datenbank unter BSD Lizenz Weltweit aktive Community Zahlreiche Features und Funktionen (Foreign Keys, Transaktionen, Trigger) Läuft auf zahlreichen Betriebssystemen und diverser Hardware Weitgehendes Einhalten der SQL-Standards Dokumentation der Abweichungen Im Schnitt pro Jahr ein Minor-Release mit neuen Features Version 9.0 wird derzeit fleißig entwickelt Der Dozent Der Dozent Name: Andreas Scherbaum Selbstständig im Bereich Datenbanken, Linux auf Kleingeräten, Entwicklung von Webanwendungen Arbeit mit Datenbanken seit 1997, mit PostgreSQL seit 1998 oder 1999 Gründungsmitglied der Deutschen und der Europäischen PostgreSQL User Group Board of Directors European PostgreSQL User Group

3 .la Was bedeutet dieses komische.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 längere Zeit gewohnt und meine Frau fand die Domain schön Ziele dieses Workshops Ziele dieses Workshops Konfiguration: (Installation,) Speichernutzung einstellen, Logdateien konfigurieren, Zugriff aus dem Netzwerk ermöglichen. der Planer und seine Statistiken Performance: grundlegende Details, Partitionierung, Tablespaces Analyse: von Anfragen, Auffinden langsamer Queries, Anfragepläne im 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?

4 Ziele dieses Workshops Skripts zum Workshops Konfiguration Konfiguration Übersicht Alle Konfigurationen für PostgreSQL werden in der Datei postgresql.conf vorgenommen Alle Einstellungen für Zugangsberechtigungen werden in der Datei pg hba.conf vorgenommen Nach Änderungen mittels pg ctl reload die Konfiguration neu laden Ein Neustart ist nur selten notwendig und ist in der Konfiguration vermerkt

5 Konfiguration Konfiguration Speichernutzung shared buffers: Verfügbarer Speicher für alle PostgreSQL Prozesse Ev. /etc/sysctl.conf anpassen (kernel.shmmax und kernel.shmall) work mem: Speicher für Sortieroperationen und Hashing Tabellen maintenance work mem: Speicher für VACUUM und ANALYZE temp buffers: Speicher für temporäre Tabellen Konfiguration Konfiguration Speichernutzung max fsm pages: bestimmt die Verwaltung von Disk Pages max fsm relations: bestimmt die Anzahl von Tabellen und Indizes VACUUM VERBOSE Ausgabe beachten Neu in PostgreSQL 8.4: FSM konfiguriert sich selbst max stack depth: Größe des nutzbaren Stacks (ulimit beachten)

6 Konfiguration Konfiguration Speichernutzung 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) page slots are required to track all free space. Current limits are: page slots, 1000 relations, using 965 kb Speicherseiten (a 8kB) und 117 Objekte verwendet Speicherseiten und 1000 Objekte kann die Datenbank verwalten kostet weniger als 1 MB RAM Konfiguration Konfiguration Logdateien log filename: Format für Logdateien in pg log (siehe strftime()) log rotation age: Logfiles nach Zeit rotieren log rotation size: Logfile nach Größe rotieren log error verbosity: PostgreSQL wird gesprächiger (verbose) log min error statement: minimaler Loglevel (Default: info)

7 Konfiguration Konfiguration Logdateien log min duration statement: Ausführungszeit von Anfragen loggen (Default: -1) bis 8.3: redirect stderr: leitet Ausgaben in eine Logdatei um ab 8.4: log destination: leitet Ausgaben in stderr, csvlog, syslog oder eventlog um ab 8.4: logging collector: aktiviert das Umleiten der Fehler 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 für den Admin + VACUUM

8 Konfiguration Konfiguration Netzwerk unix socket directory: Verzeichnis für den Unix-Domain-Socket unix socket group: Gruppenname für Domainsocket File unix socket permissions: Integer Wert für Zugriffsrechte auf Domainsocket File Konfiguration Shared Memory SHMMAX Maximale Größ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= Hinweis: SUSE/OpenSUSE und Red Hat nutzen bereits den gesamten Hauptspeicher als Shared Memory.

9 Konfiguration Shared Memory SHMMAX Berechnung Gesucht: Shared Memory mit einer Größe von 200 MB Beispiel (Berechnung von SHMMAX) 200 MB = 1024 Bytes * 1024 kb * 200 MB = aufgerundet: ( ) Konfiguration Konfiguration Übung PostgreSQL an alle Netzwerkinterfaces binden 42 maximale Verbindungen zulassen 1024 MB Shared Memory einstellen Speicher für Sortieroperationen auf 3 MB einstellen Logfiles täglich neu erstellen, der Wochentag erscheint im Dateinamen Anfragen mit einer Laufzeit über 5 Sekunden protokollieren

10 Konfiguration Konfiguration Lösung der Übung listen addresses = * max connections = 42 shared buffers = 1024MB kernel.shmmax und kernel.shmall anpassen work mem = 3MB log directory = /pfad/zum/verzeichnis (ggf. außerhalb des 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: ungefähre Größe des Caches im Betriebssystem geqo: Generic Query Optimizer ein- oder ausschalten

11 Konfiguration Konfiguration Planer seq page cost: Kosten für das Lesen eines Blocks während einer laufenden Leseoperation (1.0) random page cost: Kosten für das Lesen eines zufälligen Blocks (4.0) cpu tuple cost: Kosten für das Bearbeiten einer Zeile (row) (0.01) cpu index tuple cost: Kosten für das Bearbeiten eines Eintrags im Index (0.005) cpu operator cost: Kosten für den Aufruf eines Operators oder einer Funktion (0.0025) Konfiguration Konfiguration Statistiken track activities: in 8.3, aktiviere Statistiken für ausgeführte Befehle stats start collector: in 8.2, aktiviere Statistiken stats block level: in 8.2, aktiviere Statistiken für blockbasierte Operationen stats row level: in 8.2, aktiviere Staristiken für zeilenbasierte Operationen track counts: in 8.3, aktiviere Statistiken für Datenbankaktivitäten (Autovacuum)

12 Konfiguration Konfiguration Statistiken loggen log statement stats: Statistiken über den ausgeführten Befehl log parser stats: Statistiken über die Parser Operationen log planner stats: Statistiken über die Planer Operationen log executor stats: Statistiken über die effektiv ausgeführten Operationen Hinweis: log statement stats kann nicht zusammen mit einer anderen Option aktiviert werden Konfiguration Konfiguration Write Ahead Log (WAL) fsync: aktiviert oder deaktiviert synchrones Schreiben. off kann zu Datenverlusten und einer beschädigten Datenbank führen! synchronous commit: bei off wird nicht auf das Beenden des Schreibens gewartet. Datenverluste sind möglich, aber keine beschädigte Datenbank. wal buffers: Größe des Speicherbereichs zum Schreiben eines Eintrags in das WAL. checkpoint segments: Anzahl WAL-Logfiles, die rotiert werden

13 Gründe für schlechte Performance Die Möglichkeiten sind fast unbegrenzt... Falsche (oder gar fehlende) Konfiguration Anwendung stellt Anfragen falsch Datenbank Layout ist falsch oder ungenügend (fehlende Indizies, fehlende Normalisierung) Anwendungen fragen zu viele (unnötige) Daten ab (z.b.: SELECT *, fehlendes WHERE) Latenzzeiten (z.b. Netzwerk, Zugriffszeiten der Festplatten) Ungenügende Hardware... Ungenügende Hardware Performance Ungenügende Hardware Mehr RAM, mehr RAM, noch mehr RAM Daten die im Speicher vorgehalten werden, müssen nicht von der Platte gelesen werden Langsame Festplatten gegen schnellere ersetzen, ggf. ein RAID oder Tablespaces nutzen Es gilt: die Performance verbessert sich mit der Anzahl der Spindeln Schwachstellen im I/O-System herausfinden SSD-Platten in Betracht ziehen: sehr schnell beim Lesen, jedoch derzeit noch Probleme beim Schreiben

14 Performancesteigerung durch Hardware Performancesteigerung durch Hardware Soviel RAM wie notwendig: die wichtigen Tabellen/Daten sollen komplett im RAM liegen RAID kann Plattenzugriffe verteilen aber nur unabhängig von der tatsächlichen Nutzung Mittels Tablespaces kann man Zugriffe gezielt auf verschiedene Platten verteilen - z. B. Tabelle und Index auf zwei Spindeln legen Wenig genutzte Daten können auf langsame (und günstige) Datenträger ausgelagert werden Performancesteigerung durch Konfiguration Performance falsche Konfiguration Hinweis: die standardmäßige PostgreSQL Konfiguration ist auf geringen Ressourcenverbrauch ausgelegt. shared buffers zu gering FSM Free-Space-Map nicht angepasst Bei umfangreichen Operationen work mem erhöhen maintenance work mem kann mehr Speicher für VACUUM bereitstellen temp buffers: bei Überschreiten werden Daten auf die Festplatte ausgelagert

15 Performancesteigerung durch Konfiguration Performance Anwendung stellt Anfragen falsch Mittels log min duration statement langlaufende Anfragen ermitteln Anfragen mittels EXPLAIN und EXPLAIN ANALYZE überprüfen Gleiche Anfragen mittels Prepared Statement aufrufen: erspart den Parser Schritt Zahlreiche INSERT-Operationen mittels Prepared Statement oder besser COPY durchführen Performancesteigerung durch Konfiguration Performance Datenbank Layout ist falsch oder ungenügend Testweise prüfen, ob ein Index auf einer Spalte eine Verbesserung der Laufzeit bewirkt Wichtig: ANALYZE für die Tabelle nicht vergessen Tabellen normalisieren in der Regel ergeben sich dadurch für die Datenbank besser handhabbare Anfragen

16 Performancesteigerung durch Konfiguration Performance BG-Writer Der Background-Writer schreibt normalerweise verteilt über die halbe Zeit Parameter: checkpoint completion target (Default: 0.5) Bei kontinuierlicher Schreiblast Anpassung bis 0.9 sinnvoll Performancesteigerung durch Konfiguration Performance Transaktionen zusammenfassen commit delay verzögert abgeschlossene Transaktionen kurzzeitig (0 bis 10 Sekunden, Default: 0) Dadurch können mehrere Transaktionen in einem Durchgang geschrieben werden Nur ein sync() ist notwendig Wird ab commit siblings (Default: 5) offenen Transaktionen aktiviert

17 Performancesteigerung durch Konfiguration Performance größere Statistiken default statistics target legt die Anzahl der häufigsten Einträge in der Statistik fest Bis PostgreSQL 8.3: 10 Einträge Ab PostgreSQL 8.4: 100 Einträge Von 1 bis 1000 Einträge möglich Vorteil: die Datenbank kennt mehr häufig vorkommende Einträge und kann den Ausführungsplan anpassen Nachteil: kostet mehr Platz für die Statistiken Performancesteigerung durch Konfiguration Performance Prefetching Posix-Feature, ab PostgreSQL 8.4 vorhanden Gibt die voraussichtliche Anzahl paralleler Zugriffe bekannt Parameter: effective io concurrency (1 bis 1000, 0 deaktiviert das Feature, Default: 1)

18 Partitionierung Partitionierung Vorteile Daten werden ausgehend von der tatsächlichen Situation gespeichert Sequentielle Scans durchlaufen nicht den gesamten Datenbestand Bestimmte Verwaltungsarbeiten lassen sich effizient durchführen Daten können auf unterschiedliche Medien aufgeteilt werden Die Partitionierung kann anhand jedes beliebigen Kriteriums erfolgen solange dieses voraussagbar ist Partitionierung Partitionierung bei PostgreSQL Tabellen werden durch Inheritance (Vererbung) von einer Mastertabelle 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!

19 Partitionierung Partitionierung bei PostgreSQL Beispiel (Abgeleitete Tabellen erstellen) CREATE TABLE log_data_ ( ) INHERITS (log_data); CREATE TABLE log_data_ ( ) INHERITS (log_data); INSERT INTO log_data_ (insert_at, data) VALUES ( , data set 42 ); INSERT INTO log_data_ (insert_at, data) VALUES ( , data set 23 ); Partitionierung Partitionierung bei PostgreSQL Beispiel (Daten in Tabelle ) SELECT * FROM log_data_200901; id insert_at data :00:00+01 data set 23 (1 Zeile) Beispiel (Daten in Tabelle ) SELECT * FROM log_data_200902; id insert_at data :00:00+01 data set 42 (1 Zeile)

20 Partitionierung Partitionierung bei PostgreSQL Beispiel (Daten in Master Tabelle) SELECT * FROM log_data; id insert_at data :00:00+01 data set :00:00+01 data set 42 (2 Zeilen) Partitionierung Korrekte Timestamps erzwingen Beispiel (Abgeleitete Tabellen mit CONSTRAINTs erstellen) CREATE TABLE log_data_ ( ) INHERITS (log_data); CREATE TABLE log_data_ ( CHECK (insert_at >= DATE AND insert_at < DATE ) ) INHERITS (log_data);

21 Partitionierung Nutzung des Timestamp bei einer Anfrage Wenn PostgreSQL einen Contraint auf der vererbten Tabelle vorfindet, wird dieser dazu genutzt, die komplette Tabelle gf. aus der Abfrage auszuschließen Hinweis: Alle abgeleiteten Tabellen wurden neu mit Constraints erstellt. Beispiel (CONSTRAINTs nutzen) -- bis PostgreSQL Version 8.3: SET constraint_exclusion = on; EXPLAIN SELECT * FROM log_data WHERE insert_at= ; Partitionierung Nutzung des Timestamp bei einer Anfrage Beispiel (CONSTRAINTs in einer Anfrage nutzen) EXPLAIN SELECT * FROM log_data WHERE insert_at= ; QUERY PLAN Result (...) -> Append (...) -> Seq Scan on log_data (...) Filter: (insert_at = :00:00 ::timestamp without time zone) (4 Zeilen)

22 Partitionierung Nutzung des Timestamp bei einer Anfrage Beispiel (CONSTRAINTs in einer Anfrage nutzen) EXPLAIN SELECT * FROM log_data WHERE insert_at= ; QUERY PLAN Result (...) -> Append (cost= rows=4 width=230) -> Seq Scan on log_data (...) Filter: (insert_at = :00:00 ::timestamp without time zone) -> Seq Scan on log_data_ log_data () Filter: (insert_at = :00:00 ::timestamp without time zone) (6 Zeilen) Partitionierung Partitionierung Nachteile und Wartung Der partitionierte Schlüssel muss in den (meisten) Anfragen verwendet werden Andernfalls kann PostgreSQL nicht herausfinden, welche Tabellen ein- oder auszuschließen sind Daten müssen entweder in die partitionierte Tabelle eingefügt oder mittels Trigger/Rules von der Master Tabelle umgeleitet werden Das Löschen alter Daten geht schnell: nur die entspechende Tabelle löschen Hinweis: Rules müssen entfernt bzw. Trigger umgeschrieben werden

23 Partitionierung Partitionierung Übung Eigene partitionierte Tabellen erstellen Testdaten erstellen Daten aus partitionierten Tabellen und der Mastertabelle auslesen Tablespaces Tablespaces Vorteile gegenüber RAID Tabellen und Indexes können gezielt (und getrennt) auf verschiedene Datenträger verteilt werden Verschiedene Datenbanken oder Tabellen können sich auf verschieden schnellen Datenträgern befinden

24 Tablespaces Tablespace erstellen Beispiel (Tablespace anlegen) CREATE TABLESPACE ts_neu LOCATION /mnt/db_neu ; Der Name des Tablespace muss eindeutig sein und darf bisher nicht vergeben sein Das Verzeichnis /mnt/db neu muss postgres gehören und leer sein, der absolute Pfad wird verlangt Tablespaces können nur von einem Admin angelegt werden Das Zuweisen an einen anderen User ist möglich (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 nachträgliche Zuweisung zu einem anderen Tablespace ist möglich: Beispiel (Index nachträglich verschieben) ALTER INDEX test1_index SET TABLESPACE ts_neu;

25 Tablespaces Tablespace per Datenbank angeben Eine Datenbank kann komplett auf einem anderen Tablespace erzeugt werden: Beispiel (Tablespace für Datenbank angeben) CREATE DATABASE neue_db TABLESPACE = ts_neu; Der Default Tablespace für neue Objekte lässt sich ändern: Beispiel (Default Tablespace ändern) SET default_tablespace = ts_neu; Tablespaces Neu in PostgreSQL 8.4! Eine ganze Datenbank kann nachträglich auf einen anderen Tablespace umgezogen werden: Beispiel (Datenbank auf anderen Tablespace umziehen) ALTER DATABASE neue_db SET TABLESPACE ts_neu;

26 Tablespaces Tablespaces Übung 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...

27 Analyse von Anfragen Analyse von Anfragen Wie EXPLAIN: liefert den Queryplan für eine Anfrage EXPLAIN ANALYZE: führt die Anfrage zusätzlich aus und misst die Laufzeiten Analyse von Anfragen Analyse von Anfragen Übung Die pg tables Tabelle mit EXPLAIN und EXPLAIN ANALYZE analysieren Bonus: Verwendung von Indexes erzwingen und die Analyse wiederholen

28 Analyse von Anfragen Analyse von Anfragen Lösung 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 einen Queryplan übersetzt Zu einzelnen Teilen der Anfrage werden statistische Informationen aus den Tabellen geholt Aufgrund dieser Informationen wird entschieden, ob z.b. ein Index genutzt wird Der Planer kann ggf. Anfragen intern umschreiben (JOINs auflösen, RULEs anwenden) Der Datentyp spielt ebenfalls eine Rolle

29 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 ); INSERT INTO planer_test (inhalt) VALUES ( Inhalt 002 ); INSERT INTO planer_test (inhalt) VALUES ( Inhalt 003 ); INSERT INTO planer_test (inhalt) VALUES ( Inhalt 004 ); INSERT INTO planer_test (inhalt) VALUES ( Inhalt 005 ); Beispiel (Statistiken up to date) VACUUM ANALYZE VERBOSE planer_test; Der Planer Analyse von Anfragen Beispiel (EXPLAIN Ausgabe) postgres=# EXPLAIN SELECT id, inhalt FROM planer_test WHERE id=1; QUERY PLAN Seq Scan on planer_test (cost= rows=1 width=18) Filter: (id = 1) (2 Zeilen)

30 Der Planer Analyse von Anfragen Seq Scan on planer test (cost= rows=1 width=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 Analyse von Anfragen Frage: Warum ein sequentieller Scan, wenn wir doch einen Index auf id haben? Erzwingen wir die Nutzung des Index: SET enable seqscan=0; Einschätzung: Was wird passieren?

31 Der Planer Analyse von Anfragen 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= 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 Block danach sowieso gelesen werden Resultat: Kosten 3 Der Planer Analyse von Anfragen Erkentnisse PostgreSQL erstellt jeden Queryplan dynamisch und abhängig vom Zustand der Daten Zwei Anfragen auf die gleiche Tabelle, bei unterschiedlichen Datenmengen, können anders ausgeführt werden Daraus resultiert: PostgreSQL sollte gute Informationen über die Daten in den Tabellen haben Das wichtigste Hilfsmittel ist ANALYZE (bzw. VACUUM ANALYZE) Der Autovacuum Daemon übernimmt die meiste Arbeit

32 Der Planer Analyse von Anfragen Ausführungszeit messen Beispiel (EXPLAIN ANALYZE Ausgabe) postgres=# EXPLAIN ANALYZE SELECT id FROM planer_test WHERE id=1; QUERY PLAN Seq Scan on planer_test Filter: (id = 1) Total runtime: ms (3 Zeilen) (cost= rows=1 width=4) (actual time= rows=1 loops=1) EXPLAIN ANALYZE führt die Anfrage aus und misst die Zeit Die gemessenen Zeiten bewegen sich innerhalb der vorab geschätzten Werte Sollte es hier grobe Abweichungen geben, hat der Planer falsche Daten! Vorsicht: Es werden Daten verändert! Der Planer Analyse von Anfragen Negativbeispiel Beispiel (EXPLAIN ANALYZE Ausgabe) postgres=# EXPLAIN ANALYZE SELECT id FROM planer_test WHERE id=10; QUERY PLAN Seq Scan on planer_test Filter: (id = 10) Total runtime: ms (3 Zeilen) (cost= rows=1 width=4) (actual time= rows=0 loops=1) Eine sequentielle Suche nach einem nicht vorhandenen Wert Die Datenbank muss die gesamte Tabelle lesen (minimal gleich 0.022) Ein Index hätte hier womöglich schneller Auskunft gegeben

33 Der Planer Analyse von Anfragen größ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, ), RANDOM(); Beispiel (Statistiken up to date) VACUUM ANALYZE VERBOSE planer_test2; Der Planer Analyse von Anfragen größere Tabelle 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= rows=1 width=12) Index Cond: (id = ) (2 Zeilen)

34 Der Planer Analyse von Anfragen größere Tabelle 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= rows=1 width=12) (actual time= rows=1 loops=1) Index Cond: (id = ) Total runtime: ms (3 Zeilen) Der Planer Analyse von Anfragen größere Tabelle Beispiel (Nutzung der Indicies verbieten) SET enable_indexscan = off; SET enable_bitmapscan = off;

35 Der Planer Analyse von Anfragen größere Tabelle Beispiel (Laufzeit messen) postgres=# EXPLAIN ANALYZE SELECT id, inhalt FROM planer_test2 WHERE id=800000; QUERY PLAN Seq Scan on planer_test2 (cost= rows=1 width=12) (actual time= rows=1 loops=1) Filter: (id = ) Total runtime: ms (3 Zeilen) Transaktionen? Transaktionen Transaktionen kapseln beliebig viele Aktionen in der Datenbank zu einer einzelnen Aktion nach außen Beispiel: Banküberweisung 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 Fehler auftritt?

36 Transaktionen? Transaktionen ACID A C I D A: Atomarität (Atomicity) ganz oder gar nicht C: Konsistenz (Consistency) Datenbestand ist vor und nach der Transaktion konsistent I: Isolation (Isolation) alle Aktionen (Transaktionen) sind voneinander abgekapselt D: Dauerhaftigkeit (Durability) bestätigte Änderungen bleiben erhalten Wie werden Transaktionen genutzt? Transaktionen nutzen Beispiel (Transaktion starten) BEGIN; START TRANSACTION; Beispiel (Transaktion abschließen) COMMIT; Beispiel (Transaktion zurückrollen) ROLLBACK; Hinweis: PHP bietet keine eingebauten Funktionen für Transaktionen Perl DBI kennt begin work(), commit() und rollback()

37 Isolation von Transaktionen Isolation von Transaktionen Beispiel: Transaktion 1 startet mit eigener aktueller Ansicht der Datenbank (I Isolation) Transaktion 2 startet Transaktion 2 ändert einen Wert in einer Tabelle Transaktion 2 committed ihre Änderungen, diese werden sichtbar Aber: Transaktion 1 muss weiterhin den alten Wert sehen können, da dieser beim Start der Transaktion gültig war Isolation von Transaktionen Isolation von Transaktionen Übung Zwei Verbindungen zur Datenbank öffnen Eine Tabelle erstellen In beiden Verbindungen eine Transaktion starten Den Inhalt der Tabelle in beiden Verbindungen anzeigen lassen In einer Transaktion einen Datensatz einfügen Den Inhalt der Tabelle in beiden Verbindungen anzeigen lassen

38 Isolation von Transaktionen Isolation von Transaktionen Übung Beispiel (Beispieltabelle erstellen) CREATE TABLE transaktion_test ( id SERIAL NOT NULL PRIMARY KEY, wert VARCHAR NOT NULL ); Isolation von Transaktionen Isolation von Transaktionen Übung Beispiel (Beispiel) T1: BEGIN; T2: BEGIN; T1: SELECT * FROM transaktion_test; T2: SELECT * FROM transaktion_test; T1: INSERT INTO transaktion_test (wert) VALUES ( etwas Inhalt ); T1: SELECT * FROM transaktion_test; T2: SELECT * FROM transaktion_test; T1: COMMIT; T1: SELECT * FROM transaktion_test; T2: SELECT * FROM transaktion_test; T2: COMMIT;

39 Isolation von Transaktionen Isolation von Transaktionen Übung Beispiel (Beispiel) T1: BEGIN; T2: BEGIN; T1: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; T2: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; -- Übung von vorheriger Folie ab SELECT... wiederholen Isolation von Transaktionen Isolation von Transaktionen die Nachteile Das notwendige Vorhalten älterer Versionen eines Datensatzes wird Multiversion Concurrency Control (kurz: MVCC) genannt Diese alten Versionen belegen Platz auf der Festplatte und im Index Diese Überreste können mit dem Befehl VACUUM aufgeräumt werden, Syntax: Beispiel (VACUUM für eine Tabelle aufrufen) VACUUM ANALYZE tabelle; Hinweis: VACUUM kann nicht innerhalb einer Transaktion aufgerufen werden

40 Isolation von Transaktionen Isolation von Transaktionen mögliche Probleme Innerhalb von Transaktionen kann es zu vielfältigen Problemen kommen: Dirty Read: Andere Transaktionen können Daten der aktuellen Transaktion lesen, obwohl die Änderungen noch nicht committed wurden Non-Repeatable Read: Bei mehrfachen, gleichen Lesezugriffen innerhalb einer Transaktion gibt es unterschiedliche Ergebnisse Phantom Read: Durch Einfügen, Ändern oder Löschen gibt es in anderen Transaktionen bei gleichen Bedingungen unterschiedliche Ergebnisse Isolation von Transaktionen Isolation von Transaktionen Transaktionslevel SQL definiert 4 verschiedene Transaktionslevel: READ UNCOMMITTED: Änderungen innerhalb einer Transaktion sind von außerhalb zu sehen (in PG: READ COMMITTED) READ COMMITTED: Änderungen sind nur nach einem COMMIT zu sehen REPEATABLE READ: Die Datenbank merkt sich den Zeitpunkt des ersten Lesens eines Datensatzes, dies trifft jedoch nicht auf zwischenzeitlich eingefügte Datensätze zu (in PG: SERIALIZABLE) SERIALIZABLE: Die Transaktionen sind völlig gekapselt PostgreSQL nutzt nur READ COMMITTED und SERIALIZABLE

41 Isolation von Transaktionen Isolation von Transaktionen Probleme und Isolationslevel Level Dirty Read Non-Repeatable Read Phantom Read Read Uncommitted Möglich Möglich Möglich Read Committed Unmöglich Möglich Möglich Repeatable Read Unmöglich Unmöglich Möglich Serializable Unmöglich Unmöglich Unmöglich Isolation von Transaktionen Isolation von Transaktionen Transaktionslevel Unterschiede zwischen READ COMMITTED und SERIALIZABLE: READ COMMITTED: Daten, die vor dem Beginn des Query, aber nach Beginn der Transaktion sichtbar waren, werden angezeigt SERIALIZABLE: Nur Daten, die vor Beginn der Transaktion sichtbar waren, werden angezeigt Hinweis: bei SERIALIZABLE kann es zu Transaktionsabbrüchen kommen, die Applikation muss dies abfangen!

42 Isolation von Transaktionen Isolation von Transaktionen Transaktionslevel PostgreSQL Default: READ COMMITTED Ändern mit: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE Befehl muss nach START TRANSACTION/BEGIN aufgerufen werden Die Einstellung kann nach der ersten Daten-ändernden Anweisung (inkl. SELECT) nicht mehr geändert werden Isolation von Transaktionen Transaktionen Savepoints Ein Savepoint ist ein Punkt innerhalb einer Transaktion, bis zu dem zurückgerollt werden kann Mehrere Savepoints sind möglich Savepoints sind nur in einer Transaktion möglich Ein ROLLBACK zerstört auch alle späteren Savepoints

43 Isolation von Transaktionen Transaktionen Savepoints Beispiel (Savepoint erstellen) SAVEPOINT bis_hierhin; Beispiel (Zu einem Savepoint zurückkehren) ROLLBACK TO bis_hierhin; Beispiel (Einen Savepoint freigeben) RELEASE SAVEPOINT bis_hierhin; Isolation von Transaktionen Transaktionen Savepoints Übung Eine Transaktion starten Einen Savepoint erstellen Eine Tabelle löschen Zum Savepoint zurückkehren

44 Information Schema information schema Das Information Schema stellt einen standardisierten Weg bereit, Informationen über die Struktur der Datenbank auszulesen Dazu gibt es Views im Schema information schema Z.B. Tabellen, Spalten, Views, User, Sequencen, Trigger, Privilegien u.v.m. Information Schema information schema tables: Enthält Tabellen und Views columns: Enthält alle Spalten jeder Tabelle schemata: Enthält alle Schemata routines: Enthält alle Funktionen sql features: Unterstützte (oder nicht unterstützte) SQL Funktionalitäten

45 Information Schema information schema Übung 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> ;

46 Systemtabellen pg * Systemtabellen Nicht SQL-konform, eine PostgreSQL-Erweiterung Seit vielen Versionen vorhanden Struktur kann sich verändern Wesentlich weitreichendere Informationen als im information schema Änderungen können die Datenbank unbrauchbar werden lassen! Systemtabellen pg * Systemtabellen pg tables: Listet alle Tabellen auf pg views: Listet alle Views auf pg attribute: Enthält Informationen über alle Tabellenspalten pg namespace: Enthält Schemata pg proc: Enthält Funktionen pg statistics: Enthält Planer Statistiken pg stat * und pg statio *: Views mit aufbereiteten Statistikdaten...

47 Systemtabellen pg * Systemtabellen Übung Herausfinden wie man alle Spalten einer Tabelle anzeigen kann Systemtabellen pg * Systemtabellen Lösung Beispiel (Alle Spalten einer Tabelle) psql mit den Optionen -ee starten \d <tabelle> Ausgabe des Queries nutzen

48 Was ist VACUUM? VACUUM ein Staubsauger? Durch MVCC bleiben alte Daten nach Abschluss einer Transaktion in einer Tabelle zurück VACUUM gibt diesen Platz wieder frei ANALYZE aktualisiert die Statistiken für den Planer Shortcut: VACUUM ANALYZE Der Autovacuum Daemon kann die Arbeit automatisiert erledigen Neu in PG 8.3: HOT Heap-Only-Tuples quasi ein kleines Vacuum innerhalb des Blocks Voraussetzung: kein Wert im Index wird geändert Was ist VACUUM? HOT Beispiele Beispiel (Beispieltabelle für 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;

49 Autovacuum VACUUM automatisiert PostgreSQL besitzt einen eingebauten Daemon namens autovacuum Dieser überprüft regelmäßig alle Datenbanken und enthaltene Tabellen Die Zeit zwischen zwei Läufen wird mittels autovacuum naptime eingestellt Der Daemon selbst wird mittels autovacuum ein- und ausgeschaltet Einzelne Tabellen in einer Datenbank können über die pg autovacuum Tabelle konfiguriert werden Autovacuum Konfiguration kostenbasiertes VACUUM vacuum cost delay: Anzahl Millisekunden für die Ruhephase des VACUUM-Befehls, 0 zum Deaktivieren (Default) vacuum cost page hit: erwartete Kosten für das VACUUM eines Blocks, der sich im Shared RAM befindet (1) vacuum cost page miss: erwartete Kosten für das VACUUM eines Blocks auf der Festplatte (10) vacuum cost page dirty: erwartete Kosten, wenn ein vorher sauberer Block geschrieben werden muss (20) vacuum cost limit: Kostenlimit für eine Runde (200)

50 Autovacuum Konfiguration kostenbasiertes Auto-VACUUM autovacuum und track counts müssen aktiviert sein autovacuum max workers: Anzahl gleichzeitiger VACUUM Prozesse (3) autovacuum naptime: Zeit zwischen Beenden einer und dem Prüfen der nächsten Datenbank (1min) autovacuum vacuum cost delay: Anzahl Millisekunden für die Ruhepause. Der Wert -1 führt zur Nutzung von vacuum cost delay (20) autovacuum vacuum cost limit: Kostenlimit für eine Runde, wird über alle aktiven Worker verteilt. -1 führt zur Nutzung von vacuum cost limit (-1) Autovacuum Konfiguration kostenbasiertes Auto-VACUUM autovacuum vacuum threshold: Anzahl der notwendigen geänderten Tuples für VACUUM (50) autovacuum analyze threshold: Anzahl der notwendigen geänderten Tuples für ANALYZE (50) autovacuum vacuum scale factor: Prozentwert über die Tabellengröße, der zu autovacuum vacuum threshold addiert wird (0.2 20%) autovacuum analyze scale factor: Prozentwert über die Tabellengröße, der zu autovacuum analyze threshold addiert wird (0.1 10%)

51 Autovacuum VACUUM Übung Die Datenbank mittels VACUUM ANALYZE VERBOSE aufräumen Auf die Ausgaben (am Ende) für die Anzahl benötigter Einträge für die Free-Space-Map achten Hinweis: In PostgreSQL 8.4 sind die FSM Einstellungen entfallen. Wichtiger Termin Wichtiger Termin FrOSCon /22. August 2010 St. Augustin (bei Bonn) Webseite:

52 Wichtiger Termin Wichtiger Termin PGDay 2010 irgendwann im 2. Halbjahr (wahrscheinlich Septemter) irgendwo in den Niederlanden (wahrscheinlich Amsterdam) Webseite: PostgreSQL Buch PostgreSQL Datenbankpraxis für Anwender, Administratoren und Entwickler Erschien im Juli 2009 im Verlag Open Source Press Umfang: ca. 520 Seiten

53 Ende Fragen? PostgreSQL User Group Germany European PostgreSQL User Group PostgreSQL Service & Support