In het vorige artikel, SQL Server-replicatie instellen en configureren, hebben we diepgaand gesproken over het concept van SQL Server-replicatie, de componenten, typen en hoe u de SQL-transactiereplicatie stap voor stap kunt configureren. Het wordt ten zeerste aanbevolen om het vorige artikel door te nemen en het replicatieconcept en de componenten ervan te begrijpen voordat u dit artikel leest. In dit artikel zullen we zien hoe u problemen met een bestaande SQL Server-replicatiesite kunt oplossen.
Overzicht probleemoplossing
Het belangrijkste doel van de SQL Server-replicatie is om de gegevens in de Publisher en de Subscriber gesynchroniseerd te houden. In het gelukkige scenario, als een transactie wordt uitgevoerd en vastgelegd in de publicatiedatabase, wordt deze gekopieerd naar de distributiedatabase en vervolgens gesynchroniseerd en toegepast op alle abonnees die zijn verbonden met die uitgever. Als er zich een probleem voordoet bij een van de stappen van dit proces, zijn de wijzigingen voor de uitgever niet beschikbaar aan de kant van de abonnee. In dit geval moeten we dat probleem zo snel mogelijk oplossen en oplossen voordat we eindigen met een verlopen SQL-replicatiesite die helemaal opnieuw moet worden gesynchroniseerd of een database met zijn transactielogbestand onvoldoende vrije ruimte heeft, waardoor alle databasetransacties worden onderbroken .
Het identificeren bij welke stap de replicatiesynchronisatie mislukt en het toewijzen van een indicatief foutbericht dat leidt tot het oplossen van het probleem, is het meest uitdagende onderdeel van het probleemoplossingsproces van SQL Server-replicatie. Ook het controleren van de laatste synchronisatietijd en welke wijzigingen zijn uitgevoerd op/na die tijd die deze fout kunnen veroorzaken, kan ook helpen bij het oplossen van problemen met de replicatiesynchronisatie.
Als u de rol van de SQL Server-replicatieagent begrijpt, kunt u bepalen bij welke stap de synchronisatie mislukt. Bedenk dat er drie replicatieagenten zijn die de meeste SQL Server-replicatietypen gemeen hebben. De Momentopname-agent is verantwoordelijk voor het maken van de initiële synchronisatiemomentopname. De Log Reader-agent is verantwoordelijk voor het lezen van de wijzigingen uit het databasetransactielogbestand en kopieer het naar de distributiedatabase en tot slot de Distributie agent die verantwoordelijk is voor het synchroniseren van de wijzigingen aan de Abonnees.
In dit artikel maken we gebruik van de Replicatiemonitor en Job Activity Monitor windows bij het bewaken van de SQL Server-replicatiestatus en het verkrijgen van informatie over fouten bij synchronisatiefouten.
Scenario's voor probleemoplossing
De beste en duidelijke manier om te begrijpen hoe u problemen met SQL Server-replicatie kunt oplossen, is door praktische scenario's te bieden en te laten zien hoe u dit specifieke probleem kunt oplossen. Laten we de scenario's een voor een gaan bespreken.
SQL Server Agent-serviceprobleem
De SQL Server Agent-service speelt een cruciale rol in het synchronisatieproces van SQL Server Replication. Dit komt door het feit dat elke replicatieagent onder een SQL-agenttaak wordt uitgevoerd.
Als proactieve databasebeheerder moet u de status van de SQL-replicatiesite dagelijks controleren. Om de status van de replicatiesite te controleren, klikt u met de rechtermuisknop op de publicatie onder het knooppunt Replicatie -> Lokale publicaties en kiest u de Replicatiemonitor starten optie, zoals hieronder getoond:
In het venster Replicatiemonitor kunt u een waarschuwingsbericht zien dat aangeeft dat de replicatie binnenkort verloopt of al is verlopen, zonder een indicatieve foutmelding te zien, zoals hieronder:
Als het venster Replicatiemonitor ons geen bruikbare informatie geeft over waarom de replicatiesite binnenkort verloopt, is de volgende stap het controleren van de Job Activity Monitor onder het SQL Server Agent-knooppunt. Als u het SQL Server Agent-knooppunt bezoekt, ziet u direct dat de SQL Server Agent-service niet actief is (van de rode cirkel ernaast). Als de SQL Server Agent-service niet actief is, betekent dit dat alle taken die onder die instantie zijn gemaakt, niet werken, inclusief de taken van de replicatieagent. Als gevolg hiervan werkt de algemene replicatiesite niet.
Om dat probleem op te lossen, moeten we de SQL Server Agent-service rechtstreeks starten vanuit de SQL Server Management Studio of met behulp van de SQL Server Configuration Manager (aanbevolen), zoals hieronder weergegeven:
Controleer na het starten van de SQL Server Agent-service de Replicatiemonitor opnieuw en zorg ervoor dat de abonneestatus In werking is en alle lopende transacties worden met succes gesynchroniseerd met de Abonnee. U kunt deze stappen een voor een controleren door te controleren of de records zijn gekopieerd van het gedeelte Uitgever naar Distributeur:
Vervolgens succesvol gesynchroniseerd van de distributeur naar de abonnee, zoals hieronder:
En zorg er ten slotte voor dat er geen niet-verdeelde transactie is van het laatste tabblad, zoals hieronder weergegeven:
Daarna moeten we ervoor zorgen dat de taken van de replicatieagenten probleemloos werken. De SQL Agent-taken kunnen worden gecontroleerd door de SQL Server Agent-node onder de SSMS Object Explorer uit te vouwen en de taakactiviteitsmonitor te bekijken en vervolgens te controleren of de Log Reader Agent en Distributor-agent actief zijn, rekening houdend met het feit dat de Snapshot Agent alleen zal werken tijdens de proces voor het maken van snapshots, zoals hieronder weergegeven:
U kunt ook de geschiedenis van de taken van de replicatieagenten bekijken en de reden van de vorige fout controleren door met de rechtermuisknop op die taak te klikken en Geschiedenis bekijken te kiezen. optie zoals hieronder:
Waar u een indicatieve foutmelding kunt vinden die helpt bij het oplossen van dit probleem in de toekomst, zoals hieronder:
Om het vorige probleem te verhelpen, moet de opstartmodus van de SQL Server Agent-service worden gewijzigd van Handmatig in Automatisch, op deze manier zorgt u ervoor dat de service automatisch start wanneer de hostingserver opnieuw wordt opgestart.
Kwestie van machtiging voor momentopname agent
Stel dat u bij het controleren van de SQL Server-replicatiestatus met behulp van de Replicatiemonitor hebt opgemerkt dat er een replicatiefout is opgetreden aan het X-teken in de rode cirkel. En de Replicatiemonitor laat zien dat de fout afkomstig is van een van de replicatie-agents, van het X-teken in de rode cirkel boven aan het tabblad Agents.
Om die replicatiefout te identificeren, moeten we door het tabblad Agenten bladeren en controleren welke agent niet werkt. Op de pagina Agenten ziet u dat de Snapshot Agent de falende is. Dubbelklik op de Snapshot Agent en bekijk de onderstaande foutmelding:
De replicatieagent heeft binnen 10 minuten geen voortgangsbericht vastgelegd. Dit kan duiden op een niet-reagerende agent of hoge systeemactiviteit. Controleer of de records naar de bestemming worden gerepliceerd en of de verbindingen met de abonnee, uitgever en distributeur nog steeds actief zijn.
Helaas is deze foutmelding generiek en geeft alleen aan dat de Snapshot Agent niet werkt zonder de reden op te geven, als volgt:
Dan moeten we op een andere plaats naar nuttige informatie zoeken, namelijk de Snapshot Agent-taak. In het venster Job Activity Monitor, onder het SQL Server Agent-knooppunt, kunt u zien dat de Snapshot Agent-taak is mislukt. En uit die taakgeschiedenis kunt u zien dat het onlangs is mislukt vanwege het proxy-authenticatieprobleem. Met andere woorden, de inloggegevens voor het account waaronder de Snapshot Agent draait zijn niet correct, zoals hieronder getoond:
Om het probleem met de inloggegevens van de Snapshot Agent op te lossen, klikt u met de rechtermuisknop op de publicatie, onder het knooppunt Replicatie -> Lokale publicatie, en kiest u de Eigenschappen optie. Blader in het venster Publicatie-eigenschappen door Agent Security pagina en voer de inloggegevens opnieuw in voor het account waaronder de Snapshot Agent zal worden uitgevoerd.
Na het vernieuwen van de Snapshot Agent-accountgegevens, start u de Snapshot Agent-taak opnieuw vanuit het venster Taakactiviteitmonitor en controleert u of de taak goed werkt, zoals hieronder:
Controleer ook of de Snapshot Agent nu goed werkt en de foutmelding niet meer verschijnt onder de Replicatiemonitor, zoals hieronder weergegeven:
Kwestie van machtiging voor momentopnamemap
Neem aan dat, wanneer u probeert de uitgever en de abonnee te synchroniseren met behulp van de initiële momentopname of de replicatiesite van de momentopname opnieuw te synchroniseren met een nieuwe momentopname, het proces voor het maken van de momentopname is mislukt met het onderstaande toegangsfoutbericht:
Deze foutmelding laat zien dat het account waaronder de Snapshot Agent draait geen toestemming heeft om de snapshot-map te openen die in het foutbericht is gespecificeerd.
Om dat probleem op te lossen, moeten we het account waarop de Snapshot Agent draait, controleren vanaf de Agent Security-pagina van het venster Publicatie-eigenschappen, zoals hieronder weergegeven:
Blader vervolgens door de snapshot-map die is opgegeven in het foutbericht en zorg ervoor dat dit Snapshot-account minimale lees-schrijfrechten heeft voor die map, voer vervolgens de Snapshot Agent opnieuw uit en kijk of het probleem nu is opgelost en de synchronisatie-snapshot is gemaakt, zoals hieronder:
Kwestie van machtiging van abonnee
Stel dat u bij het controleren van de status van de SQL Server-replicatiesite met behulp van de Replicatiemonitor ziet dat er een storing is met de abonnee, zoals hieronder wordt weergegeven:
Als u op het foutpictogram klikt, ziet u dat de fout is opgetreden bij het synchroniseren van de transacties van de distributeur naar de abonnee. En uit de foutmelding blijkt duidelijk dat de distributeur geen verbinding kan maken met de SQL Server-instantie van de abonnee vanwege een machtigingsprobleem, zoals hieronder wordt weergegeven:
Om dat probleem op te lossen, moeten we de inloggegevens controleren en vernieuwen die zijn gebruikt om verbinding te maken met de abonnee-instantie. Om de inloggegevens te controleren, klikt u met de rechtermuisknop op het abonnement onder het knooppunt Replicatie -> Lokale publicaties -> de huidige publicatienaam en kiest u de optie Eigenschappen. Van de Abonneeverbinding veld onder het venster Abonnee-eigenschappen, vernieuw de inloggegevens voor het account dat wordt gebruikt om verbinding te maken met de abonnee-instantie, zoals hieronder weergegeven:
Controleer daarna de replicatiestatus opnieuw vanuit de Replicatiemonitor en u zult zien dat het probleem met de abonneeverbinding niet langer beschikbaar is en dat de replicatiesite normaal werkt, zoals hieronder weergegeven:
Abonnee niet bereikbaar
Een ander probleem met het mislukken van SQL Server-replicatie waarmee u te maken kunt krijgen vanaf de kant van de abonnee, is dat de distributeur geen verbinding kan maken met de abonnee. Gerelateerd … ” verbindingsfout, weergegeven in het venster Replicatiemonitor hieronder:
Dit foutbericht geeft aan dat er een verbindingsprobleem is tussen de Distributor-instantie en de Abonnee-instantie. De eerste en eenvoudige manier om dit verbindingsprobleem te controleren, is ervoor te zorgen dat de SQL Server-instantie van de abonnee online is. Dit kan worden gecontroleerd vanuit de SQL Server Configuration Manager aan de kant van de abonnee. In onze situatie kunnen we zien dat de SQL Server-service aan de kant van de abonnee is gestopt. Om dat probleem op te lossen, start u de SQL Server-service en controleert u vanuit de Replicatiemonitor of de replicatiesite opnieuw is gesynchroniseerd, zoals hieronder wordt weergegeven. Raadpleeg voor meer geavanceerde SQL-connectiviteitsproblemen het MS-document Problemen met connectiviteit oplossen:
Kwestie van machtiging van abonneedatabase
Stel dat u de synchronisatiestatus van de SQL Server-replicatie controleert met behulp van de Replicatiemonitor en dat de replicatie mislukt terwijl u probeert de wijzigingen van de distributeur naar de abonnee te repliceren. Als u op de abonneefout klikt, ziet u dat de De distributeur kan de abonnee bereiken en er verbinding mee maken, maar kan geen verbinding maken met de abonnementsdatabase vanwege een gebrek aan toestemming, zoals hieronder wordt weergegeven:
Om dat probleem op te lossen, maakt u verbinding met de abonnee en zorgt u ervoor dat het account dat wordt gebruikt om verbinding te maken met de abonneedatabase lid is van de vaste rol van de database db_Owner, zoals hieronder weergegeven:
Controleer daarna de replicatiemonitor opnieuw en zorg ervoor dat de distributeur de abonnementsdatabase kan bereiken en de wijzigingen kan repliceren, zoals hieronder:
Gegevensverschilprobleem
Stel dat een van de database-ontwikkelingsteams beweert dat er enkele wijzigingen zijn die zijn uitgevoerd in de Shifts-tabel op de Publisher (SQL1), niet worden weerspiegeld in de dagelijkse rapporten die worden uitgevoerd op de Subscriber-instantie (SQL2), en hij heeft de onderstaande momentopname geleverd waaruit blijkt dat de wijzigingen niet worden gerepliceerd:
De eerste stap bij het controleren van het replicatiesynchronisatieprobleem is het openen van de Replicatiemonitor en uitzoeken bij welke stap het niet werkt. Vanuit de Replicatiemonitor kunt u zien dat de Log Reader-agent faalt, omdat de wijzigingen niet worden gerepliceerd van de distributeur naar de abonnee, maar er wordt geen duidelijk bericht teruggestuurd van die agent, zoals hieronder wordt weergegeven:
Aangezien we geen zinvolle foutmelding kunnen vinden in de Replicatiemonitor, zullen we de geschiedenis van de Log Reader Agent-taak controleren met behulp van de Job Activity Monitor, waaruit blijkt dat de referenties voor het account waaronder de Log Reader Agent wordt uitgevoerd, onjuist zijn , zoals hieronder weergegeven:
Om het probleem met de Log Reader Agent-inloggegevens op te lossen, bladert u door de Agent Security-pagina van het venster Publicatie-eigenschappen en vernieuwt u de Log Reader Agent-referenties met een geldige, zoals hieronder:
Als u de Replicatiemonitor nogmaals controleert, ziet u dat de wijzigingen met succes zijn gerepliceerd en dat de gegevens worden bijgewerkt met de nieuwe ploegwijzigingen, zoals hieronder weergegeven:
Rij niet gevonden bij abonnee
Laten we de kwestie van een andere kant bekijken. Laten we zeggen dat er een wijziging is uitgevoerd in de ploegentabel zoals hieronder weergegeven:
Maar deze wijziging wordt niet gerepliceerd naar de abonnee en de algehele SQL Server-replicatiesite is mislukt. Vanuit de Replicatiemonitor kunt u zien dat het faalt terwijl u probeert de wijziging aan te brengen van de distributeur naar de abonnee, en is mislukt vanwege het feit dat het niet in staat is om dat specifieke record bij te werken met ID gelijk aan 3, omdat dit record is niet beschikbaar in de abonneedatabasetabel, zoals hieronder weergegeven:
Als u dat record aan de abonneezijde (SQL2) controleert, ziet u dat het record niet beschikbaar is, zoals hieronder:
Om dit probleem op te lossen, moeten we dat record opnieuw invoegen in de databasetabel van de abonnee en de distributeur laten proberen het opnieuw bij te werken, om het probleem met de replicatiesynchronisatie te verhelpen, zoals hieronder weergegeven:
SQL Server biedt ons een optie om de replicatiesite te laten werken, ook al is er een probleem met inconsistenties in de gegevens, waar u dit probleem later handmatig kunt oplossen. Klik hiervoor vanuit de Replicatiemonitor met de rechtermuisknop op de abonnee en kies Agentprofiel optie, zoals hieronder getoond:
Vanuit het weergegeven venster kunt u het Log Reader Agent-profiel bijwerken en toestaan dat het gegevenswijzigingen blijft repliceren in het geval er een probleem is met inconsistenties in de gegevens, zoals hieronder weergegeven:
Probleem met niet-geïnitialiseerd abonnement
Als de replicatiesite lange tijd niet wordt gecontroleerd en er gedurende meer dan drie dagen een fout is opgetreden zonder enige oplossing, is de replicatiesite verlopen en wordt het abonnement gemarkeerd als niet-geïnitialiseerd, wachtend om opnieuw te worden geïnitialiseerd met een nieuwe momentopname . Hetzelfde scenario kan zich voordoen bij het aanmaken van een nieuw abonnement zonder het te initialiseren, zoals hieronder weergegeven:
Om dat probleem op te lossen, moeten we dat abonnement opnieuw initialiseren door met de rechtermuisknop op het abonnement te klikken onder het knooppunt Replicatie -> Lokale publicaties en de publicatie uit te vouwen, vervolgens de optie Opnieuw initialiseren te kiezen en dit abonnement te markeren voor initialisatie en het gereed te maken voor het ontvangen van een nieuw momentopname, zoals hieronder weergegeven:
Als de abonnementsstatus niet-geïnitialiseerd blijft nadat deze opnieuw is geïnitialiseerd, controleert u de Snapshot Agent-taak met behulp van het venster Taakactiviteitenmonitor en ziet u waarom deze mislukt. In de taakgeschiedenis van Snapshot Agent ziet u dat de taak is mislukt vanwege een probleem bij het bepalen van de eigenaar van die agenttaak, zoals hieronder weergegeven:
Om dit probleem op te lossen, opent u de taak Snapshot Agent en wijzigt u de eigenaar van de taak in SA of een geldige beheerder, en de taak wordt succesvol uitgevoerd, zoals hieronder:
Nu zult u zien dat de abonnementsstatus is gewijzigd in Actief, aangezien het wacht op de eerste momentopname om het synchronisatieproces te starten, zoals hieronder weergegeven:
Om een nieuwe momentopname te genereren, klikt u met de rechtermuisknop op de publicatie onder het knooppunt Replicatie -> Lokale publicaties en selecteert u Status momentopnameagent bekijken optie.
Klik in het geopende venster op de knop Start om het proces voor het maken van de snapshot te starten. Wanneer de snapshot die alle Publisher-artikelen bevat die met succes zijn gemaakt, de Replicatiemonitor opnieuw opent en de status van het Abonnement controleert, waar u zult zien dat de snapshot wordt toegepast op de Abonnee en wordt gesynchroniseerd met de Publisher, zoals hieronder weergegeven:
Probleem met eigenaar van uitgeversdatabase
Neem ook aan dat bij het controleren van de status van de SQL Server-replicatiesite met behulp van de Replicatiemonitor, de replicatiesite is mislukt en de fout is gedetecteerd bij de Log Reader Agent. Bij het controleren van het foutbericht dat door die agent is geretourneerd, is gebleken dat er een probleem is bij het bepalen van de huidige eigenaar van de publicatiedatabase, zoals hieronder weergegeven:
Om dat probleem op te lossen, moeten we de huidige eigenaar van de publicatiedatabase bijwerken door deze te vervangen door een geldige databasegebruiker, met behulp van de SP_changedbowner systeem opgeslagen procedure, of gewoon vanuit het database-eigenschappenvenster. Voer daarna de taak Logboeklezer Agent opnieuw uit met behulp van het venster Taakactiviteitenmonitor en valideer vervolgens of het agentprobleem niet langer beschikbaar is met behulp van de Replicatiemonitor, zoals hieronder weergegeven:
Conclusie
In dit artikel hebben we verschillende problemen gedemonstreerd die u kunt tegenkomen bij het gebruik van de SQL Server-replicatiefunctie om gegevens tussen verschillende sites te kopiëren, en hoe u deze problemen kunt oplossen.
Het wordt ten zeerste aanbevolen om de SQL Server-engine up-to-date te houden, met de nieuwste SP's en CU's, zodat alle bugs met betrekking tot de SQL Server-replicatiefuncties automatisch worden opgelost. Ten slotte, houd als proactieve SQL Server-databasebeheerder uw replicatiesite in de gaten om elk probleem vanaf het begin op te lossen voordat het groter en moeilijker op te lossen wordt.