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?
Ez definíció szerint az alma tábla kukac oszlopának az elemeit adja vissza, nem definiált sorrendben.
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