Mali off, sta se onda desava sa robom? Firma je kupila, ima ulaznu fakturu a ne moze da je ubaci u robno, zar to nije u najmanju ruku nelegalno?

Dalje, triger i performance razmisljanje ti je sasvim ok, zapravo ti najveceg trosadziju vremena radis nocu (proracun optimuma) ono sto tebi ostaje u trigeru je funkcionalno ekvivalentno joinu u update instrukciji, plus mali overhead za formiranje scope-a trigera. Produzavanje x lockova je naravno lose po performanse ali ako moras onda moras, nije bas da drzis lockove na aplikativnom nivou, jedan select sum nad dobro indeksiranom tabelom ti nece praviti veliki problem ni na slabijem severu. Za probleme citaj dalje.


Read uncommited je ocajan izbor za OLTP bazu sa stanjima, koji je konkretan razlog za ovaj niski stepen izolacije? Istina eliminisali ste gomilu lock cekanja jer ste izbacili S lock i cekanje na U/X ali ste napravili situaciju u kojoj su biznis pravila skoro neprimenljiva, pocev od toga da lako mozes da dobijes pogresno stanje magacina ako dve dobrile u isto vreme podaju dva ista artikla, itd, itd. Brzina na ustrb sigurnosti je bar po meni pogresan izbor za poslovnu primenu, transakcione baze moraju da imaju dobru izolaciju da bi bilo kakva logika mogla da radi kako treba, neki minimum bi bilo sprecavanje dirty read-a. Meni ovo mirise na lose uradjen ERP sistem koji drzi duge aplikacione transakcije pa su prebacili na read uncommited da bi to uopste radilo.


Bez dirty-read, ostale transakcije ciji S/U/X lock pogadja ili eskalira na tvoj x lock ce uci u WAIT state dok ERP ne uradi commit/roll. koliko ce to uticati zavisi od toga koliko cesto ubacujes robu u magacine, ako je to manuelni proces par puta dnevno zaboravi odmah na performanse probleme, to nije ono sto tebe pogadja. Takodje dok sracunavas stanje grupe ti ne izazivas dodatne X lockove, samo S lockove, tako da ne sprecavas druge select komande nad ostalim artiklima u grupi tako da ni to nije nikakav problem. U tvojoj dirtyread nema nikakvog uticaja na brzinu sem sprecavanja dve dobrile da povecaju stanje istog artikla u isto vreme, problem koji imas je da bi dobrila mogla da ucita stanje artikla i da ti onda rollbackujes unos stanja i onda dobrila proda vise robe nego sto je u magacinu.


Neces, ono sto ce ubrzati racunanje su indeksi na poljima u where kaluzuli, sto ce opet usporiti insert/update u toj tabeli. uloga FK nije da ubrza bilo sta (sta vise FK usporava insert/update) vec da obezbedi referencijalni integritet baze na ustrb performansi upisa. FK nema nikakav uticaj na select.


U bazi bez dirty read ne postoji "bezbolan" nacin, dok updatujes optimume ti izazivas U/X lockove nad tom tabelom i samim tim blokiras odgovarajuce ubacivanje artikala jer ce select u tvom trigeru da udje u wait state. Takodje ulazis u dodatni rizik od deadlock-a (ti drzis x lock nad artiklom a job pokusava da procita to stanje da bi sracunao optimum, po defaultu ti ispadas kao neko ko drzi manje lockova, ali ni to ne mora da bude 100% sigurno jer zavisi od ostatka lockova koje je izazvao ERP na toj konekciji). U dirty read bazi, pa nema nikakvih performance problema, X nece blokirati triger i isti ce procitati optimum, bilo stari bilo novi


Dal je pametno ili nije zavisi od toga sta je u proceduri i da li ocekuje da na tabeli ima triger koji moze da izazove gresku. sam po sebi triger je instrument, nit je pametan nit glup, sluzi svrsi. takodje i to sto je procedura nije nikakav problem po sebi, triger je vezan za specificnu operaciju, bilo da je ona u batch-u, proceduri ili necem trecem.

Koliko razumem, ti treba da sprecis ulaz u magacin ako bi pridodata kolicina probila neku 'optimalnu' granicu, pri cemu se 'optimalna' granica menja u vremenu. To znaci da za svaki novi ulaz u magacin, treba proveriti stanje pa na osnovu toga prihvatiti ili odbiti ulaz.

Ako je ovo tacno sto sam naopisao, mozes da pokusas da napises funkcije koje vracaju odgovor na pitanje 'prihvati ili odbaci ulaz?' i onda te funkcije koristis kroz CHECK constraints (CHECK poziva korisnicku funkciju). U tom slucaju, CHECK obavlja kontrolu i dozvoljava ili ne dozvoljava unos. Ako zahtev prodje CHECK, dopusti unos, u protivnom - nista, nema unosa, sve je odbijeno, a nista nije lockirano.

Da li je brzi poziv funkcije iz CHECK constraint nego trigger? Ne znam, zavisi od situacije, sta treba da rade funkcije, a sta treba d arade trigeri da bi postigli isti efekat. Zato treba testirati pa sta ispadne bolje.

:-)

Mislim da je to malo komplikovanije resenje a nisam siguran ni da je izvodljivo. svi constraints ukljucujuci check se izvrsavaju pre promene reda tako da ce select sum() u CHECK sabrati staro stanje grupe, dodata roba nece ucestvovati u proveri.

Hvala na odgovorima,

Hajmo redom:

@

Ova kotrola bi se najviše odnosila na prmet robe iz centralnog skladišta prema maloprodajnim objektima, Isto tako bi ugrađivala u izradu dokumenata narudžba
dobavljaču, A u funkciji blokade baš ulazne primke bi služila kao represivna mjera da se ili vještački poveća optimum ili u kratkom roku određene količine vrate prema centralnom skladištu.

Odavde i proizilazi moje pitanje kako u sprezi stoje trigeri i uskladištene procedure ili eventualno funkcije jer se istu logigu moram primjeniti u raznim slučejvima, međuskladišnica izlaz, narudžba robe, Primka robe, Pa pokušavam objektno razmišljati da napravim jedinstvenu SPROC koja bi odgovara svakoj svim napoemnutim situacijama a pozivali bih trigeri na različitim tabelama.

Kada smo kod Drty Rading da li se to uzima pod pojam Set Isolation Level Read Uncomited ili se pod drty reading podrazumjeva nešto drugo.
Sada još jedno pitanje, Ja radim evo osam godina kao "nakav" database administrator još od DBF-ova i Clippera i stvarno ne vidim potrebu za tim
specilnim zaključavanjem nigje u poslovnom prcesu, Da li smo mi nakaradna firma ili je nešto drugo po srijedi, Neki od primjera za ne potrebom zaključavanja
su slijedeći, Kase rade offline i svaka ima svoju lokalnu bazu tako da možemo jedan arikal koji je ušao 10X prdati ako danas upalimo deset kasa, Kada se radi
o veleprodaji pored svih kontrola dugovanja kupaca na graju imamo gospođu koja na ruke pregleda stanje Dugovanja klupca prije potpisivanja faktura tako da
i u tom slučaju je prošlo i do pola sata od izrade fakture do konačne otpreme. Sada evo nabrajam skoro 70% dokuneata ima dva ili tri prolza, Obično slanje robe
sa Centralnog skladišta ide u četri prolaza Nalog za slaganje->Slaganje->Izlazni dokument->Ulazni dokument. i Tako

dirty read je efekat koji postoji samo u "Read uncommited" izolaciju. Dirty read znaci sledece:

- proces A krene transakciju i upise nesto (recimo promeni stanje cokoladica sa 0 na 100) i onda krene da radi neke provere
- u to vreme proces B, veleprodaja, uzme stanje i zbog dirty read efekta procita 100 i
- provera u A propadne i A rollbackuje
- B proda recimo 50 cokoladica sto je sa njegovog stanovista ok jer je procitao stanje 100.
sta sad? sa robom? sa fakturom? sa podacima?

primer je pojednostavljen, u praksi i kompleksnijim sistemima se desavaju i mnogo gore stvari. Kad je dirty read efekat iskljucen (u read commited i jacim izolacijama) onda proces B u drugom koraku ceka da A zavrsi i ako je A rollbackovao vidi 0 kao stanje. Jedini nacin da minimizujes dirty read stetu je koriscenje optimistic lockinga u aplikativnom nivou, ali onda efektivno uvodis simulaciju viseg stepena izolacije i usporavas operatere kao sto bi to radio sa izolacijom na bazi.


Ne znaci da ste nakaradni, sta vise ako vam je ERP isporucio neko drugi a izgleda jeste, oni su ti koji su ti odredili nivo izolacije za svoju bazu, sto samo moze da znaci da su oni nakaradni . A mozda i erp za kljucne operacije koristi eksplicitne transakcije sa visim nivoom izolacije? Kako bih ti to objasnio? dirty read sam po sebi nije problem, on samo drasticno povecava rizik da problemi nastanu kako broj konkurentnih korisnika raste; niste vi ni prvi ni poslednji, dosta firmi ima ovaj problem, radi se adhoc aplikacija i to sve radi super sa 5 ljudi onda krene biznis i baza krene da brlja sa 100 zaposlenih, neispravni magacini, deadlockovi, itd, itd. Ne kazem da ste vi takvi, ali nije zgoreg da se malo pozabavis tim problemom pre nego postane realan.
Inace, lockovanje uvek imas, u najmanjoj meri dva procesa ne mogu da rade update istog reda u isto vreme bez obzira na to koja je izolacija samo sto se to desava toliko brzo da ti to ne primecujes. Ono sto stepen izolacije odredjuje je koliko agresivno ces implementirati razdvojenost procesa na ustrb performansi i u zavisnosti od toga imas realne efekte (dirty read, phantom read, non-repeatable read) kao posledica nacina na koji lockovi rade, visi stepen izolacije => vise lockova i "tvrdji" lockovi i samim tim mnogo vise usera "na cekanju" sto umanjuje skalabilnost ali povecava sigurnost podataka. Po nekom mom iskustvu read uncommited je samo za arhivske i read-only baze u kojima nece biti insert/update/delete, za sve ostalo read-commited je minimum.


TO stoji, vas biznis proces je takav da se fizicki ne moze prodati roba koja nije prosla kroz ruke i to je verovatno jedini razlog zbog kojeg jos niste u problemima do guse, bar sto se tice stanja magacina (mada ima tu drugih potencijalnih problema o kojima ne mogu da komentarisem jer ne znam kako vam izgleda baza i proces fakturisanja). E sad zamisli kroz godinu dana proradi kliring kartica i gazde hoce online prodaju, vise nema prolaska robe kroz ruke pre placanja i ako kupac uplati karticom ti moras da skines robu sa stanja, sad se vrati na dirty read primer i vidi kakav to ima efekat, kupac uleti bas u trenutku kad se vidi 100 cokoladica, kupi 50 a ti rollbackujes stanje

A sad cisto da budemo nacisto, ovo ne znaci da ti sad treba da odes i da promenis isolation level, aplikacije se generalno pisu oko specificnog nivoa izolacije i ponasaju se drugacije pod razlicitim nivoima. Ako je ERP lose naspisan i dugo drzi lockove mozes da napravis kolaps, ta promena ako je i budete radili mora da ide planski.

Inace, razumem tvoj problem, popravljanje i nadogradnja gluposti u 3rd party aplikacijama nije novina, relativno skoro sam pisao neke trigere za Great P(l)ains bazu u slicne svrhe, takoda znam da bi ti trigeri resili problem, ali takodje znam i koliko cupavo i nestabilno to moze da bude jer direktno menjas logiku aplikacije o kojoj ne znas mnogo, tj. dovoljno.

_{[Ovu poruku je menjao mmix dana 02.06.2009. u 15:17 GMT+1]}

meni je uspelo da napravim CHECK koji koristi UDF da sperci da ukupan zbir po klijentu predje zadatu vrednost. Evo ga primer:

http://www.baze-podataka.net/page/6/

Primer opisuje situaciju gde se na neki racun uplacuje vise puta neki iznos. CHECK ne dozvoljava da zbir svih uplata predje neku zadatu vrednost. Slicno onom sto Ado hoce - da ukupna kolicina za robu ne predje neku zadatu vrednost, koju oni zovu 'optimalna'

Ne znam da li je to brze od trigera, kada je brze, kada je sporije, ali radi, barem teorijski, i barem na nekim primerima.

Hmm, sad sam bas probao tvoj primer i radi, u pravu si, definitivno moze i preko check constraint-a. To znaci da check constraints idu na proveru posle write-a. cudno, mogo sam se zakleti da sam na predavanju cuo ovo isto pitanje i odgovor ne jer check ide pre write-a. Nema veze...