Unterschiede bei T-SQL zwischen SQL Server und Azure SQL Managed Instance

  • Artikel

Gilt für:Azure SQL Managed Instance

In diesem Artikel werden die Unterschiede in der Syntax und dem Verhalten zwischen Azure SQL Managed Instance und SQL Server zusammengefasst und erläutert.

SQL Managed Instance bietet hohe Kompatibilität mit der SQL Server-Datenbank-Engine, und die meisten Features werden in SQL Managed Instance unterstützt.

Diagram showing the easy migration from SQL Server.

Es gibt einige PaaS-Einschränkungen, die in SQL Managed Instance eingeführt werden, und einige Verhaltensänderungen im Vergleich zu SQL Server. Die Unterschiede sind in die folgenden Kategorien unterteilt:

Die meisten dieser Features sind architekturbezogene Einschränkungen und stellen Dienstfeatures dar.

Temporäre bekannte Probleme, die in SQL Managed Instance erkannt und in Zukunft behoben werden, sind unter den Neuerungen beschrieben.

Hinweis

Microsoft Entra ID war zuvor als Azure Active Directory (Azure AD) bekannt.

Verfügbarkeit

Always On-Verfügbarkeitsgruppen

Hochverfügbarkeit ist in SQL Managed Instance integriert und kann von Benutzern nicht gesteuert werden. Folgende Anweisungen werden nicht unterstützt:

Backup

In Azure SQL Managed Instance werden automatische Sicherungen durchgeführt, sodass Benutzer vollständige COPY_ONLY-Sicherungen für Datenbanken erstellen können. Differenzielle, Protokoll- und Dateimomentaufnahme-Sicherungen werden nicht unterstützt.

  • Bei SQL Managed Instance können Sie eine Instanzdatenbank nur in einem Azure Blob Storage-Konto sichern:
    • Nur BACKUP TO URL wird unterstützt.
    • FILE, TAPE und Sicherungsmedien werden nicht unterstützt.
  • Die meisten allgemeinen WITH-Optionen werden unterstützt.
    • COPY_ONLY ist obligatorisch.
    • FILE_SNAPSHOT und CREDENTIAL werden nicht unterstützt.
    • Bandoptionen: REWIND, NOREWIND, UNLOAD und NOUNLOAD werden nicht unterstützt.
    • Protokollspezifische Optionen: NORECOVERY, STANDBY und NO_TRUNCATE werden nicht unterstützt.

Einschränkungen:

  • Bei SQL Managed Instance können Sie eine Instanzdatenbank in einer Sicherung mit bis zu 32 Stripes sichern. Dies ist ausreichend für Datenbanken mit bis zu 4 TB, wenn die Sicherungskomprimierung verwendet wird.

  • Sie können BACKUP DATABASE ... WITH COPY_ONLY nicht in einer Datenbank ausführen, die mit vom Dienst verwalteter Transparent Data Encryption (TDE) verschlüsselt ist. Die vom Dienst verwaltete TDE erzwingt die Verschlüsselung von Sicherungen mit einem internen TDE-Schlüssel. Der Schlüssel kann nicht exportiert werden, daher können Sie die Sicherung nicht wiederherstellen. Verwenden Sie automatische Sicherungen und die Point-in-Time-Wiederherstellung, oder verwenden Sie stattdessen vom Kunden verwaltete Transparent Data Encryption – BYOK (Bring Your Own Key). Sie können die Verschlüsselung für die Datenbank auch deaktivieren.

  • Native Sicherungen, die auf einer SQL Managed Instance-Instanz erstellt wurden, können nur auf einer SQL Server 2022-Instanz wiederhergestellt werden. Dies liegt daran, dass SQL Managed Instance im Vergleich zu anderen SQL Server-Versionen eine höhere interne Datenbankversion aufweist. Weitere Informationen finden Sie unter Wiederherstellen einer SQL Managed Instance-Datenbanksicherung auf SQL Server 2022.

  • Zum Sichern oder Wiederherstellen einer Datenbank in bzw. aus einem Azure-Speicher ist es erforderlich, sich über eine verwaltete Identität oder eine Shared Access Signature (SAS) zu authentifizieren. Dabei handelt es sich um einen URI, der Ihnen eingeschränkte Zugriffsrechte für Azure Storage-Ressourcen gewährt. Weitere Informationen zu diesem Thema. Die Verwendung von Zugriffsschlüsseln für diese Szenarios wird nicht unterstützt.

  • Die maximale Stripegröße für Sicherungen mit dem Befehl BACKUP in SQL Managed Instance beträgt 195 GB. Dies ist die maximale Blobgröße. Erhöhen Sie die Streifenanzahl im Backup-Befehl, um die einzelne Streifengröße zu reduzieren und innerhalb dieser Einschränkungen zu bleiben.

    Tipp

    Um diese Einschränkung beim Sichern einer Datenbank von SQL Server in einer lokalen Umgebung oder auf einem virtuellen Computer zu umgehen, haben Sie folgende Möglichkeiten:

    • Führen Sie die Sicherung mit DISK anstatt mit URL aus.
    • Laden Sie die Sicherungsdateien in Blob Storage hoch.
    • Stellen Sie die Daten in SQL Managed Instance wieder her.

    Der Befehl Restore in SQL Managed Instance unterstützt höhere Blobgrößen in den Sicherungsdateien, da für die Speicherung der hochgeladenen Sicherungsdateien ein anderer Blobtyp verwendet wird.

Informationen zu Sicherungen mithilfe von T-SQL finden Sie unter BACKUP.

Sicherheit

Überwachung

Die wichtigsten Unterschiede zwischen der Überwachung in Microsoft Azure SQL-Datenbank und SQL Server sind:

  • Bei SQL Managed Instance erfolgt die Überwachung auf Serverebene. Die .xel-Protokolldateien werden in Azure Blob Storage gespeichert.
  • In Azure SQL-Datenbank erfolgt die Überwachung auf Datenbankebene. Die .xel-Protokolldateien werden in Azure Blob Storage gespeichert.
  • Bei SQL Server-Instanz erfolgt die Überwachung lokaler oder virtueller Computer auf Serverebene. Ereignisse werden in Dateisystem- oder Windows-Ereignisprotokollen gespeichert.

Die XEvent-Überwachung in SQL Managed Instance unterstützt Azure Blob Storage-Ziele. Dateiprotokolle und Windows-Protokolle werden nicht unterstützt.

Wichtigste Unterschiede in der Syntax von CREATE AUDIT zur Überwachung in Azure Blob Storage:

  • Mit der neuen Syntax TO URL können Sie die URL des Azure Blob Storage-Containers angeben, in dem die .xel-Dateien gespeichert werden.
  • Die Syntax TO FILE wird nicht unterstützt, da SQL Managed Instance nicht auf Windows-Dateifreigaben zugreifen kann.

Weitere Informationen finden Sie unter

Zertifikate

SQL Managed Instance kann nicht auf Dateifreigaben und Windows-Ordner zugreifen. Daher gelten folgende Einschränkungen:

  • Die CREATE FROM/BACKUP TO-Datei wird für Zertifikate nicht unterstützt.
  • Das CREATE/BACKUP-Zertifikat aus FILE/ASSEMBLY wird nicht unterstützt. Dateien mit privaten Schlüsseln können nicht verwendet werden.

Siehe CREATE CERTIFICATE und BACKUP CERTIFICATE.

Problemumgehung: Anstatt eine Sicherung des Zertifikats zu erstellen und die Sicherung wiederherzustellen, rufen Sie den binären Inhalt des Zertifikats und den privaten Schlüssel ab, speichern Sie sie als SQL-Datei, und erstellen Sie Folgendes aus den Binärdaten:

CREATE CERTIFICATE
   FROM BINARY = asn_encoded_certificate
WITH PRIVATE KEY (<private_key_options>);

Anmeldeinformationen

Verwaltete Identitäten, Azure Key Vault und SHARED ACCESS SIGNATURE-Identitäten werden unterstützt. Windows-Benutzer werden nicht unterstützt.

Siehe CREATE CREDENTIAL und ALTER CREDENTIAL.

Kryptografieanbieter

SQL Managed Instance kann nicht auf Dateien zugreifen. Daher können keine Kryptografieanbieter erstellt werden:

Anmeldungen und Benutzer

  • Mithilfe von FROM CERTIFICATE, FROM ASYMMETRIC KEY und FROM SID erstellte SQL-Anmeldungen werden unterstützt. Siehe CREATE LOGIN. Serverprinzipale (Anmeldungen) werden auf Serverebene erstellt, und Benutzer (Datenbankprinzipale) werden auf Datenbankebene erstellt. Microsoft Entra-Anmeldungen, die mit der Syntax CREATE LOGIN erstellt wurden, sowie Microsoft Entra-Benutzer, die mit der Syntax CREATE USER FROM LOGIN erstellt wurden, werden unterstützt. Beim Erstellen eines Benutzers und der Angabe von FROM LOGIN wird dieser Benutzer der Anmeldung zugeordnet und erbt die ihm zugewiesenen Serverrollen und Berechtigungen.

    SQL Managed Instance unterstützt das Erstellen von eigenständigen Datenbankbenutzern auf der Grundlage von Microsoft Entra-Identitäten mit der Syntax CREATE USER [AADUser/AAD group] FROM EXTERNAL PROVIDER. Benutzer, die auf diese Weise erstellt wurden, sind nicht Serverprinzipale zugeordnet, auch wenn ein Serverprinzipal mit demselben Namen in der master-Datenbank vorhanden ist.

  • Windows-Anmeldungen, die mit der Syntax CREATE LOGIN ... FROM WINDOWS erstellt wurden, werden nicht unterstützt. Verwenden von Microsoft Entra-Anmeldungen und -Benutzern.

  • Der Microsoft Entra-Administrator der Instanz verfügt über uneingeschränkte Administratorrechte.

  • Einige Features unterstützen nicht die Verwendung von Microsoft Entra-Anmeldungen in instanzübergreifenden Interaktionen, sondern nur innerhalb einer einzelnen SQL Managed Instance, wie z. B. die SQL Server-Replikation. Das Verbindungsserverfeature unterstützt jedoch die instanzübergreifende Authentifizierung mithilfe von Microsoft Entra-Serverprinzipalen (Anmeldungen).

  • Das Festlegen einer Microsoft Entra-Anmeldung, die einer Microsoft Entra-Gruppe zugeordnet ist, als Datenbankbesitzer wird nicht unterstützt. Ein Mitglied der Microsoft Entra-Gruppe kann ein Datenbankbesitzer sein, auch wenn die Anmeldung nicht in der Datenbank erstellt wurde.

  • Identitätswechsel von Microsoft Entra-Prinzipalen auf Serverebene unter Verwendung anderer Microsoft Entra-Prinzipale werden unterstützt, z.B. in der EXECUTE AS-Klausel. Einschränkung für EXECUTE AS:

    • EXECUTE AS USER wird für Microsoft Entra-Benutzer nicht unterstützt, wenn der Name sich vom Anmeldenamen unterscheidet. Beispiel: Der Benutzer wird über die Syntax CREATE USER [myAadUser] FROM LOGIN [john@contoso.com] erstellt, und es wird ein Identitätswechsel über EXEC AS USER = myAadUser versucht. Wenn Sie einen Benutzer (USER) auf der Grundlage einer Microsoft Entra-Anmeldung erstellen, müssen Sie als Benutzername den gleichen Anmeldenamen angeben wie in der Anmeldung (LOGIN).

    • Die folgenden Vorgänge für Microsoft Entra-Prinzipale können nur von SQL Server-Anmeldungen ausgeführt werden, die der Rolle sysadmin angehören:

      • EXECUTE AS USER
      • EXECUTE AS LOGIN

    • Um eine Benutzeridentität mit der EXECUTE AS-Anweisung zu übernehmen, muss der Benutzer einer Microsoft Entra-Anmeldung zugeordnet werden. Die Identität von Benutzern, die Mitglieder von Microsoft Entra-Gruppen sind, die Microsoft Entra-Serverprinzipalen zugeordnet sind, kann mit der EXECUTE AS-Anweisung nicht effektiv angenommen werden. Dies gilt selbst dann, wenn der Aufrufer über IMPERSONATE-Berechtigungen für den angegebenen Benutzernamen verfügt.

  • Das Exportieren/Importieren von Datenbanken mithilfe von BACPAC-Dateien wird für Microsoft Entra-Benutzer in SQL Managed Instance mit SSMS V18.4 oder höher oder SqlPackage unterstützt.

    • Die folgenden Konfigurationen werden mit einer BACPAC-Datei für die Datenbank unterstützt:
      • Exportieren/Importieren einer Datenbank zwischen verschiedenen verwalteten Instanzen in derselben Microsoft Entra-Domäne
      • Exportieren einer Datenbank aus SQL Managed Instance und Importieren in SQL-Datenbank innerhalb derselben Microsoft Entra-Domäne
      • Exportieren einer Datenbank aus SQL-Datenbank und Importieren in SQL Managed Instance innerhalb derselben Microsoft Entra-Domäne
      • Exportieren einer Datenbank aus SQL Managed Instance und Importieren in SQL Server (ab Version 2012).
        • Bei dieser Konfiguration werden alle Microsoft Entra-Benutzer als SQL Server-Datenbankprinzipale (Benutzer) ohne Anmeldungen erstellt. Der Benutzertyp ist SQL und wird in sys.database_principals als SQL_USER angezeigt. Ihre Berechtigungen und Rollen verbleiben in den Metadaten der SQL Server-Datenbank und können für Identitätswechsel verwendet werden. Sie können jedoch nicht für den Zugriff und die Anmeldung bei SQL Server mithilfe der Anmeldeinformationen verwendet werden.

  • Nur die Serverebenenprinzipal-Anmeldung, die vom Bereitstellungsprozess von SQL Managed Instance, von Mitgliedern der Serverrollen (z. B. securityadmin oder sysadmin) oder von anderen Anmeldungen mit der Berechtigung ALTER ANY LOGIN auf Serverebene erstellt wurde, kann Microsoft Entra-Serverprinzipale (Anmeldungen) in der master-Datenbank für SQL Managed Instance erstellen.

  • SQL-Authentifizierungsbasierte Anmeldungen müssen der sysadmin Rolle zugewiesen werden, um Anmeldungen für Microsoft Entra-Identitäten zu erstellen.

  • Die Anmeldung muss Mitglied desselben Microsoft Entra-Mandanten sein, in dem Azure SQL Managed Instance gehostet wird.

  • Microsoft Entra-Serverprinzipale (Anmeldungen) werden ab SQL Server Management Studio 18.0 Preview 5 im Objekt-Explorer angezeigt.

  • Ein Serverprinzipal mit sysadmin-Zugriffsebene wird automatisch für das Microsoft Entra-Administratorkonto erstellt, sobald es für eine Instanz aktiviert ist.

  • Während der Authentifizierung wird die folgende Reihenfolge angewendet, um den authentifizierenden Prinzipal aufzulösen:

    1. Wenn das Microsoft Entra-Konto direkt einer Microsoft Entra-Anmeldung zugeordnet ist, die als Typ „E“ in sys.server_principals vorhanden ist, gewähren Sie den Zugriff und wenden Sie die Berechtigungen dieser Anmeldung an.
    2. Wenn das Microsoft Entra-Konto Mitglied einer Gruppe ist, die einer Microsoft Entra-Anmeldung zugeordnet ist, die als Typ „X“ in sys.server_principals vorhanden ist, gewähren Sie Zugriff und wenden Sie Berechtigungen für diese Anmeldung an.
    3. Wenn das Microsoft Entra-Konto direkt einem Microsoft Entra-Benutzer in einer Datenbank zugeordnet ist, die in sys.database_principals als Typ „E“ vorhanden ist, wird der Zugriff gewährt, und die Berechtigungen des Microsoft Entra-Datenbankbenutzers werden angewendet.
    4. Wenn das Microsoft Entra-Konto Mitglied einer Microsoft Entra-Gruppe ist, die einem Microsoft Entra-Benutzer in einer Datenbank zugeordnet ist, der in sys.database_principals als Typ „X“ vorhanden ist, gewähren Sie Zugriff und wenden Sie Berechtigungen des Microsoft Entra-Gruppenbenutzers an.

Dienstschlüssel und Diensthauptschlüssel

Konfiguration

Pufferpoolerweiterung

Sortierung

Die standardmäßige Instanzsortierung ist SQL_Latin1_General_CP1_CI_AS, sie kann als Erstellungsparameter angegeben werden. Siehe Sortierungen.

Kompatibilitätsgrade

  • Folgende Kompatibilitätsgrade werden unterstützt: 100, 110, 120, 130, 140, 150 und 160.
  • Kompatibilitätsgrade unter 100 werden nicht unterstützt.
  • Der standardmäßige Kompatibilitätsgrad für neue Datenbanken ist 150. Bei wiederhergestellten Datenbanken bleibt der Kompatibilitätsgrad unverändert, wenn er zuvor bei 100 und höher lag.

Siehe ALTER DATABASE-Kompatibilitätsgrad.

Datenbankspiegelung

Die Datenbankspiegelung wird nicht unterstützt.

  • Die Optionen ALTER DATABASE SET PARTNER und SET WITNESS werden nicht unterstützt.
  • CREATE ENDPOINT … FOR DATABASE_MIRRORING wird nicht unterstützt.

Weitere Informationen finden Sie unter ALTER DATABASE SET PARTNER und SET WITNESS und CREATE ENDPOINT … FOR DATABASE_MIRRORING.

Datenbankoptionen

  • Mehrere Protokolldateien werden nicht unterstützt.
  • In-Memory-Objekte werden in der Dienstebene „Universell“ nicht unterstützt.
  • Es gilt ein Grenzwert von 280 Dateien pro universeller Instanz, d.h. maximal 280 Dateien pro Datenbank. Auf der Dienstebene „Universell“ zählen sowohl Datendateien als auch Protokolldateien für diesen Grenzwert. Die Dienstebene „Unternehmenskritisch“ unterstützt 32.767 Dateien pro Datenbank.
  • Eine Datenbank darf keine Dateigruppen mit FILESTREAM-Daten enthalten. Es kann keine Wiederherstellung durchgeführt werden, wenn .bakFILESTREAM-Daten enthält.
  • Jede Datei wird in Azure Blob Storage gespeichert. E/A und Durchsatz pro Datei hängen von der Größe der jeweiligen Datei ab.

CREATE DATABASE-Anweisung

Für CREATE DATABASE gelten die folgenden Einschränkungen:

  • Dateien und Dateigruppen können nicht definiert werden.

  • Eine speicheroptimierte Dateigruppe und Datei werden automatisch hinzugefügt und als XTP bezeichnet.

  • Die CONTAINMENT-Option wird nicht unterstützt.

  • WITH-Optionen werden nicht unterstützt.

    Tipp

    Als Problemumgehung können Sie ALTER DATABASE nach CREATE DATABASE verwenden, um Datenbankoptionen zum Hinzufügen von Dateien oder Festlegen der Eigenständigkeit festzulegen.

  • Die FOR ATTACH-Option wird nicht unterstützt.

  • Die AS SNAPSHOT OF-Option wird nicht unterstützt.

Weitere Informationen finden Sie unter CREATE DATABASE.

ALTER DATABASE-Anweisung

Einige Dateieigenschaften können nicht festgelegt oder geändert werden:

  • Der Dateipfad kann nicht in der T-SQL-Anweisung ALTER DATABASE ADD FILE (FILENAME='path') angegeben werden. Entfernen Sie FILENAME aus dem Skript, da SQL Managed Instance die Dateien automatisch speichert.
  • Der Dateiname kann nicht mithilfe der Anweisung ALTER DATABASE geändert werden.
  • Das Ändern der XTP-Datei oder -Dateigruppe ist nicht zulässig.

Die folgenden Optionen werden standardmäßig festgelegt und können nicht geändert werden:

  • MULTI_USER
  • ENABLE_BROKER
  • AUTO_CLOSE OFF

Die folgenden Optionen können nicht geändert werden:

  • AUTO_CLOSE
  • AUTOMATIC_TUNING(CREATE_INDEX=ON|OFF)
  • AUTOMATIC_TUNING(DROP_INDEX=ON|OFF)
  • DISABLE_BROKER
  • EMERGENCY
  • ENABLE_BROKER
  • FILESTREAM
  • HADR
  • NEW_BROKER
  • OFFLINE
  • PAGE_VERIFY
  • PARTNER
  • READ_ONLY
  • RECOVERY BULK_LOGGED
  • RECOVERY_SIMPLE
  • REMOTE_DATA_ARCHIVE
  • RESTRICTED_USER
  • SINGLE_USER
  • WITNESS

Einige ALTER DATABASE-Anweisungen (z. B. SET CONTAINMENT) können vorübergehend Fehler verursachen, z. B. während der automatisierten Datenbanksicherung oder direkt nach dem Erstellen einer Datenbank. In diesem Fall sollte die ALTER DATABASE-Anweisung wiederholt werden. Weitere Informationen zu zugehörigen Fehlermeldungen finden Sie im Abschnitt Hinweise.

Weitere Informationen finden Sie unter ALTER DATABASE.

SQL Server-Agent

  • Das Aktivieren und Deaktivieren des SQL Server-Agents wird derzeit in SQL Managed Instance nicht unterstützt. Der SQL-Agent wird immer ausgeführt.
  • Der auf einer CPU im Leerlauf basierende Auftragszeitplan-Trigger wird nicht unterstützt.
  • SQL Server-Agent-Einstellungen sind schreibgeschützt. Die Prozedur sp_set_agent_properties wird in SQL Managed Instance nicht unterstützt.
  • Aufträge
    • T-SQL-Auftragsschritte werden unterstützt.
    • Die folgenden Replikationsaufträge werden unterstützt:
      • Transaktionsprotokollleser
      • Momentaufnahme
      • Verteiler
    • SSIS-Auftragsschritte werden unterstützt.
    • Andere Arten von Auftragsschritten werden derzeit nicht unterstützt:
      • Der Auftragsschritt für die Mergereplikation wird nicht unterstützt.
      • Der Warteschlangenleser wird nicht unterstützt.
      • Die Befehlsshell wird noch nicht unterstützt.
    • SQL Managed Instance kann nicht auf externe Ressourcen zugreifen – z. B. auf Netzwerkfreigaben über Robocopy.
    • SQL Server Analysis Services wird nicht unterstützt.
  • Benachrichtigungen werden teilweise unterstützt.
  • Die E-Mail-Benachrichtigung wird unterstützt. Dazu muss allerdings ein Datenbank-E-Mail-Profil konfiguriert werden. Der SQL Server-Agent kann nur ein Datenbank-E-Mail-Profil verwenden, für das der Name AzureManagedInstance_dbmail_profile angegeben werden muss.
    • Pager wird nicht unterstützt.
    • NetSend wird nicht unterstützt.
    • Warnungen werden noch nicht unterstützt.
    • Proxys werden nicht unterstützt.
  • EventLog wird nicht unterstützt.
  • Der Benutzer muss dem Microsoft Entra-Serverprinzipal (Anmeldung) direkt zugeordnet sein, um SQL-Agent-Aufträge zu erstellen, zu ändern oder auszuführen. Benutzer, die nicht direkt zugeordnet sind, z. B. Benutzer, die einer Microsoft Entra-Gruppe angehören, die über die Berechtigungen zum Erstellen, Ändern oder Ausführen von SQL-Agent-Aufträgen verfügt, können diese Aktionen nicht effektiv ausführen. Dies liegt an Einschränkungen beim Identitätswechsel für SQL Managed Instance und bei EXECUTE AS.
  • Das Feature „Multi Server Administration“ für Master-/Zielaufträge (MSX/TSX) wird nicht unterstützt.

Weitere Informationen zum SQL Server-Agent finden Sie unter SQL Server-Agent.

Tabellen

Die folgenden Tabellentypen werden nicht unterstützt:

Informationen zum Erstellen und Ändern von Tabellen finden Sie unter CREATE TABLE und ALTER TABLE.

Funktionen

BULK INSERT/OPENROWSET

SQL Managed Instance kann nicht auf Dateifreigaben und Windows-Ordner zugreifen. Daher müssen die Dateien aus Azure Blob Storage importiert werden:

  • DATASOURCE ist beim Importieren von Dateien aus Azure Blob Storage im Befehl BULK INSERT erforderlich. Siehe BULK INSERT.
  • DATASOURCE ist beim Lesen von Inhalten einer Datei aus Azure Blob Storage in der Funktion OPENROWSET erforderlich. Siehe OPENROWSET.
  • OPENROWSET kann zum Lesen von Daten aus Instanzen von Azure SQL-Datenbank, Azure SQL Managed Instance oder SQL Server verwendet werden. Andere Quellen wie Oracle-Datenbanken oder Excel-Dateien werden nicht unterstützt.

CLR

SQL Managed Instance kann nicht auf Dateifreigaben und Windows-Ordner zugreifen. Daher gelten folgende Einschränkungen:

Datenbank-E-Mail – (db_mail)

  • sp_send_dbmail kann keine Anlagen mithilfe des Parameters @file_attachments senden. Aus dieser Prozedur kann auf das lokale Dateisystem und externe Freigaben oder Azure Blob Storage nicht zugegriffen werden.
  • Informieren Sie sich zu den bekannten Problemen im Zusammenhang mit dem Parameter @query und Authentifizierung.

DBCC

Nicht dokumentierte DBCC-Anweisungen, die in SQL Server aktiviert sind, werden in SQL Managed Instance nicht unterstützt.

  • Es wird nur eine begrenzte Anzahl von globalen Ablaufverfolgungsflags unterstützt. Trace flags auf Sitzungsebene werden nicht unterstützt. Siehe Ablaufverfolgungsflags.
  • DBCC TRACEOFF und DBCC TRACEON funktionieren mit einer begrenzten Anzahl globaler Ablaufverfolgungsflags.
  • DBCC CHECKDB mit den Optionen REPAIR_ALLOW_DATA_LOSS, REPAIR_FAST und REPAIR_REBUILD kann nicht verwendet werden, weil die Datenbank im Modus SINGLE_USER nicht festgelegt werden kann. Siehe ALTER DATABASE-Unterschiede. Potenzielle Datenbankbeschädigungen werden vom Azure-Supportteam behandelt. Wenden Sie sich an den Azure-Support, wenn es Anzeichen für eine Beschädigung der Datenbank gibt.

Verteilte Transaktionen

Auf T-SQL und .NET basierte verteilte Transaktionen auf verwalteten Instanzen sind allgemein verfügbar. Zusätzliche Szenarien, z. B. XA-Transaktionen, verteilte Transaktionen zwischen verwalteten Instanzen und anderen Akteuren, werden mit DTC für Azure SQL Managed Instance unterstützt, das als Public Preview verfügbar ist.

Erweiterte Ereignisse

Einige Windows-spezifische Ziele für XEvents (Erweiterte Ereignisse) werden nicht unterstützt:

  • Das Ziel etw_classic_sync wird nicht unterstützt. Speichern Sie .xel-Dateien in Azure Blob Storage. Siehe etw_classic_sync-Ziel.
  • Das Ziel event_file wird nicht unterstützt. Speichern Sie .xel-Dateien in Azure Blob Storage. Siehe event_file-Ziel.

Externe Bibliotheken

Externe datenbankinterne R- und Python-Bibliotheken werden in einer begrenzten öffentlichen Vorschau unterstützt. Weitere Informationen finden Sie unter Machine Learning Services in Azure SQL Managed Instance (Vorschauversion)

FILESTREAM und FileTable

  • FILESTREAM-Daten werden nicht unterstützt.
  • Die Datenbank darf keine Dateigruppen mit FILESTREAM-Daten enthalten.
  • FILETABLE wird nicht unterstützt.
  • Tabellen dürfen keine FILESTREAM-Typen enthalten.
  • Die folgenden Funktionen werden nicht unterstützt:
    • GetPathLocator()
    • GET_FILESTREAM_TRANSACTION_CONTEXT()
    • PathName()
    • GetFileNamespacePat)
    • FileTableRootPath()

Weitere Informationen finden Sie unter FILESTREAM und FileTables.

Semantische Volltextsuche

Die semantische Suche wird nicht unterstützt.

Verbindungsserver

Verbindungsserver in SQL Managed Instance unterstützen eine begrenzte Anzahl von Zielen:

  • Unterstützte Ziele sind Instanzen von SQL Managed Instance, SQL-Datenbank, serverlosen und dedizierten Azure Synapse SQL-Pools und SQL Server.
  • Nicht unterstützte Ziele sind Dateien, Analysis Services und andere RDBMS. Verwenden Sie den nativen CSV-Import von Azure Blob Storage mit BULK INSERT oder OPENROWSET als Alternative zum Dateiimport, oder laden Sie Dateien mithilfe eines serverlosen SQL-Pools in Azure Synapse Analytics.

Vorgänge:

  • sp_dropserver wird zum Löschen eines Verbindungsservers unterstützt. Siehe sp_dropserver.
  • Die OPENROWSET-Funktion kann verwendet werden, um Abfragen nur auf SQL Server-Instanzen auszuführen. Diese Instanzen können verwaltet sein oder sich auf lokalen oder virtuellen Computern befinden. Siehe OPENROWSET.
  • Die OPENDATASOURCE-Funktion kann verwendet werden, um Abfragen nur auf SQL Server-Instanzen auszuführen. Diese Instanzen können verwaltet sein oder sich auf lokalen oder virtuellen Computern befinden. z. B. SELECT * FROM OPENDATASOURCE('SQLNCLI', '...').AdventureWorks2022.HumanResources.Employee. Als Anbieter werden nur die Werte SQLNCLI, SQLNCLI11, SQLOLEDB und MSOLEDBSQL unterstützt. Der SQL Server Native Client (häufig abgekürzt mit SNAC) wurde aus SQL Server 2022 und SQL Server Management Studio 19 (SSMS) entfernt. Der SQL Server Native Client (SQLNCLI oder SQLNCLI11) und der Microsoft OLE DB-Legacyanbieter für SQL Server (SQLOLEDB) werden für Neuentwicklungen nicht empfohlen. Verwenden Sie in Zukunft den neuen Microsoft OLE DB-Treiber für SQL Server (MSOLEDBSQL) oder den neuesten Microsoft ODBC Driver for SQL Server.
  • Verbindungsserver können nicht zum Lesen von Dateien (Excel, CSV) aus den Netzwerkfreigaben verwendet werden. Versuchen Sie, BULK INSERT und OPENROWSET für das Lesen von CSV-Dateien aus Azure Blob Storage oder einen Verbindungsserver, der auf einen serverlosen SQL-Pool in Synapse Analytics verweist, zu verwenden. Verfolgen Sie diese Anforderungen im Feedback zu SQL Managed Instance.

Die Verbindungsserver auf Azure SQL Managed Instance unterstützen sowohl die SQL-Authentifizierung als auch die Microsoft Entra-Authentifizierung.

PolyBase

Dank der Datenvirtualisierung mit Azure SQL Managed Instance können Sie T-SQL-Abfragen (Transact-SQL) für Daten aus Dateien ausführen, die in Azure Data Lake Storage Gen2 oder Azure Blob Storage gespeichert sind. Außerdem können Sie diese Daten mit lokal gespeicherten relationalen Daten über Joins kombinieren. Parquet- und CSV-Dateiformate (durch Trennzeichen getrennte Textdateien) werden direkt unterstützt. Das JSON-Dateiformat wird indirekt unterstützt, indem das CSV-Dateiformat angegeben wird, bei dem Abfragen jedes Dokument als separate Zeile zurückgeben. Es ist möglich, Zeilen mit JSON_VALUE und OPENJSON weiter zu analysieren. Allgemeine Informationen zu PolyBase finden Sie unter PolyBase.

Darüber hinaus ermöglicht CREATE EXTERNAL TABLE AS SELECT (CETAS) Ihnen, Daten aus Ihrer verwalteten SQL-Datenbank-Instanz in ein externes Speicherkonto zu exportieren. Sie können CETAS verwenden, um eine externe Tabelle auf der Grundlage von Parquet- oder CSV-Dateien in Azure Blob Storage oder Azure Data Lake Storage (ADLS) Gen2 zu erstellen. CETAS kann auch parallel die Ergebnisse einer T-SQL-SELECT-Anweisung in die erstellte externe Tabelle exportieren.

Replikation

  • Momentaufnahmen und bidirektionale Replikationstypen werden unterstützt. Mergereplikation, Peer-zu-Peer-Replikation und aktualisierbare Abonnements werden nicht unterstützt.
  • Die Transaktionsreplikation ist mit einigen Einschränkungen für SQL Managed Instance verfügbar:
    • Alle Replikationsteilnehmertypen (Herausgeber, Verteiler, Pullabonnent und Pushabonnent) können in SQL Managed Instance platziert werden. Der Herausgeber und der Verteiler müssen dabei entweder beide in der Cloud oder beide lokal platziert sein.
    • SQL Managed Instance kann mit der neuesten SQL Server-Version kommunizieren. Weitere Informationen finden Sie in der Matrix der unterstützten Versionen.
    • Für die Transaktionsreplikation gibt es einige zusätzliche Netzwerkanforderungen.

Weitere Informationen zum Konfigurieren von Transaktionsreplikation finden Sie in den folgenden Tutorials:

RESTORE-Anweisung

  • Unterstützte Syntax:
    • RESTORE DATABASE
    • RESTORE FILELISTONLY
    • RESTORE HEADERONLY
    • RESTORE LABELONLY
    • RESTORE VERIFYONLY
  • Nicht unterstützte Syntax:
    • RESTORE LOGONLY
    • RESTORE REWINDONLY
  • Quelle:
    • FROM URL (Azure Blob Storage) ist die einzige unterstützte Option.
    • FROM DISK/TAPE/Sicherungsmedium wird nicht unterstützt.
    • Sicherungssätze werden nicht unterstützt.
  • WITH-Optionen werden nicht unterstützt. Wiederherstellungsversuche mit WITH wie DIFFERENTIAL, STATS, REPLACE usw. sind nicht erfolgreich.

Ein Vorgang zur Wiederherstellung der Datenbank ist asynchron und kann in Azure SQL Managed Instance wiederholt werden. Sie erhalten möglicherweise eine Fehlermeldung in SSMS, wenn bei der Verbindung ein Fehler auftritt oder ein Timeout abläuft. Azure SQL Managed Instance versucht weiterhin, die Datenbank im Hintergrund wiederherzustellen, und Sie können den Fortschritt des Wiederherstellungsvorgangs mithilfe der Ansichten sys.dm_exec_requests und sys.dm_operation_status nachverfolgen.

Die folgenden Datenbankoptionen werden festgelegt oder überschrieben und können später nicht geändert werden:

  • NEW_BROKER, wenn der Broker in der BAK-Datei nicht aktiviert ist.
  • ENABLE_BROKER, wenn der Broker in der BAK-Datei nicht aktiviert ist.
  • AUTO_CLOSE=OFF, wenn eine Datenbank in der BAK-Datei AUTO_CLOSE=ON enthält.
  • RECOVERY FULL, wenn eine Datenbank in der BAK-Datei den Wiederherstellungsmodus SIMPLE oder BULK_LOGGED enthält.
  • Eine speicheroptimierte Dateigruppe wird hinzugefügt und erhält den Namen „XTP“, wenn sie in der BAK-Quelldatei nicht vorhanden war.
  • Alle vorhandenen speicheroptimierten Dateigruppen werden in „XTP“ umbenannt.
  • Die Optionen SINGLE_USER und RESTRICTED_USER werden zu MULTI_USER konvertiert.

Einschränkungen:

  • Sicherungen der beschädigten Datenbanken werden je nach Art der Beschädigung möglicherweise wiederhergestellt, automatisierte Sicherungen werden jedoch erst ausgeführt, nachdem die Beschädigung behoben wurde. Stellen Sie sicher, dass Sie DBCC CHECKDB für die Quellinstanz von SQL Managed Instance ausführen und für die Sicherung WITH CHECKSUM verwenden, um dieses Problem zu vermeiden.
  • Die Wiederherstellung der .BAK-Datei einer Datenbank, die eine in diesem Dokument beschriebene Einschränkung enthält (z. B. FILESTREAM- oder FILETABLE-Objekte), kann nicht in SQL Managed Instance durchgeführt werden.
  • .BAK-Dateien mit mehreren Sicherungssätzen können nicht wiederhergestellt werden.
  • .BAK-Dateien mit mehreren Protokolldateien können nicht wiederhergestellt werden.
  • Sicherungen, die Datenbanken von mehr als 8 TB, aktive In-Memory-OLTP-Objekte oder eine Reihe von Dateien enthalten, die das Limit von 280 Dateien pro Instanz überschreiten würden, können auf einer universellen Instanz nicht wiederhergestellt werden.
  • Sicherungen, die Datenbanken mit mehr als 4 TB oder In-Memory-OLTP-Objekte enthalten, deren Gesamtgröße größer ist als die unter Ressourcenlimits beschriebene Größe, können auf der unternehmenskritischen Instanz nicht wiederhergestellt werden. Weitere Informationen zu Anweisungen für Wiederherstellungen finden Sie unter RESTORE-Anweisungen.

Wichtig

Die gleichen Einschränkungen gelten für den integrierten Vorgang der Point-in-Time-Wiederherstellung. So kann beispielsweise eine universelle Datenbank, die größer als 4 TB ist, auf einer unternehmenskritischen Instanz nicht wiederhergestellt werden. Eine unternehmenskritische Datenbank mit In-Memory-OLTP-Dateien oder mehr als 280 Dateien kann auf einer universellen Instanz nicht wiederhergestellt werden.

Service Broker

Der instanzübergreifende Service Broker-Nachrichtenaustausch wird nur zwischen Azure SQL Managed Instance-Instanzen unterstützt:

  • CREATE ROUTE: Sie können CREATE ROUTE nicht mit ADDRESS verwenden, es sei denn, Sie verwenden LOCAL oder den DNS-Namen einer Instanz von SQL Managed Instance. Der Port ist immer 4022.
  • ALTER ROUTE: Sie können ALTER ROUTE nicht mit ADDRESS verwenden, es sei denn, Sie verwenden LOCAL oder den DNS-Namen einer Instanz von SQL Managed Instance. Der Port ist immer 4022.

Transportsicherheit wird unterstützt, Dialogsicherheit dagegen nicht:

  • CREATE REMOTE SERVICE BINDING wird nicht unterstützt.

Service Broker ist standardmäßig aktiviert und kann nicht deaktiviert werden. Folgende Optionen für „ALTER DATABASE“ werden nicht unterstützt:

  • ENABLE_BROKER
  • DISABLE_BROKER

Gespeicherte Prozeduren, Funktionen und Trigger

  • NATIVE_COMPILATION wird in der Dienstebene „Universell“ nicht unterstützt.
  • Die folgenden sp_configure-Optionen werden nicht unterstützt:
    • allow polybase export
    • allow updates
    • filestream_access_level
    • remote access
    • remote data archive
    • remote proc trans
    • scan for startup procs
  • Die folgenden sp_configure-Optionen werden ignoriert und haben keine Auswirkungen:
    • Ole Automation Procedures
  • sp_execute_external_scripts wird nur für Machine Learning Services für SQL MI unterstützt, ansonsten wird sp_execute_external_scripts für SQL Managed Instance nicht unterstützt. Siehe sp_execute_external_scripts.
  • xp_cmdshell wird nicht unterstützt. Siehe xp_cmdshell.
  • Extended stored procedures werden nicht unterstützt. Hierzu gehören sp_addextendedproc und sp_dropextendedproc. Diese Funktion wird nicht unterstützt, da sie sich in einem veralteten Pfad für SQL Server befindet. Weitere Informationen finden Sie unter Erweiterte gespeicherte Prozeduren der Datenbank-Engine – Programmierung.
  • sp_attach_db, sp_attach_single_file_db und sp_detach_db werden nicht unterstützt. Siehe sp_attach_db, sp_attach_single_file_db und sp_detach_db.

Systemfunktionen und Variablen

Die folgenden Variablen, Funktionen und Sichten geben abweichende Ergebnisse zurück:

  • SERVERPROPERTY('EngineEdition') gibt den Wert 8 zurück. Durch diese Eigenschaft wird eine Instanz von SQL Managed Instance eindeutig identifiziert. Siehe SERVERPROPERTY.
  • SERVERPROPERTY('InstanceName') gibt NULL zurück, da das für SQL Server bestehende Konzept der Instanz für SQL Managed Instance nicht gilt. Siehe SERVERPROPERTY('InstanceName').
  • @@SERVERNAME gibt einen vollständigen DNS-Namen „connectable“ zurück, z. B. my-managed-instance.wcus17662feb9ce98.database.windows.net. Weitere Informationen finden Sie unter @@SERVERNAME.
  • SYS.SERVERS gibt den vollständigen „verbindungsfähigen“ DNS-Namen zurück, z. B. myinstance.domain.database.windows.net für die Eigenschaften „name“ und „data_source“. Weitere Informationen finden Sie unter SYS.SERVERS.
  • @@SERVICENAME gibt NULL zurück, da das für SQL Server bestehende Konzept des Diensts für SQL Managed Instance nicht gilt. Siehe @@SERVICENAME.
  • SUSER_ID wird unterstützt. Es gibt NULL zurück, wenn die Microsoft Entra-Anmeldung nicht enthalten sys.sysloginsist. Siehe SUSER_ID.
  • SUSER_SID wird nicht unterstützt. Es werden falsche Daten zurückgegeben. Dies ist ein bekanntes vorübergehendes Problem. Siehe SUSER_SID.

Umgebungseinschränkungen

Subnet

  • Sie können keine anderen Ressourcen (z. B. virtuelle Computer) in dem Subnetz platzieren, in dem Sie SQL Managed Instance bereitgestellt haben. Stellen Sie diese Ressourcen in einem anderen Subnetz bereit.
  • Das Subnetz muss eine ausreichende Anzahl verfügbarer IP-Adressen aufweisen. Es müssen mindestens 32 IP-Adressen im Subnetz vorhanden sein.
  • Für die Anzahl von virtuellen Kernen und die Typen der Instanzen, die Sie in einer Region platzieren können, gibt es einige Einschränkungen und Grenzwerte.
  • Es gibt eine Netzwerkkonfiguration, die auf das Subnetz angewandt werden muss.

Virtuelles Netzwerk

  • Virtual Network kann mithilfe des Ressourcenmodells bereitgestellt werden. Das klassische Modell unterstützt keine Virtual Network (VNet)-Bereitstellung.
  • Nachdem eine Instanz von SQL Managed Instance erstellt wurde, wird das Verschieben dieser Instanz oder des VNet in eine andere Ressourcengruppe oder ein anderes Abonnement nicht unterstützt.
  • Für verwaltete SQL-Instanzen, die in virtuellen Clustern gehostet werden und vor dem 22. September 2020 erstellt wurden, wird globales VNet-Peering nicht unterstützt. Sie können sich mit diesen Ressourcen über ExpressRoute oder VNET-zu-VNET über VNet-Gateways verbinden.

Failovergruppen

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.

tempdb

  • Die maximale Dateigröße der Systemdatenbank tempdb darf in der Dienstebene „Universell“ 24 GB pro Kern nicht überschreiten. Die maximale Größe von tempdb ist in der Dienstebene „Unternehmenskritisch“ auf die Speichergröße von SQL Managed Instance begrenzt. Die Größe der Protokolldatei tempdb ist bei der Dienstebene „Universell“ auf 120 GB begrenzt. Einige Abfragen geben möglicherweise einen Fehler zurück, wenn für sie mehr als 24 GB pro Kern in tempdb erforderlich sind oder die erstellten Protokolldaten mehr als 120 GB benötigen.
  • tempdb wird immer in 12 Datendateien aufgeteilt: 1 primäre Datendatei (auch als master-Datei bezeichnet) und 11 nicht primäre Datendateien. Die Dateistruktur kann nicht geändert werden, und es können auch keine neuen Dateien zu tempdb hinzugefügt werden.
  • Speicheroptimierte TempDB-Metadaten, ein neues In-Memory Database-Feature von SQL Server 2019, wird nicht unterstützt.
  • In der model-Ddatenbank erstellte Objekte können in tempdb nach einem Neustart oder Failover nicht automatisch erstellt werden, weil tempdb die anfängliche Objektliste nicht aus der model-Datenbank abruft. Sie müssen Objekte in tempdb nach jedem Neustart oder Failover manuell erstellen.

msdb

Die folgenden Schemas in der Systemdatenbank msdb in SQL Managed Instance müssen ihren jeweiligen vordefinierten Rollen gehören:

Wichtig

Das Ändern der vordefinierten Rollennamen, Schemanamen und Schemabesitzer durch Kunden wirkt sich auf den normalen Betrieb des Diensts aus. Alle Änderungen, die an diesen Angaben vorgenommen werden, werden auf die vordefinierten Werte zurückgesetzt, sobald sie erkannt werden, oder spätestens beim nächsten Dienstupdate, um den normalen Dienstbetrieb sicherzustellen.

Fehlerprotokolle

SQL Managed Instance stellt ausführliche Informationen in Fehlerprotokollen zur Verfügung. Es gibt viele interne Systemereignisse, die im Fehlerprotokoll protokolliert werden. Verwenden Sie zum Lesen von Fehlerprotokollen eine benutzerdefinierte Prozedur, die einige nicht relevante Einträge herausfiltert. Weitere Informationen finden Sie unter SQL Managed Instance: sp_readmierrorlog oder SQL Managed Instance-Erweiterung (Vorschauversion) für Azure Data Studio.

Das Ändern der Anzahl der aufbewahrten Fehlerprotokolle wird nicht unterstützt.

Zugehöriger Inhalt