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 Instance och deras lösningsdatum eller möjliga lösning. Mer information om Azure SQL Managed Instance finns i översikten och nyheter.

Kända problem

Har lösning

Det event_file målet för system_health händelsesessionen är inte tillgängligt

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 system_health sessionen på hanterad instans 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 sessionen system_health som kan ändras för att skapa en egen motsvarighet system_healthtill , finns i Använda system_health-sessionen.

Proceduren sp_send_dbmail kan misslyckas när @query parametern används på Nov22FW-aktiverade hanterade instanser

Proceduren sp_send_dbmail kan misslyckas när @query parametern används och detta påverkar instanser som har funktionsvågen november 2022 aktiverad. 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 personifiering används.

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

Interimsvägledning om tidszonsuppdateringar för Chile 2022

Den 8 augusti 2022 gjorde den chilenska regeringen ett officiellt tillkännagivande om en ändring av tidszonen sommartid (DST). Från och med 12:00 lördag 10 september 2022, till 12:00 lördag 1 april 2023, kommer den officiella tiden att avancera 60 minuter. Ändringen påverkar följande tre tidszoner: Pacific SA Standard Time, Easter Island Standard Time och Magallanes Standard Time. Azure SQL Managed Instances med hjälp av berörda tidszoner återspeglar inte ändringarna förrän Microsoft släpper en OS-uppdatering för att stödja detta, och 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änsningarna och följa vägledningen i dokumentationen.

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

Om en instans deltar i en redundansgrupp börjar det inte gälla att ändra instansens anslutningstyp för de anslutningar som upprättas via lyssnarslutpunkten för redundansgruppen.

Lösning: Släpp och återskapa redundansgruppen när du har ändrat anslutningstypen.

Proceduren sp_send_dbmail kan misslyckas tillfälligt när @query parametern används

Proceduren sp_send_dbmail kan misslyckas tillfälligt när @query parametern används. När det här problemet uppstår misslyckas varannan körning av proceduren sp_send_dbmail med fel Msg 22050, Level 16, State 1 och meddelande Failed to initialize sqlcmd library with error number -2147467259. För att kunna se det här felet korrekt ska proceduren anropas med standardvärdet 0 för parametern @exclude_query_output, annars sprids inte felet.

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

För att kringgå det här problemet omsluter du koden för att skicka e-post till en logik för återförsök som förlitar sig på utdataparametern @mailitem_id. Om körningen misslyckas är parametervärdet NULL, vilket anger sp_send_dbmail att bör anropas en gång till för att skicka ett e-postmeddelande. Här är ett exempel på den här logiken för återförsök.

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

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

Serverförtroendegrupper används för att upprätta förtroende mellan hanterade instanser som är nödvändiga för att köra distribuerade transaktioner. När du har tagit bort den 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 se till att distribuerade transaktioner är inaktiverade och att det är användarinitierad manuell redundansväxling på den hanterade instansen.

Distribuerade transaktioner kan inte köras efter skalningsåtgärd för hanterade instanser

Skalningsåtgärder för SQL Managed Instance som omfattar ändring av tjänstnivå eller antal virtuella kärnor återställer inställningar för serverförtroendegrupp på serverdelen och inaktiverar körning av distribuerade transaktioner. Som en lösning kan du ta bort och skapa en ny serverförtroendegrupp på Azure-portalen.

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

En DNS-post <name>.database.windows.com skapas när du skapar en logisk server i Azure för Azure SQL Database och när du skapar en SQL Managed Instance. 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änstens huvudnamn 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 är 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 Azure-portalen och öppnar administratörssidan för SQL Managed Instance Active Directory. Kontrollera om du kan se felmeddelandet "Hanterad instans behöver ett tjänsthuvudnamn för att få åtkomst till Microsoft Entra-ID. Klicka här om du vill skapa ett huvudnamn för tjänsten". 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.

Begränsning av manuell redundans via portalen för redundansgrupper

Om en redundansgrupp sträcker sig över instanser i olika Azure-prenumerationer eller resursgrupper kan manuell redundans inte initieras från den primära instansen i redundansgruppen.

Lösning: Initiera redundans via portalen från den geo-sekundära instansen.

SQL Agent-roller behöver uttryckliga EXECUTE-behörigheter för icke-sysadmin-inloggningar

Om icke-sysadmin-inloggningar läggs till i sql agent-fasta databasroller finns det ett problem där explicita EXECUTE-behörigheter måste beviljas till tre lagrade procedurer i master databasen för att dessa inloggningar ska fungera. Om det här problemet uppstår visas felmeddelandet The EXECUTE permission was denied on the object <object_name> (Microsoft SQL Server, Error: 229) .

Lösning: När du har lagt till inloggningar till en fast SQL Agent-databasroll (SQLAgentUserRole, SQLAgentReaderRole eller SQLAgentOperatorRole) kör du följande T-SQL-skript för att uttryckligen bevilja EXECUTE-behörigheter till de lagrade procedurerna i listan.

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];

Minnesinterna OLTP-minnesgränser tillämpas inte

Tjänstnivån Affärskritisk tillämpar i vissa fall inte maximala minnesgränser för minnesoptimerade objekt på rätt sätt. SQL Managed Instance kan göra det möjligt för arbetsbelastningen att använda mer minne för minnesintern OLTP-åtgärder, vilket kan påverka tillgängligheten och stabiliteten för instansen. Minnesinterna OLTP-frågor som når gränserna kanske inte misslyckas omedelbart. De frågor som använder mer minnesinternt OLTP-minne misslyckas tidigare om de når gränserna.

Lösning: Övervaka minnesintern OLTP-lagringsanvändning med SQL Server Management Studio för att säkerställa att arbetsbelastningen inte använder mer än det tillgängliga minnet. Öka minnesgränserna som är beroende av antalet virtuella kärnor eller optimera arbetsbelastningen för att använda mindre minne.

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-sparad datafil med hjälp av en ALTER DATABASE REMOVE FILE instruktion returneras inte felet Msg 5042 – The file '<file_name>' cannot be removed because it is not empty omedelbart. SQL Managed Instance fortsätter att försöka släppa filen och åtgärden misslyckas efter 30 minuter med Internal server error.

Ändra tjänstnivå och skapa instansåtgärder blockeras av pågående databasåterställning

En pågående RESTORE instruktion, en migreringsprocess för datamigreringstjänsten och inbyggd återställning till tidpunkt blockerar uppdatering av en tjänstnivå eller storleksändring av den befintliga instansen och skapar 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å Affärskritisk tjänstnivå kan behöva konfigureras om efter redundansväxling

Funktionen Resource Governor 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 instansen startar om du använder Resource Governor.

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

Service Broker-dialogrutor mellan databaser slutar att leverera meddelanden till tjänsterna i andra databaser efter att åtgärden på tjänstnivå har ändrats. Meddelandena går inte förlorade och de kan hittas i avsändarkön. Ändringar av virtuella kärnor eller instanslagringsstorlekar i SQL Managed Instance gör att ett service_broke_guid värde i sys.databases-vyn ändras för alla databaser. Alla DIALOG som skapas med hjälp av en BEGIN DIALOG-instruktion som refererar till Service Brokers i andra databaser slutar leverera meddelanden till måltjänsten.

Lösning: Stoppa alla aktiviteter som använder dialogkonversationer mellan databaser i Service Broker innan du uppdaterar en tjänstnivå och initiera dem igen 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.

Lagringsutrymmet överskrids med små databasfiler

CREATE DATABASE, ALTER DATABASE ADD FILE, och RESTORE DATABASE -instruktioner kan misslyckas eftersom instansen kan nå Gränsen för Azure Storage.

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. Oanvänt utrymme på disken debiteras inte, men den totala summan av Azure Premium-diskstorlekar får inte överstiga 35 TB. I vissa fall kan en 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 klart.

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 tömma 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.

Lösning: Använd sys.databases vyn för att matcha det faktiska databasnamnet från det fysiska databasnamnet, som anges 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.

Transaktionsomfång för två databaser i samma instans stöds inte

(Löst i mars 2020) Klassen TransactionScope i .NET fungerar inte om två frågor skickas till två databaser inom samma instans under samma transaktionsomfång:

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();
}

Lösning (behövs inte sedan mars 2020): Använd Sql Anslut ion. ÄndraDatabas(Sträng) för att använda en annan databas i en anslutningskontext i stället för att använda två anslutningar.

Ingen lösning

Ö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 i avsnittet Säkerhet, Inloggningar) 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.

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

Vi har nyligen introducerat stöd för automatiska säkerhetskopieringar i msdb, men tabellen innehåller för närvarande inte användarnamnsinformation.

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 eller EXECUTE AS USER EXECUTE AS LOGIN av följande Microsoft Entra-huvudnamn stöds inte:

• Aliaserade Microsoft Entra-användare. 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 konfigureras om efter geo-redundans

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.

tempdb struktur och innehåll återskapas

Databasen tempdb är alltid uppdelad i 12 datafiler och filstrukturen kan inte ändras. Det går inte att ändra den maximala storleken per fil och nya filer kan inte läggas till i tempdb. Databasen tempdb återskapas alltid som en tom databas när instansen startar eller redundansväxlar, och eventuella ändringar som görs i tempdb bevaras inte.

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 raderas automatiskt om redundansväxling sker. Det kan finnas luckor i fellogghistoriken eftersom SQL Managed Instance har flyttats flera gånger på flera virtuella datorer.

Tillfällig instans otillgänglighet med hjälp av lyssnaren för redundanskluster under skalningsåtgärden

Skalning av hanterad instans kräver ibland att instansen flyttas till ett annat virtuellt kluster, tillsammans med de associerade tjänstunderhållna DNS-posterna. Om den 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, dvs. skrivskyddad lyssnare, 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 den 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: "Fel 40532: Det går inte att öppna servern "xxx.xxx.xxx.xxx" som begärdes vid inloggningen. Inloggningen misslyckades. (Microsoft SQL Server, Fel: 40532)".

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

Matchat

Frågekörning mot externa tabeller misslyckas med ett felmeddelande om att det inte stöds

Frågan mot den externa tabellen kan misslyckas med det allmänna felmeddelandet "Frågor över externa tabeller stöds inte med den aktuella tjänstnivån eller prestandanivån för den här databasen. Överväg att uppgradera databasens tjänst- eller prestandanivå.”. Den enda typen av extern tabell som stöds i Azure SQL Managed Instance är externa PolyBase-tabeller (i förhandsversion). Om du vill tillåta frågor i externa PolyBase-tabeller måste du aktivera PolyBase på en hanterad instans genom att köra sp_configure kommandot .

Externa tabeller som rör funktionen Elastic Query i Azure SQL Database stöds inte i SQL Managed Instance, men att skapa och köra frågor mot dem blockerades inte uttryckligen. Med stöd för externa PolyBase-tabeller har nya kontroller införts, vilket blockerar frågor om alla typer av externa tabeller i hanterad instans om inte PolyBase är aktiverat.

Om du använder externa tabeller med Elastisk fråga som inte stöds för att fråga efter data i Azure SQL Database eller Azure Synapse från din hanterade instans bör du använda funktionen Länkad server i stället. Följ anvisningarna i den här artikeln om du vill upprätta en länkad serveranslutning från SQL Managed Instance till SQL Database. Om du vill upprätta en länkad serveranslutning från SQL Managed Instance till SQL Synapse kontrollerar du stegvisa instruktioner. Eftersom det tar lite tid att konfigurera och testa en länkad serveranslutning kan du använda en tillfällig lösning för att aktivera frågor mot externa tabeller relaterade till funktionen Elastic Query:

Lösning: Kör följande kommandon (en gång per instans) som aktiverar frågor i externa tabeller:

sp_configure 'polybase enabled', 1;
GO

RECONFIGURE;
GO

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

I vissa fall kan manuell säkerhetskopiering av databaser som har gjorts på en 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å hanterade instanser med CHECKSUM aktiverat.

Agenten svarar inte vid ändring, inaktivering eller aktivering av befintliga jobb

Under vissa omständigheter kan det leda till att agenten inte svarar om du ändrar, inaktiverar eller aktiverar ett befintligt jobb. Problemet åtgärdas automatiskt vid identifiering, vilket resulterar i en omstart av agentprocessen.

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

När AZURE-rollen SQL Managed Instance-deltagare 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å.

SQL Agent-jobb kan avbrytas av omstart av agentprocessen

(Löst i mars 2020) SQL Agent skapar en ny session varje gång ett jobb startas, vilket gradvis ökar minnesförbrukningen. För att undvika att nå den interna minnesgränsen, vilket skulle blockera körning av schemalagda jobb, startas agentprocessen om när minnesförbrukningen når tröskelvärdet. Det kan leda till att körningen av jobb som körs vid omstarten avbryts.

@query parametern stöds inte i sp_send_db_mail

Parametern @query i sp_send_db_mail-proceduren fungerar inte.

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

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

"Managed Instance behöver ett tjänsthuvudnamn för att få åtkomst till Microsoft Entra-ID (tidigare Azure Active Directory). Klicka här om du vill skapa ett huvudnamn för tjänsten"

Du kan försumma det här felmeddelandet om tjänstens huvudnamn för den hanterade instansen redan finns och/eller Microsoft Entra-autentisering på den 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 Använd och skriver namnet på den 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 hanterade instansen återskapats. I så fall tilldelar du Läsbehörigheter för Microsoft Entra-ID till det nyligen skapade tjänstens huvudnamn för att Microsoft Entra-autentisering ska fungera korrekt. Detta kan göras via Azure PowerShell genom att följa anvisningarna.

Bidra med innehåll

Information om hur du bidrar till Azure SQL-dokumentationen finns i docs-deltagarguiden.

Nästa steg

En lista över uppdateringar och förbättringar av SQL Managed Instance finns i UPPDATERINGAR av SQL Managed Instance-tjänsten.

Uppdateringar och förbättringar av alla Azure-tjänster finns i Tjänstuppdateringar.