Nem szeretném szidni a magyar oktatást, de hogy lehet hogy anno megbuktam adatbázisokból, és amikor elkezdtem dolgozni?

"Ja, az lemaradt, hogy SELECT esetén NINCS lock."

Ajjajajaj...

Ezt most bemásolom neked ide dragonka, cserébe soha többet nem írsz az oldalra. Kösz!

[link]

Az egyes alap SQL utasításokhoz kapcsolódó zárolásokat mutatja be a

következő lista.

------------------------------------------------------------------

SELECT nincs zárolás

------------------------------------------------------------------

UPDATE

INSERT

DELETE érintett rekordok zárolása

------------------------------------------------------------------

"Az egyes alap SQL utasításokhoz kapcsolódó zárolásokat mutatja be a következő lista."

Nem én vagyok az aki eddig támadott téged, de a SELECT is csinál egy lockot, Shared vagy közismertebben Read locknak hívják.

[link]

Ha specifikálod, hogy nem szeretnél ilyen lockot (WITH NOLOCK mssql-ben például), akkor lehet nagyon komoly gondokat okozni. Nyilván egy kiragadott példa volt egyébként, de számtalan ilyen dolog van (például hogy az O(n) és O(n^2) között elég nagy a különbség, és azért akad a szoftver). Vagy ahogyan technológiát választasz az ne attól függjön, hogy mi a menő, hanem hogy mire szeretnéd használni. Ha azt olvasod, hogy a NOSQL jobb, mint minden más adatbázis, akkor néhány óra beletúrás a hivatalos papírokba legyen elég hozzá, hogy eldöntsd valóban gyorsít-e az alkalmazáson, stabilabbá vagy könnyebben fejleszthetővé teszi-e ha azt használod, ahelyett, hogy fórumokat elolvasgatva találgatnod kelljen (jó példa erre a blockchain implementáció hullám).

"Dehogynem lehet, sőt, azzal lehet csak igazán úgy, hogy nehéz legyen megtalálni az okát.

Ez csak azt mutatja, hogy még sosem dolgoztatok az iparban, production rendszereken."

Pedig iparban dolgozok, hatalmas, production rendszereken. Oracle-ben.

Ha bármilyen select fél óránál tovább fut, a rendszer automatikusan kilövi. Az erőforrások meg priorizálva és limitálva vannak, ergo nem tudom túlterhelni egy select-tel.

"Ja, az lemaradt, hogy SELECT esetén NINCS lock."

Ne ezaz. A SELECT tud olvasni lockolt rekordot is. A maximum, ami történhet, hogy egy éppen lockolt rekordnak a commitált változatát látja a select és nem azt a verziót, amit épp frissített egy update, de még nem commitált. Éles adatbázisban amúgysem jó ötlet, ha a select uncommited rekordot is kihoz.

Hát, azért láttam én már olyan (dinamikusan generált) selectet ami egymaga megtöltötte a shared poolt. Ami ugye egy OLTP (esetünkben ERP) rendszernél olyan szintű performancia degradációt okozott, gyakorlatban mintha összeomlott volna az adatbázis. És igen, ez is Oracle volt, "iparban."

Per pillanat Oracle cloud alapú ERP-val dolgozom, (tehát nem csak hogy Ora adatbázis, de maga az Oracle hostolja és konfigurálja,) és vannak olyan riportok amik bizony órákig futnak, és csak a vállukat vonogatják rá, hogy "ez ilyen, nem lehet vele mit csinálni." És ha ötöt elindítunk belőle, akkor már bejelentkezni is alig tudunk a rendszerbe utána.