Bekannte Probleme mit Azure SQL Managed Instance
Gilt für:
Azure SQL Managed Instance
In diesem Artikel werden die derzeit bekannten Probleme mit Azure SQL Managed Instance sowie deren Lösungsdatum oder 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
Die Liste der langfristigen Backups im Azure-Portal zeigt Sicherungsdateien für aktive und gelöschte Datenbanken mit demselben Namen an
Langfristige Backups können auf der Azure-Portalseite für eine Azure SQL Managed Instance auf der Registerkarte Backups aufgelistet und verwaltet werden. Auf der Seite werden aktive oder gelöschte Datenbanken, grundlegende Informationen zu den langfristigen Backups und Verlinkungen zum Verwalten der Backups aufgelistet. Beim Klicken auf den Link Manage wird an der Seite ein neues Blatt mit einer Liste der Backups 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 die PowerShell-Befehle Get-AzSqlInstanceDatabaseLongTermRetentionBackup und Remove-AzSqlInstanceDatabaseLongTermRetentionBackup oder die CLI-Befehle az sql midb ltr-backup list und az sql midb ltr-backup delete verwenden, um langfristige Sicherungen mit dem Parameter DatabaseState und dem Rückgabewert DatabaseDeletionTime für eine Datenbank zu filtern und zu verwalten.
Auf das event_file Ziel der system_health-Ereignissitzung kann nicht zugegriffen werden.
Wenn Sie versuchen, den Inhalt des event_file Ziels der system_health Ereignissitzung zu lesen, wird der Fehler 40538 angezeigt: "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 sys.fn_xe_file_target_read_file-Funktion.
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.
Prozedur-sp_send_dbmail kann fehlschlagen, wenn der @query Parameter für verwaltete Instanzen von Nov22FW verwendet wird
Die Prozedur sp_send_dbmail kann fehlschlagen, wenn @query der Parameter verwendet wird, und dies wirkt sich auf Instanzen aus, für die die Featurewelle vom November 2022 aktiviert ist. Fehler treten auf, wenn die gespeicherte Prozedur unter dem Sysadmin-Konto ausgeführt wird.
Dieses Problem wird durch einen bekannten Bug im Zusammenhang mit sp_send_dbmailder Verwendung von Identitätsdiebstahl 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 ä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
EXEC 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.
EXEC 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
EXEC 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). Ab Samstag, 10. September 2022, 12:00 Uhr, bis Samstag, 1. April 2023, 12:00 Uhr, wird die offizielle Zeit um 60 Minuten vorgestellt. Die Änderung betrifft die folgenden drei Zeitzonen: Chilenische Normalzeit, Osterinsel Normalzeit und Magellan (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 zu einem Fehler führt, ist der Parameterwert NULL. Das bedeutet, dass sp_send_dbmail noch einmal aufgerufen werden muss, um erfolgreich eine E-Mail 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
Bei Skalierungsvorgängen von SQL Managed Instance, bei denen die Dienstebene oder die Anzahl von virtuellen Kernen geändert wird, werden die Einstellungen für die Serververtrauensgruppe im Back-End zurückgesetzt und die Ausführung von verteilten Transaktionen deaktiviert. Dieses Problem lässt sich umgehen, indem Sie die Serververtrauensstellungsgruppe im Azure-Portal löschen und eine neue erstellen.
SQL Managed Instance mit demselben Namen wie der zuvor gelöschte logische Server kann nicht erstellt werden
Beim Erstellen eines logischen Servers in Azure für die Azure SQL-Datenbank, und beim Erstellen von SQL Managed Instance wird ein DNS-Eintrag von <name>.database.windows.com erstellt. Der DNS-Eintrag muss eindeutig sein. Wenn Sie also einen logischen Server für Azure SQL-Datenbank erstellen und diesen anschließend löschen, gibt es eine Übergangszeit 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.
Dienstprinzipal kann nicht auf Microsoft Entra ID und AKV zugreifen
Unter bestimmten Umständen kann ein Problem bei dem Dienstprinzipal auftreten, 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: Wenn Sie verhindern möchten, dass dieses Problem in Ihrer Instanz von SQL Managed Instance auftritt, bevor Sie Updatebefehle ausführen, oder falls dieses Problem bereits nach Updatebefehlen aufgetreten ist, wechseln Sie zum Azure-Portal, und öffnen Sie in SQL Managed Instance die Seite „Active Directory-Administrator“. Überprüfen Sie, ob die Fehlermeldung „Die verwaltete Instanz benötigt einen Dienstprinzipal für den Zugriff auf Microsoft Entra ID. 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.
Einschränkung beim manuellen Failover über das Portal für Failovergruppen
Wenn sich eine Failovergruppe auf mehrere Instanzen in verschiedenen Azure-Subsriptions oder Ressourcengruppen erstreckt, kann von der primären Instanz in der Failovergruppe kein manuelles Failover eingeleitet werden.
Problemumgehung: Initiieren Sie das Failover über das Portal von der geosekundären Instanz.
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, führen möglicherweise nicht sofort zu Fehlern. Bei 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 für den Vorgang tritt nach 30 Minuten der Fehler Internal server error auf.
Das Ändern der Dienstebene und Erstellen von Instanzvorgängen wird durch die laufende Datenbankwiederherstellung blockiert
Eine laufende RESTORE-Anweisung, ein Migrationsprozess des Datenmigrationsdiensts und die integrierte Zeitpunktwiederherstellung blockieren das Aktualisieren einer Dienstebene und eine Größenänderung der vorhandenen Instanz sowie das Erstellen neuer Instanzen so lange, 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 in Instanzenpools sind davon nicht betroffen. Beim Erstellen oder Ändern von Vorgängen auf Dienstebene tritt kein Fehler oder Timeout auf. Sie werden fortgesetzt, 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 Resource Governor, mit dem Sie die der Benutzerworkload zugewiesenen Ressourcen einschränken können, klassifiziert möglicherweise eine Benutzerworkload nach einem Failover oder einer vom Benutzer initiierten Änderung der Dienstebene (z. B. Änderung der maximalen virtuellen Kerne oder der maximalen Instanzspeichergröße) falsch.
Problemumgehung: Führen Sie ALTER RESOURCE GOVERNOR RECONFIGURE regelmäßig oder als Teil des SQL-Agent-Auftrags aus, der den SQL-Task beim Starten der Instanz ausführt, wenn Sie Resource Governor verwenden.
Datenbankübergreifende Service Broker-Dialoge müssen nach einem Upgrade der Dienstebene erneut initialisiert werden
Datenbankübergreifenden Service Broker-Dialoge stellen die Zustellung der Nachrichten an die Dienste in anderen Datenbanken nach Änderung der Dienstebene ein. 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.
Mit jeder Instanz von SQL Managed Instance auf der Dienstebene „Universell“ sind 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 Sicht sys.databases, um den tatsächlichen Datenbanknamen aus dem physischen Datenbanknamen aufzulösen, der in Form von GUID-Datenbankbezeichnern angegeben wurde:
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=mypassword;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=mypassword;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
Erhöhte Anzahl an Systemanmeldungen für die Transaktionsreplikation
Der Azure SQL Managed Instance-Dienst erstellt die Systemanmeldung für Zwecke 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 ignorieren. Diese Anmeldenamen dürfen nicht gelöscht werden, da mindestens einer davon für die Transaktionsreplikation verwendet wird.
In der Tabelle für manuelle Sicherungen in msdb wird der Benutzername nicht beibehalten
Wir haben kürzlich in msdb Unterstützung für automatische Sicherungen eingeführt, aber die Tabelle enthält derzeit keine Informationen zu Benutzernamen.
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.
Identitätswechsel für 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 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 persistent 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: „Fehler 40532: Der von der Anmeldung angeforderte Server ‚xxx.xxx.xxx.xxx’ kann nicht geöffnet werden. Fehler bei der Anmeldung. (Microsoft SQL Server, Fehler: 40532)“
Das Problem wird durch Neugestaltung des Skalierungsvorgangs behoben.
Gelöst
Fehler beim Abfragen einer externen Tabelle aufgrund von fehlender Unterstützung
Beim Abfragen einer externen Tabelle tritt möglicherweise die folgende generische Fehlermeldung auf: „Abfragen über externe Tabelle werden mit der aktuellen Dienst- oder Leistungsebene dieser Datenbank nicht unterstützt. 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 im Zusammenhang mit dem Feature Elastische Abfrage von Azure SQL-Datenbank werden in SQL Managed Instance nicht unterstützt, deren Erstellung und Abfrage wurde jedoch 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 das Verbindungsserverfeature nutzen, wenn Sie nicht unterstützte externe Tabellen für elastische Abfragen verwenden, um Daten in Azure SQL-Datenbank oder Azure Synapse aus Ihrer verwalteten Instanz abzufragen. Befolgen Sie die Anweisungen in diesem Artikel, um mithilfe eines Verbindungsservers eine Verbindung zwischen SQL Managed Instance und SQL-Datenbank herzustellen. Informationen zur Verbindungsherstellung zwischen SQL Managed Instance und SQL Synapse mithilfe eines Verbindungsservers finden Sie in dieser Schrittanleitung. Da das Konfigurieren und Testen der Verbindung über den Verbindungsserver etwas dauert, können Sie als temporäre Lösung eine Problemumgehung verwenden, um das Abfragen externer Tabellen im Zusammenhang mit dem Feature für elastische Abfragen zu ermöglichen:
Problemumgehung: Führen Sie (einmal pro Instanz) die folgenden Befehle aus, um Abfragen externer Tabellen zu aktivieren:
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
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 „Mitwirkender“ von SQL Managed Instance auf eine Ressourcengruppe (RG) angewandt wird, betrifft dies nicht SQL Managed Instance und hat keine Auswirkungen.
Umgehung: Richten Sie eine SQL Managed Instance Teilnehmerrolle für Benutzer auf der Abonnementebene 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 Dienstprinzipal 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, sind keine weiteren Aktionen erforderlich, da der Dienstprinzipal bereits vorhanden ist.
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.
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.
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für