Udostępnij za pomocą

Rozwiązywanie problemów z dublowanych baz danych sieci szkieletowej z usługi Azure SQL Database

W tym artykule opisano kroki rozwiązywania problemów dotyczące dublowania usługi Azure SQL Database.

Aby uzyskać informacje na temat rozwiązywania problemów z automatycznym dublowaniem bazy danych SQL Fabric, zobacz Rozwiązywanie problemów z dublowaniem z bazy danych SQL fabric.

Zmiany pojemności lub obszaru roboczego sieci szkieletowej

Zmiany pojemności lub obszaru roboczego sieci szkieletowej mogą mieć wpływ na odbijanie. Aby uzyskać więcej informacji, zapoznaj się z efektami odbijania z Zmian pojemności sieci szkieletowej.

Rozwiązywanie problemów z usługą Azure SQL Database

Przyczyna Wynik Zalecane rozwiązanie
Obszar roboczy został usunięty Dublowanie zatrzymuje się automatycznie i wyłącza zestawienie zmian w usłudze Azure SQL Database W przypadku, gdy dublowanie jest nadal aktywne w usłudze Azure SQL Database, wykonaj następującą procedurę składowaną w usłudze Azure SQL Database: exec sp_change_feed_disable_db;.
Trwałe błędy Dublowanie jest wyłączone dla bazy danych, której dotyczy problem Aby upewnić się, że zasoby obliczeniowe nie mają wpływu i aby chronić źródłową usługę Azure SQL Database, dublowanie zostanie wyłączone w przypadku wszelkich trwałych błędów. Przejrzyj sys.dm_change_feed_errors i rozwiąż podstawowe błędy przed ponownym włączeniem bazy danych do mirroringu.
Ustawienie "Użytkownicy mogą uzyskiwać dostęp do danych przechowywanych w usłudze OneLake za pomocą aplikacji spoza sieci szkieletowej" wyłączone "Replikator — tabele nie mogą osiągnąć stanu replikowania" Włącz ustawienie Dzierżawa Użytkownicy mogą uzyskiwać dostęp do danych przechowywanych w usłudze OneLake za pomocą aplikacji zewnętrznych niż sieć szkieletowa.

Aby uzyskać dodatkowe scenariusze rozwiązywania problemów, zobacz Rozwiązywanie problemów z baz danych z odbiciem lustrzanym Fabric — Microsoft Fabric.

Zapytania T-SQL dotyczące rozwiązywania problemów

Jeśli występują problemy z dublowaniem, wykonaj następujące kontrole na poziomie bazy danych przy użyciu dynamicznych widoków zarządzania (DMV) i procedur składowanych w celu zweryfikowania konfiguracji.

  1. Wykonaj następujące zapytanie, aby sprawdzić, czy zmiany są prawidłowo przepływane:

    SELECT * FROM sys.dm_change_feed_log_scan_sessions;

  2. sys.dm_change_feed_log_scan_sessions Jeśli widok DMV nie pokazuje postępu przetwarzania zmian przyrostowych, wykonaj następujące zapytanie T-SQL, aby sprawdzić, czy występują jakieś problemy:

    SELECT * FROM sys.dm_change_feed_errors;

  3. Jeśli nie zgłoszono żadnych problemów, wykonaj następującą procedurę składowaną, aby przejrzeć bieżącą konfigurację dublowanej bazy danych Azure SQL Database. Upewnij się, że została prawidłowo włączona.

    EXEC sp_help_change_feed;

    Kluczowe kolumny do wyszukania w tym miejscu to i table_namestate. Każda wartość oprócz 4 wskazuje potencjalny problem.

  4. Jeśli replikacja nadal nie działa, sprawdź, czy prawidłowy obiekt tożsamości zarządzanej ma uprawnienia.

    1. W portalu sieci szkieletowej wybierz pozycję "..." Opcja wielokropka w elemencie dublowanej bazy danych.
    2. Wybierz opcję Zarządzaj uprawnieniami .
    3. Upewnij się, że nazwa tożsamości zarządzanej jest wyświetlana z uprawnieniami do odczytu i zapisu.
    4. Upewnij się, że identyfikator AppId, który jest wyświetlany, jest zgodny z identyfikatorem tożsamości zarządzanej serwera logicznego usługi Azure SQL Database.

  5. Skontaktuj się z pomocą techniczną , jeśli jest wymagane rozwiązywanie problemów.

Tożsamość zarządzana

Należy włączyć tożsamość zarządzaną przypisaną przez system (SAMI) lub tożsamość zarządzaną przypisaną przez użytkownika (UAMI) serwera logicznego usługi Azure SQL, a jedna z nich musi być tożsamością podstawową.

Uwaga / Notatka

Obsługa tożsamości zarządzanej przypisanej przez użytkownika (UAMI) jest obecnie dostępna w wersji zapoznawczej.

Sprawdź poprawną tożsamość podstawową przy użyciu następującego zapytania Transact-SQL:

SELECT * FROM sys.dm_server_managed_identities;

Aby uzyskać więcej informacji, zobacz Tworzenie serwera usługi Azure SQL Database.

Uprawnienia dla tożsamości zarządzanych

Zarówno tożsamość zarządzana przypisana przez system (SAMI), jak i tożsamość zarządzana przypisana przez użytkownika (UAMI) dla serwera logicznego Azure SQL muszą mieć uprawnienia odczytu i zapisu w elemencie zreplikowanej bazy danych w usłudze Microsoft Fabric.

Po utworzeniu dublowanej bazy danych z portalu sieci szkieletowej uprawnienie zostanie przyznane automatycznie. Jeśli podczas instalacji wystąpi błąd Unable to grant required permission to the source server. User does not have permission to reshare , upewnij się, że masz rolę członka lub administratora w obszarze roboczym z wystarczającymi uprawnieniami. Jeśli używasz interfejsu API lub CI/CD do tworzenia bazy danych lustrzanych, upewnij się, że jawnie udzielono uprawnień.

Nie usuwaj uprawnień SAMI i/lub UAMI odczytu i zapisu na elementy baz danych zdublowane za pomocą technologii Fabric. Jeśli przypadkowo usuniesz uprawnienia, replikacja bazy danych Azure SQL Database nie działa zgodnie z oczekiwaniami. Nie można dublować nowych danych ze źródłowej bazy danych.

Jeśli usuniesz uprawnienia SAMI i/lub UAMI usługi Azure SQL Database albo uprawnienia nie zostaną poprawnie skonfigurowane, zapoznaj się z krokami opisanymi w sekcji samouczka, aby ją skonfigurować.

Błędy z nieaktualnych uprawnień przy użyciu identyfikatorów logowania firmy Microsoft Entra

Przed rozpoczęciem korzystania z uwierzytelniania identyfikatora Entra firmy Microsoft zapoznaj się z ograniczeniami w podmiotach zabezpieczeń serwera Microsoft Entra.

Użytkownicy bazy danych tworzeni za pomocą logowań Microsoft Entra mogą doświadczyć opóźnień podczas przyznawania ról i uprawnień. Może to spowodować błąd, taki jak następujący w portalu Fabric:

"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: ..."

W bieżącej wersji zapoznawczej należy użyć następujących poleceń, aby rozwiązać te problemy.

  • Usuń użytkownika z bazy danych użytkownika.
  • Wykonaj polecenie DBCC FREESYSTEMCACHE('TokenAndPermUserStore') , aby wyczyścić pamięci podręczne zabezpieczeń w bazie danych.
  • Wykonaj polecenie DBCC FLUSHAUTHCACHE , aby wyczyścić pamięć podręczną kontekstu uwierzytelniania federacyjnego.
  • W bazie danych użytkownika utwórz ponownie użytkownika na podstawie identyfikatora logowania.

Użycie dziennika transakcji

Użycie dziennika transakcji dla bazy danych włączonej do mirroringu może nadal rosnąć i blokować obcinanie dziennika. Gdy rozmiar dziennika transakcji osiągnie maksymalny zdefiniowany limit, zapisy w bazie danych kończą się niepowodzeniem. W celu ochrony przed tym funkcja dublowania wyzwala automatyczne ponowne przeniesienie całej bazy danych, gdy używane miejsce w dzienniku przekracza próg całkowitej skonfigurowanej przestrzeni dziennika. Aby zdiagnozować ten problem i dowiedzieć się więcej o automatycznym ponownym zasiewaniu, zobacz Automatyczne ponowne zasiewanie dla lustrzanych baz danych Fabric w usłudze Azure SQL Database.

Automatyczne rozpoczęcie ponownego zasiewu

Dublowanie sieci szkieletowej z usługi Azure SQL Database może być automatycznie przenoszone w określonych warunkach na poziomie pojedynczej tabeli lub dla całej bazy danych. Aby dowiedzieć się więcej, automatyczne ponowne tworzenie kopii danych dla dublowanych baz danych sieci szkieletowej z usługi Azure SQL Database.

Treści powiązane

  • Last updated on