Kända problem med Azure SQL Managed Instance

gäller för:Azure SQL Managed Instance

Den här artikeln innehåller en lista över kända problem med Azure SQL Managed Instanceoch deras lösningsdatum eller möjliga lösning. Mer information om Azure SQL Managed Instance finns i Vad är Azure SQL Managed Instance?och Vad är nytt i Azure SQL Managed Instance?

Kända problem

Har lösning

Ändra kvarhållningsperioden för säkerhetskopiering för det kostnadsfria erbjudandet

Du kan bara ändra kvarhållningsprincipen för säkerhetskopior för dina databaser i den kostnadsfria SQL-hanterade instansen med hjälp av REST API-, PowerShell - och Azure CLI-kommandon . Det går inte att ändra kvarhållningsprincipen för säkerhetskopiering via Azure-portalen.

Inloggningen till läs-sekundär misslyckades på grund av lång väntan på "HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING"

Du kan se det här felet som ett undantag för Microsoft OLE DB Driver 19 för SQL Server-drivrutinen när du försöker ansluta till en skrivskyddad sekundär replik av en redundansgrupp eller en databas som replikeras via länken Hanterad instans.

Det här felet uppstår när den sekundära repliken inte är tillgänglig för inloggningar eftersom radversioner saknas för transaktioner som var under flygning när en sekundär replik startades om eller återvanns, antingen för underhåll eller på grund av en redundansväxling. När en instans startas om eller redundansväxlar rensas versionsdata som lagras i tempdb så att sekundära läsfrågor avbryts om det finns långvariga aktiva transaktioner som startades före redundansväxlingen eller omstarten.

Lös problemet genom att rulla tillbaka eller komplettera aktiva transaktioner på den primära repliken. Undvik det här felet genom att minimera långvariga skrivtransaktioner på den primära repliken.

Interimsvägledning om tidszonsuppdateringar för Paraguay 2024

Den 14 oktober 2024 tillkännagav den paraguayanska regeringen en permanent ändring av landets tidszonspolitik. Paraguay förblir på sommartid (DST) året runt och antar effektivt UTC-3 som sin standardtid. Därför går klockorna inte framåt med 60 minuter klockan 12:00 den 23 mars 2025, som tidigare schemalagts. Den här ändringen påverkar tidszonen för Paraguays standardtid. Microsoft har släppt relaterade Windows-uppdateringar i februari och mars 2025. Azure SQL Managed Instance återspeglar för närvarande inte den här uppdateringen. Instanser som använder den berörda tidszonen återspeglar inte ändringarna förrän Azure SQL Managed Instance-tjänsten absorberar uppdateringen på operativsystemnivå.

Lösning: Om du behöver ändra berörda tidszoner för dina hanterade instanser bör du vara medveten om begränsningar och följa vägledningen i dokumentationen.

Fel 8992 vid körning av DBCC CHECKDB på en SQL Server-databas som kommer från SQL Managed Instance

Du kan se följande fel när du kör DBCC CHECKDB kommandot på en SQL Server 2022-databas när du har tagit bort ett index eller en tabell med ett index och databasen kommer från Azure SQL Managed Instance, till exempel efter återställning av en säkerhetskopia eller från länkfunktionen SQL Managed Instance:

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.

Du kan undvika problemet genom att först släppa indexet eller tabellen med indexet från källdatabasen i Azure SQL Managed Instance och sedan återställa eller länka databasen till SQL Server 2022 igen. Om det inte går att återskapa databasen från azure SQL Managed Instance-källan kontaktar du Microsofts support för att lösa problemet.

Lista över långsiktiga säkerhetskopieringar i Azure-portalen visar säkerhetskopieringsfiler för aktiva och borttagna databaser med samma namn

Långsiktiga säkerhetskopior kan visas och hanteras på azure-portalsidan för en Hanterad Azure SQL-instans på fliken Säkerhetskopior . Sidan visar aktiva eller borttagna databaser, grundläggande information om deras långsiktiga säkerhetskopior och länk för att hantera säkerhetskopior. När du väljer länken Hantera öppnas ett nytt sidofönster med en lista över säkerhetskopior. På grund av ett problem med filtreringslogik visar listan säkerhetskopior för både aktiva databaser och borttagna databaser med samma namn. Detta kräver särskild uppmärksamhet när du väljer säkerhetskopior för borttagning, för att undvika att ta bort säkerhetskopior för en felaktig databas.

Lösning: Använd säkerhetskopieringstid (UTC) information i listan för att särskilja säkerhetskopior som tillhör databaser med samma namn som fanns på instansen under olika perioder. Du kan också använda PowerShell-kommandona Get-AzSqlInstanceDatabaseLongTermRetentionBackup och Remove-AzSqlInstanceDatabaseLongTermRetentionBackup eller CLI-kommandona az sql midb ltr-backup list och az sql midb ltr-backup delete för att hantera långsiktiga säkerhetskopior med hjälp av DatabaseState-parametern och DatabaseDeletionTime-returvärdet för att filtrera säkerhetskopior för en databas.

Proceduren sp_send_dbmail kan misslyckas när parametern @query

Proceduren sp_send_dbmail kan misslyckas när @query parameter används. Fel inträffar när den lagrade proceduren körs under sysadmin-kontot.

Det här problemet orsakas av en känd bugg som rör hur sp_send_dbmail använder personifiering.

Lösning: Kontrollera att du anropar sp_send_dbmail under lämpligt anpassat konto som du har skapat och inte under sysadmin-konto.

Här är ett exempel på hur du kan skapa ett dedikerat konto och ändra befintliga objekt som skickar e-post via 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

Att ändra anslutningstyp påverkar inte anslutningar via slutpunkten för redundansklustergruppen

Om en instans deltar i en failover-grupp, börjar inte instansens anslutningstyp gälla för de anslutningar som upprättas via lyssnarslutpunkten för failover-gruppen.

Lösning: Släpp och återskapa failover-gruppen efter att du har ändrat anslutningstypen.

Distribuerade transaktioner kan köras när sql-hanterad instans har tagits bort från serverförtroendegruppen

Serverförtroendegrupper används för att upprätta förtroende mellan hanterade instanser, vilket är nödvändigt för att köra distribuerade transaktioner. När du har tagit bort den SQL-hanterade instansen från serverförtroendegruppen eller tagit bort gruppen kanske du fortfarande kan köra distribuerade transaktioner. Det finns en lösning som du kan använda för att vara säker på att distribuerade transaktioner är inaktiverade, och det är genom användarinitierad manuell failover på den SQL-hanterade instansen.

Det går inte att skapa SQL Managed Instance med samma namn som den logiska servern som tidigare tagits bort

En DNS-record med <name>.database.windows.com skapas när du skapar en logisk server i Azure för Azure SQL Database, och även när du skapar en SQL-hanterad instans. DNS-posten måste vara unik. Om du skapar en logisk server för SQL Database och sedan tar bort den finns det därför en tröskelperiod på sju dagar innan namnet släpps från posterna. Under den perioden kan en SQL Managed Instance inte skapas med samma namn som den borttagna logiska servern. Som en lösning kan du använda ett annat namn för SQL Managed Instance eller skapa ett supportärende för att frigöra det logiska servernamnet.

Tjänstprincipalen kan inte komma åt Microsoft Entra ID och AKV

I vissa fall kan det finnas ett problem med tjänstens huvudnamn som används för att komma åt Microsoft Entra-ID (tidigare Azure Active Directory-) och Azure Key Vault-tjänster (AKV). Det här problemet påverkar därför användningen av Microsoft Entra-autentisering och transparent datakryptering (TDE) med SQL Managed Instance. Detta kan uppstå som ett tillfälligt anslutningsproblem eller att inte kunna köra instruktioner som CREATE LOGIN/USER FROM EXTERNAL PROVIDER eller EXECUTE AS LOGIN/USER. Att konfigurera TDE med kundhanterad nyckel på en ny Azure SQL Managed Instance kanske inte heller fungerar under vissa omständigheter.

Lösning: Om du vill förhindra att det här problemet uppstår på din SQL Managed Instance, innan du kör några uppdateringskommandon, eller om du redan har upplevt det här problemet efter uppdateringskommandon, går du till sidan Översikt för din SQL-hanterade instans i Azure-portalen. Under Inställningarväljer du Microsoft Entra-ID för att komma åt administratörssidan för SQL Managed Instance Microsoft Entra ID. Kontrollera om du kan se felmeddelandet:

Managed Instance needs a Service Principal to access Microsoft Entra ID. Click here to create a Service Principal.

Om du har stött på det här felmeddelandet väljer du det och följer de stegvisa instruktionerna tills det här felet har lösts.

Fel fel returnerades vid försök att ta bort en fil som inte är tom

SQL Server och SQL Managed Instance tillåter inte att en användare släpper en fil som inte är tom. Om du försöker ta bort en icke tom datafil med hjälp av en ALTER DATABASE REMOVE FILE-instruktion, returneras felet Msg 5042 – The file '<file_name>' cannot be removed because it is not empty inte omedelbart. SQL Managed Instance fortsätter att försöka släppa filen och åtgärden misslyckas efter 30 minuter med Internal server error.

Förändringar i tjänstnivån och operationer för att skapa instans stoppas av pågående databasåterställning.

En pågående RESTORE instruktion, en migreringsprocess för datamigreringstjänsten och inbyggd återställning till en viss tidpunkt förhindrar uppdatering av en tjänstenivå, ändring av storlek på den befintliga instansen eller skapande av nya instanser tills återställningsprocessen är klar.

Återställningsprocessen blockerar dessa åtgärder på de hanterade instanserna och instanspoolerna i samma undernät där återställningsprocessen körs. Instanserna i instanspooler påverkas inte. Åtgärder för att skapa eller ändra tjänstnivå misslyckas inte eller överskrider tidsgränsen. De fortsätter när återställningsprocessen har slutförts eller avbrutits.

Lösning: Vänta tills återställningsprocessen är klar eller avbryt återställningsprocessen om åtgärden för att skapa eller uppdatera tjänstnivå har högre prioritet.

Resource Governor på en läsbar sekundär replika måste konfigureras om efter failover

Funktionen Resursguvernör som gör att du kan begränsa de resurser som tilldelats användararbetsbelastningen kan felaktigt klassificera vissa användararbetsbelastningar efter redundansväxling eller en användarinitierad ändring av tjänstnivån (till exempel ändringen av maximal virtuell kärna eller maximal lagringsstorlek för instanser).

Lösning: Kör ALTER RESOURCE GOVERNOR RECONFIGURE regelbundet eller som en del av ett SQL Agent-jobb som kör SQL-uppgiften när den läsbara sekundära repliken startar om du använder Resource Governor.

Service Broker-dialogrutor mellan databaser måste initieras på nytt efter uppgraderingen på tjänstnivå

Service Broker-dialoger mellan databaser slutar leverera meddelanden till tjänsterna i andra databaser efter att tjänstnivån har ändrats. Meddelandena går inte förloradeoch de finns i avsändarkön. Alla ändringar av virtuella kärnor eller instanslagringsstorlek i SQL Managed Instance gör att ett service_broke_guid värde i sys.databases vy ändras för alla databaser. Alla DIALOG som skapats med hjälp av en BEGIN DIALOG-instruktion som refererar till Service Brokers i andra separata databaser upphör att leverera meddelanden till måltjänsten.

Lösning: Stoppa alla aktiviteter som använder samtal mellan databaser i Service Broker innan du uppdaterar en tjänstnivå och initiera om dem efteråt. Om det finns återstående meddelanden som inte har levererats efter en ändring på tjänstnivå läser du meddelandena från källkön och skickar dem till målkön igen.

Överskrider lagringsgränsen på grund av små databasfiler

CREATE DATABASE, ALTER DATABASE ADD FILE, och RESTORE DATABASE -instruktioner kan misslyckas eftersom instansen kan nå Azure Storage-gränsen på tjänstnivån Generell användning, men inte uppgraderingen av tjänstnivån Nästa generations generell användning eller tjänstnivån Affärskritisk.

Varje generell instans av SQL Managed Instance har upp till 35 TB lagringsutrymme reserverat för Azure Premium-diskutrymme. Varje databasfil placeras på en separat fysisk disk. Diskstorlekarna kan vara 128 GB, 256 GB, 512 GB, 1 TB eller 4 TB. Outnyttjat utrymme på disken debiteras inte, men den totala summan av Azure Premium Disk-storlekar får inte överstiga 35 TB. I vissa fall kan en SQL-hanterad instans som inte behöver totalt 8 TB överskrida azure-gränsen på 35 TB på grund av intern fragmentering.

En generell instans av SQL Managed Instance kan till exempel ha en stor fil som är 1,2 TB stor på en 4 TB-disk. Det kan också ha 248 filer som är 1 GB vardera och som placeras på separata diskar på 128 GB. I det här exemplet:

• Den totala allokerade disklagringsstorleken är 1 x 4 TB + 248 x 128 GB = 35 TB.
• Det totala reserverade utrymmet för databaser på instansen är 1 x 1,2 TB + 248 x 1 GB = 1,4 TB.

Det här exemplet visar att en instans av SQL Managed Instance under vissa omständigheter, på grund av en specifik distribution av filer, kan nå gränsen på 35 TB som är reserverad för en ansluten Azure Premium-disk när du kanske inte förväntar dig det.

I det här exemplet fortsätter befintliga databaser att fungera och kan växa utan problem så länge nya filer inte läggs till. Det går inte att skapa eller återställa nya databaser eftersom det inte finns tillräckligt med utrymme för nya diskenheter, även om den totala storleken på alla databaser inte når instansstorleksgränsen. Felet som returneras i det fallet är inte tydligt.

Du kan identifiera antalet återstående filer med hjälp av systemvyer. Om du når den här gränsen kan du försöka tom och ta bort några av de mindre filerna med hjälp av DBCC SHRINKFILE-instruktionen eller växla till nivån Affärskritisk, som inte har den här gränsen.

GUID-värden som visas i stället för databasnamn

Flera systemvyer, prestandaräknare, felmeddelanden, XEvents och felloggposter visar GUID-databasidentifierare i stället för de faktiska databasnamnen. Förlita dig inte på dessa GUID-identifierare eftersom de kan ersättas med faktiska databasnamn i framtiden.

Tillfällig lösning: Använd sys.databases vy för att fastställa det faktiska databasnamnet från det fysiska databasnamnet, som är specificerad i form av GUID-databasidentifierare:

SELECT name AS ActualDatabaseName,
       physical_database_name AS GUIDDatabaseIdentifier
FROM sys.databases
WHERE database_id > 4;

CLR-moduler och länkade servrar kan ibland inte referera till en lokal IP-adress

CLR-moduler i SQL Managed Instance och länkade servrar eller distribuerade frågor som refererar till en aktuell instans kan ibland inte matcha IP-adressen för en lokal instans. Det här felet är ett tillfälligt problem.

Ingen lösning

Differentiella säkerhetskopior görs inte när en instans är länkad till SQL Server

När du konfigurerar en länk mellan SQL Server och Azure SQL Managed Instance görs automatiserade fullständiga säkerhetskopieringar och transaktionsloggsäkerhetskopior på den SQL-hanterade instansen, oavsett om den är i den primära rollen eller inte. Differentiella säkerhetskopior tas dock inte för närvarande, när kan leda till längre återställningstider än förväntat.

Ökat antal systeminloggningar som används för transaktionsreplikering

Azure SQL Managed Instance-tjänsten skapar systeminloggning för transaktionsreplikering. Den här inloggningen finns i SSMS (i Object Explorer, under Security, Logins) eller i systemvyn sys.syslogins. Inloggningsnamnformatet ser ut som 'DBxCy\WF-abcde01234QWERT'och inloggningen har en offentlig serverroll. Under vissa förhållanden återskapas den här inloggningen och på grund av ett fel i systemet tas inte tidigare inloggning bort. Detta kan leda till ett ökat antal inloggningar. Dessa inloggningar utgör inte ett säkerhetshot. De kan ignoreras på ett säkert sätt. Dessa inloggningar bör inte tas bort eftersom minst en av dem används för transaktionsreplikering.

Microsoft Entra-inloggningar och användare stöds inte i SSDT

SQL Server Data Tools har inte fullständigt stöd för Microsoft Entra-inloggningar och -användare.

Personifiering av Microsoft Entra-inloggningstyper stöds inte

Personifiering med EXECUTE AS USER eller EXECUTE AS LOGIN av följande Microsoft Entra-huvudnamn stöds inte:

• Användare med alias kopplat till Microsoft Entra. Följande fel returneras i det här fallet: 15517.
• Microsoft Entra-inloggningar och användare baserat på Microsoft Entra-program eller tjänstens huvudnamn. Följande fel returneras i det här fallet: 15517 och 15406.

Transaktionsreplikering måste ställas in på nytt efter geografisk felövergång.

Om transaktionsreplikering är aktiverad på en databas i en redundansgrupp måste SQL Managed Instance-administratören rensa alla publikationer på den gamla primära databasen och konfigurera om dem på den nya primära när en redundansväxling till en annan region inträffar. Mer information finns i Replikering.

Felloggar sparas inte

Felloggar som är tillgängliga i SQL Managed Instance sparas inte och deras storlek ingår inte i den maximala lagringsgränsen. Felloggar kan automatiskt raderas om failover sker. Det kan finnas luckor i fellogghistoriken eftersom SQL Managed Instance har flyttats flera gånger på flera virtuella datorer.

Löst

Tillfällig otillgänglighet av instanser med hjälp av lyssnaren för failover-gruppen under skalningsoperationen

(Löst i april 2025)

För att skala sql-hanterad instans krävs ibland att instansen flyttas till ett annat virtuellt kluster, tillsammans med de associerade tjänstunderhållna DNS-posterna. Om den SQL-hanterade instansen deltar i en redundansgrupp flyttas DNS-posten som motsvarar dess associerade lyssnare för redundansgrupper (läs-skriv-lyssnare, om instansen är den aktuella geo-primära skrivskyddade lyssnaren, om instansen är den aktuella geo-sekundära) till det nya virtuella klustret.

I den aktuella skalningsåtgärdsdesignen tas lyssnarens DNS-poster bort från det ursprungliga virtuella klustret innan själva SQL-hanterade instansen migreras helt till det nya virtuella klustret, vilket i vissa fall kan leda till en längre tid under vilken instansens IP-adress inte kan lösas med lyssnaren. Under den här tiden kan en SQL-klient som försöker komma åt den instans som skalas med lyssnarens slutpunkt förvänta sig inloggningsfel med följande felmeddelande:

Error 40532: Cannot open server "xxx.xxx.xxx.xxx" requested by the login. The login failed. (Microsoft SQL Server, Error: 40532).

Problemet åtgärdas genom omdesign av skalningsåtgärden.

Tabellen för manuella säkerhetskopieringar i msdb bevarar inte användarnamnet

(löst i augusti 2023) Vi har nyligen infört stöd för automatiska säkerhetskopieringar i msdb, men tabellen innehåller för närvarande inte användarnamnsinformation.

När du använder SQL Server-autentisering stöds inte användarnamn med @

Användarnamn som innehåller @-symbolen i mitten (till exempel 'abc@xy') kan inte logga in med SQL Server-autentisering.

Återställning av manuell säkerhetskopiering utan CHECKSUM kan misslyckas

(Löst i juni 2020) I vissa fall kan manuell säkerhetskopiering av databaser som har gjorts på en SQL-hanterad instans utan CHECKSUM misslyckas med att återställas. I sådana fall försöker du återställa säkerhetskopian igen tills du lyckas.

Lösning: Gör manuella säkerhetskopior av databaser på SQL-hanterade instanser med CHECKSUM aktiverat.

Behörigheter för resursgrupp som inte tillämpas på SQL Managed Instance

När rollen SQL Managed Instance Contributor i Azure tillämpas på en resursgrupp (RG), tillämpas den inte på SQL Managed Instance och har ingen effekt.

Lösning: Konfigurera en SQL Managed Instance-deltagarroll för användare på prenumerationsnivå.

Vilseledande felmeddelande på Azure-portalen som tyder på att tjänstens huvudnamn ska återskapas

Sidan för Active Directory-administratör i Azure-portalen för Azure SQL Managed Instance kan visa följande felmeddelande, även om tjänsthuvudkontot redan finns:

Managed Instance needs a Service Principal to access Microsoft Entra ID ([formerly Azure Active Directory](/entra/fundamentals/new-name)). Click here to create a Service Principal

Du kan försumma det här felmeddelandet om tjänstens huvudnamn för den SQL-hanterade instansen redan finns och/eller Microsoft Entra-autentisering på den SQL-hanterade instansen fungerar.

Om du vill kontrollera om tjänstens huvudnamn finns går du till sidan Företagsprogram i Azure-portalen, väljer Hanterade identiteter i listrutan Programtyp , väljer Tillämpa och skriver namnet på den SQL-hanterade instansen i sökrutan. Om instansnamnet visas i resultatlistan finns tjänstens huvudnamn redan och inga ytterligare åtgärder krävs.

Om du redan har följt anvisningarna från felmeddelandet och valt länken från felmeddelandet har tjänstens huvudnamn för den SQL-hanterade instansen återskapats. I så fall tilldelar du läsbehörigheter för Microsoft Entra-ID till det nyligen skapade tjänsthuvudkontot för att Microsoft Entra-autentisering ska fungera korrekt. Detta kan göras via Azure PowerShell genom att följa instruktioner.

Målet för event_file i system_health-händelsesessionen är inte tillgängligt

(Löst i maj 2025) När du försöker läsa innehållet i event_file målet för händelsesessionen system_health får du fel 40538: "En giltig URL som börjar med "https://" krävs som värde för alla angivna filsökvägar." Detta inträffar i SQL Server Management Studio eller när du läser sessionsdata med hjälp av funktionen sys.fn_xe_file_target_read_file .

Den här ändringen i beteendet är en oavsiktlig konsekvens av en säkerhetskorrigering som nyligen krävdes. Vi undersöker möjligheten till ytterligare en ändring som gör det möjligt för kunder att fortsätta använda den system_health sessionen i Azure SQL Managed Instance på ett säkert sätt. Under tiden kan kunderna kringgå det här problemet genom att skapa en egen motsvarighet till system_health-sessionen med ett event_file mål i Azure Blob Storage. Mer information, inklusive ett T-SQL-skript för att skapa den system_health session som kan ändras för att skapa en egen motsvarighet till system_health, finns i Använd system_health-sessionen.

Bidra till innehåll

Information om hur du bidrar till Azure SQL-dokumentationen finns i deltagarguiden för Docs.

Relaterat innehåll

• För en lista över uppdateringar och förbättringar av SQL Managed Instance, se uppdateringar av tjänsten SQL Managed Instance.

• Uppdateringar och förbättringar av alla Azure-tjänster finns i Service-uppdateringar.