Oracle a zamky a transakce

[radim.kubacki na rtscs.cz]

> -----Původní zpráva-----
> Od:	Honza Pazdziora 
> Odesláno:	7. října 1999 10:23
> Komu:	databases na linux.cz
> Předmět:	Re: Oracle a zamky(Re: Multiuzivatelsky SQL server)
> 
> 
> > rollbackem nebo commitem. Ad INSERT: az do skonceni transakce ten zaznam
> > stejne nikdo nevidi a tudiz ani k nemu menuze pristupovat (ACID
> vlastnosti
> > transakci).
> 
> To je pravda, ale ten insert Vam muze zamknout druhou tranaskaci,
> napriklad na constraintu (tohle jsem mel na mysli, kdyz jsem falesne
> obvinil Oracle, ze nezamyka po blocich).
> 
Souhlasim, presne tak. Nevim ani jak se to s temi constraints resi.

> > A jeste jedna vec. Teoreticky muzete zamykat na nekolika urovnich - cela
> > tabulka, blok s vice zaznamy, konkretni zaznamy. Dokonce to muzete
> napsat
> > tak, aby se rozhodovani provadelo automaticky. Cim mensi kus zamknete
> tim
> > mensi nebezpeci deadlocku anebo nutnost cekani na uvolneni neceho vam
> hrozi,
> > je to ovsem pracnejsi takze horsi vykon.
> 
> Co kdyz pustim dlouhy update -- na nekolika stech tisicich zaznamu.
> A pustim druhy v jine session. Musim nejak zjistit, ktere zaznamy
> budou ovlivneny a ty zamnkout. Nez to zjistim, domnivam se, ze se na
> te tabulce musim zeserializovat (tedy zamknout celou tabulku), protoze
> jinak se mi muze stat, ze pulku zaznamu zamknu jednim updatem a pulku
> druhym a dosahnu bud deadlocku nebo nekonzistence nebo neceho
> takoveho. Pote, co uz je update proveden, si drzim informaci
> o zmodifikovanych ale necommitnutych datech primo u tech dat, takze
> nikdo jiny na ne neprijde. Ale nez to nastane (nez vyhodnotim, koho
> budu vlastne menit), jdu po cele tabulce, ne?
> 
Dlouha posloupnost zmen a z ni vyplyvajici potize je nejvetsi slabina pokud
jde o flat/chained transactions :-)

Kdyz vim, ze budu menit opravdu celou tabulku tak proc ne. Klidne si ji
zamknu celou. Pokud to neni cela tabulka a umim napsat
DECLARE CURSOR c AS SELECT ... FOR UPDATE tak je to taky v pohode. A vy
navrhujete jeste obecneji to udelat tak:
zamknu celou tabulku;
prochazim vse a do pomocne struktury si ukladam ty, ktere budu menit;
pak to muzu odemnkout;
jeden po druhem je menim.

Dosahl jste teda toho, ze prideleni vasich specialnich zamku je
serializovane a nedojde ke kolizi ruznych session. Z tohoto pohledu vam to
pomuze. Eliminoval jste jisty zdroj problemu (deadlocku). Prakticky takovou
techniku muzete pouzit v Oraclu i v mySQL. 
Spousta problemu kvuli kterych se transakce pouzivaji vam ale zustala k
naprogramovani. 

> Navic zamky na urovni bloku maji jeste jeden problem. Predstavme si
> 
> session 1:				session 2:
> 
> update table set neco = ? where id = 1
> 					update table set neco = ? where id =
> 2
> 
> update table set neco = ? where id = 2 /* vysledek je cekani na zamek */
> 					update table set neco = ? where id =
> 2
> 				/* vysledek je deadlock a spadena transakce
> 				v session 1 (alespon v Oraclu) */
> 
> Tohle Vam u MySQL nenastane protoze po provedeni kazdeho prikazu je
> "transakce" commitnuta. Cili bylo by tam na neco zamykani po
> zaznamech? Kdyz by to byl zamek pouze na dobu provedeni toho SQL
> prikazu (ktera ano, muze byt dlouha), nikoli na dobu mezi SQL
> prikazy?
> 
Predpokladam, ze posledni prikaz mel byt ...id = 1
Pak opravdu dojde k deadlocku, ale jeste ne k padu transakce. I kdyz
rollback pravdepodobne bude dalsi prikaz.

Opravdu jsou asi zamky na zaznamy zbytecne v pripade, ze nepouzivate
tranakce. Ted jsem asi pochopil kam mirite.

Radim