DBA Community - Februar 2016
DBA Community - Februar 2016
|
Sizing Oracle Database Appliance (ODA)
von Sebastian Solbach ORACLE Deutschland B.V. & Co.KG
Die aktuelle X5-2 Generation der Oracle Database Appliance (ODA) bietet durch die eingesetzte Hardware und Ihre besonderen Eigenschaften,
wie die Lizenzierung auf Basis einzelner Kerne, eine ideale Plattform um selbst hochverfügbare Datenbanken schnell und einfach aufzusetzen und zu betreiben.
Die genauen Spezifikationen sind dem aktuellen Datenblatt zu entnehmen.
Herauszuheben ist neben schnelleren CPUs mit mehr Kernen dabei vor allem die Einführung von verschiedenen Storage Tiers: zwei Flash-Tiers (je 4 SSDs)
und ein Festplatten-Tier (16 Disks je Storage Shelf).
Grundannahmen
Bei diesem "schnellen" Realitätscheck lassen wir einige technische Verbesserungen bei der Migration auf eine ODA außen vor.
So berücksichtigen wir zum Beispiel nicht, dass die CPUs schneller sind. Auch den Effekt, Datenbanken mehr Memory zuweisen zu können,
betrachten wir nur am Rande. Dies gilt genauso für den Flash Cache, da dieser letztendlich auch nur eine Memory Erweiterung ist.
Datendateien oder ganze Datenbanken in den Flash Bereich der ODA auszulagern ist zwar ebenfalls eine Möglichkeit, betrachten wir aber auch nur am Rande.
Basis: AWR Report oder Statspack
Eigentlich sind alle benötigten Werte für das Sizing in einem AWR Report oder - falls man kein Diagnostic Pack besitzt - in einem Statspack Report enthalten.
Damit man aussagekräftige Werte erhält, sollte ein Zeitraum von maximal 30 Minuten zur Hochlastzeit betrachtet werden.
Möchte man auf Nummer "Sicher" gehen, sollten mehrere AWR Reports von mehreren Tagen zu unterschiedlichen Zeiten ausgewertet werden.
CPU Verbrauch
Den CPU Verbrauch pro Sekunde im Zeitraum des AWRs ist bereits ganz am Anfang unter Report Summary zu finden. 
Die DB CPU pro Sekunde liegt in diesem Beispiel bei 7,1. Diesen Wert sollte man auf ganze CPUs aufrunden. D.h. die Datenbankinstanz würde mit einem CPU_COUNT = 8 gut funktionieren. Hatte das "alte" System ebenfalls Hyperthreading aktiviert, so kann dies 1 zu 1 übernommen werden (ungeachtet der schneller CPU Performance wie oben schon erwähnt). Dies entspräche also aktuell einer Datenbank, die mit dem Template ODB-04 erzeugt wurde (Details zu ODA Datenbank Templates). Verwendete die alte Datenbank kein Hyperthreading sollte der Wert größer sein. Da genügend CPUs vorhanden sind, empfiehlt sich dann das ODB-08 Template. Memory
Im AWR Report gibt es einen Bereich mit Advisory Statistics. Aus diesen Advisories geht sehr gut hervor, wie viel physikalischer I/O eingespart werden kann, wenn das Memory der Datenbank erhöht wird. Dies ist nicht nur für die generelle Datenbankperformance auf einer ODA wichtig: Ihre jetzige Umgebung kann jetzt schon von einer Anpassung des Memories profitieren. Auf einer ODA ist dies aber ein ganz entscheidender Faktor! Erstens hat man, selbst in der Grundausstattung der ODA, 256 GB an Memory, zweitens kommt durch den Shared Flash Cache auf den SSDs nochmals ein größerer Memory Bereich hinzu. Beides kann dazu dienen die IOPs der Datenbanken zu verringern und damit die Platten zu entlasten. Besonders wichtig im AWR Report sind dabei zwei Advisors: Das "Buffer Pool Advisory", das heißt die Größe des Datenbank Caches und das "SGA Target Advisory", welche natürlich indirekt auch Auswirkungen auf den Buffer Cache hat. Hier einmal zwei Beispiele, welchen Einfluss dies auf die I/O hat: 
Auch wenn hier nur ein Auszug im Screenshot zu sehen ist, in beiden Fällen ist deutlich erkennbar, dass sich die errechneten Physical Reads (Estimated Phys Reads) bei größerem Buffer Cache verringern. Im ersten Falle ist der Faktor bei Verdopplung des DB Caches bei 0,79 während im 2. Fall eine größerer Cache die I/Os auf 17% (0,17) der aktuellen Last verringert. Ein ähnliches Bild belegt auch der SGA Target Advisor der beiden Datenbank Instanzen, bei denen beides mal bei ca. 50% mehr Memory eine deutliche Verbesserung zu sehen ist. 
Dies sollte man auf alle Fälle bei der Memory Verteilung auf der Zielplattform einer ODA mit berücksichtigen, da sich dadurch, wie wir später sehen werden einige I/Os im Vorfeld vermeiden lassen. Leider lassen sich die genaue Auswirkung aber nur ungefähr abschätzen. Hier wäre der Test auf der bestehenden (nicht ODA) Plattform mit mehr Memory definitiv aussagekräftiger. Platten I/O
Kommen wir nun zum wichtigen Punkt, wie sich der I/O der Datenbank(en) auf die Festplatten der ODA verteilen wird. Dazu sollte man sich keinesfalls auf die I/O Statistiken von anderen Storage Herstellern verlassen, da die IOPS auf dem Storage (meist 512 Bytes) nicht den IOPs der Datenbank (mit Datenbank-Blockgröße) entsprechen und gegebenenfalls RAID Level mit berücksichtien. Auch hier enthält der AWR Report bessere Informationen. Diese finden sich in der Sektion "IO Stats", insbesondere den "IOStat by Function summary" bzw. "IOStat by Filetype summary". Schauen wir uns das I/O by Filetype bei einem Extrembeispiel mal genauer an: 
Generell interessiert der I/O, der auf den langsameren HDDs landet. Der I/O auf die Log Files und damit den Redologs ist zwar generell von großer Bedeutung für die Datenbank Performance, für die ODA hat dies aber nur eine geringe Bedeutung, da dieser I/O von den schnellen SSDs in unter 1ms bestätigt wird. Gerade dies macht die ODA für OLTP Applikationen auch so interessant. Für die I/O Betrachtung muss also von den Total I/O einfach nur der Log File I/O abgezogen werden. Allerdings gibt es noch eine "Falle", die man gerne vergisst: Auf der ODA wird die Datensicherheit durch den ASM Spiegel Mechanismus erreicht, entweder mit Normal Redundancy (einfache Spiegelung) oder High Redundancy (doppelte Spiegelung). Dafür schreibt ASM für jeden Block einen Primär- und ein oder 2 Sekundär-Extents. Beim Lesen von ASM wird sowohl auf die Primär- als auch die Sekundär-Extents zugegriffen, womit beim Lesen der I/O aller 16 Platten zur Verfügung steht. Anders sieht es allerdings beim Schreiben aus, da ein "Write" erst dann bestätigt wird, wenn Primär- und Sekundär-Extent(s) geschrieben wurden. Damit muss man die Writes beim I/O Sizing verdoppeln oder verdreifachen, je nachdem, mit welcher Redundanz (Normal/High) die ODA installiert wurde. Prinzipiell muss man also folgendes berechnen: I/O Read/s + I/O Write/s * Redundanz. Da bei den Read/s und Write/s die Log File Informationen nicht relevant sind, ergibt sich folgende Formel für die I/O pro Sekunde auf den HDDs der ODA: TOTAL (I/O Read/s - Log File I/O Read/s) + (Total I/O Write/s - Log File I/O Write/s) * Redundanz
Für das Beispiel von Oben:
(892,35 {TOTAL Read: Reqs per sec} - 2,15 {Log File Reads: Reqs per sec}) +
(811,03 {TOTAL Writes: Reqs per sec} - 485,44 {Log File Writes: Reqs per sec}) * Redundanz
= (892,35 - 2,15) + (811,03 - 485,44) * Redundanz
= 890,2 + 325,59 * Redundanz
Normal Redundancy: 890,2 + 325,59 * 2 = 1541,38
High Redundancy: 890,2 + 325,59 * 3 = 1866,97
Rechnet man nun keine Memory Effekte (s.o.) mit ein, so ist aus diesen Zahlen bei diesem Extrembeispiel zu erkennen, dass diese eine Datenbank alleine eine ODA mit einem Storage Shelf komplett
auslasten würde, da dieses ca. 1500 IOPs liefert. Da auch Platz für zukünftiges Wachstum vorgehalten werden sollte, ist es empfehlenswert in diesem Fall ein zweites Storage Shelf zu beschaffen, unabhängig
davon wie groß die Datenbank ist. Mit 3000 IOPs hat die ODA genügend Reserven auch andere Lastspitzen mit abzudecken.
Bitte berücksichtigen Sie auch, dass im Falle eines RACs beide Instanzen auf dasselbe Storage zugreifen. Ist das Sourcesystem bereits ein RAC sollte der I/O aller Instanzen in die Rechnung mit einfließen. D.h. die 1500 IOPs eines Storage Shelfs müssen für beide ODA Knoten ausreichend sein. Das obige Beispiel stammte von einer Single Instanz und konnte somit für die Lastermittlung im Sizing einzeln berücksichtigt werden. Interessant wird es nun, wenn man den oben beschriebenen Effekt mit einrechnet, der Datenbank auf der ODA mehr Memory zu geben. Rechnen wir das durch mit dem Faktor 0,79 aus dem obigen Beispiel bei Verdoppelung des DB Caches: Normal Redundancy: 890,2 * 325,59 * 2 = 1541,38 * 0,79 = 1217,80 High Redundancy: 890,2 * 325,59 * 3 = 1866,97 * 0,79 = 1474,90Zwar hat ein größerer Cache auch Auswirkung auf die Write Performance, da weniger Blöcke vom Cache auf Platte geschrieben werden müssen, wenn man aber lieber ganz "konservativ" rechnet, sollte der Faktor nur auf die Reads angewendet werden. Normal Redundancy: 890,2 * 0,79 + 325,59 * 2 = 1354,44 High Redundancy: 890,2 * 0,79 + 325,59 * 3 = 1680,03In beiden Fällen (egal ob konservativ oder progressiv gerechnet wurde) sollte bei "Normal Redundancy" ein Storage Shelf ausreichend sein. Bei High Redundancy würde ich immer noch zum zweiten Storage Shelf tendieren. Sollten die 256 GB Memory nicht ausreichen (oder gegebenenfalls auch die Memory Erweiterungen auf 768GB nicht), so hat man noch eine weitere Möglichkeit auf der ODA. Die ODA verwendet für OLTP Datenbanken defaultmäßig den Flash Bereich/das Flash-Tier (die weiteren SSDs) als Memory Erweiterung. Dies kann bei der "Vergrößerung" des Buffer Caches ebenfalls mit eingerechnet werden, wenn auch nur in der "konservativen" Rechenweise, da die SSDs langsamer sind als ein Memory zugriff. Einer Datenbank der odb-6 Kategorie (24 GB SGA) stehen 72 GB Flash für Daten zusätzlich zur Verfügung. Da es sich dabei um einen "Shared Flash Cache" handelt, haben beide RAC Instanzen auf diese 72 GB Zugriff. Weitere Tuning Maßnahmen
Das Sizing bis zu diesem Punkt ging davon aus, dass keine besonderen Maßnahmen an der Datenbank vorgenommen werden.
Sollten bestimmte Faktoren dafür sprechen, dass die IOPs ein Bottleneck darstellen könnten, so gibt es noch einige Ansatzpunkte für Verbesserungen.
Sind die Datenbanken relativ klein, könnten diese komplett auf der Flash-Tier (bzw. Flash Diskgruppe) abgelegt werden. Dies wird sogar von dem Verwaltungsbefehl der ODA "oakcli" beim Anlegen einer Datenbank direkt unterstützt.
Damit stellen IOPs der Platten keine Beschränkung mehr dar, allerdings sind die Datenbanken auf Flash maximal 700 GB groß.
Deshalb ist zu überlegen, ob man nicht lieber einer Memory Erweiterung den Vorzug gibt, da Memory schneller ist als SSDs.
Mit mehr Memory lässt sich auch Oracle Database InMemory richtig gut verwenden, denn das InMemory Format ist auf Flash noch nicht möglich.
Fazit
Beim Sizing für die ODA sollte neben CPU, Memory und Plattenplatz besonders auch dem I/O Element Aufmerksamkeit geschenkt werden.
Es ist allerdings kein Hexenwerk, diese Informationen aus bestehenden AWR Reports oder Statspack herauszulesen und damit zu einer groben Abschätzung zur Eignung und Auslastung einer ODA zu kommen.
Sicher ist dies nur ein erster Näherungswert, da sich verringerte IO Zeiten bei den Redologs, Database Flash Cache, schnellere CPUs und andere Hardwareverbesserungen ebenfalls auf die Belastung des Storages und
die Gesamtperformance einer Datenbank-Plattform auswirken. Tools, wie die Consolidation Workbench im neuen Enterprise Manager 13c, liefern hier genauere Werte, da hier auch die AWRs über einen längeren Zeitraum genau
ausgewertet werden.
Nützliche Links und Referenzen
|