Dal 1999, per servire il back office, la nostra banca utilizza il sistema bancario integrato BISKVIT sulla piattaforma Progress OpenEdge, ampiamente utilizzato in tutto il mondo, anche nel settore finanziario. Le prestazioni di questo DBMS consentono di leggere fino a un milione o più record al secondo in un database (DB). Il nostro Progress OpenEdge serve circa 1,5 milioni di depositi individuali e circa 22,2 milioni di contratti per prodotti attivi (prestiti auto e mutui), ed è anche responsabile di tutti gli accordi con l'autorità di regolamentazione (Banca Centrale) e SWIFT.
Utilizzando Progress OpenEdge, ci siamo trovati di fronte alla necessità di farlo funzionare con Oracle DBMS. Inizialmente, questo pacchetto rappresentava il collo di bottiglia della nostra infrastruttura, fino a quando non abbiamo installato e configurato Pro2 CDC, un prodotto Progress che consente di inviare dati dal DBMS Progress al DBMS Oracle direttamente, online. In questo post ti racconteremo in dettaglio, con tutte le insidie, come fare amicizia in modo efficace tra OpenEdge e Oracle.
Come è successo: caricamento dei dati su QCD tramite condivisione di file
Innanzitutto, alcuni fatti sulla nostra infrastruttura. Il numero di utenti attivi del database è di circa 15mila. Il volume di tutti i database produttivi, inclusi replica e standby, è di 600 TB, il database più grande è di 16,5 TB. Allo stesso tempo, i database vengono costantemente aggiornati: solo nell’ultimo anno sono stati aggiunti circa 120 TB di dati produttivi. Il sistema è alimentato da 150 front server sulla piattaforma x86. I database sono ospitati su 21 server della piattaforma IBM.
I sistemi front-end, vari sistemi bancari core e servizi bancari sono integrati con OpenEdge Progress (BISCUIT IBS) tramite il bus Sonic ESB. Il caricamento dei dati su QCD avviene tramite scambio di file. Fino a un certo punto, una soluzione del genere presentava due grossi problemi contemporaneamente: basse prestazioni di caricamento delle informazioni nel data warehouse aziendale (CDW) e molto tempo per eseguire la riconciliazione dei dati (riconciliazione) con altri sistemi.
Pertanto, abbiamo iniziato a cercare uno strumento che potesse accelerare questi processi. La soluzione a entrambi i problemi è stata il nuovo prodotto Progress OpenEdge – Pro2 CDC (Change Data Capture). Quindi, cominciamo.
Installa Progress OpenEdge e Pro2Oracle
Per eseguire Pro2 Oracle sul computer Windows dell'amministratore, è sufficiente installare Progress OpenEdge Developer Kit Classroom Edition, che può essere gratuito. Directory di installazione predefinite di OpenEdge:
DLC: C:ProgressOpenEdge
WRK: C:OpenEdgeWRK
I processi ETL richiedono le licenze Progress OpenEdge versione 11.7+, ovvero OE DataServer per Oracle e 4GL Development System. Queste licenze sono incluse con Pro2. Per il funzionamento completo di DataServer for Oracle con un database Oracle remoto, è installato Full Oracle Client.
Sul server Oracle è necessario installare Oracle Database 12+, creare un database vuoto e aggiungere un utente (chiamiamolo cdc).
Per installare Pro2Oracle, scarica la distribuzione più recente dal centro download. Decomprimere l'archivio in una directory C:Pro2 (Per configurare Pro2 su Unix viene utilizzata la stessa distribuzione e si applicano gli stessi principi di configurazione).
Creazione di un database di replica CDC
Base di dati di replica cdc (sostituzione) Pro2 viene utilizzato per archiviare informazioni di configurazione, inclusa la mappa di replica, i nomi dei database replicati e le relative tabelle. Contiene inoltre una coda di replica, composta da note relative al fatto che una riga della tabella nel database di origine è stata modificata. I dati della coda di replica vengono utilizzati dai processi ETL per identificare le righe che devono essere copiate in Oracle dal database di origine.
Stiamo creando un database CDC separato.
Procedura per la creazione di un database
- Sul server del database creiamo una directory per il database cdc, ad esempio sul server /database/cdc/.
- Crea un manichino per il database cdc: procopia $DLC/cdc vuoto
- Abilita il supporto per file di grandi dimensioni: proutil cdc -C AbilitaFilegrandi
- Prepariamo uno script per l'avvio del database cdc. I parametri di avvio devono essere simili ai parametri di avvio del database replicato.
- Avviamo il database CDC.
- Connettersi al database cdc e caricare lo schema Pro2 dal file cdc.df, che è incluso con Pro2.
- Creiamo i seguenti utenti nel database cdc:
pro2adm – per la connessione dal pannello amministrativo Pro2;
pro2etl – per connettere processi ETL (ReplBatch);
pro2cdc – per connettere processi CDC (CDCBatch);
Attivazione di OpenEdge Change Data Capture
Ora attiviamo il meccanismo CDC stesso, con l'aiuto del quale i dati verranno replicati in un'area tecnologica aggiuntiva. A ciascun database di origine Progress OpenEdge è necessario aggiungere aree di archiviazione separate in cui verranno duplicati i dati di origine e attivare il meccanismo stesso utilizzando il comando proutil.
Procedura di esempio per il database bisquit
- Copia dal catalogo C:Pro2db файл cdcadd.st nella directory del database di origine bisquit.
- Descriviamo in cdcadd.st estensioni a dimensione fissa per le regioni "Sostituisci Area CDC" и "SostituisciCDCArea_IDX". Puoi aggiungere nuove aree di stoccaggio online: prostrct addonline bisquit cdcadd.st
- Attiva OpenEdge CDC:
proutil bisquit -C abilitacdc area "ReplCDCArea" indicearea "ReplCDCArea_IDX" - È necessario creare i seguenti utenti nel database di origine per identificare i processi in esecuzione:
UN. pro2adm – per la connessione dal pannello amministrativo di Pro2.
B. pro2etl – per connettere processi ETL (ReplBatch).
C. pro2cdc – per connettere processi CDC (CDCBatch).
Creazione di un titolare dello schema per DataServer per Oracle
Successivamente, dobbiamo creare un database Schema Holder sul server in cui i dati dal DBMS Progress verranno replicati nel DBMS Oracle. DataServer Schema Holder è un database Progress OpenEdge vuoto senza utenti o dati dell'applicazione, contenente una mappa di corrispondenza tra le tabelle di origine e le tabelle Oracle esterne.
Il database Schema Holder per Progress OpenEdge DataServer for Oracle for Pro2 deve trovarsi sul server del processo ETL; viene creato separatamente per ciascun ramo.
Come creare un titolare dello schema
- Scompatta la distribuzione Pro2 in una directory /pro2
- Crea e vai alla directory /pro2/dbsh
- Creare un database Schema Holder utilizzando il comando copia $DLC/bisquitsh vuoto
- Esecuzione della conversione bisquitsh nella codifica richiesta, ad esempio in UTF-8 se i database Oracle hanno la codifica UTF-8: proutil bisquitsh -C convchar converte UTF-8
- Dopo aver creato un database vuoto bisquitsh connettersi ad esso in modalità utente singolo: pro bisquitsh
- Andiamo al Dizionario dei dati: Strumenti -> Dizionario dati -> DataServer -> Utilità ORACLE -> Crea schema DataServer
- Avvia il titolare dello schema
- Configurazione del broker Oracle DataServer:
UN. Avvia AdminServer.
proadsv -inizio
B. Avvio del broker Oracle DataServer
oraman -nome orabroker1 -start
Impostazione del pannello amministrativo e dello schema di replica
Utilizzando il pannello amministrativo di Pro2, vengono configurati i parametri di Pro2, inclusa l'impostazione dello schema di replica e la generazione di processi ETL (Libreria processore), programmi di sincronizzazione primari (Processore Bulk-Copy), trigger di replica e policy OpenEdge CDC. Sono inoltre disponibili strumenti primari per il monitoraggio e la gestione dei processi ETL e CDC. Prima di tutto, impostiamo i file dei parametri.
Come configurare i file dei parametri
- Vai al catalogo C:Pro2bpreplScript
- Apri il file per la modifica replProc.pf
- Aggiungi i parametri di connessione al database di replica CDC:
# Database di replica
-db cdc -ld repl -H <nome host database principale> -S <porta broker database cdc>
-U pro2admin -P <password> - aggiungere a replProc.pf parametri di connessione ai database di origine e allo Schema Holder sotto forma di file di parametri. Il nome del file dei parametri deve corrispondere al nome del database di origine da connettere.
# Connettiti a tutte le fonti replicate BISQUIT
-pf bpreplscriptsbisquit.pf - aggiungere a replProc.pf parametri per la connessione a Schema Holder.
Titolare dello schema DB #Target Pro
-db bisquitsh -ld bisquitsh
-H <nome host del processo ETL>
-S <porta broker biskuitsh>
-dbbisquitsql
-ld bisquitsql
-dt ORACOLO
-S 5162 -H <nome host broker Oracle>
-DataService obroker1 - Salvare il file dei parametri replProc.pf
- Successivamente, è necessario creare e aprire per la modifica i file dei parametri per ciascun database di origine connesso nella directory C:Pro2bpreplScript: bisquit.pf. Ogni file pf contiene parametri per la connessione al database corrispondente, ad esempio:
-db bisquit -ld bisquit -H <nome host> -S <porta broker>
-U pro2admin -P <password>
Per configurare le scorciatoie di Windows, devi andare alla directory C:Pro2bpreplScript e modifica il collegamento "Pro2 - Amministrazione". Per fare ciò, apri le proprietà del collegamento e nella riga Inizia tra indicare la directory di installazione di Pro2. Un'operazione simile deve essere fatta per le scorciatoie “Pro2 – Editor” e “RunBulkLoader”.
Impostazione amministrazione Pro2: caricamento della configurazione iniziale
Lanciamo la console.
Vai su “Mappa DB”.
Per collegare i database in Pro2 – Amministrazione, vai alla scheda Mappa DB. Aggiungi la mappatura dei database di origine - Titolare dello schema - Oracle.
Vai alla scheda Mappatura. Elencato Database di origine Per impostazione predefinita, viene selezionato il primo database di origine connesso. A destra dell'elenco dovrebbe esserci un'iscrizione Tutti i database collegati — i database selezionati sono collegati. In basso a sinistra dovresti vedere un elenco di tabelle Progress da bisquit. Sulla destra c'è un elenco di tabelle dal database Oracle.
Creazione di schemi e database SQL in Oracle
Per creare una mappa di replica, devi prima generare schema SQL nell'Oracolo. In Pro2 Administration eseguiamo la voce di menu Strumenti -> Genera codice -> Schema di destinazione, quindi nella finestra di dialogo Seleziona Database seleziona uno o più database di origine e spostali a destra.
Fare clic su OK e selezionare la directory in cui salvare gli schemi SQL.
Successivamente creiamo la base. Questo può essere fatto, ad esempio, tramite Sviluppatore Oracle SQL. Per fare ciò, ci colleghiamo al database Oracle e carichiamo lo schema per l'aggiunta di tabelle. Dopo aver modificato la composizione delle tabelle Oracle, è necessario aggiornare gli schemi SQL nello Schema Holder.
Una volta completato con successo il download, esci dal database bisquitsh e apri il pannello amministrativo di Pro2. Le tabelle del database Oracle dovrebbero essere visualizzate nella scheda Mapping a destra.
Mappatura delle tabelle
Per creare una mappa di replica, nel pannello amministrativo di Pro2, vai alla scheda Mappatura e seleziona il database di origine. Fare clic su Mappa tabelle, selezionare Seleziona modifiche a sinistra delle tabelle da replicare in Oracle, spostarle a destra e confermare la selezione. Verrà creata automaticamente una mappa per i tavoli selezionati. Ripetiamo l'operazione per creare una mappa di replica per altri database di origine.
Generazione della libreria del processore di replica Pro2 e dei programmi del processore di copia di massa
La libreria del processore di replica è progettata per processi di replica personalizzati (ETL) che elaborano la coda di replica Pro2 e inviano modifiche al database Oracle. I programmi della libreria del processore di replica vengono salvati automaticamente nella directory dopo la generazione bprepl/repl_proc (parametro PROC_DIRECTORY). Per generare la libreria del processore di replica, vai a Strumenti -> Genera codice -> Libreria processore. Al termine della generazione, i programmi verranno visualizzati nella directory bprepl/repl_proc.
I programmi Bulk Load Processor vengono utilizzati per sincronizzare i database Progress di origine con il database Oracle di destinazione basato sul linguaggio di programmazione Progress ABL (4GL). Per generarli, vai alla voce di menu Strumenti -> Genera codice -> Processore di copia in blocco. Nella finestra di dialogo Seleziona database, selezionare i database di origine, spostarli sul lato destro della finestra e fare clic OK. Al termine della generazione, i programmi verranno visualizzati nella directory bpreplrepl_mproc.
Impostazione dei processi di replica in Pro2
La suddivisione delle tabelle in set serviti da un thread di replica separato migliora le prestazioni e l'efficienza di Pro2 Oracle. Per impostazione predefinita, tutte le connessioni create nella mappa di replica per le nuove tabelle di replica sono associate al thread numero 1. Si consiglia di separare le tabelle in thread diversi.
Le informazioni sullo stato dei thread di replica vengono visualizzate nella schermata Amministrazione di Pro2 nella scheda Monitor nella sezione Stato della replica. Una descrizione dettagliata dei valori dei parametri può essere trovata nella documentazione di Pro2 (directory C:Pro2Docs).
Crea e attiva le policy CDC
Le policy sono un insieme di regole che consentono al motore OpenEdge CDC di monitorare le modifiche alle tabelle. Al momento in cui scrivo, Pro2 supporta solo le policy CDC con livello 0, ovvero vengono monitorati solo i fatti registrare i cambiamenti.
Per creare una policy CDC, nel pannello amministrativo, vai alla scheda Mapping, seleziona il database di origine e fai clic sul pulsante Aggiungi/Rimuovi policy. Nella finestra Seleziona modifiche che si apre, seleziona sul lato sinistro e sposta a destra le tabelle per le quali devi creare o eliminare una policy CDC.
Per attivare, aprire nuovamente la scheda Mapping, selezionare il database di origine e fare clic sul pulsante (In)Attivare le policy. Seleziona e sposta nella parte destra della tabella le polizze per le quali vuoi attivarle, clicca su OK. Successivamente vengono contrassegnati in verde. Usando (In)Attivare le policy Puoi anche disattivare le policy CDC. Tutte le transazioni vengono eseguite online.
Dopo l'attivazione del criterio CDC, le note sui record modificati vengono salvate nell'area di archiviazione "Sostituisci Area CDC" secondo il database di origine. Queste note verranno elaborate attraverso un processo speciale CDCBatch, che in base ad essi creerà note nella coda di replica Pro2 nel database cdc (sostituzione).
Pertanto, abbiamo due code per la replica. La prima fase è CDCBatch: dal database di origine, i dati vanno prima al database CDC intermedio. La seconda fase avviene quando i dati vengono trasferiti dal database CDC a Oracle. Questa è una caratteristica dell'architettura attuale e del prodotto stesso: finora gli sviluppatori non sono riusciti a stabilire una replica diretta.
Sincronizzazione primaria
Dopo aver abilitato il meccanismo CDC e configurato il server di replica Pro2, dobbiamo avviare la sincronizzazione iniziale. Comando di sincronizzazione iniziale:
/pro2/bprepl/Script/replLoad.sh bisquit nome-tabella
Una volta completata la sincronizzazione iniziale, è possibile avviare i processi di replica.
Avvio dei processi di replica
Per avviare i processi di replica è necessario eseguire uno script replbatch.sh. Prima di iniziare, assicurati che siano presenti script replbatch per tutti i thread: replbatch1, replbatch2, ecc. Se tutto è a posto, apri la riga di comando (ad esempio, proenv), vai alla directory /bprepl/script e avviare lo script. Nel pannello amministrativo, controlliamo che il processo corrispondente abbia ricevuto lo stato IN CORSO.
Giudizio
Dopo l'implementazione, abbiamo accelerato notevolmente il caricamento delle informazioni nel data warehouse aziendale. I dati entrano automaticamente in Oracle online. Non è necessario perdere tempo eseguendo query di lunga durata per raccogliere dati da sistemi diversi. Inoltre, in questa soluzione il processo di replica può comprimere i dati, il che ha anche un effetto positivo sulla velocità. Ora la riconciliazione giornaliera del sistema BISKVIT con altri sistemi ha iniziato a richiedere 15-20 minuti invece di 2-2,5 ore, e la riconciliazione completa ha richiesto diverse ore invece di due giorni.
Fonte: habr.com