Siden 1999, for å betjene back office, har banken vår brukt det integrerte banksystemet BISKVIT på Progress OpenEdge-plattformen, som er mye brukt over hele verden, inkludert i finanssektoren. Ytelsen til denne DBMS lar deg lese opptil en million eller flere poster per sekund i én database (DB). Vår Progress OpenEdge betjener ca. 1,5 millioner individuelle innskudd og ca. 22,2 millioner kontrakter for aktive produkter (billån og boliglån), og er også ansvarlig for alle oppgjør med regulatoren (sentralbanken) og SWIFT.
Ved å bruke Progress OpenEdge ble vi møtt med behovet for å få det til å fungere med Oracle DBMS. I utgangspunktet var denne pakken flaskehalsen i infrastrukturen vår – helt til vi installerte og konfigurerte Pro2 CDC – et Progress-produkt som lar deg sende data fra Progress DBMS til Oracle DBMS direkte, online. I dette innlegget vil vi fortelle deg i detalj, med alle fallgruvene, hvordan du effektivt får venner mellom OpenEdge og Oracle.
Hvordan det skjedde: laste opp data til QCD via fildeling
Først noen fakta om infrastrukturen vår. Antallet aktive brukere av databasen er omtrent 15 tusen. Volumet av alle produktive databaser, inkludert replika og standby, er 600 TB, den største databasen er 16,5 TB. Samtidig fylles databasene stadig på: Bare det siste året er det lagt til rundt 120 TB med produktive data. Systemet drives av 150 frontservere på x86-plattformen. Databasene ligger på 21 IBM-plattformservere.
Front-end-systemer, ulike kjernebanksystemer og banktjenester er integrert med OpenEdge Progress (BISCUIT IBS) via Sonic ESB-bussen. Opplasting av data til QCD skjer gjennom filutveksling. Inntil et visst tidspunkt hadde denne løsningen to store problemer på en gang - lav ytelse ved opplasting av informasjon til et bedriftsdatavarehus (CDW) og lang tid for å utføre dataavstemming (avstemming) med andre systemer.
Derfor begynte vi å se etter et verktøy som kunne fremskynde disse prosessene. Løsningen på begge problemene var det nye Progress OpenEdge-produktet – Pro2 CDC (Change Data Capture). Så la oss begynne.
Installer Progress OpenEdge og Pro2Oracle
For å kjøre Pro2 Oracle på administratorens Windows-datamaskin er det nok å installere Progress OpenEdge Developer Kit Classroom Edition, som kan gratis. Standard OpenEdge installasjonskataloger:
DLC: C:ProgressOpenEdge
WRK: C:OpenEdgeWRK
ETL-prosesser krever Progress OpenEdge-lisenser versjon 11.7+ – nemlig OE DataServer for Oracle og 4GL Development System. Disse lisensene følger med Pro2. For full drift av DataServer for Oracle med en ekstern Oracle-database, er Full Oracle Client installert.
På Oracle-serveren må du installere Oracle Database 12+, opprette en tom database og legge til en bruker (la oss ringe ham cdc).
For å installere Pro2Oracle, last ned den nyeste distribusjonen fra nedlastingssenteret. Pakk ut arkivet i en katalog C:Pro2 (For å konfigurere Pro2 på Unix, brukes samme distribusjon og de samme konfigurasjonsprinsippene gjelder).
Opprette en cdc-replikeringsdatabase
Replikeringsdatabase cdc (repl) Pro2 brukes til å lagre konfigurasjonsinformasjon, inkludert replikeringskartet, navn på replikerte databaser og deres tabeller. Den inneholder også en replikeringskø, bestående av merknader om at en tabellrad i kildedatabasen er endret. Data fra replikeringskøen brukes av ETL-prosesser for å identifisere rader som må kopieres til Oracle fra kildedatabasen.
Vi lager en egen cdc-database.
Prosedyre for å opprette en database
- På databaseserveren lager vi en katalog for cdc-databasen - for eksempel på serveren /database/cdc/.
- Lag en dummy for cdc-databasen: procopy $DLC/tom cdc
- Aktiver støtte for store filer: proutil cdc -C EnableLargeFiles
- Vi forbereder et skript for å starte cdc-databasen. Startparametrene må være lik startparametrene til den replikerte databasen.
- Vi starter cdc-databasen.
- Koble til cdc-databasen og last inn Pro2-skjemaet fra filen cdc.df, som følger med Pro2.
- Vi oppretter følgende brukere i cdc-databasen:
pro2adm – for tilkobling fra Pro2-administrasjonspanelet;
pro2etl – for tilkobling av ETL-prosesser (ReplBatch);
pro2cdc – for å koble til CDC-prosesser (CDCBatch);
Aktiverer OpenEdge Change Data Capture
La oss nå slå på selve CDC-mekanismen, ved hjelp av hvilken data vil bli replikert til et ekstra teknologiområde. Til hver Progress OpenEdge-kildedatabase må du legge til separate lagringsområder der kildedataene skal dupliseres, og aktivere selve mekanismen ved å bruke kommandoen proutil.
Eksempel prosedyre for bisquit-databasen
- Kopiering fra katalogen C:Pro2db файл cdcadd.st til bisquit kildedatabasekatalogen.
- Vi beskriver i cdcadd.st faste størrelsesutstrekninger for regioner "ReplCDCArea" и "ReplCDCArea_IDX". Du kan legge til nye lagringsområder på nettet: prostrct addonline bisquit cdcadd.st
- Aktiver OpenEdge CDC:
proutil bisquit -C enablecdc området "ReplCDCArea" indeksområde "ReplCDCArea_IDX" - Følgende brukere må opprettes i kildedatabasen for å identifisere kjørende prosesser:
en. pro2adm – for tilkobling fra Pro2-administrasjonspanelet.
b. pro2etl – for tilkobling av ETL-prosesser (ReplBatch).
c. pro2cdc – for å koble til CDC-prosesser (CDCBatch).
Opprette en skjemaholder for DataServer for Oracle
Deretter må vi lage en Schema Holder-database på serveren der data fra Progress DBMS vil bli replikert til Oracle DBMS. DataServer Schema Holder er en tom Progress OpenEdge-database uten brukere eller applikasjonsdata, som inneholder et kart over korrespondanse mellom kildetabeller og eksterne Oracle-tabeller.
Schema Holder-databasen for Progress OpenEdge DataServer for Oracle for Pro2 må være plassert på ETL-prosessserveren; den opprettes separat for hver gren.
Hvordan lage en skjemaholder
- Pakk ut Pro2-distribusjonen i en katalog /pro2
- Opprett og gå til katalogen /pro2/dbsh
- Opprett en Schema Holder-database ved å bruke kommandoen kopier $DLC/tom bisquitsh
- Utfører konverteringen bisquitsh inn i den nødvendige kodingen - for eksempel i UTF-8 hvis Oracle-databaser har UTF-8-koding: proutil bisquitsh -C convchar convert UTF-8
- Etter å ha opprettet en tom database bisquitsh koble til den i enkeltbrukermodus: pro bisquitsh
- La oss gå til Data Dictionary: Verktøy -> Data Dictionary -> DataServer -> ORACLE Utilities -> Lag DataServer Schema
- Start Schema Holder
- Sette opp Oracle DataServer-megleren:
en. Start AdminServer.
proadsv -start
b. Start av Oracle DataServer-megleren
oraman -navn orabroker1 -start
Sette opp administrasjonspanelet og replikeringsskjemaet
Ved å bruke Pro2-administrasjonspanelet konfigureres Pro2-parametere, inkludert oppsett av replikeringsskjemaet og generering av ETL-prosesser (Processor Library), primære synkroniseringsprogrammer (Bulk-Copy Processor), replikeringsutløsere og OpenEdge CDC-policyer. Det finnes også primære verktøy for å overvåke og administrere ETL- og CDC-prosesser. Først av alt setter vi opp parameterfilene.
Hvordan konfigurere parameterfiler
- Gå til katalogen C:Pro2bpreplScripts
- Åpne filen for redigering replProc.pf
- Legg til tilkoblingsparametere til cdc-replikeringsdatabasen:
# Replikeringsdatabase
-db cdc -ld repl -H <vertsnavn for hoveddatabase> -S <databasemeglerport cdc>
-U pro2admin -P <passord> - Legge til replProc.pf koblingsparametere til kildedatabaser og Schema Holder i form av parameterfiler. Navnet på parameterfilen må samsvare med navnet på kildedatabasen som kobles til.
# Koble til alle replikerte kilder BISQUIT
-pf bpreplscriptsbisquit.pf - Legge til replProc.pf parametere for tilkobling til Schema Holder.
#Target Pro DB Schema Holder
-db bisquitsh -ld bisquitsh
-H <ETL prosess vertsnavn>
-S <biskuitsh meglerport>
-db bisquitsql
-ld bisquitsql
-dt ORAKEL
-S 5162 -H <Oracle megler vertsnavn>
-DataService orabroker1 - Lagre parameterfilen replProc.pf
- Deretter må du opprette og åpne for redigering av parameterfiler for hver tilkoblede kildedatabase i katalogen C:Pro2bpreplScripts: bisquit.pf. Hver pf-fil inneholder parametere for å koble til den tilsvarende databasen, for eksempel:
-db bisquit -ld bisquit -H <vertsnavn> -S <meglerport>
-U pro2admin -P <passord>
For å konfigurere Windows-snarveier, må du gå til katalogen C:Pro2bpreplScripts og rediger snarveien "Pro2 – Administrasjon". For å gjøre dette, åpne egenskapene til snarveien og i linjen Start i angi Pro2-installasjonskatalogen. En lignende operasjon må gjøres for snarveiene "Pro2 – Editor" og "RunBulkLoader".
Pro2 administrasjonsoppsett: Laster innledende konfigurasjon
La oss starte konsollen.
Gå til "DB Map".
For å koble til databaser i Pro2 – Administrasjon, gå til fanen DB kart. Legg til kartlegging av kildedatabaser - Skjemaholder - Oracle.
Gå til fanen Kartlegging. Oppført Kildedatabase Som standard er den første tilkoblede kildedatabasen valgt. Til høyre for listen skal det være en inskripsjon Alle databaser tilkoblet — de valgte databasene er koblet sammen. Nedenfor til venstre skal du se en liste over Progress-tabeller fra bisquit. Til høyre er en liste over tabeller fra Oracle-databasen.
Opprette SQL-skjemaer og databaser i Oracle
For å lage et replikeringskart, må du først generere SQL-skjema i Oracle. I Pro2 Administration kjører vi menypunktet Verktøy -> Generer kode -> Målskjema, deretter i dialogboksen Velg Database velg en eller flere kildedatabaser og flytt dem til høyre.
Klikk OK og velg katalogen for å lagre SQL-skjemaene.
Deretter lager vi basen. Dette kan for eksempel gjøres via Oracle SQL-utvikler. For å gjøre dette kobler vi til Oracle-databasen og laster inn skjemaet for å legge til tabeller. Etter å ha endret sammensetningen av Oracle-tabeller, må du oppdatere SQL-skjemaene i Schema Holder.
Etter at nedlastingen er fullført, avslutter du bisquitsh-databasen og åpner Pro2-administrasjonspanelet. Tabeller fra Oracle-databasen skal vises på Mapping-fanen til høyre.
Tabellkartlegging
For å lage et replikeringskart, i Pro2-administrasjonspanelet, gå til Mapping-fanen og velg kildedatabasen. Klikk på Karttabeller, velg Velg endringer til venstre for tabellene som skal replikeres i Oracle, flytt dem til høyre og bekreft valget. Et kart opprettes automatisk for de valgte tabellene. Vi gjentar operasjonen for å lage et replikeringskart for andre kildedatabaser.
Generering av Pro2-replikeringsprosessorbibliotek og bulkkopieringsprosessorprogrammer
Replikeringsprosessorbiblioteket er designet for tilpassede replikeringsprosesser (ETL-er) som behandler Pro2-replikeringskøen og pusher endringer til Oracle-databasen. Replikeringsprosessorbiblioteksprogrammer lagres automatisk i katalogen etter generering bprepl/repl_proc (PROC_DIRECTORY-parameter). For å generere replikeringsprosessorbiblioteket, gå til Verktøy -> Generer kode -> Prosessorbibliotek. Etter at genereringen er fullført, vil programmene vises i katalogen bprepl/repl_proc.
Bulk Load Processor-programmer brukes til å synkronisere Progress-kildedatabaser med Oracle-måldatabasen basert på programmeringsspråket Progress ABL (4GL). For å generere dem, gå til menyelementet Verktøy -> Generer kode -> Massekopiprosessor. I dialogboksen Velg database velger du kildedatabasene, flytter dem til høyre side av vinduet og klikker OK. Etter at genereringen er fullført, vil programmene vises i katalogen bpreplrepl_mproc.
Sette opp replikeringsprosesser i Pro2
Å dele opp tabeller i sett servert av en separat replikeringstråd forbedrer ytelsen og effektiviteten til Pro2 Oracle. Som standard er alle tilkoblinger som opprettes i replikeringskartet for nye replikeringstabeller knyttet til tråd nummer 1. Det anbefales å skille tabeller i forskjellige tråder.
Informasjon om statusen til replikeringstråder vises på Pro2-administrasjonsskjermen i fanen Monitor i delen Replikeringsstatus. En detaljert beskrivelse av parameterverdier finner du i Pro2-dokumentasjonen (katalog C:Pro2Docs).
Opprett og aktiver CDC-policyer
Politikker er et sett med regler for OpenEdge CDC-motoren for å overvåke endringer i tabeller. I skrivende stund støtter Pro2 bare CDC-policyer med nivå 0, det vil si at kun fakta overvåkes registrere endringer.
For å opprette en CDC-policy, på administrasjonspanelet, gå til Mapping-fanen, velg kildedatabasen og klikk på knappen Legg til/fjern retningslinjer. I vinduet Velg endringer som åpnes, velger du på venstre side og flytter til høyre tabellene du må opprette eller slette en CDC-policy for.
For å aktivere, åpne Mapping-fanen igjen, velg kildedatabasen og klikk på knappen (In) Aktiver retningslinjer. Velg og flytt til høyre side av tabellen policyene som må aktiveres, klikk OK. Etter dette er de merket med grønt. Ved bruk av (In) Aktiver retningslinjer Du kan også deaktivere CDC-policyer. Alle transaksjoner utføres online.
Etter at CDC-policyen er aktivert, lagres notater om endrede poster i lagringsområdet "ReplCDCArea" i henhold til kildedatabasen. Disse notatene vil bli behandlet gjennom en spesiell prosess CDCBatch, som basert på dem vil lage notater i Pro2-replikeringskøen i databasen cdc (repl).
Dermed har vi to køer for replikering. Det første trinnet er CDCBatch: fra kildedatabasen går dataene først til den mellomliggende CDC-databasen. Det andre trinnet er når data overføres fra CDC-databasen til Oracle. Dette er et trekk ved dagens arkitektur og selve produktet – så langt har ikke utviklerne klart å etablere direkte replikering.
Primær synkronisering
Etter å ha aktivert CDC-mekanismen og satt opp Pro2-replikeringsserveren, må vi starte den første synkroniseringen. Innledende synkroniseringskommando:
/pro2/bprepl/Script/replLoad.sh bisquit-tabellnavn
Etter at den første synkroniseringen er fullført, kan replikeringsprosesser startes.
Start av replikeringsprosesser
For å starte replikeringsprosesser må du kjøre et skript replbatch.sh. Før du starter, sørg for at det er replbatch-skript for alle tråder - replbatch1, replbatch2, etc. Hvis alt er på plass, åpner du kommandolinjen (f.eks. proenv), gå til katalogen /bprepl/scripts og start manuset. I administrasjonspanelet sjekker vi at den tilsvarende prosessen har fått statusen KJØRER.
Funn
Etter implementering akselererte vi kraftig opplastingen av informasjon til bedriftens datavarehus. Dataene kommer automatisk inn i Oracle online. Det er ikke nødvendig å kaste bort tid på å kjøre noen langvarige spørringer for å samle inn data fra forskjellige systemer. I tillegg kan replikeringsprosessen i denne løsningen komprimere data, noe som også har en positiv effekt på hastigheten. Nå begynte daglig avstemming av BISKVIT-systemet med andre systemer å ta 15-20 minutter i stedet for 2-2,5 timer, og en fullstendig avstemming tok flere timer i stedet for to dager.
Kilde: www.habr.com