Performance Probleme mit der Oracle ZFS Appliance

, , , , ,

Für das Data Warehouse eines unserer Projektkunden, eines großen Telekommunikationsversorgers, hat dieser eine Oracle ZFS Appliance angeschafft und per Infiniband direkt mit seinen Exadata-Produktionssystemen verbunden, um ein schnelles Datensicherungs-Medium zu gewinnen, mit dem auch unkompliziert neue Test- und Entwicklungs-Umgebungen erzeugt werden können.

Die ZFS Storage Appliance (ZA) kann, wie jedes moderne Storage-System, Snapshots erzeugen, ohne nennenswert Zeit mit dem Kopieren der Daten zu verbringen. Diese können als Klone auch zum Schreiben geöffnet werden und so als Grundlage für neue Datenbanken dienen. Waren die Entwicklungsdatenbanken bisher stark veraltet, da das Erstellen aus der Produktion viel Zeit und Speicherplatz brauchte, können diese nun spontan geklont und auch einmal auf Zuruf in den Ausgangsstand zurückgesetzt werden. Die dafür notwendigen Schritte auf der ZA werden durch ein Oracle Tool namens Snapshot Management Utility (SMU) erleichtert, der den kompletten Prozess des Klonens inklusive dem notwendigen Recovery der Datenbanken dirigiert. Die Datenbanken werden dann mittels RMAN BACKUP AS COPY als inkrementelles Backup auf den NFS-Share der ZA  gesichert, wo sie als Datafiles vorliegen und nach einem Recovery geöffnet werden können.

Zunächst wurden auf der ZFS Appliance die entsprechenden Projekte und Shares angelegt. Wir haben einen ZA Cluster verwendet, der aus zwei Köpfen besteht, die jeweils alle Platten sehen, aber nur die ihnen zugewiesenen verwenden. In jedem Kopf sind Solid State Disks (SSDs) als Schreib-Cache (ZIL) verbaut. Fällt ein Kopf aus, kann der jeweils andere seine Platten übernehmen. Dieser Vorgang dauert übrigens tatsächlich einige Zeit, hinzu kommt, dass die Caches, wie nach jedem Neustart eines Kopfes, neu gefüllt werden müssen.

Aus Performance-Gründen haben wir nur einen ZFS Pool pro Kopf eingerichtet und ihn als Mirror (und nicht als RAIDZ) konfiguriert. Laut den Vorgaben aus dem entsprechenden Oracle Whitepaper für den Datenbank-Betrieb auf der ZA wurden dann die Shares für Datafiles, Redo und Archivelog entsprechend mit den passenden Einstellungen für Logbias, Recordsize, Kompression und Primarycache konfiguriert:

Share

Logbias

Recordsize

Primarycache

Compression

DATAFILES

latency (oder throughput)

db_blocksize

all

LZJB

INDIZES

latency

db_blocksize

all

off

CONTROLFILES

latency

128k

all

LZJB

Von der in ZFS prinzipiell unterstützen Deduplikation ist übrigens für diesen Einsatzzweck stark abzuraten, da die erforderlichen Ordnungstabellen sehr viel Platz im RAM benötigen und dort mit dem Cache kollidieren.

Die SSDs für das ZIL wurden gestriped eingerichtet. Ein Fehler auf einer SSD kann nun zusammen mit einem Stromausfall und dem daraus folgenden Verlust des Hauptspeicher-Inhaltes zu Datenverlust führen, aber wählt man hier die Konfiguration als Mirror, wird im Latency-Modus die maximale Schreibrate durch den Cache durch die Bandbreite einer SSD begrenzt – zu langsam für uns.

Auf der Exadata als Quellsystem und einer X4-2 Maschine, die als Datenbankserver für die Klon-Datenbankenvorgesehen ist, werden nun die Linux-Interfaces für Infiniband eingerichtet:

Enable LACP Link Aggregation
ifcfg-ibx MTU: 65520
Connected Mode

Dann werden die ZA-Shares per dNFS eingehängt. dNFS wickelt die wesentlichen Übertragungsprozesse direkt in den Oracle-Prozessen ab und führt für den Database Writer sowie für RMAN zu erheblichen Geschwindigkeitsvorteilen. Wir haben die folgenden Linux NFS- und Mount-Options verwendet:

rw, bg, hard, nointr, rsize=1048576, wsize=1048576, tcp, vers=3,timeo=600

Die Einstellungen in /etc/sysctl.conf waren:

net.ipv4.tcp_timestamps=0
net.ipv4.tcp_sack=0
net.core.netdev_max_backlog=250000
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.core.rmem_default=16777216
net.core.wmem_default=16777216
net.core.optmem_max=16777216
net.ipv4.tcp_mem="16777216 16777216 16777216"
net.ipv4.tcp_rmem="4096 87380 16777216"
net.ipv4.tcp_wmem="4096 65536 16777216"

dNFS in Kombination mit Remote Direct Memory Access (RDMA) erbrachte die besten Ergebnisse. Allerdings ist RDMA nicht in allen Konfigurationen von Oracle mit dNFS unterstützt.

Insgesamt blieben die Lese- und vor allem Schreibraten, die wir von den Linux-Servern gegen die ZA bekamen, weit hinter den Erwartungen zurück.

Mit dd, CTAS aus der Datenbank oder anderen Testwerkzeuge haben wir folgende Durchsätze gemessen:

Konfiguration / Test

Durchsatz lesend

Durchsatz schreibend

Initiale Konfig, RMAN/OS

 

260 MB/s

CTAS, INSERT APPEND 

 

100 MB/s

Kernel-NFS

400 MB/s

 

dNFS

1,9 GB/s

 

Adaptive Direct IO, NOLOG, throughput bias, rs=128k, IPoIB

1,6 GB/s

 

NFS over RDMA

3,5 GB/s

400 MB/s pro Pool

Bündel-Test, Latency Mode

5,5 GB/s mit beiden Köpfen

1 GB/s

ORION Test

 

600 MB/s (ein Kopf)

_adaptive_direct_read=TRUE

 

55 MB/s (DOP=10)

Mit Patch für Bug 19339320

 

115 MB/s

_direct_io_wslots=32, parallel_execution_message_size=65536

 

315 MB/s

Schreiben mit vielen parallelen Sessions

 

1,2 GB/s

Mit allen SSDs

 

1,7 GB/s

NFS/IPoIB Durchsatz X4-2 / ZA

1,25GB/s pro Interface

 

Ziel mit 2x 4G Wirespeed

7 GB/s

4 GB/s (sustained IO)

Oracle-Angabe

(27TB/h), 17,3GB/s on ZA

 

Viele der genannten Tests beruhen auf Vorschlägen durch den Oracle Support. Wegen dieser Performance sind seit einigen Monaten zwei Oracle-SRs und ist mittlerweile ein Bug offen. In den Griff bekommen haben wir die Probleme bisher trotz Überprüfung von allen denkbaren Komponenten bis hinunter zur Verkabelung und Einsatzes mehrere Oracle-Engineers vor Ort nicht. Eventuell ist hier ein Bug in den Mellanox-Treibern oder im Linux Kernel verantwortlich?

Passwörter wiederherstellen in Oracle 11g

,

In der Datenbank Version 11gR1 hat Oracle bekanntlich case-sensitive Passwörter und einen neuen Passwort-Algorithmus eingeführt. In der Datenbank werden nicht die Klartext-Passwörter, sondern nur deren Hashes abgelegt, und der Algorithmus, mit dem diese Hashes berechnet werden, war bei 10g 3DES, und ist seit 11g SHA1. Im 10g-Hashverfahren fliesst der Username als Salt in den Hash mit ein, während ab 11g ein zufälliges Salt verwendet wird. Ab 11g können die Hashes also zwischen verschiedenen Benutzern geteilt werden.

Will man das Passwort eines Benutzers sichern, um es beispielsweise in einer anderen Datenbank wieder einzuspielen, kann man sich den Hash im Data Dictionary suchen (der 10g Hash steht in SYS.USER$.PASSWORD, der 11g Hash in SYS.USER$.SPARE4), und dessen Wert mit Hilfe der “BY VALUES” Klausel beim Anlegen eines neuen Users angeben:

CREATE USER AKIRA IDENTIFIED BY VALUES ‘DA3A39221404DD55’; –10g hash

ALTER USER AKIRA IDENTIFIED BY VALUES ‘S:3CAFD1F43D6958FD4F67C2EDD91B3FF54913344723750F6AE48C802D37E4’ –11g hash

Oracle erkennt hier selbstständig aus dem verwendeten Wert, ob es sich im einen 10g oder um einen 11g Hash handelt. Wird ein 11g Hash angegeben, löscht die Datenbank allerdings den 10g Hash aus dem Dictionary – und umgekehrt. Normalerweise kann man mit dieser Syntax also nur entweder einen alten oder einen neuen Hash setzen, aber nicht beide, wie man es zur vollständigen Wiederherstellung eines bisherigen Zustandes in einigen Fällen bräuchte.

In der MOS Note (Doc ID 1051962.101) hat Oracle beschrieben, wie man beide Hashes mit der “BY VALUES” Syntax eintragen kann:

alter user TEST identified by values
‘7A0F2B316C212D67;S:F3F4BA77C0E960A5973095AF787988CBE52410CB2EA53F6AF008AD99179B’;

Indem man beide Hashes mit einem Semikolon getrennt zusammen angibt.

Bei der Authentifikation ab 11g existiert eine erschreckende Sicherheitslücke im O5LOGON Protokoll, das es einem Angreifer ermöglicht, den Session Key und das Salt auszulesen, ohne Spuren zu hinterlassen. Um sie zu schließen, haben einige Datenbankadminstratoren die 11g-Authentifizierung ganz ausgeschaltet, indem sie den Parameter “SEC_CASE_SENSITIVE_LOGON=FALSE” gesetzt oder alle 11g-Hashes aus dem Dictionary gelöscht haben.

In dieser Kombination kann es zu dem Effekt kommen, dass Passwörter zum Beispiel beim Aufbau einer Testumgebung mittels der BY VALUE Methode mit einem gespeicherten 11g-Hash zurückgesetzt werden, sich aber danach kein Anwender anmelden kann, weil in der Quell-Datenbank noch der 10g-Hash verwendet wurde, dieser aber durch das Neu-Setzen des 11g-Hashes überschrieben wurde, und die Anmeldung nur mit einem 11g-Hash nicht funktioniert. Hier hilft dann die oben beschriebene Methode, beide Hashes anzugeben, so man sie denn gesichert hatte.

Siehe auch zum Thema:
  • Marcels Blog Post zum Thema Hashes in 11g. Hier wird auch der verwendete Algorithmus vollständig beschrieben.
  • “Cryptographic flaws in Oracle Database authentication protocol”, Esteban Martínez Fayó

Infrastructure Repository Databases

Eine RMAN-Catalog-Datenbank zum Speichern der Metadaten von RMAN-Sicherungen muss ab Version 12.1.0.2 auf einer Enterprise-Edition (EE) – Datenbank betrieben werden, weil sie nun Partitionierung verwendet.

Ansonsten erhält man beim Aktualisieren (upgrade) des Katalogs folgenden Fehler:

RMAN> upgrade catalog;error creating create_deleted_object_seq
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-06004: ORACLE error from recovery catalog database: ORA-00439: feature not enabled: Partitioning

Was zunächst wirkt wie eine enorme Lizenz-Verteuerung durch die Hintertür, relativiert sich durch die neu geschaffene Möglichkeit, eine sogenannte “Infrastructure Repository Database” zu verwenden. Eine solche Datenbank, immer als Enterprise Edition zu installieren, erfordert keine zusätzliche Lizensierung, wenn sie nur mittels Oracle-Tools verwendet wird:

A separate single instance Oracle Database can be installed and used as an infrastructure repository for RMAN, Oracle Enterprise Manager Cloud Control, Automatic Workload Repository (AWR) Warehouse, Global Data Services Catalog, and Grid Infrastructure Management Repository without additional license requirements, provided that all the targets are correctly licensed.

Siehe: RMAN Catalog requires Enterprise Edition (EE) since Oracle Database 12.1.0.2

DB Link Passwörter Metadaten in 11.2.0.4

, ,

Seit der Datenbank Version 11.2.0.4 funktioniert das Auslesen der Beschreibungen für Datenbank-Links über DBMS_METADATA.GET_DDL nicht mehr. Statt des Passwort Hashes wird nun eine Bind Variable angezeigt.

Die Passwörter von Datenbank-Links wurden früher in der PASSWORD-Spalte der Tabelle SYS.LINK$ im Klartext abgelegt und waren einfach lesbar. In Version 10gR1 wurde der Zugriff auf diese Tabelle aus der Rolle SELECT ANY DICTIONARY entfernt, mit 10gR2 wurde die Spalte PASSWORDX eingeführt, die nun nur noch den Hash speichert.  Mit der Sicherheit dieses Hashes steht es allerdings auch nicht zum Besten.

Während es in älteren Versionen möglich war, die komplette Link-Beschreibung inklusive der Passwort-Hashes in einer “BY VALUES”-Klausel auszulesen, sieht das Ergebnis in 11.2.0.4 so aus:

SQL> SELECT OWNER, DB_LINK, DBMS_METADATA.GET_DDL('DB_LINK',DB_LINK,OWNER) as DDL FROM DBA_DB_LINKS;
OWNER          DB_LINK      DDL
-------------- ------------ ----------------------------------------------------------
SYS            TEST_LINK    CREATE DATABASE LINK "TEST_LINK"
                            CONNECT TO "DBLINK_ACCOUNT" IDENTIFIED BY VALUES ':1'
                            USING 'TNSALIAS'

Der für den Link notwendige Hash steht allerdings immer noch in der PASSWORDX-Spalte der SYS.LINK$-Tabelle, und kann mit Hilfe von DBMS_CRYPTO recht einfach ausgelesen werden:

SQL> select 
 name, 
 userid, 
 utl_raw.cast_to_varchar2(dbms_crypto.decrypt((substr(passwordx,19)), 
  4353, (substr(passwordx,3,16)))) 
from sys.link$;

NAME       USERID         UTL_RAW.CAST_TO_VARCHAR2(DBMS_CRYPTO.DECRYPT
                          ((SUBSTR(PASSWORDX,19)),4353,(SUBSTR(PASSWORDX,3,16))))
---------- ---------      -------------------------------------------------------
TEST_LINK  DBLINK_ACCOUNT GEHEIMESPASSWORT

Oft wird eine solche Möglichkeit benötigt, um Skripte zu erstellen, die Objekte wie Links zusammensuchen, um sie zu paketieren und für Deployment bereitzustellen.

Dieser Bug in der Datenbank Version 11.2.0.4 ist bei Oracle klassifiziert unter: Bug 18461318. Der Status dieses Bus steht allerdings auf “44 – Not Feasible to fix, to Filer“, was nicht sehr vielversprechend klingt.


Update 23.11.2017: Es findet eine Verschlüsselung, keine Hash-Wert-Berechnung, des Link-Passwortes statt, und diese lässt sich brechen.

Back Up a Thousand Databases Using Enterprise Manager Cloud Control

Porus Homi Havewala schreibt im Oracle Technet Blog einen schönen Walkthrough durch die Konfiguration von RMAN-Backups im Oracle Cloud Control 12c. Im Detail wird beschrieben, wie auf diesem Weg eine zentrale Kontrolle über die Sicherungen einer Vielzahl von Datenbanken erreicht werden kann, und illustriert, wie die RMAN-Skripte, die der CC erzeugt, jederzeit eingesehen und beeinflusst werden können. Da alle Informationen im CC Repository abgelegt sind, ist eine Catalog Database für RMAN nicht mehr erforderlich.

Oracle stellt fünfte Exadata-Generation vor

,

Oracle hat die fünfte Generation der Exadata Database Machine, die Exadata X-4 vorgestellt. Das Engineered System löst das aktuelle Modell X-3 ab und verspricht weitere Verbesserungen von Performance und Storage-Kapazitäten. Die Datenbank-Maschine soll je nach Konfiguration 50 bis 100 Prozent leistungsfähiger sein als das bisherige Modell.

Hinter der Gittertür sorgen zwei zwölf-Kern-Xeon-Chips E5-2697 und 256 GB RAM pro Datenbank-Server für die nötige Computing-Leistung. Das RAM kann auf 512 GB erweitert werden. Auch die Storage-Server arbeiten mit jeweils zwei Intel-Xeon-Prozessoren, die datenintensive Workloads beschleunigen.

Jeder Storage-Server beinhaltet vier Exadata Smart Flash Karten, auf denen der Datencache aufgebaut wird. Sie erreichen eine Rohkapazität von 3,2 TB. Laut Oracle liegt die effektive Flash-Kapazität der Exadata Smart Flash Karten zehn Mal höher als beim physischen Flash-Cache. Ein vollständig ausgebautes Rack hätte laut Oracle somit eine effektive Flash-Kapazität von 440 TB.

Die Exadata Smart Flash Cache Compression ermöglicht darüberhinaus eine dynamische Steigerung der Kapazität durch transparente Kompression der Daten im Flash-Cache.

Die Schreib- und Lesegeschwindigkeiten haben sich laut Oracle um 77 bis 100 Prozent verbessert und erreichen nun maximal 2,66 Millionen Input/Output operations Per Second pro Rack und 1,96 Millionen Schreib-IOPs auf Flash-Speicher.

Mit Infiniband und dem „Zero-Loss Zero-Copy Datagram Protocol” (ZDP) wird nun die doppelte Datenmenge verarbeitet. Zusätzlich sorgt das Network Resource Management für niedrige Antwortzeiten bei Latenz-kritischen Operationen, auch wenn parallel dazu andere Aufgaben wie Berichte, Batch-Jobs oder Backups durchgeführt werden.

In der vollständig ausgebauten Konfiguration hat das System einen Listenpreis von 1,1 Millionen US-Dollar. Die Exadata X-4 wird entweder mit Oracle Linux 5 Update 9 oder Solaris 11 Update 1 ausgeliefert. Abgesehen vom Betriebssystem sind etwaige Software-Lizenzen, auch für die Exadata Storage Server Software, nicht im Preis enthalten.

Die neue Version der Oracle Exadata Software unterstützt alle früheren Exadata Hardware-Generationen sowie Oracle Database 12c (inklusive Multitenant Option) und Oracle Database 11g Release 2.