Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Gilt für:
Azure SQL Managed Instance
In diesem Artikel sind die derzeit bekannten Probleme mit Azure SQL Managed Instance sowie das Datum ihrer Behebung oder eine mögliche Problemumgehung aufgeführt. Informationen zu Azure SQL Managed Instance finden Sie unter Was ist Azure SQL Managed Instance? und Was ist neu in Azure SQL Managed Instance?
Hinweis
Microsoft Entra ID war zuvor als Azure Active Directory (Azure AD) bekannt.
Bekannte Probleme
Problemumgehung bekannt
Wiederherstellen von Vorgangsfehlern nach der Migration zu SQL Managed Instance
Wenn Sie eine Datenbank aus SQL Server 2019 und höheren Versionen mit aktivierter beschleunigter Datenbankwiederherstellung zu Azure SQL Managed Instance migrieren, die jedoch mit dem Persistent Version Store (PVS) auf etwas anderes als die PRIMARY Dateigruppe konfiguriert ist, können in der SQL Managed Instanz bei Wiederherstellungsvorgängen Fehler auftreten.
Um dieses Problem zu umgehen, stellen Sie sicher, dass Sie den persistenten Versionsspeicher (PVS) auf PRIMARY in der SQL Server-Quelldatenbank festlegen, bevor Sie es zu SQL Managed Instance migrieren. Wenn Sie die Datenbank bereits migriert haben, ohne die PVS auf PRIMARYfestzulegen, können Sie sie in der SQL Server-Quelldatenbank festlegen und dann die Datenbank erneut zu SQL Managed Instance migrieren.
Die beschleunigte Datenbankwiederherstellung kann nach der Migration zu SQL Managed Instance nicht verwendet werden.
Beginnend mit SQL Server 2019, können Sie, wenn Sie eine Datenbank zu einer Azure SQL Managed Instance migrieren und die Quelldatenbank die beschleunigte Datenbankwiederherstellung deaktiviert hat, keine beschleunigte Datenbankwiederherstellung auf der Zielinstanz von SQL Managed Instance verwenden.
Um dieses Problem zu umgehen, stellen Sie sicher, dass Sie die beschleunigte Datenbankwiederherstellung in der SQL Server-Quelldatenbank aktivieren, bevor Sie es zu SQL Managed Instance migrieren. Wenn Sie die Datenbank bereits migriert haben, ohne eine beschleunigte Datenbankwiederherstellung zu aktivieren, können Sie sie in der SQL Server-Quelldatenbank aktivieren und dann die Datenbank erneut zu sql managed instance migrieren.
SQL Server 2017 und frühere Versionen unterstützen keine beschleunigte Datenbankwiederherstellung, daher gilt dieses Problem nicht für Datenbanken, die aus diesen Versionen von SQL Server migriert wurden.
Der Dienstbroker kann nach der Migration zur verwalteten SQL-Instanz nicht verwendet werden.
Wenn Sie eine Datenbank zu azure SQL Managed Instance migrieren und der Dienstbroker in der Quelldatenbank deaktiviert ist, können Sie den Dienstbroker nicht für die verwaltete SQL-Zielinstanz verwenden.
Um dieses Problem zu umgehen, stellen Sie sicher, dass Sie service broker in der SQL Server-Quelldatenbank aktivieren, bevor Sie es zu SQL Managed Instance migrieren. Wenn Sie die Datenbank bereits migriert haben, ohne Service Broker zu aktivieren, können Sie sie in der SQL Server-Quelldatenbank aktivieren und dann die Datenbank erneut zu SQL Managed Instance migrieren.
Ändern des Aufbewahrungszeitraums für die Sicherung im Rahmen des kostenlosen Angebots
Sie können die Sicherungsaufbewahrungsrichtlinie Ihrer Datenbanken nur in der kostenlosen verwalteten SQL-Instanz mithilfe von REST-API-, PowerShell- und Azure CLI-Befehlen ändern. Sie können die Sicherungsaufbewahrungsrichtlinie nicht über das Azure-Portal ändern.
Fehler bei der Anmeldung bei lesbarem sekundärem Replikat aufgrund einer zu langen Wartezeit auf „HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING“
Möglicherweise wird dieser Fehler als Ausnahme für den Microsoft OLE DB-Treiber 19 für SQL Server angezeigt, wenn Sie versuchen, eine Verbindung mit einem schreibgeschützten sekundären Replikat einer Failovergruppe herzustellen, oder eine Datenbank, die über den Link "Verwaltete Instanz" repliziert wurde.
Dieser Fehler tritt auf, wenn das sekundäre Replikat für Anmeldungen nicht verfügbar ist, da Zeilenversionen für Transaktionen fehlen, die in-Flight waren, wenn ein sekundäres Replikat neu gestartet oder wiederverwendet wurde, unabhängig davon, ob es sich um Wartung oder aufgrund eines Failovers handelt. Wenn eine Instanz neu gestartet wird oder ein Failover erfolgt, werden die im tempdb gespeicherten Versionsverwaltungsdaten gelöscht. Sekundäre Leseabfragen werden abgebrochen, wenn lange ausgeführte aktive Transaktionen vorhanden sind, die vor dem Failover oder Neustart gestartet wurden.
Um dieses Problem zu beheben, führen Sie ein Rollback oder einen Commit für aktive Transaktionen auf dem primären Replikat durch. Um diesen Fehler zu vermeiden, minimieren Sie lang andauernde Schreibtransaktionen auf der primären Replikationseinheit.
Fehler 8992 beim Ausführen von DBCC CHECKDB auf einer SQL Server-Datenbank, die von SQL Managed Instance stammt
Möglicherweise wird der folgende Fehler angezeigt, wenn Sie den DBCC CHECKDB Befehl auf einer SQL Server 2022-Datenbank ausführen, nachdem Sie einen Index oder eine Tabelle mit einem Index gelöscht haben, und die Datenbank, die von Azure SQL Managed Instance stammt, z.B. nach dem Wiederherstellen einer Sicherungsdatei, oder aus der Link-Funktion der verwalteten SQL-Instanz:
Msg 8992, Level 16, State 1, Line <Line_Number>
Check Catalog Msg 3853, State 1: Attribute (%ls) of row (%ls) in sys.sysrowsetrefs does not have a matching row (%ls) in sys.indexes.
Um das Problem zu umgehen, legen Sie zuerst den Index oder die Tabelle mit dem Index aus der Quelldatenbank in Azure SQL Managed Instance ab, und stellen Sie dann die Datenbank erneut mit SQL Server 2022 wieder her. Wenn das Erneute Erstellen der Datenbank aus der azure SQL Managed Instance nicht möglich ist, wenden Sie sich an den Microsoft-Support, um dieses Problem zu beheben.
Vorsicht
Wenn Sie nach dem Ablegen eines Indexes einen partitionierten Index für eine Tabelle erstellen, wie in diesem Szenario beschrieben, kann auf die Tabelle nicht zugegriffen werden.
Die Liste der langfristigen Backups im Azure-Portal zeigt Sicherungsdateien für aktive und gelöschte Datenbanken mit demselben Namen an
Langfristige Sicherungen können auf der Azure-Portalseite für eine verwaltete Azure SQL-Instanz auf der Registerkarte "Sicherungen " aufgelistet und verwaltet werden. Auf der Seite werden aktive oder gelöschte Datenbanken, grundlegende Informationen zu ihren langfristigen Sicherungen und Verknüpfungen zum Verwalten von Sicherungen aufgelistet. Wenn Sie Link verwalten auswählen, wird ein neuer Seitenbereich mit einer Liste von Sicherungen geöffnet. Aufgrund eines Problems mit der Filterlogik werden in dieser Liste Backups für aktive und gelöschte Datenbanken mit demselben Namen angezeigt. Es ist deshalb besondere Aufmerksamkeit bei der Auswahl von Backups für die Löschung erforderlich, damit nicht versehentlich Backups der falschen Datenbank gelöscht werden.
Problemumgehung: Nutzen Sie die Information unter Backup Time (UTC), um Backups von Datenbanken mit demselben Namen unterscheiden zu können, die zu unterschiedlichen Zeiten in der Instanz existierten. Alternativ können Sie PowerShell-Befehle "Get-AzSqlInstanceDatabaseLongTermRetentionBackup " und "Remove-AzSqlInstanceDatabaseLongTermRetentionBackup" oder CLI-Befehle az sql midb ltr-backup list und az sql midb ltr-backup delete verwenden, um langfristige Sicherungen mithilfe des DatabaseState-Parameters und des DatabaseDeletionTime-Rückgabewerts zu verwalten, um Sicherungen für eine Datenbank zu filtern.
Fehler bei der Prozedur sp_send_dbmail, wenn der @query-Parameter verwendet wird
Die sp_send_dbmail gespeicherte Prozedur schlägt möglicherweise fehl, wenn der @query Parameter verwendet wird. Fehler treten auf, wenn die gespeicherte Prozedur unter einem Sysadmin-Konto ausgeführt wird.
Dieses Problem wird durch einen bekannten Fehler im Zusammenhang mit der sp_send_dbmail Verwendung des Identitätswechsels verursacht.
Problemumgehung: Stellen Sie sicher, dass Sie sp_send_dbmail unter einem von Ihnen erstellten, geeigneten benutzerdefinierten Konto und nicht unter einem Systemadministrator-Konto aufrufen.
Hier ist ein Beispiel dafür, wie Sie ein dediziertes Konto erstellen und vorhandene Objekte ändern können, die E-Mails senden.sp_send_dbmail
USE [msdb];
GO
-- Step 1: Create a user mapped to a login to specify as a runtime user.
CREATE USER [user_name] FOR LOGIN [login_name];
GO
EXECUTE msdb.dbo.sp_update_jobstep
@job_name = N'db_mail_sending_job',
@step_id = db_mail_sending_job_id,
@database_user_name = N'user_name';
GO
-- Step 2: Grant DB Mail permissions to the user who created it.
ALTER ROLE [DatabaseMailUserRole] ADD MEMBER [user_name];
GO
-- Step 3: If the database of the job step is not msdb, the permission error cannot be avoided even if it is a member of the role, so set it to msdb.
EXECUTE msdb.dbo.sp_update_jobstep
@job_name = N'db_mail_sending_job',
@step_id = db_mail_sending_job_id,
@database_name = N'msdb';
GO
-- Step 4: Set a principal in the email profile
EXECUTE msdb.dbo.sysmail_add_principalprofile_sp
@principal_name = N'user_name',
@profile_name = N'profile_name',
@is_default = 0;
GO
Verteilte Transaktionen können nach dem Entfernen der verwalteten SQL-Instanz aus der Server trust Group ausgeführt werden.
Serververtrauensgruppen werden verwendet, um eine Vertrauensstellung zwischen verwalteten Instanzen einzurichten. Diese Vertrauensstellung ist eine Voraussetzung für verteilte Transaktionen. Nach dem Entfernen der sql-verwalteten Instanz aus der Server trust Group oder dem Löschen der Gruppe können Sie möglicherweise weiterhin verteilte Transaktionen ausführen. Um sicherzustellen, dass verteilte Transaktionen deaktiviert sind, führen Sie ein vom Benutzer initiiertes manuelles Failover in der verwalteten SQL-Instanz aus.
SQL Managed Instance mit demselben Namen wie der zuvor gelöschte logische Server kann nicht erstellt werden
Wenn Sie einen logischen Server in Azure für Azure SQL-Datenbank oder einer verwalteten SQL-Instanz erstellen, erstellt das System einen DNS-Eintrag für <name>.database.windows.com. Dieser DNS-Eintrag muss eindeutig sein. Wenn Sie einen logischen Server für SQL-Datenbank erstellen und ihn dann löschen, bleibt der Name sieben Tage lang reserviert. In diesem Zeitraum können Sie keine SQL Managed Instance mit demselben Namen wie der gelöschte logische Server erstellen. Um das Problem zu umgehen, können Sie einen anderen Namen für SQL Managed Instance verwenden oder ein Supportticket zum Freigeben des Namens des logischen Servers erstellen.
Service Principal kann nicht auf Microsoft Entra ID und Azure Key Vault zugreifen.
Unter bestimmten Umständen besteht ein Problem mit dem Dienstprinzipal, der für den Zugriff auf Microsoft Entra ID (früher Azure Active Directory) und Azure Key Vault (AKV)-Dienste verwendet wird. Dieses Problem beeinträchtigt die Verwendung von Microsoft Entra-Authentifizierung und Transparent Database Encryption (TDE) mit SQL Managed Instance. Möglicherweise tritt dieses Problem als zeitweiliges Verbindungsproblem auf oder verhindert das Ausführen von Anweisungen wie CREATE LOGIN/USER FROM EXTERNAL PROVIDER oder EXECUTE AS LOGIN/USER. In manchen Fällen ist es eventuell nicht möglich, TDE mit einem kundenseitig verwalteten Schlüssel in einer neuen Azure SQL Managed Instance einzurichten.
Problemumgehung: Um zu verhindern, dass dieses Problem in Ihrer verwalteten SQL-Instanz auftritt, bevor Aktualisierungsbefehle ausgeführt werden, oder falls Sie dieses Problem bereits nach Aktualisierungsbefehlen aufgetreten sind, wechseln Sie zur Seite "Übersicht" Ihrer verwalteten SQL-Instanz im Azure-Portal. Wählen Sie unter Einstellungen die Microsoft Entra ID aus, um auf die SQL Managed Instance Microsoft Entra ID-Administratorseite zuzugreifen. Suchen Sie nach der folgenden Fehlermeldung:
Managed Instance needs a Service Principal to access Microsoft Entra ID. Click here to create a Service Principal.
Wenn diese Fehlermeldung auftritt, wählen Sie sie aus, und befolgen Sie die schrittweisen Anweisungen, die bereitgestellt werden, bis dieser Fehler behoben ist.
Beim Versuch, eine nicht leere Datei zu löschen, wird eine falsche Fehlermeldung zurückgegeben
SQL Server und SQL Managed Instance lassen nicht das Löschen von Dateien zu, die nicht leer sind. Wenn Sie versuchen, eine nicht leere Datendatei mithilfe einer ALTER DATABASE REMOVE FILE-Anweisung zu entfernen, tritt der Fehler auf:
Msg 5042 - The file '<file_name>' cannot be removed because it is not empty` isn't immediately returned. SQL Managed Instance keeps trying to drop the file, and the operation fails after 30 minutes with `Internal server error.
Die Änderung der Dienstebene und die Erstellung von Instanzen werden durch eine laufende Datenbankwiederherstellung blockiert.
Eine fortlaufende RESTORE Anweisung, ein Migrationsdienst-Migrationsprozess und eine integrierte Point-in-Time-Wiederherstellung können Aktualisierungen einer Dienstebene blockieren, die Größe der vorhandenen Instanz ändern oder neue Instanzen erstellen, bis der Wiederherstellungsvorgang abgeschlossen ist.
Der Wiederherstellungsvorgang blockiert diese Vorgänge für die verwalteten Instanzen und Instanzenpools in dem Subnetz, in dem der Wiederherstellungsvorgang ausgeführt wird. Die Instanzen innerhalb der Instanzenpools werden nicht davon beeinflusst. Beim Erstellen oder Ändern von Vorgängen auf Dienstebene kommt es zu keinem Fehler oder Timeout. Die Vorgänge gehen weiter, sobald der Wiederherstellungsvorgang abgeschlossen oder abgebrochen wurde.
Problemumgehung: Warten Sie, bis der Wiederherstellungsvorgang abgeschlossen ist, oder brechen Sie ihn ab, wenn die Erstellung oder Aktualisierung der Dienstebene eine höhere Priorität hat.
Der Ressourcen-Governor auf einem lesbaren sekundären Replikat muss nach einem Failover neu konfiguriert werden.
Das Feature "Ressourcenkontrolle ", mit dem Sie die Ressourcen einschränken können, die der Benutzerarbeitsauslastung zugewiesen sind, klassifizieren einige Benutzerworkloads möglicherweise fälschlicherweise nach einem Failover oder einer vom Benutzer initiierten Änderung der Dienstebene (z. B. die Änderung der maximalen vCore- oder max-Instanz-Speichergröße).
Problemumgehung: Führen Sie ALTER RESOURCE GOVERNOR RECONFIGURE regelmäßig oder als Teil eines SQL-Agent-Auftrags aus, der die SQL-Aufgabe ausführt, wenn das lesbare sekundäre Replikat gestartet wird, wenn Sie die Ressourcenkontrolle verwenden.
Überschreiten des Speicherplatzes mit kleinen Datenbankdateien
CREATE DATABASE, ALTER DATABASE ADD FILE und RESTORE DATABASE Anweisungen können fehlschlagen, da die Instanz den Azure Storage-Grenzwert auf der General Purpose-Dienstebene erreicht, aber nicht das Next-gen General Purpose-Dienstebene-Upgrade oder die Business Critical-Dienstebene.
Jede Instanz von SQL Managed Instance auf der Ebene des allgemeinen Verwendungszwecks hat bis zu 35 TB Speicherplatz für Azure Premium-Datenträger reserviert. Jede Datenbankdatei wird auf einem separaten physischen Datenträger platziert. Mögliche Datenträgergrößen sind 128 GB, 256 GB, 512 GB, 1 TB oder 4 TB. Sie werden nicht für nicht genutzten Speicherplatz auf dem Datenträger belastet, aber die Gesamtsumme der Azure Premium Disk-Größen darf 35 TB nicht überschreiten. In einigen Fällen kann eine sql-verwaltete Instanz, die insgesamt 8 TB nicht benötigt, den Azure-Grenzwert von 35 TB aufgrund der internen Fragmentierung überschreiten.
Beispiel: In einer Instanz von SQL Managed Instance auf der Dienstebene „Universell“ gibt es eine große Datei (1,2 TB), die sich auf einem 4-TB-Datenträger befindet. Darüber hinaus befinden sich 248 Dateien mit jeweils 1 GB auf separaten 128-GB-Datenträgern. In diesem Beispiel:
- Die Gesamtgröße des zugewiesenen Datenträgerspeichers beträgt 1 x 4 TB + 248 x 128 GB = 35 TB.
- Der reservierte Gesamtspeicherplatz für Datenbanken in der Instanz beträgt 1 x 1,2 TB + 248 x 1 GB = 1,4 TB.
In diesem Beispiel wird veranschaulicht, dass unter bestimmten Umständen aufgrund einer bestimmten Verteilung von Dateien eine Instanz der verwalteten SQL-Instanz möglicherweise den Grenzwert von 35 TB erreicht, der für einen angefügten Azure Premium-Datenträger reserviert ist, wenn Sie es möglicherweise nicht erwarten.
In diesem Beispiel funktionieren vorhandene Datenbanken weiterhin und können ohne Probleme weiter wachsen, solange keine neuen Dateien hinzugefügt werden. Sie können keine neuen Datenbanken erstellen oder wiederherstellen, da nicht genügend Speicherplatz für neue Datenträgerlaufwerke vorhanden ist, auch wenn die Gesamtgröße aller Datenbanken nicht die Größenbeschränkung der Instanz erreicht. Der zurückgegebene Fehler ist nicht eindeutig.
Sie können mithilfe von Systemansichten die Anzahl von verbleibenden Dateien identifizieren. Wenn Sie dieses Limit erreichen, versuchen Sie, einige der kleineren Dateien mithilfe der DBCC SHRINKFILE-Anweisung zu leeren und zu löschen, oder wechseln Sie zur Dienstebene „Unternehmenskritisch“, für die dieses Limit nicht gilt.
Anstelle von Datenbanknamen werden GUID-Werte gezeigt
Mehrere Systemansichten, Leistungsindikatoren, Fehlermeldungen, XEvents und Fehlerprotokolleinträge zeigen GUID-Datenbankbezeichner anstelle der eigentlichen Datenbanknamen an. Verlassen Sie sich nicht auf diese GUIDs, da sie in Zukunft ggf. durch tatsächliche Datenbanknamen ersetzt werden.
Problemumgehung: Verwenden Sie die Ansicht sys.databases, um den tatsächlichen Datenbanknamen aus dem physischen Datenbanknamen abzuleiten, der in Form von GUID-Datenbankbezeichnern angegeben ist.
SELECT name AS ActualDatabaseName,
physical_database_name AS GUIDDatabaseIdentifier
FROM sys.databases
WHERE database_id > 4;
CLR-Module und Verbindungsserver können manchmal nicht auf eine lokale IP-Adresse verweisen
CLR-Module in SQL Managed Instance und Verbindungsserver oder verteilte Abfragen, die auf eine aktuelle Instanz verweisen, können die IP-Adresse der lokalen Instanz mitunter nicht auflösen. Dieser Fehler ist ein vorübergehendes Problem.
Keine Lösung vorhanden
Irreführende Fehlermeldung beim Versuch, eine Verbindung zu einem Lesereplikat mit ungültigen Anmeldeinformationen herzustellen.
Wenn Sie versuchen, mithilfe von ApplicationIntent=ReadOnly und ungültigen Anmeldeinformationen eine Verbindung mit dem read-secondary-Replikat einer Business Critical-Instanz herzustellen, meldet die Instanz einen Fehler, der angibt, dass die master Datenbank schreibgeschützt ist. Die Instanz meldet nicht ordnungsgemäß, dass die Anmeldeinformationen ungültig sind.
Differenzielle Sicherungen werden nicht ausgeführt, wenn eine Instance mit SQL Server verknüpft ist
Wenn Sie eine Verbindung zwischen SQL Server und Azure SQL Managed Instance konfigurieren, werden automatisierte vollständige Sicherungen und Transaktionsprotokollsicherungen auf der SQL-verwalteten Instanz durchgeführt, unabhängig davon, ob sie sich in der primären Rolle befindet. Allerdings werden derzeit keine differenziellen Sicherungen durchgeführt, was zu längeren Wiederherstellungszeiten als erwartet führen kann.
Erhöhte Anzahl an Systemanmeldungen für die Transaktionsreplikation
Der Azure SQL Managed Instance-Dienst erstellt einen System-Login für die Zwecke der Transaktionsreplikation. Sie finden diese Anmeldung in SSMS (in Object Explorer>Security>Logins) oder in der sys.syslogins Systemansicht. Das Anmeldenamenformat hat das Format DBxCy\WF-abcde01234QWERT, und die Anmeldung hat die öffentliche Serverrolle. Unter bestimmten Bedingungen wird diese Anmeldung neu erstellt, und aufgrund eines internen Problems wird die vorherige Anmeldung nicht gelöscht. Dieser Fehler kann zu einer Erhöhung der Anzahl der Anmeldungen führen. Diese Anmeldungen stellen keine Sicherheitsrisiken dar, und Sie können sie sicher ignorieren. Löschen Sie diese Anmeldungen nicht, da mindestens eine davon für die Transaktionsreplikation verwendet wird.
Microsoft Entra-Anmeldungen und -Benutzer werden in SSDT nicht unterstützt
SQL Server Data Tools unterstützen Microsoft Entra-Anmeldungen und -Benutzer nicht vollständig.
Die Imitation von Microsoft Entra-Anmeldetypen wird nicht unterstützt.
Identitätsübernahme mithilfe von EXECUTE AS USER oder EXECUTE AS LOGIN wird für die folgenden Microsoft Entra-Entitäten nicht unterstützt:
- Microsoft Entra-Benutzer mit einem Alias. In diesem Fall gibt der Vorgang den Fehler zurück
15517. - Microsoft Entra-Anmeldungen und -Benutzer, die auf Microsoft Entra-Anwendungen oder -Dienstprinzipalen basieren. In diesem Fall gibt der Vorgang Fehler
15517und15406.
Transaktionsreplikation muss nach einem geografischen Failover neu konfiguriert werden
Wenn Sie die Transaktionsreplikation für eine Datenbank in einer Failovergruppe aktivieren, muss der Administrator der verwalteten SQL-Instanz alle Publikationen in der alten primären Instanz bereinigen und neu konfigurieren, nachdem ein Failover in eine andere Region erfolgt. Weitere Informationen finden Sie unter Replikation.
Fehlerprotokolle werden nicht dauerhaft gespeichert
Die Fehlerprotokolle in einer SQL Managed Instance werden nicht persistent gespeichert, und ihre Größe wird im Speicherlimit nicht berücksichtigt. Fehlerprotokolle werden im Falle eines Failovers möglicherweise automatisch gelöscht. Lücken können im Fehlerprotokollverlauf vorhanden sein, da die verwaltete SQL-Instanz mehrmals auf mehreren virtuellen Computern verschoben wurde.
Gelöst
Interimsleitfaden zu Zeitzonenupdates für Paraguay 2024
(Im Februar 2026 behoben)
Am 14. Oktober 2024 kündigte die paraguayische Regierung eine dauerhafte Änderung der Zeitzonenpolitik an. Paraguay bleibt nun ganzjährig auf Sommerzeit (DST), wobei effektiv UTC-3 als Standardzeit verwendet wird. Daher wurden die Uhren am 23. März 2025 um Mitternacht nicht um 60 Minuten umgestellt, wie zuvor geplant. Diese Änderung wirkt sich auf die Zeitzone Paraguay Standard aus. Microsoft hat verwandte Windows-Updates im Februar und März 2025 veröffentlicht. Sql-verwaltete Instanzen, die die betroffene Zeitzone verwenden, spiegeln diese Änderung wider und richten sich an den neuen UTC-3-Offset.
Das Ändern des Verbindungstyps wirkt sich nicht auf Verbindungen über den Failovergruppenendpunkt aus.
(Im November 2025 behoben)
Wenn eine Instance Teil einer Failover-Gruppe ist, hat das Ändern des Verbindungstyp der Instance keine Auswirkungen auf Verbindungen, die über den Listenerendpunkt der Failover-Gruppe hergestellt werden.
Auf die Instanz kann mithilfe des Failovergruppenlisteners während des Skalierungsvorgangs vorübergehend nicht zugegriffen werden
(Im April 2025 behoben)
Das Skalieren einer verwalteten SQL-Instanz erfordert manchmal, die Instanz in einen anderen virtuellen Cluster zu verschieben, zusammen mit den zugehörigen vom Dienst verwalteten DNS-Einträgen. Wenn die von SQL verwaltete Instanz an einer Failovergruppe teilnimmt, wird der DNS-Eintrag, der dem zugeordneten Failovergruppenlistener entspricht (Lese-/Schreibzugriffslistener, wenn es sich bei der Instanz um den aktuellen geo-primären schreibgeschützten Listener handelt, wenn es sich bei der Instanz um den aktuellen geo-sekundären Listener handelt) in den neuen virtuellen Cluster verschoben.
Im aktuellen Skalierungsvorgangsentwurf werden die Listener-DNS-Einträge aus dem ursprünglichen virtuellen Cluster entfernt, bevor sie die von SQL verwaltete Instanz vollständig zum neuen virtuellen Cluster migriert. In einigen Fällen führt dieses Design zu längerer Zeit, während der die IP-Adresse der Instanz nicht mithilfe des Listeners aufgelöst werden kann. Während dieser Zeit kann ein SQL-Client, der versucht, auf die Instanz zuzugreifen, die mithilfe des Listenerendpunkts skaliert wird, Anmeldefehler mit der folgenden Fehlermeldung erwarten:
Error 40532: Cannot open server "xxx.xxx.xxx.xxx" requested by the login. The login failed. (Microsoft SQL Server, Error: 40532).
Das Problem wird durch Neugestaltung des Skalierungsvorgangs behoben.
In der Tabelle für manuelle Sicherungen in msdb wird der Benutzername nicht beibehalten
(Im August 2023 behoben) Die kürzlich eingeführte Unterstützung für automatische Sicherungen enthält msdb derzeit keine Benutzernameninformationen.
Wenn Sie die SQL Server-Authentifizierung verwenden, werden Benutzernamen mit '@' nicht unterstützt.
Benutzernamen, die das @ Symbol in der Mitte enthalten (z abc@xy. B. ) können sich nicht mit SQL Server-Authentifizierung anmelden.
Das Wiederherstellen der manuellen Sicherung ohne CHECKSUM schlägt möglicherweise fehl.
(Im Juni 2020 behoben) Unter bestimmten Umständen kann das Wiederherstellen einer manuellen Sicherung von Datenbanken, die Sie auf einer SQL-verwalteten Instanz durchgeführt haben, ohne CHECKSUM fehlschlagen. Versuchen Sie in solchen Fällen erneut, die Sicherung wiederherzustellen, bis der Vorgang erfolgreich war.
Problemumgehung: Manuelle Sicherungen von Datenbanken in SQL verwalteten Instanzen mit CHECKSUM aktivierter Option ausführen.
Berechtigungen für Ressourcengruppe werden nicht auf SQL Managed Instance angewendet
Wenn Sie die Azure-Rolle "SQL Managed Instance Contributor" auf eine Ressourcengruppe (RG) anwenden, gilt sie nicht für die Azure SQL verwaltete Instanz und hat keine Auswirkung.
Umgehungslösung: Richten Sie auf Abonnementebene eine SQL Managed Instance Contributor-Rolle für Benutzer ein.
Irreführende Fehlermeldung im Azure-Portal, die das erneute Erstellen des Dienstprinzipals vorschlägt
Auf der Seite Active Directory-Administrator im Azure-Portal für Azure SQL Managed Instance wird möglicherweise die folgende Fehlermeldung angezeigt, obwohl der Serviceprinzipal bereits vorhanden ist:
Managed Instance needs a Service Principal to access Microsoft Entra ID. Click here to create a Service Principal.
Sie können diese Fehlermeldung vernachlässigen, wenn der Dienstprinzipal für die verwaltete SQL-Instanz bereits vorhanden ist und/oder die Microsoft Entra-Authentifizierung in der verwalteten SQL-Instanz funktioniert.
Um zu überprüfen, ob der Dienstprinzipal vorhanden ist, navigieren Sie zur Seite "Unternehmensanwendungen " im Azure-Portal, wählen Sie "Verwaltete Identitäten " aus der Dropdownliste " Anwendung" aus, wählen Sie "Übernehmen" aus, und geben Sie den Namen der sql-verwalteten Instanz in das Suchfeld ein. Wenn der Instanzname in der Ergebnisliste enthalten ist, ist der Service Principal bereits vorhanden und es sind keine weiteren Aktionen erforderlich.
Wenn Sie bereits die Anweisungen aus der Fehlermeldung befolgt und den Link ausgewählt haben, wird der Dienstprinzipal der verwalteten SQL-Instanz neu erstellt. Weisen Sie in diesem Fall dem neu erstellten Dienstprinzipal Microsoft Entra ID-Leseberechtigungen zu, damit die Microsoft Entra-Authentifizierung ordnungsgemäß funktioniert. Sie können diesen Schritt auch mit Azure PowerShell ausführen, indem Sie die Anweisungen befolgen.
Auf das event_file-Target der system_health-Ereignissitzung kann nicht zugegriffen werden.
(Teilweise behoben im Mai 2025) Wenn Sie versuchen, den Inhalt des event_file Ziels der system_health Ereignissitzung zu lesen, erhalten Sie den Fehler 40538: "Eine gültige URL, die mit https:// der Angabe beginnt, ist als Wert für jeden angegebenen Dateipfad erforderlich.".
Ursprünglich ist dieses Problem in SQL Server Management Studio (SSMS) oder beim Lesen der Sitzungsdaten mithilfe der sys.fn_xe_file_target_read_file-Funktion aufgetreten.
Im Mai 2025 wurde dieses Problem für das Lesen von Sitzungsdaten von SSMS behoben. Das Problem wird beim Lesen von Ereignisdaten mithilfe der sys.fn_xe_file_target_read_file Funktion nicht behoben.
Diese Verhaltensänderung ist eine unbeabsichtigte Folge einer erforderlichen Sicherheitskorrektur. Sie können dieses Problem umgehen, indem Sie ihre eigene Entsprechung der system_health Sitzung mit einem event_file Ziel in Azure Blob Storage erstellen. Weitere Informationen, einschließlich eines T-SQL-Skripts zum Erstellen der system_health Sitzung, die geändert werden kann, um ein eigenes Äquivalent system_healthzu erstellen, finden Sie unter Verwenden der system_health Sitzung.
Dialogfelder für den datenbankübergreifenden Dienstbroker müssen nach dem Upgrade der Dienstebene erneut initialisiert werden.
(Im Januar 2020 behoben) Datenbankübergreifende Dienstbrokerdialoge beenden die Übermittlung der Nachrichten an die Dienste in anderen Datenbanken nach änderung des Dienstebenenvorgangs. Die Nachrichten sind nicht verloren gegangen, sondern befinden sich in der Absenderwarteschlange. Jede Änderung der vCores- oder Instanzspeichergröße in der verwalteten SQL-Instanz bewirkt, dass ein service_broke_guid Wert in der Ansicht "sys.databases " für alle Datenbanken geändert wird. Jede DIALOG mit einer BEGIN DIALOG-Anweisung erstellte Anweisung, die auf Service Broker in anderen Datenbanken verweist, beendet die Zustellung von Nachrichten an den Zieldienst.
Problemumgehung: Beenden Sie vor dem Aktualisieren der Dienstebene alle Aktivitäten, die datenbankübergreifende Dialogkonversationen von Service Broker verwenden, und initialisieren Sie sie danach neu. Wenn nicht zugestellte Nachrichten nach einer Änderung der Dienstebene verbleiben, lesen Sie die Nachrichten aus der Quellwarteschlange und senden sie erneut an die Zielwarteschlange.
Mitwirkung am Inhalt
Informationen zur Mitwirkung an der Azure SQL-Dokumentation finden Sie im Leitfaden für Dokumentationsmitwirkende.
Zugehöriger Inhalt
Eine Liste der Updates und Verbesserungen für SQL Managed Instance finden Sie unter Dienstupdates für SQL Managed Instance.
Informationen zu Updates und Verbesserungen für alle Azure-Dienste finden Sie unter Dienstupdates.