• Articles
• admin

Am 9. Juli 2019 endet die Unterstützung für SQL Server 2008 und 2008 R2. Das bedeutet das Ende der regelmäßigen Sicherheitsupdates. Wenn Sie diese SQL Server-Instanzen jedoch nach Azure oder Azure Stack verschieben (ich werde beide für den Rest des Handbuchs einfach als Azure bezeichnen), erhalten Sie von Microsoft drei Jahre erweiterte Sicherheitsupdates ohne zusätzliche Kosten. Wenn Sie derzeit SQL Server 2008/2008 R2 ausführen und nicht vor Ablauf der Frist vom 9. Juli auf eine neuere Version von SQL Server aktualisieren können, sollten Sie dieses Angebot nutzen, anstatt das Risiko einer zukünftigen Sicherheitslücke einzugehen. Eine ungepatchte Instanz von SQL Server kann zu Datenverlust, Ausfallzeiten oder einem verheerenden Datenverstoß führen.

Eine der Herausforderungen bei der Ausführung von SQL Server 2008/2008 R2 in Azure besteht darin, eine hohe Verfügbarkeit sicherzustellen. Vor Ort führen Sie möglicherweise eine SQL Server-Failoverclusterinstanz (FCI) für hohe Verfügbarkeit aus, oder Sie führen SQL Server möglicherweise in einer virtuellen Maschine aus und verlassen sich für die Verfügbarkeit auf VMware HA oder einen Hyper-V-Cluster. Beim Wechsel zu Azure ist keine dieser Optionen verfügbar. Ausfallzeiten in Azure sind eine sehr reale Möglichkeit, die Sie minimieren müssen.

, um die Möglichkeit von Ausfallzeiten zu verringern und sich für Azure 99.95% oder 99 zu qualifizieren.99% SLA, müssen Sie SIOS DataKeeper nutzen. DataKeeper überwindet den Mangel an gemeinsam genutztem Speicher in Azure und ermöglicht es Ihnen, eine SQL Server-FCI in Azure zu erstellen, die den lokal angeschlossenen Speicher auf jeder Instanz nutzt. SIOS DataKeeper unterstützt nicht nur SQL Server 2008 R2 und Windows Server 2008 R2, wie in diesem Handbuch dokumentiert, sondern auch jede Version von Windows Server von 2008 R2 bis Windows Server 2019 und jede Version von SQL Server von SQL Server 2008 bis SQL Server 2019.

In diesem Handbuch wird der Prozess zum Erstellen einer SQL Server 2008 R2-Failoverclusterinstanz (FCI) mit zwei Knoten in Azure beschrieben, die unter Windows Server 2008 R2 ausgeführt wird. Obwohl SIOS DataKeeper auch Cluster unterstützt, die sich über Availability Zones oder Regionen erstrecken, wird in diesem Handbuch davon ausgegangen, dass sich jeder Knoten in derselben Azure-Region, jedoch in unterschiedlichen Azure-Domänen befindet. SIOS DataKeeper wird anstelle des gemeinsam genutzten Speichers verwendet, der normalerweise zum Erstellen einer SQL Server 2008 R2-FCI erforderlich ist.

Voraussetzungen

Active Directory
In diesem Handbuch wird davon ausgegangen, dass Sie über eine vorhandene Active Directory-Domäne verfügen. Sie können Ihre eigenen Domänencontroller verwalten oder Azure Active Directory-Domänendienste verwenden. Für dieses Tutorial stellen wir eine Verbindung zu einer Domain namens contoso her.lokal. Natürlich werden Sie eine Verbindung zu Ihrer eigenen Domain herstellen, wenn Sie diesem Tutorial folgen.

Offene Firewall-Ports
– SQL Server: 1433 für Standardinstanz
– Load Balancer Health Probe: 59999
– DataKeeper: Diese Firewallregeln werden der Windows-Host-basierten Firewall während der Installation automatisch hinzugefügt. Einzelheiten dazu, welche Ports geöffnet sind, finden Sie in der SIOS-Dokumentation.
– Beachten Sie, dass Sie diese Ports auch dort berücksichtigen müssen, wenn Sie über eine netzwerkbasierte Sicherheit verfügen, die Ports zwischen den Clusterknoten blockiert.

DataKeeper-Dienstkonto
Erstellen Sie ein Domänenkonto. Wir werden dieses Konto angeben, wenn wir DataKeeper installieren. Dieses Konto muss der lokalen Administratorengruppe auf jedem Knoten des Clusters hinzugefügt werden.

Erstellen der ersten SQL Server-Instanz in Azure

In diesem Handbuch wird das SQL Server 2008R2SP3-Image unter Windows Server 2008R2 verwendet, das im Azure Marketplace veröffentlicht wird.

Wenn Sie die erste Instanz bereitstellen, müssen Sie einen neuen Verfügbarkeitssatz erstellen. Erhöhen Sie während dieses Vorgangs unbedingt die Anzahl der Fehlerdomänen auf 3. Dadurch können sich die beiden Clusterknoten und der Dateifreigabezeuge jeweils in ihrer eigenen Fehlerdomäne befinden.

Wenn Sie noch kein virtuelles Netzwerk konfiguriert haben, erlauben Sie dem Erstellungsassistenten, ein neues für Sie zu erstellen.

Sobald die Instanz erstellt wurde, gehen Sie zu den IP-Konfigurationen und machen Sie die private IP-Adresse statisch. Dies ist für SIOS DataKeeper erforderlich und wird für Clusterinstanzen empfohlen.

Stellen Sie sicher, dass Ihr virtuelles Netzwerk so konfiguriert ist, dass der DNS-Server ein lokaler Windows AD Controller ist, um sicherzustellen, dass Sie der Domäne in einem späteren Schritt beitreten können.

Fügen Sie nach der Bereitstellung der virtuellen Maschinen jeder Instanz mindestens zwei zusätzliche Festplatten hinzu. Premium oder Ultra SSD werden empfohlen. Deaktivieren Sie das Caching auf den Datenträgern, die für die SQL-Protokolldateien verwendet werden. Aktivieren Sie das schreibgeschützte Caching auf der Festplatte, die für die SQL-Datendateien verwendet wird. Weitere Informationen zu bewährten Speichermethoden finden Sie unter Leistungsrichtlinien für SQL Server in virtuellen Azure-Maschinen.

Erstellen der 2. SQL Server-Instanz in Azure

Führen Sie die gleichen Schritte wie oben aus, stellen Sie jedoch sicher, dass diese Instanz in demselben virtuellen Netzwerk und Verfügbarkeitssatz platziert wird, den Sie mit der 1. Instanz erstellt haben.

Erstellen einer FSW-Instanz (File Share Witness)

Damit der Windows Server-Failovercluster (WSFC) optimal funktioniert, müssen Sie eine weitere Windows Server-Instanz erstellen und sie im selben Verfügbarkeitssatz wie die SQL Server-Instanzen platzieren. Indem Sie es in demselben Verfügbarkeitssatz platzieren, stellen Sie sicher, dass sich jeder Clusterknoten und die FSW in verschiedenen Fehlerdomänen befinden. Diese Instanz benötigt keinen SQL Server, es kann ein einfacher Windows-Server sein, da er nur eine einfache Dateifreigabe hosten muss.

Diese Instanz hostet den von WSFC geforderten File Share Witness. Diese Instanz muss nicht die gleiche Größe haben, und es müssen keine zusätzlichen Festplatten angeschlossen werden. Es dient nur dazu, eine einfache Dateifreigabe zu hosten. Es kann tatsächlich für andere Zwecke verwendet werden. In meiner Laborumgebung ist mein FSW auch mein Domänencontroller.

Deinstallieren von SQL Server 2008 R2

Auf jeder der beiden bereitgestellten SQL Server-Instanzen ist bereits SQL Server 2008 R2 installiert. Sie werden jedoch als eigenständige SQL Server-Instanzen und nicht als Clusterinstanzen installiert. SQL Server muss von jeder dieser Instanzen deinstalliert werden, bevor wir die Clusterinstanz installieren können. Der einfachste Weg, dies zu tun, besteht darin, das SQL-Setup wie unten gezeigt auszuführen.

Wenn Sie Setup ausführen.exe / Action-RunDiscovery Sie sehen alles, was vorinstalliert ist

setup.exe /Action=RunDiscovery

Setup ausführen.exe / Action=Uninstall /FEATURES=SQL,AS,RS,IS,Tools /INSTANCENAME=MSSQLSERVER startet den Deinstallationsprozess

setup.exe /Action=Uninstall /FEATURES=SQL,AS,RS,IS,Tools /INSTANCENAME=MSSQLSERVER

Setup ausführen.exe / Action-Rundscovery bestätigt die Deinstallation abgeschlossen

setup.exe /Action-RunDiscovery

Führen Sie diesen Deinstallationsvorgang auf der 2. Instanz erneut aus.

Instanzen zur Domäne hinzufügen

Alle drei Instanzen müssen einer Windows-Domäne hinzugefügt werden. Wie im Abschnitt Voraussetzungen erwähnt, müssen Sie Zugriff haben, um einem vorhandenen Windows Active Directory beizutreten. In unserem Fall treten wir einer Domain namens contoso bei.lokal.

Windows-Failoverclusterfunktion hinzufügen

Die Failoverclusterfunktion muss den beiden SQL Server-Instanzen hinzugefügt werden

Add-WindowsFeature Failover-Clustering

Installieren Sie das Rollup-Update für Windows Server 2008 R2 SP1

Es ist ein wichtiges Update (kb2854082) erforderlich, um eine Windows Server 2008 R2-Instanz in Azure zu konfigurieren. Dieses Update und viele weitere sind im Convenience Rollup Update für Windows Server 2008 R2 SP1 enthalten. Installieren Sie dieses Update auf jeder der beiden SQL Server-Instanzen.

Formatieren des Speichers

Die zusätzlichen Datenträger, die bei der Bereitstellung der beiden SQL Server-Instanzen angehängt wurden, müssen formatiert werden. Führen Sie die folgenden Schritte für jedes Volume in jeder Instanz aus.

Microsoft Best Practices sagt Folgendes …

„Größe der NTFS-Zuordnungseinheit: Beim Formatieren der Datenfestplatte wird empfohlen, eine Zuordnungseinheitsgröße von 64 KB für Daten- und Protokolldateien sowie TempDB zu verwenden.“

Führen Sie die Clustervalidierung aus

Führen Sie die Clustervalidierung aus, um sicherzustellen, dass alles für die Clusterbildung bereit ist.

Import-Module FailoverClustersTest-Cluster -Node "SQL1", "SQL2"

Ihr Bericht enthält WARNUNGEN zu Speicher und Netzwerk. Sie können diese Warnungen ignorieren, da wir wissen, dass es keine freigegebenen Festplatten gibt und nur eine einzige Netzwerkverbindung zwischen den Servern besteht. Möglicherweise erhalten Sie auch eine Warnung vor einer verbindlichen Bestellung, die ebenfalls ignoriert werden kann. Wenn Sie auf FEHLER stoßen, müssen Sie diese beheben, bevor Sie fortfahren.

Fehler beim Ausführen der Clustervalidierung?

Ich bin bei einigen Gelegenheiten auf diesen Fehler gestoßen und versuche immer noch herauszufinden, unter welchen Bedingungen dies auftritt. Gelegentlich werden Sie feststellen, dass test-cluster nicht wie im Forenbeitrag beschrieben ausgeführt werden kann.

Test-ClusterUnable to Validate a Cluster Configuration. The operation has failed. The action validate a configuration did not completeThere is an error in XML document (5, 73). Attempt by methodMicrosoft.Xml.Serialzation.GeneratedAssembly.XmlSerialzationReaderClusterPrep.Config.Read4_As...Bolean) to access methodMS.Internal.ServerClusters.Validation.TestAssemblyCollection.Add(MS.Internal.ServerClusters.V....Failed

Wenn Ihnen dies passiert, habe ich festgestellt, dass der folgende im Forumsbeitrag empfohlene Fix für mich funktioniert.

Inside C:\Windows\System32\WindowsPowerShell\v1.0 make a copy of powershell_ise.exe.config file (make a copy inside C:\Windows\System32\WindowsPowerShell\v1.0)- rename it to powershell.exe.configOpen it with notepad- delete current config line and paste:<?xml version="1.0" encoding="utf-8" ?><configuration> <system.xml.serialization> <xmlSerializer useLegacySerializerGeneration="true"/> </system.xml.serialization></configuration>- save and run test-cluster

Mit diesem Fix können Sie test-cluster zwar über Powershell ausführen, aber ich habe festgestellt, dass das Ausführen von Validate über die GUI auch mit diesem Fix immer noch einen Fehler auslöst. Ich habe eine Abfrage bei Microsoft, um festzustellen, ob sie eine Lösung haben, aber wenn Sie die Clustervalidierung ausführen müssen, müssen Sie möglicherweise Test-Cluster in Powershell verwenden.

Erstellen des Clusters

Best Practices zum Erstellen eines Clusters in Azure sind die Verwendung von Powershell zum Erstellen eines Clusters unter Angabe einer statischen IP-Adresse. Mit Powershell können wir eine statische IP-Adresse angeben, während die GUI-Methode dies nicht tut. Wenn Sie also die GUI-Methode verwenden, wird eine doppelte IP-Adresse als Cluster-IP-Adresse angezeigt, die behoben werden muss, bevor der Cluster verwendet werden kann.

Ich habe jedoch festgestellt, dass der typische Powershell-Befehl New-Cluster mit dem Befehl -StaticAddress nicht funktioniert. Um das Problem der doppelten IP-Adresse zu vermeiden, müssen wir auf den Cluster zurückgreifen.exe-Dienstprogramm und führen Sie den folgenden Befehl aus.

cluster /cluster:cluster1 /create /nodes:"sql1 sql2" /ipaddress:10.0.0.100/255.255.255.0

Fügen Sie den File Share Witness hinzu

Als nächstes müssen wir den File Share Witness hinzufügen. Erstellen Sie auf dem 3. Server, den wir als FSW bereitgestellt haben, einen Ordner und geben Sie ihn wie unten gezeigt frei. Sie müssen dem Cluster Name Object (CNO) Lese- / Schreibberechtigungen sowohl auf der Freigabe- als auch auf der Sicherheitsebene erteilen, wie unten gezeigt.

Führen Sie nach dem Erstellen der Freigabe den Assistenten zum Konfigurieren des Clusterquorums auf einem der Clusterknoten aus, und führen Sie die unten dargestellten Schritte aus.

Installieren Sie DataKeeper

Installieren Sie DataKeeper auf jedem der beiden SQL Server-Clusterknoten wie unten gezeigt.

Hier geben wir das Domänenkonto an, das wir jeder Gruppe lokaler Domänenadministratoren hinzugefügt haben.

Konfigurieren von DataKeeper

Sobald DataKeeper auf jedem der beiden Clusterknoten installiert ist, können Sie DataKeeper konfigurieren.

HINWEIS – Der häufigste Fehler, der in den folgenden Schritten auftritt, ist sicherheitsbezogen, am häufigsten durch bereits vorhandene Azure-Sicherheitsgruppen, die erforderliche Ports blockieren. Bitte beachten Sie die SIOS-Dokumentation, um sicherzustellen, dass die Server über die erforderlichen Ports kommunizieren können.

Zuerst müssen Sie eine Verbindung zu jedem der beiden Knoten herstellen.

Wenn alles richtig konfiguriert ist, sollten Sie Folgendes im Serverübersichtsbericht sehen.

Erstellen Sie als Nächstes einen neuen Job und führen Sie die unten dargestellten Schritte aus

Wählen Sie hier Ja, um die DataKeeper Volume-Ressource im verfügbaren Speicher zu registrieren

Führen Sie die obigen Schritte für jedes der Volumes aus. Sobald Sie fertig sind, sollten Sie Folgendes in der WSFC-Benutzeroberfläche sehen.

Sie können nun SQL Server im Cluster installieren.

HINWEIS: Zu diesem Zeitpunkt ist das replizierte Volume nur auf dem Knoten verfügbar, auf dem derzeit verfügbarer Speicher gehostet wird. Das wird erwartet, also keine Sorge!

Installieren Sie SQL Server auf dem ersten Knoten

Wenn Sie die Installation skripten möchten, habe ich das folgende Beispiel einer Skriptclusterinstallation von SQL Server 2008 R2 in den ersten Knoten des Clusters aufgenommen. Das Skript zum Hinzufügen eines Knotens zu einem vorhandenen Cluster finden Sie weiter unten im Handbuch.

Natürlich für Ihre Umgebung anpassen.

c:\SQLServerFull\setup.exe /q /ACTION=InstallFailoverCluster /FEATURES=SQL /INSTANCENAME="MSSQLSERVER" /INSTANCEDIR="C:\Program Files\Microsoft SQL Server" /INSTALLSHAREDDIR="C:\Program Files\Microsoft SQL Server" /SQLSVCACCOUNT="contoso\admin" /SQLSVCPASSWORD="xxxxxxxxx" /AGTSVCACCOUNT="contoso\admin" /AGTSVCPASSWORD="xxxxxxxxx" /SQLDOMAINGROUP="contoso\SQLAdmins" /AGTDOMAINGROUP="contoso\SQLAdmins" /SQLCOLLATION="SQL_Latin1_General_CP1_CI_AS" /FAILOVERCLUSTERGROUP="SQL Server 2008 R2 Group" /FAILOVERCLUSTERDISKS="DataKeeper Volume E" "DataKeeper Volume F" /FAILOVERCLUSTERIPADDRESSES="IPv4;10.0.0.101;Cluster Network 1;255.255.255.0" /FAILOVERCLUSTERNETWORKNAME="SQL2008Cluster" /SQLSYSADMINACCOUNTS="contoso\admin" /SQLUSERDBLOGDIR="E:\MSSQL10.MSSQLSERVER\MSSQL\Log" /SQLTEMPDBLOGDIR="F:\MSSQL10.MSSQLSERVER\MSSQL\Log" /INSTALLSQLDATADIR="F:\MSSQL10.MSSQLSERVER\MSSQLSERVER" /IAcceptSQLServerLicenseTerms

Wenn Sie die GUI verwenden möchten, folgen Sie einfach den Screenshots unten.

Führen Sie auf dem ersten Knoten das SQL Server-Setup aus.

Wählen Sie Neue SQL Server-Failoverclusterinstallation aus, und führen Sie die Schritte wie dargestellt aus.

Wählen Sie nur die Optionen, die Sie benötigen.

Bitte beachten Sie, dass in diesem Dokument davon ausgegangen wird, dass Sie die Standardinstanz von SQL Server verwenden. Wenn Sie eine benannte Instanz verwenden, müssen Sie sicherstellen, dass Sie den Port sperren, den sie überwacht, und diesen Port später verwenden, wenn Sie den Load Balancer konfigurieren. Außerdem müssen Sie eine Load Balancer-Regel für den SQL Server-Browserdienst (UDP 1434) erstellen, um eine Verbindung zu einer benannten Instanz herzustellen. Keine dieser beiden Anforderungen wird in diesem Handbuch behandelt, aber wenn Sie eine benannte Instanz benötigen, funktioniert dies, wenn Sie diese beiden zusätzlichen Schritte ausführen.

Hier müssen Sie eine nicht verwendete IP-Adresse angeben

Wechseln Sie zur Registerkarte Datenverzeichnisse und verschieben Sie Daten und Protokolldateien. Am Ende dieses Handbuchs sprechen wir über das Verschieben von tempdb auf ein nicht gespiegeltes DataKeeper-Volume, um eine optimale Leistung zu erzielen. Behalten Sie es vorerst auf einer der gruppierten Festplatten.

Installieren Sie SQL Server auf dem zweiten Knoten

Nachfolgend finden Sie ein Beispiel für den Befehl, den Sie ausführen können, um einem vorhandenen Cluster einen zusätzlichen SQL Server 2008 R2-Knoten hinzuzufügen.

c:\SQLServerFull\setup.exe /q /ACTION=AddNode /INSTANCENAME="MSSQLSERVER" /SQLSVCACCOUNT="contoso\admin" /SQLSVCPASSWORD="xxxxxxxxx" /AGTSVCACCOUNT="contoso\admin" /AGTSVCPASSWORD="xxxxxxxx" /IAcceptSQLServerLicenseTerms

Wenn Sie die GUI bevorzugen, folgen Sie den folgenden Screenshots.

Führen Sie das SQL Server-Setup erneut auf dem zweiten Knoten aus, und wählen Sie Knoten zu einem SQL Server-Failovercluster hinzufügen aus.

Congratulations , du bist fast fertig! Aufgrund der fehlenden Unterstützung von unentgeltlichem ARP durch Azure müssen wir jedoch einen internen Load Balancer (ILB) konfigurieren, um die Clientumleitung zu unterstützen, wie in den folgenden Schritten gezeigt.

Aktualisieren der SQL-Cluster-IP-Adresse

Damit die ILB ordnungsgemäß funktioniert, müssen Sie den folgenden Befehl von einem der Clusterknoten aus ausführen. It SQL Cluster IP ermöglicht es der SQL Cluster-IP-Adresse, auf die ILB-Integritätssonde zu antworten und gleichzeitig die Subnetzmaske auf 255.255.255.255 festzulegen, um IP-Adressenkonflikte mit der Integritätssonde zu vermeiden.

cluster res <IPResourceName> /priv enabledhcp=0 address=<ILBIP> probeport=59999 subnetmask=255.255.255.255

HINWEIS – Ich weiß nicht, ob es sich um einen Zufall handelt, aber gelegentlich habe ich diesen Befehl ausgeführt und es sieht so aus, als würde er ausgeführt, aber er schließt den Job nicht ab und ich muss ihn erneut ausführen. Die Art und Weise, wie ich feststellen kann, ob es funktioniert hat, ist, indem ich mir die Subnetzmaske der SQL Server-IP-Ressource ansehe, wenn es nicht 255.255.255.255 ist, dann wissen Sie, dass es nicht erfolgreich ausgeführt wurde. Sie können daher auch versuchen, die Cluster-GUI neu zu starten, um zu überprüfen, ob die Subnetzmaske aktualisiert wurde.

Schalten Sie die Ressource nach erfolgreicher Ausführung offline und wieder online, damit die Änderungen wirksam werden.

Erstellen Sie den Load Balancer

Der letzte Schritt besteht darin, den Load Balancer zu erstellen. In diesem Fall gehen wir davon aus, dass Sie die Standardinstanz von SQL Server ausführen und Port 1433 abhören.

Die private IP-Adresse, die Sie beim Erstellen des Load Balancers definieren, ist genau dieselbe Adresse, die Ihre SQL Server FCI verwendet.

Fügen Sie dem Backend-Pool nur die beiden SQL Server-Instanzen hinzu. Fügen Sie die FSW NICHT zum Backend-Pool hinzu.

In dieser Lastausgleichsregel müssen Sie Floating IP aktivieren

Validieren Sie den Cluster

Bevor Sie fortfahren, führen Sie die Clustervalidierung noch einmal aus. Der Clustervalidierungsbericht sollte genau die gleichen Netzwerk- und Speicherwarnungen zurückgeben wie bei der ersten Ausführung. Angenommen, es liegen keine neuen Fehler oder Warnungen vor, ist Ihr Cluster korrekt konfiguriert.

Bearbeiten Sie sqlserv.exe-Konfigurationsdatei

Im Verzeichnis C:\Program Dateien (x86) \ Microsoft SQL Server\100 \Tools\Binn wir haben eine sqlps.exe.config-Datei und sqlservr.exe.config mit den folgenden Zeilen in der Konfigurationsdatei:

<configuration> <startup> <supportedRuntime version="v2.0.50727"/> </startup></configuration>

Diese Dateien sind standardmäßig nicht vorhanden und können erstellt werden. Wenn diese Datei(en) bereits für Ihre Installation vorhanden sind, muss die Zeile <supportedRuntime version=“v2.0.50727″/> einfach im Unterabschnitt <startup>…</startup> des Abschnitts <configuration>…</configuration> platziert werden. Dies sollte auf beiden Servern erfolgen.

Testen des Clusters

Der einfachste Test besteht darin, SQL Server Management Studio auf dem passiven Knoten zu öffnen und eine Verbindung zum Cluster herzustellen. Wenn Sie eine Verbindung herstellen können, herzlichen Glückwunsch, Sie haben alles richtig gemacht! Wenn Sie keine Verbindung herstellen können, haben Sie keine Angst, Sie wären nicht die erste Person, die einen Fehler macht. Ich habe einen Blog-Artikel geschrieben, um das Problem zu beheben. Die Verwaltung des Clusters entspricht genau der Verwaltung eines herkömmlichen gemeinsam genutzten Speicherclusters. Alles wird über den Failovercluster-Manager gesteuert.

Optional – Tempdb verschieben

Für eine optimale Leistung ist es ratsam, tempdb auf die lokale, nicht replizierte SSD zu verschieben. Für SQL Server 2008 R2 muss sich tempdb jedoch auf einem Clusterdatenträger befinden. SIOS verfügt über eine Lösung namens Nicht gespiegelte Volume-Ressource, die dieses Problem behebt. Es ist ratsam, eine nicht gespiegelte Volume-Ressource des lokalen SSD-Laufwerks zu erstellen und tempdb dorthin zu verschieben. Daher müssen Sie sicherstellen, dass der Ordner mit tempdb und die Berechtigungen für diesen Ordner bei jedem Neustart des Servers neu erstellt werden.