Flash Cache Compression besser abschalten

,

Wer auf Exadata Flash Cache Compression eingeschaltet hat, sollte diese zunächst wieder abschalten. In einer eMail von gestern Abend empfiehlt Oracle mit Verweis auf MOS Doc ID 2115005.1: „(EX28) High risk of data loss on X3 or X4 Exadata storage when flash compression is enabled and running late 2015 or early 2016 software release „, auf allen Exadata Systeme in Version 12.1.2.3.0 die Flash Cache Compression abzuschalten. Für Versionen 12.1.2.2.1 und 12.1.2.2.0 lautet die Empfehlung, den Patch 22917774 bzw. 22928622 einzuspielen. Für ältere Systeme wird ein Upgrade empfohlen.

Hintergrund ist Bug 22909764:

Due to bug 22909764, on X4 and X3 storage servers (with X4-2, X4-8, X3-2, and X3-8 Exadata Database Machines) running Exadata 12.1.2.2.0, 12.1.2.2.1, or 12.1.2.3.0, when Exadata Smart Flash Cache Compression is enabled, one or more flash drives may fail on multiple storage servers, leading to a potential for data loss if flash cache is configured write-back, or reduced performance if flash cache is configured write-through.

Die in der MOS Note verlinkte Bug Note ist nicht öffentlich zugreifbar.

Exadata Flash Cache Compression wurde mit Exadata Storage Server Software 11.2.3.3.0 eingeführt. Sie erhöht die Kapazität, verringert die IO-Raten und arbeitet transparent. Voraussetzung für die Verwendung ist ein Exadata Storage Server X3, und der Einsatz erfordert die Advanced Compression Option.

/von

SMU 1.3.0

Das Oracle Snap Management Utility (SMU) für die Administration von Snapshots und Klonen auf der ZFS Storage Appliance ist in der Version 1.3 erschienen. Damit können nun auch 12c Container-Datenbanken verwendet werden.

Neben der Unterstützung von Snap Cloning für Multitenant Databases bringt die neue Version weitere Features mit:

  • Clone Copy (Binärkopie der Quelldatenbank)
  • Standby Clone (Einrichtung von Data Guard aus einem Klon)
  • Incomplete Recovery (Point in Time Recovery einer Datenbank auf einen Zeitpunkt oder eine SCN zwischen zwei Snapshot Backups)
  • Refresh Clone (Ein Klon muss für einen Refresh nicht mehr neu angelegt werden)

Die Release Notes finden sich hier.

/von

Probleme mit dem Snapshop Management Utility

,

In einem Kundenprojekt werden Test- und Entwicklungs-Datenbanken vorbereitet, indem ein Backup der Produktion auf einem ZFS Appliance Cluster geklont wird. Auf diese Weise können schnell und ohne überflüssigen Platzverbrauch neue Datenbanken erzeugt werden.

Das Klonen eines ZFS Shares (datasets) selbst erfordert keine spezielle Vorbereitung und ist mit einem Klick in der Appliance GUI beziehungsweise einem CLI-Befehl erledigt. Soll allerdings eine ganze Datenbank geklont werden, ist etwas mehr Umsicht erforderlich, denn die Klone aller ZFS Shares, auf denen Datafiles der Datenbank liegen, müssen zusammenhängend ausgeführt werden, und es muss sichergestellt werden, das kein Share, auf dem Dateien der Datenbank liegen, vergessen wird. Außerdem müssen bei Online Backups die Archive Redo Files separat geklont werden. Und beim De-kommissionieren einer Datenbank muss geprüft werden, welche Klone aufgelöst werden können.

Um all dies zu berücksichtigen, ohne sich die Finger wund zu skripten, hat Oracle das Snapshop Management Utility (SMU) entwickelt. In der GUI lassen sich alle Datenbanken, die verwaltet werden sollen, sowie alle Storage Server, die verwendet werden, eintragen, und dann lässt sich jede Datenbank wahlweise online oder offline mit einem Befehl per Snapshot sichern und auch klonen. Es steht sowohl eine Web GUI als auch ein Command Line Interface (CLI) zur Verfügung.

Ein feine Sache, die viel eigenen Entwicklungsaufwand sparen kann, und ein Produkt mit Oracle Support. Unser Kunde plant, das SMU in das eigene Skript-Framework inkl. der lokalen Vor- und Nachbereitungen bei der Erstellung von Testumgebungen einzubauen und per CLI aufzurufen.

In der letzten SMU-Version 1.1 liefen die Tests vielversprechend, aber eine Sache fehlte noch: SMU konnte nur Datenbanken verwalten, deren Datafiles auf einem einzigen Kopf eines ZFS-Appliance-Clusters liegen. Hat man eine ZFS Cluster, wird man seine größeren Datenbanken aber selten nur auf einem Kopf belassen. Stattdessen wird man in der Regel versuchen, die Datafiles auf beide Köpfe zu verteilen, um die Bandbreite beider Köpfe zu nutzen und so die Gesamtperformance zu erhöhen.

Daher war die Freude groß, als es im README zur Version 1.2 hieß:

„Important: Previously, all of the database shares had to reside with one head of a clustered Oracle ZFS Storage system. With the Snap Management Utility 1.2 release, this is no longer a requirement. Shares can span both heads of a clustered appliance.“

Leider ist es aber nicht möglich, diese Funktionalität auch zu nutzen. Auch nur der Versuch, mit dem SMU 1.2 ein Offline-Backup einer Datenbank, deren Datendateien sich über beide Köpfe eines Clusters erstrecken, auszuführen, führt zum Fehler:

„The number of remote shares is greater than the number of shares to backup.“

Für dieses Problem haben wir im Dezember 2014 einen Oracle Service Request eröffnet, der mittlerweile zu einem Bug (20469398) geführt hat. Das bisherige Fazit ist aber leider: SMU ist für größere Installationen, die an Performance interessiert sind, nicht zu verwenden.

/von