Dela via


Felsöka infrastrukturspeglingsdatabaser från Azure SQL Database

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.

  1. Kör följande fråga för att kontrollera om ändringarna flödar korrekt:

    SELECT * FROM sys.dm_change_feed_log_scan_sessions;
    
  2. sys.dm_change_feed_log_scan_sessions Om 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;
    
  3. 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_name och state. Alla värden förutom 4 indikerar ett potentiellt problem.

  4. Om replikeringen fortfarande inte fungerar kontrollerar du att rätt SAMI-objekt har behörigheter.

    1. I Infrastrukturportalen väljer du "..." ellipsalternativet för det speglade databasobjektet.
    2. Välj alternativet Hantera behörigheter .
    3. Bekräfta att namnet på den logiska Azure SQL-servern visas med läs-, skrivbehörigheter.
    4. Kontrollera att AppId som visas matchar ID:t för SAMI för din logiska Azure SQL Database-server.
  5. 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äkerhetidentitetssidan .

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.

  1. Lägg till SAMI som användare genom att välja ellipsalternativet ... på det speglade databasobjektet.
  2. Välj alternativet Hantera behörigheter .
  3. 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 FLUSHAUTHCACHE fö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.