I den forrige artikel, Opsætning og konfiguration af SQL Server-replikering, diskuterede vi i dybden, SQL Server-replikeringskonceptet, dets komponenter, typer og hvordan man konfigurerer SQL Transactional Replication trin for trin. Det anbefales stærkt at gennemgå den forrige artikel og forstå replikeringskonceptet og dets komponenter, før du læser denne artikel. I denne artikel vil vi se, hvordan du fejlfinder et eksisterende SQL Server-replikeringssted.
Fejlfindingsoversigt
Hovedmålet med SQL Server-replikeringen er at holde dataene i udgiveren og abonnenten synkroniseret. I det lykkelige scenarie, hvis en transaktion udføres og begås i udgivelsesdatabasen, vil den blive kopieret til distributionsdatabasen og derefter synkroniseret og anvendt på alle abonnenter, der er forbundet til den pågældende udgiver. Hvis der opstår et problem på et hvilket som helst trin i denne proces, vil udgiverændringerne ikke være tilgængelige på abonnentsiden. I dette tilfælde er vi nødt til at fejlfinde og rette det problem så hurtigt som muligt, før vi ender med et udløbet SQL-replikeringssted, der skal synkroniseres igen fra bunden, eller en database med dens transaktionslogfil løber tør for ledig plads, hvilket sætter alle databasetransaktioner på pause .
At identificere, på hvilket trin replikeringssynkroniseringen mislykkes, og tildele en vejledende fejlmeddelelse, der fører til at løse problemet, er den mest udfordrende del af fejlfindingsprocessen for SQL Server-replikering. Desuden kan kontrol af det sidste synkroniseringstidspunkt og hvilke ændringer, der er udført på/efter det tidspunkt, der kan forårsage denne fejl, også hjælpe med fejlfinding af replikeringssynkroniseringsfejlen.
En forståelse af SQL Server-replikeringsagentens rolle vil hjælpe med at identificere, i hvilket trin synkroniseringen mislykkes. Husk, at der er tre replikeringsagenter, der er fælles for de fleste af SQL Server-replikeringstyperne. Snapshot-agenten er ansvarlig for at oprette det indledende synkroniseringssnapshot. Loglæseragenten er ansvarlig for at læse ændringerne fra databasetransaktionslogfilen og kopiere den til distributionsdatabasen og endelig Distribution agent, der er ansvarlig for at synkronisere ændringerne til abonnenterne.
I denne artikel vil vi drage fordel af replikeringsmonitor og Jobaktivitetsovervågning vinduer til at overvåge SQL Server-replikeringsstatus og få oplysninger om eventuelle synkroniseringsfejl.
Fejlfindingsscenarier
Den bedste og ligetil måde at forstå, hvordan du fejlfinder SQL Server-replikeringsproblemerne, er ved at levere praktiske scenarier og vise, hvordan du løser dette særlige problem. Lad os begynde at diskutere scenarierne én efter én.
SQL Server Agent Service Problem
SQL Server Agent-tjenesten spiller en afgørende rolle i synkroniseringsprocessen for SQL Server-replikering. Dette skyldes, at hver replikeringsagent kører under et SQL-agentjob.
Som en proaktiv databaseadministrator skal du kontrollere SQL-replikeringsstedets status på daglig basis. For at kontrollere replikeringsstedets status skal du højreklikke på publikationen under noden Replikering -> Lokale publikationer og vælge Start replikeringsmonitor mulighed, som vist nedenfor:
Fra vinduet Replikeringsovervågning kan du se en advarselsmeddelelse, der viser, at replikeringen snart udløber eller allerede er udløbet, uden at se nogen vejledende fejlmeddelelse som nedenfor:
Hvis vinduet Replikeringsovervågning ikke giver os nyttige oplysninger om, hvorfor replikeringsstedet snart udløber, er næste trin at tjekke Jobaktivitetsovervågning under SQL Server Agent-noden. Når du besøger SQL Server Agent-noden, vil du se direkte, at SQL Server Agent Service ikke kører (fra den røde cirkel ved siden af den). Hvis SQL Server Agent Service ikke kører, betyder det, at alle de job, der er oprettet under den instans, ikke fungerer, inklusive replikeringsagentjobbene. Som følge heraf fungerer det overordnede replikeringssted ikke.
For at løse dette problem skal vi starte SQL Server Agent-tjenesten direkte fra SQL Server Management Studio eller bruge SQL Server Configuration Manager (anbefales), som vist nedenfor:
Når du har startet SQL Server Agent-tjenesten, skal du kontrollere replikeringsmonitoren igen og sikre dig, at abonnentstatus er Kører og alle afventende transaktioner synkroniseres med abonnenten. Du kan kontrollere disse trin et efter et ved at kontrollere, at posterne er kopieret fra sektionen Udgiver til distributør:
Derefter synkroniseret fra distributøren til abonnenten, som nedenfor:
Og sørg endelig for, at der ikke er nogen ikke-distribueret transaktion fra den sidste fane, som vist nedenfor:
Derefter skal vi sikre os, at replikeringsagentjobbene er oppe og køre uden problemer. SQL Agent-jobbene kan kontrolleres ved at udvide SQL Server Agent-noden under SSMS Object Explorer og se Job Activity Monitor og derefter kontrollere, om Log Reader Agent og Distributor-agenten kører, idet man tager i betragtning, at Snapshot Agent kun vil fungere under proces til oprettelse af snapshot, som vist nedenfor:
Du kan også gennemgå historikken for replikeringsagentjobbene og kontrollere den tidligere fejlårsag ved at højreklikke på det pågældende job og vælge Vis historik mulighed som nedenfor:
Hvor du kan finde en vejledende fejlmeddelelse, der hjælper med at løse dette problem i fremtiden, som nedenfor:
For at overvinde det tidligere problem skal SQL Server Agent-tjenestens starttilstand ændres fra Manuel til Automatisk, på denne måde vil du sikre dig, at tjenesten starter automatisk, når hostingserveren genstartes.
Snapshot Agent-tilladelsesproblem
Antag, at mens du tjekkede SQL Server-replikeringsstatus ved hjælp af replikeringsmonitor, bemærkede du, at der er en replikeringsfejl fra X-tegnet inde i den røde cirkel. Og replikeringsmonitoren viser, at fejlen er fra en af replikeringsagenterne, fra X-tegnet inde i den røde cirkel øverst på fanen Agenter.
For at identificere replikeringsfejlen bør vi gennemse fanen Agenter og kontrollere, hvilken agent der fejler. Fra siden Agenter vil du se, at Snapshot-agenten er den fejlende. Dobbeltklik på Snapshot Agent og se nedenstående fejlmeddelelse:
Replikeringsagenten har ikke logget en statusmeddelelse i 10 minutter. Dette kan indikere en ikke-reagerende agent eller høj systemaktivitet. Bekræft, at poster bliver replikeret til destinationen, og at forbindelser til abonnenten, udgiveren og distributøren stadig er aktive.
Desværre er denne fejlmeddelelse generisk, og den viser kun, at Snapshot Agenten ikke fungerer uden at angive årsagen som følger:
Så skal vi søge efter nyttig information et andet sted, som er Snapshot Agent-jobbet. Fra vinduet Job Activity Monitor under SQL Server Agent-noden kan du se, at Snapshot Agent-jobbet er mislykket. Og fra den jobhistorik kan du se, at den mislykkedes for nylig på grund af proxy-godkendelsesproblemet. Med andre ord er legitimationsoplysningerne for den konto, som Snapshot-agenten kører under, ikke korrekte, som vist nedenfor:
For at løse problemet med Snapshot Agent-legitimationsoplysninger skal du højreklikke på publikationen under replikeringsnoden -> Lokal publikation og vælge Egenskaber mulighed. Gennemse Agentsikkerhed i vinduet Publikationsegenskaber side og genindsæt legitimationsoplysningerne for den konto, som Snapshot-agenten kører under.
Efter at have opdateret Snapshot Agent-kontoens legitimationsoplysninger, skal du starte Snapshot Agent-jobbet igen fra vinduet Job Activity Monitor og sikre dig, at jobbet fungerer fint, som nedenfor:
Tjek også, om Snapshot-agenten fungerer fint nu, og fejlmeddelelsen ikke længere vises under replikeringsmonitoren, som vist nedenfor:
Snapshot-mappetilladelsesproblem
Antag, at når du forsøger at synkronisere udgiveren og abonnenten ved hjælp af det indledende snapshot eller gensynkronisere snapshot-replikeringsstedet ved hjælp af et nyt snapshot, mislykkedes processen til oprettelse af snapshot med adgangsfejlmeddelelsen nedenfor:
Denne fejlmeddelelse viser, at den konto, som Snapshot Agent kører under, ikke har tilladelse til at få adgang til den øjebliksbillede mappe, der er angivet i fejlmeddelelsen.
For at løse dette problem skal vi kontrollere den konto, som Snapshot-agenten kører under, fra siden Agentsikkerhed i vinduet Publikationsegenskaber, som vist nedenfor:
Gennemse derefter snapshot-mappen, der er angivet i fejlmeddelelsen, og sørg for, at denne snapshot-konto har minimum læse-skrivetilladelse på den mappe, kør derefter snapshot-agenten igen og se, at problemet er løst nu, og synkroniserings-snapshottet er oprettet med succes, da nedenfor:
Problem med abonnenttilladelse
Antag, at mens du kontrollerer SQL Server-replikeringsstedets status, ved hjælp af replikeringsmonitoren, kan du se, at der er en fejl med abonnenten, som vist nedenfor:
Hvis du klikker på fejlikonet, vil du se, at fejlen er opstået, når du forsøger at synkronisere transaktionerne fra distributøren til abonnenten. Og fra fejlmeddelelsen er det klart, at distributøren ikke er i stand til at oprette forbindelse til Subscriber SQL Server-instansen på grund af tilladelsesproblem, som vist nedenfor:
For at løse dette problem skal vi kontrollere og opdatere de legitimationsoplysninger, der bruges til at oprette forbindelse til Subscriber-instansen. For at kontrollere legitimationsoplysningerne skal du højreklikke på abonnementet under replikeringsnoden -> Lokale publikationer -> det aktuelle publikationsnavn og vælge indstillingen Egenskaber. Fra Subscriber Connection feltet under vinduet Subscriber Properties skal du opdatere legitimationsoplysningerne for den konto, der skal bruges til at oprette forbindelse til Subscriber-forekomsten, som vist nedenfor:
Derefter skal du kontrollere replikeringsstatussen igen fra replikeringsmonitoren, og du vil se, at abonnentforbindelsesproblemet ikke længere er tilgængeligt, og replikeringsstedet kører normalt, som vist nedenfor:
Abonnent kan ikke nås
Et andet problem med SQL Server-replikeringsfejl, du kan blive udsat for fra abonnentsiden, er, at distributøren ikke er i stand til at oprette forbindelse til abonnenten, hvilket viser under distributøren til abonnentsiden, at den ikke er i stand til at åbne forbindelse med abonnenten på grund af "Netværk Relateret … ” forbindelsesfejl, vist i vinduet Replikeringsovervågning nedenfor:
Denne fejlmeddelelse angiver, at der er et forbindelsesproblem mellem distributørforekomsten og abonnentforekomsten. Den første og ligetil måde at kontrollere dette forbindelsesproblem på er at sikre, at Subscriber SQL Server-forekomsten er online. Dette kan kontrolleres fra SQL Server Configuration Manager fra abonnentsiden. I vores situation kan vi se, at SQL Server Service på abonnentsiden er stoppet. For at løse dette problem skal du starte SQL Server Service og kontrollere fra replikeringsmonitoren, at replikeringsstedet er synkroniseret igen, som vist nedenfor. For mere avanceret SQL-forbindelsesproblem, se Fejlfinding Connectivity MS-dokumentet:
Problem med tilladelse til abonnentdatabase
Antag, at du kontrollerer SQL Server-replikeringssynkroniseringsstatus ved hjælp af replikeringsmonitoren, og det viser sig, at replikeringen mislykkes, mens du forsøger at replikere ændringerne fra distributøren til abonnenten. Ved at klikke på abonnentfejlen vil du se, at Distributøren er i stand til at nå abonnenten og oprette forbindelse til den, men kan ikke oprette forbindelse til abonnementsdatabasen på grund af manglende tilladelse, som vist nedenfor:
For at løse dette problem skal du oprette forbindelse til abonnenten og sørge for, at kontoen, der bruges til at oprette forbindelse til abonnentdatabasen, er medlem af den faste rolle db_Owner-databasen, som vist nedenfor:
Derefter skal du kontrollere replikeringsmonitoren igen og sikre dig, at distributøren er i stand til at nå abonnementsdatabasen og replikere ændringerne som nedenfor:
Problem med dataforskel
Antag, at et af databaseudviklingsteamene hævder, at der er nogle ændringer, der udføres på Shifts-tabellen på Publisher (SQL1), ikke afspejles i de daglige rapporter, der kører på Subscriber-forekomsten (SQL2), og han leverede øjebliksbilledet nedenfor der viser, at ændringerne ikke replikeres:
Det første trin i at kontrollere replikeringssynkroniseringsproblemet er at åbne replikeringsovervågningen og finde ud af, på hvilket trin den fejler. Fra replikeringsmonitoren kan du se, at loglæseragenten fejler, da ændringerne ikke replikeres fra distributøren til abonnenten, men der returneres ingen klar besked fra denne agent, som vist nedenfor:
Da vi ikke kan finde en meningsfuld fejlmeddelelse fra replikeringsmonitoren, vil vi kontrollere historikken for Log Reader Agent-jobbet ved hjælp af Job Activity Monitor, som viser, at legitimationsoplysningerne for den konto, som Log Reader Agent kører under, er forkerte. , som vist nedenfor:
For at løse problemet med loglæseragent-legitimationsoplysninger skal du gennemse siden Agentsikkerhed i vinduet Publikationsegenskaber og opdatere loglæseragent-legitimationsoplysningerne med et gyldigt som nedenfor:
Hvis du tjekker replikeringsmonitoren igen, vil du se, at ændringerne er replikeret med succes, og at dataene er opdateret med de nye skiftændringer, som vist nedenfor:
Række ikke fundet hos abonnent
Lad os se på spørgsmålet fra en anden side. Lad os sige, at der er foretaget en ændring i skifttabellen som vist nedenfor:
Men denne ændring replikeres ikke til abonnenten, og det overordnede SQL Server-replikeringssted er mislykket. Fra replikeringsmonitoren kan du se, at den fejler, mens den forsøger at foretage ændringen fra distributøren til abonnenten, og mislykkedes på grund af det faktum, at den ikke er i stand til at opdatere den specifikke post med ID lig med 3, fordi denne post er ikke tilgængelig i abonnentdatabasetabellen, som vist nedenfor:
Når du tjekker denne post på abonnentsiden (SQL2), vil du se, at posten ikke er tilgængelig, som nedenfor:
For at løse dette problem skal vi indsætte denne post igen i abonnentdatabasetabellen og lade distributøren forsøge at opdatere den igen, hvilket løser problemet med replikeringssynkroniseringsfejl, som vist nedenfor:
SQL Server giver os mulighed for at lade replikeringsstedet fortsætte med at fungere, selvom der er fundet et datainkonsistensproblem, hvor du manuelt kan løse dette inkonsistensproblem senere. For at gøre det skal du højreklikke på abonnenten fra replikeringsmonitoren og vælge Agentprofil mulighed, som vist nedenfor:
Fra det viste vindue kan du opdatere Log Reader Agent-profilen og tillade den at fortsætte med at replikere dataændringer i tilfælde af, at der er datainkonsistens, som vist nedenfor:
Ikke-initialiseret abonnementsudgave
Hvis replikationsstedet efterlades uden overvågning i lang tid, og der opstod en fejl uden nogen rettelse i mere end tre dage, udløber replikeringsstedet, og abonnementet vil blive markeret som ikke-initialiseret og venter på at blive geninitialiseret igen ved hjælp af et nyt snapshot . Det samme scenarie kan opstå, når du opretter et nyt abonnement uden at initialisere det, som vist nedenfor:
For at løse dette problem bør vi geninitialisere abonnementet ved at højreklikke på abonnementet under replikeringsnoden -> Lokale publikationer og udvide publikationen, derefter vælge indstillingen Geninitialisere og markere dette abonnement til initialisering og gøre det klar til at modtage en ny snapshot, som vist nedenfor:
Hvis abonnementsstatus forbliver uinitialiseret efter geninitialisering, skal du kontrollere Snapshot Agent-jobbet ved hjælp af Job Activity Monitor-vinduet og se, hvorfor det fejler. Fra Snapshot Agent jobhistorik kan du se, at jobbet mislykkedes på grund af et problem, der bestemmer ejeren af det agentjob, som vist nedenfor:
For at overvinde dette problem skal du åbne Snapshot Agent-jobbet og ændre ejeren af jobbet til SA eller en gyldig administratorbruger, og jobbet vil køre med succes som nedenfor:
Nu vil du se, at abonnementsstatus er ændret til Kører, hvilket betyder, at den venter på det indledende øjebliksbillede for at starte synkroniseringsprocessen, som vist nedenfor:
For at generere et nyt øjebliksbillede skal du højreklikke på publikationen under replikeringsnoden-> Lokale publikationer og vælge Se Snapshot Agent Status mulighed.
Fra det åbnede vindue skal du klikke på knappen Start for at starte processen til oprettelse af snapshot. Når øjebliksbilledet, der indeholder alle Publisher-artiklerne, er oprettet med succes, skal du åbne replikeringsmonitoren igen og kontrollere status for abonnementet, hvor du vil se, at snapshottet er anvendt på abonnenten og synkroniseret med Publisheren, som vist nedenfor:
Udgiverdatabaseejerproblem
Antag også, at når du kontrollerer status for SQL Server-replikeringsstedet ved hjælp af replikeringsmonitoren, var replikeringsstedet fejlet, og fejlen blev opdaget hos Log Reader Agent. Ved at kontrollere fejlmeddelelsen, der returneres fra den pågældende agent, konstateres det, at der er et problem med at bestemme den nuværende ejer af publikationsdatabasen, som vist nedenfor:
For at løse dette problem skal vi opdatere den nuværende publikationsdatabaseejer ved at erstatte den med en gyldig databasebruger ved hjælp af SP_changedbowner systemlagret procedure eller blot fra vinduet med databaseegenskaber. Kør derefter Log Reader Agent-jobbet igen ved hjælp af Job Activity Monitor-vinduet, og valider derefter, om agentproblemet ikke længere er tilgængeligt, ved hjælp af Replikeringsmonitor, som vist nedenfor:
Konklusion
I denne artikel demonstrerede vi forskellige problemer, som du kan komme ud for, når du bruger SQL Server-replikeringsfunktionen til at kopiere data mellem forskellige websteder, og hvordan du løser disse problemer.
Det anbefales stærkt at holde SQL Server Engine opdateret med de nyeste SP'er og CU'er, så alle fejl relateret til SQL Server Replication-funktionerne vil blive rettet automatisk. Til sidst, som en proaktiv SQL Server-databaseadministrator, skal du holde øje med dit replikeringswebsted for at løse ethvert problem fra begyndelsen, før det bliver større og sværere at rette.