Azure SQL VM – keine Möglichkeit den Plattenplatz zu konfigurieren

Ein Kunde hatte mich die letzten Tage gebeten, ihn bei der Optimierung eines SQL Servers auf einer Azure VM zu unterstützen. Der Kunde hatte immer mal wieder leichte Performance Probleme mit dem SQL Server, der Applikation Hersteller bzw Betreuer wollte oder konnte nicht mehr sagen bzw helfen. Von dort erhielten der Kunde erst einmal nur die Aussage, man empfehle für die DATA-Platten des SQL Servers eine Latenz von 5ms… ok, in Azure lässt sich dies offiziell nur mit ULTRA Disks erreichen. Ich möchte hier in diesem Beitrag nicht unbedingt auf das Wie eingehen, sondern nur auf einen Fehler, der mir im Rahmen der Analysen aufgefallen ist.

Erst einmal zur Erläuterung, ich habe mit dem Kunden gesprochen und ihm vorgerechnet was es kostet den Server mit 2 TB Ultra-Disks auszustatten und ob es nicht vielleicht sinnvoller und zielführender ist, den SQL Server auf „Herz und Nieren“ zu prüfen, zu optimieren (auch die Applikation bzw deren T-SQL) und im letzten Schritt notfalls doch auf Ultra-Disks zu gehen.

Der Kunde war einverstanden und gemeinsam haben wir den SQL Server einem Review unterzogen, auch wenn die Marketplace-Images von Microsoft (Danke an das Produktteam!) schon sehr gut konfiguriert sind, lässt sich doch noch das ein oder andere anpassen.

Azure SQL VM und die Data-Disks

Wenn man den Empfehlungen zu Azure SQL in einer virtuellen Maschine folgt, dann kann man dort in den Empfehlungen lesen:

Stripe multiple Azure data disks using Storage Spaces to increase I/O bandwidth up to the target virtual machine’s IOPS and throughput limits.

https://docs.microsoft.com/en-us/azure/azure-sql/virtual-machines/windows/performance-guidelines-best-practices-storage

In einem ersten Anlauf haben wir die 1TB Platte durch mehrere kleine Platten ersetzt, um den maximalen Throughput von 200MB auf 625MB zu erhöhen. Das hat soweit auch ohne Downtime funktioniert, der Kunde ist bisher sehr glücklich. Aber im Zuge dieser Arbeiten bin ich eben auch auf eine Meldung im Azure Portal an dieser virtuellen Maschine bzw der SQL Server Konfigurationsübersicht gestossen, mit der ich im ersten Moment nichts anfangen konnte und Google auch keinerlei Hilfe brachte.

Im Azure Portal gibt es die Möglichkeit für alle SQL Server innerhalb einer Azure VM entsprechend mehrere Extensions auszurollen, die den Administrator dabei unterstützen sollen, die VM bzw den SQL Server über Powershell, Azure CLI oder das Portal zu administrieren und deren Daten in Logs und Metrics darzustellen. Hierzu nutzt Microsoft unter anderem den „SQL Server IaaS Extension Query Service“ oder „SQL Server IaaS Agent extension“, beide sammeln Daten aus der virtuellen Maschine und dem SQL Server und stellen diese nutzerfreundlich im Portal dar. Leider war das bei diesem Kunden und dieser VM nicht zu 100% verfügbar, wie der folgende Screenshot zeigt.

Auch in der weiteren Übersicht „Configure“ waren keine Daten zum Storage ermittelbar, obwohl alle Extensions auf dem Server ausgerollt waren und auch nach einem/mehreren Reboots keinerlei Daten anzeigten. Also bin ich auf die Suche nach der Ursache gegangen…

Extension-Log und fn_trace_gettable

Wie man der Microsoft-Dokumentation entnehmen kann, gibt es unterschiedliche Modis, für unterschiedliche Anforderungen und natürlich kann man hier auch entnehmen, dass es ein lokales Errorlog gibt, welches man unter Umständen zur Fehlersuche nutzen kann. Bei diesem Errorlog handelt es sich um ein XE-File und ein Tracefile, beide nicht mit dem Notepad sondern nur SQL Server Management Studio lesbar… also blieb nichts anderes, als kurzerhand mit einer T-SQL Systemfunktion auf das Tracefile zuzugreifen, um festzustellen, dass der Systemuser anscheinend keinerlei oder zu wenige Berechtigungen hat. Normalerweise befindet sich die Extension direkt auf dem C-Laufwerk im Verzeichnis C:\SQLIaaSExtension, so dass man diesen Pfad in der SQL Abfrage entsprechend nutzen muss.

SELECT * FROM fn_trace_gettable('C:\SQLIaaSExtension\Log\log.trc', default);  
GO  

Durch die Ausführung dieses T-SQL Statements zum Auslesen des Extension-Logfiles, erhielt ich unter anderem die folgende Zeile :

alter server role [sysadmin] add member [NT Service\SQLIaaSExtensionQuery]

Bei der Suche nach dem User musste ich dann feststellen, dass der Kunde diesen User – warum auch immer – gelöscht hat (später stellte ich fest, dass dies anscheinend nicht „per accident“ passiert ist, sondern bewusst, denn auf anderen SQL Servern in Azure fehlt der User ebenfalls)

USE [master]
GO

/****** Object:  Login [NT SERVICE\SqlIaaSExtensionQuery]    Script Date: 5/10/2021 3:35:08 PM ******/
DROP LOGIN [NT SERVICE\SqlIaaSExtensionQuery]
GO

/****** Object:  Login [NT SERVICE\SqlIaaSExtensionQuery]    Script Date: 5/10/2021 3:35:08 PM ******/
CREATE LOGIN [NT SERVICE\SqlIaaSExtensionQuery] FROM WINDOWS WITH DEFAULT_DATABASE=[master], DEFAULT_LANGUAGE=[us_english]
GO

ALTER SERVER ROLE [sysadmin] ADD MEMBER [NT SERVICE\SqlIaaSExtensionQuery]
GO

Testweise habe ich diesen User erneut angelegt, berechtigt und im Azure Portal überprüft, ob es eine Veränderung in den Ansichten gibt… Ja, die SQL Server IaaS Agent Extension kann nun wieder auf den SQL Server zugreifen und die notwendigen oder relevanten Daten auslesen.

Björn Peters

Björn arbeitet auch weiterhin aus Mexiko als Senior Consultant – Microsoft Data Platform und Cloud für die Kramer&Crew in Köln. Auch der Community bleibt er aus der neuen Heimat treu, er engagiert sich auf Data Saturdays oder in unterschiedlichen Foren. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure SQL für Science-Fiction, Backen 😉 und Radfahren.