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.