← vissza az akli.hu portálra v1.0 · 2026. március

SDS — fejlesztői dokumentáció

Script Dispatcher
Rendszer.

Szabványos, dokumentált, visszakövethető és automatizált keretrendszer Oracle adatbázis-javító scriptek biztonságos futtatásához — minimális emberi beavatkozással, maximális átláthatósággal.

01

A fejlesztés háttere és célja

Az üzemeltetett rendszerben időről időre szükségessé válik adatbázis-szintű közvetlen beavatkozás. Ezek három fő forrásból erednek:

Korábban ezeket a javításokat manuálisan, ad-hoc módon, dokumentálatlanul hajtották végre. Egy-egy egyedi adatjavítás akár 45 percet is igénybe vehetett, nem volt nyoma, ki mikor mit futtatott, és nem volt közvetlen kapcsolat a jegykezelő rendszerrel.

Cél: szabványos, dokumentált, visszakövethető és automatizált keretrendszer kialakítása az adatbázis-javító scriptek biztonságos futtatásához — minimális emberi beavatkozással, maximális átláthatósággal.

02

Rendszer architektúra

Az SDS rendszer két különálló adatbázis-rétegből épül fel, amelyek egy DB linken keresztül kommunikálnak egymással.

Kezelői réteg Oracle APEX feltöltés · indítás · eredmény DB LINK Végrehajtó réteg kérés · eredmény · napló dispatcher csomag Oracle Scheduler aszinkron job-ok Üzleti adatok sémája a javító eljárások itt olvasnak és írnak

a kezelői réteg sosem nyúl közvetlenül az üzleti adatokhoz — mindig a végrehajtó réteg dispatcherén keresztül

2.1 Főbb adatbázis objektumok

Végrehajtó séma

Kérelem táblaMinden végrehajtási kérelem rögzítése: ki, mikor, mit indított, aktuális státusz.
Paraméter táblaA kéréshez tartozó összes paraméter tárolása (név, típus, irány, érték).
Eredmény táblaFutás eredménye: sikeres-e, futási idő, visszaadott üzenet.
Napló táblaRészletes soronkénti futási napló (INFO / WARN / ERROR szintek).
Dispatcher csomagGenerikus végrehajtó: indítás, lekérdezés, naplózás, paraméterkezelés.
Végrehajtó motorKódvédett végrehajtó csomag. Tartalmaz környezet-ellenőrzést — csak engedélyezett adatbázisban futhat.

Kezelői réteg (APEX)

Audit táblaKi, mikor, melyik session-ből indított feladatot.
Paraméter auditAz indításkor megadott paraméterek másolata — visszakereshető állapot.
Staging táblaFeltöltött sorok átmeneti tárolása: PENDING → DISPATCHED → DONE / ERROR.
APEX csomagAz APEX oldalon futó logika: feltöltés, indítás, eredmény visszaolvasás.

03

Működési folyamat

Egy feladat végrehajtása hat lépésből áll:

1 Feladatlista 2 Feltöltés 3 Ellenőrzés 4 Indítás 5 Aszinkron futás 6 Eredmény
1

Feladatlista összeállítása

A felhasználó elkészíti a futtatandó tételek listáját CSV fájlban. Minden sor egy eljárás-hívást jelent a szükséges paraméterekkel.

2

Feltöltés

CSV feltöltése az APEX felületen. A rendszer azonnal feldolgozza: soronként beolvassa, staging táblába tölti, batch azonosítót rendel hozzá.

3

Ellenőrzés

A feltöltött sorok megtekinthetők és ellenőrizhetők indítás előtt. Hibás sorok már itt jelzésre kerülnek.

4

Indítás

Egy gombnyomásra minden PENDING sor elküldésre kerül a végrehajtó adatbázisba. Az audit táblában rögzül az indító felhasználó, időpont és session.

5

Aszinkron futás

A végrehajtó réteg Oracle Scheduler job-okat hoz létre. Ezek egymástól függetlenül futnak le.

6

Eredmény visszaolvasás

Az APEX felületen lekérdezhető az eredmény: sikeres-e, mennyi ideig futott, mit írt vissza az eljárás.

04

Biztonság és nyomon követhetőség

A rendszer kétszintű naplózást alkalmaz — a kezelői és a végrehajtó rétegen egyaránt.

4.1 Kezelői réteg (APEX)

  • Felhasználó azonosításSession alapján automatikus — nem lehet névtelenül indítani feladatot.
  • Kétlépéses folyamatA feltöltés és az indítás szét van választva — nem futhat le véletlen utasítás.
  • Batch azonosítóMinden feltöltési csomaghoz egyedi azonosító keletkezik, amely a jegykezelő rendszerhez kapcsolódási pontként szolgál.
  • Audit táblaMinden indítás archiválva: eljárás neve, paraméterek, időpont, felhasználói session azonosító.

4.2 Végrehajtó réteg

  • Kérelem rögzítéseA kérelem azonnal és visszavonhatatlanul rögzítésre kerül az indítás pillanatában.
  • Paraméter archiválásA futáshoz használt pontos paraméterek tárolva maradnak.
  • Részletes futási naplóSoronkénti naplózás INFO / WARN / ERROR szinteken.
  • Eredmény archívSiker/kudarc, futási idő és a teljes visszaadott üzenet tárolva.
  • Környezet ellenőrzésA végrehajtó motor csak az engedélyezett adatbázis-környezetekben futhat le.
  • KódvédelemA végrehajtó motor Oracle wrap utility-vel védett — a forráskód nem olvasható.
APEX staging APEX audit végrehajtó kérelem végrehajtó eredmény részletes napló

audit lánc — bármely időpontban visszakereshető: ki indította, milyen paraméterekkel, mi volt az eredmény

05

Időmegtakarítás

Egyedi javítás

korábban
30–45 perc
most
2–3 perc

Tömeges feldolgozás

korábban
fél munkanap vagy több
most
5–10 perc

a sávok hossza szemléltető jellegű, nem lineáris időskála

Dokumentálás

manuális, gyakran elmarad automatikus, teljes körű, visszakereshető

06

A rendszer által kezelt javítási típusok

Az SDS keretrendszer generikus — bármilyen Oracle tárolt eljárás meghívható rajta keresztül. A következő javítási típusok kerültek eddig implementálásra:

6.1

Hierarchikus adatstruktúra-kezelés

Szülő-gyermek kapcsolatban lévő adatok módosítása: lezárás dátummal, aktív jelző kezeléssel, új kapcsolat létrehozása duplikátum védelemmel.

6.2

Entitás-adat javítás

Adott rekord meghatározott mezőjének módosítása. Duplikátum védelem: ha a módosítás már megtörtént, a rendszer kihagyja és naplózza.

6.3

Tiltás / feloldás kezelés

Adott entitás tiltólistára helyezése vagy a tiltás feloldása, teljes validációval. Tömeges feldolgozáshoz XLSX/CSV konverter script áll rendelkezésre.

07

Azonosított és kezelt technikai problémák

ORA-02064

DB linken keresztüli tranzakciókezelés

Probléma

Oracle nem engedélyezi, hogy DB linken keresztül hívott eljárás a hívó tranzakciójában adatmódosítást (DML) végezzen.

Megoldás

Minden érintett adatmódosítás önálló tranzakcióba (PRAGMA AUTONOMOUS_TRANSACTION) került, külön segédeljárásokkal az atomikus végrehajtáshoz.

PLS-00564

CLOB típus korlátozása DB linken

Probléma

DB linken keresztül nem lehet CLOB típusú OUT paramétert átadni.

Megoldás

VARCHAR2(32767) típusú wrapper eljárás készült, amely a kezelői réteg számára olvasható formában adja vissza az eredményt.

ORA-00060

Holtpont tömeges párhuzamos futtatásnál

Probléma

Tömeges feldolgozásnál párhuzamosan futó job-ok körkörösen egymásra vártak, ami holtpontot (deadlock) okozott.

Gyökérok

Idegen kulcs (FK) oszlopokon hiányzó indexek — ezek nélkül Oracle a DELETE műveletnél az egész gyermektáblát zárolja, ami párhuzamos futásnál kölcsönös blokkolást okoz.

Azonosítás

Rendszer-katalógus lekérdezéssel meghatározásra kerültek az indexeletlen FK oszlopok.

Megoldás

Hiányzó indexek létrehozása ONLINE opcióval (leállás nélkül), plusz a package-szintű globális változók lokális változókra cserélése a párhuzamos futások közötti adatkeveredés megelőzésére.

NLS_LANG

Karakterkódolási probléma kódvédelem után

Probléma

A végrehajtó motor kódvédelmét (Oracle wrap) követően az ékezetes karakterek elvesztek a napló üzenetekben.

Megoldás

A wrap futtatása előtt UTF-8 karakterkészlet beállítása (NLS_LANG), illetve a napló üzenetek ékezet nélküli szövegekre cserélése robusztusabb megoldásként.

08

Jövőbeli fejlesztési irányok

Több célrendszer támogatása

A jelenlegi egycélrendszeres architektúra bővíthető további adatbázisok bekötésével — az APEX felületen célrendszer-választóval, a háttérben regisztrált DB linkekkel.

Éles üzem

A rendszer tesztkörnyezetben validált és éles üzemre kész. Élesítéshez szükséges: DB linkek létrehozása az éles adatbázisokhoz, a végrehajtó csomag telepítése az éles sémába.

További javító modulok

Az SDS keretrendszer bővíthető új javító eljárásokkal programozói beavatkozás nélkül — elegendő az eljáráscsomag és a hozzá tartozó CSV minta elkészítése.

Konverter eszköz

A meglévő XLSX/CSV konverter script tovább általánosítható, hogy tetszőleges eljárást kezeljen, ne csak egy specifikus típust.

09

Összefoglalás

Az SDS rendszer egy szabványos, biztonságos és teljes mértékben dokumentált keretrendszert biztosít az Oracle adatbázis-javító eljárások futtatásához. Bevezetésével az egyedi javítások ideje 45 percről 2–3 percre csökkent, a dokumentálás automatikussá vált, és a teljes folyamat visszakereshető a jegykezelő rendszer batch azonosítóján keresztül. A rendszer éles üzemre kész.

Hatékonyság

95%-os időmegtakarítás egyedi javításoknál; tömeges feldolgozásnál arányosan több.

Biztonság

Kétlépéses, jóváhagyásos folyamat — véletlen futtatás kizárva.

Nyomon követés

Teljes audit lánc a kezelői felülettől a végrehajtó adatbázisig, minden futás archiválva.

Szabványosítás

Egységes eljárásrend minden javításhoz, CSV alapú tömeges feldolgozással.

Bővíthetőség

Új scriptek bevezetése programozói beavatkozás nélkül, pusztán eljáráscsomag + CSV elkészítésével.

Kapcsolódás

Jegykezelő rendszerhez azonnal illeszthető batch azonosítón keresztül.