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
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 bei einem Neustart eines sekundären Replikats vorhanden waren oder aufgrund eines Failovers wiederverwendet wurden. Wenn eine Instanz neu gestartet wird oder fehlschlägt, werden die in tempdb gespeicherten Versionsverwaltungsdaten gelöscht, sodass sekundäre Leseabfragen abgebrochen werden, 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 Commit für aktive Transaktionen im primären Replikat durch. Um diesen Fehler zu vermeiden, minimieren Sie lang andauernde Schreibtransaktionen auf der primären Replikationseinheit.
Interimsleitfaden zu Zeitzonenupdates für Paraguay 2024
Am 14. Oktober 2024 kündigte die paraguayische Regierung eine dauerhafte Änderung der Zeitzonenpolitik des Landes an. Paraguay befindet sich das ganze Jahr über in der Sommerzeit (DST) und übernimmt effektiv UTC-3 als Standardzeit. Daher werden die Uhren nicht um 60 Minuten um 12:00 Uhr am 23. März 2025, wie zuvor geplant, voranschreiten. Diese Änderung wirkt sich auf die Zeitzone der Paraguay-Standardzeit aus. Microsoft hat verwandte Windows-Updates im Februar und März 2025 veröffentlicht. Azure SQL Managed Instance spiegelt derzeit dieses Update nicht wider. Instanzen, die die betroffene Zeitzone verwenden, spiegeln die Änderungen erst wieder, wenn der Azure SQL Managed Instance-Dienst das Update auf Betriebssystemebene aufnimmt.
Problemumgehung: Wenn Sie die betroffenen Zeitzonen für Ihre verwalteten Instanzen ändern müssen, beachten Sie die Einschränkungen, und befolgen Sie die Anleitung in der Dokumentation.
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.
Die Prozedur sp_send_dbmail kann fehlschlagen, wenn der Parameter @query
Die Prozedur sp_send_dbmail kann fehlschlagen, wenn der Parameter @query verwendet wird. Fehler treten auf, wenn die gespeicherte Prozedur unter dem Sysadmin-Konto ausgeführt wird.
Dieses Problem wird durch eine bekanntes Problem mit sp_send_dbmail bei der Verwendung von Identitätswechseln verursacht.
Problemumgehung: Stellen Sie sicher, dass Sie unter dem entsprechenden benutzerdefinierten Konto, das Sie erstellt haben, und nicht unter dem Sysadmin-Konto aufrufen sp_send_dbmail.
Hier ist ein Beispiel dafür, wie Sie ein dediziertes Konto erstellen und vorhandene Objekte, die E-Mails über sp_send_dbmail senden, ändern können.
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
Vorläufiger Leitfaden zur Aktualisierung der Zeitzonen für Chile im Jahr 2022
Am 8. August 2022 gab die chilenische Regierung eine offizielle Ankündigung über die Umstellung der Zeitzone auf Sommerzeit (DST). Beginnend um 12:00 Uhr Samstag, 10. September 2022, bis 12:00 Uhr Samstag, 1. April 2023, die offizielle Zeit erweiterte 60 Minuten. Die Änderung betrifft die folgenden drei Zeitzonen: Pazifische SA Normalzeit, Osterinsel-Normalzeit und Magallanes-Normalzeit. Azure SQL Managed Instances, die die betroffenen Zeitzonen verwenden, spiegeln die Änderungen erst dann wider, wenn Microsoft ein entsprechendes Betriebssystemupdate veröffentlicht und der Azure SQL Managed Instance-Dienst das Update auf Betriebssystemebene einfließen lässt.
Problemumgehung: Wenn Sie die betroffenen Zeitzonen für Ihre verwalteten Instanzen ändern müssen, beachten Sie die Einschränkungen, und befolgen Sie die Anleitung in der Dokumentation.
Das Ändern des Verbindungstyps wirkt sich nicht auf Verbindungen durch den Endpunkt der Failovergruppe aus
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.
Problemumgehung: Löschen Sie die Failover-Gruppe, und erstellen Sie sie nach dem Ändern des Verbindungstyp neu.
Die Prozedur sp_send_dbmail kann vorübergehend fehlschlagen, wenn der Parameter @query verwendet wird
Die Prozedur sp_send_dbmail kann zu vorübergehenden Fehlern führen, wenn der Parameter @query verwendet wird. Wenn dieses Problem besteht, tritt bei jeder zweiten Ausführung der Prozedur sp_send_dbmail der Fehler Msg 22050, Level 16, State 1 mit der Meldung Failed to initialize sqlcmd library with error number -2147467259 auf. Damit dieser Fehler ordnungsgemäß angezeigt werden kann, muss die Prozedur mit dem Standardwert 0 für den Parameter @exclude_query_output aufgerufen werden. Andernfalls wird der Fehler nicht weitergegeben.
Dieses Problem wird durch eine bekanntes Problem mit sp_send_dbmail bei der Verwendung von Identitätswechseln und Verbindungspooling verursacht.
Um dieses Problem zu umgehen, umschließen Sie den Code für das Senden von E-Mails in einer Wiederholungslogik, die auf dem Ausgabeparameter @mailitem_id basiert. Wenn die Ausführung fehlschlägt, dann ist der Parameterwert NULL, was angibt, dass sp_send_dbmail ein weiteres Mal aufgerufen werden sollte, um eine E-Mail erfolgreich zu senden. Im Folgenden finden Sie ein Beispiel für diese Wiederholungslogik:
CREATE PROCEDURE send_dbmail_with_retry AS
BEGIN
DECLARE @miid INT
EXEC msdb.dbo.sp_send_dbmail
@recipients = 'name@mail.com', @subject = 'Subject', @query = 'select * from dbo.test_table',
@profile_name ='AzureManagedInstance_dbmail_profile', @execute_query_database = 'testdb',
@mailitem_id = @miid OUTPUT
-- If sp_send_dbmail returned NULL @mailidem_id then retry sending email.
--
IF (@miid is NULL)
EXEC msdb.dbo.sp_send_dbmail
@recipients = 'name@mail.com', @subject = 'Subject', @query = 'select * from dbo.test_table',
@profile_name ='AzureManagedInstance_dbmail_profile', @execute_query_database = 'testdb',
END
Verteilte Transaktionen können nach dem Entfernen der verwalteten Instanz aus der Serververtrauensgruppe ausgeführt werden
Serververtrauensgruppen werden verwendet, um eine Vertrauensstellung zwischen verwalteten Instanzen einzurichten. Diese Vertrauensstellung ist eine Voraussetzung für verteilte Transaktionen. Nachdem Sie die verwaltete Instanz aus der Serververtrauensgruppe entfernt oder die Gruppe gelöscht haben, können Sie möglicherweise weiterhin verteilte Transaktionen ausführen. Es gibt eine Problemumgehung, mit der Sie sicherstellen können, dass verteilte Transaktionen deaktiviert sind, und zwar ein vom Benutzer eingeleitetes manuelles Failover auf der verwalteten Instanz.
Verteilte Transaktionen können nach dem Skalierungsvorgang einer verwalteten Instanz nicht ausgeführt werden
Skalierungsvorgänge für verwaltete SQL-Instanzen, die das Ändern der Dienstebene oder die Anzahl der vCores umfassen, setzen die Einstellungen der Server trust Group im Back-End zurück und deaktivieren die Ausführung verteilter Transaktionen. Löschen Sie als Problemumgehung die bestehende Server Trust Group im Azure-Portal und erstellen Sie eine neue.
SQL Managed Instance mit demselben Namen wie der zuvor gelöschte logische Server kann nicht erstellt werden
Beim Erstellen eines <name>.database.windows.com für die Azure SQL-Datenbank und beim Erstellen einer SQL Managed Instance wird ein DNS-Eintrag von erstellt. Der DNS-Eintrag muss eindeutig sein. Wenn Sie daher einen logischen Server für die SQL-Datenbank erstellen und diesen anschließend löschen, gibt es eine Schwellenperiode von 7 Tagen, ehe der Name in den Datensätzen freigegeben wird. In diesem Zeitraum kann SQL Managed Instance nicht mit dem gleichen Namen wie der gelöschte logische Server erstellt werden. 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 könnte ein Problem mit dem Dienstprinzipal bestehen, 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. Dabei kann es sich um ein vorübergehendes Konnektivitätsproblem handeln, oder Anweisungen, z. B. CREATE LOGIN/USER FROM EXTERNAL PROVIDER oder EXECUTE AS LOGIN/USER, können nicht ausgeführt werden. 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 auf Ihrer SQL Managed Instance auftritt, sollten Sie vor der Ausführung von Aktualisierungsbefehlen oder falls dieses Problem bereits nach Aktualisierungsbefehlen aufgetreten ist, die Seite Übersicht Ihrer SQL Managed Instance im Azure-Portal aufrufen. Wählen Sie unter Einstellungen die Microsoft Entra ID aus, um auf die SQL Managed Instance Microsoft Entra ID-Administratorseite zuzugreifen. Überprüfen Sie, ob Sie die Fehlermeldung „Die verwaltete Instanz benötigt einen Dienstprinzipal, um auf Microsoft Entra ID zuzugreifen.” sehen können. Klicken Sie hier, um einen Service Principal zu erstellen". Falls diese Fehlermeldung auftritt, wählen Sie sie aus, und befolgen Sie die Schrittanleitung bis zur Behebung des Fehlers.
SQL-Agent-Rollen benötigen explizite EXECUTE-Berechtigungen für Anmeldungen, die keine Systemadministratoranmeldungen sind
Wenn Anmeldungen für Nicht-Systemadministrator*innen einer der festen SQL-Agent-Datenbankrollen hinzugefügt werden, besteht ein Problem, bei dem drei gespeicherten Prozeduren in der master-Datenbank explizite EXECUTE-Berechtigungen gewährt werden müssen, damit diese Anmeldungen funktionieren. Wenn dieses Problem auftritt, wird die Fehlermeldung The EXECUTE permission was denied on the object <object_name> (Microsoft SQL Server, Error: 229) angezeigt.
Problemumgehung: Nachdem Sie einer festen SQL-Agent-Datenbankrolle (SQLAgentUserRole, SQLAgentReaderRole oder SQLAgentOperatorRole) Anmeldungen hinzugefügt haben, führen Sie für jeden hinzugefügten Anmeldenamen das folgende T-SQL-Skript aus, um den aufgelisteten gespeicherten Prozeduren explizit EXECUTE-Berechtigungen zu erteilen.
USE [master];
GO
CREATE USER [login_name] FOR LOGIN [login_name];
GO
GRANT EXECUTE ON master.dbo.xp_sqlagent_enum_jobs TO [login_name];
GRANT EXECUTE ON master.dbo.xp_sqlagent_is_starting TO [login_name];
GRANT EXECUTE ON master.dbo.xp_sqlagent_notify TO [login_name];
Arbeitsspeicherlimits für In-Memory-OLTP werden nicht angewendet
In einigen Fällen werden auf der Dienstebene „Unternehmenskritisch“ maximale Arbeitsspeicherlimits für arbeitsspeicheroptimierte Objekte nicht ordnungsgemäß angewendet. Mit SQL Managed Instance kann die Workload eventuell mehr Arbeitsspeicher für In-Memory-OLTP-Vorgänge belegen. Dies kann sich auf die Verfügbarkeit und Stabilität der Instanz auswirken. In-Memory-OLTP-Abfragen, die die Grenzwerte erreichen, schlagen möglicherweise nicht sofort fehl. Abfragen, die mehr Arbeitsspeicher für In-Memory-OLTP beanspruchen, schlagen früher fehl, wenn sie die Limits erreichen.
Problemumgehung: Überwachen Sie die Arbeitsspeichernutzung für In-Memory-OLTP mithilfe von SQL Server Management Studio, um sicherzustellen, dass die Workload nicht mehr als den verfügbaren Arbeitsspeicher beansprucht. Erhöhen Sie die Arbeitsspeicherlimits, die von der Anzahl von virtuellen Kernen abhängen, oder optimieren Sie Ihre Workload, damit sie weniger Arbeitsspeicher belegt.
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 der Anweisung ALTER DATABASE REMOVE FILE zu entfernen, wird der Fehler Msg 5042 – The file '<file_name>' cannot be removed because it is not empty nicht sofort zurückgegeben. SQL Managed Instance versucht weiterhin, die Datei zu löschen, und der Vorgang schlägt nach 30 Minuten mit dem Fehler Internal server error fehl.
Die Änderung der Dienstebene und die Erstellung von Instanzen werden durch eine laufende Datenbankwiederherstellung blockiert.
Eine fortlaufende RESTORE Anweisung, ein Migrationsprozess mit dem Datenmigrationsdienst und eine integrierte Point-in-Time-Wiederherstellung blockieren die Aktualisierung einer Dienstebene oder die Größenänderung der vorhandenen Instanz und das Erstellen neuer Instanzen, 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.
Resource Governor auf Dienstebene „Unternehmenskritisch“ muss möglicherweise nach einem Failover neu konfiguriert werden
Das Feature Ressourcensteuerung, mit dem Sie die Ressourcen einschränken können, die der Benutzerarbeitslast zugewiesen sind, kann nach einem Failover oder einer vom Benutzer initiierten Änderung der Dienstebene (zum Beispiel der Änderung der maximalen vCore- oder maximalen Instanzspeichergröße) einige Benutzerarbeitslast möglicherweise falsch klassifizieren.
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 die Instanz gestartet wird, wenn Sie die Ressourcenkontrolle verwenden.
Datenbankübergreifende Service Broker-Dialoge müssen nach einem Upgrade der Dienstebene erneut initialisiert werden
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. Jegliche Änderung virtueller Kerne oder der Instanzspeichergröße von SQL Managed Instance führt dazu, dass der Wert service_broke_guid in der Sicht sys.databases für alle Datenbanken geändert wird. Ein DIALOG, der mit der Anweisung BEGIN DIALOG erstellt wurde und auf Service Broker-Instanzen in einer anderen Datenbank verweist, stellt die Zustellung von Nachrichten an den Zieldienst ein.
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 nach dem Ändern der Dienstebene noch nicht zugestellte Nachrichten vorhanden sind, lesen Sie sie aus der Quellwarteschlange, und senden Sie sie erneut an die Zielwarteschlange.
Überschreiten des Speicherplatzes mit kleinen Datenbankdateien
CREATE DATABASE-, – ALTER DATABASE ADD FILEund RESTORE DATABASE-Anweisungen schlagen möglicherweise fehl, weil die Instanz das Azure-Speicherlimit erreichen kann.
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. Nicht verwendeter Speicherplatz auf dem Datenträger wird nicht berechnet, aber die Gesamtgröße der Azure Premium-Datenträger darf 35 TB nicht überschreiten. In einigen Fällen kann eine verwaltete Instanz, die nicht insgesamt 8 TB benötigt, aufgrund interner Fragmentierung das Azure-Limit von 35 TB ü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.
Dieses Beispiel veranschaulicht, dass eine Instanz von SQL Managed Instance unter bestimmten Umständen aufgrund einer spezifischen Verteilung von Dateien das für einen angefügten Azure Premium-Datenträger reservierte Limit von 35 TB erreichen kann, wenn Sie dies 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. Es könnten jedoch keine neuen Datenbanken erstellt oder wiederhergestellt werden, da für neue Datenträgerlaufwerke nicht genügend Speicherplatz vorhanden ist, selbst nicht dann, wenn die Gesamtgröße aller Datenbanken das Größenlimit der Instanz nicht überschreitet. Der Fehler, der in diesem Fall zurückgegeben wird, ist nicht klar.
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.
Ein Transaktionsbereich in zwei Datenbanken in derselben Instanz wird nicht unterstützt
(Gelöst im März 2020) Die TransactionScope-Klasse in .NET funktioniert nicht, wenn zwei Abfragen an zwei Datenbanken in derselben Instanz im gleichen Transaktionsbereich gesendet werden:
using (var scope = new TransactionScope())
{
using (var conn1 = new SqlConnection("Server=quickstartbmi.neu15011648751ff.database.windows.net;Database=b;User ID=myuser;Password=<password>;Encrypt=true"))
{
conn1.Open();
SqlCommand cmd1 = conn1.CreateCommand();
cmd1.CommandText = string.Format("insert into T1 values(1)");
cmd1.ExecuteNonQuery();
}
using (var conn2 = new SqlConnection("Server=quickstartbmi.neu15011648751ff.database.windows.net;Database=b;User ID=myuser;Password=<password>;Encrypt=true"))
{
conn2.Open();
var cmd2 = conn2.CreateCommand();
cmd2.CommandText = string.Format("insert into b.dbo.T2 values(2)"); cmd2.ExecuteNonQuery();
}
scope.Complete();
}
Problemumgehung (seit März 2020 nicht mehr erforderlich): Verwenden Sie SqlConnection.ChangeDatabase(String), um anstelle von zwei Verbindungen eine andere Datenbank im Verbindungskontext zu verwenden.
Keine Lösung vorhanden
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 und Transaktionsprotokollsicherungen für die verwaltete Instance übernommen, 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 Systemanmeldedaten zum Zweck der Transaktionsreplikation. Diesen Anmeldenamen finden Sie in SSMS (im Objekt-Explorer im Abschnitt Sicherheit unter Anmeldungen) oder in der Systemsicht sys.syslogins. Das Format des Anmeldenamens sieht etwa wie 'DBxCy\WF-abcde01234QWERT' aus, und der Anmeldename hat eine öffentliche Serverrolle. Unter bestimmten Bedingungen wird dieser Anmeldename neu erstellt, und aufgrund eines Fehlers im System wird die vorherige Anmeldung nicht gelöscht. Dies kann zu einer erhöhten Anzahl von Anmeldungen führen. Diese Anmeldungen stellen keine Sicherheitsrisiken dar. Sie können sie sicher ignorieren. Diese Anmeldenamen dürfen nicht gelöscht werden, da mindestens einer 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.
Der Identitätswechsel mithilfe von EXECUTE AS USER oder EXECUTE AS LOGIN der folgenden Microsoft Entra-Prinzipale wird nicht unterstützt:
- Microsoft Entra-Benutzer mit einem Alias. In diesem Fall wird der Fehler
15517zurückgegeben. - Microsoft Entra-Anmeldungen und -Benutzer, die auf Microsoft Entra-Anwendungen oder -Dienstprinzipalen basieren. In diesem Fall werden die Fehler
15517und15406zurückgegeben.
Transaktionsreplikation muss nach einem geografischen Failover neu konfiguriert werden
Wenn die Transaktionsreplikation für eine Datenbank in einer Failover-Gruppe aktiviert ist, muss der SQL Managed Instance-Administrator alle Veröffentlichungen für die alte primäre Instanz bereinigen und nach einem Failover in eine andere Region für die neue primäre Instance erneut konfigurieren. Weitere Informationen finden Sie unter Replikation.
Struktur und Inhalt von tempdb werden neu erstellt
Die Datenbank tempdb ist stets in 12 Datendateien aufgeteilt, und die Dateistruktur kann nicht geändert werden. Die maximale Größe pro Datei kann nicht geändert werden. Zudem können tempdb keine neuen Dateien hinzugefügt werden. Die Datenbank tempdb wird beim Start oder Failover einer Instanz stets als leere Datenbank neu erstellt. An tempdb erfolgte Änderungen werden nicht beibehalten.
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. Möglicherweise gibt es Lücken im Fehlerprotokollverlauf, weil SQL Managed Instance auf mehreren virtuellen Computern mehrmals verschoben wurde.
Auf die Instanz kann mithilfe des Failovergruppenlisteners während des Skalierungsvorgangs vorübergehend nicht zugegriffen werden
Für die Skalierung verwalteter Instanzen ist es manchmal erforderlich, die Instanz in einen anderen virtuellen Cluster zu verschieben, zusammen mit den zugehörigen dienstbasierten DNS-Einträgen. Wenn die verwaltete Instanz an einer Failovergruppe teilnimmt, wird der DNS-Eintrag, der dem zugeordneten Failovergruppenlistener entspricht, in den neuen virtuellen Cluster verschoben (Lese-/Schreibzugriffslistener, wenn es sich bei der Instanz um den aktuellen geo-primären Listener handelt; und schreibgeschützter Listener, wenn es sich bei der Instanz um den aktuellen geo-sekundären Listener handelt).
Im aktuellen Skalierungsvorgangsentwurf werden die Listener-DNS-Einträge aus dem ursprünglichen virtuellen Cluster entfernt, bevor die verwaltete Instanz selbst vollständig zum neuen virtuellen Cluster migriert wird, was in einigen Situationen zu einer längeren Zeit führen kann, in 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.
Gelöst
In der Tabelle für manuelle Sicherungen in msdb wird der Benutzername nicht beibehalten
(Behoben im August 2023) Wir haben kürzlich in msdb Unterstützung für automatische Sicherungen eingeführt, doch die Tabelle enthält derzeit keine Informationen zu Benutzernamen.
Fehler beim Abfragen einer externen Tabelle aufgrund von fehlender Unterstützung
Das Abfragen einer externen Tabelle kann möglicherweise mit der generischen Fehlermeldung "Abfragen über externe Tabellen werden nicht mit der aktuellen Dienstebene oder Leistungsstufe dieser Datenbank unterstützt" fehlschlagen. Ziehen Sie eine Änderung der Dienst- oder Leistungsebene der Datenbank in Betracht.“ Die einzige Art von externen Tabellen, die in Azure SQL Managed Instance unterstützt wird, sind externe PolyBase-Tabellen (in der Vorschau). Um Abfragen für externe PolyBase-Tabellen zuzulassen, müssen Sie PolyBase für verwaltete Instanzen aktivieren, indem Sie den Befehl sp_configure ausführen.
Externe Tabellen bezogen auf das Elastic Query-Feature der Azure SQL-Datenbank werden in der SQL Managed Instance nicht unterstützt, allerdings sind das Erstellen und Abfragen nicht explizit blockiert. Im Zuge der Unterstützung externer PolyBase-Tabellen wurden neue Überprüfungen eingeführt, durch die das Abfragen beliebiger externer Tabellentypen in verwalteten Instanzen blockiert wird, wenn PolyBase nicht aktiviert ist.
Sie sollten stattdessen die Linked Server-Funktion nutzen, wenn Sie nicht unterstützte externe Tabellen für elastische Abfragen verwenden, um Daten aus Ihrer verwalteten Instanz in Azure SQL-Datenbank oder Azure Synapse abzufragen. Befolgen Sie die Anweisungen in diesem Artikel, um mithilfe eines Verbindungsservers eine Verbindung zwischen SQL Managed Instance und SQL-Datenbank herzustellen. Um die Verbindung zwischen SQL Managed Instance und SQL Synapse über einen Verbindungsserver herzustellen, überprüfen Sie die Schritt-für-Schritt-Anleitung. Da das Konfigurieren und Testen der Linked Server-Verbindung etwas Zeit in Anspruch nimmt, können Sie als temporäre Lösung eine Problemumgehung verwenden, um das Abfragen externer Tabellen im Zusammenhang mit der Elastic Query-Funktion zu ermöglichen:
Problemumgehung: Führen Sie (einmal pro Instanz) die folgenden Befehle aus, um Abfragen externer Tabellen zu aktivieren:
EXECUTE sp_configure 'polybase enabled', 1;
GO
RECONFIGURE;
GO
Bei der SQL Server-Authentifizierung werden Benutzernamen mit „@“ nicht unterstützt
Benutzernamen mit dem @-Symbol in der Mitte (z. B. 'abc@xy') können sich nicht per SQL Server-Authentifizierung anmelden.
Wiederherstellen der manuellen Sicherung ohne CHECKSUM schlägt möglicherweise fehl
(Behoben im Juni 2020) Unter bestimmten Umständen kann die manuelle Sicherung von Datenbanken, die für eine verwalteten Instanz ohne CHECKSUM erstellt wurde, nicht wiederhergestellt werden. Versuchen Sie in solchen Fällen erneut, die Sicherung wiederherzustellen, bis der Vorgang erfolgreich war.
Problemumgehung: Erstellen Sie manuelle Sicherungen von Datenbanken für verwaltete Instanzen mit aktivierter CHECKSUM.
Der Agent reagiert beim Ändern, Deaktivieren oder Aktivieren vorhandener Aufträge nicht mehr
Unter bestimmten Umständen kann es vorkommen, dass der Agent nicht mehr reagiert, wenn ein vorhandener Auftrag geändert, deaktiviert oder aktiviert wird. Das Problem wird bei Erkennung automatisch behoben, indem ein Neustart des Agent-Prozesses ausgeführt wird.
Berechtigungen für Ressourcengruppe werden nicht auf SQL Managed Instance angewendet
Wenn die Azure-Rolle „SQL Managed Instance Contributor“ auf eine Ressourcengruppe (RG) angewandt wird, wird sie nicht auf die SQL Managed Instance selbst angewandt und hat daher keine Auswirkungen.
Umgehungslösung: Richten Sie auf Abonnementebene eine SQL Managed Instance Contributor-Rolle für Benutzer ein.
SQL Agent-Aufträge können durch den Neustart des Agent-Prozesses unterbrochen werden
(Behoben im März 2020:) Der SQL-Agent erstellt bei jedem Starten eines Auftrags eine neue Sitzung und erhöht den Speicherverbrauch allmählich. Um zu vermeiden, dass die interne Arbeitsspeichergrenze erreicht wird, wodurch die Ausführung geplanter Aufträge blockiert würde, wird der Agent-Prozess neu gestartet, sobald die Arbeitsspeicherauslastung den Schwellenwert erreicht. Dies kann dazu führen, dass die Ausführung von Aufträgen unterbrochen wird, die zum Zeitpunkt des Neustarts ausgeführt werden.
@query Parameter wird in sp_send_db_mail nicht unterstützt
Der @query-Parameter in der Prozedur sp_send_db_mail funktioniert nicht.
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:
„Die Verwaltete Instanz benötigt ein Dienstprinzipal für den Zugriff auf Microsoft Entra ID (früher Azure Active Directory). Klicken Sie hier, um einen Dienstprinzipal zu erstellen"
Sie können diese Fehlermeldung ignorieren, wenn der Dienstprinzipal für die verwaltete Instanz bereits vorhanden ist oder die Microsoft Entra-Authentifizierung für die verwaltete Instanz funktioniert.
Um zu überprüfen, ob der Dienstprinzipal vorhanden ist, navigieren Sie im Azure-Portal zur Seite Unternehmensanwendungen, wählen Sie in der Dropdownliste Anwendungstyp die Option Verwaltete Identitäten aus. Klicken Sie auf Übernehmen, und geben Sie in das Suchfeld den Namen der verwalteten Instanz 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 in der Fehlermeldung befolgt und den Link in der Fehlermeldung ausgewählt haben, wurde der Dienstprinzipal der verwalteten Instanz neu erstellt. Weisen Sie in diesem Fall dem neu erstellten Dienstprinzipal Microsoft Entra ID-Leseberechtigungen zu, damit die Microsoft Entra-Authentifizierung ordnungsgemäß funktioniert. Dies kann über Azure PowerShell anhand dieser Anweisungen erfolgen.
Auf das event_file Ziel der system_health-Ereignissitzung kann nicht zugegriffen werden
(Im Mai 2025 behoben) 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://' beginnt, ist als Wert für jeden angegebenen Dateipfad erforderlich." Dies geschieht in SQL Server Management Studio oder beim Lesen der Sitzungsdaten mithilfe der funktion sys.fn_xe_file_target_read_file .
Diese Verhaltensänderung ist eine unbeabsichtigte Folge einer kürzlich erforderlichen Sicherheitskorrektur. Wir untersuchen die Machbarkeit einer zusätzlichen Änderung, die es Kunden ermöglichen würde, die system_health Sitzung auf Azure SQL Managed Instance sicher weiter zu verwenden. In der Zwischenzeit können Kunden dieses Problem umgehen, indem sie ein eigenes Äquivalent 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.
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.