Commit a data bezpecne na disku?

[Jan Serak]

Petr Novotny wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 27 Mar 00, at 12:53, Jan Serak wrote:
> 
> > > Samotne provedeni zapisu na UPDATE... muze trvat nekolik hodin.
> > > Zapis typu "uzivatel xxx provadi UPDATE... a ja jsem mu potvrdil, ze
> > > mam vsechna data" je zlomek sekundy. Pokud je na disku bezpecne
> > > zapsana takovato vec, lze pri obnovovani databaze po padu ten
> > > UPDATE... provest.
> >
> > Stale nerozumim. Co je 'provedeni zapisu na UPDATE'?
> 
> To znamena fyzickou zmenu dat v tabulkach. Mam-li pul miliardy
> radku vyhovujicich podmince v UPDATE, je zrejme, ze "kompletni
> provedeni" toho UPDATE bude trvat nekolik hodin. Rozumime si?
> 
> > Pri UPDATE
> > DBMS neco dela a zcela jiste neco zapisuje, ale co? Do dat? Do logu?
> 
> To je to, k cemu se snazim dopidit. Nezajimaji me spekulace
> "mohlo by to byt takto".
> 
> > Taky nechapu, co je provedeni (nebo dokonceni?) UPDATE, ktery byl
> > spusten pred padem OS, pri obnovovani databaze.
> 
> Model:
> 1. Klient predava databazi data pres UPDATE. (Soucasti UPDATE
> totiz jsou cenna data. Rozumime si?)
> 2.Klient zavola COMMIT.
> 3. Navratovy kod prikazu COMMIT je nejaky ekvivalent OK.
> Databaze zacina data zapisovat do hlavni tabulky (treba i nekolik
> milionu zapisu).
> 4. Dojde k padu databaze, nez #3 skonci.
> 5. Pouziji nejakou obdobu "fsck" na databazi. Pritom se obnovi
> korektni stav databaze. Provede se i ten UPDATE z kroku #1?

Takze jsme se dopidili: zalezi na DBMS. Napr. Oracle provadi primo
zmeny v datech a navic do logu zapisuje informace nutne pro obnoveni
puvodniho stavu v pripade, ze transakce neskonci COMMITem ale
ROLLBACKem. COMMIT potom znamena jen cvrnknuti disku, protze se jen
premaze log a odemcou modifikovane zaznamy (zhruba receno).

> 
> > Pokud hodlate experimentovat se sitovym vypinacem, tak muzete byt
> > naprosto klidny: pri takovemto zasahu muzete prijit i o data, ktera
> > byla na disk ulozena treba pred 14 dny, a to proste jen proto, ze
> > nebyl DBMS regulerne ukoncen. A neni se cemu divit, kdyz takova vec
> > dokaze rozhodit treba i filesystem.
> 
> filesystem opravim. Mate protipriklad?

Ale jak? Opravite ho tak, ze je strukturne cisty. Ale mate za vsech
okolnosti jistotu, ze po oprave bude obsahovat data, ktera nejaky
program ulozil (pomoci fclose()) tesne pred padem systemu?

> 
> Moment, vy se mi ted snazite rict, ze SQL je v jadru nespolehlivy
> protokol? 
> Ze klient nikdy nema jistotu, ze server data prevzal a
> zodpovida za ne? Uf. Jestli mate pravdu, budu muset nektere sve
> nazory prehodnotit.

Rozhodne se nesnazim tvrdit, ze SQL je protokol. A uz vubec se nesnazim
tvrdit, ze SQL podporuje klient - server. SQL je (doslova)
strukturovany dotazovaci jazyk (Structured Query Language), ktery
ma definovanou syntax a semantiku. Zpusob implementace zavisi
uz jen na vyrobci DBMS (viz popis prubehu transakce v Oracle a Vasem
DBMS).

> 
> > Za normalniho stavu v momente, kdy se ukonci COMMIT, je to starost
> > DBMS. Tedy v pripade transakcni databaze.
> 
> V tom pripade prosim o definici normalniho stavu.

Z pohledu, ze ktereho se na problem snazime divat, to znamena, ze je
zajisteno (virtualne neprerusitelne) napajeni serveru tak, ze pri
vypadku stihne dojit ke korektnimu shozeni DBMS na baterky.

					Jan Serak