Dienstag Jan 29, 2013

Sparen Sie Zeit und Nerven mit Oracle Dojos

Gestern leitete ein Kollege die E-Mail eines Kunden an mich weiter. Die Nachricht war mit "TCP Window Scale Option" überschrieben und enthielt einen wertvollen Hinweis auf einen Tuning-Parameter unter Windows Server 2008 R2. Obwohl ich diesen Parameter bereits kannte, bin ich immer wieder mehr als froh über derartige Hinweise. Besonders interessant war jedoch die Situation, aus der heraus dieser Informationsaustausch entstand. Lesen Sie selbst dazu den nachfolgenden Text des Kunden in anonymisierter und leicht abgewandelter Form:

"Hallo Herr XY,

nur als Info ein Problem, das uns diese Tage lange und extrem beschäftigt hat. Ich habe ein RAC SE 1123 auf 2 Win2008R2 Servern aufgebaut. Dies hat bei uns im Büro wunderbar funktioniert, mit Client-Verbindungen die teilweise auch auf den RAC Nodes laufen.

Erst bei der Inbetriebnahme beim Kunden hatten wir das Problem dass die Verbindungen von dendie Clients (.NET Applikationen) nicht richtig bzw. gleichmäßig auf die 2 Nodes verteilt werden (TNSNAMES Eintrag ist OK). Es ist so, dass die Verbindungen, die aus NodeA rausgehen, nach mehreren Sekonden Verzögerung immer wieder bei NodeA landen und von NodeB genauso. Von PCs aus (z.B. XP) funktioniert die Verteilung ohne Verzögerung wunderbar.

Nach langer, langer Suche haben wir entdeckt, dass dies an der in Windows  7/Vista neuen TCP Option liegt (TCP Window Scale Option). Den Befehl „C:> netsh interface tcp set global autotuninglevel = disable“ haben wir auf den beiden Windows 2008 R2 Server Nodes ausgeführt und neu gebootet. Dann war alles wieder OK.

Ich habe auch ein Dokument auf Metalink diesbezüglich gefunden: Oledb and Odbc 64 Bit On Windows 2008 and Windows Vista Have Bad Performances [ID 1264980.1]

Schöne Grüße

Kunde"


Ich habe diese Nachricht mit einem lachenden und einem weinenden Auge gelesen. Das Lachende freute sich darüber, dass uns ein Kunde seine Erfahrungen mitteilt, einen wertvollen Hinweis liefert und ein Kollege das dann auch noch an mich weiterleitet. Alles keine Selbstverständlichkeiten. Danke!



Mein weinendes Auge dachte daran, dass dieser Hinweis in unserem ersten Oracle Dojo #1 "Oracle 11g R2 mit Real Application Clusters auf Windows Server 2008 R2" auf Seite 39 im Schritt 8 beschrieben ist und der Kunde sich diesen ganzen Ärger und seine Zeit hätte sparen können. Abgesehen davon, enthält dieses Oracle Dojo noch einige weitere Tuning-Hinweise, die ebenfalls berücksichtigt werden sollten, möchte man einen Windows Server 2008 R2 optimal konfigurieren. Und dies gilt nicht nur für einen Cluster.



Wir schreiben heute das Jahr 2013 und das Oracle Dojo #1 wurde auf der DOAG Konferenz 2011 vorgestellt. Eigentlich müsste man annehmen, dass seitdem genug Zeit verstrichen ist, um die kleinen roten Heftchen überall bekannt zu machen. Vielleicht ist es aber gerade der Fluch unseres sogenannten Informationszeitalters, dass sich, aufgrund seiner Schnelllebigkeit, die bereits verfügbaren Informationen nicht verbreiten und vertiefen können, sondern im Nirvana des schieren Überangebots verlieren und bereits nach kurzer Zeit in Vergessenheit geraten. Zwei Jahre werden demnach nicht als Zeit des Wachstums und der Reife angesehen, sondern als Siechtum und Verfall. Eine Information muss in Google auf der ersten Seite erscheinen und brandaktuell sein. Alles andere interessiert nicht. Die Information von Gestern ist Geschichte und langweilig. Auf der zweiten und dritten Seite beginnt bereits die Liste der Velierer im Buhlen um Follower. Zugegeben: Ich sehe mir meist auch nur die erste Seite an. Meine Sozialkritik richtet sich also durchaus auch an mich selbst.

Was kann man also anderes tun, als immer wieder auf die Dinge aufmerksam zu machen? Und weil die Stimme eines Einzelnen im Internet hoffnungslos untergeht, kann ich Sie nur darum bitten, meinen Hinweis in Ihrem Umfeld zu verbreiten und auf unsere Oracle Dojos aufmerksam zu machen. Denn davon gibt es mittlerweile sechs Stück und weitere sind in Vorbereitung. Sie können jedes einzelne Heft hier downloaden und für manche Exemplare auch die Druckausgabe bestellen - und zwar kostenfrei!

Vielleicht schrieben Sie auch einen eigenen Blog-Eintrag dazu, so wie es meine Kolleginnen mit ihrer Oracle News Box Germany gemacht haben. Und wenn Sie wissen möchten, was eigentlich hinter den Oracle Dojos steckt, lesen Sie am besten dieses Interview mit Günther Stürner.

Danke!



Sonntag Dez 16, 2012

SQL Server 2012 - AlwaysOn

Ich war nicht nur irritiert, ich war sogar regelrecht schockiert - und für einen kurzen Moment sprachlos (was nur selten der Fall ist). Gerade eben hatte mich jemand gefragt "Wann Oracle denn etwas Vergleichbares wie AlwaysOn bieten würde - und ob überhaupt?" War ich hier im falschen Film gelandet? Auch auf die Gefahr hin arrogant zu wirken, konnte ich nicht anders, als meinen Unmut kundzutun und zu erklären, dass diese Fragestellung normalerweise genau anders herum läuft. Zugegeben, es mag vielleicht strittige Punkte geben im Vergleich zwischen Oracle und SQL Server - bei denen nicht unbedingt immer Oracle die Nase vorn haben muss - aber das Thema Clustering für Hochverfügbarkeit (HA), Disaster Recovery (DR) und Skalierbarkeit gehört mit Sicherheit nicht dazu.

 

"Windows was the God ..."

Womit ich meinem Gesprächspartner als Erstes auf seine Frage antwortete, war nicht eine Aufzählung von Vorteilen der Oracle Maximum Availability Architecture (MAA) gegenüber Microsoft SQL Server 2012 AlwaysOn. Stattdessen sprach ich mit ihm über den grundlegenden Unterschied zwischen Microsoft und Oracle. Dazu muss man zunächst das bedeutendste Microsoft Dogma kennen. Es lässt sich schlicht und einfach auf den Punkt bringen: "Alles muss auf Windows basieren."

Die Überschrift dieses Absatzes ist kein von mir erfundener Ausspruch, sondern ein Zitat. Konkret stammt es aus einem längeren Artikel von Kurt Eichenwald in der Vanity Fair aus dem August 2012. Er lautet Microsoft's Lost Decade und sei jedem ans Herz gelegt, der die "Microsoft-Maschinerie" unter Steve Ballmer und einige ihrer Kuriositäten besser verstehen möchte.

"YOU TALKING TO ME?" Microsoft C.E.O. Steve Ballmer bei seiner Keynote auf der 2012 International Consumer Electronics Show in Las Vegas am 9. Januar

 

Manche Dinge in diesem Artikel mögen überspitzt dargestellt erscheinen - sind sie aber nicht. Vieles davon kannte ich bereits aus eigener Erfahrung und kann es nur bestätigen. Anderes hat sich mir erst so richtig beim Lesen erschlossen. Insbesondere die folgenden Passagen führten zum Aha-Erlebnis:

Windows was the god—everything had to work with Windows,” said Stone...

Every little thing you want to write has to build off of Windows (or other existing roducts),” one software engineer said. “It can be very confusing, …

Ich habe immer schon darauf hingewiesen, dass in einem SQL Server Failover Cluster die Microsoft Datenbank eigentlich kaum Nenneswertes zum Geschehen beiträgt, sondern sich voll und ganz auf das Windows Betriebssystem verlässt. Deshalb muss man auch die Windows Server Enterprise Edition installieren, soll ein Failover Cluster für den SQL Server eingerichtet werden. Denn hier werden die Cluster Services geliefert - nicht mit dem SQL Server. Er ist nur lediglich ein weiteres Server Produkt, für das Windows in Ausfallszenarien genutzt werden kann - so wie Microsoft Exchange beispielsweise, oder Microsoft SharePoint, oder irgendein anderes Server Produkt, das auf Windows gehostet wird. Auch Oracle kann damit genutzt werden. Das Stichwort lautet hier: Oracle Failsafe. Nur - warum sollte man das tun, wenn gleichzeitig eine überlegene Technologie wie die Oracle Real Application Clusters (RAC) zur Verfügung steht? Oracle RAC setzt auch keine Windows Server Enterprise Edition voraus, da Oracle die eigene Clusterware liefert. Welche darüber hinaus für kürzere Failover-Zeiten sorgt, da diese Cluster-Technologie Datenbank-integriert ist und sich nicht auf "Dritte" verlässt.

Wenn man sich also schon keine technischen Vorteile mit einem SQL Server Failover Cluster erkauft, sondern zusätzlich noch versteckte Lizenzkosten durch die Lizenzierung der Windows Server Enterprise Edition einhandelt, warum hat Microsoft dann in den vergangenen Jahren seit SQL Server 2000 nicht ebenfalls an einer neuen und innovativen Lösung gearbeitet, die mit Oracle RAC mithalten kann? Entwickler hat Microsoft genügend? Am Geld kann es auch nicht liegen? Lassen Sie einfach noch einmal die beiden obenstehenden Zitate auf sich wirken (oder lesen Sie den ganzen Artikel in der Vanity Fair) und sie werden den Grund erahnen.

Anders lässt es sich ja auch gar nicht mehr erklären, dass AlwaysOn aus zwei unterschiedlichen Technologien besteht, die beide jedoch wiederum auf dem Windows Server Failover Clustering (WSFC) basieren. Daraus und aus weiteren Abhängigkeiten ergeben sich klare Nachteile:

1. AlwaysOn ist eine komplexe Technologie

Der SQL Server AlwaysOn Stack ist zusammengesetzt aus drei verschiedenen Technlogien:

  • Windows Server Failover Clustering (WSFC)
  • SQL Server Failover Cluster Instances (FCI)
  • SQL Server Availability Groups (Verfügbarkeitsgruppen)

Man kann eine derartige Lösung nicht als nahtlos bezeichnen, wofür auch die vielen von Microsoft dargestellten Einschränkungen sprechen. Während sich frühere SQL Server Versionen in Richtung eigener HA/DR Technologien entwickelten (wie Database Mirroring), empfiehlt Microsoft nun die Migration. Doch weshalb dieser Schwenk? Er führt nicht zu einem konsisten und robusten Angebot an HA/DR Technologie für geschäftskritische Umgebungen.

Im Gegensatz zu AlwaysOn, vermeidet die Oracle HA/DR Technologie eine derartige Komplexität, hervorgerufen durch multiple Abhängigkeiten. Den Unterschied machen Datenbank-integrierte Mechanismen aus - wie Fast Application Notification (FAN) und Fast Connection Failover (FCF). So kann die Oracle Clusterware bei erkannten Problemen sofort die anderen Cluster-Ressourcen oder eine Anwendung informieren, um unmittelbar zu reagieren und Maßnahmen wesentlich schneller einzuleiten. Der SQL Server bietet nichts Vergleichbares.

2. Failover Cluster Instanzen - Kein RAC-Pendant

Die SQL Server und Windows Server Clustering Technologie basiert noch immer auf dem veralteten Aktiv-Passiv Modell und führt zu einer Verschwendung von Systemressourcen. In einer Betrachtung von lediglich zwei Knoten erschließt sich auf Anhieb noch nicht der volle Mehrwert eines Aktiv-Aktiv Clusters (wie den Real Application Clusters), wie er von Oracle bereits vor zehn Jahren entwickelt wurde. Doch kennt man die Vorzüge der Skalierbarkeit durch einfaches Hinzufügen weiterer Cluster-Knoten, die dann alle gemeinsam als ein einziges logisches System zusammenarbeiten, versteht man was hinter dem Motto "Pay-as-you-Grow" steckt. In einem Aktiv-Aktiv Cluster geht es zwar auch um Hochverfügbarkeit - und ein Failover erfolgt zudem schneller, als in einem Aktiv-Passiv Modell - aber es geht eben nicht nur darum. Der Microsoft SQL Server hat keine adäquate Technologie zu bieten.

An dieser Stelle sei darauf hingewiesen, dass die Oracle 11g Standard Edition bereits die Nutzung von Oracle RAC bis zu vier Sockets kostenfrei beinhaltet. Möchten Sie dazu Windows nutzen, benötigen Sie keine Windows Server Enterprise Edition, da Oracle 11g die eigene Clusterware liefert. Sie kommen in den Genuss von Hochverfügbarkeit und Skalierbarkeit und können dazu die günstigere Windows Server Standard Edition nutzen - oder auch Oracle Enterprise Linux (bzw. eine andere Linux Distribution), was das Preis-/Leistungsverhältnis noch interessanter macht. Ein Wechsel der Plattform ist auch zu einem späteren Zetpunkt möglich, da Oracle über Plattformgrenzen hinweg transparent portierbar ist. Dies ist unabhängig von HA und DR ein weiteres wichtiges Alleinstellungsmerkmal der Oracle Datenbank.

3. SQL Server Multi-Subnet Clustering - Abhängigkeit zu 3rd Party Storage Mirroring 

Die SQL Server Multi-Subnet Clustering Architektur unterstützt den Aufbau eines Stretch Clusters, basiert dabei aber auf dem Aktiv-Passiv Modell. Das eigentlich Problematische ist jedoch, dass man sich zur Absicherung der Datenbank auf 3rd Party Storage Mirroring Technologie verlässt, ohne Integration zwischen dem Windows Server Failover Clustering (WSFC) und der darunterliegenden Mirroring Technologie. Wenn nun im Cluster ein Failover auf Instanzen-Ebene erfolgt, existiert keine Koordination mit einem möglichen Failover auf Ebene des Storage-Array.

Oracle liefert auch hier eine eigene und integrierte Lösung: Automatic Storage Management (ASM).

4. Availability Groups (Verfügbarkeitsgruppen) - Vier, oder doch nur Zwei?

Ein primäres Replikat erlaubt bis zu vier sekundäre Replikate innerhalb einer Verfügbarkeitsgruppe, jedoch nur zwei im Synchronen Commit Modus. Während dies zwar einen Vorteil gegenüber dem stringenten 1:1 Modell unter Database Mirroring darstellt, fällt der SQL Server 2012 damit immer noch weiter zurück hinter Oracle Data Guard mit bis zu 30 direkten Standby Zielen - und vielen weiteren durch kaskadierende Ziele möglichen.

Damit eignet sich Oracle Active Data Guard auch für die Bereitstellung einer Reader-Farm mit höchsten Anforderungen an Skalierbarkeit für Internet-basierende Unternehmen. Mit AwaysOn Verfügbarkeitsgruppen ist dies nicht möglich.

5. Availability Groups (Verfügbarkeitsgruppen) - kein asynchrones Switchover 

Die Technologie der Verfügbarkeitsgruppen wird auch als geeignetes Mittel für administrative Aufgaben positioniert - wie Upgrades oder Wartungsarbeiten. Man muss sich jedoch einem gravierendem Defizit bewusst sein: Im asynchronen Verfügbarkeitsmodus besteht die einzige Möglichkeit für Role Transition im Forced Failover mit Datenverlust! Um den Verlust von Daten durch geplante Wartungsarbeiten zu vermeiden, muss man den synchronen Verfügbarkeitsmodus konfigurieren, was jedoch ernstzunehmende Auswirkungen auf WAN Deployments nach sich zieht. Spinnt man diesen Gedanken zu Ende, kommt man zu dem Schluss, dass die Technologie der Verfügbarkeitsgruppen für geplante Wartungsarbeiten in einem derartigen Umfeld nicht effektiv genutzt werden kann.

Derartige Einschränkungen existieren nicht mit Oracle MAA.

6. Automatisches Failover - Nicht immer möglich

Sowohl die SQL Server FCI, als auch Verfügbarkeitsgruppen unterstützen automatisches Failover. Möchte man diese jedoch kombinieren, wird das Ergebnis kein automatisches Failover sein. Denn ihr Zusammentreffen im Failover-Fall führt zu Race Conditions (Wettlaufsituationen), weshalb diese Konfiguration nicht länger das automatische Failover zu einem Replikat in einer Verfügbarkeitsgruppe erlaubt. Auch hier bestätigt sich wieder die tiefere Problematik von AlwaysOn, mit einer Zusammensetzung aus unterschiedlichen Technologien und der Abhängigkeit zu Windows.

Oracle kennt derartige Race Conditions nicht. 

7. Problematische RTO (Recovery Time Objective)

Microsoft postioniert die SQL Server Multi-Subnet Clustering Architektur als brauchbare HA/DR Architektur. Bedenkt man jedoch die Problematik im Zusammenhang mit DNS Replikation und den möglichen langen Wartezeiten auf Client-Seite von bis zu 16 Minuten, sind strenge RTO Anforderungen (Recovery Time Objectives) nicht erfüllbar. Im Gegensatz zu Oracle besitzt der SQL Server keine Datenbank-integrierten Technologien, wie Oracle Fast Application Notification (FAN) oder Oracle Fast Connection Failover (FCF).

Für Oracle MAA Konfigurationen sind dagegen Inter-Site Failover-Zeiten im Bereich von Sekunden keine Seltenheit.

8. Problematische RPO (Recovery Point Objective)

SQL Server ermöglicht Forced Failover (erzwungenes Failover), bietet jedoch keine Möglichkeit zur automatischen Übertragung der letzten Datenbits von einem alten zu einem neuen primären Replikat, wenn der Verfügbarkeitsmodus asynchron war. Oracle Data Guard hingegen bietet diese Unterstützung durch das Flush Redo Feature. Dies sichert "Zero Data Loss" und beste RPO auch in erzwungenen Failover-Situationen.

9. Lesbare Sekundäre Replikate mit Einschränkungen

Aufgrund des Snapshot Isolation Transaction Level für lesbare sekundäre Replikate, besitzen diese Einschränkungen mit Auswirkung auf die primäre Datenbank. Die Bereinigung von Ghost Records auf der primären Datenbank, wird beeinflusst von lang laufenden Abfragen auf der lesabaren sekundären Datenbank. Die lesbare sekundäre Datenbank kann nicht in die Verfügbarkeitsgruppe aufgenommen werden, wenn es aktive Transaktionen auf der primären Datenbank gibt. Zusätzlich können DLL Änderungen auf der primären Datenbank durch Abfragen auf der sekundären blockiert werden. Und imkrementelle Backups werden hier nicht unterstützt.

Keine dieser Einschränkungen besteht mit Oracle Data Guard.

10. Keine erprobte Lösung 

Wenn Sie dem Link zur Oracle MAA folgen, finden Sie eine Vielzahl an Case Studies zum erfolgreichen Einsatz der Oracle HA Technologien. Nicht zuletzt ist auch dies ein wichtiges Unterscheidungsmerkmal zu AlwaysOn, denn die Oracle Technologie hat sich über die Jahre hinweg bereits zigfach in höchst kritischen Umgebungen bewährt.   
   

Fazit

Natürlich war mein Gesprächspartner nicht mit jedem der hier dagestellten Punkte auf Anhieb und ohne Lieferung weiterer Details einverstanden - und Sie werden es vielleicht auch nicht sein. Dann freue ich mich auf ihre Kommentare und eine rege Diskussion. Doch am Ende waren wir uns einig: Die unbedingte Abhängigkeit zu Windows wird zunehmend zum Problem, da sie die Komplexität einer Microsoft-basierenden Infrastruktur erhöht, anstelle sie zu reduzieren. Und dies ist das Letzte, was sich CIOs, Architekten und Administratoren heutzutage wünschen. 

 

About

In diesem Blog dreht sich alles um die Integration von Oracle Technologie mit Microsoft Produkten. Wenn Sie sich für die Oracle Datenbank auf Windows Server interessieren oder .NET Anwendungen mit Visual Studio entwickeln, sind Sie hier richtig. Weitere Bereiche sind die Integration mit dem Active Directory und SharePoint. Ich teile hier aber auch meine Gedanken zu Unterschieden zwischen der Oracle Datenbank und dem Microsoft SQL Server. Wenn Sie eine bestimmte Frage haben, lassen Sie es mich wissen - ich bin sehr an ihren Erfahrungen mit Oracle und Microsoft interessiert. Ihr Claus Jandausch

Search

Archives
« April 2014
MoDiMiDoFrSaSo
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Heute