Blog
Tuesday, 29. November 2022

Verbessern Sie die Skalierbarkeit in SQL Server 2022

Kristóf
IT-Consultant

In den vergangenen SQL Server-Versionen hat Microsoft die Parallelität und Skalierbarkeit der tempdb-Datenbank verbessert. Welche Bereiche die Verbesserungen umfassen und welche Konfliktbereiche wie behoben wurden wird in diesem Artikel näher erläutert.

Ab SQL Server 2016 beziehen sich mehrere Verbesserungen auf Best Practices im Einrichtungsprozess, d. h. wenn mehrere tempdb-Datendateien vorhanden sind, werden alle Dateien automatisch um den gleichen Betrag vergrößert.

Darüber hinaus hat Microsoft ab SQL Server 2019 die speicheroptimierte Metadatenfunktion zu tempdb hinzugefügt und die meisten PFS-Konflikte mit gleichzeitigen PFS-Updates beseitigt.

In SQL Server 2022 adressiert Microsoft nun einen weiteren gemeinsamen Konfliktbereich, indem es gleichzeitige Aktualisierungen der Global Allocation Map (GAM) und der Shared Global Allocation Map (SGAM) einführt. Die Funktion „Gleichzeitige GAM-Updates“ in SQL Server 2022 fügt die Funktion für gleichzeitige GAM- und SGAM-Updates hinzu, um tempdb-Konflikte zu vermeiden. Dadurch werden Kunden-Workloads viel skalierbarer und bieten einen noch besseren Durchsatz.

SQL Server hat tempdb in jeder einzelnen Version verbessert und SQL Server 2022 ist da keine Ausnahme.

Kurz zu tempdb

Tempdb ist eine Systemdatenbank, die allen Benutzern zur Verfügung steht, die mit einer Instanz von SQL Server, Azure SQL-Datenbank oder Azure SQL Managed Instance verbunden sind. Wie der Name schon sagt, wurde die tempdb-Datenbank für die temporäre Speicherung entwickelt. Was bedeutet, dass nichts dauerhaft gespeichert werden soll, was in tempdb geschrieben wurde.
Wichtig zu wissen ist, dass SQL Server zwar die tempdb-Datenbank für fast jede SQL Server-Workload verwendet, es aber nur eine tempdb pro SQL Server-Instanz gibt.

tempdb ist eine globale Ressource, die Folgendes enthält:

  • Temporäre Benutzerobjekte, die explizit erstellt werden. Dazu gehören globale oder lokale temporäre Tabellen und Indizes, temporär gespeicherte Prozeduren, Tabellenvariablen, Cursor und Tabellen, die in Tabellenwertfunktionen zurückgegeben werden.
  • Interne Objekte, die die Datenbank-Engine erstellt. Sie beinhalten:
    • Arbeitstabellen zum Speichern von Zwischenergebnissen für Spools, Cursor, Sortierungen und temporäre Speicherung großer Objekte (LOB).
    • Arbeitsdateien für Hash-Join- oder Hash-Aggregat-Operationen.
    • Sortierzwischenergebnisse für Vorgänge wie das Erstellen oder Neuerstellen von Indizes (wenn SORT_IN_TEMPDB angegeben ist) oder bestimmte GROUP BY-, ORDER BY- oder UNION-Abfragen.
    • Jedes interne Objekt verwendet mindestens neun Seiten. Eine IAM-Seite und einen achtseitigen Extent. Weitere Informationen zu Seiten und Blöcke finden Sie unter Seiten und Blöcke.
  • Version stores sind Sammlungen von Daten-Seiten, die Informationen über einzelne Zeilen bereitstellen und die Versionierung auf Zeilen-Ebene ermöglichen. Hierbei unterscheidet man zwischen zwei unterschiedlichen Typen: (1) ein sog. gemeinsamer oder geteilter version store, oder (2) ein sog. online-index-build version store. Die version stores umfassen:
    • Zeilenversionen, die durch Datenänderungstransaktionen in einer Datenbank generiert werden, die READ COMMITTED über Zeilenversionsisolations- oder Snapshot-Isolationstransaktionen verwendet.
    • Zeilenversionen, die durch Datenänderungstransaktionen für Funktionen wie Online-Indexoperationen, Multiple Active Results Sets (MARS) und AFTER-Trigger generiert werden.

Vorgänge innerhalb von tempdb werden minimal protokolliert, sodass Transaktionen rückgängig gemacht werden können. tempdb wird bei jedem Start von SQL Servern neu erstellt, sodass das System immer mit einer sauberen Kopie der Datenbank startet. Temporäre Tabellen und gespeicherte Prozeduren werden beim Trennen automatisch gelöscht und es sind keine Verbindungen aktiv, wenn das System heruntergefahren wird.

tempdb muss nie von einer Sitzung von SQL Server zu einer anderen gespeichert werden. Sicherungs- und Wiederherstellungsvorgänge sind auf tempdb nicht zulässig.

Tempdb-Performance-Herausforderungen

In der Vergangenheit war tempdb einer dieser häufigen Schmerzpunkte in SQL Server. Warum war es ein Schmerzpunkt? Nun, die Nutzung ist einer der Hauptgründe. Durch die Verwendung bezieht sich Microsoft auf das Erstellen von temporären Tabellen und anderen Benutzerobjekten, aber tempdb wird auch intern verwendet, um diese auf die Festplatte zu übertragen, wenn nicht genügend Arbeitsspeicher für einen Prozess verfügbar ist oder eine ungenaue Schätzung vorliegt, die dazu führt, dass SQL Server in tempdb übergeht.

Tempdb workloads

Der Hauptunterschied zwischen tempdb und anderen Datenbanken ist die Arbeitslast. Mit tempdb erstellen und löschen wir ständig Objekte wie temporäre Tabellen. Dies gilt insbesondere in intensiven OLTP-Umgebungen, in denen möglicherweise Threads viele verschiedene Aufgaben erledigen. Die Auswirkungen werden verstärkt, wenn sie bereits Ressourcenkonflikte auf dem System sehen.

Was wird in tempdb gespeichert?

  • Temp-Tabellen und Tabellenvariablen sind möglich in tempdb, das ist normalerweise der erste Objekttyp, an den wir denken. Wenn Sie also eine temporäre Tabelle in einer gespeicherten Prozedur oder in einem regulären Stapel erstellen, wird diese an tempdb gesendet.
  • Version stores auf Zeilen-Ebene werden in der tempdb verarbeitet, wenn die sog. Snapshot-Isolation verwendet wird. Bei einem lesenden Zugriff wird dann der Wert eines bestimmten Snapshots aus der Tempdb zurückgegeben, statt der aktuell in der Tabelle befindliche. So kann garantiert werden, dass selbst während manipulativen Transaktionen ein konsistentes Abbild einer Zeile oder Tabelle gelesen werden kann.
  • Hash-Vorgänge werden in tempdb übertragen. Arbeitstabellen werden auch für Spools, Cursor, Sortierungen und den temporären Speicher für große Objekte (LOB) verwendet – dies alles wird an tempdb gehen.
  • Trigger verwenden den Zeilenversionsspeicher in tempdb – dieser wird an tempdb weitergeleitet.
  • Online-Indexoperationen – Wenn Sie Ihre Indizes mit dem Schlüsselwort ONLINE ON verwalten, werden temporäre Schattenkopien in tempdb erstellt.
  • auch DBCC CHECKDB erstellt Schattenkopien in tempdb

Wie Sie sehen können, gibt es eine Menge Dinge, die in tempdb einfließen. Tempdb wird für Benutzerobjekte wie globale oder lokale temporäre Tabellen und Indizes, gespeicherte Prozeduren, Tabellenvariablen, Tabellenwertfunktionen und Cursor verwendet. Aber wir verwenden tempdb auch für interne Szenarien, wie z. B. Überläufe auf die Festplatte und als Arbeitstabellen, die Zwischenergebnisse für Spools und Sortierungen speichern.

Leistungspakete der Mainzer Datenfabrik

Als professioneller SQL Server Support und zertifizierter Microsoft Partner unterstützen wir Sie in allen Fragen und individuellen Problemen rund um Ihre Serverumgebung, egal ob vor Ort oder remote. Überzeugen Sie sich selbst von unserem vielfältigen Angebot und den individuellen Leistungspaketen.

SQL Server Assessments & Support Windows Server

Was verursacht Konflikte in tempdb?

Da tempdb für so viele verschiedene Szenarien verwendet wird, gibt es nur eine tempdb-Datenbank pro SQL Server-Instanz. Dadurch, dass Microsoft begann auf größere Computer mit größeren Workloads zu pushen, konnten Parallelitätsprobleme im tempdb-Bereich aus drei Schlüsselbereichen beobachtet werden:

  • Objektzuweisungskonflikt
  • Metadatenkonflikt
  • Konflikt zwischen temporärem Tabellencache

Objektzuweisungskonflikt

Tempdb ist wie jede andere Datenbank strukturiert, aber die Workloads sind in tempdb anders, sodass Objektzuweisungskonflikte aufgrund der ständigen Erstellung und Löschung von Objekten eine größere Bedeutung haben.

Auf einem Server, auf dem Objektzuweisungskonflikte auftreten, stellen Sie möglicherweise eine schwerwiegende Blockierung fest, insbesondere wenn der Server stark ausgelastet ist. Infolgedessen werden die Arbeitslasten von SQL Server verlangsamt, aber die CPU des Servers scheint eventuell nicht ausgelastet zu sein. Dies liegt daran, dass sich der Konflikt in den Systemmetadaten befindet.

Für tempdb war es schon immer eine der wichtigsten Best Practices, mehrere primäre Datendateien (mdf) mit derselben Größe und derselben Wachstumsrate zu erstellen. Ziel war es, den Objektzuweisungskonflikt zu verringern, indem die tempdb-Aktivität auf mehrere Partitionen verteilt wurde.

SQL Server-Datenbanken müssen eine primäre Datendatei haben, die standardmäßig die Dateierweiterung .mdf verwendet, und eine Protokolldatendatei, die die Dateierweiterung .ldf verwendet. Die primäre tempdb-Datendatei tempdb.mdf verfügt über Schlüsselseiten, die nachverfolgen, wie Objekte in SQL Server zugewiesen werden.

Global Allocation Map (GAM) & Shared Global Allocation Map (SGAM)

Global Allocation Map (GAM) & Shared Global Allocation Map (SGAM)

Seite 0 ist eine Kopfseite, und dies gilt für alle primären oder sekundären Datendateien in SQL Server.

Seite 1 ist eine sogenannte PFS-Seite (Page Free Space), die immer dann verwendet wird, wenn SQL einem Objekt Speicherplatz zuweisen muss. Grundsätzlich enthält die PFS-Seite Informationen darüber, wie voll die Seiten für die nächsten 8088 Seiten in der Datenbank sind. Wenn SQL Server einige Daten hinzufügen muss, verwendet SQL Server die PFS-Seite, um die Zuordnung vorzunehmen.

Nach 8088 Seiten gibt es eine weitere PFS-Seite in derselben Datendatei – sie wiederholt sich. Sie haben also mehr als eine PFS-Seite, je nachdem, wie groß die Datei ist.

Seite 2 ist immer die Global Allocation Map (GAM). Hier kommt die Extent-Zuordnung ins Spiel, da die GAM nachverfolgt, wann SQL Server einen einheitlichen Extent zuweisen muss.

Ein Extent in SQL Server besteht aus 8 x 8-KB-Seiten, 64 KB, und dies ist normalerweise die Einheit der Datenzuweisung. Wenn Sie demnach eine Tabelle haben, die größer als acht Seiten ist, erstellen wir jedes Mal bei der Zuweisung von Speicherplatz einen vollständigen Extent. Dieser ist ein einheitlicher Extent, da alle acht Seiten zu diesem Objekt gehören.

Jedes Mal, wenn SQL einem Objekt einen einheitlichen Extent zuweisen muss, wechselt SQL zur GAM-Seite und prüft die Verfügbarkeit. Das GAM ist eine Bitmap. Wenn also das Bit 1 ist, ist dieser Extent verfügbar, um zugewiesen zu werden. Bei 0 i ist er nicht verfügbar und kann nicht zugewiesen werden. Sobald SQL Server den Extent zugewiesen hat, ändert es einfach das Bit für diese GAM-Seite von 1 auf 0, wodurch angezeigt wird, dass es nicht mehr verfügbar ist.

Je größer die Datei, desto mehr GAM-Seiten haben Sie, für das GAM erhalten Sie nach 63.904 Extents eine weitere GAM-Seite.

Seite 3 ist für die Shared Global Allocation Map (SGAM) und diese Seite wird verwendet, wenn SQL Speicherplatz einem gemischten Extent zuweisen muss. Diese SGAM-Seite verfolgt die gemischte Extent-Nutzung.

Eine gemischte Extent-Nutzung bedeutet, dass ein Extent von mehr als einem Objekt verwendet wird.

Wenn wir also ein Objekt mit weniger als 8 Seiten haben und wir keinen vollen Extent zuweisen möchten, verwenden wir einen gemischten Extent. Standardmäßig werden bei der Erstellung eines brandneuen Objekts die ersten acht Seiten gemischt zugewiesen.

Das SGAM ist eine Bitmap. Wenn das Bit also 1 ist, wird es als gemischter Extent verwendet und hat Platz zum Zuweisen. Wir würden anschließend nach der entsprechenden PFS-Seite suchen, um die leeren Seiten innerhalb dieses Extents zu finden und es daraufhin dieser Seite zuweisen. Der wichtige Punkt hier ist, dass SGAM in Verbindung mit der PFS-Seite verwendet wird, um Speicherplatz auf einem gemischten Extent zuzuweisen, und nach etwa 64.000 Extents erhalten Sie ein weiteres SGAM für dieselbe Datei.

Wenn Sie mehrere Dateien in tempdb haben, erhalten Sie einen weiteren unmittelbaren Header, PFS, GAM und SGAM, da alle Dateien dieselbe Struktur haben und wir bei mehreren Dateien versuchen, die Arbeitslast auf diese Dateien zu verteilen.

SQL Server verteilt Objektzuordnungen auf Dateien in derselben Dateigruppe basierend auf dem proportionalen Füllalgorithmus. Wir versuchen, den gleichen Prozentsatz an freiem Speicherplatz in jeder Datei innerhalb der Dateigruppe beizubehalten. Wenn also alle Dateien in der Dateigruppe mit derselben Größe beginnen und dieselbe Größe behalten und dieselbe Menge an freiem Speicherplatz haben, drehen wir das von einem proportionalen Füllalgorithmus in einen Round-Robin-Algorithmus, jede nachfolgende Zuweisung trifft auf die nächste Datei und so weiter. Aus diesem Grund empfiehlt Microsoft, mehrere Dateien mit derselben Größe zu haben. Die Verteilung von Objektzuweisungen auf alle Dateien ermöglicht es Ihnen, dieses Objekt bei einem Engpass der Zuordnung zu umgehen. Diese Empfehlung kam in SQL Server 2000 heraus und gilt immer noch in SQL Server 2019.

Mehrere Dateien gleicher Größe sind unsere bewährte Vorgehensweise. Dies bleibt so lange bestehen, bis Tests das Gegenteil beweisen.

Metadatenkonflikt

Die andere Hauptart von Konflikten wird als Metadatenkonflikt bezeichnet. Bei dieser Art von Konflikten geht es nicht um I/O. Er tritt im Arbeitsspeicher auf, wenn mehrere Threads gleichzeitig versuchen, dieselbe Seite im Arbeitsspeicher zu ändern.

Metadatenkonflikte wurden in SQL Server 2019 mit der speicheroptimierten tempdb-Metadatenverbesserung behoben.

Speicheroptimierte Metadatentabellen für tempdb sind im Grunde eine Kombination aus dem In-Memory-OLTP und den Metadatenfunktionen für temporäre Tabellen. Microsoft nahm die Systemtabellen und die tempdb-Systemtabellen und verschob diese in nicht dauerhafte speicheroptimierte Tabellen.

Tempdb ist temporär, es wird gelöscht und jedes Mal neu erstellt, wenn Sie SQL Server neu starten, sodass es keinen Grund dafür gab, dass die Metadaten dauerhaft sind. Microsoft konvertierte die 12 Systemtabellen, die an der Objektverfolgung und tempdb beteiligt sind, in speicheroptimierte, nicht dauerhafte Tabellen. Wir brauchen keine spezielle speicheroptimierte Dateigruppe für tempdb, da sie sowieso nicht dauerhaft ist. All dies befindet sich „im Arbeitsspeicher“, es wird keine Festplatte benötigt und bei speicheroptimierten Tabellen gibt es kein Latchen und kein Sperren. Wir können die Parallelität mit diesen Metadatentabellen massiv erhöhen, indem wir diese lock-freien, Latch-freien Datenstrukturen verwenden.

Das Aktivieren von speicheroptimierten Metadatentabellen erfordert einen Neustart, da wir die Hekaton-DLLs konfigurieren müssen. Dies war eine große Verbesserung in SQL Server 2019, die einen Großteil der Metadatenkonflikte beseitigen wird.

Konflikt zwischen temporärem Tabellencache

In früheren Versionen von SQL Server, beginnend mit SQL Server 2005, hat Microsoft das Zwischenspeichern von temporären Tabellen eingeführt, um einige der Konflikte beim Zwischenspeichern von Metadaten zu umgehen. Wenn Sie ein temporäres Tabellenobjekt zwischenspeichern haben und die Tabelle löschen, löscht SQL Server die Metadaten nicht komplett. Es wird ein Cache aller temporären Objekte aufbewahrt, die über eine gespeicherte Prozedur verwendet werden und verwenden dann die Metadaten für diese Objekte wieder wenn Sie dieselbe gespeicherte Prozedur mit derselben temporären Tabelle erneut aufrufen.

Infolgedessen hat das Zwischenspeichern temporärer Tabellen weniger Zugriffe auf die Metadaten und lindert einige dieser Metadatenkonflikte, jedoch nicht vollständig.

Das Zwischenspeichern temporärer Tabellen half dabei, Metadatenkonflikte zu lösen, indem es uns ermöglicht, Tabellen wiederzuverwenden, die sich zwischen den Ausführungen gespeicherter Prozeduren nicht geändert haben.

Solange die Tabelle nach ihrer Erstellung nicht geändert wurde, kann sie bei einer anderen Ausführung derselben gespeicherten Prozedur wiederverwendet werden. Wenn die Tabelle jedoch z. B. ein Index oder eine Spalte hinzugefügt wird, kann sie nicht wieder verwendbar und muss gelöscht werden, wenn die gespeicherte Prozedur abgeschlossen ist.

Es gibt mehrere verschiedene Tabellen, aus denen wir Metadaten löschen müssen, um die Tabelle vollständig zu löschen. Dies geschah alles synchron am Ende der Ausführung der gespeicherten Prozedur. Darüber hinaus erfordern alle diese neuen Funktionen jedes Mal die Nachverfolgung der neuen Metadaten, wenn dem SQL Server eine neue Funktion hinzugefügt wird (ColumnStore-Indizes, temporale Tabellen, In Memory OLTP usw.), sodass die Anzahl der Systemtabellen, die wir löschen müssen zunimmt, was den Prozess wirkungsvoller macht.

Cache-Konflikte bei temporären Tabellen können in größeren SQL Server-Umgebungen und mit einer größeren Anzahl von Kernen stärker ausgeprägt sein. Bei zunehmender Größe des Caches und der Anzahl gleichzeitiger Threads, die auf den Cache zugreifen, kann dies zu einem langsameren Cache-Zugriff, sowie zu Konflikten um das zugeordnete Speicherobjekt führen mit dem Cache.

Diese Bedingung kann sich auf zwei verschiedene Arten manifestieren: CMEMTHREAD und SOS_CACHESTORE Spinlock wartet. Um Konflikte zwischen dem temporären Tabellencache zu beheben, wird empfohlen, diese Wartebedingungen nachzuverfolgen und sicherzustellen, dass Sie die neuesten kumulativen Updates (CUs) für SQL Server installiert haben.

Verbesserungen von SQL Server 2022 tempdb

In SQL Server 2022 wurden die letzten gemeinsamen Konfliktbereiche angegangen, indem gleichzeitige GAM- und SGAM-Updates eingeführt wurden, die den gleichzeitigen PFS-Updates ähneln.

Wir verwenden die Seiten Global Allocation Map (GAM), wenn wir nach einheitlichen Extents suchen, und die Seiten Shared Global Allocation Map (SGAM), bei der Suche nach gemischten Extents in tempdb.

Auf SQL Server 2019 gibt es eine GAM-Konfliktwand, die über 123.000 Konflikte verursacht, wobei die längste Wartezeit 949 Millisekunden dauert. Der Grund dafür ist, dass mit dem Update-Latch nur jeweils ein Thread die GAM-Seite ändern kann. Dies ist der Hauptgrund, warum wir immer noch mehrere Datendateien benötigen. Aufgrund dieses Konflikts wird der SQL Server-Durchsatz verringert. Auch Workloads, die viele Aktualisierungen der GAM-Seite erfordern, werden länger dauern bis sie abgeschlossen sind, wobei die CPU des Computers nicht ausgelastet ist. Dieser Konflikt ist auf das Arbeitslastvolumen und insbesondere auf die Verwendung sich wiederholender Create-and-Drop-Vorgänge zurückzuführen.

Beginnend mit SQL Server 2016 hat Microsoft das Standardverhalten geändert, um beim Erstellen neuer Objekte in tempdb immer einheitliche Extents zuzuweisen. Dies hat dazu beigetragen, die meisten SGAM-Konflikte zu vermeiden, aber dennoch gemischte Extents für die Seitenzuweisungen der Index Allocation Map (IAM) zu verwenden. IAM-Seiten werden verwendet, um alle Seiten zu verfolgen, die zu einem Objekt gehören, sodass jedes erstellte Objekt mindestens eine IAM-Seite hat. Bei den meisten Workloads verursachen diese IAM-Seitenzuweisungen keine Probleme, aber bei extrem ausgelasteten tempdb-Workloads mit vielen Threads gleichzeitiger Zuweisungen können diese IAM-Seitenzuweisungen immer noch SGAM-Konflikte verursachen.

SQL Server 2022 adressiert GAM- und SGAM-Konflikte

SQL Server-Tempdb-Konflikte werden in SQL Server 2022 nahezu vollständig behandelt und diese Vorteile sind standardmäßig aktiviert. Mit diesen Verbesserungen in SQL Server 2022 ermöglicht Microsoft gleichzeitige Updates für GAM und SGAM unter einem gemeinsamen Latch, anstatt den Update-Latch zu verwenden. Es löst fast alle tempdb-Konflikte, sodass parallele Threads die GAM- und SGAM-Seiten ändern können.

Es gibt immer noch mögliche Metadaten-Konfliktpunkte, aber mit SQL Server 2022 werden sie selten sein und sollten nicht zu erheblichen Leistungsproblemen führen.

Wenn gleichzeitige GAM- und gleichzeitige SGAM-Updates einige der letzten Streitpunkte sind, brauchen wir dann immer noch die Best Practices, um mehrere Datendateien für tempdb zu verwalten?

zu Beginn werden wir weiterhin dieselben Best Practices empfehlen, aber wir können uns anpassen, wenn wir aufgrund von Kundenfeedback feststellen, dass dies nicht mehr erforderlich ist.

Fazit

In SQL Server 2022 hat Microsoft die Leistung von tempdb auf einen Faktor verbessert, der möglicherweise die bewährten Methoden für tempdb überarbeiten muss, die sich seit fast einem Vierteljahrhundert bewährt haben.

Die Leistung von tempdb wurde stark verbessert. Viel von dem, was auf SQL Server ausgeführt wird, basiert auf tempdb. Diese Verbesserungen werden wahrscheinlich mehr als genug sein, um SQL Server 2022 in den meisten Organisationen zu einem obligatorischen Upgrade zu machen.

Der entscheidende Punkt ist, dass es für DBAs wichtig ist, die Leistung von tempdb zu optimieren, aber auch tempdb-Engpässe zu verfolgen und zu beheben. SQL Server hat tempdb in jeder einzelnen Version verbessert, SQL Server 2022 ist keine Ausnahme.

Wenn Sie Fragen zum Thema haben oder Unterstützung brauchen: Kontaktieren Sie uns gerne unverbindlich über das Kontaktformular.

Interesse geweckt?

Unsere Expert:innen stehen Ihnen bei allen Fragen rund um Ihre IT Infrastruktur zur Seite.

Kontaktieren Sie uns gerne über das Kontaktformular und vereinbaren ein unverbindliches Beratungsgespräch mit unseren Berater:innen zur Bedarfsevaluierung. Gemeinsam optimieren wir Ihre Umgebung und steigern Ihre Performance!
Wir freuen uns auf Ihre Kontaktaufnahme!

Taunusstraße 72
55118 Mainz
info@madafa.de
+49 6131 3331612
Bürozeiten
Montag bis Donnerstag:
9:00 - 17:00 Uhr MEZ

Freitags:
9:30 - 14:00 Uhr MEZ