Zalohovaci software - testovanie

[Ing. Pavel PaJaSoft Janoušek]

> -----Original Message-----
> From: Chlopcik Ales [mailto:chlopcik na vojnem-plzen.cz] 
> 	Ne, neni. V souboru je (muze byt => je) zapsana cast 
> transakce (treba
> sekvencni cisla) PO, ale dalsi data PRED transakci cislo 
> 1234. Neboli :
> V souboru je (diky trefe MEZI zapisy teze transakce) zapsana 
> pouze cast
> transakce => soubor(y) NENI konzistentni. Pokud BEHEM 
> vytvareni snapsotu
> neni ZAJISTENA konzistentnost souboru, pak je nejista. V tom je totiz
> jadro cokla, na kterem se nemuzeme shodnout. Ja tvrdim, ze transakce
> vyvolava VICE nez jeden zapis do databazovych souboru => jsem 
> schopen se
> pri vytvareni klonu/kopie/... trefit mezi dva zapisy teze transakce.
> Samozrejme, ze u MultiFile databazi je tato pravdepodobnost vyssi.

	A o tomto jste presvedcen z realnych implementaci nebo se jenom
domnivate? Ja nerikam, ze to nekdo takto zhovadile implementuje, ale
muzete mi nasledne zodpovedet, pokud by Vas popis byl realitou, jak
takovy datastor je schopen realneho zotaveni po HW chybe? Nezda se Vam,
ze pri tomto zpusobu v podstate datastor neni schopen se obnovit,
protoze bud a) musi bezmezne duverovat tomu co nacetl (coz v pripade HW
vypadku uz bude kravina - co ted?!) nebo si naopak musi implementovat
vlastni mechanicmy casovych zamku, konzistentnicht "tecek" apod.? A ja
tvrdim, ze vetsina rozumne implementovanych datastoru dela ty
"prasecinky" (v realu neatomicke operace z hlediska HW, protoze to jinak
nejde, do dnes jsme se v beznem HW s atomicnosti dostali maximalne na
Compare & Exchange - z hlediska teoretickych nastroju na hoooodne low
end urovni) v pameti a na disk zapisuje az vysledky, pripadne casove a
jine znacky (a pokud je to natolik rozsahle, tak mame docasne soubory
atd.) - a tam si bud je jist, ze je ZAPSAL (je na datastoru ci jeho
implementaci jak kvalitne si to zjisti) nebo nezapsal - preruseni klidne
i v prubehu zapisu, nic se nedeje, proste se odroluje. Mozna Vam to
uniklo, ale jsou databaze, ktere pro optimalni beh nepouzivani nic jako
system souboru v tradicnim podani, ale proste "prostor na disku" -
podobne jako alokovana pamet (treba partition) a zcela ve vlastni rezii
vse resi (co treba RAW zarizeni a Oracle?) - jak byste zazalohoval
takovyto datastor?

> byla, je (a IMHO i bude) definovana POUZE mezi klientem a 
> SRDB. Rozhodne

	A k cemu by takovato definice byla, kdyz by se klientovi lhalo,
ze neco provedl a je provedeno, on s tim pocital (respektive jedna jeho
kopie by si pri vycenasobnem pristupu si to myslela) a realita by byla
jina, nasledny pad by zcela znicil tyto informace a jina databaze na
uplne jinem miste by pocitala s tim, co ta "spadla" davno zapomnela... -
nezda se Vam to znacne priskrcene a paranoidni, ze by to takto mohlo
fungovat a realne bezet?

> NedejBoze pri
> kazdem cteni dat z disku :-) proverovat konzistentnost 
> nactenych (svych
> vlastnich :-) dat, pak TO bude mit dost tristni nasledky na jeji

	A Vy si myslite, ze se tak nedeje? Mozna Vam to uniklo, ale
zacina se s timto mechanismem uz na HW urovni (unitr disku), pak na
urovni sbernice (IMHO takove existuji, PCI to asi nebude - mozna se
mylim), nasleduje ECC v pameti, kontrolni soucty na urovni aplikace,
digitalni podpisy atd. nerikejte, ze Vam tyto pojmy nic nerikaji...
vidite, rikaji - bezne je pouzivate a ani je nevnimate, coz je dobre, je
to zamer...

> (nebot zalohovani jinymi nez databazovymi prostredky se u
> komercnich/vestich/lepsich/.... SRDB asi /IMHO/ nepredpoklada), pak se
> dostavame do dosti divokych oblasti.

	A co muj uvadeny realny priklad on-line zalohovani hooodne
velkeho datastoru formou zurnalu na pasku? Pripada Vam to divoke? - v
jakem smyslu - slozite, drahe?

> :-), ze konkretne Informix (verzi neznam, cca 10 let) obnovu z
> NevimJakUdelaneZalohy nerozdychal. Takze se toho chopili TeoReTici a

	Dekuji ze jste mi pripomnel nazev dotycneho datastoru, resp.
jeho puvodniho vyrobce, i zde kolega z AIS (ktery dneska tvori mlcici
vetsinu) bude vedet o kom hovorim, ale verte, ze takto se realne funguje
(dneska jiz hooodne let) a pro pojistovnu neco jako ztrata kmenoveho
stavu pojistek by byla fatalni... problemy byly a jsou s kde cim, ale
prijit o celou databazi si nedovoli... (na stranu druhou to neni az zase
tak "super" hype stroj, jak by nekdo cekal)

-------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)             FoNet, spol. s r. o.
Technicka podpora, Intranet/Internet     Sokolova 67, 619 00 Brno
E-mail: mailto:Janousek na FoNet.Cz         Tel.: +420  5  4324 4749
WWW:    http://WWW.FoNet.Cz/           E-mail: mailto:Info na FoNet.Cz
-------------------------------------------------------------------