Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
I den här artikeln beskrivs felsökningssteg för spegling av Azure SQL Database.
Information om hur du felsöker den automatiskt konfigurerade speglingen för Fabric SQL-databasen finns i Felsöka spegling från Fabric SQL-databasen (förhandsversion).
Ändringar i Fabric-kapacitet eller arbetsytor
Ändringar i Fabric-kapaciteten eller arbetsytan kan påverka speglingen. För mer information, granska effekterna av spegling från ändringar i Fabric-kapacitet.
Felsökning av Azure SQL Database
| Orsak | Result | Rekommenderad lösning |
|---|---|---|
| Arbetsytan har tagits bort | Spegling stoppas automatiskt och inaktiverar ändringsflödet i Azure SQL Database | Om spegling fortfarande är aktiv i Azure SQL Database kör du följande lagrade procedur i Azure SQL Database: exec sp_change_feed_disable_db;. |
| Beständiga fel | Spegling är inaktiverat | För att säkerställa att dina beräkningsresurser inte påverkas och för att skydda din Azure SQL Database-källa kan spegling inaktiveras vid eventuella beständiga fel. Granska sys.dm_change_feed_errors och lös de underliggande felen innan du återaktiverar tabellen för spegling. |
| Inställningen "Användare kan komma åt data som lagras i OneLake med appar utanför Fabric" inaktiverad | "Replikator – tabeller kan inte nå replikeringsstatus" | Aktivera hyresgästsinställningen Användare kan komma åt data som lagras i OneLake med appar utanför Fabric. |
Ytterligare felsökningsscenarier finns under Felsöka Fabric-speglingsdatabaser – Microsoft Fabric.
T-SQL-frågor för felsökning
Om du har speglingsproblem utför du följande kontroller på databasnivå med hjälp av dynamiska hanteringsvyer (DMV:er) och lagrade procedurer för att verifiera konfigurationen.
Kör följande fråga för att kontrollera om ändringarna flödar korrekt:
SELECT * FROM sys.dm_change_feed_log_scan_sessions;sys.dm_change_feed_log_scan_sessionsOm DMV inte visar några framsteg vid bearbetning av inkrementella ändringar kör du följande T-SQL-fråga för att kontrollera om det finns några rapporterade problem:SELECT * FROM sys.dm_change_feed_errors;Om inga problem rapporteras kör du följande lagrade procedur för att granska den aktuella konfigurationen av den speglade Azure SQL Database. Bekräfta att den har aktiverats korrekt.
EXEC sp_help_change_feed;De nyckelkolumner som ska sökas efter här är
table_nameochstate. Alla värden förutom4indikerar ett potentiellt problem.Om replikeringen fortfarande inte fungerar kontrollerar du att rätt SAMI-objekt har behörigheter.
- I Infrastrukturportalen väljer du "..." ellipsalternativet för det speglade databasobjektet.
- Välj alternativet Hantera behörigheter .
- Bekräfta att namnet på den logiska Azure SQL-servern visas med läs-, skrivbehörigheter.
- Kontrollera att AppId som visas matchar ID:t för SAMI för din logiska Azure SQL Database-server.
Kontakta supporten om felsökning krävs.
Hanterad identitet
Den systemtilldelade hanterade identiteten (SAMI) för den logiska Azure SQL-servern måste vara aktiverad och måste vara den primära identiteten. Mer information finns i Skapa en Azure SQL Database-server. Aktivera SAMI i Azure-portalen på resursmenyn under Säkerhet på identitetssidan .
Om statusen för SAMI-inställningen antingen är inaktiverad eller aktiverad från början, inaktiveras och sedan aktiveras igen, misslyckas speglingen av Azure SQL Database till Fabric OneLake efter aktiveringen.
SAMI måste vara den primära identiteten. Kontrollera att SAMI är den primära identiteten med följande T-SQL-skript: SELECT * FROM sys.dm_server_managed_identities;
Användartilldelad hanterad identitet (UAMI) stöds inte. Om du lägger till en UAMI blir den den primära identiteten och ersätter SAMI som primär. Detta gör att replikeringen misslyckas. Så här löser du följande:
- Ta bort alla UAMIs. Kontrollera att SAMI är aktiverat.
SAMI-behörigheter
Den systemtilldelade hanterade identiteten (SAMI) för den logiska Azure SQL-servern måste ha läs- och skrivbehörighet för det speglade databasobjektet i Microsoft Fabric. När du skapar den speglade databasen från Fabric-portalen beviljas behörigheten automatiskt. Om du får fel Unable to grant required permission to the source server. User does not have permission to reshare under installationen kontrollerar du att du har en medlems- eller administratörsroll på arbetsytan med tillräcklig behörighet. När du använder API :et för att skapa den speglade databasen måste du uttryckligen bevilja behörigheten.
Ta inte bort läs - ochskrivbehörigheterna för SAMI för infrastrukturresursens speglade databasobjekt. Om du av misstag tar bort behörigheterna fungerar inte spegling av Azure SQL Database som förväntat. Inga nya data kan speglas från källdatabasen.
Om du tar bort Azure SQL Database SAMI-behörigheter eller behörigheter inte har konfigurerats korrekt använder du följande steg.
- Lägg till SAMI som användare genom att välja ellipsalternativet
...på det speglade databasobjektet. - Välj alternativet Hantera behörigheter .
- Ange namnet på den logiska Azure SQL Database-servernamnet. Ange läs- och skrivbehörigheter .
Fel från inaktuella behörigheter med Microsoft Entra-inloggningar
Granska begränsningarna i Microsoft Entra-serverobjekt innan du använder Microsoft Entra-ID-autentisering.
Databasanvändare som skapats med Microsoft Entra-inloggningar kan uppleva fördröjningar när de beviljas roller och behörigheter. Detta kan resultera i ett fel, som följande i Fabric-portalen:
"The database cannot be mirrored to Fabric due to below error: Unable to retrieve SQL Server managed identities. A database operation failed with the following error: 'VIEW SERVER SECURITY STATE permission was denied on object 'server', database 'master'. The user does not have permission to perform this action.' VIEW SERVER SECURITY STATE permission was denied on object 'server', database 'master'. The user does not have permission to perform this action. SqlErrorNumber=300,Class=14,State=1, Activity ID: ..."
Under den aktuella förhandsversionen ska följande kommandon användas för att åtgärda dessa problem.
- Släpp användaren från användardatabasen.
- Kör
DBCC FREESYSTEMCACHE('TokenAndPermUserStore')för att rensa säkerhetscacheminnen i databasen. - Kör
DBCC FLUSHAUTHCACHEför att rensa cachen för federerad autentiseringskontext. - I användardatabasen skapar du användaren igen baserat på inloggningen.
Användning av transaktionslogg
Användningen av transaktionsloggen för en databas aktiverad för databasåterspegling kan fortsätta att växa och förhindra loggtrunkering. När transaktionsloggens storlek når den maximala definierade gränsen misslyckas skrivningar till databasen. För att skydda mot detta utlöser speglingen en automatisk ominitiering av hela databasen när det använda loggutrymmet överskrider ett tröskelvärde för det totalt konfigurerade loggutrymmet. För att diagnostisera detta och lära dig mer om automatisk återsådd, se Automatisk återsådd för Fabric-speglade databaser från Azure SQL Database.
Omseedning har påbörjats automatiskt
Infrastrukturspegling från Azure SQL Database kan automatiskt återställas under vissa förhållanden, på enskild tabellnivå eller för hela databasen. Mer information finns i Automatisk återställning för infrastrukturspeglingsdatabaser från Azure SQL Database.