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 Hardwarekonfigurationseigenschaften. 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 die Standard- als auch die Enterprise-Edition können bei einer Abdeckung durch eine Software Assurance mithilfe des Azure-Hybridvorteils (AHB) durch die Dienstebenen Universell (inklusive Upgrade auf die Dienstebene Universell der nächsten Generation, derzeit in der Vorschau) oder Unternehmenskritisch ausgetauscht werden. Dabei gelten die folgenden Austauschverhältnisse: 1 Standard-Edition = 1 Universell, 1 Enterprise-Edition = 1 Unternehmenskritisch, 1 Enterprise Edition = 4 Universell und 4 Universell = 1 Enterprise Edition. Weitere Informationen finden Sie unter Welche spezifischen Rechte gelten für den Azure-Hybridvorteil für SQL Server?.

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. Senden Sie eine Supportanfrage über das Azure-Portal, wenn Sie eine verwaltete Instanz in einer Region benötigen, die derzeit nicht unterstützt wird.

SQL Managed Instance verfügt über zwei Standardeinschränkungen: eine Einschränkung der Anzahl von Subnetzen, die Sie verwenden können, und eine Einschränkung der Anzahl von virtuellen Kernen, die Sie bereitstellen können. Die Einschränkungen variieren je nach Abonnementtyp und Region. Eine Liste mit den Einschränkungen für regionale Ressourcen nach Abonnementtyp finden Sie in der Tabelle unter Regionale Ressourcenbeschränkungen. Dies sind weiche Einschränkungen, die bei Bedarf erweitert werden können. 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 Features und Previewfunktionen finden Sie unter Neuerungen in Azure SQL Managed Instance.

Sie können eine verwaltete Instanz per Azure-Portal, PowerShell, Azure CLI und mit ARM-Vorlagen bereitstellen.

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

Dies ist eine aktuelle Einschränkung der zugrunde liegenden Komponente, bei der der Subnetzname anhand regulärer Ausdrücke überprüft wird: ^[a-zA-Z_][^\/:*?"<>|`'^]*(?<![.\s])$. Alle Namen, die die Überprüfung mit regulären Ausdrücken bestehen und gültige Subnetznamen sind, werden derzeit unterstützt.

Sie können Ihre verwaltete Instanz per Azure-Portal, PowerShell, Azure CLI oder mit ARM-Vorlagen skalieren.

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

Sie können verwaltete Instanzen über das Azure-Portal, mit PowerShell, mit der Azure-Befehlszeilenschnittstelle oder mit Resource Manager-REST-APIs löschen.

Die erwartete Dauer für die Erstellung einer neuen verwalteten Instanz oder die Änderung von Dienstebenen (virtuelle Kerne, 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.

• Eine Datenbank wird wiederhergestellt und gelöscht, bevor eine vollständige Sicherung erstellt wird. 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 löschen und eine weitere Datenbank mit demselben Namen erstellen, wenn die vollständige Sicherung erstellt und der Löschvorgang abgeschlossen ist. Je nach Größe der Datenbank kann die vollständige Sicherung mehrere Stunden dauern.

Es ist möglich, dass Ihr Abonnement nicht für die kostenlose SQL Managed Instance berechtigt ist. Andernfalls gibt es ein Limit von einer kostenlosen Instanz pro Abonnement. Sie müssen eine vorhandene kostenlose Instanz entfernen, um eine neue zu erstellen. Wenn Sie Ihre kostenlose Instanz kürzlich gelöscht haben, dauert es bis zu einer Stunde, bis der Banner des kostenlosen Angebots wieder angezeigt wird.

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

Diese Funktion ist derzeit nicht verfügbar.

Ja, Sie können eine automatisierte Sicherung aus Azure Storage wiederherstellen oder eine Datenbanksicherung mithilfe von SQL Server Management Studio (SSMS) 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 SQL-verwaltete Instanz bietet 4- und 8 vCore-Optionen. Wenn für Ihr Unternehmen eine Instanz mit mehr Ressourcen erforderlich ist, erstellen Sie eine voll ausgestattete kostenpflichtige SQL Managed Instance.

Sicherungsoptionen können für die kostenlose SQL-verwaltete Instanz nicht geändert werden.

Derzeit ist das Studentenabonnement nicht berechtigt. Überprüfen Sie für berechtigte Abonnements die kostenlosen SQL-verwaltete Instanz Voraussetzungen.

Die Namensänderung für eine verwaltete Instanz wird nicht unterstützt.

Ja. Die DNS-Standardzone .database.windows.net von SQL Managed Instance kann durch eine eigene ausgetauscht werden. Allerdings sollte der Hostnamensteil des FQDN der verwalteten Instanz nicht geändert werden.

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 Instanz oder den Hostnamen der verwalteten Instanz gefolgt von einem benutzerdefinierten Domänennamen verwenden. Das CliConfg-Tool fügt den Alias lediglich unter „HKLM\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo“ oder „HKLM\SOFTWARE\WOW6432Node\Microsoft\MSSQLServer\Client\ConnectTo“ zur Registrierung hinzu. Dies hängt davon ab, ob Sie die 64-Bit-Version (C:\Windows\System32\cliconfg.exe) oder die 32-Bit-Version (C:\Windows\SysWOW64\cliconfg.exe) verwenden, damit dies auch mithilfe einer Gruppenrichtlinie oder eines Skripts erfolgen kann. Verwenden Sie beide, um sicherzustellen, dass 32-Bit- und 64-Bit-Programme den Alias auflösen können.
• Verwenden Sie den CNAME-Eintrag im DNS, wobei der Hostname der verwalteten Instanz auf den FQDN der verwalteten Instanz verweist. In diesem Fall TrustServerCertificate=TRUE ist bei der Verwendung der Authentifizierung mit Microsoft Entra ID (früher Azure Active Directory) erforderlich.
• Verwenden Sie den A-Eintrag im DNS, wobei der Hostname der verwalteten Instanz auf die IP-Adresse der verwalteten Instanz verweist. Die Verwendung der IP-Adresse wird nicht empfohlen, da sie ohne vorherige Ankündigung geändert werden kann. In diesem Fall ist TrustServerCertificate=TRUE erforderlich, wenn Sie die Microsoft Entra-Authentifizierung verwenden.

Azure SQL Managed Instance bietet die gleichen Leistungsstufen pro Compute- und Speichergröße wie andere Bereitstellungsoptionen von Azure SQL-Datenbank. Wenn Sie Daten in einer einzelnen Instanz konsolidieren möchten oder einfach eine Funktion ausschließlich in SQL Managed Instance unterstützt werden soll, können Sie die Daten mithilfe der Export-/Import-Funktion (BACPAC) migrieren. Hier finden Sie weitere Optionen, wofür die SQL-Datenbankmigration zu SQL Managed Instance geeignet wäre:

• 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 die 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.

Weitere Informationen zum Migrieren von anderen Plattformen finden Sie im Leitfaden zur Azure-Datenbankmigration.

Als Ausgangspunkt für einen Leistungsvergleich zwischen einer verwalteten Instanz und SQL Server empfiehlt sich der Artikel The best practices for performance comparison between Azure SQL Managed Instance and SQL Server (Bewährte Methoden für den Leistungsvergleich zwischen Azure SQL Managed Instance und 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 sich auf die Leistung von SQL Managed Instance der Dienstebene „Universell“ auswirken. Weitere Informationen finden Sie unter Auswirkung der Protokolldateigröße auf die Leistung auf der Dienstebene „Universell“.

Sie können die Leistung Ihrer verwalteten Instanz wie folgt optimieren:

• 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 auf einer universellen Instanz die Leistung 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.

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 in Azure SQL-Datenbank und Azure SQL Managed Instance.

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.

Nein, Warnungsmetriken sind nur für eine verwaltete Instanz verfügbar. Warnungsmetriken für einzelne Datenbanken in einer verwalteten Instanz sind nicht verfügbar.

Die Speichergröße für SQL Managed Instance hängt von der ausgewählten Dienstebene (Universell, Universell der nächsten Generation oder Unternehmenskritisch) 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 Inkrementen 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 die Speicherleistung auf universeller Dienstebene.

Nein, der Sicherungsspeicher wird nicht vom Speicherplatz Ihrer verwalteten Instanz 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.

Informationen zum Nachverfolgen, wann automatisierte Sicherungen in SQL Managed Instance ausgeführt wurden, finden Sie unter Überwachen der Sicherungsaktivität.

Ja, Sie können in Azure Blob Storage eine vollständige Kopiesicherung erstellen. Diese kann jedoch nur in einer verwalteten Instanz wiederhergestellt werden. Weitere Informationen finden Sie unter Kopiesicherung. Allerdings ist die Kopiesicherung nicht möglich, wenn die Datenbank von einer dienstverwalteten TDE-Technologie verschlüsselt wird, da das für die Verschlüsselung verwendete Zertifikat nicht zugänglich ist. Verwenden Sie in diesem Fall die Point-in-Time-Wiederherstellung, um diese Datenbank auf eine andere verwaltete Instanz zu verschieben, oder wechseln Sie zu einem kundenseitig verwalteten Schlüssel.

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 Migrationsleitfaden: SQL Server zu Azure SQL Managed Instance.

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 sind hier dokumentiert und werden vom Dienst automatisch festgelegt. Beachten Sie, dass es sich bei diesen Regeln lediglich um die Regeln handelt, die wir für die Wartung des Diensts benötigen. Für die Verbindungsherstellung mit Ihrer Instanz und die Verwendung anderer Features müssen Sie weitere featurespezifische Regeln festlegen und pflegen.

SQL Managed Instance ist für das Festlegen von Regeln auf Verwaltungsports zuständig. Dies wird mit einer Funktion mit dem Namen dienstgestützte Subnetzkonfiguration erreicht. Hiermit wird der unterbrechungsfreie Fluss von Verwaltungsdatenverkehr sichergestellt, um eine SLA zu erfüllen.

Ja. Sie können Datenverkehr analysieren, der über Ihre Netzwerksicherheitsgruppen eingeht, indem Sie Network Watcher-Flussprotokolle konfigurieren.

Ja. Nachdem eine verwaltete Instanz bereitgestellt wurde, können Sie eine NSG festlegen, die den eingehenden Zugriff an Port 1433 steuert. Wir empfehlen Ihnen, den zugehörigen IP-Adressbereich so weit wie möglich zu begrenzen.

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. Dies lässt sich am einfachsten erreichen, indem eine 0/0-Regel einer UDR hinzugefügt wird, die dem Subnetz einer verwalteten Instanz zugeordnet ist. So kann Datenverkehr über das virtuelle Netzwerkgerät geleitet werden.

Das Subnetz muss eine ausreichende Anzahl verfügbarer IP-Adressen aufweisen. Informationen zur Ermittlung der Größe von VNet-Subnetzen für SQL Managed Instance finden Sie unter Bestimmen von Subnetzgröße und -bereich für Azure SQL Managed Instance.

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.

Dies ist nicht möglich, 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 Anordnen einer verwalteten Instanz in einem Subnetz, das bereits andere Ressourcentypen enthält, nicht unterstützt.

Nein, das wird nicht unterstützt. Der Hostname der verwalteten Instanz wird dem Lastenausgleich vor dem virtuellen Cluster der verwalteten Instanz zugeordnet. Da von einem einzelnen virtuellen Cluster mehrere verwaltete Instanzen gehostet werden können, kann eine Verbindung nicht an die korrekte verwaltete Instanz weitergeleitet werden, ohne deren 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 für verwaltete Instanzen statische IP-Adressen.

In seltenen, aber erforderlichen Situationen können wir eine Onlinemigration einer verwalteten Instanz zu einem neuen virtuellen Cluster oder einer anderen virtuellen Computergruppe innerhalb des virtuellen Clusters durchführen, da Technologiestapeländerungen zur Verbesserung der Sicherheit und Zuverlässigkeit des Diensts dienen. Die Migration zu einer neuen virtuellen Computergruppe führt zum Andern der IP-Adresse, die dem Hostnamen der verwalteten Instanz zugeordnet ist. Der Dienst für die verwaltete Instanz beansprucht keine Unterstützung statischer IP-Adressen und behält sich das Recht vor, die IP-Adresse im Rahmen regulärer Wartungszyklen ohne Vorankündigung zu ändern.

Aus dem oben genannten Grund sollte auf lokale und öffentliche VNet-Endpunkte nur über die zugehörigen Domänennamen zugegriffen 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 öffentlichen IP-Adresse des Frontends bereitstellen und eine NAT-Regel konfigurieren, um eingehenden Datenverkehr an den privaten Endpunkt einer verwalteten Instanz zu übersetzen. Richten Sie dann eine DNS-Auflösung ein oder konfigurieren Sie Client-Aliase, damit SQL-Clients über den vollqualifizierten Domänennamen der verwalteten Instanz eine Verbindung zur ö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 den lokalen VNet-Endpunkt verwendet SQL Managed Instance die Standardportnummer 1433 und für den öffentlichen Datenendpunkt die Standardportnummer 3342.

Sowohl das globale Peering virtueller Netzwerke (VNet-Peering) als auch Azure Virtual WAN werden empfohlen, um zwei verwaltete Instanzen in unterschiedlichen Regionen zu vernetzen. 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 globales Virtuelles-Netzwerk-Peering (VNet-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.

Wenn Sie globales VNet-Peering mit Instanzen verwenden möchten, die vor September 2020 erstellt wurden, sollten Sie ein Wartungsfenster konfigurieren oder die Instanz in ein neues Subnetz verschieben, da die Instanz bei beiden Optionen in einen neuen virtuellen Cluster verschoben wird, der das globale Peering virtueller Netzwerke 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). Dies wird auch für lokale Umgebungen empfohlen.
• Verwenden Sie nur die Microsoft Entra-Authentifizierung.
• Greifen Sie auf die Instanz mit einem DBA-Konto mit geringen 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 Instanz zum ersten Mal bereitgestellt wird. Das Ändern der Zeitzone einer vorhandenen verwalteten Instanz wird nicht unterstützt. Weitere Informationen finden Sie unter Zeitzonenbeschränkungen.

Als Problemumgehung können Sie eine neue verwaltete Instanz mit der richtigen Zeitzone erstellen und dann entweder eine Sicherung und Wiederherstellung oder eine instanzübergreifende Point-in-Time-Wiederherstellung durchführen (unsere Empfehlung).

Ja. Kunden können Anmeldungen erstellen, bei denen es sich um Mitglieder der sysadmin-Rolle handelt. Kunden, die über die sysadmin-Berechtigung verfügen, sind auch für den Betrieb der Instanz verantwortlich. Dies kann negative Auswirkungen auf die Erfüllung der SLA-Anforderungen haben. Informationen zum Hinzufügen der 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 TDE (Transparent Data Encryption) für SQL-Datenbank, SQL Managed Instance und Azure Synapse Analytics.

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

Ja, das ist möglich. Um eine verschlüsselte SQL Server-Datenbank zu migrieren, müssen Sie Ihre vorhandenen Zertifikate exportieren und in SQL Managed Instance importieren und anschließend eine vollständige Datenbanksicherung erstellen und auf einer verwalteten Instanz wiederherstellen.

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 bzw. einen Schlüssel als Verschlüsselungsschlüssel-Schutzvorrichtung im Quellsystem für SQL Managed Instance bereitstellen, um Daten aus der verschlüsselten Sicherungsdatei lesen zu können. 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 TDE-Anwendungsfall „Bring-Your-Own-Key“ (BYOK), in dem ebenfalls die Key Vault-Integration zum Speichern des Verschlüsselungsschlüssels verwendet wird. Wenn Sie den Schlüssel nicht als Schutzvorrichtung für den Verschlüsselungsschlüssel verwenden, sondern nur für SQL Managed Instance zum Wiederherstellen verschlüsselter Datenbanken zur Verfügung stellen möchten, befolgen Sie die Anweisungen zum Einrichten von BYOK-TDE, und aktivieren Sie nicht das Kontrollkästchen Legen Sie den ausgewählten Schlüssel als TDE-Standardschutzvorrichtung fest.

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.

Für SQL Managed Instance ist das vCore-basierte Kaufmodell verfügbar.

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.
• Gehen Sie eine Verpflichtung zur Reservierung von Computeressourcen ein, um mit dem Vorteil für reservierte Instanzen bis zu 33 Prozent der Kosten zu sparen. Kombinieren Sie dies mit dem Azure-Hybridvorteil, um Kosten in Höhe von bis zu 82 Prozent zu sparen.
• 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 Sparen von Kosten für Ressourcen mit reservierter Kapazität – Azure SQL-Datenbank und SQL Managed Instance.

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. Dies wird in separaten Vereinbarungen geregelt, die Sie mit jedem einzelnen Toolhersteller getroffen 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 sich der Verbrauch Ihres Sicherungsspeichers innerhalb der zugeordneten Menge an freiem Speicher für Sicherungen bewegt, fallen für automatisierte Sicherungen in SQL Managed Instance keine weiteren Kosten an. Sie sind also kostenlos. Eine Überschreitung der Nutzung des Sicherungsspeichers über den freien Speicherplatz hinaus verursacht zusätzliche 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.

Informationen zur Optimierung Ihrer Kosten für Sicherungsspeicher finden Sie unter Optimieren von Sicherungen für SQL Managed Instance.

Fallstudien zu SQL Managed Instance:

• Komatsu
• KMD
• PowerDETAILS
• Allscripts

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 SQL Managed Instance-Kennwortrichtlinie für SQL-Anmeldungen erbt Azure-Plattformrichtlinien, die auf die VMs angewendet werden, die einen virtuellen Cluster bilden, der die verwaltete Instanz enthält. Zurzeit ist es nicht möglich, irgendeine dieser Einstellungen zu ändern, da diese Einstellungen durch Azure definiert und von der verwalteten Instanz geerbt sind.

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 Anmeldenamen, und passen Sie Werte für Richtlinie und Ablauf an.)

Weitere Informationen finden Sie unter Grundlegendes zu den Änderungen im Zusammenhang mit der Stammzertifizierungsstelle für Azure SQL-Datenbank und SQL Managed Instance.

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

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.

Alle Regionen, Angebote und Abonnementtypen haben die Featurewelle ab November 2023 aktiviert.

Die Featurewelle ist für Instanzen in berechtigten Subnetzen verfügbar. Wenn keine neuen Features angezeigt werden, ist es wahrscheinlich, dass das Subnetz, in dem Ihre SQL Managed Instance bereitgestellt wird, nicht berechtigt ist.