- Ventilátorok - Ház, CPU (borda, radiátor), VGA
- Kormányok / autós szimulátorok topikja
- OLED monitor topik
- Kompakt vízhűtés
- Megjelent a Red Magic kompakt OLED kijelzős gaming táblagépe
- Nvidia GPU-k jövője - amit tudni vélünk
- ThinkPad (NEM IdeaPad)
- Hobby elektronika
- Milyen házat vegyek?
- Milyen notebookot vegyek?
Új hozzászólás Aktív témák
-
#6013
Neil Watts
veterán
Sziasztok!
Kerdesem nem kozvetlenul SQL-hez kapcsolodik, sokkal inkabb Oracle DB-hez.
Itthoni kiserletezes soran Password4j 1.8.2-t/1.8.3-at szeretnek Oracle 23ai free ala betolteni, mert legtobbszor
ora-29532 java call terminated by uncaught java exception java.lang.noclassdeffounderror org/slf4j/loggerfactory-t kapok az implementaciom futtatasa soran. 19c alatt loadjava -v -thin -user… modon siman betolt.Reprodukalni igy tudod:
Probald meg az slf4j-api-t majd a password4j 1.8.2-t Oracle-be tolteni:
loadjava -r -v -f -s -g "$SCHEMA_NAME" -resolve -user "$SCHEMA_NAME/$SCHEMA_PASSWORD@$CONTAINER_NAME" "$jar_file"loadjava -r -v -f -s -g "$SCHEMA_NAME" -append-resolver "((* -))" -jarsasdbobjects -user "$SCHEMA_NAME/$SCHEMA_PASSWORD@$CONTAINER_NAME" "$jar_file"loadjava -v -thin -user "$SCHEMA_NAME/$SCHEMA_PASSWORD@$CONTAINER_NAME" "$jar_file"(A peldak egy shell script-embol szarmaznak)
Nagy valoszinuseggel az alabbit fogod kapni:
ora-29532 java call terminated by uncaught java exception java.lang.noclassdeffounderror org/slf4j/loggerfactorymikor pl. Argon2-es implementaciodat szeretned futtatni. 1.8.3-ra valtastol sem ereztem valtozast, sajnos. Lehet valamit ugy csinalok ahogy nem kene, de mar a loadjavat atnyalaztam elegge.
Elvart mukodes:
Azt varnam, hogy betoltes utan hasznalni tudjam projektjeimben a Password4j-t.
Kornyezet:
OS: Oracle Linux 8 podman-ben (Rocky Linux 9-en)
DB: Oracle 23ai free
JDK version:Adatbazisban:
SELECT dbms_java.get_ojvm_property(PROPSTRING=>'java.version') FROM dual11.0.27OL8-on:
java -version
openjdk version "17.0.15" 2025-04-15 LTS
OpenJDK Runtime Environment (Red_Hat-17.0.15.0.6-2.0.1) (build 17.0.15+6-LTS)
OpenJDK 64-Bit Server VM (Red_Hat-17.0.15.0.6-2.0.1) (build 17.0.15+6-LTS, mixed mode, sharing)Extra info:
Az slf4j-nel a legtobb osztaly az org.slf4j///org/slf4j/... modon toltodott be, mig 19c-n ezek org/slf4j/... formatumuak. Azt kideritettem, hogy Java 8 utan modulrendszer jot a Javaba elvileg, es az okozza ezt. Ez okozhatja a hibat?Pl:
org.slf4j///org/slf4j/loggerfactory and org/slf4j/LoggerFactory
Kezzel is megprobaltam betolteni.
Ha betoltom a ket jart (slf4j-api, password4j) wgy mezitlabas java projektbe akkor mukodik JDK 8/11/17/21/24-gyel ahogy kell.
Ha mavennel huzom be, az slf4j-apin kivul akkor sem huz be mas fuggoseget.PLS HELP! :)
Ha barmi infora szuksegetek van, akkor csak szoljatok!
Udv.
-
bambano
titán
Ha fafejség ellen kell harcolni, arra a nézettábla megoldás.
Itt az az érdekes helyzet van, hogy a nézettábla két irányból is alkalmazható:
1. van egy pocsék tárolási struktúrád, és abból akarsz jó nézetet generálni.
2. csinálsz egy rendes tárolási struktúrát és abból generálsz pocsék nézetet.Én azt javaslom, hogy minél előbb át kell térni a rendes megoldásra, vagyis 2.
Tehát megcsinálod a 3 táblát, elkezded abba tölteni az adatokat, akár visszamenőleg is, és ráhúzol annyi nézetet, amennyi az aktuális helyzetben kell. Ráadásul nézetet ráhúzni és eldobni sokkal egyszerűbb, mint alaptáblát módosítani. Megcsinálod, hogy azok a programok, amik a rossz struktúrát használják, használják a nézettáblákat, amiket meg ezután módosítotok, már az új megoldást használják.
szerk: ha minden szenzor egy tábla rendszerben tárolod az adatokat és egy nézettáblába hozod össze a sok táblát, akkor ott problémás lehet, hogy egy új szenzor hozzáadásakor megcsinálod a szenzor saját tábláját, és amikor a nézettáblát módosítod, akkor le kell bontani a korábbi nézettáblát és feltenni az újat. Ha pedig minden szenzor egy tábla rendszer van, akkor az új nézettábla létrehozása nem befolyásolja a többi működését.
Itt kerül elő az alapkérdés, hogy milyen a kapcsolat a fafejűekkel, hogy nekik mi mindenről van döntési joguk és mi mindent kell tudniuk. Én csendben átírnám, oszt jónapot.
-
fjanni
tag
válasz
bambano
#6003
üzenetére
Értem a 3 tábla felépítését és ez a megoldás jónak tűnik. Megoldja azt hogy eltérő időbélyegekkel hogyan lehet összefűzni adatokat.
Az adat összefűzés azért kell mert ipari üzemről van szó ahol gázmérők regisztrálják a fogyasztást főmérők/almérők/mellérendelt mérők struktúrában. Minden időpontban meg kell tudni mondani pl. hogy az almérőkőn mért fogyasztás összege megegyezik-e a főmérőével. De ugyanígy az elektromos mérőknél pl. hogy a napelem általt termelt energia / a hálózatról vásárolt energia / visszatermelés hogyan viszonyul egymáshoz és pl. mennyi az üzem tényleges fogyasztása stb. és mindezeket összesítve órára/napra/hétre hónapra stb. Tehát különböző mérőpontoknál szerzett adatokkal műveleteket kell végezni, ezt pedig csak úgy lehet hogy összerendelem azokat.
Ez azonban egy jelentős struktúra váltás és egy német cégnél ezt nehéz átvinni, de megpróbálom.
Viszont nekem addig is kell egy megoldás és a korábban említett View jó lehet erre. Fogom a tábla adatokat, először is konvertálom az időt a legközelebbi negyed órás időre (00/15/30/45min) beleteszem a mérési pont azonosítóját (MPxxx) is az adat mellé és unionnal összefűzöm őket. Aztán ezt a view-t használom a Grafana Query-kben. -
bambano
titán
"Valóban a mérő azonosító karaktereiben lehet betű is.": majd valami agyhalott kitalálja, hogy legyen benne ékezetes betű, pl. tulaj neve vagy címe rövidítve, esetleg bugos utf8 konverter az adatbáziskezelőben (mint ma a debianban...
) és akkor lefekszik az egész....Egyébként a számmal is az a gond, hogyha nem tudod a határait, nem biztos, hogy találsz hozzá természetes adattípust. Akkor eltárolod stringként, és vége. Vagy jöhet olyan történet is, mint egyszeri lakcímnél, hogy beépítenek egy telket, és hirtelen a természetes szám házszámból lesz egy /b.
Soha nem tudhatod, hogy egy architect miket képes elbarkácsolni
-
-
bambano
titán
Én is közüzemi cég szerűséget találgatok...
Szerintem a mérőket ki kell venni, mert stringek között keresni rosszabb, mint egész számok között, másrészt nem tudni, melyik mérő neve milyen hosszú.Archiváláson valóban érdemes gondolkodni, de a kötelező megőrzési idő, szerintem, elég nagy ahhoz, hogy archiválástól függetlenül meg lehet borítani a lekérdezéseket. Ha a jelentési teljesítmény nem jó, akkor nem jól tervezték meg az adatbázist.
Egyébként a nagy tábla a biztonsági mentéseket borítja meg leghamarabb...
-
válasz
bambano
#6005
üzenetére
Nekem az a gyanúm, hogy valami olyan feladatról lehet szó, mint egy közüzemi cégnél, hogy jönnek a mérőkről az adatok és két adott időpont között ki kell számolni az adott időszakban elfogyasztott (mért) mennyiséget.
Szerintem ehhez elegendő egy tábla (feltéve, ha a mérőkről nem szükséges további információ, pl. telepítési hely, lokáció, hitelesítési év, ilyesmi).
Viszont az adatok mennyiségétől függően már most érdemes elgondolkodni az időközönkénti archiváláson, mert egy ilyen tábla elképesztő nagyra tud "hízni", ami az esetleges riportolási performanciát megboríthatja.
Én nem vagyok data enginieer, csak egy mezei riportingos, ezért az irományomat ilyen kritikus szemmel nézd kérlek
. -
bambano
titán
válasz
martonx
#6004
üzenetére
Én úgy értettem abból, amit írt, hogy össze akarja kötni az azonos időben különböző mérőkkel mért értékeket, és ezt nem lehet időbélyeg alapján, mert az mindig változik.
Tehát ha valamiféle egységben (gazdasági egység, megrendelő, számlázási egység) több mérő van, tudni akarja az egy időpontban mért értékeket. Találgatás: például nálam 5 hőmennyiség mérő van, ha simán leszeded a mért értékeket, különbözik az időpont, de bizonyos célokra tudni kell, hogy amikor az egyik mért valamit, pontosan akkor mit mért a másik. -
martonx
veterán
De, ugyanarra való mindegyik tábla, ergo 1 tábla kell csak, hiszen ha jó lenne az adat struktúra, problémád se lenne.
![;]](//cdn.rios.hu/dl/s/v1.gif)
ID / MP_code / Zeit / Zaehlerstand - ez a helyes struktúra. Az időbélyeges problémádat nem értem Amikor jön az adat MP_code tartalmazza, hogy mi is az, az időpont tartalmazza, hogy mikor jött, az utolsó mező pedig, hogy mennyi az annyi. Én még az Id-t is lehet kihagynám, ha MP_code plusz idő bélyeg egyedi tud lenni, akkor lehetne a kettő együtt a Primary key. De ez csak egy ötlet. -
bambano
titán
Felveszel két táblát, index mezőnek (nem tudom, hogy hívják pontosan). Az egyikbe belerakod a mérőpontok adatait:
id, mérőpont neve, egyéb adata (pl. gázt, villanyt, mit mér).
A másikba leltározod a méréseket: id, dátum, egyéb adatok.Ezután csinálsz egy táblát, aminek van saját id-je, belerakod a mérés indextáblából az id mezőt, a mérőpont azonosítóját, esetleg az aktuális dátumot defaultnak, illetve a mért adatot.
Ez három tábla, nem 500. Lesz egy rakás szkripted, ami összegyűjti a mérési adatokat. Amikor egy ilyen szkript elindul, belerak egy rekordot a mérések leltártáblájába, és visszakapja az id-t. Amikor összeszedi a mérőpontok adatait, akkor ezt az id-t is belerakja a mért adat táblába, és ezzel az id-vel lehet összekötni az egyidejű méréseket.
Egy Chomsky nevű fickó írásait kellene olvasgatnia mindenkinek nálatok.
-
fjanni
tag
válasz
martonx
#6000
üzenetére
Nem ugyanarra van, minden tábla más mérési pont adatát tárolja, valamelyik gáz fogyasztás és van amelyik villamos energia fogyasztás adatot tárol, és olyan is van ahol villamos teljesítmény adatot tárolnak adott timestamp-hez kötve.
Ha sikerülne elérni hogy újrafejlesszék akkor annak milyennek kellene lennie?
Jelenleg ilyen egy tábla, a tábla neve MP001
Egy másik tábla pedig: MP002
Látható hogy szinte minden táblában más az időbélyeg adat, van ahol rövid időn belül sok adat lett letárolva stb.
Ehelyett mi a jó megoldás?
Az hogy egy táblába írok úgy hogy minden adatnak van egy mérési pont azonosítója?
ID / MP_code / Zeit / Zaehlerstand - itt ügyelni kell arra hogy az időbélyeg adatok egy beírásnál megegyezzenek.
vagy
egy rekordba legyen írva az össze adat egy dátum mellé?
ID / Zeit / MP001 / MP002 / MP003 .... ahány mérési pont van?Ha elfogadják az új formátumok akkor pedig átkonvertáljuk a régi adatokat is ebbe az új formátumba.
-
Louro
őstag
válasz
martonx
#6000
üzenetére
Uh, ilyen nálunk is van az egyik területen. Kb. 3-4 hetente felhívom a figyelmüket, hogy rendezzék már az adataikat. Ugyanarra a témára, naponta hoznak létre táblákat és van, hogy 1-2 rekord van csak benne. Mondtam nekik, hogy +1 oszlop, ami a napot jelöli, sokkal ideálisabb lenne. Ehelyett már 300+ táblájuk van csak egy célra és nekik így jó. Szerencsére csak két ilyen fafejű kolléga van. Persze panaszkodni tudnak, hogy ha az SSMS-ben lenyitják a táblák listáját, akkor van, hogy megnyekken a rendszer.
És nem egy DWH területről beszélünk. Kb. 100 táblában elférnének, de ehelyett 5000+ táblájuk van. Nekem fizikailag fáj, ha velük kell foglalkoznom. Hiába jelzem, hogy ha unique indexet akarnak trigger miatt, akkor ne 4 adatból rakják össze, amik ráadásul eltérő adattípusúak, hanem csináljanak egy dedikált unique mezőt és arra lehet indexálni.
De hát mi csak csóró üzemeltetők vagyunk és ők a détaendzsinírek.
) és akkor lefekszik az egész....
. 
.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- Eredeti játékok OFF topik
- DOOM - The Dark Ages
- bitpork: Augusztus 2- szombat jelen állás szerint.
- World of Tanks - MMO
- LED világítás a lakásban
- Ventilátorok - Ház, CPU (borda, radiátor), VGA
- Brave
- Kormányok / autós szimulátorok topikja
- PlayStation 5
- Külföldi rendelések: boltok, fizetés, postázás
- További aktív témák...
- Beszámítás! Oculus Rift virtuális valóság szemüveg garanciával hibátlan működéssel
- BESZÁMÍTÁS! ASUS ROG STRIX Z270G GAMING WiFi alaplap garanciával hibátlan működéssel
- Billentyűzet magyarosítás magyarítás lézerrel is! 10-15ezer közötti áron! Óriási betűkészeletünk van
- Fotós felszerelés - Stúdió lámpa / Softbox / Vaku
- BESZÁMÍTÁS! MSI B550 R9 5900X 32GB DDR4 512GB SSD RX 6700 XT 12GB Rampage SHIVA Enermax 750W
Állásajánlatok
Cég: Liszt Ferenc Zeneművészeti Egyetem
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged