Sascha Lorenz - with a passion for massive SQL Server workloads

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 gen

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 Neuentwickl

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 (Column

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. 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 ei

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 ed

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? Ein kurzer Blick auf die 2014 Version des oben genannten Links zeigt diese noch: 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 “