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.
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"
Készítem a popcornt
Felkiáltójel, esetleg pont a mondat végén...? :-D
igen!!4444
tranzakciokat hasznalsz a sql futtatasanal?
Support Slackware: https://paypal.me/volkerdi
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...
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.
Szóval be kell tenni egy `flush table <tábla>`-t minden load data vagy insert select után -- megnézem, köszi.
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 ...
Gábriel Ákos
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á.
Hát van egy tippem, kétszer kell ugyanazt beírni, hogy egyszer lefusson (Sql*Plus-ban nem megy, de YaSql-ben igen):
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.
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).
Amit a kolléga említett, az valami 7-es orákulum lehetett :-)
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
Ez csak találgatás, de lehet, hogy a tábla tartalma is befolyásolja az eredményt?
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.
Ez definíció szerint az alma tábla kukac oszlopának az elemeit adja vissza, nem definiált sorrendben.
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.
É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...)
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.
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.
Gábriel Ákos
É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...
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).
Gábriel Ákos
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.
Ezt egy adatbázisban kellene tárolni -- de milyen kezelővel? :D=
kezelő = sql fajták
sqlplus?
/
az utasítás után, hogy végre is hajtsa?
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 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."
Érin a frissítés, nem mondom, de nem az évvégi hajrában fog sor kerülni rá ;)
10-et kibírt most már az az 1-2 év nem számít
Gábriel Ákos
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.
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,...
" 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.
Gábriel Ákos