Kontaktné údaje
- info@ipesoft.com
- +421 907 703 854
- Obchodná 9076/3D
010 08 Žilina
Slovensko
© Copyright IPESOFT 2023
V dnešnom článku si povieme, ako dokáže D2000 pracovať s databázami. Tentokrát nebudeme hovoriť o jeho „zabudovaných“ databázach (konfiguračnej, monitorovacej a archívnej), ale sústredíme sa na prístup k aplikačne špecifickým databázam, ktorých štruktúra aj obsah je plne v rukách aplikačných špecialistov a konzultantov, ktorí vytvárajú SCADA, MES, EMS a iné aplikácie postavené na technológii D2000.
Proces DbManager
Podobne ako v systéme D2000 existujú špecializované procesy na komunikáciu (D2000 KOM), skriptovanie (D2000 Event Handler) alebo archiváciu (D2000 Archív), existuje aj špecializovaný proces na prácu s aplikačnými databázami – D2000 DbManager. Tento proces pristupuje do SQL databáz a vykonáva všetky potrebné akcie. Požiadavky na DbManager prichádzajú z procesov D2000 Event Handler (skripty vykonávané na serveri) a z procesov D2000 HI (priamy prístup užívateľov do databáz cez zobrazovač Browser + aktívne schémy so skriptami).
Nasledujúci obrázok ukazuje časť architektúry systému D2000. Ku jadru systému (proces D2000 Server) sú pripojení traja užívatelia (D2000 HI) a jeden proces D2000 Event Handler. Ich požiadavky na SQL databázy obsluhujú dva procesy D2000 DbManager. Ďalšie typy procesov sme pre prehľadnosť nekreslili.
Proces D2000 DbManager dokáže pristupovať k databázam dvoma rôznymi spôsobmi:
• Cez ODBC rozhranie k ľubovolnej databáze, pre ktorú je nainštalovaný v systéme ODBC ovládač a vytvorené ODBC DSN (Data Source Name). Bežne pracujeme s databázami PostgreSQL, MySql, MariaDB, Sybase SQL Anywhere, Microsoft SQL Server, Informix, Firebird a inými.
• Cez OCI rozhranie (Oracle Client Interface) k Oracle databáze. V minulosti bola Oracle databáza široko používaná vo veľkých D2000 aplikáciách a preto bola vytvorená špecializovaná verzia DbManager procesu využívajúca pokročilé vlastnosti OCI. Proces DbManager v OCI verzii existoval aj na platformách ako OpenVMS alebo HP-UX.
Existujú aj ďalšie dôvody, prečo môže byť v jednej aplikácii spustených niekoľko procesov DbManager:
• Niektoré staršie ODBC ovládače môžu byť dostupné iba v 32-bitovej verzii (nutný je teda 32-bitový DbManager), iné sú 64-bitové (nutný je 64-bitový DbManager).
• Z dôvodu oddelenia sietí môže vzniknúť potreba umiestniť proces DbManager do siete s databázou, prípadne priamo na databázový server. Toto sa týka najmä tzv. interfejsných databáz, t.j. databáz slúžiacich na prepojenie roznych systémov (napr. MES systém a ERP systém).
V rámci DODM modelu (o ktorom si môžete prečítať samostatný blog) je proces DbManager rodičom objektov typu Databáza a tie sú rodičmi objektov typu Tabuľka.
Objekt Databáza
Objekt Databáza reprezentuje SQL databázu spolu s prístupovými právami do nej, keďže obsahuje aj konfiguráciu užívateľského mena a hesla. Preto je potrebné vytvoriť niekoľko objektov typu Databáza, pokiaľ potrebujeme pristupovať do SQL databázy s rôznymi prístupovými právami (napr. na prístup k rôznym schémam).
Proces D2000 DbManager má optimalizáciu na paralelnú prácu viacerých užívateľov objektom typu Databáza. Preto je schopný vytvoriť viacero spojení s jednou SQL databázou. Každé takéto spojenie je obsluhované vlastným taskom a môže pracovať v transakčnom režime (rezervované pre konkrétny ESL skript, ktorý transakciu vytvoril) alebo v netransakčnom režime (zdieľané viacerými skriptami alebo procesmi D2000 HI, pričom po každej operácii sa automaticky vykonáva COMMIT, preto takéto spojenie voláme aj automatické). V konfiguračnom dialógu objektu Databáza sa dá nastaviť počet predpripravených spojení (vznikajú po štarte procesu DbManager), obmedziť maximálny počet spojení, maximálny počet netransakčných (automatických) spojení a dokonca rezervovať automatické spojenia pre zobrazovač Browser.
Dá sa tiež špecifikovať, po akom čase sa majú zatvárať už nepoužívané spojenia (vytvorené nad rámec predpripravených spojení). DbManager umožňuje vytvorené spojenia recyklovať – keďže vytvorenie spojenia môže predstavovať pre niektoré SQL databázy pomerne náročnú operáciu s vysokou réžiou (napr. pre Oracle).
Pokiaľ sa nachádza na sieti medzi procesom DbManager a SQL databázou firewall, môže byť užitočné špecifikovať prázdne operácie po nejakej dobe nečinnosti – niekedy sa stáva, že firewall dlhšie nepoužívané TCP spojenie „zruší“ a keď ho chce DbManager znovu použiť, dôjde k chybe. Prázdne operácie umožňujú priebežne kontrolovať stav spojenia s SQL databázou a v prípade rozpadu ho znovu vytvoriť.
Dôležitá je aj možnosť nastavenia interpretácie časových údajov v databáze – časy môžu byť v lokálnom čase (podľa pásmového času servera, na ktorom je spustený DbManager), prípadne v monotónnom čase so špecifikovaným offsetom od UTC.
Hodnota objektu typu Databáza je rovná aktuálnemu počtu spojení, ktoré má proces DbManager pre tento objekt vytvorené.
Objekt Tabuľka
Objekt Tabuľka reprezentuje tabuľku alebo pohľad (view) v SQL databáze. Každá tabuľka má svoju štruktúru – názvy stĺpcov a dátové typy, ktoré sú definované objektom typu Definícia štruktúry. Je možné nakonfigurovať, ktoré stĺpce tvoria kľúč, ktoré su voliteľné (t.j. existujú v definícii štruktúry v D2000, ale nie v SQL databáze) a ktoré sú nenulové.
Na objekte Tabuľka je možné definovať aj typ prístupu k tabuľke (žiaden, čítanie, čítanie+zápis).
Užitočnou vlastnosťou je zadefinovanie časovej hĺbky. DbManager dokáže automaticky mazať dáta v tabuľke, ktorých definovaný stĺpec (typu Absolútny čas) je starší ako časová hĺbka. Alternatívne je možné definovať rôzne časové hĺbky pre rôzne obdobia pomocou objektu typu Účel údajov.
Kvôli zákonom na ochranu údajov (GDPR) bola implementovaná aj možnosť automatickej anonymizácie dát vo zvolených stĺpcoch na základe nastaveného časového stĺpca.
Príklad použitia: údaje v stĺpcoch Meno, Priezvisko, Datum_narodenia v tabuľke Zmluvy budú anonymizované po 5 rokoch na základe stĺpca Cas_ukoncenia_zmluvy. Anonymizácia bude prebiehať tak, že Meno a Datum_narodenia sa vymažú, Priezvisko sa zmení na „Anonymizované yyyy-mm-dd“, kde yyyy-mm-dd sa nahradí dátumom, v ktorom bola anonymizácia uskutočnená.
Operácie s databázou
Akcie, ktoré vykonáva DbManager, môžeme rozdeliť na niekoľko skupín.
Akcie zobrazovača Browser – jedná sa o priame interaktívne prezeranie dát užívateľom v rámci schémy alebo priamo v D2000 HI. Užívateľ môže prechádzať medzi jednotlivými stránkami a podľa nastavených prístupových práv a vlastností Browsera prípadne editovať, vkladať nové riadky a mazať riadky.
Akcie zo skriptu – akcie vykonávané v ESL skripte (a ich ekvivalenty dostupné z jazyka Java). Tieto sa dajú ďalej rozdeliť do viacerých kategórií:
• Práca s transakciami: otváranie/zatváranie transakcií, ich commitovanie a rollback. Sem patria akcie:
Handle transakcie je následne možné použiť pri akciách patriacich do ďalších kategórií. Ak tieto akcie nepoužívajú handle transakcie, tak sa COMMIT vykonáva automaticky po každej akcii.
• Štandardná práca s dátami – na základe podmienky (WHERE) alebo na základe kľúčového stĺpca (stĺpcov) definovaných na objekte Tabuľka je možné čítať/vkladať/aktualizovať riadky (jeden alebo viaceré) v tabuľke. Sem patria akcie:
o DB_CONNECT – „pripojenie sa“ k tabuľke
o DB_DISCONNECT - „odpojenie sa“ od tabuľky
o DB_DELETE – mazanie dát v tabuľke
o DB_INSERT – vkladanie
o DB_UPDATE - aktualizácia
o DB_INSUPD – kombinácia vkladania a aktualizácie (ak už riadok s daným kľúčom existuje)
o DB_READ – čítanie
• Zrýchlená práca s dátami – akcie DBS_* umožňujú vynechať DB_CONNECT/DB_DISCONNECT, ostatná funkcionalita je identická:
o DBS_READ
• Akcie na prácu s BLOB-mi: BLOB-y sa používajú v databázach na uchovanie veľkých binárnych dát (napr. PDF faktúry). Tieto sú na strane D2000 reprezentované ako súbory. Na čítanie/zápis slúžia špeciálne akcie:
o DB_READ_BLOB, DBS_READ_BLOB – čítanie BLOBu do súboru
o DB_UPDATE_BLOB, DBS_UPDATE_BLOB – uloženie BLOBu do SQL databázy
• Stránkovaná práca s dátami: jedná sa o skriptové akcie, ktoré umožňujú stránkovaný prístup k dátam. Pre veľké objemy dát je lepšie dáta načítavať a spracovať v skripte postupne, napr. po 100 riadkoch – ekvivalent stránkovania v Browseri.
o PG_CONNECT - „pripojenie sa“ k tabuľke a nastavenie veľkosti stránky
o PG_DISCONNECT - „odpojenie sa“ od tabuľky
o PG_READ – čítanie zadanej stránky dát
o PG_INSERT – vloženie jedného riadku do tabuľky
o PG_DELETE – zmazanie jedného riadku v tabuľke
o PG_UPDATE – aktualizácia jedného riadku v tabuľke
• Akcie na „variabilnú“ prácu s databázou: ak nie je dopredu známe, z akej tabuľky a ktoré stĺpce treba čítať, je možné použiť príkaz SQL_SELECT, ktoré umožňujú špecifikovať celý SQL príkaz. Tento môže byť aj parametrizovaný (SQL_PREPARE a ďalšie s ním spojené). Výhodou parametrizovaných príkazov je možnosť ich recyklácie v DbManageri (spustenie viackrát s inými parametrami) aj v SQL databáze (SQL príkaz sa paruje a vytvára sa preň exekučný plán iba raz). Patria sem aj akcie na vykonanie ľubovolného SQL príkazu a spustenie uloženej procedúry (stored procedure):
o SQL_CONNECT - „pripojenie sa“ k databáze
o SQL_DISCONNECT - „odpojenie sa“ od databázy
o SQL_EXEC_DIRECT – spustenie ľubovolného SQL príkazu (bez vrátenia dát)
o SQL_EXEC_PROC – vykonanie uloženej procedúry so zoznamom parametrov
o SQL_SELECT – spustenie ľubovolného SQL SELECT príkazu (bez parametrizácie)
o SQL_PREPARE – pripravenie ľubovolného SQL SELECT príkazu (s parametrizáciou)
o SQL_BINDIN – nastavenie hodnôt parametrov pre SQL_PREPARE
o SQL_FETCH – načítanie 1 alebo viac riadkov vrátených po SQL_PREPARE
o SQL_FREE – uvoľnenie zdrojov a ukončenie SQL_PREPARE
Po akcii SQL_PREPARE je možné viackrát vykonávať sekvenciu SQL_BINDIN (nastavenie parametrov – zakaždým iných) a opakovaný SQL_FETCH (čítanie vrátených riadkov). Nakoniec volaním SQL_FREE prácu ukončíme. Takto sa implementuje recyklovanie parametrizovaného SQL príkazu.
• Špeciálne akcie: iné špecializované akcie:
o DB_REFRESH_TABLE – vynútenie obnovy dát zobrazených v Browseri. Štandardne po zmene dát cez konkrétny objekt typu Tabuľka nasleduje obnovenie dát pre Browsery, v ktorých je táto Tabuľka zobrazená (pokiaľ nemajú konfiguračne obnovu dát vypnutú). Môže ale nastať situácia, že sa dáta zmenia iným spôsobom (napr. cez inú Tabuľku alebo akciou SQL_EXEC_DIRECT) a je potrebné obnovu vynútiť zo skriptu.
o DB_SET_PROCESS_PARAMS – nastavenie alebo zrušenie „kontextu“. Kontext znamená nastaviť pomenované parametre (dvojice meno-hodnota), ktoré sa ukladajú v dočasnej globálnej tabuľke (global temporary table) D2000_PROCESS_PARAMS. Kontext je štandardne spoločný pre jeden D2000 HI alebo D2000 Event Handler proces, prípadne sa dá obmedziť štartovacím parametrom --batch_mode na eventy spustené akciou OPENEVENT s rovnakým číslom inštancie. Kontext je viditeľný nielen v rámci D2000, ale môžu ho využívať aj pohľad a uložené procedúry v SQL databáze. Príkladom môže byť použitie dvoch pomenovaných parametrov na nastavenie obdobia (PERIOD_FROM, PERIOD_TO), pre ktoré sa budú napr. zobrazovať faktúry pomocou databázových pohľadov.
o ON DB_CHANGE – zaregistrovanie handleru pre zmenu dát. Handler bude volaný, keď nastane zmena obsahu databázovej tabuľky, prípadne bola volaná akcia DB_REFRESH_TABLE, prepla sa aktívna inštancia procesu DbManager (alebo sa prepol redundantný D2000 Server), prípadne bola tabuľka vymazaná z konfigurácie.
Záver
Proces D2000 DbManager je súčasťou D2000 už viac ako dve desaťročia. Za ten čas prešiel optimalizáciou a prerábkou na multithreadovú aplikáciu, aby zvládal prácu pre desiatky užívateľov nielen v aplikáciách typu SCADA či MES, ale aj v čiste databázovo-orientovaných aplikáciach typu ETRM (Energy Trading & Risk Management), v ktorých hrajú aplikačné databázy primárnu úlohu.
V pokračovaní dnešného blogu si povieme niečo o možnostiach ladenia, debugovania a tuningu databázových akcií v D2000.
2.5.2024, Ing. Peter Humaj, www.ipesoft.com