Mittwoch, 20. Juli 2016

SQL Server In-Memory OLTP – Isolation Level Beispiele

Wie schon mal von mir erwähnt, erlebe ich bei den Teilnehmern meiner SQL Server In-Memory OLTP Workshops die meisten Schwierigkeiten bei der Verwendung der “neuen” Isolation Level. Zwar klingen für viele Entwickler die Level SNAPSHOT, REPEATABLE READ und SERIALIZABLE vertraut, nur schon bei den SQL Server “disk-based” Tabellen haben die wenigsten diese aktiv genutzt. Standard ist häufig READ COMMITED und das ist auch gut so. Die Tatsache, dass In-Memory OLTP aber ohne Sperren auskommt, fühlt sich für die meisten Entwickler erstmal befremdlich an.

Zwar haben wohl die meisten Interessierten schon mal die Microsoft PowerPoints mit einer Erklärung des Version Stores gesehen und sich gefreut, wie schön da Versionen von Zeilen nebeneinander koexistieren können. Nur wie sieht das in der Praxis für den Entwickler aus?

Der deutsche Begriff für die Technologie In-Memory OLTP “Arbeitsspeicheroptimierung” trifft es irgendwie nicht ganz. Zwar wird der Arbeitsspeicher wesentlich optimierter genutzt, dennoch klingt das im Deutschen schon unspektakulär, oder?

In-Memory OLTP wurde entwickelt, um äußerst schnelle Lösungen zu ermöglichen. Auch wenn man mittels altbekanntem T-SQL mit dieser Engine arbeitet und diese auch hybride Lösungen mit den nun  “disk-based” Tabellen (also den guten alten 8kb-lastigen Strukturen) ermöglicht, so ist es doch eine durch und durch neue Engine. Und vieles was die gute alte Engine an Schlamperei bei der Programmierung einfach mal geschluckt hat, funktioniert nun nicht mehr. Dafür ist In-Memory OLTP einfach zu spezialisiert auf Geschwindigkeit. Spontane Flexibilität wird da schwierig.

Zur Erinnerung: Isolation Level bestimmen in der Welt der pessimistischen Level wie lange ein Shared Lock auf einem Datensatz oder gar auf einen Bereich aufrecht erhalten wird. Wenn ein Datensatz exklusiv gesperrt ist, dann kann er nicht gelesen und erst recht nicht geändert werden. Also, es kommt in einer Transaktion ein SELECT daher und verhindert durch den verwendeten Isolation Level, dass andere Transaktionen Daten ändern oder ergänzen können. Die Transaktion mit der Änderung (UPDATE, DELETE usw.) bleibt einfach hängen (Blocking genannt…), da ja kein rankommen an die Daten ist. Ist ja ein Shared Lock drauf. 

In der optimistischen Welt der In-Memory OLTP Engine ist das alles anders. Und ja, auch schon früher konnte man mit optimistischer Isolation arbeiten, nur haben das die wenigsten Entwickler genutzt. Die Wahl hat man nicht mehr, wenn man wenn es nun “ein wenig” schneller haben möchte.

Durch den Version Store von In-Memory OLTP können nun mehrere Versionen einer Datenzeilen parallel existieren und jede Transaktion sieht die für sich gültigen Zeilen. Liest sich doch ganz einfach, oder? Wie ist das jetzt aber bei Änderungen? Und wenn jeder seine “Wahrheit” sieht, wer hat dann am Ende recht?

Abgesehen von zwei Ausnahmen (Wobei es sich eigentlich nur um eine handelt…), lässt der SQL Server erstmal alle Änderungen zu. Erst beim COMMIT einer Transaktion wird geprüft, ob es Abhängigkeiten gibt, welche einen Fehler auslösen müssen. Und, um es nun noch ein wenig interessanter zu gestalten, im Gegensatz zum pessimistischen Modell, können nun SELECTs im Nachhinein ungültig sein.

Gehen wir ein paar Beispiele einfach mal durch.

Hier sehen wir, dass ein einfaches SELECT problemlos läuft. Nichts anderes haben wir erwartet, oder?

image

Was ist das? Sobald wir eine explizite Transaktion aufmachen und ein SELECT ausführen, gibt es einen Fehler.

image

Meldung 41368, Ebene 16, Status 0, Zeile 5
Accessing memory optimized tables using the READ COMMITTED isolation level is supported only for autocommit transactions. It is not supported for explicit or implicit transactions. Provide a supported isolation level for the memory optimized table using a table hint, such as WITH (SNAPSHOT).

Wir lernen aus der Fehlermeldung, dass wir einen Isolation Level benötigen, wenn wir mit transaktionalen Klammern arbeiten. In den folgenden Beispielen setze ich daher einen Table Hint (WITH SNAPSHOT).

Und schon funktioniert unsere einfache Abfrage.

image

Kommen wir zu spannenderen Dingen. Wir öffnen eine weitere Session und führen ebenfalls ein SELECT in einer Transaktion aus. Wichtig hierbei, wir schließen diese noch nicht.

image

Probieren wir mal ein einfaches UPDATE.

image

Ups, ja klar. Ein UPDATE muss ja auch lesen was es so löschen möchte. Also brauchen wir auch hier einen Isolation Level.

Und schon funktioniert das UPDATE in Session 63. Als wir versuchen die selbe Zeile zu ändern, laufen wir in einen Fehler. In der pessimistischen Welt wären wir hier hängen geblieben.

image

Meldung 41302, Ebene 16, Status 110, Zeile 34
The current transaction attempted to update a record that has been updated since this transaction started. The transaction was aborted.

Wir lernen daraus, dass die SQL Server In-Memory OLTP Engine aufpasst, dass wir nichts überschreiben, was in einer anderen Session bereits geändert wurde.

Bei einem DELETE hätten wir übrigens den gleichen Fehler erhalten.

So, kommen wir zu einem INSERT.

Erst machen wir in 63 ein INSERT mit der ID 4 und dann ein INSERT in 62 mit der ID 4. Und schon haben wir zwei Zeilen mit der identischen ID. Autsch.

image

Nun kommt es darauf an, wer zuerst ein COMMIT ausführt.

image

Und wir sehen, dass es nur einen geben konnte (Sorry…). Dennoch gab es einen Moment in der Vergangenheit, in dem mindestens zwei Wahrheiten existierten. Damit sollte der Entwickler umgehen lernen.

Und wo wir gerade bei zwei Wahrheiten sind. Können wir unsere zwei Versionen einer Zeile jeweils auch ändern?

image

Nein, das schlägt auch gleich fehl.

Wie schaut es noch generell mit DELETES aus?

Wir haben wieder zwei Sessions. Beide zeigen das gleiche Resultset.

image

Nach einem DELETE in 63 verschwindet dort unsere ID 4. In Session 62 ist diese aber noch dabei, da diese auf eine alte Version der Zeile zeigt.

image

Das bleibt so lange, wie die Session 62 ihre Transaktion nicht schließt. Ein COMMIT in 63 hilft da nicht weiter.

image

Erst das Beenden der Transaktion in 62 zeigt auch hier die letzte wahrhaftige Wahrheit. Auch dessen sollte sich ein Entwickler bewusst sein.

image

Nun kommen wir zu den wirklich interessanten Dingen. Steigern wir den Isolation Level und gehen auf REPEATABLEREAD. Bitte dran denken, dass die Verwendung der höheren Level unter Last auch messbar wird!

Wir starten wieder von vorne. In 63 öffnen wir eine Transaktion und lesen unsere Tabelle. In 62 führen wir ein UPDATE durch. Die Transaktion sparen wir uns, damit entfällt auch die Notwendigkeit für einen Table Hint.

image

Nun haben wir in 63 die alte Version und in 62 sehen wir schon die neue Version.

image

Unsere Transaktion liest im Step 21 aber fleißig wiederholt unsere Tabelle. Und bekommt den alten Stand geliefert.

image

Und nun wird es unangenehm. Ein COMMIT in der Session 63 führt zu einem Fehler. Aber wir haben doch nur gelesen?! Warum?

Weil die SQL Server In-Memory OLTP Engine ERST beim COMMIT eine Überprüfung durchführt, ob die ISOLATION LEVEL denn auch eingehalten worden sind. Wie schon erwähnt, kann also ein SELECT im Nachhinein fehlschlagen. Der Entwickler hat auf Basis der Daten gearbeitet, muss sich aber bewusst sein, dass er evtl. schon in einer alten Realität agierte und ihm sein Code um die Ohren fliegt.

image

Meldung 41305, Ebene 16, Status 0, Zeile 96
The current transaction failed to commit due to a repeatable read validation failure.

Wie schaut es mit INSERTs und REPEATABLEREAD aus? Probieren wir das einfach mal aus.

In 63 öffnen wir die Transaktion und schauen uns die Daten an. Dann schreiben wir in 62 eine neue Zeile, welche dort auch sichtbar ist.

In Step 25 sehen wir, dass uns in 63 weiterhin die alte Version gezeigt wird.

image

Erst ein Schließen der Transaktion führt dazu, dass wir den aktuellen Stand sehen. INSERTs führen also NICHT zu Fehlern bei REPEATABLEREAD. Dafür können neue Zeilen unvermittelt erscheinen.

image

Auf zum nächsten Level. Alles noch mal, nun mit SERIALIZABLE.

In 63 sehen wir unsere Daten und in 62 fügen wir eine Zeile hinzu. In Step 29 schauen wir mal wieder nach unseren Daten und sehen die Zeile nicht.

image

Erst das COMMIT in 63 zeigt, was dieser Isolation Level bewirkt. Er verhindert, dass im Lesebereich, der war hier jetzt ganz grob die ganze Tabelle, alte Versionen gelesen werden können und führt nach Ende der Transaktion zu einem Fehler.

Wichtig, nicht das INSERT schlägt fehl, sondern das SELECT, welches in der Vergangenheit einen ungültigen Stand der Daten las. Nochmals, In-Memory OLTP prüft erst beim COMMIT, ob die Isolation Level eingehalten wurden!!!

image

Meldung 41325, Ebene 16, Status 0, Zeile 128
The current transaction failed to commit due to a serializable validation failure.

Diese noch recht einfachen Beispiele zeigen schon sehr deutlich, dass existierender T-SQL Code in aller Regel gründlich überarbeitet werden muss für die Nutzung von In-Memory OLTP. Ja, das bedeutet Aufwand. Nur dieser ist meiner Erfahrung nach mehr als gerechtfertigt, wenn man den deutlichen Performance Gewinn für seine Lösung sieht.

Ich habe bewusst unterwegs ein paar technische Details übersprungen, damit sich das Thema halbwegs zügig liest. Dieser Post ist nicht als Schulungsersatz für die Verwendung von In-Memory OLTP gedacht, sondern um bewusst zu machen, dass es da Arbeit gibt.

Für viele Entwickler (und Entwicklerinnen…) mag sich nach dem Lesen dieses Posts In-Memory OLTP nun noch ein wenig schräger anfühlen als schon vorher, nur gerade aus den gezeigten Mechaniken zieht diese Engine ihre unglaubliche Geschwindigkeit. Probiert sie einfach mal aus!

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 !

Mittwoch, 4. November 2015

SQL Server 2016 "R" in Reporting Services zur Implementierung eines IBCS Charts

Heute möchte ich kurz auf einen Post meines PSG Kollegen Thomas Martens (kurz Tom) hinweisen:

Er ist u.a. Experte für die Sprache “R” und beschäftigt sich schon einige Jahre mit diversen Implementierungen von fortgeschrittenen Algorithmen. Um so erfreuter war er, als bekannt wurde, dass Microsoft in dem kommenden SQL Server 2016 “R” integrieren wird.

Neben der Nutzung von “R” für komplexe finanzmathematische und statistische Herausforderungen ist ein weiteres Steckenpferd vom Tom die Entwicklung von individuellen Visualisierungen mittels des “R”-Paketes GGPLOT2.

Daher hat er es sich nicht nehmen lassen quasi Stunden nach der Verfügbarkeit des CTP 3 ein erstes Beispiel in seinem Blog zu posten.

https://minceddata.wordpress.com/2015/11/03/they-walk-in-line-sql-server-2016-reporting-services-and-r-charting-using-ggplot2-2/

Dabei handelt es sich einfach gesagt um einen SSRS Report, welcher mittels eines “R”-Skriptes Daten aus einer SQL Server Tabelle und SSRS Parameter nutzt, um dann mit GGPLOT2 eine Umsetzung eines IBCS Charts live zu rendern.


Das eröffnet der Nutzung des SQL Servers und der Reporting Services ganz neue Dimensionen!


Tom scharrt schon mit den Füssen, weil “R” auch für seinen Liebling Power BI angekündigt wurde. Ich bin gespannt.

Dienstag, 24. März 2015

Data Vault in der SQL Server Data Warehouse Welt

Meine Session auf der SQL Server Konferenz 2015 in Darmstadt zeigte mir, dass das Thema Data Vault durchaus polarisiert. Und da ich bei immer mehr Kundensituationen von uns auf Interesse zum Thema Data Vault treffe bzw. auch schon erste Architekturen vorfinde, möchte ich hier mal wieder ein paar Worte zu meiner Sicht der Lage äußern.

Meinem Verständnis nach brachte die Diskussion der letzten Monate um die Vor- bzw. Nachteile des Einsatzes der Data Vault Modellierung einen notwendigen frischen Wind in die Data Warehouse Welt. Und zwar jenseits des allgemeinen Big Data Hypes.

Data Vault kann durchaus als eine besondere Form des Stagings verstanden werden, wobei ich DV eher als einen Ansatz für die Modellierung eines Core Data Warehouses verstanden habe. Des Weiteren stellt Data Vault die rohen, unveränderten Daten in den Vordergrund. Die Idee dahinter ist, dass es keine einheitliche Wahrheit in einem Data Warehouse geben kann. Diese “Wahrheit” ist häufig durch eine Interpretation geprägt. Gerade die Suche nach der vermeintlich vorhanden Wahrheit in den Daten lässt viele Data Warehouse und Business Intelligence Projekte scheitern oder zumindest in Schönheit sterben.

Inwieweit passt nun die Data Vault Modellierung (& Nutzung) in die Microsoft Welt?

Das klassische Data Warehouse basiert auf relationalen Datenbanken. Die Bewirtschaftung mittels ETL- oder ELT-Strecke erfolgt meist mit einem Mix von SSIS und T-SQL Komponenten. Im Übrigen liegen häufig gerade in der Konzeptionierung der Strecke viele zukünftige (und zum Teil versteckte und damit nicht wahrgenommene) technische Schulden.

Eine bekannte Herausforderung bei DWH Projekten ist, dass sich diese häufig nicht wirklich eignen für agile Projektstrukturen. Auf der anderen Seite sterben viele DWH Projekte gerade wegen den sonst häufig starren Steuerungsstrukturen einen grausamen und meist auch teuren Tod. Es gibt mittlerweile eine Reihe von valide Ansätze den agilen Ansatz in die Data Warehouse Welt zu tragen, dennoch empfinde ich viele Ansätze, welche ich so vorfinde, als eher einen agil geprägten Projektverlauf, sprich völliges Chaos.

Data Vault kann tatsächlich mehr Agilität in DWH Projekte bringen. Ein Grundsatz im DV ist, dass es nur zusätzliche Objekte geben kann und keine Änderungen an bestehenden Strukturen durchgeführt werden. Durch diese und andere klare Regeln ist die Modellierung eines Data Vault erstaunlich stringent und passt sich dennoch dem unruhigen Fahrwasser im Datengeschäft an. 

Wichtig ist es dennoch nochmals hervorzuheben, dass ein Data Vault eben gerade nicht die traditionellen Data Warehouse Modellierungsmethoden ablösen will oder sollte. Meinem Verständnis nach ist es eine sinnvolle Ergänzung einer DWH Architektur. Primär wird sie von mir genutzt, um Quellen zu harmonisieren und ihre Strukturen homogen zu gestalten. Das vereinfacht die weitere Nutzung dieser Daten in der DWH Strecke ungemein. Gerade im Kontext Verarbeitung von Daten in Echtzeit kann diese Investition helfen.

Braucht nun wirkliches jedes (neue) Data Warehouse ein Data Vault? Eher nicht. Es kommt wie so häufig mal wieder drauf an.

Für mich ist der Grad an Stabilität eines geplanten Data Warehouses entscheidend. Inwiefern werden die Quellen als auch die Anforderungen stabil bleiben oder ist mit diversen Erweiterungen und Änderungen zu rechnen? Sofern diese Frage nicht beantwortet werden können oder die Antwort nicht belastbar genug ist, empfehle ich den Einsatz eines Data Vaults, um ein wenig Ruhe in die Strukturen zu bekommen.

In Abgrenzung zu klassischen DWH Modellierungen liefert das Data Vault Konzept auch Muster für die Bewirtschaftung mit. Unter anderem ist die Wiederholbarkeit von Bewirtschaftungsjobs möglich ohne sich mit der Herausforderung von möglichen Dubletten beschäftigen zu müssen. Wer sich schon länger mit DWH Umgebungen beschäftigt, weiß diese Eigenschaft durchaus schätzen zu lernen. 

Wenn wir kurz noch gedanklich in der SQL Server Welt bleiben, stellen sich natürlich Fragen, wie denn nun ein Data Vault zum Beispiel mittels der Analysis Services genutzt werden können. Diese erwarten ja einen klassischen Stern als Quelle. Meiner Erfahrung nach nutzen hier viele Anwender zurzeit die Option den Zugriff direkt mittels Views zu realisieren. Mit einer solchen Architektur bin ich nicht immer einverstanden, da ich gerade bei größeren Cubes hier durchaus Probleme bei der Verarbeitung erlebt habe. Häufig wird das Persistieren des Data Mart für einen Würfel als zu umständlich und zeitraubend angesehen. Es gilt noch belastbare Konzepte durch Lab Arbeit und Projekt Erfahrung zu sammeln, um diese Frage zufriedenstellend beantworten zu können.

Freitag, 6. Februar 2015

Dienstag, 9. Dezember 2014

10 Jahre SQL Server Usergroup in Hamburg – PASS Deutschland e.V. feiert !

Hallo PASS’ler im Norden,

hiermit möchten wir zu einem besonderen Treffen der Regionalgruppe Hamburg einladen!

Es gibt etwas zu feiern! Die PASS Deutschland besteht seit 10 Jahren, im Oktober haben wir uns in der Regionalgruppe zum 100. Mal getroffen und wir wollen mit Euch gemeinsam das Jahr gemütlich ausklingen lassen. Deswegen gibt es leckeres Essen und eine Verlosung von Überraschungspreisen.

Bitte bringt gern Kollegen und Freunde mit, die sich auch mit dem SQL Server beschäftigen. Wir freuen uns auf Euch!

Donnerstag, 11. Dezember 2014,
18:00 Uhr bis ca. 20:30 Uhr,
(Vortrag beginnt ab 18:30 und geht bis ca. 20:30 Uhr, davor sorgen wir dafür, dass ihr nicht verhungert…)

in der MICROSOFT Niederlassung Hamburg (Adresse unten)

Thema: SQL Server Data Tools für Datenbankentwickler von Peter Horst
”Wir werden das Entwickeln von Datenbankanwendungen mit den Microsoft SQL Server Data Tools kennenlernen. Themen wie Delta-Deployment auf unterschiedliche Datenbankschemaversionen, Refactoring, Code-Analyse & Datenbank Unit Test werden nicht fehlen.”

Wir treffen uns bei:
Microsoft Deutschland GmbH
Geschäftsstelle Hamburg
Gasstraße 6a
22761 Hamburg

Kostenlose Parkplätze befinden sich hinter dem Gebäude. Der Parkplatz ist
über die Rampe mit dem Schild "Microsoft Kunden" erreichbar.

Nur wenige Minuten zu Fuß ist der S-Bahnhof Bahrenfeld entfernt (S1/S11).

Ansprechpartner vor Ort: MS Empfangs-Team, Cornelia Matthesius und Sascha Lorenz.

Wir bitten um eine vorherige Anmeldung per Email an: slo@sqlpass.de

Wichtig: Wir benötigen die Anmeldungen 2 Tage vor dem Treffen, da wir uns
2014 bei Microsoft treffen können und dort Besucherausweise ausgestellt
werden! Spontane Teilnehmer sind dennoch willkommen. ;-)