ADMIN 03/14 stellt Erste-Hilfe-Tipps zu Windows-Rettung, Backup und Recovery bei Datenbanken vor und verrät wie man Linux-Systeme vollständig sichert und ... (mehr)

Monitoring hilft

Erste Ansätze bietet ein genaues I/O- und CPU-Load-Monitoring des Servers, wobei man hier die aktuellen Werte mit den Werten des zuvor vorhandenen Setups vergleichen sollte. Bestenfalls kann man sogar auf ein Test-Setup zurückgreifen, das produktionsnahe Situationen simulieren oder reproduzieren kann. Auch Unit-Tests der Applikationen, die die Datenbank verwenden, und Tools zum Testen der Datenbank an sich – wie PgTAP [19] – sind oft sehr wertvoll, sofern sie gefahrlos auf ein Produktionssystem angewendet werden können. Automatisiertes Monitoring der Datenbanklogs (wie des Oracle Alert Log) sollte man generell nutzen und natürlich gerade in solchen Situationen genau beachten.

Zudem empfiehlt es sich unbedingt, nach jeder Wiederherstellung auch interne Statistiken der Datenbank zu überprüfen und gegebenenfalls zu aktualisieren. Sie werden oft für Query-Planer verwendet, um den effizientesten Weg für die Ausführung eines Statements zu kalkulieren. Via PL/PGSQL-Packages bei Oracle (»DBMS_STATS« ) oder etwa »ANALYZE« bei PostgreSQL lassen sich interne Informationen zu Tabellen und Indizes neu sammeln und Statistiken auf den neuesten Stand bringen.

Zusätzlich zu Query-Plänen sollten auch durchschnittliche Query-Laufzeiten genauer unter die Lupe genommen werden (»EXPLAIN« , »EXPLAIN PLAN« und ähnliche Kommandos), denn es könnte durchaus der Fall sein, dass sich hier etwas geändert hat. Verliert beispielsweise ein Index oder eine Tabelle nach dem Wiederherstellen etwas an Größe (Bloat), so kann es durchaus sein, dass der Query-Planer einen anderen Weg vorschlägt und lieber einen anderen Index in Betracht zieht oder sogar dazu tendiert, stattdessen gleich die gesamte Tabelle zu lesen. Das kann sich gravierend auf die Laufzeiten auswirken. Je komplexer die Query, umso eher kann sich die Ausführung ändern.

Datenbank-Tools, die Statistiken über Query-Laufzeiten und/oder -Pläne führen, können hierbei sehr hilfreich sein. Bei manchen Datenbanken sind sie von Haus aus integriert. Oracle bietet beispielsweisde diverse Tools, um SQL-Pläne zu managen [20]. Auch PostgreSQL liefert zusätzliche Informationen über Query-Laufzeiten (»pg_stat_statements« [21]) und -Pläne [22] via Extensions. Letztendlich darf man auch nicht vergessen, dass neu aufgesetzte Systeme eine gewisse Anlaufzeit brauchen, um wieder warm zu werden. So kann es durchaus etwas dauern, bis alle heißen Daten wieder im RAM gelandet sind.

Zusammenfassend lässt sich nur sagen: Umso öfter Backups wiederhergestellt und getestet werden, desto kleiner ist das Risiko einer ungeplanten Downtime.

Infos

  1. PostgreSQL: http://www.postgresql.org
  2. Oracle: http://www.oracle.com/technetwork/database/features/availability/rman-overview-096633.html
  3. Pacemaker: http://clusterlabs.org
  4. Corosync: http://corosync.github.io/corosync
  5. RAC: http://www.oracle.com/us/products/database/options/real-application-clusters/overview/index.html
  6. Oracle Active Data Guard: http://www.oracle.com/technetwork/database/features/availability/dataguardoverview-083155.html
  7. PostgreSQL-HA: http://www.postgresql.org/docs/current/static/high-availability.html
  8. PgBouncer: http://pgfoundry.org/projects/pgbouncer
  9. Pgpool-II: http://www.pgpool.net)
  10. Bucardo: http://bucardo.org/wiki/Bucardo
  11. Postgres-XC: http://sourceforge.net/projects/postgres-xc
  12. MySQL-Replication: http://www.mysql.com/products/enterprise/replication.html
  13. MySQL-Cluster: http://dev.mysql.com/doc/index-cluster.html
  14. Tungsten Replicator: https://code.google.com/p/tungsten-replicator/
  15. Percona XtraDB Cluster: http://www.percona.com/software/percona-xtradb-cluster
  16. Pg_dumpall: http://www.postgresql.org/docs/current/static/app-pg-dumpall.html
  17. Etckeeper: https://github.com/joeyh/etckeeper
  18. Oracle-Backup verifizieren: http://docs.oracle.com/cd/B28359_01/backup.111/b28270/rcmvalid.htm
  19. PgTAP: http://pgtap.org/documentation.html
  20. Oracle-Ausführungspläne verwalten: http://docs.oracle.com/cd/B28359_01/server.111/b28274/optplanmgmt.htm
  21. Pg_statements: http://www.postgresql.org/docs/current/static/pgstatstatements.html
  22. Pg_stat_plans: https://github.com/2ndQuadrant/pg_stat_plans

Der Autor

Peter Strohmeier arbeitet als Datenbankadminis-trator für PostgreSQL bei der 25th-floor de Pretis & Helmberger KG, einem seit 2004 existierenden Full-Service-Dienstleister für komplexe IT-Lösungen basierend auf Open-Source-Technologien mit Sitz in der österreichischen Hauptstadt Wien.

Ähnliche Artikel

comments powered by Disqus
Mehr zum Thema

Asynchrone Replikation in PostgreSQL 9

Nachdem das PostgreSQL Core Team Replikation lange für eine Angelegenheit von Drittanbietern hielt, entschloss es sich im Jahr 2008, dem Wunsch vieler Anwender zu folgen und eine Replikationslösung zu integrieren, die schließlich in PostgreSQL 9 Teil der Datenbank wurde.

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019