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

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.

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.

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 wird 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 verwalteten SQL-Instanz erstellt wurden, können nicht auf einer SQL Server-Instanz wiederhergestellt werden. Dies liegt daran, dass SQL Managed Instance im Vergleich zu einer SQL Server-Version eine höhere interne Datenbankversion aufweist.

  • Zum Sichern oder Wiederherstellen einer Datenbank in bzw. aus einem Azure-Speicher ist es erforderlich, eine Shared Access Signature (SAS) mit einem URI zu erstellen, 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

Nur 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.

  • Azure Active Directory-Dienstprinzipale (Anmeldungen), die mit der Syntax CREATE LOGIN oder der Syntax CREATE USER FROM LOGIN [Azure AD-Anmeldung] erstellt wurden, werden unterstützt. Diese Anmeldungen werden auf Serverebene erstellt.

    SQL Managed Instance unterstützt Azure AD-Datenbankprinzipale mit der Syntax CREATE USER [AADUser/AAD group] FROM EXTERNAL PROVIDER. Dieses Feature wird auch als Azure AD-Benutzer für eigenständige Datenbanken bezeichnet.

  • Windows-Anmeldungen, die mit der Syntax CREATE LOGIN ... FROM WINDOWS erstellt wurden, werden nicht unterstützt. Verwenden Sie Azure Active Directory-Anmeldungen und -Benutzer.

  • Der Azure AD-Administrator der Instanz verfügt über uneingeschränkte Administratorrechte.

  • Azure AD-Benutzer auf Datenbankebene ohne Administratorrechte können mit der Syntax CREATE USER ... FROM EXTERNAL PROVIDER erstellt werden. Siehe CREATE USER ... FROM EXTERNAL PROVIDER.

  • Azure AD-Serverprinzipale (Anmeldungen) unterstützen SQL-Features nur innerhalb einer Instanz von SQL Managed Instance. Funktionen, die eine instanzübergreifende Interaktion erfordern – unabhängig davon, ob innerhalb desselben Azure AD-Mandanten oder in verschiedenen Mandanten –, werden für Azure AD-Benutzer nicht unterstützt. Beispiele für solche Funktionen:

    • SQL-Transaktionsreplikation
    • Linkserver
  • Das Festlegen einer Azure AD-Anmeldung, die einer Azure AD-Gruppe zugeordnet ist, als Besitzer der Datenbank wird nicht unterstützt. Ein Mitglied der Azure AD-Gruppe kann ein Datenbankbesitzer sein, auch wenn die Anmeldung nicht in der Datenbank erstellt wurde.

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

    • EXECUTE AS USER wird für Azure AD-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 eines Azure AD-Serverprinzipals (Anmeldung) erstellen, müssen Sie als Benutzernamen den gleichen Anmeldenamen angeben wie in der Anmeldung (LOGIN).

    • Die folgenden Vorgänge für Azure AD-Prinzipale können nur von Prinzipalen (Anmeldungen) auf SQL Server-Ebene ausgeführt werden, die der Rolle sysadmin angehören:

      • EXECUTE AS USER
      • EXECUTE AS LOGIN
    • Um die Identität eines Benutzers mit einer EXECUTE AS-Anweisung anzunehmen, muss der Benutzer dem Azure AD-Serverprinzipal (Anmeldung) direkt zugeordnet werden. Die Identität von Benutzern, die Mitglieder von Azure AD-Gruppen sind, die Azure AD-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 Azure AD-Benutzer in SQL Managed Instance per SSMS V18.4 oder höher oder SQLPackage.exe 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 Azure AD-Domäne
      • Exportieren einer Datenbank aus SQL Managed Instance und Importieren in SQL-Datenbank innerhalb derselben Azure AD-Domäne
      • Exportieren einer Datenbank aus SQL-Datenbank und Importieren in SQL Managed Instance innerhalb derselben Azure AD-Domäne
      • Exportieren einer Datenbank aus SQL Managed Instance und Importieren in SQL Server (ab Version 2012).
        • Bei dieser Konfiguration werden alle Azure AD-Benutzer als SQL Server-Datenbankprinzipale (Benutzer) ohne Anmeldungen erstellt. Der Benutzertyp wird als SQL aufgeführt und 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 Prinzipalanmeldung auf Serverebene, 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 Azure AD-Serverprinzipale (Anmeldungen) in der Masterdatenbank für SQL Managed Instance erstellen.

  • Wenn es sich bei der Anmeldung um einen SQL-Prinzipal handelt, können nur Anmeldungen, die der Rolle sysadmin angehören, den Befehl „create“ verwenden, um Anmeldungen für ein Azure AD-Konto zu erstellen.

  • Die Azure AD-Anmeldung muss Mitglied einer Azure AD-Instanz im selben Verzeichnis sein, das auch für Azure SQL Managed Instance verwendet wird.

  • Azure AD-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 Azure AD-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 Azure AD-Konto direkt dem Azure AD-Serverprinzipal (Anmeldung) zugeordnet ist, der in sys.server_principals als Typ „E“ vorhanden ist, wird der Zugriff gewährt, und die Berechtigungen des Azure AD-Serverprinzipals (Anmeldung) werden angewendet.
    2. Wenn das Azure AD-Konto Mitglied einer Azure AD-Gruppe ist, die dem Azure AD-Serverprinzipal (Anmeldung) zugeordnet ist – in sys.server_principals als Typ „X“ vorhanden –, wird der Zugriff gewährt, und die Berechtigungen der Azure AD-Gruppenanmeldung werden angewendet.
    3. Wenn das Azure AD-Konto direkt einem Azure AD-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 Azure AD-Datenbankbenutzers werden angewendet.
    4. Wenn das Azure AD-Konto Mitglied einer Azure AD-Gruppe ist, die einem Azure AD-Benutzer in einer Datenbank zugeordnet ist – in sys.database_principals als Typ „X“ vorhanden –, wird der Zugriff gewährt, und die Berechtigungen des Azure AD-Gruppenbenutzers werden angewendet.

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 und 150.
  • Kompatibilitätsgrade unter 100 werden nicht unterstützt.
  • Der standardmäßige Kompatibilitätsgrad für neue Datenbanken ist 140. 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 Filestreamdaten enthalten. Es kann keine Wiederherstellung durchgeführt werden, wenn die BAK-Datei FILESTREAM-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.

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

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 Azure AD-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 Azure AD-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

Derzeit werden verteilte Transaktionen teilweise in der öffentlichen Vorschau unterstützt. Verteilte Transaktionen werden unter den folgenden Bedingungen unterstützt (alle müssen erfüllt sein):

  • Alle Transaktionsteilnehmer sind Azure SQL Managed Instances beteiligt sind, die zur Serververtrauensgruppe gehören.
  • Transaktionen werden entweder von .NET (TransactionScope-Klasse) oder Transact-SQL initiiert.

Azure SQL Managed Instance unterstützt derzeit keine anderen Szenarios, die regelmäßig vom MS DTC lokal oder in Azure Virtual Machines unterstützt werden.

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 Dateitabelle

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

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.
  • Verteilte beschreibbare Transaktionen sind nur in verwalteten SQL-Instanzen möglich. Weitere Informationen finden Sie unter Verteilte Transaktionen. MS DTC wird jedoch nicht unterstützt.
  • 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:

  • Instanzenübergreifende Schreibtransaktionen werden nur für verwaltete SQL-Instanzen unterstützt.
  • 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. Als Anbieter werden nur die Werte SQLNCLI, SQLNCLI11 und SQLOLEDB unterstützt. z. B. SELECT * FROM OPENDATASOURCE('SQLNCLI', '...').AdventureWorks2012.HumanResources.Employee. Siehe OPENDATASOURCE.
  • 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 Azure AD-Authentifizierung.

PolyBase

An der Aktivierung der PolyBase-Unterstützung in SQL Managed Instance wird derzeit gearbeitet. Als Problemumgehung können Sie in der Zwischenzeit Verbindungsserver für einen serverlosen SQL-Pool in Synapse Analytics oder SQL Server verwenden, um Daten aus Dateien abzufragen, die in Azure Data Lake oder Azure Storage gespeichert sind.
Allgemeine Informationen zu PolyBase finden Sie unter PolyBase.

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 die Public Preview von 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 ONLY
    • RESTORE HEADER ONLY
    • RESTORE LABELONLY ONLY
    • RESTORE VERIFYONLY ONLY
  • Nicht unterstützte Syntax:
    • RESTORE LOG ONLY
    • RESTORE REWINDONLY ONLY
  • 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.
  • ASYNC RESTORE: Die Wiederherstellung wird auch bei einer Unterbrechung der Clientverbindung fortgesetzt. Wenn die Verbindung ausfällt, können Sie sich in der Ansicht sys.dm_operation_status über den Status eines Wiederherstellungsvorgangs sowie über CREATE- und DROP-Vorgänge für die Datenbank informieren. Siehe sys.dm_operation_status.

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 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. Gibt NULL zurück, wenn die Azure AD-Anmeldung in sys.syslogins nicht vorhanden ist. 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.

VNET

  • VNet kann mithilfe des Ressourcenmodells bereitgestellt werden – das klassische Modell wird für VNets nicht unterstützt.
  • 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 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 auf die sekundäre Instanz in einer Failovergruppe repliziert. Daher sind Szenarien, die von Objekten aus den Systemdatenbanken abhängen, auf der sekundären Instanz nicht möglich, es sei denn, die Objekte werden manuell auf 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 Masterdatei 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 Modelldatenbank erstellte Objekte können in tempdb nach einem Neustart oder Failover nicht automatisch erstellt werden, weil tempdb die anfängliche Objektliste nicht aus der Modelldatenbank 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.

Nächste Schritte