Konfiguration af heterogen databasereplikering – SQL Server til Oracle

Introduktion

SQL Server-replikering er en SQL Server-funktion, der giver os mulighed for at overføre data fra én instans til en anden til sådanne formål som at konsolidere data til et rapporteringsmiljø eller migreringer. Jeg ville personligt ikke betragte SQL Server Replication som en teknologi med høj tilgængelighed, selvom nogle mennesker anser det for at være det.

SQL Server-replikering bruger udtryk, der ligner dem i forlagsbranchen til at beskrive den måde, data håndteres på fra kilde til destination. Nøgletermerne er som følger:

• Publisher – en SQL Server-instans, der gør data tilgængelige til at blive replikeret til andre instanser (pakket som publikationer).
• Publikation – en enhed, der er klar til at blive videregivet til den modtagende instans, der består af en samling af artikler, der faktisk er databaseobjekter.
• Distributor – en SQL Server-instans, der er ansvarlig for lagring af data knyttet til en eller flere udgivere i en database kaldet en distributionsdatabase . En lokal distributør er gemt i samme instans som udgiveren, mens en fjerndistributør er placeret i en anden instans.
• Abonnent – ​​en instans, der modtager en replikeret database. Et abonnentabonnement er en anmodning om en udgivelseskopi, som det forventer at modtage fra udgiveren.
• Øjebliksbillede.

I artiklen vil jeg dele et par punkter, jeg lærte ved at konfigurere SQL Server-replikeringen til at understøtte en heterogen abonnent. Jeg vil oprette en publikation og efterfølgende et Oracle-abonnement, som afhænger af denne publikation. Jeg vil også demonstrere et par punkter sammen med processens flow, som er meget vigtige for fejlfinding af problemer.

Trinene til at konfigurere en snapshot-replikeringssession er som følger:

1. Konfigurer en distributør
2. Konfigurer en udgiver (sammen med publikationen inklusive de artikler, der udgives)
3. Konfigurer en abonnent

Jeg vil give en kort forklaring af hvert trin.

Konfiguration af en distributør

En distributør er en instans, der er ansvarlig for at gemme information, der bruges under replikeringen. Når du prøver at oprette en publikation i instansen for første gang, vil SQL Server foreslå, at du konfigurerer en distributør. I denne artikel er vores distributør en lokal distributør .

Oprettelse af en publikation

Lad os identificere den database, der indeholder de objekter, vi gerne vil replikere. Dette vil være en publikationsdatabase .

For at oprette en publikationsdatabase skal du følge instruktionerne på skærmbillederne nedenfor.

Dette trin giver dig mulighed for at vælge en type publikation, du ønsker at konfigurere. Hver publikationstype er beskrevet i den nederste rude. Af enkeltheds- og kompatibilitetsårsager vælger vi en snapshot-publikation. Bemærk venligst, at vi har til hensigt at replikere objekter til en Oracle-instans. I dette tilfælde Transaktionel og Snapshot-publikationer er understøttet. Der er andre gode use cases for en peer-to-peer og flette replikering.

På dette trin vælger vi de artikler, vi ønsker at publicere. SQL Server giver os mulighed for at udgive fire nøgleobjekttyper såsom:

1. Tabeller
2. Lagrede procedurer
3. Visninger
4. Brugerdefinerede funktioner

Som du kan se, vil vi udgive to tabeller:Ordrer og Ordrelinjer. For at demonstrere fleksibiliteten ved SQL Server-replikering vil vi filtrere posterne som vist nedenfor.
Bemærk: Vi er interesserede i, at antallet af OrderID'er er større end 1000.

For at ekskludere uønskede rækker fra offentliggjorte tabeller skal du klikke på Tilføj... og derefter Næste .

Nedenstående skærmbilleder viser, hvordan man filtrerer kolonner for OrderLines-tabellen.

Konfigurer derefter egenskaberne for Snapshot Agent. Vi definerer et indledende snapshot og det interval, hvor et nyt snapshot genereres. De data, der udtrækkes i dette trin, gemmes i en mappe, der er angivet, da distributøren oprindeligt blev konfigureret.

Først skal du opsætte en tidsplan for en øjebliksbilledeagents start. Klik på Næste .

For hver snapshot-agent skal du angive den konto, som den skal køre under.

Konfigurer derefter Snapshot Agent-sikkerhedsindstillingerne. Tabellen Sikkerhedsindstillinger åbner et andet vindue, hvor vi definerer, hvem der kører Snapshot Agent-processen samt bestemmer de SQL Server-logindetaljer, der skal forbindes til udgiveren. Der er visse tilladelser, der kræves af disse principaler, som kan være lidt usikre i produktionen. Brug af SQL Server Agent Service-kontoen er en løsning for at undgå komplikationer, men det anbefales faktisk IKKE af Microsoft.

Tæt på slutningen skal du beslutte, om du vil gemme konfigurationen som et script til senere brug eller oprette publikationen med det samme.

Det næste trin (fig. 16) opsummerer alle de muligheder, du har valgt. Det anbefales at lave en hurtig gennemgang, før du klikker på Udfør knap.

Processen med at oprette publikation starter. Du kan klikke på Stop for at afbryde processen.

Når processen er afsluttet, bliver din publikation synlig i Objekt Explorer-ruden i SQL Server Management Studio.

Tilføjelse af en abonnent

En abonnent modtager publikationer, der er stillet til rådighed af Udgiveren . Den kopi af publikationen, der skal leveres til en abonnent, kaldes et abonnement . En udgiver kan have mange abonnenter. Hver
abonnent modtager artiklerne udgivet af denne udgiver som en enhed kaldet udgivelsen, for så vidt angår udgiveren og betragtes som abonnementet på abonnenten.

Ved at oprette et abonnement fortæller vi blot udgiveren:"Jeg vil gerne have kopier af denne publikation". Lige så meget som en Publisher kan have mange publikationer, kan der også være mange abonnenter på en
udgivelse. Forholdet mellem udgivere og abonnenter er således et en-til-mange forhold.

New Subscription Wizard lader os bestemme, hvilken publikation vi gerne vil abonnere på. Vi kan vælge fra en liste over de tidligere oprettede publikationer som vist i fig. 20.

Dernæst beslutter vi, om vi vil køre et Push-abonnement i stedet for et Pull-abonnement. Selvom et Pull-abonnement er bedre for ydeevnen, når du forestiller dig flere abonnenter, vil det ikke
fungere for en heterogen databasereplikering. Ikke-SQL-serverabonnenter skal bruge et Pull-abonnement. Det er værd at nævne, at artiklerne offentliggjort i dette scenarie også er begrænset til tabeller og indekserede visninger.

Tilføj en Oracle-abonnent ved hjælp af et datakildenavn (DSN). Denne DSN skal allerede være oprettet, testet og fundet ud af at virke i forhold til at kunne oprette forbindelse til Oracle-instansen via Oracle Net. Det betyder, at du skal have en Oracle-klient installeret på SQL Server-værten med en indgang til en fil kaldet tnsnames.ora definere destinationen for forbindelsen. Denne TNS-indgang bruges igen til at konfigurere det datakildenavn, som guiden Nyt abonnement beder om på dette trin.

Indgangen, jeg har oprettet i min tnsnames.ora-fil, ser sådan ud:

ORCL10G =
 (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = IGIRI-LP)(PORT = 1522))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl10g)
    )
 )

Den fremhævede del er aliaset, mens de andre detaljer definerer destinationen for forbindelsen. Vi kan bekræfte, om denne post fungerer korrekt, og om mine Oracle-miljøvariabler er konfigureret korrekt ved at bruge tnsping hjælpeprogram som vist nedenfor.

Når den er bekræftet, bruges denne TNS-indgang til at konfigurere det DSN, vi agter at bruge. Vores TNS-tjenestenavn hedder ORCL10G mens DSN hedder ORCLDC . Det er DSN, vi bruger i guiden Nyt abonnement.

Bemærk, at vi har brugt 64-bit versionen af ​​ODBC til at konfigurere DSN, og det er et system DSN, ikke en bruger DSN. Konfigurationen afhænger ikke af, hvem der er logget på computeren.

Vælg en abonnenttype, der skal tilføjes, og indtast datakildenavnet. Klik på OK .

Vælg en eller flere abonnenter, samt angiv en database for hvert abonnement.

Når først DSN er tilføjet, kan vi fortsætte med at konfigurere distributionsagentsikkerheden. Vi finder ud af, at dette ligner tilfældet, da vi konfigurerede en Snapshot Agent Security i guiden Ny udgivelse.

Her har vi dog en sektion, hvor vi etablerer forbindelse til Abonnenten snarere end til Udgiveren (husk at dette er et push-abonnement). Denne brugerkonto skal være oprettet på Oracle-instansen og skal have privilegier til at oprette tabeller og kvoter på dens standard tablespace (her skal du muligvis have en Oracle DBA).

Tilføj parametre til distributionsagentsikkerheden, og klik på OK .

Angiv konto- og forbindelsesmulighederne for hver distributionsagent, og klik på Næste .

Definer synkroniseringsplanen for hver agent. I vores tilfælde valgte vi at synkronisere løbende. Klik på Næste .

Vælg muligheden for at initialisere abonnementet med det samme, hvilket betyder, at du kopierer ALLE tilgængelige data i Snapshot-mappen igen. Det tilrådes for NoSQL Server-abonnenter at geninitialisere abonnementet, når der føjes nye artikler til publikationen. Klik på Næste .

Vælg de muligheder, der skal udføres, efter at processen er fuldført. Klik på Næste .

Bekræft de oplysninger, du har tilføjet, og klik på Udfør .

Processen med at oprette abonnement kører.

Abonnementet, vi lige har oprettet, viser en post i Object Explorer (på Publisher), der er knyttet til dens overordnede publikation. Bemærk, at den ikke vises i den lokale abonnementsknude, der giver dig en liste over abonnementer, der er oprettet på den aktuelle forekomst, som ikke er i dette tilfælde.

Overvågning og fejlfinding

SQL Server leverer replikeringsmonitoren til at gennemgå og overvåge detaljer om alle replikeringssessioner på instansen. Replikeringsmonitoren kan informere administratoren, når Snapshot-agenten kører og fuldfører. Det kan også vise os, om abonnementerne er initialiseret, og om distributionsagenten kører problemfrit.

Der er otte SQL Server Agent-job knyttet til vores nuværende konfiguration. At se historikken for disse job giver også detaljer om, hvorvidt alt er i orden.

Faktiske Oracle-fejl er angivet i replikeringsovervågningen og i SQL Server-fejlloggen, når de stødes på. Dette detaljeringsniveau gør SQL Server Replication interessant at fejlfinde. At have kendskab til Oracle (til SQL Server DBA) vil tage en lang vej at forstå de fejl, der kan opstå.

Tag et kig på eksemplet med fejlen i fig. 34. Denne fejl opstod før Oracle Net- og ODBC-miljøerne blev konfigureret korrekt. Fejlene giver en meget klar indikation af, hvor problemet er.

Visningen Jobaktivitetsovervågning informerer os også om, hvilke job der lykkes, og hvilket job vi skal fejlfinde i detaljer ved at undersøge jobhistorikken.

Når alle de tidligere fejl er løst, åbnes et abonnement ved at dobbeltklikke på det, og det giver os en detaljeret oversigt over alle sessioner, fejl og resultater, vi forventer at se, når alt er i orden. Bemærk, at Agent Bulk kopierer data fra udgiveren til abonnenten i batches. Vi kan også forespørge på de tabeller, der er blevet oprettet i Oracle-instansen, og sammenligne posterne. (Fig. 37).

Som du kan se, forbereder SQL Server tabellen eksklusiv kildeskemaet (Salg), før du opretter tabellen i Oracle og kopierer dataene.

Rekordtællingen i Oracle-instansen matcher den i kildetabellen og tager højde for, at vi filtrerer OrderLines-tabellen for OrderID'er større end 1000.

Konklusion

Vi har kort gennemgået processen med at konfigurere heterogen databasereplikering med en Oracle-instans som abonnent. Selvom denne mulighed gradvist forældes af Microsoft, er der brugstilfælde, der stadig kan drage fordel af de muligheder, som denne gamle SQL Server-funktion tilbyder. Referencesektionen giver en bredere læsning om emnet, som jeg tror vil være nyttig for dem, der ønsker at øve sig mere.

Referencer

Konfigurer replikering for Always-On-tilgængelighedsgrupper
Ikke-Oracle-abonnenter
Heterogen databasereplikering
Oracle-abonnenter