Kedves Fórumtársak!
/usr/bin/mysql Ver 15.1 Distrib 10.0.37-MariaDB, for Linux (x86_64) using readline 5.1
Adott egy rakás sql parancs-sorozat. Ezek nem érik el a kétszázas darabszámot, egy-egy sorozatban van kb. egy tucat, részben egymásra épülő sql-parancs. Pl. tábla létrehozása, adatbeolvasás csv-file-ból (kB nagyságrendben), táblaszerkezet módosítása és különféle lekérdezések. Ezeket egy PHP szkrip futtatja, mégpedig úgy, hogy minden sorozatból futtatja az elsőt, majd mindegyikből a másodikat és így tovább. Elvégez különféle ellenőrzéseket (ide értve, hogy egyáltalán lefut-e a parancs), az eredményeket meg kiírja két táblába. Mindez egyugyanazon adatbázisban.
Azt tapasztaltam, de reprodukálható módon nem teszteltem, hogy újrafuttatás esetén nem feltétlenül ugyanazon eredmények születtek, esetenként a kapott eredmény képtelenségnek látszott. Pl. a php-script azt találta, hogy két select esetében a két eredménylistában különböző számú oszlop van, holott a két select-et egyedileg futtatva a két eredménylista teljesen azonos. Ismételt futtatás után meg egyformának találta (ahogy elvárná az ember két egyforma eredménylista esetében).
Egyetlen script egyenként csinálja a futtatást. És igen, nem bizonyított a program helyessége, de korábban ilyen furcsaságokat nem tapasztaltam.
Lehetséges, hogy a táblák létrehozása, importálás, szerkezetmódosítás végrehajtása fáziskésésben van, és a lekérdezések nem a (végleges) adattartalmon hajtódnak végre? Vagy valami más lehetőség?
Köszi, üdvrivalgással:
KEA.
- 1990 megtekintés
Hozzászólások
> a lekérdezések nem a (végleges) adattartalmon hajtódnak végre?
Mán miért ne lenne ez lehetséges? Van valami lock, tranzakció közben?
"antiegalitarian, antiliberal, antidemocratic, and antipopular"
- A hozzászóláshoz be kell jelentkezni
Készítem a popcornt
- A hozzászóláshoz be kell jelentkezni
Felkiáltójel, esetleg pont a mondat végén...? :-D
- A hozzászóláshoz be kell jelentkezni
igen!!4444
- A hozzászóláshoz be kell jelentkezni
tranzakciokat hasznalsz a sql futtatasanal?
Support Slackware: https://paypal.me/volkerdi
- A hozzászóláshoz be kell jelentkezni
Nincs tranzakció. Elemi utasítások mennek egyenként, egymás után, Lemegy egyenként -- mondjuk -- száz create, utána a száz load data az előbb létrehozott táblákba (egymástól függetlenül), utána jönnek a select-ek...
- A hozzászóláshoz be kell jelentkezni
Biztosan az a kiinduló pont, hogy olyan táblán végzel műveletet, aminek adatai változnak a művelet végzése közben.
Hogy a tábla miért változhat, azt így nem lehet megmondani, lehet hogy egy sima fflush gond van valahol, de a tranzakció kezelés biztosan segítene.
- A hozzászóláshoz be kell jelentkezni
Szóval be kell tenni egy `flush table <tábla>`-t minden load data vagy insert select után -- megnézem, köszi.
- A hozzászóláshoz be kell jelentkezni
Meg kéne ismerkedni olyan fogalmakkal mint DDL, DML, tranzakció, ACID, tranzakció izolációs szintek, dirty-read...
Aztán meg kell ismerkedni azzal hogy az adott verziójú mariadb / mysql / whatever mit és hogyan basz el ebből ...
zászló, zászló, szív
- A hozzászóláshoz be kell jelentkezni
Első találkozásom az Oracle entitással:
select bla, bla (tökegyszerű select)
És minden második futásra írta ki az eredményt, ami kb egy/néhány sor volt.
Az adatbázis ottt csücsült a diszken és a kutya sem nyúlt hozzá.
- A hozzászóláshoz be kell jelentkezni
Hát van egy tippem, kétszer kell ugyanazt beírni, hogy egyszer lefusson (Sql*Plus-ban nem megy, de YaSql-ben igen):
scott> SELECT 'Literal FROM DUAL;
'> SELECT 'Literal FROM DUAL;
LITERAL
--------------------------
Literal FROM DUAL;
SELECT
- A hozzászóláshoz be kell jelentkezni
Vagy lehetett egy 'nem kell ide ORDER BY, hiszen index alapján keres, tehát az index alapján rendezve jön az eredmény' is.
- A hozzászóláshoz be kell jelentkezni
Persze vannak valódi hibák is, de azokat nem "nyeretlen kétévesek" találják meg. (Például nálunk olyan volt az ősrégi 10.2-ben, hogy egy új kliens megörökölte az előző klienstől a SID-del együtt a statement cache-t is, még akkor is, ha másik user volt, tehát a gondosan előállított végrehajtási terveket nem lehetett végrehajtani).
- A hozzászóláshoz be kell jelentkezni
Amit a kolléga említett, az valami 7-es orákulum lehetett :-)
- A hozzászóláshoz be kell jelentkezni
select kukac from alma;
Erre kellene egy táblázat verziónkét, mi a várható eredmény. Esetleg tőbb dimenziós, sql fajták szerint.Valamint az 1+1=? valószínű eredményei szerint csoportosítva. :-D
- A hozzászóláshoz be kell jelentkezni
Ez csak találgatás, de lehet, hogy a tábla tartalma is befolyásolja az eredményt?
- A hozzászóláshoz be kell jelentkezni
Bocsánat, pongyola volt a kiírás. Mondjuk normál működést feltételezve minden esetben 3 sor jön ki. Az említett anomália minden második esetben működött így.
- A hozzászóláshoz be kell jelentkezni
Ez definíció szerint az alma tábla kukac oszlopának az elemeit adja vissza, nem definiált sorrendben.
- A hozzászóláshoz be kell jelentkezni
Igen, lehet definícióval dobálódzni, de a kerdés pont arról szól, hogy ahhoz képest mi lesz az eredmény. Egyelőre a többdimenziós mátrixban tudunk egy pontot, ahol nem definíció szerint működik.
- A hozzászóláshoz be kell jelentkezni
Éspedig? Azért rettenet mód csodálkoznék, ha ugyanabban a session-ben és tranzakcióban ugyanaz a select más halmazt adna vissza. Másik sessionben/tranzakcióban természetesen adhat vissza más halmazt, hiszen a DB állapota a két select szempontjából nem biztos, hogy azonos. De azonos session-ben is lehet kétszer egymás után futó select-ből eltérő halmazt visszakapni, ha közben egy commit-tal lezárt tranzakció hozzányúlt az adatokhoz.
A halmaz rendezettsége az más kérdés, sőt a select * from alma esetén a visszakapott tábla oszlopainak a sorrendje sem determinisztikus - ha arra van szükség, hogy pl. egy csv-fájlba minden esetbe adott sorrendben kerüljenek bele a támla oszlopai, akkor nem select * from, hanem select {oszlopok felsorolása} from... a helyes megoldás. (Oracle esetén jellemzően nem lesz más a select * esetén sem az oszlopok sorrendje, de elég egy dump/restore, és máris kavarodás jön...)
- A hozzászóláshoz be kell jelentkezni
Mi is csodálkoztunk V. Csabával. Bár kb. az első sql parancs volt amit láttunk, de azért nem kell így bonyolítani, hogy session meg tranzakció. A db-hez senki nem nyúlt hozzá. Nem a lista tartalma volt más, hanem 1. eredmény 2. sömmi 3. loop.
- A hozzászóláshoz be kell jelentkezni
Egyelőre az jött le hogy szerinted szar az SQL. Szerintem nem érted és nem is szereted.
Ezzel nincsen semmi gond csak így elnézve elég vicces hogy mindjárt az Oracle (meg a mysql) a gagyi szar és nem gyanakszunk level 8 hibára.
zászló, zászló, szív
- A hozzászóláshoz be kell jelentkezni
Én kérek elnézést, hogy a szert orálkulumot megbántottam! Nincs itt semmi szeretem vagy nem szeretem. Egyszerűen csak néztünk ki a fejünkből - minden egyéb érzelmi vagy szakmai megfontolás nélkül. A történet lényege az, hogy megtörtént. ;) A zellernek írt hozzászólásomból (fent) kiolvashatod a történet részleteit. Még egy tudnivaló: a hiba előfordulásakor garantáltan senki sem használta a db-t.
A dolgot úgy lehetne modellezni, mintha egy kalkulátor az 1+1 requestre minden másodikra felváltva 0 és 2 eredményt ad. Ebből sem lehet kitalálni. hogy szeretem-e a kalkulátort vagy értek-e hozzá, sőt ha a kalkulátor egyébként jól szokott működni akkor a kalkulátor csip ALU-ról sem lehet általános véleményt megfogalmazni. Egyszer csak megtörtént...
- A hozzászóláshoz be kell jelentkezni
Kalkulátorban is ha eléd raknak egy HP48G-t először utálni fogod. Pedig kurva jó, csak nem olyan mint a megszokott (hanem RPN).
zászló, zászló, szív
- A hozzászóláshoz be kell jelentkezni
Annak idején a kedvencem volt az LZR 2665 nyomtató, csak egy soros terminált kellett rádugni és lehetett programozni. Postscriptben, kb. 87-ben. Az ára akkor $26.000 volt.
- A hozzászóláshoz be kell jelentkezni
Ezt egy adatbázisban kellene tárolni -- de milyen kezelővel? :D=
- A hozzászóláshoz be kell jelentkezni
kezelő = sql fajták
- A hozzászóláshoz be kell jelentkezni
sqlplus?
/
az utasítás után, hogy végre is hajtsa?
- A hozzászóláshoz be kell jelentkezni
Például lehet, hogy egy ilyen sorozatban vannak `ALTER SESSION` utasítások is. Ezzel a kreatív 'interleaved' végrehajtási móddal esetleg azt sikerül elérni, hogy ezek hatása a sorrendtől függően érvényesül.
- A hozzászóláshoz be kell jelentkezni
A 10.0.37 az már nagyon-nagyon öreg, azóta rengeteg hibát javítottak. A 10.0 ág tíz éve jelent meg kb. Persze új hibákat is születtek közben bőven az újabb verziókkal, az is igaz.
10.6, 10.11, 11.4 az LTS jelenleg, én első körben ezek közül valamelyik frissebbel próbálkoznék, már amennyiben az alkalmazásod is hajlandó vele dolgozni.
"Everything fails, all the time."
- A hozzászóláshoz be kell jelentkezni
Érin a frissítés, nem mondom, de nem az évvégi hajrában fog sor kerülni rá ;)
- A hozzászóláshoz be kell jelentkezni
10-et kibírt most már az az 1-2 év nem számít
zászló, zászló, szív
- A hozzászóláshoz be kell jelentkezni
Lehet nem fejeztem ki magam elég világosan. Az én esetemben (legalábbis) egy felhasználó, egy munkamenetben egymás után (elvileg) hajtott végre elemi sql utasításokat, bármiféle tranzakció, sessionpiszkálás, és egyéb "cifraságok" nélkül. Ehhez képest úgy tűnt, hogy a valóságban nem így történt meg, azaz a táblalétrehozások után jöttek az adatfeltöltések (load data), majd a select-ek, és egyes esetekben a select eredménye nem az elvárt volt. A futtató kód nem változott közben, az adattartalom (a load data után) szintén nem változott, tehát fölmerülhet az a gondolat, hogy az egymásután kapott parancsokat esetleg nem hajtja végre teljes mértékben, mielőtt a következőt megkezdené. A hozzászólásokból azt látom, hogy ilyen akár elő is fordulhat. Majd januárban tesztelem.Mindenesetre a futtató progiba beleraktam egy flush tables-t az egyes parancssorozatok végrehajtása közé (tehát az összes create után is, meg az összes load data után is stb.)
Az, hogy egy listázásnál a sorok sorrendje általános esetben bármilyen is lehet, az tulajdonság (akkor is, ha nem mindig tetszik), de hogy az oszlopok sorrendje nem volna kötött, az nekem újdonság. Minden eddigi tapasztalatom szerint a select * a tábla létrehozásakor megadott sorrendben adja vissza az oszlopokat.
Ami meg az öregséget illeti, példálózhatnék olyan esetekkel, amikor a frissítések elkapkodása megbosszulta magát, de a helyzet sokkal prózaibb. Adott egy privát masina, belső hálózaton, ebben a jó öreg My/Maria kizárólag egyetlen felhasználót (=én) szolgál ki esetenként, azt is localhoston.
Üdv:
KEA.
- A hozzászóláshoz be kell jelentkezni
Olvasd vissza a topiknyitót, ott az van, hogy adott n darab batch (köteg), amiket a php egy sessionben round-robin elv alapján hajt végre, hogy B11, B21, ..., Bn1, B12, B22, ..., Bn2, B13,...
- A hozzászóláshoz be kell jelentkezni
" bármiféle tranzakció, sessionpiszkálás, és egyéb "cifraságok" nélkül."
Nem tudom mennyire új neked de az SQL DML-ek mindenképpen tranzakcióban zajlanak, akkor is ha te ezt explicite nem kezeled.
Abszolút beállításfüggő hogy DML-enként külön tranzakció vagy sem. Viszont ha beraksz közé egy DDL-t akkor lesz egy commit mindenképpen, mert a DDL-ek tranzakción kívül történnek.
Bele lehet szaladni dolgokba.
zászló, zászló, szív
- A hozzászóláshoz be kell jelentkezni
Azért nem mindegy, milyen SQL, és milyen táblaformátum. MySQL-nél pl a MyISAM engine képtelen bármiféle tranzakciókezelésre, mert hiányoznak belőle a szükséges feature-k. Ott lehet, hogy az SQL engine logikailag rángatja a tranzakció kezdete-vége karokat, de üres kapcsolók azok.
- A hozzászóláshoz be kell jelentkezni
Hm, a reprodukciós kísérletben minden teszt-táblánál megadtam az InnoDB-t. Az eredeti, problémás esetben szinte biztos, hogy ez egy csomó helyen hiányzott (merthogy a diák spórol meg feledékeny). Közben megnéztem, hogy az InnoDB az alapértelmezett, tehát ez nem szólhatott bele. Alighanem meg kell keresnem az eredeti feladatsort és azt újra végrehajtani. Majd beszámolok róla.
- A hozzászóláshoz be kell jelentkezni
Egyetlen script egyenként csinálja a futtatást.
Lehetséges, hogy a táblák létrehozása, importálás, szerkezetmódosítás végrehajtása fáziskésésben van, és a lekérdezések nem a (végleges) adattartalmon hajtódnak végre? Vagy valami más lehetőség?
Ha tényleg így van, ahogy írod, hogy egymás után futnak le SQL utasítások, szinkron módon, tehát a kiadott utasítás akkor tér vissza, ha végzett (a legtöbb kliens library API ilyen, úgyhogy ez vélhetően így van), és semmi más nem fut párhuzamosan ezzel a folyamattal, akkor semmilyen fáziskésés nem lehet. És ehhez nem kell semmilyen explicit flush művelet sem, hogy ez így igaz legyen.
Ami még befolyásolhatja a dolgot:
-van benne valami aktuális időtől függő, vagy random számtól függű dolog
-van benne olyan SELECT, ahol a visszaadott sorok sorrendje számít a további végrehajtásban, és elfelejtettük az ORDER BY-t
-ha olyan kliens library-t használsz, ami csak visszatérési értékkel jelzi a sikertelenséget és nem exception dobásával, és valahol el van felejtve a sikeresség ellenőrzése
De igazán jó véleményt az tud mondani, aki látja a PHP scriptedet.
- A hozzászóláshoz be kell jelentkezni
...és a legszebb az egészben, hogy nem sikerült reprodukálnom a jelenséget.
- A hozzászóláshoz be kell jelentkezni
Az is meg, meg az a koncepció is, hogy az egyes kötegeket nem sorban egymás után hanem round-robin elven hajtod végre. (Vagy nem jól írtad a topiknyitóban.)
- A hozzászóláshoz be kell jelentkezni
Én nem szeretnék nagyon geci lenni, de elmesélni, hogy hogy működik valami, majd ez alapján debugolni mérsékelten nehéz az adott rendszer ismerete nélkül.
Mivek kB-os méretű adatokról van szó, nem tudsz csinálni egy olyan móricka rendszert, amiben ezt tudod reprózni, de nincsenek benne éles/NDA védett dolgok és megosztani a vonatkozó forrásokat? Simán lehet, hogy az SQL parancsok között van valami "viccesebb", de az is lehet, hogy a table engine amit használsz a MySQL-ben okoz gondot.
Amit én átnéznék még tüzetesen, az a MySQL konfigurációja, és az abba include-olt fájlok tartalma. Simán lehet, hogy van valami olyan opció bekapcsolva, ami befolyásolja a tranzakciókezelést és/vagy az izolációt. Mondanám, hogy nézz bele a "SHOW VARIABLES" kimenetébe, de az mocsok hosszú is tud lenni, első körben ránéznék, hogy mi van a default-tól eltérően konfigurálva.
Alternatív ötlet, hogy Docker-ben a saját gépeden indíts el egy pőre MariaDB-t egyező verzióval, és kapcsold rá az ominózus PHP-s cuccot, hogy nyomkodja.
- A hozzászóláshoz be kell jelentkezni