Donnerstag, 30. Juni 2016

SQL Server in-Memory OLTP – Ein Plädoyer für Lasttest Werkzeuge und End-to-End Monitoring

Im Rahmen einiger Proof-of-Concepts und Workshops für die in-Memory OLTP Engine des SQL Servers habe ich die Erfahrung gemacht, dass selbst komplexe Eigenentwicklungen von Unternehmen häufig ohne Werkzeuge für realistische Lasttests auskommen müssen.

Ziel der PoCs ist es zu evaluieren, ob das Investment in die Integration von SQL Server in-Memory OLTP überhaupt einen wirtschaftlich gerechtfertigten Vorteil mit sich bringt. Die einfache Frage im Raum ist häufig: Wird unsere Anwendung mittels in-Memory OLTP tatsächlich deutlich schneller? Die Voraussetzung für eine solche Überlegung ist natürlich, dass man entweder zurzeit mit der bestehenden Last zu langsam unterwegs ist oder für die Zukunft mit wesentlich mehr Last rechnet und davon ausgeht, dass diese zu Problemen führen wird.

Die wenigsten Kunden nutzen zurzeit die in-Memory OLTP Engine des SQL Servers für eine komplette Neuentwicklung auf der grünen Wiese. Wobei, wer als ISV oder Entwicklungsleiter schon länger eine Neuentwicklung im Auge hatte, dann ist der SQL Server 2016 ein guter Grund nun endlich damit zu beginnen. Die Implementierung von in-Memory OLTP in eine bereits produktive Anwendung ist immer mit Aufwand verbunden. Dieser besteht i.d.R. aus Lizenzkosten (Enterprise Edition, sofern nicht eh schon gesetzt) und natürlich Aufwand für die Anpassung der Anwendung. In-Memory OLTP basiert ja u.a. auf einem Versionstore und damit einem optimistischen Konzept hinsichtlich von Änderungen an den Daten. Daher müssen die Entwickler häufig diesbezüglich erst geschult und gecoacht werden.

Nur lohnt sich dieser Aufwand auch wirklich? Dann kommt oft noch die Definitionsrunde, was denn nun eigentlich mit schneller gemeint ist. Nur oft kann diese Frage gar nicht in der ersten Runde seriös und abschließend geklärt werden, da Werkzeuge fehlen, um eine realistische Last auf einem Testsystem zu erzeugen.

Die Funktionsweise von in-Memory OLTP selbst kann ich mittlerweile sehr gut demonstrieren mit Open Source Werkzeugen und meinen eigenen Beispielszenarien. Nur hat sowas ja nichts zu tun mit der Last eines selbst entwickelten Webshops oder einer angepassten ERP Umgebung. Ohne Tests sind Aussagen über mögliche Verbesserungen reine Kaffeesatzleserei.

Der Verzicht auf die Entwicklung von Lasttest Werkzeugen und ein End-to-End Monitoring sind aus meiner Sicht eindeutig technische Schulden. Natürlich kann ich nachvollziehen, dass das unglaublich unattraktive Stories sind und gerade hier gerne am Ende eines Projektes Budget gespart wird.

Der Lasttest wird ersetzt durch ein generisches Monitoring des SQL Servers (wenn überhaupt…) und das End-to-End Monitoring ergibt sich durch den Durchschnitt der Tickets mit dem Label “Performance”.

Mir ist es ein Rätsel, wie ohne Lasttests eine Anwendung überhaupt hinsichtlich irgendwelcher Seiteneffekte durch mehrere Anwender getestet werden konnte. Wobei damit dann häufig auch deutlich wird, warum man überhaupt vor Ort ist, um diese zu tunen bzw. warum sich da jemand Vorteile durch die in-Memory Engine verspricht.

Ähnliches gilt für das End-to-End Monitoring. Die vorhandenen SLAs beschränken sich zumeist auf RTO & RPO. Kennzahlen darüber hinaus sind nicht definiert und “Effekte” im Frontenderlebnis nicht nachvollziehbar.

Daher meine Bitte an Alle: Implementiert Lasttests, welche auch weiter entwickelt werden mit der Anwendung, und gleich dazu noch ein End-to-End Monitoring drauf, damit evtl. Effekte frühzeitig bemerkt werden können.

Natürlich wäre dann auch der Beweis, dass in-Memory OLTP genau diesen Workload beschleunigt wesentlich einfacher zu erbringen und mit weniger Aufwand möglich. So verbringe ich nicht unwesentlich viel Zeit in den PoCs und entwickle rudimentäre Lasttests, um den Budgetverantwortlichen zumindest eine grobe Einschätzung der Möglichkeiten liefern zu können.

Donnerstag, 16. Juni 2016

SQL Server 2016 - in-Memory OLTP

Die letzten Monate habe ich recht viel Zeit damit verbraucht Kunden im Rahmen von Workshops, PoCs und Projekten das Thema in-Memory OLTP und unsere Erfahrungen damit im SQL Server 2014 und SQL Server 2016 näher zu bringen. Bekannt wurde das Feature ja vor einiger Zeit als Projekt “Hekaton” für den SQL Server 2012.

Seinerzeit war das Interesse bei den Kunden sehr verhalten. Sowohl Endkunden als auch ISVs haben das Thema zwar wahrgenommen, aber da es ja erst mit 2014 realisierbar war, führte dieses bei den meisten zu einer “Das ist etwas für später…”-Meinung. Wenige haben für sich das Potenzial von in-Memory OLTP erkannt.

Das letzte halbe Jahr hat sich dieses geändert. Mit der Sichtbarkeit des Commitments von Microsoft in diese Technologie, von einem Feature mag ich da gar nicht mehr sprechen wollen, wurde vielen Nutzern des SQL Servers klar, dass sich das Spiel ändern wird bzw. eigentlich schon geändert hatte.

Nun, im SQL Server 2016, durch die Kombination von Technologien (Columnstore Index und in-Memory OLTP) zu Operational Analytics ist der Umfang der Änderungen bzw. Erweiterungen an der Architektur der SQL Server Engine deutlich sichtbarer geworden. Marketing ist halt doch alles. Hier mal ein gutes Beispiel.

Und für viele ist damit nun ein Wettbewerbsvorteil möglich, welchen man nicht mehr ignorieren kann.

Was machen wir da draußen schon mit in-Memory OLTP?

In den Workshops und PoCs erfahren und erleben die Kunden, wie leicht es geworden ist eine für sie bisher unvorstellbare Geschwindigkeit ihres Workloads auf ihrer bestehenden Hardware zu realisieren. Und ja, es ist kein “ein-und-läuft”-Feature. Viele Kunden entwickeln mittlerweile ihre LoB Systeme zum Teil selber und sind sehr darauf bedacht sich am Ende keinen Flaschenhals bei der Datenbank einzubauen.

In Projekten werden meist partiell Tabellen vom sogenannten “disk-based” Modell übertragen in die in-Memory Welt. Dabei sind häufig gar nicht die eigentliche Tabelle und die neuen Formen der Indizierung die Herausforderung, sondern ist eher die intellektuelle Hürde, dass nun mit einem Versionstore gearbeitet wird und sich die Isolationslevel ein wenig anders anfühlen. Hilft ja alles nichts. Da kommt ja auch ein wesentlicher Teil der Geschwindigkeit her.

Des Weiteren leiten wir Teams an sich dieser Technologie kreativ zu nähern. Zwar steht ja OLTP drauf, aber das heißt ja nichts. Gerade mit der Möglichkeit auf die “Durability” bewusst zu verzichten, können ganz besondere Number Cruncher in T-SQL entstehen. Besonders, wenn der T-SQL Code dann auch kompiliert werden konnte.

Und wir bringen in-Memory OLTP in Produktion. Das ist nicht immer ganz einfach, da bei dieser spezialisierten Engine ein wenig von der Flexibilität des SQL Servers abhanden kam. Dieses ist aber meist verkraftbar, wenn man sich die Vorteile vor Augen führt. Speziell Deployment Szenarien beim rund-um-die-Uhr-Betrieb können dabei Herausforderungen sein, welchen man bereits in der Designphase einer Lösung begegnen muss. Wobei, DevOps lässt hier grüßen. Und wer schon mal mit unseren Entwicklern in Berührung gekommen ist, kennt unsere repository-driven Ansätze für größere Umgebungen.

Resümee von mir: in-Memory OLTP lebt!

Donnerstag, 9. Juni 2016

SQL Server Missing Indexes Feature – Vorsicht!

Dieser kurze Post richtet sich primär an DBAs und Entwickler, welche vielleicht gerade damit begonnen haben sich mit dem Themen SQL Server, Performance Optimierung usw. zu beschäftigen.

Vielen dürfte das Missing Index Feature bekannt sein. Der Query Plan wird bei der Kompilierung durch den Query Optimizer um einen Index Vorschlag angereichert.

https://technet.microsoft.com/en-us/library/ms345417(v=sql.105).aspx 

Dieser Vorschlag wird auch prominent im Management Studio dargestellt.

image

Diese “Empfehlungen” entstehen im Bruchteil einer Sekunde beim Kompilieren eines SQL Statements. Und beziehen sich einzig allein das eine Statement bzw. die eine Prozedur. Schauen also nicht nach links und rechts.

Ich sehe in ihnen eher den plakativen Hinweis, dass selbst dem Query Optimizer in der Kürze der Zeit aufgefallen ist, dass es deutliches Potenzial gibt. Mehr sollte es nicht sein.

Also nicht jeden Vorschlag unreflektiert umsetzen! Ist ja eigentlich klar, oder?

Nun durfte ich bei einem Kunden die Erfahrung machen, dass im Internet (es ist doch böse, wusste es immer…) Skripte zu finden gibt, welche den Plancache des SQL Server für eine komplette Instanz auslesen, die Missing Indexes Informationen extrahieren und automatisch ALLE Empfehlungen umsetzen. Es werden also in allen Datenbanken einer Instanz ungeprüft neue Indexe erzeugt.

Das mag auf den aller ersten Blick ja eine super Idee sein, nur so hat selbst Microsoft dieses Feature nicht gemeint. Viel hilft nicht immer viel…

Indexe, speziell sogenannte abdeckende Indexe, sind eine gewollte Form der Redundanz von Daten. Es wird also Speicher belegt und Indexe müssen auch bei Schreibvorgängen gepflegt werden. Speziell komplexere Systeme wie zum Beispiel ein SharePoint mögen so etwas gar nicht.

Bei diesem Kunden führte eine solche “Maßnahme” dazu, dass quasi alle Anwendungen danach deutlich langsamer liefen als vorher. Von dem plötzlichen Wachstum um 2/3 auf dem Storage ganz zu schweigen.

Ich verzichte bewusst auf eine Verlinkung zu den Skripten, um diese nicht noch relevanter zum Thema erscheinen zu lassen.

Freitag, 3. Juni 2016

SQL Server 2016 – Business Intelligence Edition?

Nachdem nun der SQL Server 2016 verfügbar ist, schauen Kunden der SQL Server 2014 Business Intelligence Edition ein wenig ungläubig drein. Die BI Edition gibt es nicht mehr. Habe mir dazu die Hinweise auf der Lizenzierungsseite von Microsoft angeschaut.

Hier der O-Ton aus dem Licensing Guide für SQL 2016:

For SQL Server Business Intelligence Edition Licenses with Software Assurance

SQL Server 2014 was the last version of the SQL Server Business Intelligence Edition. Customers with active SA coverage on qualifying Business Intelligence Edition server licenses on June 1, 2016 are eligible to upgrade to and use SQL Server 2016 Enterprise (Server+CAL) software with those licenses.

During the current term of SA coverage (effective on or before June 1, 2016), customers who are licensing SQL Server 2014 Business Intelligence Edition can, for a given deployment, upgrade to and use the SQL Server 2016 Enterprise Edition (Server+CAL) software in place of the licensed SQL Server 2014 edition. Note: Customers who upgrade to SQL Server 2016 software are subject to current version Enterprise Edition server license product terms. 

Customers with Enterprise Agreements effective on or before June 1, 2016 can continue to acquire additional SQL Server 2014 Business Intelligence server licenses—and upgrade those licenses to SQL Server 2016—through the end of their current enrollment term, as long as the number of new licenses acquired does not exceed more than 25% of the number of qualifying licenses acquired as of May 1, 2016. 

After their current term expires, SA coverage can be renewed and maintained on SQL Server Enterprise Edition server licenses to provide continued access to SA benefits, including License Mobility rights, Failover Server rights, and access to future releases.

Denke mal, dass das fair klingt, oder?

Wie immer sind alle Lizenzierungshinweise hier von mir ohne jegliche Gewähr!

Donnerstag, 2. Juni 2016

SQL Server 2016 ist verfügbar – Was ist in welcher Edition?

SQL Server 2016 ist verfügbar. *jubel*

Selten wurde eine Version so von mir intensiv im Vorfeld verfolgt, weil sie gefühlt für jeden etwas spannendes Neues dabei hat.

Kommen wir zur Frage, welche Features haben es ins Release bzw. in welche Edition (Standard oder Enterprise) geschafft?

Zwar habe ich aufgrund meiner Kommunikation mit Microsoft als MVP und durch die weltweite SQL Community vor dem Release Einiges erfahren. Dieser Artikel geht aber bewusst unbefangen an das Thema und nimmt einzig und allein die offizielle Microsoft Seite dazu als Quelle.

https://msdn.microsoft.com/en-us/library/cc645993.aspx (Stand 02.06.2016)

Blättern wir also mal gemeinsam durch die Liste. Was fällt als Erstes auf? Wo ist die BI Edition hin?

image

Ein kurzer Blick auf die 2014 Version des oben genannten Links zeigt diese noch:

image

Das könnte evtl. zu Unruhe im Feld führen.

Abschnitt “Cross-Box Scale Limits”

Ein Blick auf “Maximum Compute Capacity” zeigt, dass die Standard Edition 2016 nun “Limited to lesser of 4 sockets or 24 cores” statt wie bei der 2014 “Limited to lesser of 4 Sockets or 16 cores” nutzen kann. Könnte sich als nützlich erweisen.

Nun wird es aber gleich richtig spannend:

image

Die Standard Edition der SQL Server Analysis Services (SSAS) unterstützt nun auch Tabular als Modell, wenn auch “nur” für 16 GB. Das ist sehr schön und war auch meiner Sicht auch schon ein wenig überfällig. Guter Zug, Microsoft!

Immer wieder schön zu lesen, dass die maximale Datenbank Größe 524 PB ist. Aber das nur am Rande.

Abschnitt “RDBMS High Availability”

Auf den ersten Blick keine Änderungen. Wobei mir mal so war, als sollten die Verfügbarkeitsgruppen in abgespeckter Form auch für die Standard Edition kommen. Das behalte ich mal im Auge und recherchiere dazu ein wenig nach.

Abschnitt “RDBMS Scalability and Performance”

Okay, dass es “Operational analytics” nicht in die Standard schafft, war klar, da sich hier ja sowohl “In-Memory Column Store” als auch “In Memory OLTP” die Hand geben. Dennoch, cooler Kram ist!

Und eine kleine Überraschung, dass es die “Stretch Database” in die Standard geschafft hat. Wobei, kurz drauf rum denken, macht Sinn, da es sich hier um den Einstieg in die Azure Welt für die SQL Server Kunden handelt. Nützliches Feature auf jeden Fall.

Und wo wir hier gerade sind, wem “Delayed Durability” noch Nichts sagt, mal nachlesen. Kann SEHR nützlich sein, wenn man sich bewusst ist, was man da tut.

Abschnitt “RDBMS Security”

Jetzt wird es schon wieder aufregend. Sowohl “Row-level security” als auch “Dynamic data masking” haben es in die Standard Edition geschafft. Wieder ein guter Zug. Dass es “Always Encrypted” nur für Enterprise gibt, nun ja, ist doch eigentlich auch ein Cloud Treiber, oder?

Abschnitt “Replication”

Noch ein Cloud Feature ist “Transactional replication to Azure”. Gibt es auch für Alle.

Abschnitt “Management Tools”

Da ist mir Nichts aufgefallen.

Abschnitt “Manageability”

Wieder Nichts. Vielleicht brauche ich auch nur einen weiteren Kaffee…

Abschnitt “Development Tools”

Bin mal kurz in der Teeküche. Wieder Nichts.

Abschnitt “Programmability”

Jetzt wird es ja richtig cool. Okay, Kaffee hilft halt immer.

image

Denke mal, dass dieses Bild für sich spricht, oder? Was ist denn jetzt eigentlich der Unterschied zwischen Basic und Advanced R ist, werde ich noch mit meinem Kollegen Tom Martens bei Gelegenheit näher erklären.

JSON, yeah…

Query Store, wow…

Temporal, Hammer… (und dann noch Strech…)

Microsoft, da habt ihr ja mal alles richtig gemacht!

Abschnitt “Integration Services”

image

Azure, Hadoop und HDFS. Schön, machst rund.

Abschnitt “Integration Services – Advanced Adapters”

Okay, da ist Name halt Programm. Mach ja auch Sinn.

Abschnitt “Integration Services – Advanced Transformations”

Okay, halt auch was für den größeren Geldbeutel. Wobei, da hätte ich mir auch mal etwas Neues gewünscht.

Abschnitt “Master Data Services”

Gibst weiterhin nur in der Enterprise Edition. Hat ja auch diverse Neuerungen erfahren. Es lebt zumindest.

Abschnitt “Data Warehouse”

Hat sich Nichts geändert.

Abschnitt “Analysis Services”

Nichts Neues.

Abschnitt “BI Semantic Model (Multidimensional)”

Auch hier nichts Neues.

Abschnitt “BI Semantic Model (Tabular)”

Jetzt aber, Tabular im Standard. Aber…

Keine Perspektiven, Partitionen und kein DirectQuery (Mist…). Wobei, dennoch ein guter Schritt.

Abschnitt “Power Pivot für SharePoint”

Alles weiterhin nur für die Enterprise Edition. Interessant wie sich der Teil weiter entwickeln wird, dank PowerBI.

Abschnitt “Data Mining”

Weiterhin gehen die Basics mit der Standard, der Rest mit der Enterprise. Hat da jemand gerade R gesagt?

Abschnitt “Reporting Services”

Nun gut, Mobile Reports, sprich das Datazen Universum, gibt es nur für die Enterprise. Damit war aber auch zu rechnen.

Abschnitt “Bussines Intelligence Clients”

Dieser Abschnitt ist nach wie vor ein wenig verwirrend. Klar, dass die Clients für mobile Reporting auch nur mittels der Enterprise Edition genutzt werden können.

Das mit PowerBI hätte man geschickter formulieren können, sonst denkt noch jemand, dass man dafür zwingend einen SQL Server Enterprise Edition bräuchte. Was natürlich nicht so ist. Das geht auch ganz ohne SQL Server und macht dennoch Spaß. Das sage ich nicht von Vielem!

Abschnitt “Spatial und Location Services”

Alles bleibt wie es war.

Abschnitt “Additional Database Services”

Nichts Neues.

Abschnitt “Other Components”

Schade, dass man hier ganz hinten im Bus “Data Quality Services” und “StreamInsight” findet. Hätte mir für beide Technologien mehr gewünscht. Zumindest sind sie noch dabei. Inwiefern der Einsatz für die breite Masse Sinn macht, sei dahin gestellt.

Und schon sind wir durch. In Summe hat Microsoft die Standard Edition aufgewertet und vieles von dem coolem Kram nicht nur in der Enterprise gelassen.

Natürlich sind alle Angaben in diesem Artikel unverbindlich und ohne Gewähr !