Häufig gestellte Fragen (FAQ) zu Azure SQL Managed Instance

Eine Liste der in SQL Managed Instance unterstützten Funktionen finden Sie unter Azure SQL Managed Instance: Features.

Informationen zu den Unterschieden in Syntax und Verhalten zwischen Azure SQL Managed Instance und SQL Server finden Sie unter T-SQL-Unterschiede zu SQL Server.

Informationen zu den verfügbaren Hardwaremerkmalen finden Sie unter Technische Unterschiede in Hardwarekonfigurationen. Informationen zu den verfügbaren Dienstebenen und ihren Merkmalen finden Sie unter Technische Unterschiede zwischen Dienstebenen.

Jeder Kunde ist für alle Dienstebenen qualifiziert. Sowohl Standard- als auch Enterprise-Editionenlizenzen, die mit Software Assurance abgedeckt sind, können dem SQL Server-Datenbankmodul zugewiesen werden, indem sie den Azure-Hybridvorteil (AHB) für die Dienstebene "General Purpose" (die das Upgrade der Dienstebene 'Next-gen General Purpose' umfasst) oder für die Dienstebene "Business Critical" nutzen. Der Azure-Hybridvorteil verwendet die folgenden Wechselverhältnisse: 1 Standard Edition = 1 General Purpose, 1 Enterprise Edition = 1 Business Critical, 1 Enterprise Edition = 4 General Purpose und 4 General Purpose = 1 Enterprise Edition. Weitere Informationen finden Sie unter Spezifische Rechte des Azure-Hybridvorteils.

Eine Liste mit den unterstützten Abonnementtypen finden Sie unter Unterstützte Abonnementtypen.

Verwaltete Instanzen können in den meisten Azure-Regionen erstellt werden. Weitere Informationen finden Sie auf der Seite mit den unterstützten Regionen für SQL Managed Instance. Wenn Sie sql managed instance in einer Region benötigen, die derzeit nicht unterstützt wird, senden Sie eine Supportanfrage über das Azure-Portal.

Sql Managed Instance hat zwei Standardgrenzwerte: ein Grenzwert für die Anzahl der Subnetze, die Sie verwenden können, und einen Grenzwert für die Anzahl der vCores, die Sie bereitstellen können. Die Einschränkungen variieren je nach Abonnementtyp und Region. Eine Liste der regionalen Ressourceneinschränkungen nach Abonnementtyp finden Sie in der Tabelle aus der Einschränkung regionaler Ressourcen. Diese weichen Grenzen können bei Bedarf erhöht werden. Senden Sie eine Supportanfrage zum Erhöhen des Kontingents über das Azure-Portal, wenn Sie mehr verwaltete Instanzen in Ihren aktuellen Regionen bereitstellen müssen. Weitere Informationen finden Sie unter Anfordern von Kontingenterhöhungen für Azure SQL-Datenbank.

Der Grenzwert von 100 Datenbanken pro Instanz von SQL Managed Instance ist ein harter Grenzwert, der in den Dienstebenen Universell und Unternehmenskritisch nicht geändert werden kann. In der Dienstebene Universell der nächsten Generation können Sie bis zu 500 Datenbanken haben.

Sie können eine Migration zu anderen Azure-Varianten erwägen, die zu Ihrer Workload passen: Hyperscale in Azure SQL-Datenbank oder SQL Server auf virtuellen Azure-Computern.

Sie können erwägen, eine Migration zu SQL Server auf virtuellen Azure-Computern oder zu Azure SQL-Datenbank mit Arbeitsspeicher- bzw. CPU-Optimierung durchzuführen.

Informationen zu Produktfehlern und bekannten Problemen finden Sie unter Bekannte Probleme.

Neue und Vorschaufunktionen finden Sie unter Was ist neu.

Sie können eine von SQL verwaltete Instanz über das Azure-Portal, PowerShell, Azure CLI und ARM-Vorlagen bereitstellen.

Ja, Sie können eine SQL-verwaltete Instanz in einem vorhandenen Abonnement bereitstellen, wenn dieses Abonnement zu den unterstützten Abonnementtypen gehört.

Das Starten eines Subnetznamens mit einer Ziffer ist eine aktuelle Einschränkung einer zugrunde liegenden Komponente, die den Subnetznamen anhand des regex überprüft:

^[a-zA-Z_][^\\\/\:\*\?\"\<\>\|\`\'\^]*(?<![\.\s])$

Alle Namen, die den Regex bestehen und gültige Subnetznamen sind, werden aktuell unterstützt.

Sie können Ihre von SQL verwaltete Instanz über das Azure-Portal, PowerShell, Azure CLI oder ARM-Vorlagen skalieren.

Ja, das ist möglich. Eine Anleitung finden Sie unter Verschieben von Ressourcen in eine neue Region.

Sie können SQL-verwaltete Instanzen über azure-Portal, PowerShell, Azure CLI oder Resource Manager-REST-APIs löschen.

Die erwartete Zeit zum Erstellen einer neuen verwalteten SQL-Instanz oder zum Ändern von Dienstebenen (vCores, Speicher) hängt von mehreren Faktoren ab. Weitere Informationen finden Sie unter Verwaltungsvorgänge.

Die Wiederherstellung jeder Datenbank wird während des gesamten definierten Aufbewahrungszeitraums garantiert – sogar Datenbanken, die erstellt und dann nach nur wenigen Sekunden gelöscht wurden. Wenn eine Datenbank erstellt, gelöscht oder wiederhergestellt wird, werden in unterschiedlichen Intervallen Sicherungen erstellt, um die Daten beizubehalten, sodass eine Wiederherstellung während des angegebenen Aufbewahrungszeitraums möglich ist. Wenn eine Datenbank gelöscht wird, bevor ein Sicherungsvorgang abgeschlossen ist, wird der Löschvorgang möglicherweise mit dem folgenden Fehler blockiert:

Message database 'backup_restore_db_lkg_native_restore' already exists. Choose a different database name.

Um diesen Fehler zu vermeiden, überprüfen Sie den Zustand des Löschvorgangs, bevor Sie eine Datenbank mit demselben Namen neu erstellen. Weitere Informationen finden Sie unter sys.dm_operation_status. Sobald der Vorgangszustand als Abgeschlossen angezeigt wird, ist es möglich, eine Datenbank mit demselben Namen WIEDERHERZUSTELLEN oder ZU ERSTELLEN.

In den folgenden gängigen Anwendungsfällen tritt dieser Fehler wahrscheinlich auf:

• Mehrere Datenbanken werden gelöscht und kurz darauf mit demselben Namen erneut erstellt. Wenn eine Datenbank gelöscht wird, wird das verbleibende Fragment des Transaktionsprotokolls synchron gesichert, bevor der Löschvorgang abgeschlossen ist, wie in der Abbildung gezeigt:

  

  Es ist nicht möglich, eine Datenbank mit dem gleichen Namen zu erstellen, bevor das Protokollfragment gesichert und der Löschvorgang abgeschlossen ist. Aufgrund der sequenziellen Natur von Löschvorgängen werden Datenbanken, die kurz nach der Erstellung gelöscht werden, in eine Warteschlange eingereiht. Dies kann den Prozess des Löschens der Datenbanken verlängern und die Möglichkeit der Erstellung neuer Datenbanken mit demselben Namen verzögern.

• Falls eine Datenbank wiederhergestellt und gelöscht wird, bevor eine vollständige Sicherung erstellt wurde. Wenn eine Datenbank wiederhergestellt wird, besteht der erste Schritt des Wiederherstellungsprozesses im Erstellen einer neuen vollständigen Sicherung der Datenbank. Wenn Sie versuchen, eine Datenbank wiederherzustellen, und diese dann sofort löschen, bevor die vollständige Sicherung abgeschlossen ist, können Sie die Datenbank erst dann löschen und eine weitere Datenbank mit demselben Namen erstellen, wenn die vollständige Sicherung durchgeführt und der Löschvorgang abgeschlossen ist. Je nach Größe der Datenbank kann die vollständige Sicherung mehrere Stunden dauern.

Es ist wahrscheinlich, dass Sie für den Monat keine Gutschriften mehr haben. Wechseln Sie im Azure-Portal zu Ihrer verwalteten SQL-Instanz, und überprüfen Sie den Status. Überprüfen Sie, ob sich Ihre Instanz wegen unzureichender Credits in einem angehaltenen Zustand befindet.

Diese Funktion ist derzeit nicht verfügbar.

Ja, Sie können automatisierte Sicherungen aus anderen von SQL verwalteten Instanzen wiederherstellen, oder Sie können eine lokale Datenbanksicherung mithilfe von SQL Server Management Studio (SSMS) oder durch Ausführen eines RESTORE DATABASE Befehls und der Zieldatei .bak aus Azure Storage oder S3 Buckets wiederherstellen.

Trotz der Ressourcenbeschränkungen ist die kostenlose SQL Managed-Version so konzipiert, dass Sie Ihre Workloads ohne Auswirkungen testen können. Die Leistung, die Sie beim Verwenden der kostenlosen SQL-verwalteten Instanz erleben, ist identisch mit der Leistung einer Produktionsversion der Instanz.

Die kostenlose verwaltete SQL-Instanz bietet nur 4 und 8 vCore-Optionen. Wenn Ihr Unternehmen eine Instanz mit mehr Ressourcen erfordert, sollten Sie es auf eine voll ausgestattete kostenpflichtige SQL Managed Instance aktualisieren.

Kostenlose verwaltete SQL-Instanz unterstützt PITR nur bis zu 7 Tage. Andere Sicherungsoptionen können für die kostenlose verwaltete SQL-Instanz nicht geändert werden.

Das Ändern des Namens einer verwalteten SQL-Instanz wird nicht unterstützt.

Ja, die standardmäßige DNS-Zone .database.windows.net der SQL-Verwalteten Instanz kann mit Ihrer eigenen geändert werden. Der SQL-verwaltete Instanzhostname-Teil seines FQDNs, einschließlich der zufällig generierten Unterzone (z.B. sqlmiFQDN.randomized-subzone vor dem .database.windows.net), sollte gleich bleiben.

So verwenden Sie statt der Standardzone eine andere DNS-Zone, z. B. .contoso.com:

• Verwenden Sie das Clientnetzwerkhilfsprogramm (CliConfg) von SQL Server, um einen Alias zu definieren. Sie können entweder nur den Hostnamen der verwalteten SQL-Instanz verwenden oder den Hostnamen der verwalteten SQL-Instanz, gefolgt von einem benutzerdefinierten Domänennamen. Das CliConfg-Tool fügt einen Alias in der Registrierung unter HKLM\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo oder "HKLM\SOFTWARE\WOW6432Node\Microsoft\MSSQLServer\Client\ConnectTo, je nachdem, ob Sie die 64-Bit-Version (C:\Windows\System32\cliconfg.exe) oder die 32-Bit-Version (C:\Windows\SysWOW64\cliconfg.exe) verwenden. Sie können auch einen Alias mithilfe einer Gruppenrichtlinie oder eines Skripts hinzufügen, aber Sie sollten beide festlegen, dass 32-Bit- und 64-Bit-Programme den Alias auflösen können.
• Verwenden Sie den CNAME-Eintrag in DNS mit dem Hostnamen der verwalteten SQL-Instanz, der auf den Domänennamen der VNet-lokalen SQL-Instanz verweist. In diesem Fall ist HostNameInCertificate=<VNet-local endpoint domain name> (empfohlen) oder TrustServerCertificate=TRUE erforderlich, wenn die Microsoft Entra-Authentifizierung verwendet wird.
• Verwenden Sie einen Eintrag in DNS mit dem Hostnamen der verwalteten SQL-Instanz, der auf die IP-Adresse der verwalteten SQL-Instanz verweist. Die Verwendung der IP-Adresse wird nicht empfohlen, da sie ohne vorherige Ankündigung geändert werden kann. In diesem Fall ist HostNameInCertificate=<VNet-local endpoint domain name> (empfohlen) oder TrustServerCertificate=TRUE erforderlich, wenn die Microsoft Entra-Authentifizierung verwendet wird.

Azure SQL Managed Instance bietet die gleichen Leistungsstufen pro Compute- und Speichergröße wie andere Bereitstellungsoptionen von Azure SQL-Datenbank. Wenn Sie Daten für eine einzelne Instanz konsolidieren möchten oder ein Feature benötigen, das ausschließlich in sql Managed Instance unterstützt wird. Sie können Ihre Daten mithilfe der BACPAC-Funktionalität (Export/Import) migrieren. Hier sind weitere Möglichkeiten zur Überlegung für die SQL-Datenbankmigration zu einer SQL Managed Instance:

• Verwenden der externen Datenquelle
• Verwenden von SQLPackage
• Verwenden von BCP

Eine Option ist das Exportieren einer Datenbank in eine BACPAC-Datei und das anschließende Importieren der BACPAC-Datei. Dieser Ansatz wird empfohlen, wenn Ihre Datenbank kleiner als 100 GB ist.

Transaktionsreplikation kann verwendet werden, wenn alle Tabellen in der Datenbank Primärschlüssel aufweisen und in der Datenbank keine In-Memory-OLTP-Objekte vorhanden sind.

Informationen zum Migrieren Ihrer SQL Server-Instanz finden Sie unter SQL Server zu Azure SQL Managed Instance: Anleitung zur Migration.

Informationen zur Migration von anderen Plattformen finden Sie in den Azure-Datenbankmigrationshandbüchern.

Für einen Leistungsvergleich zwischen SQL Managed Instance und SQL Server ist ein guter Ausgangspunkt der Artikel Best Practices for Performance Comparison between Azure SQL Managed Instance and SQL Server.

Weitere Informationen finden Sie unter Key causes of performance differences between SQL Managed Instance and SQL Server (Hauptursachen für Leistungsunterschiede zwischen SQL Managed Instance und SQL Server). Die Größe der Transaktionsprotokolldatei kann die Leistung einer Allgemeiner Zweck SQL Managed Instance beeinflussen. Weitere Informationen finden Sie unter Auswirkung der Protokolldateigröße auf die Leistung auf der Dienstebene „Universell“.

Sie können die Leistung Ihrer sql-verwalteten Instanz optimieren, indem Sie:

• Die automatische Optimierung, die aufgrund einer kontinuierlichen Leistungsoptimierung, die auf künstlicher Intelligenz und maschinellem Lernen basiert, für hohe Leistung und stabile Workloads sorgt.
• In-Memory-OLTP, das den Durchsatz und die Latenz bei transaktionalen Verarbeitungsworkloads verbessert und schnellere geschäftliche Erkenntnisse liefert.
• Anwendung einiger bewährter Methoden für die Anwendungs- und Datenbankoptimierung.
• Änderung des Verbindungstyps vom Proxy- in den Umleitungsmodus, um eine niedrigere Latenz und einen höheren Durchsatz zu erreichen, wenn Ihre Workload aus vielen kleinen Transaktionen besteht.

Erwägen Sie, die Größe der Datendateien zu erhöhen, um die Leistung auf einer Allzweck-Instanz zu verbessern. Informationen zur Optimierung der Speicherleistung auf einer universellen Instanz finden Sie unter Bewährte Speichermethoden für den Tarif „Universell“.

Informationen hierzu finden Sie unter Analysieren der Wartestatistik unter SQL Managed Instance. Bei einer Wartestatistik handelt es sich um Informationen, mit denen Sie ggf. besser verstehen können, warum die Abfragedauer lang ist. Darüber hinaus können Sie hiermit die Abfragen identifizieren, die sich im Datenbankmodul im Wartezustand befinden.

MSSQLSERVER_833 gibt an, dass die Ausführung einer E/A-Anforderung länger als 15 Sekunden dauerte. Dieser Fehler in azure SQL Managed Instance bezieht sich auf allgemeine Infrastrukturbedingungen und nicht auf die Workload. In Cloudumgebungen und Systemen, die Remotespeicher nutzen, gibt es mehrere Architekturebenen, die sich auf eine einzelne E/A-Anforderung auswirken. Dieses erwartete Verhalten ist eine bekannte Einschränkung des Dienstes, die typischerweise durch vorübergehende Netzwerkprobleme verursacht wird oder wenn Azure-Speicherressourcen vorübergehend nicht verfügbar sind. Das System wird in der Regel ohne Eingriff wiederhergestellt.

Dieses Vorkommen ist selten und wirkt sich nicht auf die durchschnittliche Latenz von E/A-Anforderungen für Remotespeicher aus. Abhängig von der spezifischen Workload oder dem Thread, der die E/A-Anforderung auslöst, können Kunden in bestimmten Szenarien möglicherweise SQL-Befehlstimeouts und erhöhte Latenz beobachten, während andere wahrscheinlich keinerlei Beeinträchtigungen feststellen. Beispielsweise blockieren nicht alle E/A-Anforderungen mit langer Ausführungszeit Operationen, wie etwa der Vorabrufseitenzugriff, der häufig nicht betroffen ist.

Die Verwendung des Dienstebenenupgrades der nächsten Generation kann dazu beitragen, dieses Problem zu beheben, da es die Leistung und Zuverlässigkeit ohne zusätzliche Kosten verbessert. Kunden werden ermutigt, sie nach einer verbesserten Servicequalität zu erkunden.

Wenn dieser Fehler dauerhaft auftritt, sollten Sie die Überprüfung von Workloadmustern, speicherleistung und Netzwerkkonfigurationen in Betracht ziehen. Erwägen Sie außerdem die Verwendung der Business Critical-Dienstebene, die für Anwendungen mit geringen E/A-Latenzanforderungen entwickelt wurde.

Alle möglichen Optionen zur Überwachung und Warnung bei der Nutzung und Leistung von SQL Managed Instance finden Sie im Blogbeitrag zu Überwachungsoptionen für Azure SQL Managed Instance. Informationen zur Leistungsüberwachung in Echtzeit für SQL Managed Instance finden Sie unter Leistungsüberwachung in Echtzeit für Azure SQL Managed Instance.

Weitere Informationen finden Sie unter Überwachung und Leistungsoptimierung.

Informationen hierzu finden Sie unter Leistungsüberwachung in Echtzeit für Azure SQL Managed Instance.

Ja, SQL Profiler wird für SQL Managed Instance unterstützt. Weitere Informationen finden Sie unter SQL Server Profiler. Allerdings sollten Sie stattdessen erweiterte Ereignisse für die Aktivität „Ablaufverfolgung“ in Erwägung ziehen, da sie weniger Auswirkungen auf die überwachte Instanz haben. Weitere Informationen finden Sie unter Übersicht über erweiterte Ereignisse.

Nein, sie werden nicht unterstützt. Sie können DMVs und den Abfragedatenspeicher zusammen mit SQL Profiler und XEvents verwenden, um Ihre Datenbanken zu überwachen.

Informationen hierzu finden Sie unter Überwachen der CPU-Auslastung auf Ihren SQL Server- und Azure SQL-Instanzen.

Ja. Anweisungen finden Sie unter Erstellen von Warnungen für SQL Managed Instance. Weitere Tipps und Tricks finden Sie in diesem Blog.

Warnungsmetriken sind nur für eine SQL-verwaltete Instanz verfügbar. Warnungsmetriken für einzelne Datenbanken in einer von SQL verwalteten Instanz sind nicht verfügbar.

Die Speichergröße für die verwaltete SQL-Instanz hängt von der ausgewählten Dienstebene (General Purpose, Next-Gen General Purpose oder Business Critical) ab. Informationen zu Speicherbeschränkungen dieser Dienstebenen finden Sie unter Ressourceneinschränkungen.

Die Mindestmenge an verfügbarem Speicherplatz in einer Instanz beträgt 32 GB. Der Speicher kann in Schritten von 32 GB bis zur maximalen Speichergröße hinzugefügt werden. Die ersten 32 GB sind kostenlos.

Ja, Sie können Add-On-Speicher unabhängig von Computeressourcen in gewissem Umfang erwerben. Weitere Informationen finden Sie unter Maximal reservierter Instanzspeicher in der Tabelle.

Informationen zur Optimierung der Speicherleistung finden Sie unter Best Practices für Speicher in Allgemeiner Zwecknutzung.

Nein, der Sicherungsspeicher wird nicht von Ihrem VON SQL verwalteten Instanzspeicherplatz abgezogen. Der Sicherungsspeicher ist unabhängig vom Instanzspeicherplatz, und seine Größe ist nicht begrenzt. Der Sicherungsspeicher wird durch den Zeitraum zum Beibehalten der Sicherung Ihrer Instanzdatenbanken begrenzt, der bis zu 35 Tagen festgelegt werden kann. Weitere Informationen finden Sie unter Automatisierte Sicherungen.

Um nachzuverfolgen, wann automatisierte Sicherungen auf einer SQL-verwalteten Instanz durchgeführt werden, sehen Sie sich Sicherungsaktivität überwachen an.

Ja, Sie können eine kopiegeschützte vollständige Sicherung in ihrem Azure Blob Storage erstellen, aber sie kann nur in einer sql-verwalteten Instanz wiederhergestellt werden. Ausführliche Informationen finden Sie unter "Nur Kopieren"-Sicherungen. Es ist jedoch nicht möglich, eine Kopiesicherung durchzuführen, wenn die Datenbank durch einen dienstverwalteten TDE verschlüsselt wird, da das für die Verschlüsselung verwendete Zertifikat nicht zugänglich ist. Verwenden Sie in diesem Fall das Feature "Point-in-time-restore", um die Datenbank in eine andere von SQL verwaltete Instanz zu verschieben oder zu einem vom Kunden verwalteten Schlüssel zu wechseln.

Ja, sie wird unterstützt und ist für SQL Server 2005 und höhere Versionen verfügbar. Wenn Sie die native Wiederherstellung verwenden möchten, laden Sie die BAK-Datei in Azure Blob Storage hoch, und führen Sie die T-SQL-Befehle aus. Weitere Informationen finden Sie unter Native Restore von URL.

Ja, aber nur bis SQL Server 2022, während des Mainstream-Supportzeitraums für SQL Server 2022. Eventuell werden in Zukunft einige Features in Azure SQL Managed Instance eingeführt, die Änderungen am Datenbankformat erfordern, sodass Sicherungen nicht mehr mit der neuesten Version von SQL Server kompatibel sind. Der Zugriff auf solche Features erfordert eine explizite Zustimmung.

Systemdatenbanken werden nicht in die sekundäre Instanz in einer Failovergruppe repliziert. Daher sind Szenarien, die von Objekten aus den Systemdatenbanken abhängen, in der sekundären Instanz nicht möglich, es sei denn, die Objekte werden manuell in der sekundären Instanz erstellt. Ein Problemumgehung finden Sie unter Aktivieren von Szenarios in Abhängigkeit von Objekten in den Systemdatenbanken.

Die erforderlichen NSG- und UDR-Regeln werden in der Konfiguration dienstgestützter Subnetze dokumentiert und vom Dienst automatisch festgelegt. Beachten Sie, dass diese Regeln nur diejenigen sind, die wir für die Wartung des Diensts benötigen. Um eine Verbindung mit einer von SQL verwalteten Instanz herzustellen und unterschiedliche Features zu verwenden, müssen Sie andere featurespezifische Regeln festlegen und verwalten.

Wie kann ich eingehende NSG-Regeln an Management Ports festlegen?

SQL Managed Instance ist für das Festlegen von Regeln auf Verwaltungs-Ports zuständig. Die Regeln werden über die Funktionalität namens dienstgestützte Subnetzkonfiguration festgelegt. Hiermit wird der unterbrechungsfreie Fluss von Verwaltungsdatenverkehr sichergestellt, um eine SLA zu erfüllen.

Ja. Sie können den durch Ihre Netzwerksicherheitsgruppe fließenden Datenverkehr analysieren, indem Sie Netzwerküberwachungs-Flussprotokolle konfigurieren.

Ja. Nachdem eine von SQL verwaltete Instanz bereitgestellt wurde, können Sie NSG festlegen, die den eingehenden Zugriff auf den Port 1433 steuert. Es wird empfohlen, den IP-Bereich so weit wie möglich einzugrenzen.

Nein Dies wird aus verschiedenen Gründen nicht unterstützt:

• Das Routing von Datenverkehr als Antwort auf eine eingehende Verwaltungsanforderung wäre asymmetrisch und würde nicht funktionieren.
• Das Routing des Datenverkehrs zu Azure Storage würde durch Durchsatzbeschränkungen und Latenz beeinträchtigt. Auf diese Weise ist es nicht möglich, die erwartete Dienstqualität und Verfügbarkeit zu gewährleisten.
• Diese Konfigurationen sind fehleranfällig und können nicht unterstützt werden.

Ja. Die einfachste Möglichkeit besteht darin, eine 0/0-Regel zu einem UDR hinzuzufügen, der dem SQL-verwalteten Instanzsubnetz zugeordnet ist, um den Datenverkehr über NVA weiterzuleiten.

Das Subnetz muss über eine ausreichende Anzahl verfügbarer IP-Adressen verfügen. Um die Größe des Subnetzes des virtuellen Netzwerks für die verwaltete SQL-Instanz zu bestimmen, sehen Sie Erforderliche Subnetzgröße und -bereich für Azure SQL Managed Instance ermitteln.

Falls nicht genügend IP-Adressen im Subnetz vorhanden sind, in dem Ihre SQL Managed Instance bereitgestellt wird, müssen Sie ein neues Subnetz erstellen und die verwaltete SQL-Instanz in dieses verschieben. Es wird auch empfohlen, das neue Subnetz mit mehr zugeordneten IP-Adressen zu erstellen, damit ähnliche Situationen bei zukünftigen Updatevorgängen vermieden werden können. Erfahren Sie, wie Sie Azure SQL Managed Instance zwischen Subnetzen verschieben.

Nein Sie können entweder ein leeres Subnetz oder ein Subnetz verwenden, das bereits eine oder mehrere verwaltete Instanzen enthält.

Nicht, wenn darin verwaltete Instanzen enthalten sind. Dies ist eine Einschränkung der Azure-Netzwerkinfrastruktur. Es ist für Sie nur zulässig, einem leeren Subnetz weiteren Adressraum hinzuzufügen.

Ja. Eine verwaltete SQL-Datenbank-Instanz kann online in ein anderes Subnetz innerhalb desselben virtuellen Netzwerks oder in ein anderes virtuelles Netzwerk verschoben werden. Erfahren Sie, wie Sie Azure SQL Managed Instance zwischen Subnetzen verschieben.

Das ist nicht erforderlich. Sie können entweder ein virtuelles Netzwerk für Azure SQL Managed Instance erstellen oder ein vorhandenes virtuelles Netzwerk für Azure SQL Managed Instance konfigurieren.

Nein Derzeit wird das Platzieren einer SQL-verwalteten Instanz in einem Subnetz, das bereits andere Ressourcentypen enthält, nicht unterstützt.

Nein, das wird nicht unterstützt. Der Hostname einer verwalteten SQL-Instanz wird dem Lastenausgleichsmodul vor dem virtuellen Cluster der verwalteten SQL-Instanz zugeordnet. Da ein virtueller Cluster mehrere verwaltete Instanzen hosten kann, kann eine Verbindung nicht an die richtige verwaltete SQL-Instanz weitergeleitet werden, ohne den Namen anzugeben. Weitere Informationen zur Architektur des virtuellen Clusters für SQL Managed Instances finden Sie unter Verbindungsarchitektur für virtuelle Cluster.

Derzeit garantieren nur private Endpunkte zu sql-verwalteten Instanzen statische IP-Adressen.

In seltenen, aber notwendigen Situationen können wir eine Onlinemigration einer SQL verwalteten Instanz zu einem neuen virtuellen Cluster oder einer anderen virtuellen Computergruppe innerhalb des virtuellen Clusters durchführen, da Änderungen am Technologiestack vorgenommen werden, die das Ziel haben, die Sicherheit und Zuverlässigkeit des Dienstes zu verbessern. Die Migration zu einer neuen virtuellen Computergruppe oder einem virtuellen Cluster führt zu einer Änderung der IP-Adresse, die dem Hostnamen der verwalteten SQL-Instanz zugeordnet ist. Der Dienst für verwaltete SQL-Instanzen bietet keine Unterstützung für statische IP-Adressen und behält sich das Recht vor, die IP-Adresse ohne Vorankündigung zu ändern, als Teil der regelmäßigen Wartungszyklen.

Aus diesem Grund sollten VNet-lokale und öffentliche Endpunkte nur über die zugehörigen Domänennamen aufgerufen werden. Wir raten dringend davon ab, sich auf die Unveränderlichkeit ihrer IP-Adresse zu verlassen, da dies zu längerer Nichtverfügbarkeit führen kann, während der Dienst fehlerfrei ist.

Wenn Sie eine statische IP-Adresse benötigen, die von außerhalb des virtuellen Netzwerks erreichbar ist, können Sie Azure Firewall mit einer frontend öffentlichen IP-Adresse bereitstellen und eine NAT-Regel konfigurieren, um eingehenden Datenverkehr in den privaten Endpunkt einer sql-verwalteten Instanz zu übersetzen. Richten Sie dann die DNS-Auflösung ein oder konfigurieren Sie Clientaliase, damit SQL-Clients über den vollqualifizierten Domänennamen der SQL verwalteten Instanz eine Verbindung mit der öffentlichen IP-Adresse der Firewall herstellen.

Ja, ein öffentlicher Endpunkt kann aktiviert werden, damit eingehender Datenverkehr aus dem Internet SQL Managed Instance erreichen kann. Weitere Informationen finden Sie unter Verwenden von SQL Managed Instance mit öffentlichen Endpunkten und Konfigurieren des öffentlichen Endpunkts in SQL Managed Instance.

Nein, die Verwendung eines benutzerdefinierten Ports ist nicht möglich. Für VNet-lokale Endpunkte verwendet SQL Managed Instance die Standardportnummer 1433 und für öffentliche Datenendpunkte, SQL Managed Instance verwendet die Standardportnummer 3342.

Sowohl das globale virtuelle Netzwerk-Peering als auch das virtuelle Azure-WAN werden empfohlen, um zwei verwaltete Instanzen in verschiedenen Regionen zu verbinden. Express-Route-Verbindungspeering ist eine alternative Option. Wenn in Ihrer Umgebung keine Option möglich ist, ist die einzige andere Konnektivitätsmethode eine Site-to-Site-VPN-Verbindung. Konfigurieren einer Site-to-Site-VPN-Verbindung über das Azure-Portal, mit PowerShell oder mit der Azure CLI

Unterstützung für globale virtuelle Netzwerk-Peering für neu erstellte virtuelle Cluster wurde am 22. September 2020 zu Azure SQL Managed Instance hinzugefügt. So wird das Peering virtueller Netzwerke für verwaltete Instanzen unterstützt, die nach dem 22. September 2020 in leeren Subnetzen erstellt wurden. Für Instanzen, die vor diesem Datum bereitgestellt worden sind, ist die Peeringunterstützung aufgrund der Einschränkungen beim globalen virtuellen Netzwerk-Peering auf die Netzwerke innerhalb derselben Region beschränkt. Weitere Informationen finden Sie im entsprechenden Abschnitt des Artikels Azure Virtual Network – häufig gestellte Fragen.

Um globale virtuelle Netzwerk-Peering mit Instanzen zu verwenden, die vor September 2020 erstellt wurden, sollten Sie ein Wartungsfenster konfigurieren. Oder erwägen Sie , die Instanz in ein neues Subnetz zu verschieben. Mit beiden Optionen wird die Instanz in einen neuen virtuellen Cluster verschoben, der globale virtuelle Netzwerk-Peering unterstützt.

Erfahren Sie , wie Sie überprüfen, ob das globale virtuelle Netzwerk-Peering bei Bedarf im virtuellen Cluster unterstützt wird.

Kunden wird empfohlen, zum Mindern von Risiken bei der Datenexfiltration eine Reihe von Sicherheitseinstellungen und -kontrollen anzuwenden:

• Aktivieren Sie Transparent Data Encryption (TDE) für alle Datenbanken.
• Deaktivieren Sie die Common Language Runtime (CLR). Diese Einstellung wird auch lokal empfohlen.
• Verwenden Sie nur die Microsoft Entra-Authentifizierung.
• Greifen Sie auf die Instanz mit einem DBA-Konto mit eingeschränkten Rechten zu.
• Konfigurieren Sie den Zugriff auf die JIT-Jumpbox für das Systemadministratorkonto.
• Aktivieren Sie SQL-Überwachung, und integrieren Sie sie in Warnungsmechanismen.
• Aktivieren Sie Bedrohungserkennung in der Microsoft Defender für SQL-Suite.
• Wenden Sie eine Dienstendpunktrichtlinie auf das Subnetz an, um den ausgehenden Datenverkehr an Azure Storage zu steuern.
• CREATE EXTERNAL TABLE AS SELECT (CETAS) ist standardmäßig deaktiviert. Informationen zum Aktivieren von CETAS über die Serverkonfigurationsoption allowPolyBaseExport finden Sie unter CREATE EXTERNAL TABLE AS SELECT (CETAS).

Ja. Weitere Informationen dazu finden Sie unter Auflösen privater DNS-Namen in Azure SQL Managed Instance.

Ja. Weitere Informationen dazu finden Sie unter Auflösen privater DNS-Namen in Azure SQL Managed Instance.

Die Zeitzonenkonfiguration kann festgelegt werden, wenn eine verwaltete SQL-Instanz zum ersten Mal bereitgestellt wird. Das Ändern der Zeitzone einer vorhandenen verwalteten SQL-Instanz wird nicht unterstützt. Weitere Informationen finden Sie unter Zeitzonenbeschränkungen.

Problemumgehungen umfassen das Erstellen einer neuen verwalteten SQL-Instanz mit der richtigen Zeitzone und dann entweder eine manuelle Sicherung und Wiederherstellung oder was wir empfehlen, eine instanzübergreifende Point-in-Time-Wiederherstellung durchzuführen.

Ja, Kunden können Anmeldeinformationen erstellen, die Mitglieder der Sysadmin-Rolle sind. Kunden, die die Sysadmin-Berechtigung übernehmen, übernehmen auch die Verantwortung für den Betrieb der Instanz, was sich negativ auf die SLA-Verpflichtung auswirken kann. Informationen zum Hinzufügen einer Anmeldung zur Sysadmin-Serverrolle finden Sie unter Microsoft Entra-Authentifizierung.

Ja, Azure SQL Managed Instance unterstützt Transparent Data Encryption (TDE). Weitere Informationen finden Sie unter Transparent Data Encryption für SQL Managed Instance.

Ja. Das Szenario „Azure Key Vault für BYOK“ ist für Azure SQL Managed Instance verfügbar. Weitere Informationen finden Sie unter Transparent Data Encryption mit kundenseitig verwaltetem Schlüssel.

Ja, das ist möglich. Um eine verschlüsselte SQL Server-Datenbank zu migrieren, müssen Sie Ihre vorhandenen Zertifikate in sql Managed Instance exportieren und importieren. Nehmen Sie dann eine vollständige Datenbanksicherung und stellen Sie sie in einer sql-verwalteten Instanz wieder her.

Sie können auch den Azure Database Migration Service nutzen, um die per TDE verschlüsselten Datenbanken zu migrieren.

Sie können die TDE-Schutzvorrichtung für SQL Managed Instance mit Azure Cloud Shell rotieren. Eine Anleitung finden Sie unter Transparent Data Encryption in SQL Managed Instance mithilfe eines eigenen Schlüssels aus dem Azure Key Vault.

Ja. Sie müssen die Datenbank nicht entschlüsseln, um sie in SQL Managed Instance wiederherzustellen. Sie müssen ein Zertifikat oder einen Schlüssel als Verschlüsselungsschutz im Quellsystem bereitstellen, damit SQL Managed Instance Daten aus der verschlüsselten Sicherungsdatei lesen kann. Dies kann auf zwei Arten erreicht werden:

• Laden Sie die Zertifikatschutzvorrichtung in SQL Managed Instance hoch. Das kann nur mithilfe von PowerShell geschehen. Im Beispielskript wird der gesamte Prozess beschrieben.
• Laden Sie eine asymmetrische Schlüsselschutzvorrichtung in Azure Key Vault hoch, und verweisen Sie in SQL Managed Instance darauf. Dieser Ansatz ähnelt dem Bring-your-own-Key(BYOK)-TDE-Anwendungsfall, der auch die Key Vault-Integration zum Speichern des Verschlüsselungsschlüssels verwendet. Wenn Sie den Schlüssel nicht als Verschlüsselungsschlüsselschutz verwenden möchten und nur den Schlüssel für die sql Managed Instance zum Wiederherstellen verschlüsselter Datenbanken verfügbar machen möchten, befolgen Sie die Anweisungen zum Einrichten von BYOK TDE, und aktivieren Sie nicht das Kontrollkästchen Stellen Sie den ausgewählten Schlüssel zur Standard-TDE-Schutzkomponente.

Nachdem Sie die Verschlüsselungsschutzvorrichtung für SQL Managed Instance verfügbar gemacht haben, können Sie mit dem Standardverfahren für die Datenbankwiederherstellung fortfahren.

Sql Managed Instance bietet ein vCore-basiertes Einkaufsmodell.

Sie können mit den Azure SQL-Vorteilen wie folgt Kosten sparen:

• Maximieren Sie die vorhandenen Investitionen in lokale Lizenzen, um mit dem Azure-Hybridvorteil bis zu 55 Prozent an Kosten zu sparen.
• Verpflichten Sie sich zu einer Reservierung für Computeressourcen und sparen Sie bis zu 33 Prozent mit Azure Reservations Vorteil. Kombinieren Sie diesen Vorteil mit dem Azure Hybrid-Vorteil für Einsparungen von bis zu 82 Prozent.
• Sparen Sie bis zu 55 Prozent gegenüber den Listenpreisen, indem Sie den Vorteil in Bezug auf Preise für Azure Dev/Test nutzen. Hierbei erhalten Sie vergünstigte Preise für Ihre laufenden Entwicklungs- und Testworkloads.

Um sich für den Vorteil für reservierte Instanzen zu qualifizieren, muss Ihr Abonnementtyp ein Enterprise Agreement (Angebotsnummern: MS-AZR-0017P oder MS-AZR-0148P) oder eine einzelne Vereinbarung mit Preisen für nutzungsbasierte Bezahlung (Angebotsnummern: MS-AZR-0003P oder MS-AZR-0023P) sein. Weitere Informationen zu Reservierungen finden Sie unter Azure Reservations.

Reservierungen können unter bestimmten Einschränkungen storniert, umgetauscht oder rückerstattet werden. Weitere Informationen finden Sie unter Self-Service-Umtausch und -Rückerstattungen für Azure-Reservierungen.

Informationen zu den Preisoptionen für SQL Managed Instance finden Sie auf der Seite mit den Preisen.

Sie können zu diesem Zweck die Microsoft Cost Management-Lösung verwenden. Navigieren Sie im Azure-Portal zu Abonnements, und wählen Sie Kostenanalyse aus.

Verwenden Sie die Option Kumulierte Kosten, und filtern Sie dann nach dem Ressourcentyp als microsoft.sql/managedinstances.

Sie können kompatible Microsoft- oder Drittanbieter-Clienttools für den Zugriff auf SQL Managed Instance verwenden, und es werden Ihnen auf Ihrer Azure-Rechnung keine zusätzlichen Kosten in Rechnung gestellt. Wenn für einige Tools jedoch eine Lizenz erforderlich ist, müssen Sie über eine offiziell lizenzierte Software verfügen. Diese Anforderung unterliegt separaten Vereinbarungen, die Sie mit jedem einzelnen Werkzeughersteller haben.

Die Menge an freiem Speicherplatz für Sicherungen entspricht der Menge an reserviertem Datenspeicher, den Sie erworben haben. Die gilt unabhängig vom festgelegten Aufbewahrungszeitraum für die Sicherungen. Wenn der Speicherverbrauch Ihrer Sicherungen den zugewiesenen kostenlosen Sicherungsspeicherplatz nicht überschreitet, verursachen automatisierte Sicherungen auf SQL Managed Instance keine zusätzlichen Kosten und sind daher kostenlos. Eine Überschreitung der Nutzung des Sicherungsspeichers über dem freien Speicherplatz führt zu zusätzlichen Kosten. Einzelheiten dazu finden Sie auf der Seite Preise im Abschnitt Sicherungsspeicher. Weitere technische Informationen zu automatisierten Sicherungen von SQL Managed Instance finden Sie unter Erläuterungen zur Nutzung von Sicherungsspeicher.

Sie können die Kosten für den Sicherungsspeicher über das Azure-Portal überwachen. Eine Anleitung finden Sie unter Überwachen der Kosten für automatisierte Backups.

Informationen zum Optimieren der Kosten für den Sicherungsspeicher finden Sie unter Feinabstimmung der Speicherkosten für Sicherungsspeicher in der verwalteten SQL-Instanz.

Es gibt auch eine Forrester-Studie, die ein besseres Verständnis der Nutzen, Kosten und Risiken im Zusammenhang mit der Bereitstellung von Azure SQL Managed Instance vermittelt: The Total Economic Impact™ of Microsoft Azure SQL Database Managed Instance.

Die Kennwortrichtlinie für verwaltete SQL-Instanzen für SQL-Anmeldungen erbt Azure-Plattformrichtlinien, die auf virtuelle VMs angewendet werden, die den virtuellen Cluster bilden, der die verwaltete SQL-Instanz besitzt. Derzeit ist es nicht möglich, diese Einstellungen zu ändern, da diese Einstellungen von Azure definiert und von der von SQL verwalteten Instanz geerbt werden.

Für jeden Anmeldenamen muss das Kennwort bei der Anmeldung festgelegt und nach dem Erreichen des maximalen Alters geändert werden.

Ja, es ist möglich, die Felder CHECK_POLICY und CHECK_EXPIRATION auf der Anmeldeebene zu steuern. Sie können die aktuellen Einstellungen überprüfen, indem Sie den folgenden T-SQL-Befehl ausführen:

SELECT *
FROM sys.sql_logins

Anschließend können Sie die angegebenen Anmeldeeinstellungen ändern, indem Sie Folgendes ausführen:

ALTER LOGIN <login_name> WITH CHECK_POLICY = OFF;
ALTER LOGIN <login_name> WITH CHECK_EXPIRATION = OFF;

Ersetzen Sie „test“ durch den gewünschten Login-Namen und passen Sie die Richtlinien- und Ablaufwerte an.

Weitere Informationen finden Sie unter Zertifikatsrotation für Azure SQL-Datenbank & SQL Managed Instance.

Weitere Informationen finden Sie unter Planen von Azure-Wartungsereignissen in SQL Managed Instance.

Änderungen und Funktionen, die mit der Feature-Welle vom November 2022 eingeführt wurden, stehen nun standardmäßig allen Instanzen zur Verfügung. Da separate Maßnahmen zum Registrieren einer Instanz nicht mehr erforderlich sind, wurden Optionen, die die Featurewelle vom November 2022 erwähnen, aus dem Azure-Portal entfernt.

Sie können für ein neues Feature von SQL Managed Instance stimmen oder eine neue Idee für eine Verbesserung im Feedbackforum von SQL Managed Instance bereitstellen. Auf diese Weise können Sie an der Produktentwicklung mitwirken und uns bei der Priorisierung von potenziellen Verbesserungen unterstützen.

Informationen zum Erstellen einer Azure-Supportanfrage finden Sie unter Erstellen einer Azure-Supportanfrage.

Zonenredundanz wird derzeit für die Allzweck-Dienststufe der nächsten Generation nicht unterstützt.

Nein, das Upgrade der Dienstebene der nächsten Generation wird derzeit weder für Instanzpools noch für Instanzen innerhalb eines Pools unterstützt.