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?
Obs
Microsoft Entra ID tidigare kallades Azure Active Directory (Azure AD).
Kända problem
Har lösning
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 att du har återställt en säkerhetskopia eller från länkfunktionen Hanterad instans:
_Msg 8992, Level 16, State 1, Line <Line_Number>an
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äkerhetskopieringar. 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-kommandon Get-AzSqlInstanceDatabaseLongTermRetentionBackup och Remove-AzSqlInstanceDatabaseLongTermRetentionBackupeller CLI-kommandon 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 parametern DatabaseState och DatabaseDeletionTime returnera värde för att filtrera säkerhetskopior för en databas.
Målet för event_file i system_health-händelsesessionen är inte tillgängligt
När du försöker läsa innehållet i event_file mål för system_health händelsesessionen 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.
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
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 Daylight-Saving Time (DST) tidszonsändring. 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 som använder berörda tidszoner återspeglar inte de ändringar som 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å OS-nivå.
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.
Ändra anslutningstyp påverkar inte anslutningar via slutpunkten för redundansgruppen
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.
Proceduren sp_send_dbmail kan misslyckas tillfälligt när @query parameter används
Proceduren sp_send_dbmail kan misslyckas tillfälligt när @query parameter används. När det här problemet uppstår misslyckas körning av proceduren sp_send_dbmail varannan gång, 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 bör 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 använder personifiering och anslutningspooler.
För att kringgå det här problemet omsluter du kod 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 att sp_send_dbmail ska anropas en gång till för att lyckas 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, vilket är nödvändigt 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 vara säker på att distribuerade transaktioner är inaktiverade och det är användarinitierad manuell redundansväxling på den hanterade instansen.
Distribuerade transaktioner kan inte köras efter en skalningsoperation av hanterade instanser
SQL Managed Instance-skalningsåtgärder 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 nya Server Trust Group 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-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ä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 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 "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.
Arbetssätt: Initiera övergång via portalen från den geo-sekundära instansen.
SQL Agent-roller behöver explicita EXECUTE-behörigheter för användare som inte är sysadmin
Om icke-sysadmin-inloggningar läggs till i någon fasta databasroller för SQL Agentfinns det ett problem där explicita EXECUTE-behörigheter måste beviljas till tre lagrade procedurer i master-databasen för att inloggningarna 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 i en fast DATABASroll för SQL Agent (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 inte korrekt maximala minnesgränser för minnesoptimerade objekt i vissa fall. SQL Managed Instance kan göra det möjligt för arbetsbelastningen att använda mer minne för minnesinterna 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 hjälp av 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 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 vid en given tidpunkt blockerar både uppdateringen av tjänstnivån och ändringen av instansens storlek samt skapandet av nya instanser tills återställningsprocessen är avslutad.
Å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å tjänstnivån Affärskritisk kan behöva rekonfigureras efter ett failover
Funktionen Resource Governor som gör att du kan begränsa de resurser som tilldelats användararbetsbelastningen kan felaktigt klassificera viss användararbetsbelastning 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-dialoger mellan databaser upphör med att leverera meddelanden till tjänsterna i andra databaser efter att tjänstenivå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 FILEoch 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. 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 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.
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=<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();
}
Lösning (behövs inte sedan mars 2020): Använd SqlConnection.ChangeDatabase(String) om du vill använda en annan databas i en anslutningskontext i stället för att använda två anslutningar.
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 automatiska säkerhetskopior av fullständig data och transaktionsloggar på den hanterade instansen, oavsett om den är i primär roll 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:
- 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:
15517och15406.
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.
tempdb struktur och innehåll återskapas
Den tempdb databasen ä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. Den tempdb databasen återskapas alltid som en tom databas när instansen startar eller växlar över till beredskapsläge, 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 automatiskt raderas om failover sker. Det kan finnas luckor i fellogghistoriken eftersom SQL Managed Instance har flyttats flera gånger på flera virtuella datorer.
Tillfällig otillgänglighet av instanser med hjälp av lyssnaren för failover-gruppen under skalningsoperationen
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 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 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 instansen medan den skalas via 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 av inloggningsprocessen. Inloggningen misslyckades. (Microsoft SQL Server, Fel: 40532)".
Problemet åtgärdas genom omdesign av skalningsåtgärden.
Löst
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.
Fråga på extern tabell misslyckas med felmeddelandet 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 tjänstnivån eller prestandanivån för databasen". 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 på externa PolyBase-tabeller måste du aktivera PolyBase på en hanterad instans genom att köra kommandot sp_configure.
Externa tabeller som rör Elastic Query- funktion i Azure SQL Database stöds inte i SQL Managed Instance, men att skapa och fråga dem blockerades inte uttryckligen. Med stöd för externa PolyBase-tabeller har nya kontroller införts, vilket blockerar frågeställning av någon typ av extern tabell i en 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. Om du vill upprätta en länkad serveranslutning från SQL Managed Instance till SQL Database följer du anvisningarna från den här artikeln. Följ stegvisa instruktioner för att upprätta en länkad serveranslutning från SQL Managed Instance till SQL Synapse. 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
(löst i juni 2020) 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äkerhetskopieringar 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 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å.
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 Agent-processen om när dess minnesanvändning når tröskelvärdet. Det kan leda till att jobb som körs vid omstarten avbryts.
@query parameter 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
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 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änstehuvudnamnet finns på Azure-portalen går du till sidan Enterprise-program, väljer Hanterade identiteter från rullgardinsmenyn Programtyp, klickar på Användoch 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änsthuvudkontot för att Microsoft Entra-autentisering ska fungera korrekt. Detta kan göras via Azure PowerShell genom att följa instruktioner.
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.