MariaDB ugyanazon futtatás különböző eredmény

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"

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...

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

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

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).

É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...)

 

É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...

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."

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.

" 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