Archív konference Delphi
Zpět na výběr roku archívu nebo přejít na fulltextové vyhledávání v konferenci.
Firebird a GBAK na velkou GDB
[*] Pavel Cisar <pcb(zv)atlas(tec)cz> - 19.10.2004 10:59:21
Haj hou!
On 19 Oct 2004 at 8:59, Petr Fejfar wrote:
> Diskuse nad timto bodem vznikla prece tak, ze ES napsal, ze aby MGA
> fungovala, tak se budou muset verzovat i indexy a PC odpovedel ze ne,
> ze se verzuji jen radky. Ale posleze doplnil, ze aby to fungovalo, tak
> uzel indexu obsahuje nekolik ruznych klicu ke kazde zapsane hodnote.
>
> A tim IMHO v podstate potvrdil puvodni namitku ES, ze se s indexem
> musi udelat ne zrovna lacina operace, i kdyz se ji zrovna nerika
> verzovani ;-)
Omyl, napsal jsem, ze uzel indexu obsahuje pouze jedinou hodnotu
klice a odkaz na radek, a ze muze existovat vice *uzlu* s ruznou
hodnotou klice, ktere odkazuji na stejny radek, resp. retez verzi
tohoto radku. Relevance nalezeneho uzlu / klice se vyhodnocuje pres
radek a jeho retez verzi pro dany transakcni kontext.
> Co kdybys misto osobnich utoku na ES dolozil tu evidentnost argumentu
> a co je u cache urcujicim kriteriem, kdyz ne vyznamny rozdil pristupovych
> dob k mediim?
>
> Osobne si nedovedu predstavit, ze by nekdo implementoval (+financoval)
> cache u systemu, ktera by mohla pracovat hur nez system bez cache.
> Ty o takovem systemu vis?
O tom jsem uz preci psal ja. Vubec totiz nejde o pristupovou dobu do
cache jak to vidi Erik, ale o uspesnost vyuziti cache, tedy zda jsou
data ctena z cache misto z disku. Zvetseni velikosti cache
automaticky neznamena zvyseni uspesnosti jejiho vyuziti (pominme
extremni pripad, kdy se cela databaze vejde do cache). Zalezi na
charakteristikach pristupu k datum (nahodny, sekvencni, frekvence,
lokalizace atd.) a mechanizmu rizeni obsahu cache. Ale to je jen
pulka problemu - cteni dat, samostatnou kapitolou je zapis skrz
cache.
Cache databazovych systemu se vyrazne lisi od zpusobu prace cache
napr. v operacnim systemu pro soubory na disku, nebo v CPU pro
instrukce. U Databazi existuje rada struktur zapisovanych odddelene
ktere jsou ale na sobe zavisle, a je nutne je zapisovat v presnem
konkretnim poradi, aby v pripade nedokonceneho zapisu (napr. z duvodu
vypadku proudu) nedoslo k poskozeni dat. Napr. u Firebirdu existuji
tzv. Pointer Pages (PP), ktere obsahuji mapu Datovych stranek (DP)
prirazenych dane tabulce. V pripade ulozeni dat do nove datove
stranky je treba aktualizovat a zapsat i prislusnou Pointer stranku.
Pokud by poradi bylo PP a pak DP, a k zapisu DP by z nejakeho duvodu
nedoslo, obsahovala by databaze odkaz (v PP) na neulozenou, a tedy
obsahove chybnou stranku. Po restartu by server pri pokusu o pristup
k teto datove strance vyhucel s chybou, a to dost natvrdo, protoze
integrita databaze je v haji. Pri zapisu v poradi DP a pak PP, pokud
k zapisu PP nedojde, bude databaze obsahovat DP na kterou se nelze
dostat (neodkazuje na ni PP), coz je sice nehezke, ale nedojde k
zadne chybe pri praci s databazi. Ona nedostupna DP stejne obsahuje
pouze nove vytvorena nepotvrzena data urcena k odstraneni. Podstatne
je, ze vnitrni integrita databaze neni narusena.
Vyse uvedenemu postupu se rika careful write, a je pro databazovy
system velmi dulezity. Pro menene stranky jejichz zapis je odlozen
(jsou v cache) je tedy nutne uchovavat orientovany graf zavislosti,
aby pak pri zapisu z cache na disk bylo dodrzeno poradi zapisu.
Slozitost struktury pro rizeni cache a careful write typicky roste s
velikosti cache (vyhledavani stranek v cache, grafy zavislosti),
proto muze byt prace s mensi cache rychlejsi nez s velkou cache.
Optimalni velikost cache je ruzna podle velikosti databaze,
charakteru dat a charakteru prace s nimi. Je nutne ji posuzovat a
nastavovat individualne, a plati to pro kazdy databazovy system.
Tohle myslim potvrdi kazdy zkuseny DBA.
S pozdravem
Pavel Cisar (ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix(tec)cz
Vse co potrebujete pro Firebird a InterBase
Vlakna - zobrazeni informaci uzivateli na jeden fo
[*] Petr Fejfar <development(zv)callnet(tec)cz> - 19.10.2004 10:55:20
Ing. Jiri Sokol wrote:
> problem nekde se synchronizaci, ale posledne jste mi radili, abych se
> vyvaroval uziti Synchronize ve vlaknech, ze pry jinak vlakna ani
> nemusim pouzivat.
Jenomze ty namitky se tykaly toho, ze jsi pomoci Synchronize spoustel cely
kod threadu - to ten thread pak skutecne k nicemu nepotrebujes.
Pokud je delka kodu provadeneho v ramci Synchronize rozumna a aplikaci
nevadi,
ze pokud se sejdou zadosti sychnronize, zastavi se v podstate vsechny
thready,
ktere synchronize volali, tak ji klidne volej, akorat se snaz omezit delku
kodu volaneho pres Synchronize na minimum.
Pokud to vadi nebo pokud se chces soustredit v budoucnu na propracovane
mutlithreaded aplikace, vyhodnejsi ale pracnejsi bude navrhnout si vlastni
IPC
(Inter Process Communication).
HTH, pf
Vlakna - zobrazeni informaci uzivateli na jeden fo
[*] Milan Tomes <delphi(zv)haida(tec)cz> - 19.10.2004 10:51:20
Ahoj,
AFAIK tak jak to mas je v poradku a z principu je nutno vsechna volani VCL
synchronizovat prave pres Synchronize.
Hlavni thread aplikace by mel byt vyhrazen interakci s uzivatelem kam
zobrazeni ListView rozhodne spada a tak to mas IMHO naprosto spravne.
Je pravda, ze Synchronize zpusobi to, ze se dana metoda provede v kontextu
main threadu, ale to je presne to o co tady bezi. Jedine upozorneni je
takove, aby dana metoda delala jen a jen to pridani do ListView - tedy
zadnou narocnou akci. Synchronize totiz onen volajici thread pozastavi do
okamziku ukonceni volane metody.
Ja jsem toto vzdy resil pres volani nejake metody formulare pres
Synchronize, ktera si precetla hodnoty z property volajiciho threadu a
provedla akci (v Tvem pripade pridani hodnoty do ListView).
S pozdravem
Milan Tomes
> [mailto:delphi-l-owner(zv)clexpert(tec)cz]On Behalf Of Ing. Jiri Sokol
> Sent: Tuesday, October 19, 2004 10:33 AM
>
> Ahoj!
> Potrebuju nakopnout s viz subjekt. Ted to mam tak, ze hlavni
> aplikace vytvori "informacni" formular, na kterym je ListView
> (aspon doufam, ze se nepletu - proste pridavam zaznamy do tabulky
> se 3 sloupci).
> Podle potreby tyto vlakna volaji jednu proceduru hlavniho
> formulare, ktera zapise na ten infromacni fomrular pozadovane informace.
> Tusim, ze toto neni spravna cesta. Automaticky me napada, ze bude
> problem nekde se synchronizaci, ale posledne jste mi radili,
> abych se vyvaroval uziti Synchronize ve vlaknech, ze pry jinak
> vlakna ani nemusim pouzivat. K priblizeni co se deje - pouzivam
Vlakna - zobrazeni informaci uzivateli na jeden fo
[*] delphin(zv)post(tec)cz - 19.10.2004 10:49:20
> Jak to resite teda vy, kdyz mate vice vlaken a potebujete neco uzivateli
napsat?
Napriklad poslat message hlavnimu vlaknu zpravu pomoci PostMessage.Chyba pri pouziti JCL debugeru
[*] Josef Zvonicek <prosoft(zv)prosoft(tec)cz> - 19.10.2004 10:43:19
Zdravim.
Mam problem pri pouziti JCL debugeru. Pokud mam zaskrknutou polozku Inser
JCL debug data tak pri prekladu programu se mi objevi okno JCL debug data
information a v nem Linker bug DirectShow9. Nevim co je spatne s timto
unitem. Pomuze mi nekdo?
Diky. Josef Zvonicek.
Project MAP file size JCLDebug size Ratio Executable file name
Linker bug Line errors
-------- ------------- ------------- -----
------------------------------------------------ ----------- -----------
tree.dpr 478185 54200 11,3 C:\DELPHI\PROJEKTY\Graficka
dokumentace\tree.exe DirectShow9 1
Vlakna - zobrazeni informaci uzivateli na jeden fo
[*] Ing. Jiri Sokol <js-delphi(zv)email(tec)cz> - 19.10.2004 10:33:18
Ahoj!
Potrebuju nakopnout s viz subjekt. Ted to mam tak, ze hlavni aplikace vytvori "informacni" formular, na kterym je ListView (aspon doufam, ze se nepletu - proste pridavam zaznamy do tabulky se 3 sloupci).
Podle potreby tyto vlakna volaji jednu proceduru hlavniho formulare, ktera zapise na ten infromacni fomrular pozadovane informace.
Tusim, ze toto neni spravna cesta. Automaticky me napada, ze bude problem nekde se synchronizaci, ale posledne jste mi radili, abych se vyvaroval uziti Synchronize ve vlaknech, ze pry jinak vlakna ani nemusim pouzivat. K priblizeni co se deje - pouzivam workflow vlaken Petra Fejfara, akorat ne pres semaphor, ale pres udalosti (nevznika mi fronta pozadavku). Tyto vlakna vytvorim jednou a protoze si nactou nejake data z databaze, se kterymi pak pracuji, tak tyto vlakna ziji po celou dobu zivota programu. Akorat vzdy provedou svoji akci a pak se "uspi".
Jak to resite teda vy, kdyz mate vice vlaken a potebujete neco uzivateli napsat?
Diky za rady
Jirka
--------------------------------------------------
Ing. Jiri Sokol; jiri.sokol(zv)seznam(tec)cz; 972 231 187
D6Prof+SP3; WinXPProf+SP1; FB 1.5.0
programator amater
Server/Client socket D5 vs. D7
[*] Jiri Cincura <diskuze(zv)cincura(tec)net> - 19.10.2004 10:31:18
mydelphiconf(zv)centrum(tec)cz wrote:
> Ahojky Delphini,
> v Delphi5 jsem mel v zalozce System mimojine i komponenty ServerSocket
> a KlientSocket. Ted jsem presel na D7 a ejhle, komponenty nikde ...
> nemuzu je nikde najit. Netusite, cim to Borland nahradil a pripadne
> jestli bude stejne pouziti (nejake url na tu 'novou alternativu' by se mi
> siklo ... :( )
No v D7 jsou komponenty Indy, ale me se moc nelibi (teda ze zacatku se mi
libily, ale jak jsem pronikal hloubeji ...). Ja bych ti doporucil Synapse
(http://synapse.ararat(tec)cz). Je to hromada Unit a trid, kde mas vsechno co
potrebujes. Me se libi vic.
--
Jiri Cincura
e-mail: mailto:jiri(zv)cincura.net; mailto:xcincura(zv)informatics.muni(tec)cz
ICQ#: 314711544
web:
http://www.cincura.net/
http://photo.cincura.net/
http://phorum.cincura.net/
---
A i kdyz je nase doba obtizna a zmatena, je podnetna a vyplnena
prilezitostmi. And if our times are difficult and perplexing, so are they
challenging and filled with opportunity. -Robert F. Kennedy, 1961
Cachovani (Was: Firebird a GBAK na velkou GDB)
[*] Milan Tomes <delphi(zv)haida(tec)cz> - 19.10.2004 10:13:17
> [mailto:delphi-l-owner(zv)clexpert(tec)cz]On Behalf Of Petr Fejfar
> Sent: Tuesday, October 19, 2004 9:53 AM
>
> Milan Tomes wrote:
>
> > Ja netvrdim, ze existuje takovy system, ale pokud vezmu situaci, kdy
> > existuje cache jen pro cteni - a to je to o cem ES psal - tak mi pri
> > neustalem zapisu (rozumej pouze pri zapisu, kdy se neprovadi zadna
> > operace cteni) je k nicemu a navic me muze jeste zpomalit.
>
> Tady mi neco zrejme unika...
>
> Ano, v nejhorsim pripade ti cache bude k nicemu.
> Ale jak muze RO cache zpomalit operaci zapisu?
Zalezi na konkretni implementaci - pokud si predstavim vlakno, starajici se
o casovou relevanci obsahu cache, tak je to jasne...
Priklad:
1. V cache mam stranku c. 1
2. prave provadim zapis stranky 1 se zmenenym obsahem
Napadaji me dve reseni:
1. Dam cache vedet - znovu si nacti obsah, tvuj stavajici je neplatny
2. Pri kazdem dotazu na stranku v cache si nejdrive overim platnost udaju
Pojem stranka si muzes nahradit treba souborem
Prijde mi, ze reseni 1 je lepsi, ale je to jen muj osobni nazor, a v ten
okamzik zde mam rezii, kterou nepotrebuji...
Pri reseni c. 2 mam zase zbytecnou rezii pri kazdem dotazu na udaj v cache.
Je samozrejme, ze na modernich systemech je tato rezie vicemene
zanedbatelna. Cele moje snazeni bylo o tom, dokazat, ze *v nekterych
situacich* cache zpomaluje. Na tom se asi shodneme.
S pozdravem
Milan Tomes
Cachovani (Was: Firebird a GBAK na velkou GDB)
[*] Petr Fejfar <development(zv)callnet(tec)cz> - 19.10.2004 09:53:15
Milan Tomes wrote:
> Ja netvrdim, ze existuje takovy system, ale pokud vezmu situaci, kdy
> existuje cache jen pro cteni - a to je to o cem ES psal - tak mi pri
> neustalem zapisu (rozumej pouze pri zapisu, kdy se neprovadi zadna
> operace cteni) je k nicemu a navic me muze jeste zpomalit.
Tady mi neco zrejme unika...
Ano, v nejhorsim pripade ti cache bude k nicemu.
Ale jak muze RO cache zpomalit operaci zapisu?
> HDD s cache, CPU s cache, SQL server s cache (pro cteni - pro zapis je
> vypnuta) a ja budu jen a jen zapisovat. K cemu je mi cache pro cteni
> ??? K nicemu a jeste bude probihat thread, ktery se stara o jeji
> spravu i kdyz ji v dany okamzik nepotrebuji.
No ale rezie toho threadu bude urcite zanedbatelna vzhledem k prenosu dat
nativni rychlosti, ne? A tak ja taky rozumim namitce ES.
pf
Server/Client socket D5 vs. D7
[*] mydelphiconf(zv)centrum(tec)cz - 19.10.2004 10:07:16
Ahojky Delphini,
v Delphi5 jsem mel v zalozce System mimojine i komponenty ServerSocket a KlientSocket. Ted jsem presel na D7 a ejhle, komponenty nikde ... nemuzu je nikde najit. Netusite, cim to Borland nahradil a pripadne jestli bude stejne pouziti (nejake url na tu 'novou alternativu' by se mi siklo ... :( )
Diky moc, P.
WinXP SP2, D7 Ent.
MGA a indexy (Was: Firebird a GBAK na velkou GDB)
[*] Milan Tomes <delphi(zv)haida(tec)cz> - 19.10.2004 09:53:15
> [mailto:delphi-l-owner(zv)clexpert(tec)cz]On Behalf Of Petr Fejfar
> Sent: Tuesday, October 19, 2004 9:45 AM
>
> Milan Tomes wrote:
>
> > Jenze dle toho jak jsem to pochopil ja se s indexem jako takovym
> > vubec nic v okamziku vytvareni nove verze radku nic nedela. Do
> > tabulky verzi radku se zapise nova verze a index ukazuje na tu
> > tabulku verzi - kde je tedy nejaka operace *s indexem* ???
>
> A jak bys tedy uplatnil index pri hledani hodnoty nove generace
> - tusim to bylo Patrik, kdyz puvodni uzel obsahoval Erik?
> Ten index se prece nejak musi updatnout.
>
> Tohle si vykladam tak, pri vlozeni hodnoty nove generace se prida uzel
> ukazujici na puvodni record, za kterym je seznam generaci, ze ktere
> se vybere ta prava. Ale mohu se mylit - pak mi ale stejne jako ES neni
> jasne,
> jak MGA pracuje s indexy.
Kaju se kaju - mas pravdu. Nutne musi dojit a take dojde k aktualizaci
indexu presne tak jak popisujes - na spravne misto se prida nova polozka
ukazujici na tabulku verzi dotycneho zaznamu. Jestli je polozka indexu
relevantni potom rozhoduje kontext transakce.
S pozdravem
Milan Tomes
MGA a indexy (Was: Firebird a GBAK na velkou GDB)
[*] Petr Fejfar <development(zv)callnet(tec)cz> - 19.10.2004 09:45:14
Milan Tomes wrote:
> Jenze dle toho jak jsem to pochopil ja se s indexem jako takovym
> vubec nic v okamziku vytvareni nove verze radku nic nedela. Do
> tabulky verzi radku se zapise nova verze a index ukazuje na tu
> tabulku verzi - kde je tedy nejaka operace *s indexem* ???
A jak bys tedy uplatnil index pri hledani hodnoty nove generace
- tusim to bylo Patrik, kdyz puvodni uzel obsahoval Erik?
Ten index se prece nejak musi updatnout.<CITE PC>
Kazdy radek ma konkretni, fixni pozici v databazi, kde zacina retez
verzi (pokud jich je vice), pocinaje nejnovejsi verzi. Uzel indexu
obsahuje hodnotu klice a odkaz na radek -> celo retezu. Index muze
obsahovat vice uzlu s ruznymi klici odkazujicimi na stejny radek /
retez. O relevanci radku rozhoduje hodnota radku pro dany transakcni
kontext.
</CITE>
Tohle si vykladam tak, pri vlozeni hodnoty nove generace se prida uzel
ukazujici na puvodni record, za kterym je seznam generaci, ze ktere
se vybere ta prava. Ale mohu se mylit - pak mi ale stejne jako ES neni
jasne,
jak MGA pracuje s indexy.
pf
Firebird a GBAK na velkou GDB
[*] Milan Tomes <delphi(zv)haida(tec)cz> - 19.10.2004 09:23:12
> -----Original Message-----
> From: delphi-l-owner(zv)clexpert(tec)cz
> [mailto:delphi-l-owner(zv)clexpert(tec)cz]On Behalf Of Petr Fejfar
> Sent: Tuesday, October 19, 2004 8:59 AM
> To: delphi-l(zv)clexpert(tec)cz
> Subject: Re: Firebird a GBAK na velkou GDB
>
>
> Milan Tomes wrote:
>
> > probehne jen jeden - kde je tedy ono smeti na ktere neustale
> > poukazujes ??? Ze by v tom "nieco robi" ??? :)))
>
> Vzdyt ti to tam ES explicitne napsal:
>
> <CITE>
> To znamena, ze ak Transakcia1 vytvorila nejake nove generacie zaznamov
> (v ramci tych operacii "nieco robi"), tak to bolo zbytocne a
> </CITE>
>
> > Pokud jsem to pochopil dobre ja, tak jsi to Ty dobre nepochopil -
> > index ukazuje na zacatek tabulky s verzemi zaznamu tj. v podstate na
> > jednu strukturu a vybere se zaznam, ktery je v danem kontextu
> > relevantni.
>
> Diskuse nad timto bodem vznikla prece tak, ze ES napsal, ze aby MGA
> fungovala,
> tak se budou muset verzovat i indexy a PC odpovedel ze ne, ze se
> verzuji jen
> radky.
> Ale posleze doplnil, ze aby to fungovalo, tak uzel indexu
> obsahuje nekolik
> ruznych klicu ke kazde zapsane hodnote.
>
> A tim IMHO v podstate potvrdil puvodni namitku ES, ze se s indexem musi
> udelat
> ne zrovna lacina operace, i kdyz se ji zrovna nerika verzovani ;-)
Jenze dle toho jak jsem to pochopil ja se s indexem jako takovym vubec nic v
okamziku vytvareni nove verze radku nic nedela. Do tabulky verzi radku se
zapise nova verze a index ukazuje na tu tabulku verzi - kde je tedy nejaka
operace *s indexem* ???
>
> >>> 1. Sprava cache ma vlastni rezii, ktera diky nutnosti implementace
> >>> careful write dle orientovanych grafu zavislosti v ramci cache u
> >>> kazdeho db enginu neni nijak mala, a s velikosti cache narusta.
> >>> 2. Na ucinnost cache maji vliv dalsi faktory (access patterns,
> >>> mechanizmus rizeni obsahu atd.)
> >> uz si sa v praxi stretol s pripadom, ked po zvecseni RAMky
> >> doslo v dosledku zvysenej rezie spravy pamete k znizeniu vykonu
> >> pocitaca a bolo potrebne RAMku zmensit? Ja este nie.
> >> Pomer pristupovej doby disku a RAM-ky je asi milion, takze
> >> to by musela byt poriadne komplikovana a neefektivna
> >> sprava pameti aby sa nevyplatila. V praxi su skor ine problemy,
> >> ze ta RAMka nieco stoji.
> >
> > Nejde o pristupove doby... Ale ja vim - Ty mas preci vzdy pravdu ne
> > ??? Poskytnout Ti nejaky argument, ktery je zcela evidentni Ti
> > opravdu nestaci a je to jen jako hazet hrach na zed... :(((((((
>
> Co kdybys misto osobnich utoku na ES dolozil tu evidentnost argumentu
> a co je u cache urcujicim kriteriem, kdyz ne vyznamny rozdil pristupovych
> dob k mediim?
>
> Osobne si nedovedu predstavit, ze by nekdo implementoval (+financoval)
> cache u systemu, ktera by mohla pracovat hur nez system bez cache.
> Ty o takovem systemu vis?
Ja netvrdim, ze existuje takovy system, ale pokud vezmu situaci, kdy
existuje cache jen pro cteni - a to je to o cem ES psal - tak mi pri
neustalem zapisu (rozumej pouze pri zapisu, kdy se neprovadi zadna operace
cteni) je k nicemu a navic me muze jeste zpomalit. Neber v potaz jakoukoliv
jinou cache nez tu, kterou ma databazovy stroj a kterou si take sam
spravuje. Je samozrejme - a to jsem take psal - ze cache sama o sobe
zrychluje pristup k jednotlivym zarizenim (at uz k RAM, HDD ci jinemu
zdroji), ale jsou situace kdy je vicemene zbytecna, protoze neprinasi zadne
zrychleni ba naopak jeji rezie prinasi zpomaleni.
Je samozrejme, ze i cache pro cteni casto zpomaluje, ale pokud si vezmeme
pomer mezi zpomalenim a zrychlenim, tak se dostavame napr. do cisel 1:1000 a
pak se samozrejme ono zpomaleni - zcela logicky - vynecha.
Takze vezmeme nasledujici situaci:
HDD s cache, CPU s cache, SQL server s cache (pro cteni - pro zapis je
vypnuta) a ja budu jen a jen zapisovat. K cemu je mi cache pro cteni ??? K
nicemu a jeste bude probihat thread, ktery se stara o jeji spravu i kdyz ji
v dany okamzik nepotrebuji. Toto jsem mel na mysli. Je samozrejme, ze se
vetsinou nejaka operace cteni vyskytne, ale pri zapisu by me tato cache
pouze obtezovala.
Jinak se ES omlouvam za osobni utok, ale opravdu me rozciluji lide, kteri
MUSI mit za kazdou cenu pravdu a nejsou ochotni prijmout argumenty jinych.
Jeste bych rad zareagoval na onen puvodni vyrok Erika:
<CITE>
uz si sa v praxi stretol s pripadom, ked po zvecseni RAMky
doslo v dosledku zvysenej rezie spravy pamete k znizeniu vykonu
pocitaca a bolo potrebne RAMku zmensit? Ja este nie.
Pomer pristupovej doby disku a RAM-ky je asi milion, takze
to by musela byt poriadne komplikovana a neefektivna
sprava pameti aby sa nevyplatila. V praxi su skor ine problemy,
ze ta RAMka nieco stoji.
</CITE>
Ano - pokud zvetsis pamet RAM, tak se nepochybne i zvysi spotreba strojoveho
casu na jeji obnovu (nezapominej, ze se jedna o dynamicke pameti RAM a musi
se neustale obnovovat - tusim, ze kdysi se to cislo pohybovalo nekde okolo
4ms), ale jeji prinos je vyvazen mensim vyuzitim strankovaciho souboru -
samozrejme v pripade pouziti Windows - a tudiz je pridani RAM vnimano jako
zrychleni. Odmysli si vsak operacni system a mer cas procesoru, ktery se
stravi vlastnim refreshem obsahu pameti a uvidis...
S pozdravem
Milan Tomes
Firebird a GBAK na velkou GDB
[*] Richard Kejval <kejval.delphi(zv)centrum(tec)cz> - 19.10.2004 09:13:12
> tak teda uvediem jednoduchy priklad, kedy sa nevyhoda MGA
> z hladiska mozneho generovania zbytocneho smetia prejavi:
>
> Uvazujme tabulku, v ktorej je zaznam s polozkou Erik a dve
> transakcie, ktore tu polozku budu citat aj zapisovat. Transakcie
> su uvedene vedla seba, ako bezia (T1 bola spustena trocha skor
> ako T2):
>
> 1. Optimisticke zamykanie (MGA)
>
> Transakcia1 Transakcia2
>
> precita 'Erik' precita 'Erik'
> nieco robi zapise 'Patrik' (ako novu generaciu)
> nieco robi nieco robi
> nemoze zapisat 'Fero' nieco robi
> rollback commit
>
Na tomto prikladu je jasne videt, ze si vubec nepochopil, nebo
nechces pochopit praci s transakcemi. Vzdyt Ti tam chybi uplne
zakladni predpoklad, s jakou urovni izolace jednotlive transakce
pristupuji k datum. Bez toho je to uplny blabol..
S pozdravem
ing. Richard Kejval
mobil: 602477679
http://www.icsoftware(tec)cz
Firebird a GBAK na velkou GDB
[*] Petr Fejfar <development(zv)callnet(tec)cz> - 19.10.2004 08:59:10
Milan Tomes wrote:
> probehne jen jeden - kde je tedy ono smeti na ktere neustale
> poukazujes ??? Ze by v tom "nieco robi" ??? :)))
Vzdyt ti to tam ES explicitne napsal:
<CITE>
To znamena, ze ak Transakcia1 vytvorila nejake nove generacie zaznamov
(v ramci tych operacii "nieco robi"), tak to bolo zbytocne a
</CITE>> Pokud jsem to pochopil dobre ja, tak jsi to Ty dobre nepochopil -
> index ukazuje na zacatek tabulky s verzemi zaznamu tj. v podstate na
> jednu strukturu a vybere se zaznam, ktery je v danem kontextu
> relevantni.
Diskuse nad timto bodem vznikla prece tak, ze ES napsal, ze aby MGA
fungovala,
tak se budou muset verzovat i indexy a PC odpovedel ze ne, ze se verzuji jen
radky.
Ale posleze doplnil, ze aby to fungovalo, tak uzel indexu obsahuje nekolik
ruznych klicu ke kazde zapsane hodnote.
A tim IMHO v podstate potvrdil puvodni namitku ES, ze se s indexem musi
udelat
ne zrovna lacina operace, i kdyz se ji zrovna nerika verzovani ;-)>>> 1. Sprava cache ma vlastni rezii, ktera diky nutnosti implementace
>>> careful write dle orientovanych grafu zavislosti v ramci cache u
>>> kazdeho db enginu neni nijak mala, a s velikosti cache narusta.
>>> 2. Na ucinnost cache maji vliv dalsi faktory (access patterns,
>>> mechanizmus rizeni obsahu atd.)
>> uz si sa v praxi stretol s pripadom, ked po zvecseni RAMky
>> doslo v dosledku zvysenej rezie spravy pamete k znizeniu vykonu
>> pocitaca a bolo potrebne RAMku zmensit? Ja este nie.
>> Pomer pristupovej doby disku a RAM-ky je asi milion, takze
>> to by musela byt poriadne komplikovana a neefektivna
>> sprava pameti aby sa nevyplatila. V praxi su skor ine problemy,
>> ze ta RAMka nieco stoji.
>
> Nejde o pristupove doby... Ale ja vim - Ty mas preci vzdy pravdu ne
> ??? Poskytnout Ti nejaky argument, ktery je zcela evidentni Ti
> opravdu nestaci a je to jen jako hazet hrach na zed... :(((((((
Co kdybys misto osobnich utoku na ES dolozil tu evidentnost argumentu
a co je u cache urcujicim kriteriem, kdyz ne vyznamny rozdil pristupovych
dob k mediim?
Osobne si nedovedu predstavit, ze by nekdo implementoval (+financoval)
cache u systemu, ktera by mohla pracovat hur nez system bez cache.
Ty o takovem systemu vis?
pf
Firebird a GBAK na velkou GDB
[*] Stepan Dobias <stepan.dobias(zv)del(tec)cz> - 19.10.2004 08:53:10
Pro Slavka - "CZ Strakonice, a.s (Vsude je FB a full backup kazdych 8
hodin.)" . - je pro me prekvapeni, ze tam bezi zalohovani kazdych 8 hodin
kdyz jsem sam nastavoval zalohovani jednou denne. Pokud si dobre vzpominam
sam jsi tvrdil, ze zalohovani prilis zatezovalo system.
Pro priznivce Firebirdu :
Moc teda Firebird neznam, ale jak jsem pochopil z predchozich prispevkum P.
Cisare tak jsme nedelali nic blbe a on Backup a Restore skutecne trva tak
strasne dlouho. V porovnani s MS SQL 2000 asi tak 3 az 5 nasobek casu na
stejne velke DB (Pri Restore je rozdil jeste vyraznejsi). Jde to tedy na
vrub Multigeracni architektury (dle P. Cisare) a souhlasim s tim, ze pokud
to vyvojar vi tak se s tim dokaze vyrovnat.
Zalohovani:
Mohl by nekdo presne specifikovat proc by mel byt problem pri zalohovani MS
SQL 2000? My to provozujume kazdy den na zatizene DB a nemame s tim zatim
zadny problem (uz asi 3 rok). Odpoved bych ocenil od nekoho kdo ma
zkusenosti a ne od nekoho kdo neco nekde slysel od souseda. Rad se necham
poucit o moznych problemech.
S pozdravem
Stepan
Firebird a GBAK na velkou GDB
[*] Lstiburek Pavel <lstiburek(zv)ceb(tec)cz> - 19.10.2004 08:35:07
On backup na MSSQL pracuje trochu sloziteji (nez jsem sam napsal),
backupovana nejsou jen data, ale i log. Do backupu jsou poslany vsechny
zaznamy bez ohledu na stav transkaci, ktera meni.
Pri restore jsou, ale vsechny nedokoncene nebo startu backup zahajene
operace odrolovany. Stejne tak je mozno i restorovat do libovolneho
okamziku v minulosti po startu backupu (az tam co mame k dispozici log).
To je i jeden z duvodu proc backup-restore nevede k zadne reoganizaci
DB, mam proste stejny srot jako pred touto operaci.
Stejne tak operace shrink jsou na vekych a zatizenych DB dost problematicke.
Log proste roste rychleji nez ho stacim sklepavat.
Provozuji DB o velikosti cca 2G a log staci vzhledem narust cca o 50-200M
denne, v zavislosti na zatizeni. Nutnost "seklepavat" log je jediny duvod proc
je DB prevadena 1x tydne do "dbo only" modu, aby mohl probehnout shrink.
Pavel
> From: Winsoft [mailto:winsoft(zv)netkosice.sk]
> > cte existujici data. Pochop prosim, ze kdyz znas MS SQL
> a/nebo Oracle, tak
> > to neznamena, ze znas vse. Opravdu si nedokazu predstavit on-line
> zalohovani
> > na MS SQL.
>
> tak som si pozrel manual MS SQL 2000, ked to tu uz riesime. On-line
> zalohovanie tam ma fungovat. A aspon v kratkosti este zopar
> informacii:
>
> 1. je tam niekolko typov backupov (napr. Database, Database
> differential,
> Transaction log, File or file differential) a tri recovery
> modely: Simple,
> Full, Bulk-Logged.
>
> Co sa tyka vplyvu transakcii na zalohovanie, tak citujem "Performing a
> backup
> operation has minimal effect on running transactions, so
> backup operations
> can
> be run during normal operations."
>
> 2. Co sa tyka restrikcii na backup, tak opet citujem (kompletne):
>
> ---------------------
>
> Backup Restrictions
> In Microsoft? SQL ServerT, backup operations can occur while
> the database is
> online and in use. However, some operations are not allowed during a
> database backup:
>
> a.. Creating or deleting database files.
>
> b.. The file truncation portion of a shrink operation on either the
> database (automatically or manually) or the database files.
> They will fail
> if a backup is running. You can perform the truncation after
> the backup
> completes. For more information, see Shrinking a Database.
>
> If a backup is started when one of these operations is in
> progress, the
> backup waits for the operation to complete, up to the limit set by the
> session timeout. If a backup is in progress and one of these
> operations is
> attempted, the operation fails and the backup continues.
>
> ---------------------
>
> 3. A este zopar veci, ktore ma zaujali (je tam toho vela,
> presiel som to
> len zbezne):
>
> - Backup and Recovery of Related Databases (umoznuje urobit zalohu
> dvoch alebo viacerych databaz, ktore musia byt logicky konzistentne)
>
> - Partial Database Restore Operations (napr. ak aplikacia omylom
> zrusila tabulku je mozne obnovit len tu cast databazy, ktora
> obsahovala
> tabulku. Tiez sa to da pouzit na vytvorenie podmnoziny databazy
> na inom serveri pre vyvojarske ucely alebo pre reporty)
>
> - Restarting Interrupted Backup and Restore Operations (v pripade
> ak backup alebo restore operacia je prerusena, napr. v dosledku
> vypadku prudu, je mozne restartnut tu operaciu od bodu, v ktorom
> doslo k peruseniu)
>
> 4. Dalej su tam rady ohladom Handling Large Mission-Critical
> Environments, teda ako zvysit rychlost backup a restore operacii.
>
>
Textovy vystup
[*] Marian Nykel <m.any(zv)centrum(tec)cz> - 19.10.2004 07:37:03
Asi bych na to sel pres funkci Format - lze v ni nastavit pocet znaku vystupu,
zarovnani, vyplnovani atd. Chce si to s ni jenom pohrat...
--
mANY
Textovy vystup
[*] Obermaier Petr Ing. <obermaier(zv)mail.sdas(tec)cz> - 19.10.2004 07:37:03
From: delphi-l-owner(zv)clexpert(tec)cz [mailto:delphi-l-owner(zv)clexpert(tec)cz]On Behalf Of mr.guest_delphi(zv)centrum(tec)cz
Jak tohle srovnat :
Korpus: Hloubka x Vyska Celo: Vyska x Sirka
- urci si max. sirky sloupcu
- pracuj s pomocnym stringem naplnenym mezerami pro sumu max. sirek s uvazovanim dalsich "pevnych" mezer mezi sloupci
- v pomocnem stringu na pozici "suma max. sirky predch. sloupcu" + 1 zapisuj pres Copy hodnoty pro aktualni sloupec
- vypis zobrazuj neproporcionalnim fontem (courier, lucida)
Firebird a GBAK na velkou GDB
[*] Karel Rys <delphi(zv)zas-me(tec)cz> - 19.10.2004 07:13:01
Winsoft dne 18 Oct 2004 v 16:17:
> a ako sa riesi zmena programu alebo databazy, ked dojde k zmene
> legislativy, alebo zmene struktury alebo fungovania podniku, alebo
> chyby v programe? To vsetko sa riesi za chodu systemu za plnej
> prevadzky?
Kvuli zmene struktury databaze je samozrejme nutne, aby s ni uzivatele v dany moment nepracovali -
to vsak, se svym omezenym obzorem, povazuju za vicemene samozrejme u kazde databaze, bez ohledu na
to, zda pouziva MGA nebo ne.
> Aky je to podnik, ze sa tam pracuje aj v nedelu a cez sviatky s
> informacnym systemom?
Neni to tak trochu jedno? ;-) Takove provozy proste jsou a mam s nimi co do cineni, nicmene to sem
preci vubec nepatri!
Karel Rys
Firebird a GBAK na velkou GDB
[*] Milan Tomes <delphi(zv)haida(tec)cz> - 19.10.2004 06:42:59
> [mailto:delphi-l-owner(zv)clexpert(tec)cz]On Behalf Of Winsoft
> Sent: Monday, October 18, 2004 10:56 PM
>
> > Protoze puvodni hodnotu radku (tedy smeti, ale smeti se z toho stava
> > teprve az po commitu) se *musi* generovat a uchovavat bez ohledu na
> > zvolenou architekturu, to same co jsi napsal plati i pro system se
> > zamky a transakcnim logem. Jedna transakce vygeneruje "smeti"
> > zbytecne.
>
> tak teda uvediem jednoduchy priklad, kedy sa nevyhoda MGA
> z hladiska mozneho generovania zbytocneho smetia prejavi:
>
> Uvazujme tabulku, v ktorej je zaznam s polozkou Erik a dve
> transakcie, ktore tu polozku budu citat aj zapisovat. Transakcie
> su uvedene vedla seba, ako bezia (T1 bola spustena trocha skor
> ako T2):
>
> 1. Optimisticke zamykanie (MGA)
>
> Transakcia1 Transakcia2
>
> precita 'Erik' precita 'Erik'
> nieco robi zapise 'Patrik' (ako novu generaciu)
> nieco robi nieco robi
> nemoze zapisat 'Fero' nieco robi
> rollback commit
Opet nemas pravdu - i v MGA architekture se da transakci rici, ze ma cekat a
ne hned vyhodit chybu, nicmene tento priklad mi neprijde jako normalni a
bezny. Nicmene netvrdim, ze se nemuze stat. V praxi bude onen zapis spise
podminen nejakou podminkou. A i kdyby v tomto pripade nebyl tento priklad na
MGA rychlejsi, tak je milion dalsich, kdy tato architektura zrychleni
prinese. Napr.: proc by mela transakce 2 cekat na dokonceni transakce 1 kdyz
se jenom cetli zaznamy ??? Opravdu se neda tohle nejak pausalizovat.
A jak jiz psal P. Cisar - "smeti" se generuje jen pri zapisu a ten probehne
jen jeden - kde je tedy ono smeti na ktere neustale poukazujes ??? Ze by v
tom "nieco robi" ??? :)))
> Teda Transakcia2 zbehla ale Transkacia1 nie. To znamena,
> ze ak Transakcia1 vytvorila nejake nove generacie zaznamov
> (v ramci tych operacii "nieco robi"), tak to bolo zbytocne a
> tie zaznamy su nanic a teda vzniklo smetie. Cize Transakcia1
> bezala a zatazovala system zbytocne a okrem mozneho smetia,
> zatazenia systemu a sposobenia novej generacie zaznamu 'Patrik'
> nic nevyriesila.
>
> 2. Pesimisticke zamykanie so zamkami
>
> Transakcia1 Transakcia2
>
> precita 'Erik' nemoze precitat (zamknute), tak caka
> nieco robi caka
> nieco robi caka
> zapise 'Fero' caka
> nieco robi caka
> commit odomknute, precita 'Fero'
> zapise 'Patrik'
> nieco robi
> nieco robi
> commit
A delka dobehnuti transakce 2 muze byt i nekolik dnu... No fuj... :)))
Predpokladam, ze i pri pouziti pesimistickeho zamykani se muze transakci
rici - "v pripade konfliktu okamzite skonci". Zaroven me ale napada, ze
takovy system by byl v praxi vlastne nepouzitelny, protoze by transakce
predcasne koncili temer neustale... Dle mych zkusenosti probiha soucasne
cteni dost casto, ale samozrejme zalezi opet na programatorovi. Je nutno
prizpusobit zpusob programovani a vsechny transakce - i ty u kterych to neni
vyslovne potreba - musi byt dokonceny v co nejkratsim casovem intervalu coz
znamena pouziti nejakeho meziclanku ve forme MemoryDatasetu apod...
>
> Zbehli obidve transakcie, jedna z nich ale cakala, kym sa uvolni zamok.
> Ziadne smetie nevzniklo, v trans. logu su zmeny, ktore boli aj komitnute.
>
> Aj v systeme so zamkami ale mozu vzniknut deadlocky a transakcia
> vtedy nezbehne (napr. ked sa zamknuty zaznam zisti neskoro a dovtedy
> samotna transakcia zamkla ine zaznamy).
>
> > > V pripade pouzitia zamkov, ak transakcia narazi na zamknuty zaznam,
> > > tak nepokracuje, ale caka na odomknutie. Cize pobezi len ta prva
> > > transakcia, ta druha bude cakat a nebude zatazovat system (teda sice
> > > tato transakcia stoji a caka, ale o to rychlejsie pobezi ta, co bezi).
> >
> > 1. Databaze maji typicky dva rezimy: cekani na uvolneni blokovaneho
> > zdroje, a rezim kdy je chyba okamzite nahlasena. Ty popisujes pouze
> > prvni pripad.
>
> MS SQL caka na odomknutie, pricom je mozne definovat timeout.
> Prednastavene je nekonecne cakanie. Samozrejme deadlocky
> sa detekuju, po ich zisteni sa uz necaka ale jedna transakcia
> sa zrusi (a druha moze pokracovat).
Proc opakujes to same, co psal P. Cisar ???
>
> > > A po komitnuti prvej transakcie a uvolneni zamkov moze pokracuje
> > > a komitnut aj druha transakcia.
> >
> > Si delas legraci ? Po komitnuti prvni transakce to muze akorat tak
> > vyhucet na chybu, nijak by doslo k "lost update". Blokovana transakce
> > muze ulozit sve zmeny *pouze* pokud blokujici transakce bude
> > odvolana.
>
> pozri ten moj priklad, tam to tak bezi
>
> > > praveze MGA vyraba zbytocne zaznamy, lebo nepredchadza
> > > konfliktom pesimisticky ale optimisticky
> >
> > 1. Optimisticke zamykani vede k nepomerne vyssi propustnosti
> > soubzneho zpracovani nez pesimisticke, to je vedecky dokazany fakt.
>
> zial, nie vzdy. V uvedenom priklade to tak nebolo.
>
> > > ako to, ze nie su verzovane indexy? Ako sa potom hlada v roznych
> generaciach
> > > zaznamu? A kedy sa tie indexy potom vlastne aktualizuju? Toto mi
> vysvetli,
> > > nejako neviem najst uspokojive riesenie (co neznamena, ze neexistuje
> ;-) ).
> >
> > Kazdy radek ma konkretni, fixni pozici v databazi, kde zacina retez
> > verzi (pokud jich je vice), pocinaje nejnovejsi verzi. Uzel indexu
> > obsahuje hodnotu klice a odkaz na radek -> celo retezu. Index muze
> > obsahovat vice uzlu s ruznymi klici odkazujicimi na stejny radek /
> > retez. O relevanci radku rozhoduje hodnota radku pro dany transakcni
> > kontext.
>
> cize ak som to dobre pochopil, index obsahuje odkazy na rozne
> generacie zaznamov a dodatocne je potrebne overit, ci ten zaznam
> vybrany indexom je z tej mojej transakcie. Tu je potom este
> otazka, ci sa nieco robi s indexom vtedy, ked transakcia zbehne,
> resp. ked nezbehne. Teda ci sa ten index aktualizuje (napr. po
> zbehnuti transakcie sa mozu IMHO v indexe zrusit odkazy
> na stare generacie zaznamov, ktore boli transakciou prepisane).
> alebo sa ponechava ako je a upratovanie indexov sa robi
> dodatocne cez ten sweep (dufam, ze tak sa to v IB vola)
> alebo priebeznym upratovanim.
Pokud jsem to pochopil dobre ja, tak jsi to Ty dobre nepochopil - index
ukazuje na zacatek tabulky s verzemi zaznamu tj. v podstate na jednu
strukturu a vybere se zaznam, ktery je v danem kontextu relevantni.
>
> > Tento system ma sice tu nevyhodu, ze pro nektere operace napr.
> > zjisteni poctu radku v tabulce nelze pouzit *jen* index, ale na
> > druhou stranu odpadaji jakekoliv hratky s indexem v pripade
> > rollbacku, problemy synchronizace transakci na indexech apod. ktere
> > postihuji systemy bez MGA.
>
> takze pocas upratovania, ok
>
> > Zkus se nad tim zamyslet jeste jednou. Zjistis, ze se realny vykon
> > soubezneho zpracovani nezvysi, ale naopak snizi. Vzroste totiz vyskyt
> > "falesnych" kolizi.
>
> lenze falosna kolizia ak sa zamok zisti vcas, nema iny dopad
> ako pozdrzanie transakcie. Cize nemusi to byt vzdy nevyhodne.
Ja osobne to vidim jako naprosto tragickou nevyhodu. Co treba ukazes
uzivateli, ktery ceka na dokonceni operace ??? Neco jako "Nezlobte se, ale
jiny uzivatel prave cte jakykoliv z milionu radku, ktery prave potrebujete
cist i Vy" ??? Pak si bude klepat na celo, protoze selsky rozum rika - "proc
bych to nemohl cist take - vzdyt noviny si muze take cist nekolik lidi
naraz"... A zase jsme u osobniho nazoru... :)))
>
> V MDA je paralelizmus vecsi, ale zas to nemusi byt vzdy vyhodne.
> V priklade, co som uviedol, nebola ziadna vyhoda paralelizmu,
> prave naopak. U MDA mam taky nedobry pesimisticky pocit,
> ze ked tam ten optimizmus nevyjde, tak sa situacia zacne
> zhorsovat (pribuda smetie, vznikaju generacie zaznamov,
> strata vykonu pocitaca v dosledku nezbehnutia transakcie).
> A toho zhorsenie samotne moze sposobi dalsie zhorsenie
> (nezbehnutu transakciu treba opakovat, mozno zbehne,
> mozno zase nie, medzitym mozu byt spustene ine transakcie).
> A takto sa to kumulovat.
MGA Eriku - MGA.
Ted jsi na to kapl - je to jen o Tvem osobnim nazoru a Tvych pocitech. Jak
jiz psal P. Cisar - clovek, ktery vi, ze programuje nad MGA by mel zpusob
programovani prizpusobit prave teto okolnosti. Ja osobne s tim zadny vyrazny
problem nemam a to mi bezi v nekterych okamzicich i nekolik desitek
soucasnych transakci - ovsem jen jedna je R/W.
>
> > Takhle jednoduse to nikdy a nikde nefunguje. Nelze stavet primou
> > umeru mezi velikosti cache a ucinnosti cache, protoze:
> >
> > 1. Sprava cache ma vlastni rezii, ktera diky nutnosti implementace
> > careful write dle orientovanych grafu zavislosti v ramci cache u
> > kazdeho db enginu neni nijak mala, a s velikosti cache narusta.
> >
> > 2. Na ucinnost cache maji vliv dalsi faktory (access patterns,
> > mechanizmus rizeni obsahu atd.)
>
> uz si sa v praxi stretol s pripadom, ked po zvecseni RAMky
> doslo v dosledku zvysenej rezie spravy pamete k znizeniu vykonu
> pocitaca a bolo potrebne RAMku zmensit? Ja este nie.
> Pomer pristupovej doby disku a RAM-ky je asi milion, takze
> to by musela byt poriadne komplikovana a neefektivna
> sprava pameti aby sa nevyplatila. V praxi su skor ine problemy,
> ze ta RAMka nieco stoji.
Nejde o pristupove doby... Ale ja vim - Ty mas preci vzdy pravdu ne ???
Poskytnout Ti nejaky argument, ktery je zcela evidentni Ti opravdu nestaci a
je to jen jako hazet hrach na zed... :(((((((
S pozdravem
Milan Tomes
Firebird a GBAK na velkou GDB
[*] Winsoft <winsoft(zv)netkosice.sk> - 19.10.2004 02:06:39
> cte existujici data. Pochop prosim, ze kdyz znas MS SQL a/nebo Oracle, tak
> to neznamena, ze znas vse. Opravdu si nedokazu predstavit on-line
zalohovani
> na MS SQL.
tak som si pozrel manual MS SQL 2000, ked to tu uz riesime. On-line
zalohovanie tam ma fungovat. A aspon v kratkosti este zopar informacii:
1. je tam niekolko typov backupov (napr. Database, Database differential,
Transaction log, File or file differential) a tri recovery modely: Simple,
Full, Bulk-Logged.
Co sa tyka vplyvu transakcii na zalohovanie, tak citujem "Performing a
backup
operation has minimal effect on running transactions, so backup operations
can
be run during normal operations."
2. Co sa tyka restrikcii na backup, tak opet citujem (kompletne):
---------------------
Backup Restrictions
In Microsoft? SQL ServerT, backup operations can occur while the database is
online and in use. However, some operations are not allowed during a
database backup:
a.. Creating or deleting database files.
b.. The file truncation portion of a shrink operation on either the
database (automatically or manually) or the database files. They will fail
if a backup is running. You can perform the truncation after the backup
completes. For more information, see Shrinking a Database.
If a backup is started when one of these operations is in progress, the
backup waits for the operation to complete, up to the limit set by the
session timeout. If a backup is in progress and one of these operations is
attempted, the operation fails and the backup continues.
---------------------
3. A este zopar veci, ktore ma zaujali (je tam toho vela, presiel som to
len zbezne):
- Backup and Recovery of Related Databases (umoznuje urobit zalohu
dvoch alebo viacerych databaz, ktore musia byt logicky konzistentne)
- Partial Database Restore Operations (napr. ak aplikacia omylom
zrusila tabulku je mozne obnovit len tu cast databazy, ktora obsahovala
tabulku. Tiez sa to da pouzit na vytvorenie podmnoziny databazy
na inom serveri pre vyvojarske ucely alebo pre reporty)
- Restarting Interrupted Backup and Restore Operations (v pripade
ak backup alebo restore operacia je prerusena, napr. v dosledku
vypadku prudu, je mozne restartnut tu operaciu od bodu, v ktorom
doslo k peruseniu)
4. Dalej su tam rady ohladom Handling Large Mission-Critical
Environments, teda ako zvysit rychlost backup a restore operacii.
Erik
Textovy vystup
[*] mr.guest_delphi(zv)centrum(tec)cz - 18.10.2004 23:48:28
Jak tohle srovnat :
Korpus: Hloubka x Vyska Celo: Vyska x Sirka
Suplik 1.) 37 x 48 51,5 x 15,5
Suplik 2.) 37 x 568 72,5 x 15,5
Suplik 3.) 37 x 1038 72,5 x 15,5
Aby to vypadalo nejak takhle
Korpus: Hloubka x Vyska Celo: Vyska x Sirka
Suplik 1.) 37 x 48 51,5 x 15,5
Suplik 2.) 255 x 568 72,5 x 155,5
Suplik 3.) 37 x 1038 172,5 x 15,5
Kod :
WriteLn(vystup, 'Korpus: Hloubka x Vyska Celo: Vyska x Sirka');
Tempik := 0 ;
Celkem := 0 ;
while (Tempik < Length(PoleCel)) do
begin
Celkem := PoleCel[Tempik].bokVrtani ;
WriteLn(vystup, ' Suplik ' + IntToStr(Tempik+1) + '.) ' + FloatToStr(Hloubka) + ' x ' + FloatToStr(Celkem) + #9#9 + ' '
+ FloatToStr(PoleCel[Tempik].celoVVrtani) + ' x ' + FloatToStr(PoleCel[Tempik].celoSVrtani) + #9#9#9);
Inc(Tempik) ;
end;
Diky, snad je to jednoduse a primo receno.
Firebird a GBAK na velkou GDB
[*] Winsoft <winsoft(zv)netkosice.sk> - 18.10.2004 22:56:24
> Protoze puvodni hodnotu radku (tedy smeti, ale smeti se z toho stava
> teprve az po commitu) se *musi* generovat a uchovavat bez ohledu na
> zvolenou architekturu, to same co jsi napsal plati i pro system se
> zamky a transakcnim logem. Jedna transakce vygeneruje "smeti"
> zbytecne.
tak teda uvediem jednoduchy priklad, kedy sa nevyhoda MGA
z hladiska mozneho generovania zbytocneho smetia prejavi:
Uvazujme tabulku, v ktorej je zaznam s polozkou Erik a dve
transakcie, ktore tu polozku budu citat aj zapisovat. Transakcie
su uvedene vedla seba, ako bezia (T1 bola spustena trocha skor
ako T2):
1. Optimisticke zamykanie (MGA)
Transakcia1 Transakcia2
precita 'Erik' precita 'Erik'
nieco robi zapise 'Patrik' (ako novu generaciu)
nieco robi nieco robi
nemoze zapisat 'Fero' nieco robi
rollback commit
Teda Transakcia2 zbehla ale Transkacia1 nie. To znamena,
ze ak Transakcia1 vytvorila nejake nove generacie zaznamov
(v ramci tych operacii "nieco robi"), tak to bolo zbytocne a
tie zaznamy su nanic a teda vzniklo smetie. Cize Transakcia1
bezala a zatazovala system zbytocne a okrem mozneho smetia,
zatazenia systemu a sposobenia novej generacie zaznamu 'Patrik'
nic nevyriesila.
2. Pesimisticke zamykanie so zamkami
Transakcia1 Transakcia2
precita 'Erik' nemoze precitat (zamknute), tak caka
nieco robi caka
nieco robi caka
zapise 'Fero' caka
nieco robi caka
commit odomknute, precita 'Fero'
zapise 'Patrik'
nieco robi
nieco robi
commit
Zbehli obidve transakcie, jedna z nich ale cakala, kym sa uvolni zamok.
Ziadne smetie nevzniklo, v trans. logu su zmeny, ktore boli aj komitnute.
Aj v systeme so zamkami ale mozu vzniknut deadlocky a transakcia
vtedy nezbehne (napr. ked sa zamknuty zaznam zisti neskoro a dovtedy
samotna transakcia zamkla ine zaznamy).
> > V pripade pouzitia zamkov, ak transakcia narazi na zamknuty zaznam,
> > tak nepokracuje, ale caka na odomknutie. Cize pobezi len ta prva
> > transakcia, ta druha bude cakat a nebude zatazovat system (teda sice
> > tato transakcia stoji a caka, ale o to rychlejsie pobezi ta, co bezi).
>
> 1. Databaze maji typicky dva rezimy: cekani na uvolneni blokovaneho
> zdroje, a rezim kdy je chyba okamzite nahlasena. Ty popisujes pouze
> prvni pripad.
MS SQL caka na odomknutie, pricom je mozne definovat timeout.
Prednastavene je nekonecne cakanie. Samozrejme deadlocky
sa detekuju, po ich zisteni sa uz necaka ale jedna transakcia
sa zrusi (a druha moze pokracovat).
> > A po komitnuti prvej transakcie a uvolneni zamkov moze pokracuje
> > a komitnut aj druha transakcia.
>
> Si delas legraci ? Po komitnuti prvni transakce to muze akorat tak
> vyhucet na chybu, nijak by doslo k "lost update". Blokovana transakce
> muze ulozit sve zmeny *pouze* pokud blokujici transakce bude
> odvolana.
pozri ten moj priklad, tam to tak bezi
> > praveze MGA vyraba zbytocne zaznamy, lebo nepredchadza
> > konfliktom pesimisticky ale optimisticky
>
> 1. Optimisticke zamykani vede k nepomerne vyssi propustnosti
> soubzneho zpracovani nez pesimisticke, to je vedecky dokazany fakt.
zial, nie vzdy. V uvedenom priklade to tak nebolo.
> > ako to, ze nie su verzovane indexy? Ako sa potom hlada v roznych
generaciach
> > zaznamu? A kedy sa tie indexy potom vlastne aktualizuju? Toto mi
vysvetli,
> > nejako neviem najst uspokojive riesenie (co neznamena, ze neexistuje
;-) ).
>
> Kazdy radek ma konkretni, fixni pozici v databazi, kde zacina retez
> verzi (pokud jich je vice), pocinaje nejnovejsi verzi. Uzel indexu
> obsahuje hodnotu klice a odkaz na radek -> celo retezu. Index muze
> obsahovat vice uzlu s ruznymi klici odkazujicimi na stejny radek /
> retez. O relevanci radku rozhoduje hodnota radku pro dany transakcni
> kontext.
cize ak som to dobre pochopil, index obsahuje odkazy na rozne
generacie zaznamov a dodatocne je potrebne overit, ci ten zaznam
vybrany indexom je z tej mojej transakcie. Tu je potom este
otazka, ci sa nieco robi s indexom vtedy, ked transakcia zbehne,
resp. ked nezbehne. Teda ci sa ten index aktualizuje (napr. po
zbehnuti transakcie sa mozu IMHO v indexe zrusit odkazy
na stare generacie zaznamov, ktore boli transakciou prepisane).
alebo sa ponechava ako je a upratovanie indexov sa robi
dodatocne cez ten sweep (dufam, ze tak sa to v IB vola)
alebo priebeznym upratovanim.
> Tento system ma sice tu nevyhodu, ze pro nektere operace napr.
> zjisteni poctu radku v tabulce nelze pouzit *jen* index, ale na
> druhou stranu odpadaji jakekoliv hratky s indexem v pripade
> rollbacku, problemy synchronizace transakci na indexech apod. ktere
> postihuji systemy bez MGA.
takze pocas upratovania, ok
> Zkus se nad tim zamyslet jeste jednou. Zjistis, ze se realny vykon
> soubezneho zpracovani nezvysi, ale naopak snizi. Vzroste totiz vyskyt
> "falesnych" kolizi.
lenze falosna kolizia ak sa zamok zisti vcas, nema iny dopad
ako pozdrzanie transakcie. Cize nemusi to byt vzdy nevyhodne.
V MDA je paralelizmus vecsi, ale zas to nemusi byt vzdy vyhodne.
V priklade, co som uviedol, nebola ziadna vyhoda paralelizmu,
prave naopak. U MDA mam taky nedobry pesimisticky pocit,
ze ked tam ten optimizmus nevyjde, tak sa situacia zacne
zhorsovat (pribuda smetie, vznikaju generacie zaznamov,
strata vykonu pocitaca v dosledku nezbehnutia transakcie).
A toho zhorsenie samotne moze sposobi dalsie zhorsenie
(nezbehnutu transakciu treba opakovat, mozno zbehne,
mozno zase nie, medzitym mozu byt spustene ine transakcie).
A takto sa to kumulovat.
> Takhle jednoduse to nikdy a nikde nefunguje. Nelze stavet primou
> umeru mezi velikosti cache a ucinnosti cache, protoze:
>
> 1. Sprava cache ma vlastni rezii, ktera diky nutnosti implementace
> careful write dle orientovanych grafu zavislosti v ramci cache u
> kazdeho db enginu neni nijak mala, a s velikosti cache narusta.
>
> 2. Na ucinnost cache maji vliv dalsi faktory (access patterns,
> mechanizmus rizeni obsahu atd.)
uz si sa v praxi stretol s pripadom, ked po zvecseni RAMky
doslo v dosledku zvysenej rezie spravy pamete k znizeniu vykonu
pocitaca a bolo potrebne RAMku zmensit? Ja este nie.
Pomer pristupovej doby disku a RAM-ky je asi milion, takze
to by musela byt poriadne komplikovana a neefektivna
sprava pameti aby sa nevyplatila. V praxi su skor ine problemy,
ze ta RAMka nieco stoji.
Erik
prekreslovani bez processmessages
[*] Jiri Cincura <diskuze(zv)cincura(tec)net> - 18.10.2004 21:08:17
Jan Novak wrote:
>
> Ja bych treba hlavni smycku obsluhy fronty zprav resil tak, ze bych mel
> vytvorenych nekolik (3-10?) threadu a zpravu z cela fronty bych odevzdal
> prvnimu nebezicimu treadu. Mozna bych jeden z tech threadu mel
> rezervovany jen pro urcitou mnozinu zprav typu WM_QUIT atd.
Tak tohle bych chtel videt v akci.
> Jenze to by nejdriv cela VCL musela byt thread-safe. A nejen ta,
> kuprikladu databazovi klienti, atd..
Hmmm, zajimavy napad.
--
Jiri Cincura
e-mail: mailto:jiri(zv)cincura.net; mailto:xcincura(zv)informatics.muni(tec)cz
ICQ#: 314711544
web:
http://www.cincura.net/
http://photo.cincura.net/
http://phorum.cincura.net/
---
A i kdyz je nase doba obtizna a zmatena, je podnetna a vyplnena
prilezitostmi. And if our times are difficult and perplexing, so are they
challenging and filled with opportunity. -Robert F. Kennedy, 1961
prekreslovani bez processmessages
[*] Jan Novak <delfin4(zv)volny(tec)cz> - 18.10.2004 20:56:16
>> A to vsechno jen kvuli tomu, ze VCL ma nedoresene
> To vubec ne
Ja bych treba hlavni smycku obsluhy fronty zprav resil tak, ze bych
mel vytvorenych nekolik (3-10?) threadu a zpravu z cela fronty bych
odevzdal prvnimu nebezicimu treadu. Mozna bych jeden z tech threadu
mel rezervovany jen pro urcitou mnozinu zprav typu WM_QUIT atd.
Jenze to by nejdriv cela VCL musela byt thread-safe. A nejen ta,
kuprikladu databazovi klienti, atd..prekreslovani bez processmessages
[*] Jan Novak <delfin4(zv)volny(tec)cz> - 18.10.2004 20:34:14
> BTW ta metoda je Execute ;-)
no jo. Mesic jsem nesahnul na Delphi, delam ted zakazku na linuxu v C
s knihovnou Qt od Trolltechu a v QThread je to run(). I to 'begin' se
tam pise jako '{'...Firebird a GBAK na velkou GDB
[*] Slavomir Skopalik <skopalik(zv)elektlabs(tec)cz> - 18.10.2004 17:08:00
> systemu za plnej prevadzky? Aky je to podnik, ze sa tam
> pracuje aj v nedelu a cez sviatky s informacnym systemom?
Napriklad:
CZ Strakonice, a.s.
Kingspan, a.s.
TRZ - Valcovna Bohumin
Vsude je FB a full backup kazdych 8 hodin.
Provoz jede nepretrzite (az na vyjimky).
Pro zasadni zmeny se dohodne odstavka (v radu hodin).
Slavek
prekreslovani bez processmessages
[*] Petr Vones <konference(zv)petrvones(tec)net> - 18.10.2004 15:59:54
From: "Jan Novak" <delfin4(zv)volny(tec)cz>
> Delej, jak myslis. Ale pro mne je vyhodnejsi vlozit jedno volani
> ProcessMessages nez odvozovat novout tridu od TThread, definovat
> metodu Run a spekulovat, jak bych bezpecne pres Synchronize volal
> metody nekolika obrazovych objektu...
Neni treba spekulovat, to ma pomerne jasna pravidla.
> To se pak text programu rozroste tak, ze puvodni myslenka se v nem
> uplne ztrati. A to vsechno jen kvuli tomu, ze VCL ma nedoresene
To vubec ne, mozna v pripade ze je to spatne navrzene uz od zacatku.
> prekreslovani, ze ho dela v 'hlavnim' treadu.
Ne, to je proto, ze si opominul zakladni principy fungovani Win32. To neni
problem VCL.
Petr Vones
Firebird a GBAK na velkou GDB
[*] Milan Tomes <delphi(zv)haida(tec)cz> - 18.10.2004 15:59:54
Diky za informaci - neni nad to si rozsirit obzory... :)))
S pozdravem
Milan Tomes
> [mailto:delphi-l-owner(zv)clexpert(tec)cz]On Behalf Of Lstiburek Pavel
> Sent: Monday, October 18, 2004 3:32 PM
>
> Pri zalohovani MSSQL se zalohuji data pouze dokoncenych transakci,
> nedokoncene transakce (dle logu) nejsou do zalohy preneseny. Stejne se
> chova k transakcim zahajenym po okamziku zahajeni zalohy, at uz byly
> nebo nebyly dokonceny.
> DB lze obnovit k danemu okamziku (start BACKUP) s tim, ze vsechny
> "rozjete" transakce jsou ztraceny. Podrobneji viz popis v BOL.Firebird a GBAK na velkou GDB
[*] Winsoft <winsoft(zv)netkosice.sk> - 18.10.2004 16:17:56
> Podnikovy informacni system. Zalohovani bezi automaticky na serveru - a
bezi tak casto, jak
> zakaznik chce - tj. krome zalohovani o pulnoci (kteremu nevadi, kdyz nekdo
omylem aplikaci necha
> pustenou) muze bezet treba kazde dve hodiny i pres den, zatimco uzivatele
vesele pracuji.
a ako sa riesi zmena programu alebo databazy, ked dojde k zmene legislativy,
alebo zmene struktury alebo fungovania podniku, alebo chyby v programe?
To vsetko sa riesi za chodu systemu za plnej prevadzky? Aky je to podnik,
ze sa tam pracuje aj v nedelu a cez sviatky s informacnym systemom?
Erik
Firebird a GBAK na velkou GDB
[*] Pavel Cisar <pcb(zv)atlas(tec)cz> - 18.10.2004 15:55:54
Haj hou!
On 18 Oct 2004 at 15:35, Richard Kejval wrote:
> U MGA prirustkove zalohovani z principu neni mozne, proto u velkych
> databazi backup trva podstatne dele nez u databazi s lock&log
> architekturou a to je jedna z nevyhod MGA, ale myslim, ze ty vyhody,
> ktere tu zminil Pavel by to mely vyvazit
Implementovat prirustkove zalohovani nad MGA mozne samozrejme je, jen
ho nelze realizovat tak jednoduse jako on-line zalohovani, a na
logicke urovni kde pracuje gbak. Soucasti Firebirdu 2.0 by mel byt
novy nastroj nbackup, ktery provadi i viceurovnove prirustkove
zalohovani na fyzicke urovni databazovych stranek, podrobnosti na
http://firebird.sourceforge.net/index.php?op=devel&sub=engine&id=nback
up
pozor na zalomeni URL)
S pozdravem
Pavel Cisar (ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix(tec)cz
Vse co potrebujete pro Firebird a InterBase
Firebird a GBAK na velkou GDB
[*] Lstiburek Pavel <lstiburek(zv)ceb(tec)cz> - 18.10.2004 15:31:50
Pri zalohovani MSSQL se zalohuji data pouze dokoncenych transakci,
nedokoncene transakce (dle logu) nejsou do zalohy preneseny. Stejne se
chova k transakcim zahajenym po okamziku zahajeni zalohy, at uz byly
nebo nebyly dokonceny.
DB lze obnovit k danemu okamziku (start BACKUP) s tim, ze vsechny
"rozjete" transakce jsou ztraceny. Podrobneji viz popis v BOL.
Pavel
> From: Milan Tomes [mailto:delphi(zv)haida(tec)cz]
> > [mailto:delphi-l-owner(zv)clexpert(tec)cz]On Behalf Of Winsoft
> >
> > > A co treba takova zaloha velke databaze za provozu? U MGA
> zadny problem,
> > zatimco znamy se se
> > > zalohovanim dat z MS SQL dost potykal (ale MS SQL skoro
> neznam, takze
> > netvrdim, ze to nejak udelat
> > > nejde).
> >
> > U MGA ziadny problem? Ak pocas zalohovania pobezi ina
> transakcia, ktora
> > bude zapisovat, tak sa budu generovat nove zaznamy, co
> znamena naslednu
> > zvysenu reziu, co sa tyka dat aj indexov. Ak tam bude viac takych
> > transakcii,
> > tak sa to este viac skomplikuje. Zvysuje sa totiz riziko konfliktov
> > transkacii
> > lebo v dosledku zatazenia systemu zalohovanim je
> predpoklad, ze transakcie
> > budu trvat dlhsie.
>
> Proboha co je zase tohle za pip ???
> Pochopis uz konecne, ze se nic nekomplikuje ???
> Proste se nastartuje nativne podporovana transakce typu
> snapshot a uz se
> zalohuje.
>
> Vysvetli mi co je na tomhle tak sloziteho a jakou roli v tom
> hraje delka
> nejake transakce. V dobe zalohovani klidne muzou bezet dalsi
> transakce a
> nicemu to nevadi. Zalohovani totiz do databaze vubec nic
> nezapisuje ale jen
> cte existujici data. Pochop prosim, ze kdyz znas MS SQL
> a/nebo Oracle, tak
> to neznamena, ze znas vse. Opravdu si nedokazu predstavit
> on-line zalohovani
> na MS SQL.
>
prekreslovani bez processmessages
[*] Jiri Cincura <diskuze(zv)cincura(tec)net> - 18.10.2004 15:31:50
Jan Novak wrote:
> Jeste nikdy jsem s ProcessMessages nemel zadne problemy, jak tu nekteri o
> nich syckuji.
Jasne. Ja taky ne. Pouzivam to taky. Jinak by to tam asi ani nebylo. Ale je
nutne uvedomit si, na co si musim dat pri pouzivani pozor (stejne jako ne ke
vsemu musis z threadu pristupovat pres Synchronize, chce to jen myslet).
Ale pokud to na to jde, radsi jdu do threadu, pozdeji se to vyplati. Je
pravda, ze ze zacatku to chce laborovat, ale kdyz uz mas pekne promenne v
threadu, mas takovy lepsi (citelnejsi, efektivnejsi, ...) kod.
BTW ta metoda je Execute ;-)
--
Jiri Cincura
e-mail: mailto:jiri(zv)cincura.net; mailto:xcincura(zv)informatics.muni(tec)cz
ICQ#: 314711544
web:
http://www.cincura.net/
http://phorum.cincura.net/
http://photo.cincura.net/
---
Nekdo vidi veci, ktere existuji, a pta se - proc?. Ja snim o vecech, ktere
nikdy neexistovaly a ptam se - proc ne? (Robert Kennedy)
Firebird a GBAK na velkou GDB
[*] Richard Kejval <kejval.delphi(zv)centrum(tec)cz> - 18.10.2004 15:35:51
Winsoft wrote:
> neviem ako je to presne u MS SQL, nerobim 24x7 systemy, ze by som mal s
tym
> nejake problemy. O aku konkretne aplikaciu vlastne islo, ze to bolo
> kriticke?
> Viem akurat tolko, ze v MS SQL je (aj) moznost inkrementalnych backupov.
U MGA prirustkove zalohovani z principu neni mozne, proto u velkych databazi
backup trva podstatne dele nez u databazi s lock&log architekturou a to je
jedna
z nevyhod MGA, ale myslim, ze ty vyhody, ktere tu zminil Pavel by to mely
vyvazit
S pozdravem
ing. Richard Kejval
mobil: 602477679
http://www.icsoftware(tec)cz
Firebird a GBAK na velkou GDB
[*] Karel Rys <delphi(zv)zas-me(tec)cz> - 18.10.2004 15:37:53
Winsoft dne 18 Oct 2004 v 15:03:
> > A co treba takova zaloha velke databaze za provozu? U MGA zadny
> > problem,
> zatimco znamy se se
> > zalohovanim dat z MS SQL dost potykal (ale MS SQL skoro neznam,
> > takze
> netvrdim, ze to nejak udelat
> > nejde).
>
> neviem ako je to presne u MS SQL, nerobim 24x7 systemy, ze by som mal
> s tym nejake problemy. O aku konkretne aplikaciu vlastne islo, ze to
> bolo kriticke? Viem akurat tolko, ze v MS SQL je (aj) moznost
> inkrementalnych backupov.
Podnikovy informacni system. Zalohovani bezi automaticky na serveru - a bezi tak casto, jak
zakaznik chce - tj. krome zalohovani o pulnoci (kteremu nevadi, kdyz nekdo omylem aplikaci necha
pustenou) muze bezet treba kazde dve hodiny i pres den, zatimco uzivatele vesele pracuji.
> U MGA ziadny problem? Ak pocas zalohovania pobezi ina transakcia,
> ktora bude zapisovat, tak sa budu generovat nove zaznamy, co znamena
> naslednu zvysenu reziu, co sa tyka dat aj indexov. Ak tam bude viac
> takych transakcii, tak sa to este viac skomplikuje. Zvysuje sa totiz
> riziko konfliktov transkacii lebo v dosledku zatazenia systemu
> zalohovanim je predpoklad, ze transakcie budu trvat dlhsie.
Zalohovani bezi podobne jako jiny SQL dotaz, takze jestli ma server momentalne obslouzit 20
uzivatelu, nebo 20 uzivatelu plus zalohovani, uz nebude velky rozdil.
Je samozrejme pravda, ze kdyz nekdo v tu chvili zapisuje, vznikne nova verze zaznamu, protoze tu
starou musi server kvuli snapshotu uchovat. Vzhledem k celkovemu objemu databaze je to ale v
podstate zanedbatelne a nejblizsi garbage collection nebo sweep to odstrani. Velmi podstatne ale
je, ze se udela zaloha, aniz by nekdo musel pobihat po firme a vyhanet lidi z aplikace.
Karel Rys
TADODataSet
[*] Lstiburek Pavel <lstiburek(zv)ceb(tec)cz> - 18.10.2004 15:25:47
Ahoj,
TADOCustomDataSet ma moznost ulozeni do a nacteni z XML souboru, totez je i u komponent ADONIS.
Me by se ale docela hodilo ulozit / nacist dataset do/z XML stringu.
Potreboval bych ho predavat jine aplikaci a vytvareni docasnych souboru se mi nezda prilis efektivni,
nehral jste si s tim nekdo ?
U TADO se mi zda, ze je to zahrabano dost hluboko a od ADONISe nemam ani zdroje. Nebo se mylim ?
Muzete me nekdo trochu postrcit !
Pavel
prekreslovani bez processmessages
[*] Jan Novak <delfin4(zv)volny(tec)cz> - 18.10.2004 15:21:46
>> Ale preneseni cinnosti do
>> zvlast threadu casto zpusobi daleko vetsi problemy, zejmena kvuli
>> synchronizaci se muze program zakomplikovat na neunosnou miru.
> Proc ??? Kvuli trivialni synchronizaci si pridelas starosti s
> ProcessMessages a budes radeji rozdelovat deletrvajici operaci na
> kousky, aby to nezatuhavalo?
Delej, jak myslis. Ale pro mne je vyhodnejsi vlozit jedno volani
ProcessMessages nez odvozovat novout tridu od TThread, definovat
metodu Run a spekulovat, jak bych bezpecne pres Synchronize volal
metody nekolika obrazovych objektu...
To se pak text programu rozroste tak, ze puvodni myslenka se v nem
uplne ztrati. A to vsechno jen kvuli tomu, ze VCL ma nedoresene
prekreslovani, ze ho dela v 'hlavnim' treadu.
Jeste nikdy jsem s ProcessMessages nemel zadne problemy, jak tu
nekteri o nich syckuji.Firebird a GBAK na velkou GDB
[*] Milan Tomes <delphi(zv)haida(tec)cz> - 18.10.2004 15:11:45
> [mailto:delphi-l-owner(zv)clexpert(tec)cz]On Behalf Of Winsoft
> Sent: Monday, October 18, 2004 3:04 PM
>
> > A co treba takova zaloha velke databaze za provozu? U MGA zadny problem,
> zatimco znamy se se
> > zalohovanim dat z MS SQL dost potykal (ale MS SQL skoro neznam, takze
> netvrdim, ze to nejak udelat
> > nejde).
>
> U MGA ziadny problem? Ak pocas zalohovania pobezi ina transakcia, ktora
> bude zapisovat, tak sa budu generovat nove zaznamy, co znamena naslednu
> zvysenu reziu, co sa tyka dat aj indexov. Ak tam bude viac takych
> transakcii,
> tak sa to este viac skomplikuje. Zvysuje sa totiz riziko konfliktov
> transkacii
> lebo v dosledku zatazenia systemu zalohovanim je predpoklad, ze transakcie
> budu trvat dlhsie.
Proboha co je zase tohle za pip ???
Pochopis uz konecne, ze se nic nekomplikuje ???
Proste se nastartuje nativne podporovana transakce typu snapshot a uz se
zalohuje.
Vysvetli mi co je na tomhle tak sloziteho a jakou roli v tom hraje delka
nejake transakce. V dobe zalohovani klidne muzou bezet dalsi transakce a
nicemu to nevadi. Zalohovani totiz do databaze vubec nic nezapisuje ale jen
cte existujici data. Pochop prosim, ze kdyz znas MS SQL a/nebo Oracle, tak
to neznamena, ze znas vse. Opravdu si nedokazu predstavit on-line zalohovani
na MS SQL.
S pozdravem
Milan Tomes
Firebird a GBAK na velkou GDB
[*] Winsoft <winsoft(zv)netkosice.sk> - 18.10.2004 15:03:44
> A co treba takova zaloha velke databaze za provozu? U MGA zadny problem,
zatimco znamy se se
> zalohovanim dat z MS SQL dost potykal (ale MS SQL skoro neznam, takze
netvrdim, ze to nejak udelat
> nejde).
neviem ako je to presne u MS SQL, nerobim 24x7 systemy, ze by som mal s tym
nejake problemy. O aku konkretne aplikaciu vlastne islo, ze to bolo
kriticke?
Viem akurat tolko, ze v MS SQL je (aj) moznost inkrementalnych backupov.
U MGA ziadny problem? Ak pocas zalohovania pobezi ina transakcia, ktora
bude zapisovat, tak sa budu generovat nove zaznamy, co znamena naslednu
zvysenu reziu, co sa tyka dat aj indexov. Ak tam bude viac takych
transakcii,
tak sa to este viac skomplikuje. Zvysuje sa totiz riziko konfliktov
transkacii
lebo v dosledku zatazenia systemu zalohovanim je predpoklad, ze transakcie
budu trvat dlhsie.
Erik
Firebird a GBAK na velkou GDB
[*] Richard Kejval <kejval.delphi(zv)centrum(tec)cz> - 18.10.2004 13:47:39
Ahoj do konference,
Winsoft wrote:
> tak si kup disky bez cache, ked ich cache spomaluje. Vypni si
> procesorovu cache, ked spomaluje. A zmensi si RAMku,
> ked spomaluje Tvoj pocitac. Len na tom usetris. Ak si este
> nezapisoval ten 1GB bez cache a s cache, tak si to
> radsej najprv vyskusaj.
Myslim, ze uz to pomalu ztraci "sportovni uroven".. Kdo
nema klapky na ocich, tak uz si nazor o MGA udelal a
ja musim jen Erikovi podekovat, ze vyprovokoval Pavla
k celkem podrobnemu popisu problemu. Takze jestli slo
jen o to, tak 3x bravo Eriku !!! :-)
S pozdravem
ing. Richard Kejval
mobil: 602477679
http://www.icsoftware(tec)cz
Firebird a GBAK na velkou GDB
[*] Pavel Cisar <pcb(zv)atlas(tec)cz> - 18.10.2004 13:35:38
Haj hou!
On 18 Oct 2004 at 12:19, Winsoft wrote:
> nerobim novu generaciu zaznamu v situacii, ked ma zamky upozornia, ze
> zaznam je pouzity (hoci aj na citanie) v inej transakcii. V tomto
> pripade predidem vytvaraniu mozneho smetia. U MGA sa transakcia zastavi
> az ked vznikne konflikt.
1. Nova verze vznika jen pri zapisu, nikoliv pri cteni. Pokud jiz
existuje nova nepotvrzena verze, pak se samozrejme zadna dalsi verze
nevytvari, protoze je jasne ze nemuzu prepsat nepotvrzenou zmenu svou
vlastni. Je to stejne, jako by byl na radku zamek. V danem okamziku
muze existovat pouze jedina nepotvrzena verze radku.
2. Pokud radek ctu, pak samozrejme nebranim jinym ho zmenit. U
systemu se zamky k tomu pri cteni dochazi jen u izolace Repeatable
Read a vyssi. System se zamky ma v takovem pripade vyhodu, ze je
garantovano, ze nacteny radek bude mozne rovnez zmenit. To MGA
implicitne negarantuje, pokud neni vyzadan explicitni pesimisticky
zamek. Na druhou stranu system se zamky nedava na vyber, a prectena
data jsou "chranena" proti zapisu, at uz o to stojim nebo ne. U MGA
si muzu presne vybrat, a dostanu co chci.
S pozdravem
Pavel Cisar (ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix(tec)cz
Vse co potrebujete pro Firebird a InterBase
Firebird a GBAK na velkou GDB
[*] Milan Tomes <delphi(zv)haida(tec)cz> - 18.10.2004 13:03:36
> [mailto:delphi-l-owner(zv)clexpert(tec)cz]On Behalf Of Winsoft
> Sent: Monday, October 18, 2004 12:20 PM
>
> > A v pripade pouziti napr. MSSQL, ktery pouziva zamky uz dopredu vis, ze
> > vsechny transakce budou commitnuty. Tak to me tedy opravdu rozesmalo.
>
> ale preco mi podsuvas veci, ktore som nepovedal? Dokonca som jasne
> povedal (hned v nasledujucom odstavci) ze ani kommit ani deadlock
> sa neda vylucit ani v pripade zamkov, ale je tam vecsia pravdepodobnost,
> ze k tomu nedojde, pretoze zamky tomu mozu zabranit. Myslim si,
> ze som to velmi jasne napisal ako je to so zamkami a kto chcel tak ten
> rozdiel IMHO pochopil. No smejes sa potom naozaj neviem na com.
Smeji se tomu jak to vyznelo a to byl opravdu blud. Omlouvam se, ze jsem
okamzite nepochopil velikost Tveho mysleni, ale uz jsem takovy a Ty me
urcite nezmenis... :)
>
> > > V pripade pouzitia zamkov, ak transakcia narazi na zamknuty zaznam,
> > > tak nepokracuje, ale caka na odomknutie. Cize pobezi len ta prva
> > > transakcia, ta druha bude cakat a nebude zatazovat system (teda sice
> > > tato transakcia stoji a caka, ale o to rychlejsie pobezi ta, co bezi).
> >
> > V pripade MGA pokud transakce narazi na zaznam, ktery byl zmenen jinou
> > transakci tak je preci situace naprosto stejna - je ohlasena chyba a
> > transakce nemuze dobehnout, takze o co Ti jde ??? Evidentne jsi nikdy s
> MGA
> > architekturou nepracoval.
>
> to ma byt snad opet zase provokacia? Zamok existuje aj na citanie, nielen
> pri kolizii zapisu. Evidentne si so zamkovou architekturou nepracoval.
Vysvetli mi, prosim, co je na tomto textu za provokaci.
>
> > > A dalsie vyhody: nemam ziadne smetie, system sa zatazoval len
> > > vtedy ked to bolo potrebne.
> >
> > Nemas zadne smeti ??? A co to, ktere je v transakcnim logu ??? To neni
> > smeti, ktere je naprosto nepotrebne ???
>
> nerobim novu generaciu zaznamu v situacii, ked ma zamky upozornia,
> ze zaznam je pouzity (hoci aj na citanie) v inej transakcii. V tomto
> pripade predidem vytvaraniu mozneho smetia. U MGA sa transakcia
> zastavi az ked vznikne konflikt.
Ach jo... Jak to, ze nedelas smeti v transakcnim logu, kdyz sen teprve
uprostred transakce narazi na zamknuty zaznam ??? To je preci nesmysl. Krom
jineho nechapu, proc bych nemohl cist zaznam, ktery *pouze* cetla jina
transakce.
> > > ako to, ze nie su verzovane indexy? Ako sa potom hlada v roznych
> > > generaciach
> > > zaznamu? A kedy sa tie indexy potom vlastne aktualizuju? Toto mi
> vysvetli,
> > > nejako neviem najst uspokojive riesenie (co neznamena, ze
> > > neexistuje ;-) ).
> >
> > Me ano - indexy se aktualizuji pri commitnuti transakce. Pokud
> byl nejaky
> > zaznam odebran ci pridan, je zarazen na prislusne misto indexu - ostatni
> > transakce tuto zmenu jiz mohou videt a jiz bezici ho neuvidi prave diky
> > verzim radku.
>
> stale tomu nerozumiem , preto uvediem priklad:
>
> Mam zaznam s menom na ktorom je index. Nech prvy zaznam
> obsahuje meno Erik a pouziva ho prva transakcia. Nech druha
> transakcia chce zmenit jeho obsah, tak vyrobi novu generaciu
> tohto zaznamu s menom Patrik. A teraz sa pytam ako je to s
> indexom? Prva transakcia potrebuje index na zaznam Erik
> druha zas index na zaznam Patrik, tak ako dostane prva
> transkacia ten index na Erik a druha na Patrik? Je to jasne
> ale mam este nejako dovysvetlovat tento jednoduchy priklad?
No a ja Ti na to odpovim uplne stejne - transakce vidi takova data, ktera
byla videt pri jejim zahajeni. Je opravdu tak veliky problem pochopit tak
primitivni odpoved ???
>
> > > tak mozme uz teda porovnat vykon IB a MS SQL? ;-)
> >
> > Ze by to byla pointa ??? Jde Ti o vykonovy test abys mohl rici MS SQL je
> > proste rychlejsi ??? Gratuluju... :)))
>
> moje pointa spociva len v tom, nazorne vyskusat, ci sa a ako
> tie vselijake teoreticke vyhody prejavia prakticky. Lebo ja neviem
> na svojom pocitaci pouzit architekturu ako taku, nakreslenu
> niekde na papieri ale len jej konkretnu implementaciu.
Zkus se podivat na ten smajlik na konci vety...
>
> > > ked nezvysim RAM (aj fyzicky, ked treba), tak sa udaje z databazy
> > > nezmestia do cache a teda je prepoklad, ze praca s nou bude pomalsia.
> > > Cize mozem si vybrat - pomalsia praca alebo vecsia cache. Takze
> > > podla mna velkost databazy ma zjavny vplyv na spotrebu pamete.
> >
> > Jeste, ze jsi pripsal, ze podle Tebe. Pokud bych se drzel Tveho tvrzeni,
> tak
> > by soucasne pevne disky meli mit cache nekolik GB a procesory take...
> Prosim
> > podivej se na to co jsi napsal a zamysli se nad tim. Vzdyt to
> preci vubec
> > nemusi byt pravda. Pokud budu mit jakoukoliv databazi - i kdyz to
> samozrejme
> > plati analogicky pro soubor - muze me cache dokonce zpomalovat.
> Vzdycky je
> > nutne dodat: "zalezi na konkretnim pouziti". Pokud budu porad jen
> zapisovat
> > nova data, tak preci nepotrebuji 1GB cache ne ???
>
> tak si kup disky bez cache, ked ich cache spomaluje. Vypni si
> procesorovu cache, ked spomaluje. A zmensi si RAMku,
> ked spomaluje Tvoj pocitac. Len na tom usetris. Ak si este
> nezapisoval ten 1GB bez cache a s cache, tak si to
> radsej najprv vyskusaj.
Vis co - zacni s temi citacemi u sebe. Ja jsem reagoval jen a jen na blabol
typu: "Cim vetsi databaze, tim vic cache je potreba". To je naprosty
nesmysl. Je samozrejme, ze cache na disku i procesoru je velkym zrychlenim,
ale v nekterych pripadech je samozrejme i zpomalenim. Zkus se nad tim trosku
vice do hloubky zamyslet a urcite prijdes na to proc.
S pozdravem
Milan Tomes
Firebird a GBAK na velkou GDB
[*] Winsoft <winsoft(zv)netkosice.sk> - 18.10.2004 12:19:32
> A v pripade pouziti napr. MSSQL, ktery pouziva zamky uz dopredu vis, ze
> vsechny transakce budou commitnuty. Tak to me tedy opravdu rozesmalo.
ale preco mi podsuvas veci, ktore som nepovedal? Dokonca som jasne
povedal (hned v nasledujucom odstavci) ze ani kommit ani deadlock
sa neda vylucit ani v pripade zamkov, ale je tam vecsia pravdepodobnost,
ze k tomu nedojde, pretoze zamky tomu mozu zabranit. Myslim si,
ze som to velmi jasne napisal ako je to so zamkami a kto chcel tak ten
rozdiel IMHO pochopil. No smejes sa potom naozaj neviem na com.
> > V pripade pouzitia zamkov, ak transakcia narazi na zamknuty zaznam,
> > tak nepokracuje, ale caka na odomknutie. Cize pobezi len ta prva
> > transakcia, ta druha bude cakat a nebude zatazovat system (teda sice
> > tato transakcia stoji a caka, ale o to rychlejsie pobezi ta, co bezi).
>
> V pripade MGA pokud transakce narazi na zaznam, ktery byl zmenen jinou
> transakci tak je preci situace naprosto stejna - je ohlasena chyba a
> transakce nemuze dobehnout, takze o co Ti jde ??? Evidentne jsi nikdy s
MGA
> architekturou nepracoval.
to ma byt snad opet zase provokacia? Zamok existuje aj na citanie, nielen
pri kolizii zapisu. Evidentne si so zamkovou architekturou nepracoval.
> > A dalsie vyhody: nemam ziadne smetie, system sa zatazoval len
> > vtedy ked to bolo potrebne.
>
> Nemas zadne smeti ??? A co to, ktere je v transakcnim logu ??? To neni
> smeti, ktere je naprosto nepotrebne ???
nerobim novu generaciu zaznamu v situacii, ked ma zamky upozornia,
ze zaznam je pouzity (hoci aj na citanie) v inej transakcii. V tomto
pripade predidem vytvaraniu mozneho smetia. U MGA sa transakcia
zastavi az ked vznikne konflikt.
> Evidentne jsi nikdy v zivote architekturu MGA nepouzil. Ale treba jsi
takovy
> genius, ze dokazes naprosto dokonale predvidat vsechny stavy Tveho
programu,
> takze nejaky deadlock Ti proste nehrozi :)
naozaj vtipne, hlavne ked som to netvrdil. Skus hovorit viac za seba
a menej za mna. A ked uz hovoris za mna, tak pouzi citaciu z mojho
textu a nie vlastne zmyslaniny. Predideme tak zbytocnym konfliktom.
> > ako to, ze nie su verzovane indexy? Ako sa potom hlada v roznych
> > generaciach
> > zaznamu? A kedy sa tie indexy potom vlastne aktualizuju? Toto mi
vysvetli,
> > nejako neviem najst uspokojive riesenie (co neznamena, ze
> > neexistuje ;-) ).
>
> Me ano - indexy se aktualizuji pri commitnuti transakce. Pokud byl nejaky
> zaznam odebran ci pridan, je zarazen na prislusne misto indexu - ostatni
> transakce tuto zmenu jiz mohou videt a jiz bezici ho neuvidi prave diky
> verzim radku.
stale tomu nerozumiem , preto uvediem priklad:
Mam zaznam s menom na ktorom je index. Nech prvy zaznam
obsahuje meno Erik a pouziva ho prva transakcia. Nech druha
transakcia chce zmenit jeho obsah, tak vyrobi novu generaciu
tohto zaznamu s menom Patrik. A teraz sa pytam ako je to s
indexom? Prva transakcia potrebuje index na zaznam Erik
druha zas index na zaznam Patrik, tak ako dostane prva
transkacia ten index na Erik a druha na Patrik? Je to jasne
ale mam este nejako dovysvetlovat tento jednoduchy priklad?
> > tak mozme uz teda porovnat vykon IB a MS SQL? ;-)
>
> Ze by to byla pointa ??? Jde Ti o vykonovy test abys mohl rici MS SQL je
> proste rychlejsi ??? Gratuluju... :)))
moje pointa spociva len v tom, nazorne vyskusat, ci sa a ako
tie vselijake teoreticke vyhody prejavia prakticky. Lebo ja neviem
na svojom pocitaci pouzit architekturu ako taku, nakreslenu
niekde na papieri ale len jej konkretnu implementaciu.
> > ked nezvysim RAM (aj fyzicky, ked treba), tak sa udaje z databazy
> > nezmestia do cache a teda je prepoklad, ze praca s nou bude pomalsia.
> > Cize mozem si vybrat - pomalsia praca alebo vecsia cache. Takze
> > podla mna velkost databazy ma zjavny vplyv na spotrebu pamete.
>
> Jeste, ze jsi pripsal, ze podle Tebe. Pokud bych se drzel Tveho tvrzeni,
tak
> by soucasne pevne disky meli mit cache nekolik GB a procesory take...
Prosim
> podivej se na to co jsi napsal a zamysli se nad tim. Vzdyt to preci vubec
> nemusi byt pravda. Pokud budu mit jakoukoliv databazi - i kdyz to
samozrejme
> plati analogicky pro soubor - muze me cache dokonce zpomalovat. Vzdycky je
> nutne dodat: "zalezi na konkretnim pouziti". Pokud budu porad jen
zapisovat
> nova data, tak preci nepotrebuji 1GB cache ne ???
tak si kup disky bez cache, ked ich cache spomaluje. Vypni si
procesorovu cache, ked spomaluje. A zmensi si RAMku,
ked spomaluje Tvoj pocitac. Len na tom usetris. Ak si este
nezapisoval ten 1GB bez cache a s cache, tak si to
radsej najprv vyskusaj.
Erik
jmeno exe souboru
[*] mstevlik(zv)gamo.sk - 18.10.2004 12:33:34
> K cemu je to dobre? K tomu abych na to nezapomel a do instalatoru nedal
jiny
> program.
> Jde o to ze pri prekladu vznikaji dva odlisne soubory podle konfigurace
> stroje pro ktery je urcen.
> Takze proc mam jeste upravovat vysledny soubor kdyz uz upravim nejaky
> konfiguracni soubor pred prekladem?
Ja to robim tak, ze mam N dpr suborov, pricom kazdy znich ma vlastny nazov
a vsetky pouzivaju tie iste zdrojaky
A potom si skompilujem do dpr kt. prave chcem (mam moznost mat pri nom inu
verziu ako pri inych dpr. co je podla mna podstatne)
Stevlik Marian
ISYS programator
GAMO a.s.
Kyjevske nam. 6
974 04 Banska Bystrica
mail: mstevlik(zv)gamo.sk
tel: +421 48 4137935, 4372111
ip-tel: 421 48 4372098
mobil: +421 905 462010
icq: 38493645
delphi-l-owner(zv)clexpert(tec)cz wrote on 18.10.2004 12:17:32:Firebird a GBAK na velkou GDB
[*] Pavel Cisar <pcb(zv)atlas(tec)cz> - 18.10.2004 11:59:30
Haj hou!
On 17 Oct 2004 at 23:52, Winsoft wrote:
> > > namiesto generovania smetia sa pocka na odomknutie zaznamu
> >
> > ??? Co tim mas na mysli ? "Smeti" je puvodni hodnota radku. Tu musis
> > vzdy uchovat, bez ohledu na architekturu kterou zvolis.
>
> V MDA kedze zaznamy sa nezamykaju, transakcie vytvaraju nove
> generacie zaznamov aj ked nie je (a nemoze byt) vopred zname
> ci budu komitnute. Takze spustim 2 dlhe transakcie, obidva bezia
> a vyrabaju nove gereracie a zatazuju system. A teraz dojde ku kolizii
> medzi nimi a na jednu (alebo obidve) sa musi pouzit rollback. Jedna
> z nich teda zbytocne zatazovala system a vyrobila zbytocne smetie.
Protoze puvodni hodnotu radku (tedy smeti, ale smeti se z toho stava
teprve az po commitu) se *musi* generovat a uchovavat bez ohledu na
zvolenou architekturu, to same co jsi napsal plati i pro system se
zamky a transakcnim logem. Jedna transakce vygeneruje "smeti"
zbytecne.
Je tu ovsem jeden podstatny rozdil. Zatimco system se zamky musi pri
rollbacku pracne rekonstruovat puvodni stav databaze, u systemu s MGA
se jednoduse zaznamena novy stav transakce - rollback, a je hotovo. V
pripade Firebirdu jde o zmenu dvou bitu v bitove mape stavu
transakci.
> V pripade pouzitia zamkov, ak transakcia narazi na zamknuty zaznam,
> tak nepokracuje, ale caka na odomknutie. Cize pobezi len ta prva
> transakcia, ta druha bude cakat a nebude zatazovat system (teda sice
> tato transakcia stoji a caka, ale o to rychlejsie pobezi ta, co bezi).
1. Databaze maji typicky dva rezimy: cekani na uvolneni blokovaneho
zdroje, a rezim kdy je chyba okamzite nahlasena. Ty popisujes pouze
prvni pripad.
2. Chovani systemu s MGA a bez MGA je naprosto stejne. Pokud
transakce narazi na zmenu z jine transakce, muze cekat, nebo muze
ihned nahlasit chybu. Toto chovani proste neni zadne specifikum
systemu se zamky. Jeste jednou: system s MGA nema specialni datovou
strukturu a obsluzny mechanizmus pro zamek na radek, protoze
naprosto stejne funkcionality dosahne i bez teto struktury a
obsluzneho kodu. Existence novejsi verze radku funguje naprosto
stejne, jako kdyby byl na radek uvalen zamek.
> A po komitnuti prvej transakcie a uvolneni zamkov moze pokracuje
> a komitnut aj druha transakcia.
Si delas legraci ? Po komitnuti prvni transakce to muze akorat tak
vyhucet na chybu, nijak by doslo k "lost update". Blokovana transakce
muze ulozit sve zmeny *pouze* pokud blokujici transakce bude
odvolana.
> > > ako optimalizuje MDA, ked treba vytvarat novu generaciu velkeho
> > > mnozstva zaznamov v transakcii, ake tam su moznosti? Alebo
> > > ked sa zmaze vela zaznamov?
> >
> > Co konkretne by jsi chtel optimalizovat ? Je urcite mnozstvi prace,
> > ktere je vzdy zapotrebi udelat. MGA nikdy nedela vic nez je nezbytne
> > nutne.
>
> praveze MGA vyraba zbytocne zaznamy, lebo nepredchadza
> konfliktom pesimisticky ale optimisticky
1. Optimisticke zamykani vede k nepomerne vyssi propustnosti
soubzneho zpracovani nez pesimisticke, to je vedecky dokazany fakt.
2. Kazdy system se zamky se snazi co nejblize priblizit
optimistickemu zamykani, proto pouziva mnoho ruznych typu zamku.
3. I system s MGA umoznuje pesimisticke zamykani, pokud si ho vyvojar
aplikace explicitne vyzada.
> > > a co tych x indexov navesenych na ten zaznam, tie netreba spravovat
> > > extra pre kazdu generaciu zaznamu?
> >
> > Ne, indexy verzovane nejsou, pouze radky.
>
> ako to, ze nie su verzovane indexy? Ako sa potom hlada v roznych generaciach
> zaznamu? A kedy sa tie indexy potom vlastne aktualizuju? Toto mi vysvetli,
> nejako neviem najst uspokojive riesenie (co neznamena, ze neexistuje ;-) ).
Kazdy radek ma konkretni, fixni pozici v databazi, kde zacina retez
verzi (pokud jich je vice), pocinaje nejnovejsi verzi. Uzel indexu
obsahuje hodnotu klice a odkaz na radek -> celo retezu. Index muze
obsahovat vice uzlu s ruznymi klici odkazujicimi na stejny radek /
retez. O relevanci radku rozhoduje hodnota radku pro dany transakcni
kontext.
Tento system ma sice tu nevyhodu, ze pro nektere operace napr.
zjisteni poctu radku v tabulce nelze pouzit *jen* index, ale na
druhou stranu odpadaji jakekoliv hratky s indexem v pripade
rollbacku, problemy synchronizace transakci na indexech apod. ktere
postihuji systemy bez MGA.
> > > mozno tie rozne typy zamkov su tam prave preto aby sa dal
> > > redukovat pocet zamkov a ta sprava bola rychlejsia
> >
> > Samozrejmne, protoze bez toho by to lehlo velmi rychle. Nicmene je to
> > vyhaneni certa dablem (viz nasledky lock promotion)
>
> IMHO to je elegantne riesenie problemu. Optimalizuje
> sa s urcitym prijatelnym rizikom. A tak to uz byva, aj do
> cache sa niekedy nacitaju nepotrebne udaje aj predpoved
> vetvevenia skoku v procesore sa obcas netrafi. No a co?
> Dolezite je, ze vecsinou to funguje a celkovo sa teda
> vykonnost zvysi.
Zkus se nad tim zamyslet jeste jednou. Zjistis, ze se realny vykon
soubezneho zpracovani nezvysi, ale naopak snizi. Vzroste totiz vyskyt
"falesnych" kolizi.
> ked nezvysim RAM (aj fyzicky, ked treba), tak sa udaje z databazy
> nezmestia do cache a teda je prepoklad, ze praca s nou bude pomalsia.
> Cize mozem si vybrat - pomalsia praca alebo vecsia cache. Takze
> podla mna velkost databazy ma zjavny vplyv na spotrebu pamete.
Takhle jednoduse to nikdy a nikde nefunguje. Nelze stavet primou
umeru mezi velikosti cache a ucinnosti cache, protoze:
1. Sprava cache ma vlastni rezii, ktera diky nutnosti implementace
careful write dle orientovanych grafu zavislosti v ramci cache u
kazdeho db enginu neni nijak mala, a s velikosti cache narusta.
2. Na ucinnost cache maji vliv dalsi faktory (access patterns,
mechanizmus rizeni obsahu atd.)
S pozdravem
Pavel Cisar (ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix(tec)cz
Vse co potrebujete pro Firebird a InterBase
jmeno exe souboru
[*] Petr Vones <konference(zv)petrvones(tec)net> - 18.10.2004 11:59:30
From: "Petr Fiser" <petr.fiser(zv)3jservis(tec)cz>
> Lze nejakym jednoduchym zpusobem rict prekladaci jmeno vysledneho exe
> souboru napr.:
Ne.
Petr Vones
jmeno exe souboru
[*] Petr Fiser <petr.fiser(zv)3jservis(tec)cz> - 18.10.2004 12:17:32
K cemu je to dobre? K tomu abych na to nezapomel a do instalatoru nedal jiny
program.
Jde o to ze pri prekladu vznikaji dva odlisne soubory podle konfigurace
stroje pro ktery je urcen.
Takze proc mam jeste upravovat vysledny soubor kdyz uz upravim nejaky
konfiguracni soubor pred prekladem?
Je to jen pro poradek abych v tom neudelal bordel.
> Petr Fiser wrote:
> > Dobry den.
> >
> > Lze nejakym jednoduchym zpusobem rict prekladaci jmeno vysledneho exe
> > souboru napr.:
> >
> > {$IFDEF neco}
> > exename := xxx;
> > {$IFDEF necojineho}
> > exename := yyy;
>
> Jako ze mas Project1.dpr a chces mit misto Project1.exe muj_program.exe?
>
> A k cemu je to jako dobre. Vzdy to muzes prejmenovat po kompilaci ne?
>
> -- jmeno exe souboru
[*] Jiri Cincura <diskuze(zv)cincura(tec)net> - 18.10.2004 11:53:30
Petr Fiser wrote:
> Dobry den.
>
> Lze nejakym jednoduchym zpusobem rict prekladaci jmeno vysledneho exe
> souboru napr.:
>
> {$IFDEF neco}
> exename := xxx;
> {$IFDEF necojineho}
> exename := yyy;
Jako ze mas Project1.dpr a chces mit misto Project1.exe muj_program.exe?
A k cemu je to jako dobre. Vzdy to muzes prejmenovat po kompilaci ne?
--
Jiri Cincura
e-mail: mailto:jiri(zv)cincura.net; mailto:xcincura(zv)informatics.muni(tec)cz
ICQ#: 314711544
web:
http://www.cincura.net/
http://phorum.cincura.net/
http://photo.cincura.net/
---
Nekdo vidi veci, ktere existuji, a pta se - proc?. Ja snim o vecech, ktere
nikdy neexistovaly a ptam se - proc ne? (Robert Kennedy)
Firebird a GBAK na velkou GDB
[*] Miso <delphinpp(zv)atlas(tec)cz> - 18.10.2004 11:37:26
----- Original Message -----
From: "Petr Zahradnik" <clexpert(zv)clexpert(tec)cz>
> > 2. Tento styl argumentace a nazoru tady od tebe slysime dost casto.
>
> Pavle, prosim prejdi z pluralu na singular - jestli chces zacit flame,
..kludne sa Pavol moze vyjadrovat v plurale, ja zdielam ten isty nazor..
Michal
jmeno exe souboru
[*] Petr Fiser <petr.fiser(zv)3jservis(tec)cz> - 18.10.2004 11:35:26
Dobry den.
Lze nejakym jednoduchym zpusobem rict prekladaci jmeno vysledneho exe souboru napr.:
{$IFDEF neco}
exename := xxx;
{$IFDEF necojineho}
exename := yyy;
Dekuji.
Petr Fiser
3J Servis s.r.o
Dulni 441
Bilina, 418 01
Tel: +420 603 887 663
Firebird a GBAK na velkou GDB
[*] Karel Rys <delphi(zv)zas-me(tec)cz> - 18.10.2004 10:57:23
Winsoft dne 15 Oct 2004 v 23:47:
> a myslis, ze snapshot citanie je akurat ta kriticka operacia ktoru
> treba riesit? Na ukor inych operacii? Ja nevidim ziaden problem, ze
> ked idem tlacit rozsiahlu zostavu, nacitam data do datasetu, odpojim
> sa od databazy a mozem tlacit hoci aj tyzden tie data. A ten shaphot
> mi ine neriesi, LEN to citanie dat. A aj to len vtedy ked nastane taka
> konstelacia, ze treba citat vela zaznamov v transakcii, co sa da IMHO
> velmi dobre eliminovat nacitanim si tych zaznamov rovno do mojho
> programu. A pri zapisovani zaznamov v transakcii zase len potrebujem
> serializaciu, cize ten shapshot ma nezachrani.
A co treba takova zaloha velke databaze za provozu? U MGA zadny problem, zatimco znamy se se
zalohovanim dat z MS SQL dost potykal (ale MS SQL skoro neznam, takze netvrdim, ze to nejak udelat
nejde).
Do datasetu sice lze, nepohodlne, leccos nacist, ale kdyz to za me udela spolehlive server...
Potiz s datasety bude prinejmensim v tom, ze po siti tahas spoustu dat (tabulka muze mit miliony
zaznamu) a po celou tu dobu ti je nesmi nikdo odjinud zmenit, jinak uz to neni snapshot, ale gulas
:) V MGA je nekdo zmenit muze, ale ty porad vidis data pred zmenou. Tedy pokud to tak chces a
transakci na snapshot nastavis, samozrejme. Jinak pokud sestava neni zrovna primitivni a taha si
data z ruznych tabulek a je typu master-detail, tak si ty datasety taky uzij :)
Karel Rys
Firebird a GBAK na velkou GDB
[*] Marek Spisak <spishark(zv)post(tec)cz> - 18.10.2004 10:47:23
>>>Velikost cache je fixni, takze k narustu spotreby RAM z duvodu rustu
>>>velikosti databaze nedochazi. nemelo by to zadnou logiku, kazda
>>>databaze bobtna i bez smeti.
>>>
>>>
>>ked nezvysim RAM (aj fyzicky, ked treba), tak sa udaje z databazy
>>nezmestia do cache a teda je prepoklad, ze praca s nou bude pomalsia.
>>Cize mozem si vybrat - pomalsia praca alebo vecsia cache. Takze
>>podla mna velkost databazy ma zjavny vplyv na spotrebu pamete.
>>
>>
>
>Jeste, ze jsi pripsal, ze podle Tebe. Pokud bych se drzel Tveho tvrzeni, tak
>by soucasne pevne disky meli mit cache nekolik GB a procesory take... Prosim
>podivej se na to co jsi napsal a zamysli se nad tim. Vzdyt to preci vubec
>nemusi byt pravda. Pokud budu mit jakoukoliv databazi - i kdyz to samozrejme
>plati analogicky pro soubor - muze me cache dokonce zpomalovat. Vzdycky je
>nutne dodat: "zalezi na konkretnim pouziti". Pokud budu porad jen zapisovat
>nova data, tak preci nepotrebuji 1GB cache ne ???
>
souhlas, mame FB databaze o celkem slusne velikosti - nejvetsi ma pres
10 GB, DB server ma 1 GB pameti a jede to slusne. Proc by se musela
databaze nacpat cela do pameti aby slusne jela??? Zalezi na navrhu
databaze, indexaci... Vetsinu databazi bych do pameti nenarval ani
kdybych se rozkrajel ;). Nehlede na to, ze na jednom FB serveru nam bezi
mnohdy vice nez 1 databaze.
Marek.Meno prvku vymenovaneho typu
[*] Jan Kostial <lucky62(zv)szm.sk> - 18.10.2004 10:11:20
Moj typ TMyType ale nie je property ziadnej triedy.
Je to proste typ. Pomohlo by definovat ho vo vhodnej sekcii nejakej unit?
Lucky
> TypeInfo funguje pouze na properties, ke kterym existuje RTTI informace.
> To jsou property uvedene v sekci published.
>
> Jan Kostial napsal(a):
> > GetEnumName by bolo perfektne,
> > bohuzial funkcia TypeInfo(TMyType) mi napise chybu:
> >
> > Type TMyType has no type info.
> > Nepomohol ani prepinac {$M+}
> >
> ______________________________________________________
> Karel Kral, vedouci odd. IT / IT manager
> Purus, s.r.o., Cezavy 627, 664 56 Blucina, CZ
> Tel: 547 235 000, 602 552 432, Fax: 547 231 203
> E-Mail: mailto:kral(zv)purus(tec)cz, WWW: http://www.purus(tec)cz
> ______________________________________________________
>
>
>Firebird a GBAK na velkou GDB
[*] Pavel Cisar <pcb(zv)atlas(tec)cz> - 18.10.2004 09:27:16
Haj hou!
On 18 Oct 2004 at 7:15, Milan Tomes wrote:
> co presne myslis tim "zacvicit" s constraints ???
>
> Zrusit a znovu vytvorit ???
Ano, presne tak.
S pozdravem
Pavel Cisar (ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix(tec)cz
Vse co potrebujete pro Firebird a InterBase
TStringList CustomSort dle datumu
[*] Petr Brant <brant(zv)dcomm(tec)cz> - 18.10.2004 09:25:16
Nenacitej jen nazvy, ale take data, takze napriklad
TFileAndDate = class
FileName: string;
DT: TDateTime;
end;
var FileList: TList;
FileAndDate: TFileAndDate ;
...a pri nacitani nazvu:
FileAndDate:= TFileAndDate.Create;
FileAndDate.FileName:= ...
FileAndDate.DT:= ....
FileList.Add(FileAndDate);
No a protoze trida TList ma metodu Sort, tak uz je jednoduche seznam
setridit tak jak potrebujes. Samozrejme po sobe nezapomen v pameti uklidit,
tady v cyklu volat Free pro kazdy prvek seznamu a na zaver zrusit i samotny
FileList. Ale to je snad samozrejme.
Zdravim
RNDr. Petr Brant [brant(zv)dcomm(tec)cz]
http://brant.wz(tec)cz <http://brant.wz(tec)cz>
> Do StringListu nacitam z adresare nazvy souboru dle masky. Poradi nekdo
> jak
> ve StringListu nazvy souboru setridit dle datumu vzniku souboru?
>
Meno prvku vymenovaneho typu
[*] Karel Kral <kralkonf(zv)purus(tec)cz> - 18.10.2004 08:47:13
TypeInfo funguje pouze na properties, ke kterym existuje RTTI informace.
To jsou property uvedene v sekci published.
Jan Kostial napsal(a):
> GetEnumName by bolo perfektne,
> bohuzial funkcia TypeInfo(TMyType) mi napise chybu:
>
> Type TMyType has no type info.
> Nepomohol ani prepinac {$M+}
>
______________________________________________________
Karel Kral, vedouci odd. IT / IT manager
Purus, s.r.o., Cezavy 627, 664 56 Blucina, CZ
Tel: 547 235 000, 602 552 432, Fax: 547 231 203
E-Mail: mailto:kral(zv)purus(tec)cz, WWW: http://www.purus(tec)cz
______________________________________________________
Firebird a GBAK na velkou GDB
[*] Milan Tomes <delphi(zv)haida(tec)cz> - 18.10.2004 07:15:06
Ahoj,
co presne myslis tim "zacvicit" s constraints ???
Zrusit a znovu vytvorit ???
S pozdravem
Milan Tomes
> [mailto:delphi-l-owner(zv)clexpert(tec)cz]On Behalf Of Pavel Cisar
> Sent: Friday, October 15, 2004 11:15 AM
>
> odstraneni smeti z indexu. Proto je nanejvyse vhodne po hromadnem
> vymazu nebo zmene cca 1/3 radku v tabulce ihned deaktivovat a
> opetovne aktivovat indexy (u FK je nutne "zacvicit" s constraints, PK
> se da vetsinou preskocit). Pri takovych operacich by s db nemel nikdo
> dalsi pracovat, anzto je to bepecnejsi a predevsim mnohem rychlejsi.Firebird a GBAK na velkou GDB
[*] Milan Tomes <delphi(zv)haida(tec)cz> - 18.10.2004 07:09:05
> [mailto:delphi-l-owner(zv)clexpert(tec)cz]On Behalf Of Winsoft
> Sent: Sunday, October 17, 2004 11:53 PM
>
> > > namiesto generovania smetia sa pocka na odomknutie zaznamu
> >
> > ??? Co tim mas na mysli ? "Smeti" je puvodni hodnota radku. Tu musis
> > vzdy uchovat, bez ohledu na architekturu kterou zvolis.
>
> V MDA kedze zaznamy sa nezamykaju, transakcie vytvaraju nove
> generacie zaznamov aj ked nie je (a nemoze byt) vopred zname
> ci budu komitnute. Takze spustim 2 dlhe transakcie, obidva bezia
> a vyrabaju nove gereracie a zatazuju system. A teraz dojde ku kolizii
> medzi nimi a na jednu (alebo obidve) sa musi pouzit rollback. Jedna
> z nich teda zbytocne zatazovala system a vyrobila zbytocne smetie.
A v pripade pouziti napr. MSSQL, ktery pouziva zamky uz dopredu vis, ze
vsechny transakce budou commitnuty. Tak to me tedy opravdu rozesmalo.
>
> V pripade pouzitia zamkov, ak transakcia narazi na zamknuty zaznam,
> tak nepokracuje, ale caka na odomknutie. Cize pobezi len ta prva
> transakcia, ta druha bude cakat a nebude zatazovat system (teda sice
> tato transakcia stoji a caka, ale o to rychlejsie pobezi ta, co bezi).
V pripade MGA pokud transakce narazi na zaznam, ktery byl zmenen jinou
transakci tak je preci situace naprosto stejna - je ohlasena chyba a
transakce nemuze dobehnout, takze o co Ti jde ??? Evidentne jsi nikdy s MGA
architekturou nepracoval.
> A po komitnuti prvej transakcie a uvolneni zamkov moze pokracuje
> a komitnut aj druha transakcia. Samozrejme kommit sa neda
> ani tu zarucit a neda sa vylucit ani deadlock, ale sanca na zbehnutie
> tych transakcii je tu celkom ina. Dokonca aj v pripade deadlocku
> sa v MS SQL rollback robi len u jednej transkacii, tam kde
> je jednoduchsi (cize mozme predpokladat ze u tej, ktora bola
> neskor spustena - a teda po jej opetovnom spusteni uz moze zbehnut).
Tak ci onak reseni tohoto stavu zavisi na programatorovi a ne na serveru -
princip je uplne stejny bez ohledu na architekturu. Jak MGA tak i lock
system ohlasi chybu v konkretni transakci. Jestli jsi jeste nepochopil
princip MGA, tak vez, ze Pavel se Ti snazil dost dlouho vysvetlit, ze nejde
o chybu pri zapisovani (rozumej UPDATE) jednoho zaznamu ve dvou transakcich
(tam to totiz vzdycky bez ohledu na architekturu skonci stejne), ale o
pouzivani read (rozumej SELECT) a write (rozumej UPDATE, INSERT) soucasne a
tam mi prijde architektura MGA vyhodnejsi. Zkratka a jednoduse klidne mohu
cist jeden konkretni zaznam i v pripade, ze mi jina transakce tento zaznam
zmenila a nemam s tim zadny problem - ctu totiz verzi platnou pri startovani
transakce (samozrejme zalezi na nastavene urovni izolace).
> A dalsie vyhody: nemam ziadne smetie, system sa zatazoval len
> vtedy ked to bolo potrebne.
Nemas zadne smeti ??? A co to, ktere je v transakcnim logu ??? To neni
smeti, ktere je naprosto nepotrebne ???
>
> Zamky mi teda umoznuju rychlejsie detekovat a predist konfliktom
> v transakciach za cenu cakania, ked je zamknute. To sa mi vidi
> dobre riesenie, pricom system zamkov je velmi jednoduchy
> na pochopenie aj implementovanie (kto si spusti napr. MS SQL
> si to moze aj lahko overit). A su moznosti urcovat izolaciu
> transakcii, alebo aj automaticky optimalizovat zamky alebo povedzme
> zamknut aj celu databazu ak potrebujem co najrychlejsie a s istotou
> zbehnut nejaku surnu transakciu. A tento system je velmi vyhodny
> pre kratke transakcie, teda typicke transakcie u beznych aplikacii
> Skratka osvedcena a overena architektura. Musela by byt ovela
> vyhodnejsia ina architektura aby sa vyplatilo prejst na inu. A takou
> IMHO teda MDA architektura nie je.
Evidentne jsi nikdy v zivote architekturu MGA nepouzil. Ale treba jsi takovy
genius, ze dokazes naprosto dokonale predvidat vsechny stavy Tveho programu,
takze nejaky deadlock Ti proste nehrozi :)
Ja se vyvojem na FireBirdem nejaky ten rok zabyvam a i pri velice dlouhych
transakcich (podivej se na komponenty IBX) se mi jeste NIKDY nestalo, ze
bych se dostal do deadlocku a pritom naprosto standardne pouzivam situaci
kdy jedna transakce (R/O) cte a druha updatuje data prectena tou prvni
transakci. Tohle by naprosto spolehlive polozilo MSSQL na zada (soude dle
drive napsaneho P. Cisarem, Tebou a dokumentace k MSSQL) - ale take je
mozne, ze pravdu nemam :)
>
> > > ako optimalizuje MDA, ked treba vytvarat novu generaciu velkeho
> > > mnozstva zaznamov v transakcii, ake tam su moznosti? Alebo
> > > ked sa zmaze vela zaznamov?
> >
> > Co konkretne by jsi chtel optimalizovat ? Je urcite mnozstvi prace,
> > ktere je vzdy zapotrebi udelat. MGA nikdy nedela vic nez je nezbytne
> > nutne.
>
> praveze MGA vyraba zbytocne zaznamy, lebo nepredchadza
> konfliktom pesimisticky ale optimisticky
Skoro se mi chce napsat, ze optimisticke reseni je i v zivote vyhodnejsi nez
pesimisticke, ale zalezi to na uhlu pohledu... :)
>
> > > a co tych x indexov navesenych na ten zaznam, tie netreba spravovat
> > > extra pre kazdu generaciu zaznamu?
> >
> > Ne, indexy verzovane nejsou, pouze radky.
>
> ako to, ze nie su verzovane indexy? Ako sa potom hlada v roznych
> generaciach
> zaznamu? A kedy sa tie indexy potom vlastne aktualizuju? Toto mi vysvetli,
> nejako neviem najst uspokojive riesenie (co neznamena, ze
> neexistuje ;-) ).
Me ano - indexy se aktualizuji pri commitnuti transakce. Pokud byl nejaky
zaznam odebran ci pridan, je zarazen na prislusne misto indexu - ostatni
transakce tuto zmenu jiz mohou videt a jiz bezici ho neuvidi prave diky
verzim radku.
>
> > > mozno tie rozne typy zamkov su tam prave preto aby sa dal
> > > redukovat pocet zamkov a ta sprava bola rychlejsia
> >
> > Samozrejmne, protoze bez toho by to lehlo velmi rychle. Nicmene je to
> > vyhaneni certa dablem (viz nasledky lock promotion)
>
> IMHO to je elegantne riesenie problemu. Optimalizuje
> sa s urcitym prijatelnym rizikom. A tak to uz byva, aj do
> cache sa niekedy nacitaju nepotrebne udaje aj predpoved
> vetvevenia skoku v procesore sa obcas netrafi. No a co?
> Dolezite je, ze vecsinou to funguje a celkovo sa teda
> vykonnost zvysi.
>
> > > tak preco to neopravis (alebo niektory z uzivatelov), ved je to open
> source,
> > > architektura je jednoducha, prinos by bol znacny (alebo
> nie?), tak v com
> > > je problem?
> >
> > A kdo rika, ze to jeste nikdo neopravil ? Zkus si jeste jednou
> > precist co jsem puvodne napsal.
>
> tak mozme uz teda porovnat vykon IB a MS SQL? ;-)
Ze by to byla pointa ??? Jde Ti o vykonovy test abys mohl rici MS SQL je
proste rychlejsi ??? Gratuluju... :)))
>
> > Velikost cache je fixni, takze k narustu spotreby RAM z duvodu rustu
> > velikosti databaze nedochazi. nemelo by to zadnou logiku, kazda
> > databaze bobtna i bez smeti.
>
> ked nezvysim RAM (aj fyzicky, ked treba), tak sa udaje z databazy
> nezmestia do cache a teda je prepoklad, ze praca s nou bude pomalsia.
> Cize mozem si vybrat - pomalsia praca alebo vecsia cache. Takze
> podla mna velkost databazy ma zjavny vplyv na spotrebu pamete.
Jeste, ze jsi pripsal, ze podle Tebe. Pokud bych se drzel Tveho tvrzeni, tak
by soucasne pevne disky meli mit cache nekolik GB a procesory take... Prosim
podivej se na to co jsi napsal a zamysli se nad tim. Vzdyt to preci vubec
nemusi byt pravda. Pokud budu mit jakoukoliv databazi - i kdyz to samozrejme
plati analogicky pro soubor - muze me cache dokonce zpomalovat. Vzdycky je
nutne dodat: "zalezi na konkretnim pouziti". Pokud budu porad jen zapisovat
nova data, tak preci nepotrebuji 1GB cache ne ???
S pozdravem
Milan Tomes
Firebird a GBAK na velkou GDB
[*] Martin Schayna <mschayna(zv)aktis(tec)cz> - 18.10.2004 00:42:39
Winsoft wrote:
> tak mozme uz teda porovnat vykon IB a MS SQL? ;-)
Ja bych byl pro.
Shodou okolnosti mame ted postavenou malou farmicku
se servery Sun a IBM a deviti stejnymi klienty, meli jsme ji
na Invexu (pav. V stanek c.4 ABRA). Navrhete oba,
Pavel i Erik, nejaky test proti stejne naplnene databazi
se stejnymi tabulkami, ktery by otestoval obe
architektury...
Otestovat muzeme treba FB CS 1.5 a Oracle 9.2
na Linuxu (jestli se nepletu tak MS SQL na Linuxu
nebezi).
Martin Schayna
www.aktis(tec)cz
Firebird a GBAK na velkou GDB
[*] Winsoft <winsoft(zv)netkosice.sk> - 17.10.2004 23:52:35
> > namiesto generovania smetia sa pocka na odomknutie zaznamu
>
> ??? Co tim mas na mysli ? "Smeti" je puvodni hodnota radku. Tu musis
> vzdy uchovat, bez ohledu na architekturu kterou zvolis.
V MDA kedze zaznamy sa nezamykaju, transakcie vytvaraju nove
generacie zaznamov aj ked nie je (a nemoze byt) vopred zname
ci budu komitnute. Takze spustim 2 dlhe transakcie, obidva bezia
a vyrabaju nove gereracie a zatazuju system. A teraz dojde ku kolizii
medzi nimi a na jednu (alebo obidve) sa musi pouzit rollback. Jedna
z nich teda zbytocne zatazovala system a vyrobila zbytocne smetie.
V pripade pouzitia zamkov, ak transakcia narazi na zamknuty zaznam,
tak nepokracuje, ale caka na odomknutie. Cize pobezi len ta prva
transakcia, ta druha bude cakat a nebude zatazovat system (teda sice
tato transakcia stoji a caka, ale o to rychlejsie pobezi ta, co bezi).
A po komitnuti prvej transakcie a uvolneni zamkov moze pokracuje
a komitnut aj druha transakcia. Samozrejme kommit sa neda
ani tu zarucit a neda sa vylucit ani deadlock, ale sanca na zbehnutie
tych transakcii je tu celkom ina. Dokonca aj v pripade deadlocku
sa v MS SQL rollback robi len u jednej transkacii, tam kde
je jednoduchsi (cize mozme predpokladat ze u tej, ktora bola
neskor spustena - a teda po jej opetovnom spusteni uz moze zbehnut).
A dalsie vyhody: nemam ziadne smetie, system sa zatazoval len
vtedy ked to bolo potrebne.
Zamky mi teda umoznuju rychlejsie detekovat a predist konfliktom
v transakciach za cenu cakania, ked je zamknute. To sa mi vidi
dobre riesenie, pricom system zamkov je velmi jednoduchy
na pochopenie aj implementovanie (kto si spusti napr. MS SQL
si to moze aj lahko overit). A su moznosti urcovat izolaciu
transakcii, alebo aj automaticky optimalizovat zamky alebo povedzme
zamknut aj celu databazu ak potrebujem co najrychlejsie a s istotou
zbehnut nejaku surnu transakciu. A tento system je velmi vyhodny
pre kratke transakcie, teda typicke transakcie u beznych aplikacii
Skratka osvedcena a overena architektura. Musela by byt ovela
vyhodnejsia ina architektura aby sa vyplatilo prejst na inu. A takou
IMHO teda MDA architektura nie je.
> > ako optimalizuje MDA, ked treba vytvarat novu generaciu velkeho
> > mnozstva zaznamov v transakcii, ake tam su moznosti? Alebo
> > ked sa zmaze vela zaznamov?
>
> Co konkretne by jsi chtel optimalizovat ? Je urcite mnozstvi prace,
> ktere je vzdy zapotrebi udelat. MGA nikdy nedela vic nez je nezbytne
> nutne.
praveze MGA vyraba zbytocne zaznamy, lebo nepredchadza
konfliktom pesimisticky ale optimisticky
> > a co tych x indexov navesenych na ten zaznam, tie netreba spravovat
> > extra pre kazdu generaciu zaznamu?
>
> Ne, indexy verzovane nejsou, pouze radky.
ako to, ze nie su verzovane indexy? Ako sa potom hlada v roznych generaciach
zaznamu? A kedy sa tie indexy potom vlastne aktualizuju? Toto mi vysvetli,
nejako neviem najst uspokojive riesenie (co neznamena, ze neexistuje ;-) ).
> > mozno tie rozne typy zamkov su tam prave preto aby sa dal
> > redukovat pocet zamkov a ta sprava bola rychlejsia
>
> Samozrejmne, protoze bez toho by to lehlo velmi rychle. Nicmene je to
> vyhaneni certa dablem (viz nasledky lock promotion)
IMHO to je elegantne riesenie problemu. Optimalizuje
sa s urcitym prijatelnym rizikom. A tak to uz byva, aj do
cache sa niekedy nacitaju nepotrebne udaje aj predpoved
vetvevenia skoku v procesore sa obcas netrafi. No a co?
Dolezite je, ze vecsinou to funguje a celkovo sa teda
vykonnost zvysi.
> > tak preco to neopravis (alebo niektory z uzivatelov), ved je to open
source,
> > architektura je jednoducha, prinos by bol znacny (alebo nie?), tak v com
> > je problem?
>
> A kdo rika, ze to jeste nikdo neopravil ? Zkus si jeste jednou
> precist co jsem puvodne napsal.
tak mozme uz teda porovnat vykon IB a MS SQL? ;-)
> Velikost cache je fixni, takze k narustu spotreby RAM z duvodu rustu
> velikosti databaze nedochazi. nemelo by to zadnou logiku, kazda
> databaze bobtna i bez smeti.
ked nezvysim RAM (aj fyzicky, ked treba), tak sa udaje z databazy
nezmestia do cache a teda je prepoklad, ze praca s nou bude pomalsia.
Cize mozem si vybrat - pomalsia praca alebo vecsia cache. Takze
podla mna velkost databazy ma zjavny vplyv na spotrebu pamete.
Erik
Firebird a GBAK na velkou GDB
[*] Pavel Cisar <pcb(zv)atlas(tec)cz> - 17.10.2004 21:18:25
On 17 Oct 2004 at 18:04, Winsoft wrote:
> > 1. Zapominas, ze to tvoje "smeti" se musi generovat a ukladat tak
> > jako tak, at uz je pouzita MGA nebo neni. Rozdil je v tom, kam se
> > uklada. U MGA je v databazi, jinak jde do transakcniho logu. Oba
> > pristupy maji sve vyhody i nevyhody.
>
> namiesto generovania smetia sa pocka na odomknutie zaznamu
??? Co tim mas na mysli ? "Smeti" je puvodni hodnota radku. Tu musis
vzdy uchovat, bez ohledu na architekturu kterou zvolis.
> > 2. I transakcni logy se museji "uklizet", protoze rostou donekonecna.
> > Diky jejich oddelenemu ulozeni nemaji takovy vliv na cinnost systemu,
> > pokud se "vymknou" kontrole. Na druhou stranu ma MGA mechanizmy,
> > ktere *automaticky* a ucine snizuji pravdepodobnost, ze se mnozstvi
> > smeti vymkne kontrole. Pracovat s tim ci onim bez zasadnich problemu
> > je otazka znalosti a discipliny, nicmene obeho je zapotrebi u obou
> > architektur.
>
> povedal by som, ze cistit databazu od neplatnych zaznamov
> je narocnejsia zalezitost ako cistit trans. log. S trans. logom
> je ovela menej problemov to je neporovnatelne.
To mas samozrejme pravdu, ale odsunem puvodnich hodnot do logu
zaroven znacke komlikujes jejich dostupnost, a tedy rozumnou
implementaci snapshotu. A bez snapshotu nektere operace proste nejdou
rozumne udelat. V obou pripadech jde o kompromis, protoze zatim nikdo
neprisel na postup, ktery by dovoloval mit obe vlastnosti za stejne
"nizkou" cenu. Navic odstranovani smeti neni az takovy problem.
> > > Ked mam dvoch uzivatelov a kazdy z nich spusti dlhsiu
> > > transakciu v ktorej si budu prepisovat zaznamy, vysledkom
> > > bude, ze nezbehne ani jedna ani druha transakcia. A mozu
> > > tie transakcie spustat aj cely den. Tak co som vlastne vyriesil?
> >
> > Ale v tom se MGA a lock&log architektura nijak nelisi. Navic jde o
> > zcela vykonstruovany, v praxi naprosto nesmyslny priklad. V cem je
> > tedy argument ?
>
> v pripade zamkov je daleko vyssia sanca na ukoncenie aspon
> jednej z tychto transakcii.
Proc myslis ze je to u MGA jinak ? MGA nema zamky na radky, protoze
je nepotrebuje, anzto stejnou funkci jakou maji zamky realizuji
samotne verze. Kolize zapisu je tedy detekovana u obou architektur
naprosto stejne.
> A hovoris vykonstruovany priklad?
Ano, protoze zadne transakce si nemohou jak ty pises "vzajemne
prepisovat zaznamy". Ta ktera prijde jako druha bude mit proste
smulu, skonci s chybou (a na architekture nezalezi). Mozna te i
prekvapi, ze MGA ma oproti systemu se zamky prakticky nulovou moznost
vzniku deadlocku.
> Ze sa pouzivaju rozne zamky to je vsetko otazka optimalizacie (napr.
> preco zamykat kazdy zaznam extra, ked potrebujem zamknut celu tabulku).
> Zamok je jednoduchy mechanizmus ale ked treba zamykat vela zaznamov je
> logicke, ze sa to optimalizuje.
Prave ze je nutne to optimalizovat upgradem typu zamku, napr. z row
lock na page lock, pripadne i table lock. Tim se prakticky eliminuje
vyhoda radkovych zamku pro transakce ktere meni vetsi mnozstvi dat,
pripadne vetsi mnozstvi ctou v izolaci Repeatable Read. Co to v praxi
znamena je ti urcite jasne, obzvlaste pokud jsi pracoval s nejakou
databazi ktera nemela zamky na jednotlive radky (napr. MS SQLServer
pred verzi 7). Proste des bes.
> > Jen takovy maly priklad: MS SQLServer ma od verze 7 zamky na urovni
> > radku. Kazdy radek precteny v izolaci vyssi nez Read Committed je
> > nutne uzamknout share lockem, aby nebyl zmenen. Vis co se stane,
> > pokud takova transakce precte par set tisic radku, o milionech
> > nemluve ?
> >
> > (napoveda: pokud si myslis, ze vytvori prislusny pocet radkovych
> > zamku, pak jsi na omylu).
>
> ako optimalizuje MDA, ked treba vytvarat novu generaciu velkeho
> mnozstva zaznamov v transakcii, ake tam su moznosti? Alebo
> ked sa zmaze vela zaznamov?
Co konkretne by jsi chtel optimalizovat ? Je urcite mnozstvi prace,
ktere je vzdy zapotrebi udelat. MGA nikdy nedela vic nez je nezbytne
nutne.
> > Rovnez mi vysvetli, proc a v cem je nasledujici postup u MGA:
> >
> > I/O: Zapis jedne, v nejhorsim pripade dvou db stranek.
> >
> > ...horsi nes nasledujici obecny postup u Lock&Log:
> >
> > I/O: vzdy zapis aktualni db stranky + zapis do logu.
>
> a co tych x indexov navesenych na ten zaznam, tie netreba spravovat
> extra pre kazdu generaciu zaznamu?
Ne, indexy verzovane nejsou, pouze radky.
> > Ty si vazne myslis, ze zamek existuje nekde na disku ? Je v RAMce, ve
> > zvlastni strukture. Problem ovsem neni ve vytvoreni nebo zruseni
> > zamku, ale v rizeni velmi velkeho poctu zamku, a to ruznych typu, a
> > zmeny jejich charakteru za provozu systemu.
>
> mozno tie rozne typy zamkov su tam prave preto aby sa dal
> redukovat pocet zamkov a ta sprava bola rychlejsia
Samozrejmne, protoze bez toho by to lehlo velmi rychle. Nicmene je to
vyhaneni certa dablem (viz nasledky lock promotion)
> > > takze namiesto kratkej transkcie mozem pouzit dlhu ale riskujem
> > > vytvaranie dalsich zaznamov a spomalovanie systemu. A kazda
> > > taka transkcia bude zvysovat a zvysovat reziu (a nie linearne, lebo
> > > riziko kolizie zaznamov sa zvysuje) a pojde to podla mna dovtedy,
> > > kym tych transkcii a generacii nebude tolko, ze cely system zdochne.
> >
> > 1. O jake kolizi mluvis ? Mnozstvi verzi jednoho radku nema s
> > pravdepodobnosti kolize nic spolecneho.
>
> dlhsia transakcia znamena vecsiu sancu, ze pocas jej vykonavania
> sa vyskytne ina transakcia, nie? A viac transakcii zas vecsiu sancu
> na koliziu medzi nimi, nie?
Ano, ale to prece plati obecne pro jakykoliv system, nejde o nejake
specifikum MGA. MGA v takovych scenarich moznost kolize zapisu nijak
nezvysi, naopak eliminaci moznosti kolize mezi ctenim a zapisem
umoznuje provoz dele trvajicim transakcim i v situacich, ve kterych
by to u systemu se zamky nebylo mozne.
> > 2. Mluvis ocividne bez blizsi povedomosti o tom, jak MGA skutecne
> > funguje. Prodluzovani retezu verzi radku neni apriori problem, a pri
> > spravne implementaci MGA a tvorbe aplikaci s ohledem na MGA nema na
> > vykon nijak zasadni vliv.
>
> tak preco tam treba vobec robit to zbieranie smetia? Ved ked to smetie
> nema na vykon vplyv, tak je IMHO zbytocne to pravidelne spustat.
Smeti zacina mit vliv na vykon pouze kdyz je ho opravdu hodne. Do 15%
objemu databze to temer nelze merit. Vyjimkou jsou extremne dlouhe
retezce verzi, ale ty vznikaji pouze kdyz se aplikace zamerne navrhne
urcitym konkretnim zpusobem (coz nikdo se znalosti MGA nikdy
neudela).
> > Firebird Super Server s tim ovsem problem za urcitych okolnosti mel a
> > stale jeste obcas ma, protoze Borland sprasil garbage collection
> > thread. S Classicem je situace o necem jinem, a Vulcan by na tom mel
> > byt jeste o fous lepe. Nicmene to stale nic nevypovida o MGA jako
> > takove, pouze o konkretni implementaci.
>
> tak preco to neopravis (alebo niektory z uzivatelov), ved je to open source,
> architektura je jednoducha, prinos by bol znacny (alebo nie?), tak v com
> je problem?
A kdo rika, ze to jeste nikdo neopravil ? Zkus si jeste jednou
precist co jsem puvodne napsal.
> > Zvysovani velikosti databaze automaticky neznamena *vyrazne*
> > pomalejsi pristup k datum, a uz vubec netusim, jak jsi prisel na
> > vyssi naroky na pamet.
>
> RAMka zvykne byt rychlejsia ako disk a preto je asi vyhodne
> vyuzit ju ako cache. No a cim viac RAMky na cache, tym viac
> dat sa do nej vmesti a praca s nimi potom rychlejsia. No a co sa tyka
> velkosti diskovej pamete, tak smetie vytvarane v MDA na velkosti
> databazy asi neuberie, skor napak
Velikost cache je fixni, takze k narustu spotreby RAM z duvodu rustu
velikosti databaze nedochazi. nemelo by to zadnou logiku, kazda
databaze bobtna i bez smeti.
> > Ze neni Oracle, DB2, Sybase nebo MS SQLServer zcela prepracovany na
> > MGA je vec spise ekonomicka a zpetne kompatibility, nez kvuli
> > technologicke vyhodnosti zamku a transakcniho logu. Proste se jim
> > nevyplati to cele predelavat. Nicmene kdyz je MGA podle tebe tak
> > spatna oproti klasicke, tak mi vysvetli proc rada novych (ktere
> > zacinaji na zelene louze) implementaci transakci (napr. u MySQL)
> > pouziva prave MGA/MVCC ?
>
> aha, takze Microsoft a Oracle si nemozu ekonomicky dovolit
> implementovat MGA. Na rozdiel od akejsi firmicky (neviem
> si teraz spomenut ako sa vlastne vola), ktora robi MySQL.
> Zvlastna logika.
Takze jeste jednou a po lopate: Architektura ovlivnuje implementaci
mnoha dalsich subsystemu db enginu. Prepracovat napr. Oracle plne na
MGA by znamenalo prepsat ho skoro cely. Navic by nebylo jednoduche
dodrzet zpetnou kompatibilitu vsech vlastnosti a vychytavek ktere
obsahuje (dost jich je napsanych "na telo" systemu zamku a logu,
pripadne ma implementacne zavisly interface). U systemu rozsahu
Oracle to tedy neni ekonomicky unosne. U MySQL se transakce teprve
implementovaly, takze si mohli svobodne vybrat, jak je udelaji.
S pozdravem
Pavel Cisar (ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix(tec)cz
Vse co potrebujete pro Firebird a InterBase
Firebird a GBAK na velkou GDB
[*] Winsoft <winsoft(zv)netkosice.sk> - 17.10.2004 18:04:12
> 1. Zapominas, ze to tvoje "smeti" se musi generovat a ukladat tak
> jako tak, at uz je pouzita MGA nebo neni. Rozdil je v tom, kam se
> uklada. U MGA je v databazi, jinak jde do transakcniho logu. Oba
> pristupy maji sve vyhody i nevyhody.
namiesto generovania smetia sa pocka na odomknutie zaznamu
> 2. I transakcni logy se museji "uklizet", protoze rostou donekonecna.
> Diky jejich oddelenemu ulozeni nemaji takovy vliv na cinnost systemu,
> pokud se "vymknou" kontrole. Na druhou stranu ma MGA mechanizmy,
> ktere *automaticky* a ucine snizuji pravdepodobnost, ze se mnozstvi
> smeti vymkne kontrole. Pracovat s tim ci onim bez zasadnich problemu
> je otazka znalosti a discipliny, nicmene obeho je zapotrebi u obou
> architektur.
povedal by som, ze cistit databazu od neplatnych zaznamov
je narocnejsia zalezitost ako cistit trans. log. S trans. logom
je ovela menej problemov to je neporovnatelne.
> > Ked mam dvoch uzivatelov a kazdy z nich spusti dlhsiu
> > transakciu v ktorej si budu prepisovat zaznamy, vysledkom
> > bude, ze nezbehne ani jedna ani druha transakcia. A mozu
> > tie transakcie spustat aj cely den. Tak co som vlastne vyriesil?
>
> Ale v tom se MGA a lock&log architektura nijak nelisi. Navic jde o
> zcela vykonstruovany, v praxi naprosto nesmyslny priklad. V cem je
> tedy argument ?
v pripade zamkov je daleko vyssia sanca na ukoncenie aspon
jednej z tychto transakcii. A hovoris vykonstruovany priklad?
IMHO je to jednoduchy priklad na dlhe transakcie s moznymi
koliziami, nic ine. Teda to, co ma MDA riesit. Najprv ma kritizujes
ked hovorim, ze treba kratke transakcie a neskor ked uvediem
priklad na dlhe, tak hovoris, ze je to v praxi nezmysel. Tak
sa skus najprv sam ujednotit na tych transakciach.
> To je jen tvuj osobni nazor. Kolik databazi jsi uz implementoval,
> pripadne jejich implementaci prostudoval ? Vis vubec kolik *typu*
> zamku potrebuje takovy lock&log db engin ktery neni urcen jen na
> hrani ? Co musi delat aby to vsechno ukociroval ?
jednu suborovu databazu som implementoval. Ale to nie je
dolezite. Ze sa pouzivaju rozne zamky to je vsetko otazka
optimalizacie (napr. preco zamykat kazdy zaznam extra, ked
potrebujem zamknut celu tabulku). Zamok je jednoduchy
mechanizmus ale ked treba zamykat vela zaznamov je logicke,
ze sa to optimalizuje.
> Jen takovy maly priklad: MS SQLServer ma od verze 7 zamky na urovni
> radku. Kazdy radek precteny v izolaci vyssi nez Read Committed je
> nutne uzamknout share lockem, aby nebyl zmenen. Vis co se stane,
> pokud takova transakce precte par set tisic radku, o milionech
> nemluve ?
>
> (napoveda: pokud si myslis, ze vytvori prislusny pocet radkovych
> zamku, pak jsi na omylu).
ako optimalizuje MDA, ked treba vytvarat novu generaciu velkeho
mnozstva zaznamov v transakcii, ake tam su moznosti? Alebo
ked sa zmaze vela zaznamov?
> Rovnez mi vysvetli, proc a v cem je nasledujici postup u MGA:
>
> I/O: Zapis jedne, v nejhorsim pripade dvou db stranek.
>
> ...horsi nes nasledujici obecny postup u Lock&Log:
>
> I/O: vzdy zapis aktualni db stranky + zapis do logu.
a co tych x indexov navesenych na ten zaznam, tie netreba spravovat
extra pre kazdu generaciu zaznamu?
> At to vezmu z kterekoliv strany, mezi obojim pristupem v *principu*
> neni zadny rozdil. Puvodni hodnotu radku je vzdy treba vzit a nekam
> odsunout, a novou zapsat na jeho puvodni pozici. Rozdil je pouze v
> nezbytnych transformacich datovych struktur, poctu I/O a absenci
> zamku na radky u MGA. Nicmene MGA toho provadi mene, s mensim
> mnozstvim datovych struktur a podstatne jednodussim kodem. Mohli by
> jsme to sice objektivne zmerit, ale uz z takto hrubeho popisu lze
> dovodit, ze by rychlejsi a jednoduss mela byt spise MGA, nikoliv
> naopak.
ja by som to predsa len radsej objektivne zmeral ;-)
> > zamok v RAMke je jedna instrukcia, zamknut zaznam v subore
> > nemoze byt takisto ziadny velky problem.
>
> Ty si vazne myslis, ze zamek existuje nekde na disku ? Je v RAMce, ve
> zvlastni strukture. Problem ovsem neni ve vytvoreni nebo zruseni
> zamku, ale v rizeni velmi velkeho poctu zamku, a to ruznych typu, a
> zmeny jejich charakteru za provozu systemu.
mozno tie rozne typy zamkov su tam prave preto aby sa dal
redukovat pocet zamkov a ta sprava bola rychlejsia
> > takze namiesto kratkej transkcie mozem pouzit dlhu ale riskujem
> > vytvaranie dalsich zaznamov a spomalovanie systemu. A kazda
> > taka transkcia bude zvysovat a zvysovat reziu (a nie linearne, lebo
> > riziko kolizie zaznamov sa zvysuje) a pojde to podla mna dovtedy,
> > kym tych transkcii a generacii nebude tolko, ze cely system zdochne.
>
> 1. O jake kolizi mluvis ? Mnozstvi verzi jednoho radku nema s
> pravdepodobnosti kolize nic spolecneho.
dlhsia transakcia znamena vecsiu sancu, ze pocas jej vykonavania
sa vyskytne ina transakcia, nie? A viac transakcii zas vecsiu sancu
na koliziu medzi nimi, nie?
> 2. Mluvis ocividne bez blizsi povedomosti o tom, jak MGA skutecne
> funguje. Prodluzovani retezu verzi radku neni apriori problem, a pri
> spravne implementaci MGA a tvorbe aplikaci s ohledem na MGA nema na
> vykon nijak zasadni vliv.
tak preco tam treba vobec robit to zbieranie smetia? Ved ked to smetie
nema na vykon vplyv, tak je IMHO zbytocne to pravidelne spustat.
> Firebird Super Server s tim ovsem problem za urcitych okolnosti mel a
> stale jeste obcas ma, protoze Borland sprasil garbage collection
> thread. S Classicem je situace o necem jinem, a Vulcan by na tom mel
> byt jeste o fous lepe. Nicmene to stale nic nevypovida o MGA jako
> takove, pouze o konkretni implementaci.
tak preco to neopravis (alebo niektory z uzivatelov), ved je to open source,
architektura je jednoducha, prinos by bol znacny (alebo nie?), tak v com
je problem?
> Zvysovani velikosti databaze automaticky neznamena *vyrazne*
> pomalejsi pristup k datum, a uz vubec netusim, jak jsi prisel na
> vyssi naroky na pamet.
RAMka zvykne byt rychlejsia ako disk a preto je asi vyhodne
vyuzit ju ako cache. No a cim viac RAMky na cache, tym viac
dat sa do nej vmesti a praca s nimi potom rychlejsia. No a co sa tyka
velkosti diskovej pamete, tak smetie vytvarane v MDA na velkosti
databazy asi neuberie, skor napak
> Ze neni Oracle, DB2, Sybase nebo MS SQLServer zcela prepracovany na
> MGA je vec spise ekonomicka a zpetne kompatibility, nez kvuli
> technologicke vyhodnosti zamku a transakcniho logu. Proste se jim
> nevyplati to cele predelavat. Nicmene kdyz je MGA podle tebe tak
> spatna oproti klasicke, tak mi vysvetli proc rada novych (ktere
> zacinaji na zelene louze) implementaci transakci (napr. u MySQL)
> pouziva prave MGA/MVCC ?
aha, takze Microsoft a Oracle si nemozu ekonomicky dovolit
implementovat MGA. Na rozdiel od akejsi firmicky (neviem
si teraz spomenut ako sa vlastne vola), ktora robi MySQL.
Zvlastna logika.
Erik
C++ a Delphi v jednom souboru
[*] Jakub Cermak <cermiforum(zv)centrum(tec)cz> - 17.10.2004 13:37:53
Bohuzel ceckove direktivy jsou #ifdef neco a #endif (je tam # na zacatku,
takze to nepude)
WinXP SP1, Delphi 6 Ent.
Jakub Cermak
ja.cermi(zv)centrum(tec)cz
ICQ 159971304
http://cermi.wz(tec)cz
----- Original Message -----
From: "Jan Rizek" <jan_rizek(zv)centrum(tec)cz>
To: <delphi-l(zv)clexpert(tec)cz>
Sent: Saturday, October 16, 2004 2:54 PM
Subject: Re: C++ a Delphi v jednom souboru
> Rekl bych ze by se na to dali pouzit direktivy kompilatoru -
>
> {$IFDEF CPLUSPLUS}
> ceckovy kod....
> {$ENDIF}
>
> {$IFDEF DELPHI}
> delphi...
> {$ENDIF}
>
> Pokud C++ podporuje stejne direktivy kompilatoru..
>
> > Zdravim konferenci,
> > nekde jsem slysel, ze jde do 1 souboru napsat zdrojak pro Pascal/Delphi
a
> > C++. Proste mi jde o to aby, kdyz ten soubor prelozim v Delphi, aby
> > prekladac "nevidel" na C++ kod a naopak.Odhaduju ze se to dela pomoci
> > komentaru, ale jak presne nemam tuseni. Nevite nekdo jak na to? Nejlepe
> > priklad
> >
> > WinXP SP1, Delphi 6 Ent., C++ Builder 5
> >
> > Jakub Cermak
> > ja.cermi(zv)centrum(tec)cz
> > ICQ 159971304
> > http://cermi.wz(tec)cz
> >
> >
> >
> >
>
>prekreslovani bez processmessages
[*] Petr Zahradnik <clexpert(zv)clexpert(tec)cz> - 16.10.2004 23:50:54
Puvodni zprava ze dne 16.10.2004:
> Jinak je pravda, ze pri rekurzivnim volani ProcessMessages je
> potreba uvedomovat si mozne dusledky. Ale preneseni cinnosti do
> zvlast threadu casto zpusobi daleko vetsi problemy, zejmena kvuli
> synchronizaci se muze program zakomplikovat na neunosnou miru.
Proc ??? Kvuli trivialni synchronizaci si pridelas starosti s
ProcessMessages a budes radeji rozdelovat deletrvajici operaci na
kousky, aby to nezatuhavalo?
Petr Zahradnik, pocitacovy expert
==========================================================
Petr Zahradnik, Computer Laboratory
web: http://www.clexpert(tec)cz, e-mail: clexpert(zv)clexpert(tec)cz
==========================================================
prekreslovani bez processmessages
[*] Petr Vones <konference(zv)petrvones(tec)net> - 16.10.2004 23:44:54
From: "Jan Novak" <delfin4(zv)volny(tec)cz>
> Jinak je pravda, ze pri rekurzivnim volani ProcessMessages je potreba
> uvedomovat si mozne dusledky. Ale preneseni cinnosti do zvlast threadu
> casto zpusobi daleko vetsi problemy, zejmena kvuli synchronizaci se
> muze program zakomplikovat na neunosnou miru.
Naprosto nesouhlasim. Pouziti samostatneho threadu cely problem naopak
zjednodusi.
Petr Vones
prekreslovani bez processmessages
[*] Jan Novak <delfin4(zv)volny(tec)cz> - 16.10.2004 23:22:52
> prubezne volam application.processmessages, aby se zmeny projevily.
> Coz bohuzel zaroven zpusobuje, ze ovladaci prvky reaguji
Ja pouzivam 2 zpusoby:
1. na zacatku OnClick nastavim Screen.Cursor na crHourGlass a
'finally' jej vratim zpet. Tim se daji vyradit vsechny ovladaci prvky
najednou.
2. kdyz chci, aby ostatni tlacitka reagovala, tak jen na dobu
zpracovani OnCLick nastavim kliknutemu tlacitku Enabled na false a
finally na true.
Jinak je pravda, ze pri rekurzivnim volani ProcessMessages je potreba
uvedomovat si mozne dusledky. Ale preneseni cinnosti do zvlast threadu
casto zpusobi daleko vetsi problemy, zejmena kvuli synchronizaci se
muze program zakomplikovat na neunosnou miru.Firebird a GBAK na velkou GDB
[*] Ludek ZITA <konference(zv)sales(tec)cz> - 16.10.2004 20:34:41
On Behalf Of Petr Zahradnik
[Pavel Cisar]
> > Moznost kolize kterou ty apriori vylucujes argumentem, ze data
> > podlehajici uzaverce nemuze nikdo jiny menit. Ano, data primo
> > podlehajici uzaverce nikoliv (napr. "uzavirane" doklady), ale data
> > spriznena grafem zavislosti a potrebna pro zpracovani (napr. nazev
> > strediska, zbozi apod. z ciselniku) tomuto omezeni podlehat nemusi.
>
[Petr Zahradnik]
> Kdyz ti to nekdo zmeni pred nebo po uzaverce, tak mas
> vysledek stejny jako v prubehu uzaverky - v obou pripadech je
> to problem.
Ahoj,
No ja bych si dovolil souhlasit s Pavlem Cisarem. Protoze nejde jen o
data, ale take o indexy nad hlavnimi i ciselnikovymi tabulkami.
To na vysledek uzaverky (z pohledu platnych dat) vliv nema, ale kolize
mezi zapisem a ctenim na indexu jiste vznikne.
Ludek Borland Delphi 2005
[*] petr palicka <palicka.petr(zv)seznam(tec)cz> - 15.10.2004 07:23:00
Petr Vones wrote:
> From: "Jiri Foldyna" <jiri.f(zv)avizo(tec)cz>
>>No, ja bych ocenil podobny nastroj, ktery by v jednom GUI umoznoval vyvoj
>>novych veci v .NET (klidne v C#) a udrzbu starych ve Win32 (a Object
> Zalezi na typu aplikaci co chces vyvijet, treba Compact Framework nebude
> podporovan.
hmm, skoda, to je jediny, co me zatim na .NETu laka :/
>>(koneckoncu, bude to teprve ctvrty nebo paty, co znam :-)), vic me zdrzuje
>>stridani vyvojovych prostredi s ruznym ovladanim. Takze ano, pokud to bude
> To je opravdu jen vec zvyku.
myslim, ze J.F. to myslel takhle: udrzovat stavajici Win32 + nove psat
pro .NET = (v pripade dvou IDE) znacnej hokej v klavesa pri zmene IDE.
Ja treba, kdyz potrebuju neco opravit v PCFANDU, tak mi nejvetsi potize
dela jine rozlozeni DOSove klavesnice (to je preklepu a hledani...). V
Pripade jednotneho IDE pro Win32 i .NET by podobne potize odpadly.
Peca
Firebird a GBAK na velkou GDB
[*] Pavel Cisar <pcb(zv)atlas(tec)cz> - 16.10.2004 19:30:36
Haj hou!
On 16 Oct 2004 at 16:30, Winsoft wrote:
> lenze paradoxne to je presne to spracovanie udajov, ktore by
> ta MGA architektura mala riesit, koli ktoremu bola robena, nie?
> Teda nie kratke transakcie ale dlhe. A neriesi to, ani nemoze riesit,
> lebo riesi len polovicu problemu (citanie) a aj to za cenu
> znacnych komplikacii - generovania smeti a jeho upratovania.
1. Zapominas, ze to tvoje "smeti" se musi generovat a ukladat tak
jako tak, at uz je pouzita MGA nebo neni. Rozdil je v tom, kam se
uklada. U MGA je v databazi, jinak jde do transakcniho logu. Oba
pristupy maji sve vyhody i nevyhody.
2. I transakcni logy se museji "uklizet", protoze rostou donekonecna.
Diky jejich oddelenemu ulozeni nemaji takovy vliv na cinnost systemu,
pokud se "vymknou" kontrole. Na druhou stranu ma MGA mechanizmy,
ktere *automaticky* a ucine snizuji pravdepodobnost, ze se mnozstvi
smeti vymkne kontrole. Pracovat s tim ci onim bez zasadnich problemu
je otazka znalosti a discipliny, nicmene obeho je zapotrebi u obou
architektur.
3. Jak je videt, MGA neni principialne odlisna od architektury zamku
a transakcniho logu. Oba pristupy resi stejny problem a potykaji se
se stejnymi prekazkami, pouze technicke reseni maji odlisne. Oba
pristupy maji sve prednosti i nevyhody.
> Ked mam dvoch uzivatelov a kazdy z nich spusti dlhsiu
> transakciu v ktorej si budu prepisovat zaznamy, vysledkom
> bude, ze nezbehne ani jedna ani druha transakcia. A mozu
> tie transakcie spustat aj cely den. Tak co som vlastne vyriesil?
Ale v tom se MGA a lock&log architektura nijak nelisi. Navic jde o
zcela vykonstruovany, v praxi naprosto nesmyslny priklad. V cem je
tedy argument ?
> > To je omyl, MGA *nema* automaticky vyssi rezii, prave naopak. Za
> > bezneho provozu ma rezii mensi, protoze zmenena data neni treba
> > odsouvat do externiho uloziste (transakcni protokol), ale v
> > optimalnim pripade se presouvaji pouze v ramci teze databazove
> > stranky. A i v pripadech kdy je nezbytne data odsunout do jine db
> > stranky, snizuje rezii sprava cache. Cely system je navrzen tak, aby
> > minimalizoval pocet I/O operaci, ktere jsou hlavnim urcujicim prvkem
> > vykonu kazdeho db systemu.
>
> Podla mna je neporovnatelne jednoduchsie a rychlejsie zamknut zaznam
> a ukladat pripadne zmeny do trans. logu ako vyrabat a spravovat verzie
> zaznamov a indexov.
To je jen tvuj osobni nazor. Kolik databazi jsi uz implementoval,
pripadne jejich implementaci prostudoval ? Vis vubec kolik *typu*
zamku potrebuje takovy lock&log db engin ktery neni urcen jen na
hrani ? Co musi delat aby to vsechno ukociroval ?
Jen takovy maly priklad: MS SQLServer ma od verze 7 zamky na urovni
radku. Kazdy radek precteny v izolaci vyssi nez Read Committed je
nutne uzamknout share lockem, aby nebyl zmenen. Vis co se stane,
pokud takova transakce precte par set tisic radku, o milionech
nemluve ?
(napoveda: pokud si myslis, ze vytvori prislusny pocet radkovych
zamku, pak jsi na omylu).
Rovnez mi vysvetli, proc a v cem je nasledujici postup u MGA:
1. Ziskani zamku na db stranku (jen po dobu I/O)
2. Presun stavajiciho radku v ramci stranky, pokud je to ucelne, tak
pouze jako delta k nove hodnote radku, a tudiz mensi. Pokud nelze
puvodni verzi ulozit na stenou stranku, pak se presune na jinou
stranku kde je misto (ta se pracne nehleda, system o takovych
strankach "vi").
3. Ulozeni nove hodnoty radku na misto puvodniho.
I/O: Zapis jedne, v nejhorsim pripade dvou db stranek.
...horsi nes nasledujici obecny postup u Lock&Log:
1. Ziskani zamku na radek (do konce transakce), pripadne zmena typu
zamku (napr. pokud uz byl radek cten, tak zmena z share lock na write
lock apod.) a db stranku (jen po dobu I/O)
2. Nacteni stavajici hodnoty radku, transformace dat do struktury pro
transakcni log a zapis do logu.
3. Zapis nove hodnoty radku na misto puvodniho.
I/O: vzdy zapis aktualni db stranky + zapis do logu.
At to vezmu z kterekoliv strany, mezi obojim pristupem v *principu*
neni zadny rozdil. Puvodni hodnotu radku je vzdy treba vzit a nekam
odsunout, a novou zapsat na jeho puvodni pozici. Rozdil je pouze v
nezbytnych transformacich datovych struktur, poctu I/O a absenci
zamku na radky u MGA. Nicmene MGA toho provadi mene, s mensim
mnozstvim datovych struktur a podstatne jednodussim kodem. Mohli by
jsme to sice objektivne zmerit, ale uz z takto hrubeho popisu lze
dovodit, ze by rychlejsi a jednoduss mela byt spise MGA, nikoliv
naopak.
> > MGA neresi *jen* problem kolizi R/O vs. R/W transakci. Predevsim
> > zjednodusuje cely system implementace atomicity operaci a izolace
> > transakci. MGA totiz nepouziva zamky, cimz se cela implementace
> > znacne zjednodusuje. Navic minimalizuje mnozstvi nezbytnych iternich
> > datovych struktur, presouvani dat atd. MGA ma i radu pozitivnich
> > "vedlejsich" vlastnosti, jako napriklad *okamzite* zotaveni po padu
> > systemu (zadne prehravani logu), automaticka podpora on-line
> > zalohovani atd. Samozrejmne ma i sva uskali, predevsim nutnost brat
> > pri navrhu systemu v uvahu nutnost odstanovani smeti. Pokud ovsem
> > clovek vi jak to funguje a co delat pripadne co nedelat, pak s tim
> > nejsou problemy.
>
> zamok v RAMke je jedna instrukcia, zamknut zaznam v subore
> nemoze byt takisto ziadny velky problem.
Ty si vazne myslis, ze zamek existuje nekde na disku ? Je v RAMce, ve
zvlastni strukture. Problem ovsem neni ve vytvoreni nebo zruseni
zamku, ale v rizeni velmi velkeho poctu zamku, a to ruznych typu, a
zmeny jejich charakteru za provozu systemu.
> takze namiesto kratkej transkcie mozem pouzit dlhu ale riskujem
> vytvaranie dalsich zaznamov a spomalovanie systemu. A kazda
> taka transkcia bude zvysovat a zvysovat reziu (a nie linearne, lebo
> riziko kolizie zaznamov sa zvysuje) a pojde to podla mna dovtedy,
> kym tych transkcii a generacii nebude tolko, ze cely system zdochne.
1. O jake kolizi mluvis ? Mnozstvi verzi jednoho radku nema s
pravdepodobnosti kolize nic spolecneho.
2. Mluvis ocividne bez blizsi povedomosti o tom, jak MGA skutecne
funguje. Prodluzovani retezu verzi radku neni apriori problem, a pri
spravne implementaci MGA a tvorbe aplikaci s ohledem na MGA nema na
vykon nijak zasadni vliv.
Firebird Super Server s tim ovsem problem za urcitych okolnosti mel a
stale jeste obcas ma, protoze Borland sprasil garbage collection
thread. S Classicem je situace o necem jinem, a Vulcan by na tom mel
byt jeste o fous lepe. Nicmene to stale nic nevypovida o MGA jako
takove, pouze o konkretni implementaci.
> existencia viacerych generacii zaznamov automaticky znamena
> viac dat v databaze, teda pomalsi pristup, vyssie naroky na pamet,
> atd. Kazda jedna databazova operacia to IMHO pociti.
Zvysovani velikosti databaze automaticky neznamena *vyrazne*
pomalejsi pristup k datum, a uz vubec netusim, jak jsi prisel na
vyssi naroky na pamet.
> nech uz porovnavam vlastnosti alebo konkretne implementacie, nevidim
> ziadne extra vyhody pre MGA
Ze zadne vyhody nevidis ovsem nedokazuje ze zadne neexistuji,
dokazuje to pouze ze ty osobne zadne nevidis.
> myslim si, ze keby to bola naozaj taka skvela zalezitost, ako to su
> popisujem tak uz davno by ta multigeneracna architektura v MS SQL aj v
> Oracli bola. Ale je to len jedna z moznosti, ktora riesi jeden
> ciastkovy (povedal by som okrajovy) problem a preto tam zrejme nie je
> ziadny dovod budovat na tom cely system.
Pokud by MVCC/MGA bylo naprosto zbytecne, pak by se Oracle nikdy
neobtezoval ji do sve databaze doplnit (a to uz pomerne davno). Pokud
vim ja, tak MVCC je oblibenym argumentem pri kazdem tendru kde stoji
Oracle proti DB2 od IBM. A tvrdit, ze MS doplnuje MVCC do SQLServeru
*jen* kvuli pretahovani zakazniku od Oracle je rovnez ponekud
kratkozrake.
Ze neni Oracle, DB2, Sybase nebo MS SQLServer zcela prepracovany na
MGA je vec spise ekonomicka a zpetne kompatibility, nez kvuli
technologicke vyhodnosti zamku a transakcniho logu. Proste se jim
nevyplati to cele predelavat. Nicmene kdyz je MGA podle tebe tak
spatna oproti klasicke, tak mi vysvetli proc rada novych (ktere
zacinaji na zelene louze) implementaci transakci (napr. u MySQL)
pouziva prave MGA/MVCC ?
S pozdravem
Pavel Cisar (ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix(tec)cz
Vse co potrebujete pro Firebird a InterBase
Firebird a GBAK na velkou GDB
[*] Petr Zahradnik <clexpert(zv)clexpert(tec)cz> - 16.10.2004 18:46:33
Stale nemam moc casu, tak zase jen telegraficky:
> Moznost kolize kterou ty apriori vylucujes argumentem, ze data
> podlehajici uzaverce nemuze nikdo jiny menit. Ano, data primo
> podlehajici uzaverce nikoliv (napr. "uzavirane" doklady), ale data
> spriznena grafem zavislosti a potrebna pro zpracovani (napr. nazev
> strediska, zbozi apod. z ciselniku) tomuto omezeni podlehat nemusi.
Kdyz ti to nekdo zmeni pred nebo po uzaverce, tak mas vysledek stejny
jako v prubehu uzaverky - v obou pripadech je to problem.
>> A tak mi tedy rekni, kde muze nastat ten problem. Ja bych rekl, ze ten
>> problem muze spis nastat uplne nekde jinde, nez v SQL databazi. Takze
>> hlavne si uvedom, ze preceneni polozek zbozi v hypermarketu neznamena
>> jen odstartovani jakesi transakce v pocitaci, ale znamena treba take
>> to, ze nejaka frcinka musi vyrazit k regalu a zmenit cedulku, aby si
>> tu novou cenu mohl kazdy precist. Mnohem vetsi problem tedy je ten, ze
>> si nekdo nalozil do voziku danou poozku, pak hodinu jezdi mezi regaly,
>> no a kdyz prijde k pokladne, muze se docela divit.
> Je videt, ze o tom moc nevis. Praxe (v TESCO, ale zarucene i jinde)
> je takova, ze pokud se cena snizuje, upravuje se nejdrive na kase (a
> na samoobsluznych vahach co tisknou cenovky napr. pro zeleninu),
> protoze zakaznik muze byt nesouladem s cenovkou na regalu pouze
> prijemne prekvapen - zaplati mene nez cekal. Pak se tisknou a
> aktualizuji cenovky na regale. Pokud se cena zvysuje, nejprve se
> vytisknou cenovky, a teprve kdyz jsou na regalech, provede se
> preceneni na kase.
Jasne, ze ja jako demagog o tom nic nevim. Muzes mi jako odbornik na
hypermarket vysvetlit, kde tedy nastane ten problem, kdyz v prubehu
transakce zmeny ceny zrovna nekdo neco chce zaplatit na pokladne, a
tedy dostane bud starsi nebo novejsi cenu? Bude jako prijemne
prekvapen nebo nemile prekvapen? Je snad nejaky rozdil mezi tim, kdyz
tam bude hodinu pendlovat a mezitim nekdo zmeni cedulku?
A zaver je tedy jako jaky? Ze mi vysvetlis, jak v Tescu pobihaji
zamestnanci (nebo jezdi na koleckovych bruslich) s cedulkama? Kde je
ten problem v databazi? To mi rekni - kde je problem v transakci
preceneni, kdyz nebude plne serializovana?
>> Telekomunikacni spolecnost - vychazi se z uzavrenych dat, proste delas
>> vyuctovani za urcite obdobi, kdy uz do toho obdobi nevstupuji zadne
>> udaje. Neni tam problem.
> Ted jsi me opravdu pobavil. Ty vydis jen jedinou moznost takoveho
Auau, to to boli, kdyz to vidim ^^^^^^^
> zpracovani - tisk slozenky za obdobi zpetne. Jenze podobnych
> zpracovani je mnoho druhu, vcetne vypoctu okamziteho zbyvajiciho
> kreditu, pruzneho prepocitavani tarifu atd.
No a kdyz znas Tesco, znas taky Go a Twist, jak tam funguji ty
kredity? Jsi si vazne jisty, ze treba SMSky nemuzes precerpat? Zkousel
jsi to?
>> Slovo demagogie od tebe slysim casto. Co ti na to mam rict? Ze kazdy,
>> kdo ma jiny nazor nez ty, je demagog? Ano, i tak si to muzes
>> vysvetlovat, pro me za me... kazdy mame jine argumenty...
> 1. Tady nejde o odlisny nazor, ale o zvolene argumenty.
No vsak jo, ja se ti snazim oponovat a ty mi na to odpovidas, ze je to
demagogie. Ani by me neprekvapilo, kdybys nevedel, co to slovo
znamena, kdyz ho pouzivas v tomto kontextu.
> Argumentace typu letadla jsou zbytecna a nevim co na nich kdo vidi,
> protoze ja nikam nelitam a kamkoliv potrebuji jsem se vzdy dostal
> autem, lodi a vlakem vypovidaji jen o tvych zkusenostech, znalostech
> a potrebach, ale neprinaseji nic k diskuzi o problematice obecneho
> pouziti letadel, a jejich uzitecnosti.
Jaky zase letadlo?
> 2. Tento styl argumentace a nazoru tady od tebe slysime dost casto.
Pavle, prosim prejdi z pluralu na singular - jestli chces zacit flame,
ja na to opravdu nemam cas. Pokud neumis diskutovat na urovni
slusnosti, tak se vazne s tebou nemam o cem bavit. Napadat ostatni
(nejen me, ale treba Erika), to by umel kdekdo. Tahle konference neni
o tom, kdo koho umi rychleji a kvetnateji poslat do prdele, ani o tom,
kdo koho umi nazyvat demagogy nebo co od koho tu casto slysime. Jestli
chces, abych na tvoje nazory nereagoval, tak to jednoduse uplne nahoru
do prispevku napis, a muzes tu mit klidne sve monology a ja si to budu
cist a nebudu komentovat a ty si je zase muzes treba lepit na
nastenku.
> Co ti na to mam rict ? Snad jen ze IT neni jen o tom, co delas a
> znas ty osobne. Za tvymi dvermi zacina cely svet, ktery je vetsi a
> pestrejsi nez si mozna dovedes predstavit.
Ano, s tim ja souhlasim. A proto striktne odmitam tva "jedina
pravdiva" reseni vsech problemu na celem svete. Ja se ti tu snazim
vysvetlit, ze vsechno zalezi na konkretnim pripadu a na konkretnim
database designu a na konkretnich podminkach a na vyhodnoceni moznych
kolizi a jejich pravdepodobnosti a jejich moznych nasledku a na mire
rizika a reseni takovych stavu.
Kdyz si ja nebo kdokoliv jiny neco nedovede predstavit, tak tady
financuji tuhle konferenci prave proto, ze je tu snad dost chytrych
lidi, kteri to vysvetlit dokazi, kteri se v tom pohybuji. A opravdu,
Pavle, nejsem zvedavy na to, abys mi tu nadaval do demagogu a ostatnim
rovnou rikal, ze ze sebe delaji blazny.
Ja se moc rad necham poucit. Ale jestli me chces poucovat o tom, ze ja
jsem demagog, ze argumentuji urcitym priblblym stylem, a ze ostatni ze
sebe delaji blazny, tak se obavam, ze tim nikoho zrovna moc nepoucis.
A me rozhodne ne.
Petr Zahradnik, pocitacovy expert
==========================================================
Petr Zahradnik, Computer Laboratory
web: http://www.clexpert(tec)cz, e-mail: clexpert(zv)clexpert(tec)cz
==========================================================
prekreslovani bez processmessages
[*] Jiri Cincura <diskuze(zv)cincura(tec)net> - 16.10.2004 18:46:33
Martin Burle wrote:
> Ahoj,
> v prubehu deletrvajici akce cosi vypisuji a prekresluji na formulari,
> prubezne volam application.processmessages, aby se zmeny projevily. Coz
> bohuzel zaroven zpusobuje, ze ovladaci prvky reaguji na pripadne akce
> uzivatele, a tomu bych rad zamezil. Nevi nekdo, jak tomu jednoduse
> zabranit? Zatim me napadlo jen odchycovani zprav a likvidovani tech
> "nepovolenych" na urovni application.onMessage. Budu vdecny za kazdou
> radu, jak to udelat jinak, popripade jak se pri prekreslovani bez
> processmessages obejit.
1. Udelat na to vlastni thread!
2. Kdyz uz, tak uz. Disabluj vsechno co jde.
--
Jiri Cincura
e-mail: mailto:jiri(zv)cincura.net; mailto:xcincura(zv)informatics.muni(tec)cz
ICQ#: 314711544
web: http://www.cincura.net; http://photo.cincura.net
---
Nekdo vidi veci, ktere existuji, a pta se - proc?. Ja snim o vecech, ktere
nikdy neexistovaly a ptam se - proc ne? (Robert Kennedy)
prekreslovani bez processmessages
[*] Martin Burle <mburle2(zv)volny(tec)cz> - 16.10.2004 19:00:34
> 1. volat metodu Update formulare nebo daneho prvku (tim se sice obsah
> prekresli ale aplikace bude stale "mrtva")
Diky, uz vim kde jsem delal chybu - vytvarim totiz formular s nejakym
panelem, pak tomu panelu zmenim parenta, takze se mi ten panel zobrazi na
jinem formulari. Nedoslo mi, ze nemohu volat update na ten neviditelny form,
ale na form ktery je ted parent, resp. primo na panel.
MB
Firebird a GBAK na velkou GDB
[*] Winsoft <winsoft(zv)netkosice.sk> - 15.10.2004 15:35:43
> Multigeneracni Architektura uzce souvisi s urovni izolace transakci.
> IB/FB nepouziva zamky a transakcni protokol pro odstineni transakci. V
> databazi je udrzovana historie verzi radku - od nejnovejsi k nejstarsi
> tak, jak byla vytvorena jednotlivymi transakcemi. Diky teto historii
> muze server pristoupit ke kterekoliv verzi radku, ktera je pro konkretni
> transakci relevantni. Mezi vyhody patri velka propustnost systemu,
> zvlaste u transakci s vyssi urovni izolace. Vyhodou je take moznost
> zalohovat databazi za provozu. Nevyhodou je nutnost cisteni DB od
> "spiny", tj. starych verzi radku.
mne sa zda, ze tato architektura riesi problem, ktory by vlastne nemal
byt problemom, lebo transakcie by mali byt kratke. V praxi sa samozrejme
mozu take transakcie zist, ale stavat na nich architekturu databazoveho
servera? MS SQL 2005 bude podporovat Snapshot Isolation,
predpokladam, ze je to nieco obdobne, ak nie to iste viz.
http://www.microsoft.com/technet/prodtechnol/sql/2005/SQL05B.mspx
Erik
prekreslovani bez processmessages
[*] Petr Vones <konference(zv)petrvones(tec)net> - 16.10.2004 18:42:32
From: "Martin Burle" <mburle2(zv)volny(tec)cz>
> v prubehu deletrvajici akce cosi vypisuji a prekresluji na formulari,
> prubezne volam application.processmessages, aby se zmeny projevily. Coz
> bohuzel zaroven zpusobuje, ze ovladaci prvky reaguji na pripadne akce
> uzivatele, a tomu bych rad zamezil. Nevi nekdo, jak tomu jednoduse zabranit?
To je prave jeden z duvodu proc nikdy nevolat Application.ProcessMessages
Korektni reseni jsou vicemene dve, kde to prvni neni uplne idealni:
1. volat metodu Update formulare nebo daneho prvku (tim se sice obsah
prekresli ale aplikace bude stale "mrtva")
2. deletrvajici akci provadet v samostatnem threadu
Petr Vones
prekreslovani bez processmessages
[*] Martin Burle <mburle2(zv)volny(tec)cz> - 16.10.2004 18:34:32
Ahoj,
v prubehu deletrvajici akce cosi vypisuji a prekresluji na formulari,
prubezne volam application.processmessages, aby se zmeny projevily. Coz
bohuzel zaroven zpusobuje, ze ovladaci prvky reaguji na pripadne akce
uzivatele, a tomu bych rad zamezil. Nevi nekdo, jak tomu jednoduse zabranit?
Zatim me napadlo jen odchycovani zprav a likvidovani tech "nepovolenych" na
urovni application.onMessage. Budu vdecny za kazdou radu, jak to udelat
jinak, popripade jak se pri prekreslovani bez processmessages obejit.
MB
Firebird a GBAK na velkou GDB
[*] Pavel Cisar <pcb(zv)atlas(tec)cz> - 16.10.2004 17:58:28
Haj hou1
On 16 Oct 2004 at 15:32, Petr Zahradnik wrote:
> > a) Tato data sdileji struktury (tabulky apod.) s daty ktera do
> > uzaverky nespadaji, nicmene mohou byt diky implementaci db enginu v
> > rozsahu pripadneho konfliku (db stranky, indexy apod.).
>
> To mi prosim blize vysvetli. Ja v tom zadny zavazny nebo neresitelny
> problem nevidim.
Je to problem obecne synchronizace typu MRSW (multiple reader, single
writer) na internich datovych strukturach db enginu, jako jsou napr.
indexy. Pro vyhodnoceni tveho dotazu je treba index ktery je menen z
jine transakce, pricemz ke kolizi dojde i kdyz ty primo vubec
nepotrebujes cist data (z tabulky) ktera jsou menena. Kolizni bod je
synchronizace pristupu k indexu jako takovemu. Problem to muze byt
dle okolnosti i dost zavazny, prostredky aplikace neresitelny.
Problem na ktery poukazuji je v tom, ze aplikacni programator ma
tendenci vnimat data v databazi na jine urovni jejich organizace nez
jak je vnima db engine. Skutecnost, ze ty prostor pro kolizi ze sveho
navrhu schematu nevidis, jeste neznamena, ze neexistuje.
> > b) Na klicova data se vazi dalsi data (napr. ciselniky apod.) na
> > ktera se restrikce nemenitelnosti z titulu podstaty operace (ucetni
> > uzaverka) vztahovat nemusi.
>
> A z toho tedy vyvozujes co?
Moznost kolize kterou ty apriori vylucujes argumentem, ze data
podlehajici uzaverce nemuze nikdo jiny menit. Ano, data primo
podlehajici uzaverce nikoliv (napr. "uzavirane" doklady), ale data
spriznena grafem zavislosti a potrebna pro zpracovani (napr. nazev
strediska, zbozi apod. z ciselniku) tomuto omezeni podlehat nemusi.
Proto musi uzaverka pracovat prinejmensim v izolaci repeatable read
(aby nedochazelo k fluktuaci hodnot v ramci zpracovani), coz u
systemu se zamky okamzite vede ke kolizi cteni a zapisu. U MGA k tomu
dojit nemuze.
> > Jednou za rok nekdy v noci ? I ten nejbeznejsi hypermarket precenuje
> > prubezne i nekolikrat za den, navic rada hypermarketu v podstate bezi
> > v rezimu 7x24. Neprecenuje se sice veskere zbozi, ale v podstate se
> > stale neco precenuje.
>
> A tak mi tedy rekni, kde muze nastat ten problem. Ja bych rekl, ze ten
> problem muze spis nastat uplne nekde jinde, nez v SQL databazi. Takze
> hlavne si uvedom, ze preceneni polozek zbozi v hypermarketu neznamena
> jen odstartovani jakesi transakce v pocitaci, ale znamena treba take
> to, ze nejaka frcinka musi vyrazit k regalu a zmenit cedulku, aby si
> tu novou cenu mohl kazdy precist. Mnohem vetsi problem tedy je ten, ze
> si nekdo nalozil do voziku danou poozku, pak hodinu jezdi mezi regaly,
> no a kdyz prijde k pokladne, muze se docela divit.
Je videt, ze o tom moc nevis. Praxe (v TESCO, ale zarucene i jinde)
je takova, ze pokud se cena snizuje, upravuje se nejdrive na kase (a
na samoobsluznych vahach co tisknou cenovky napr. pro zeleninu),
protoze zakaznik muze byt nesouladem s cenovkou na regalu pouze
prijemne prekvapen - zaplati mene nez cekal. Pak se tisknou a
aktualizuji cenovky na regale. Pokud se cena zvysuje, nejprve se
vytisknou cenovky, a teprve kdyz jsou na regalech, provede se
preceneni na kase.
> >> IMHO, vyhodnoceni obratu na zakaznickem uctu neni zase az tak
> >> kriticka operace. Kdyz dojde k nejake nepresnosti, neni to zase az
> >> takova tragedie.
>
> > Takove veci jako ze nejaka ta nepresnost neni zadna tragedie
> > vykladej kterekoliv telekomunikacni spolecnosti, bance nebo
> > pojistovne.
>
> Telekomunikacni spolecnost - vychazi se z uzavrenych dat, proste delas
> vyuctovani za urcite obdobi, kdy uz do toho obdobi nevstupuji zadne
> udaje. Neni tam problem.
Ted jsi me opravdu pobavil. Ty vydis jen jedinou moznost takoveho
zpracovani - tisk slozenky za obdobi zpetne. Jenze podobnych
zpracovani je mnoho druhu, vcetne vypoctu okamziteho zbyvajiciho
kreditu, pruzneho prepocitavani tarifu atd. Hodne podobnych
zpracovani se provadi *prubezne*. Pri on-line, realtimovem sberu dat
vyzaduje takove zpracovani vylouceni vyskytu phantom rows, coz se bez
snapshotu da zajistit *jen* izolacni urovni Serializable.
> > Ano, u takove aplikace v takovemto scenari na tom mozna nezalezi, to
> > ale neznamena za u dalsich x tisic jinych aplikaci a scenaru na tom
> > rovnez nezalezi. Takoveto argumenty Petre jsou cista demagogie.
>
> Slovo demagogie od tebe slysim casto. Co ti na to mam rict? Ze kazdy,
> kdo ma jiny nazor nez ty, je demagog? Ano, i tak si to muzes
> vysvetlovat, pro me za me... kazdy mame jine argumenty...
1. Tady nejde o odlisny nazor, ale o zvolene argumenty.
Argumentace typu letadla jsou zbytecna a nevim co na nich kdo vidi,
protoze ja nikam nelitam a kamkoliv potrebuji jsem se vzdy dostal
autem, lodi a vlakem vypovidaji jen o tvych zkusenostech, znalostech
a potrebach, ale neprinaseji nic k diskuzi o problematice obecneho
pouziti letadel, a jejich uzitecnosti.
2. Tento styl argumentace a nazoru tady od tebe slysime dost casto.
Co ti na to mam rict ? Snad jen ze IT neni jen o tom, co delas a znas
ty osobne. Za tvymi dvermi zacina cely svet, ktery je vetsi a
pestrejsi nez si mozna dovedes predstavit.
> > 1. Struktura databaze s potrebou nebo nepotrebou serializace nema
> > vubec nic spolecneho. Michas hrusky s pomeranci.
>
> Navrh databaze ma s potrebou nebo nepotrebou serializace spolecneho
> mnoho, rozhodne vic nez si myslis.
Serializace je metoda synchronizace pristupu ke sdilenym zdrojum.
Dokud bude databaze sdilena, bude pravdepodobnost kolize nenulova, a
jeji struktura na tom nic nezmeni. Potrebu serializace odstranis jen
zrusenim sdileni, nikoliv carovanim se strukturou sdileneho zdroje.
> > Struktura databaze ma vliv na miru pravdepodobnosti a cetnosti
> > kolizi.
>
> Vsechno toto spolu uzce souvisi a nemuzes neco vynechat.
Co vynechavam ?
> > Pro zapis do databaze je serializace nezbytna, a zadny db system s
> > transakcemi (a zadna uroven izolace transakci) ti jiny pristip
> > nedovoli, i.e. dva soubezne zapisy na totez misto zpusobi vzdy
> > kolizi, a musi byt serializovany. Rozdil je pouze ve zpusobu
> > vyhodnoceni soft-kolize mezi zapisem a ctenim. Z dovodu praktickych
> > potreb je zaveden kompromis mezi korektnosti dat a urovni
> > paralelizace, pricemz specifika tohoto kompromisu udava uroven
> > izolace transakci.
>
> No ja jen nechapu, co tim chces rici, jako v cem tedy argumentujes.
> Pripominam, ze se bavime o dlouhotrvajicich transakcich, ktere
> zpracovaji tuny dat po dlouho dobu.
Nejde o dlouhe transakce jako takove, jde o transakce ktere data
ctou, a ktere zaroven vyzaduji uroven stability ctenych dat vyssi nez
Read Committed. Shodou okolnosti jde velmi casto prave o transakce
ktere zpracovavaji velke mnozstvi dat, a tudiz trvaji dlouho. To
problem prohlubuje, ale nikoliv zapricinuje. Problem je v
implementaci synchronizace pristupu ke sdilenym datum pomoci zamku,
ktera vede ke kolizim mezi operacemi cteni a zapisu, ke kterym pri
jinem stylu implementace (MGA/MVCC) vubec nedochazi. System s MGA ma
bez potreby zmeny ve strukture transakci a databaze mnohem mensi
procento kolizi nez jine systemy, protoze muze dojit pouze ke kolizim
soubeznych zapisu, ktere nejsou tak caste ani tak rozsahle.
S pozdravem
Pavel Cisar (ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix(tec)cz
Vse co potrebujete pro Firebird a InterBase
Prepis z C++ do Delphi
[*] Jiri Cincura <diskuze(zv)cincura(tec)net> - 15.10.2004 11:53:21
Robert Plzak wrote:
> Zdravim profici...
>
> Mam kod v C++ a potrebuji to dat do Delphi:
> X1 = 32H, X2 = 30H, X3 = 32H, X4 = 3CH
>
> --- C++ ---------------------------------
> Pom1 = (X1 << 4) | (X2 and 0x0F);
> Pom2 = ((X3 << 4) | (X4 and 0x0F)) >> 1; Pom = 2.5 * 12.8 * Pom1 + 0.25
> * Pom2; MHz = Pom - 107;
>
> --- Delphi ------------------------------
> Pom1 := (X1 shl 4) or (X2 and $0F);
> Pom2 := ((X3 shl 4) or (X4 and $0F)) shr 1; Pom := 2.5 * 12.8 * Pom1 +
> 0.25 * Pom2; MHz := Pom - 107; -----------------------------------------
>
> Vysledek by mel byt 92.3 ale neni :o(
> Mam to spatne ?
>
> Dik za radu a pekny den vsem...
>
> R. Plzak
No me v C++ and neprelozi. Pokud dam za and --> & tak 92.3 v zadnem pripade,
pokud --> && tak 92.3 taky ne.
Nejdrive posli spravny kod a pak ti nekdo pomuze.
--
Jiri Cincura
e-mail: mailto:jiri(zv)cincura.net; mailto:xcincura(zv)informatics.muni(tec)cz
ICQ#: 314711544
web: http://www.cincura.net; http://photo.cincura.net
---
Nekdo vidi veci, ktere existuji, a pta se - proc?. Ja snim o vecech, ktere
nikdy neexistovaly a ptam se - proc ne? (Robert Kennedy)
seznam tabulek
[*] Lstiburek Pavel <lstiburek(zv)ceb(tec)cz> - 15.10.2004 12:27:25
Nejjednodusi je
SELECT * FROM INFORMATION_SCHEMA.TABLES
SELECT * FROM INFORMATION_SCHEMA.COLUMS
...
Jinak TADOConnection ma metody GetProcedureNames a GetTableNames.
Pavel
> From: Matejcek Petr [mailto:konference(zv)crhov.komfi(tec)cz]
> poradil by pls nekdo jak se da zjistit jeke tabulky jsou v MS SQL
> databazi ?
> znam pouze nazev databaze a poteebuji vedet co v ni je
ADMIN: MDI aplikace - problem se zaviranim oken
[*] Petr Zahradnik <clexpert(zv)clexpert(tec)cz> - 15.10.2004 13:03:29
Puvodni zprava ze dne 15.10.2004:
> Velice se vsem omlouvam, ale 13. 10. jsem odesilal Adminovi na
> soukr. mail:
>
> [cut]
>
> Teprve dnes se mi podarilo odeslat dotaz (zmenil jsem subj.). A take
> jsem dostal "odpoved". Na predchazejici dotazy mi z konference zadne
> odpovedi nedosly.
No a ja jsem na to odpovidal, ze prispevek do konference prisel, ze
chyba neni v konferenci. No a pak to takhle dopada:
http://www.clexpert(tec)cz/vodicka.jpg
To je seznam prispevku s danym subjektem - dole nesmyslne opakovane
prispevky a nahore odpovedi na nej...
Pak je uplne zbytecne psat administratorovi, kdyz jeho odpoved stejne
ignoruju a posilam stejny prispevek dal a dal, misto abych zjistil,
kde ty prispevky mizi treba v nejakem antispamu...
Petr Zahradnik, pocitacovy expert
==========================================================
Petr Zahradnik, Computer Laboratory
web: http://www.clexpert(tec)cz, e-mail: clexpert(zv)clexpert(tec)cz
==========================================================
Firebird a GBAK na velkou GDB
[*] Winsoft <winsoft(zv)netkosice.sk> - 16.10.2004 16:30:20
> Ruzne implementace MGA (nebo tez MVCC - Multiversion concurrency
> control) to resi ruzne. Firebird provadi odstranovani smeti prubezne,
> takze za bezneho provozu je uroven smeti v databazi velmi nizka.
> Problem muze vyvstat v extremnich pripadech, jako je vymaz x milionu
> zaznamu ktery tuto debatu odstartoval, pripadne vymaz/zmena dat v
> cele tabulce (zpusobuje "skytnuti"). Pokud si je vyvojar vedem
> vlastnosti MGA, pak je schopen system navrhnout tak, aby i tyto
> pripady nezpusobily vazne problemy.
lenze paradoxne to je presne to spracovanie udajov, ktore by
ta MGA architektura mala riesit, koli ktoremu bola robena, nie?
Teda nie kratke transakcie ale dlhe. A neriesi to, ani nemoze riesit,
lebo riesi len polovicu problemu (citanie) a aj to za cenu
znacnych komplikacii - generovania smeti a jeho upratovania.
Ked mam dvoch uzivatelov a kazdy z nich spusti dlhsiu
transakciu v ktorej si budu prepisovat zaznamy, vysledkom
bude, ze nezbehne ani jedna ani druha transakcia. A mozu
tie transakcie spustat aj cely den. Tak co som vlastne vyriesil?
Cely efekt MGA je len v tom, ze namiesto riesenia problemu
sa zameni jeden problem za iny.
> To je omyl, MGA *nema* automaticky vyssi rezii, prave naopak. Za
> bezneho provozu ma rezii mensi, protoze zmenena data neni treba
> odsouvat do externiho uloziste (transakcni protokol), ale v
> optimalnim pripade se presouvaji pouze v ramci teze databazove
> stranky. A i v pripadech kdy je nezbytne data odsunout do jine db
> stranky, snizuje rezii sprava cache. Cely system je navrzen tak, aby
> minimalizoval pocet I/O operaci, ktere jsou hlavnim urcujicim prvkem
> vykonu kazdeho db systemu.
Podla mna je neporovnatelne jednoduchsie a rychlejsie zamknut zaznam
a ukladat pripadne zmeny do trans. logu ako vyrabat a spravovat verzie
zaznamov a indexov.
> MGA neresi *jen* problem kolizi R/O vs. R/W transakci. Predevsim
> zjednodusuje cely system implementace atomicity operaci a izolace
> transakci. MGA totiz nepouziva zamky, cimz se cela implementace
> znacne zjednodusuje. Navic minimalizuje mnozstvi nezbytnych iternich
> datovych struktur, presouvani dat atd. MGA ma i radu pozitivnich
> "vedlejsich" vlastnosti, jako napriklad *okamzite* zotaveni po padu
> systemu (zadne prehravani logu), automaticka podpora on-line
> zalohovani atd. Samozrejmne ma i sva uskali, predevsim nutnost brat
> pri navrhu systemu v uvahu nutnost odstanovani smeti. Pokud ovsem
> clovek vi jak to funguje a co delat pripadne co nedelat, pak s tim
> nejsou problemy.
zamok v RAMke je jedna instrukcia, zamknut zaznam v subore
nemoze byt takisto ziadny velky problem.
> A to myslis vazne ? Samotna operace vyberu a nacteni dat do datasetu
> neprobehne v nulovem case. Pokud maji byt data korektni, pak musi by
> operace provedena v izolacni urovni serializable (nebo alespon
> repeatable read, ale ne vsechny db ji podporuji), coz u databazi
> pouzivajicich zamky vylouci jakekoliv zmeny dat v ctenych tabulkach
> po dobu behu transakce, tedy tvoje operace naplneni datasetu
> zablokuje ostatni kteri chteji zmenu provest. Rovnez jakakoliv zmena
> v datech ktere chces cist po odstartovani tve transakce zablokuje
> tvou transakci. MGA nikoho nezablokuje, a je tedy jedno, zda si to
> nactes do datasetu a pak to vytisknes z pameti, nebo to budes
> prubezne sosat a tisknou z databaze. Bez MGA to typicky musis delat
> pres dataset, aby jsi minimalizoval dobu behu sve transakce, a i
> tehdy muzes mit problemy (pokud potrebujes vyloucit phantom rows), a
> tedy dobu po kterou blokujes ostatni, s MGA je to jedno.
takze namiesto kratkej transkcie mozem pouzit dlhu ale riskujem
vytvaranie dalsich zaznamov a spomalovanie systemu. A kazda
taka transkcia bude zvysovat a zvysovat reziu (a nie linearne, lebo
riziko kolizie zaznamov sa zvysuje) a pojde to podla mna dovtedy,
kym tych transkcii a generacii nebude tolko, ze cely system zdochne.
> Na ukor jakych operaci ? Zmeny ? Vkladani ? Vymazu ? Jakych operaci ?
> Chovani transakci u systemu s MGA i u systemu bez MGA je obecne
> naprosto stejne, s tim rozdilem, ze implementace nevyuzivajici zamky
> (MGA) umoznuje, aby operace cteni neblokovala zmenu dat (je-li to
> pozadovano), a operace zmeny nezablokovala cteni (opet, je-li to
> pozadovano). Bez MGA nemas na vyber, a musis hledat reseni problemu
> mimo databazi (nacitani do datasetu apod.).
existencia viacerych generacii zaznamov automaticky znamena
viac dat v databaze, teda pomalsi pristup, vyssie naroky na pamet,
atd. Kazda jedna databazova operacia to IMHO pociti.
> > su to dost silne slova na databazy ako MS SQL a Oracle
> > ale mas samozrejme pravo na svoj nazor. Mozes uviest
> > aj nejake porovnania vykonu tejto architektury s inymi
> > architeturami napr. MS SQL?
>
> Neda se porovnovat vykon architektury, ale pouze vykon serveru. Na
> vykon serveru ma vliv mnoho veci, nejen konkretni implementace
> architektury transakci, takze vykon architektury se neda objektivne
> zmerit, a tudiz ani srovnavat. Daji se srovnavat pouze vlastnosti.
nech uz porovnavam vlastnosti alebo konkretne implementacie, nevidim
ziadne extra vyhody pre MGA
> Nicmene ja nezpochybnuji pouzitelnost a funkcnost MVCC implementace u
> Oracle a MS. Muj nazor na implementaci MVCC u Oracle a SQLServeru
> 2005 se opira o fakt, ze MVCC je u nich nabastlena na zcela odlisnou
> architekturu zamku a transakcniho logu. Je to jako ucit stareho psa
> novym kouskum, na ktere neni fyziologicky staveny. Da se to, ale neni
> to proste ono. Napr. u Oracle je MVCC implementovana na urovni celych
> db stranek, tedy do transakcniho logu je pri kazde zmene db stranky
> ulozena predchozi verze teto stranky. engine pak pro transakce v MVCC
> rezimu (je to jen jedna spec. uroven izolace, nikoliv obecna
> vlastnost systemu) dohleda prislusnou verzi stranky v logu. Jaky to
> ma dopad na spotrebu diskoveho prostoru netreba zduraznovat, nemluve
> o dopad na spravce vyrovnavaci pameti, pocet I/O operaci atd.. A to
> se zde vubec nebavime o integraci MVCC do zbytku systemu z pohledu
> vyvojare aplikaci, ktera vypada jako kdyz se michaji hrusky s mrkvi.
myslim si, ze keby to bola naozaj taka skvela zalezitost, ako to su
popisujem
tak uz davno by ta multigeneracna architektura v MS SQL aj v Oracli bola.
Ale je to len jedna z moznosti, ktora riesi jeden ciastkovy (povedal by som
okrajovy) problem a preto tam zrejme nie je ziadny dovod budovat na tom
cely system.
Erik
Firebird a GBAK na velkou GDB
[*] Pavel Cisar <pcb(zv)atlas(tec)cz> - 15.10.2004 11:15:19
Haj hou!
Nejak mi to po ranu nemysli :-) Zapomel jsem dodat, ze pri vymazu
(ale i pri zmene) velkeho mnozstvi dat z tabulky je nejvetsi problem
s indexy. Odstranovani smeti v podobe starych verzi radku se da jeste
prezit, pokud to neni Super Server a server je zaroven pod zatezi od
vice uzivatelu (pak muze dojit k "vyhladoveni" GC vlakna), ale v
odstraneni smeti z indexu. Proto je nanejvyse vhodne po hromadnem
vymazu nebo zmene cca 1/3 radku v tabulce ihned deaktivovat a
opetovne aktivovat indexy (u FK je nutne "zacvicit" s constraints, PK
se da vetsinou preskocit). Pri takovych operacich by s db nemel nikdo
dalsi pracovat, anzto je to bepecnejsi a predevsim mnohem rychlejsi.
S pozdravem
Pavel Cisar (ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix(tec)cz
Vse co potrebujete pro Firebird a InterBase
Stinovani FB databaze
[*] Andreas Bednarek <bednarek(zv)digitus(tec)cz> - 16.10.2004 15:34:15
Ahoj vsem,
mam nejakou nejasnost ohledne stinovani FB databaze, muzete-li mi poradit...
Rekneme, ze mam hlavni db soubor 'd:\data.fdb'
vytvorim shadow v automatickem rezimu a conditional na 'e:\data.shd'
CREATE SHADOW 1 AUTO CONDITIONAL 'e:\data.shd'
V pripade selhani disku C ocekavam, ze
a) 'e:\data.shd' prevezme ulohu primarni databaze bez preruseni spojeni k DB (AUTO)
b) vytnori se novy stinovy soubor (CONDITIONAL)
Otazky
ad a) Tohle bude fungovat zrejme do te doby, nez se klient od DB odpoji, mam pravdu? Nebot pri novem pokusu o pripojeni budu pravdepodobne zadat o 'd:\data.fdb', ktery neni pristupny. Nebo je to reseno jeste jinak?
ad b) kde a s jakym nazvem se ten novy stinovy soubor vytvori?
Pokud vite, diky!
A.B.Firebird a GBAK na velkou GDB
[*] Petr Zahradnik <clexpert(zv)clexpert(tec)cz> - 16.10.2004 15:32:14
Pavle, nemam zrovna moc casu, tak jen telegraficky to nejdulezitejsi:
> MGA/MVCC tenhle problem znacne zjednodusuje, protoze eliminuje
> nejcastejsi zdroj problemu spojeny s dlouhymi transakcemi.
Ja hlavne vubec nereaguji na MGA/MVCC, jestli sis vsiml. Ja jen
reaguji na ty argumenty k dlouhotrvajicim transakcim...
>> IMHO, kdyz delas ucetni uzaverku, nema nikdo co ve starych datech
>> hrabat. Tohle je operace, ktera se delaji v okamziku, kdy je prace s
>> konkretnimi daty hotova. Jinak si nedovedu predstavit, na co by ti byla
>> ucetni zaverka, kdyz by ti tam nekdo neco pod rukou zmenil. Notabene na
>> co by ti byla i tehdy, kdyz by ti to nekdo zmenil treba pul hodiny nebo
>> pul roku po te uzaverce. Takova ucetni uzaverka je ti na dve veci v
>> obou techto pripadech, takze nepomuze ani serializace.
> 1. Pokud by jsi zuzil problem pouze na data spadajici primo do
> uzaverky, pak by jsi mel i pravdu, ale...
> a) Tato data sdileji struktury (tabulky apod.) s daty ktera do
> uzaverky nespadaji, nicmene mohou byt diky implementaci db enginu v
> rozsahu pripadneho konfliku (db stranky, indexy apod.).
To mi prosim blize vysvetli. Ja v tom zadny zavazny nebo neresitelny
problem nevidim.
> b) Na klicova data se vazi dalsi data (napr. ciselniky apod.) na
> ktera se restrikce nemenitelnosti z titulu podstaty operace (ucetni
> uzaverka) vztahovat nemusi.
A z toho tedy vyvozujes co?
> 2. Ucetni uzaverka byl jen priklad obecneho typu zpracovavane ulohy
> ktery je ostatnim blizky. Jsou i jine ulohy obdobneho charakteru
> ktere nemaji tak jednoznacne restrikce jako *ucetni* uzaverka. Navic
> se konkretni situace muze v detailech lisit od predpokladaneho
> standardu pro danou operaci.
Ano, ja to chapu. Ale uvedl jsi tento priklad a ja na nej zareagoval.
Je to spatne?
>> IMHO, kdyz precenujes hromadne sklad (protoze kdyz delas jednu
>> polozku, netrva to dlouho, predpokladam, ze tim myslis cely sklad
>> hypermarketu), nema nikdo co v takovych datech hrabat. Predpokladam,
>> ze to delas jednou za rok nekdy v noci, protoze jinak si nedovedu ani
>> predstavit, ze tam nahodis serializaci a nechas zakazniky stat 4,5
>> hodiny u pokladen, nez ti tato transakce dojede...
> Jednou za rok nekdy v noci ? I ten nejbeznejsi hypermarket precenuje
> prubezne i nekolikrat za den, navic rada hypermarketu v podstate bezi
> v rezimu 7x24. Neprecenuje se sice veskere zbozi, ale v podstate se
> stale neco precenuje.
A tak mi tedy rekni, kde muze nastat ten problem. Ja bych rekl, ze ten
problem muze spis nastat uplne nekde jinde, nez v SQL databazi. Takze
hlavne si uvedom, ze preceneni polozek zbozi v hypermarketu neznamena
jen odstartovani jakesi transakce v pocitaci, ale znamena treba take
to, ze nejaka frcinka musi vyrazit k regalu a zmenit cedulku, aby si
tu novou cenu mohl kazdy precist. Mnohem vetsi problem tedy je ten, ze
si nekdo nalozil do voziku danou poozku, pak hodinu jezdi mezi regaly,
no a kdyz prijde k pokladne, muze se docela divit.
Takze precenovani zbozi v hypermarketu opet neni ten spravny pripad.
Vstupuje tam do hry vice faktoru, pricemz vlastni zmena ceny je oproti
ostatnim fyzickym kolizim na prodejne zcela zanedbatelna.
>> IMHO, vyhodnoceni obratu na zakaznickem uctu neni zase az tak
>> kriticka operace. Kdyz dojde k nejake nepresnosti, neni to zase az
>> takova tragedie.
> Takove veci jako ze nejaka ta nepresnost neni zadna tragedie
> vykladej kterekoliv telekomunikacni spolecnosti, bance nebo
> pojistovne.
Telekomunikacni spolecnost - vychazi se z uzavrenych dat, proste delas
vyuctovani za urcite obdobi, kdy uz do toho obdobi nevstupuji zadne
udaje. Neni tam problem.
Banka - to je prilis neobecny pripad a tam se zrejme plne serializaci
v urcitych fazich nevyhnes, nicmene asi ne kazdy tu dela soft pro
banky. I kdyz bych ti taky mohl vypravet, co se leckdy na ucte
prihodi...
Pojistovna - tim myslis konkretne co? Kde je to kriticke misto?
>> Pokud takove vyhodnoceni obratu delas proto, ze prave mas na
>> drate zakaznika, ktery zadoni o vetsi rabat, a ty se chces presvedcit,
>> kolik odebral za posledni 3 mesice, pravdepodobne ti je uplne jedno,
>> ze mu nekde ve skladu zrovna ted delaji vydejku... proste nic se
>> nestane, kdyz tam nebude.
> Ano, u takove aplikace v takovemto scenari na tom mozna nezalezi, to
> ale neznamena za u dalsich x tisic jinych aplikaci a scenaru na tom
> rovnez nezalezi. Takoveto argumenty Petre jsou cista demagogie.
Slovo demagogie od tebe slysim casto. Co ti na to mam rict? Ze kazdy,
kdo ma jiny nazor nez ty, je demagog? Ano, i tak si to muzes
vysvetlovat, pro me za me... kazdy mame jine argumenty...
> 1. Struktura databaze s potrebou nebo nepotrebou serializace nema
> vubec nic spolecneho. Michas hrusky s pomeranci.
Navrh databaze ma s potrebou nebo nepotrebou serializace spolecneho
mnoho, rozhodne vic nez si myslis.
> Struktura databaze ma vliv na miru pravdepodobnosti a cetnosti
> kolizi.
Vsechno toto spolu uzce souvisi a nemuzes neco vynechat.
> Pro zapis do databaze je serializace nezbytna, a zadny db system s
> transakcemi (a zadna uroven izolace transakci) ti jiny pristip
> nedovoli, i.e. dva soubezne zapisy na totez misto zpusobi vzdy
> kolizi, a musi byt serializovany. Rozdil je pouze ve zpusobu
> vyhodnoceni soft-kolize mezi zapisem a ctenim. Z dovodu praktickych
> potreb je zaveden kompromis mezi korektnosti dat a urovni
> paralelizace, pricemz specifika tohoto kompromisu udava uroven
> izolace transakci.
No ja jen nechapu, co tim chces rici, jako v cem tedy argumentujes.
Pripominam, ze se bavime o dlouhotrvajicich transakcich, ktere
zpracovaji tuny dat po dlouho dobu.
Petr Zahradnik, pocitacovy expert
==========================================================
Petr Zahradnik, Computer Laboratory
web: http://www.clexpert(tec)cz, e-mail: clexpert(zv)clexpert(tec)cz
==========================================================
IBO cislo TCP portu WAS: Je spusteny FB1.5? (druh
[*] Milan Tomes <delphi(zv)haida(tec)cz> - 15.10.2004 13:31:32
Nevim proc chces tohle zkouset pres IBO - ja osobne to zkousim pres Synapsi.
Jde proste jen o to, zda se navaze spojeni na port 3050. Pokud ano, tak
pristoupim k dalsimu kroku.
Alternativu TIBDatabaseInfo neznam, ale rad bych ji nasel neb mame IBO take
koupene.
S pozdravem
Milan Tomes
> [mailto:delphi-l-owner(zv)clexpert(tec)cz]On Behalf Of Andreas Bednarek
> Sent: Friday, October 15, 2004 12:49 PM
>
> > 1. snazim se o pripojeni na port 3050 (popr. jiny dle konfigurace) -
> > tusim,
> > ze je to primo doporuceny postup v dokumentaci
>
> a v tomhle mam trochu problem, protoze se mi nedari specifikovat
> cislo portu
> v connection string. vypise mi to mmj. 'undefined service 3050/tcp'. Kdyz
>
> > 2. Verzi serveru s pripade korektniho pripojeni zjistit pomoci
> > TIBDatabaseInfo z IBX - property Version
> >
>
> Je v IBO neco podobneho? (...uz to hledam...) Pripadne opet, slo
> by to pres nejake API?Firebird a GBAK na velkou GDB
[*] Pavel Cisar <pcb(zv)atlas(tec)cz> - 16.10.2004 15:04:12
Haj hou!
On 16 Oct 2004 at 0:45, Petr Zahradnik wrote:
> Mimochodem, Pavle, ted jsem si precetl jeste ten zbytek, tak nekolik
> reakci:
>
> > 1. Ne vsechny transakce mohou byt kratke.
>
> Kazdy rozumny (dle meho nazoru) vyvojar ti rekne (a v kazde seriozni
> technicke literature o relacnich databazich se doctes), ze transakce
> ma byt co mozna nejkratsi.
Ano, to se rika a pise, a sam to tvrdim a pisu taky :-) Problem je v
tom, ze ostatni vyvojari to casto ctou jinak nez jak je to napsano.
Pozadavek na co nejkratsi transakce znamena doslova toto:
Transakce by mela trvat nejkratsi moznou dobu nutnou na provedeni
pozadovane operace.
Pricemz "nejkratsi doba nezbytna pro provedeni operace" neni nijak
kvantifikovana, a klidne muze byt i par minut, hodin nebo dnu.
Bohuzel hodne lidi si to nejakym myslenkovym zkratem prelozi tak, ze
transakce trvajici dele nez par vterin jsou spatne, coz je naprosta
pitomost. Ze dlouhotrvajici transakce (prakticky jakehokoliv typu,
tedi i ciste R/O) u db enginu vyuzivajicich zamky a transakcni log
vetsinou vyrazne snizuji propustnost systemu a je tedy nutne nachazet
externi (z pohledu db) reseni a zkracovat je vice nez je z navrhu
systemu logicke, je problem implementace db enginu, nikoliv transakci
obecne.
MGA/MVCC tenhle problem znacne zjednodusuje, protoze eliminuje
nejcastejsi zdroj problemu spojeny s dlouhymi transakcemi.
> > Zatimco transakce modifikujici data jsou typicky kratke, transakce
> > ktere data zpracovavaji
>
> Takze data, ktera data zpracovavaji, data nemodifikuji? Ja myslel, ze
> kazda transakce hlavne modifikuje data...
1. Data jina data nezpracovavaji, data zpracovava kod v ramci
transakce.
2. Ne kazda transakce data musi cist, muze jen zapisovat (kdyz
ukladam zmeny provedene uzivatelem, nemusim vzdy hned neco cist), a
ne kazda transakce musi data zapisovat, muze je jen cist (napr. pro
tisk sestav neni typicky nutne nikam nic zapisovat). A pak jsou
transakce ktere ctou i zapisuji.
3. Pomer poctu jednotlivych typu transakci v ramci aplikace zalezi na
typu a zamereni aplikace a zpusobu specifikace transakci. Pokud tve
vlastni systemy vyzaduji, pripadne je navrhujes tak ze pouzivaji
pouze transakce ktere ctou i zapisuji, neznamena to, ze nic jineho
neexistuje, ale pouze ze v uzce vymezene oblasti ve ktere se
pohybujes jsi se s nicim jinym nesetkal.
> > (napr. ucetni uzaverka, preceni skladu, vyhodnoceni obratu na
> > zakaznickem uctu apod.) jsou casto i velmi dlouhe.
>
> IMHO, kdyz delas ucetni uzaverku, nema nikdo co ve starych datech
> hrabat. Tohle je operace, ktera se delaji v okamziku, kdy je prace s
> konkretnimi daty hotova. Jinak si nedovedu predstavit, na co by ti byla
> ucetni zaverka, kdyz by ti tam nekdo neco pod rukou zmenil. Notabene na
> co by ti byla i tehdy, kdyz by ti to nekdo zmenil treba pul hodiny nebo
> pul roku po te uzaverce. Takova ucetni uzaverka je ti na dve veci v
> obou techto pripadech, takze nepomuze ani serializace.
1. Pokud by jsi zuzil problem pouze na data spadajici primo do
uzaverky, pak by jsi mel i pravdu, ale...
a) Tato data sdileji struktury (tabulky apod.) s daty ktera do
uzaverky nespadaji, nicmene mohou byt diky implementaci db enginu v
rozsahu pripadneho konfliku (db stranky, indexy apod.).
b) Na klicova data se vazi dalsi data (napr. ciselniky apod.) na
ktera se restrikce nemenitelnosti z titulu podstaty operace (ucetni
uzaverka) vztahovat nemusi.
2. Ucetni uzaverka byl jen priklad obecneho typu zpracovavane ulohy
ktery je ostatnim blizky. Jsou i jine ulohy obdobneho charakteru
ktere nemaji tak jednoznacne restrikce jako *ucetni* uzaverka. Navic
se konkretni situace muze v detailech lisit od predpokladaneho
standardu pro danou operaci.
> IMHO, kdyz precenujes hromadne sklad (protoze kdyz delas jednu
> polozku, netrva to dlouho, predpokladam, ze tim myslis cely sklad
> hypermarketu), nema nikdo co v takovych datech hrabat. Predpokladam,
> ze to delas jednou za rok nekdy v noci, protoze jinak si nedovedu ani
> predstavit, ze tam nahodis serializaci a nechas zakazniky stat 4,5
> hodiny u pokladen, nez ti tato transakce dojede...
Jednou za rok nekdy v noci ? I ten nejbeznejsi hypermarket precenuje
prubezne i nekolikrat za den, navic rada hypermarketu v podstate bezi
v rezimu 7x24. Neprecenuje se sice veskere zbozi, ale v podstate se
stale neco precenuje.
> IMHO, vyhodnoceni obratu na zakaznickem uctu neni zase az tak kriticka
> operace. Kdyz dojde k nejake nepresnosti, neni to zase az takova
> tragedie.
Takove veci jako ze nejaka ta nepresnost neni zadna tragedie vykladej
kterekoliv telekomunikacni spolecnosti, bance nebo pojistovne.
> Pokud takove vyhodnoceni obratu delas proto, ze prave mas na
> drate zakaznika, ktery zadoni o vetsi rabat, a ty se chces presvedcit,
> kolik odebral za posledni 3 mesice, pravdepodobne ti je uplne jedno,
> ze mu nekde ve skladu zrovna ted delaji vydejku... proste nic se
> nestane, kdyz tam nebude.
Ano, u takove aplikace v takovemto scenari na tom mozna nezalezi, to
ale neznamena za u dalsich x tisic jinych aplikaci a scenaru na tom
rovnez nezalezi. Takoveto argumenty Petre jsou cista demagogie.
> > 3. Jediny zpusob jak zajistit stabilitu dat v ramci transakce je
> > striktni serializace transakci, tedy nulova paralelnost zpracovani.
>
> Jiste, to mas pravdu. Zrovna jako treba jedina bezpecna sifra je
> Vernamova sifra, kde je klic stejne dlouhy jako data a opravdu
> nahodny. Jenze to neni snadno dosazitelne, proto se pouzivaji jine
> sifrovaci algoritmy, ktere nejsou 100% bezpecne, ale lze pristoupit na
> danou miru bezpecnosti. Kdyz budes vyhodnocovat napriklad bezpecnost
> site (ale i treba sveho bytu), take nikdy nebude 100% bezpecna, ale
> musis pristoupit na urcitou miru rizika, ktera je pro tebe prijatelna.
>
> Stejne je to s transakcemi. Kdyz pristoupis na serializaci, pak budes
> mit misto SQL Serveru pomale orezavatko. Proto nedelaji database
> design programy, ale lidi, kteri musi databazi navrhnout tak, aby
> nebyla nutna serializace, pripadne aby se maximalne omezila, pricemz
> se prihlizi k tomu, ze kolize nebo nepresnost muze nastat, ovsem
> hlavne jde o to, jak moc velky problem to bude, a jak pravdepodobne to
> bude. Navrhnout databazi s tim, ze se nastavi serializace, to umi
> kazdy trubka. Ale navrhnout databazi tak, aby byla dostatecne vykonna
> a presto co nejmene kolizni, to uz neni tak jednoduche.
1. Struktura databaze s potrebou nebo nepotrebou serializace nema
vubec nic spolecneho. Michas hrusky s pomeranci. Struktura databaze
ma vliv na miru pravdepodobnosti a cetnosti kolizi. Pro zapis do
databaze je serializace nezbytna, a zadny db system s transakcemi (a
zadna uroven izolace transakci) ti jiny pristip nedovoli, i.e. dva
soubezne zapisy na totez misto zpusobi vzdy kolizi, a musi byt
serializovany. Rozdil je pouze ve zpusobu vyhodnoceni soft-kolize
mezi zapisem a ctenim. Z dovodu praktickych potreb je zaveden
kompromis mezi korektnosti dat a urovni paralelizace, pricemz
specifika tohoto kompromisu udava uroven izolace transakci.
Protoze system se zamky neumoznuje rozumne pouzitelnou izolaci cteni
a zapisu v podobe shapshotu pro cteni, a ze je tudiz nutne hledat
alternativni reseni problemu v aplikaci, casovani a strukture
transakci atd. jeste neznamena, ze pouziti techto nouzovych reseni je
normalni a ze to tak ma byt.
> Ja tvrdim jednu vec - je lepsi s kolizemi pocitat, byt na ne pripraven
> a umet je resit, nez se jim snazit za kazdou cenu vyhnout (tedy i za
> tu cenu, ze udelas z SQL Serveru to serializovane orezavatko).
Mas i nemas pravdu. Mas pravdu v pripade kolizi mezi zapisy, ale
nikoliv pri kolizi cteni a zapisu. Kolize zapisu je normalni vec, pri
dobrem navrhu databaze a transakci neni nijak casta, a neni problem
je poresit. Kolize cteni a zapisu je implementacni artefakt db enginu
*bez* MVCC/MGA, a s MGA nemusi byt ani zdaleka tak casty jak v realu
je bez MGA. Vyvojari kteri nepouzivaji MGA engine se toto omezeni
casem naucili nejak obchazet, nicmene ne vzdy se to da vyresit na
100% bez serializace. MGA tento resi prave problem jednoduse, ciste a
elegantne bez potreby serializace.
> > Interni "ucetnictvi" db enginu umoznuje paralelismus jen do prvni
> > kolize. Zatimco cteci transakce se vzajemne neobtezuji, a mohou tedy
> > stastne a spokojene bezet soucasne na plne obratky, staci jedna
> > ktera zapisuje do oblasti zajmu ctecich transakci, a vsechno jde do
> > haje.
>
> Ne, ne, vsechno nejde do haje - v pripade, ze s tim pocitas a v
> pripade, ze to je proste dane procento, kdy to lze tolerovat a skody
> nejsou velike.
>
> > Z pohledu architektury je to jak u Oracle tak u MS obycejny bastl.
>
> Jo! Fuj! Nejlepsi je Firebird, ze? :-)
Nic takoveho jsem nenapsal. Nicmene Firebird (nejen) je na MGA
postaven, kdezto Oracle a MS SQLServer nikoliv, tudiz je do nich MVCC
"nejak" dobastlene. Jejich puvodni architektura na MVCC proste neni
stavena.
Je to podobne, jako kdyby VW utesnil Skodovku, pridal lodni sroub a
prohlasil to za skvely novy vuz ktery je i zavodni jachtou. Asi bude
plavat, nejspis se asi nepotopi, ale poradna lod to nebude. Navic to
urcite ovlivni i jeho jizdni schopnosti jako normalniho auta. O
problemech se zaskolovanim obsluhy nemluve.
S pozdravem
Pavel Cisar (ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix(tec)cz
Vse co potrebujete pro Firebird a InterBase
C++ a Delphi v jednom souboru
[*] Jan Rizek <jan_rizek(zv)centrum(tec)cz> - 16.10.2004 14:54:11
Rekl bych ze by se na to dali pouzit direktivy kompilatoru -
{$IFDEF CPLUSPLUS}
ceckovy kod....
{$ENDIF}
{$IFDEF DELPHI}
delphi...
{$ENDIF}
Pokud C++ podporuje stejne direktivy kompilatoru..
> Zdravim konferenci,
> nekde jsem slysel, ze jde do 1 souboru napsat zdrojak pro Pascal/Delphi a
> C++. Proste mi jde o to aby, kdyz ten soubor prelozim v Delphi, aby
> prekladac "nevidel" na C++ kod a naopak.Odhaduju ze se to dela pomoci
> komentaru, ale jak presne nemam tuseni. Nevite nekdo jak na to? Nejlepe
> priklad
>
> WinXP SP1, Delphi 6 Ent., C++ Builder 5
>
> Jakub Cermak
> ja.cermi(zv)centrum(tec)cz
> ICQ 159971304
> http://cermi.wz(tec)cz
>
>
>
>
TStringList CustomSort dle datumu
[*] Viktor Marek <viktor(zv)mbox.vol(tec)cz> - 16.10.2004 14:30:09
Zdravim
Do StringListu nacitam z adresare nazvy souboru dle masky. Poradi nekdo jak
ve StringListu nazvy souboru setridit dle datumu vzniku souboru?
Diky
Viktor Marek
viktor(zv)vol(tec)cz
select do souboru
[*] Matejcek Petr <konference(zv)crhov.komfi(tec)cz> - 15.10.2004 15:15:41
DD,
mam vypsany nejaky select v DBGridu a potreboval bych ho nasypat do
textoveho souboru
poradil by pls nekdo jak na to ?
diky PM
Firebird a GBAK na velkou GDB
[*] Pavel Cisar <pcb(zv)atlas(tec)cz> - 16.10.2004 12:36:00
Haj hou!
On 15 Oct 2004 at 23:47, Winsoft wrote:
> > 1. Ne vsechny transakce mohou byt kratke. Zatimco transakce
> > modifikujici data jsou typicky kratke, transakce ktere data
> > zpracovavaji (napr. ucetni uzaverka, preceni skladu, vyhodnoceni
> > obratu na zakaznickem uctu apod.) jsou casto i velmi dlouhe.
>
> a teraz zhodnotme ako tento problem riesi MGA: poskytne sice
> snapshot ale za cenu nasledneho zdlhaveho zbierania narobeneho
> smetia.
Ruzne implementace MGA (nebo tez MVCC - Multiversion concurrency
control) to resi ruzne. Firebird provadi odstranovani smeti prubezne,
takze za bezneho provozu je uroven smeti v databazi velmi nizka.
Problem muze vyvstat v extremnich pripadech, jako je vymaz x milionu
zaznamu ktery tuto debatu odstartoval, pripadne vymaz/zmena dat v
cele tabulce (zpusobuje "skytnuti"). Pokud si je vyvojar vedem
vlastnosti MGA, pak je schopen system navrhnout tak, aby i tyto
pripady nezpusobily vazne problemy.
> Takze ked robim uzavierku, najprv usetrim cas a neskor ho
> stratim. Aky je potom z toho celkovy efekt? Nehovoriac o tom,
> ze v dosledku takejto architektury ma system automaticky vecsiu
> reziu vlastne pri kazdej databazovej operacii.
To je omyl, MGA *nema* automaticky vyssi rezii, prave naopak. Za
bezneho provozu ma rezii mensi, protoze zmenena data neni treba
odsouvat do externiho uloziste (transakcni protokol), ale v
optimalnim pripade se presouvaji pouze v ramci teze databazove
stranky. A i v pripadech kdy je nezbytne data odsunout do jine db
stranky, snizuje rezii sprava cache. Cely system je navrzen tak, aby
minimalizoval pocet I/O operaci, ktere jsou hlavnim urcujicim prvkem
vykonu kazdeho db systemu.
> Mne sa zda byt vyhodnejsie minimalizovat transakcne problemy komplexne,
> nie len zobrat jeden pripad (podla mna vobec nie typicky pripad)
> pouzitia a na nom vybudovat architekturu databazy.
MGA neresi *jen* problem kolizi R/O vs. R/W transakci. Predevsim
zjednodusuje cely system implementace atomicity operaci a izolace
transakci. MGA totiz nepouziva zamky, cimz se cela implementace
znacne zjednodusuje. Navic minimalizuje mnozstvi nezbytnych iternich
datovych struktur, presouvani dat atd. MGA ma i radu pozitivnich
"vedlejsich" vlastnosti, jako napriklad *okamzite* zotaveni po padu
systemu (zadne prehravani logu), automaticka podpora on-line
zalohovani atd. Samozrejmne ma i sva uskali, predevsim nutnost brat
pri navrhu systemu v uvahu nutnost odstanovani smeti. Pokud ovsem
clovek vi jak to funguje a co delat pripadne co nedelat, pak s tim
nejsou problemy.
> > 2. Transakce nejen zajistuji atomicitu zmen, ale *predevsim*
> > stabilitu datoveho pohledu. Nenech se zmylit skutecnosti, ze
> > transakce provadejici zmeny potrebuji spise atomicitu operaci,
> > protoze transakce zpracovavajici data vyzaduji predevsim prave
> > stabilitu dat.
>
> ano, samozrejme, ale snapshot si viem zabezpecit aj sam - nacitam
> data z databazy niekde do datasetu (myslim ten v .NET) a mam
> snapshot. A nech ta uroven v databaze je hoci aj serializovana
> ak to potrebujem.
A to myslis vazne ? Samotna operace vyberu a nacteni dat do datasetu
neprobehne v nulovem case. Pokud maji byt data korektni, pak musi by
operace provedena v izolacni urovni serializable (nebo alespon
repeatable read, ale ne vsechny db ji podporuji), coz u databazi
pouzivajicich zamky vylouci jakekoliv zmeny dat v ctenych tabulkach
po dobu behu transakce, tedy tvoje operace naplneni datasetu
zablokuje ostatni kteri chteji zmenu provest. Rovnez jakakoliv zmena
v datech ktere chces cist po odstartovani tve transakce zablokuje
tvou transakci. MGA nikoho nezablokuje, a je tedy jedno, zda si to
nactes do datasetu a pak to vytisknes z pameti, nebo to budes
prubezne sosat a tisknou z databaze. Bez MGA to typicky musis delat
pres dataset, aby jsi minimalizoval dobu behu sve transakce, a i
tehdy muzes mit problemy (pokud potrebujes vyloucit phantom rows), a
tedy dobu po kterou blokujes ostatni, s MGA je to jedno.
> a myslis, ze snapshot citanie je akurat ta kriticka operacia ktoru treba
> riesit? Na ukor inych operacii?
Na ukor jakych operaci ? Zmeny ? Vkladani ? Vymazu ? Jakych operaci ?
Chovani transakci u systemu s MGA i u systemu bez MGA je obecne
naprosto stejne, s tim rozdilem, ze implementace nevyuzivajici zamky
(MGA) umoznuje, aby operace cteni neblokovala zmenu dat (je-li to
pozadovano), a operace zmeny nezablokovala cteni (opet, je-li to
pozadovano). Bez MGA nemas na vyber, a musis hledat reseni problemu
mimo databazi (nacitani do datasetu apod.).
> > 4. Clanek na ktery se odvolavas pouze dokazuje, ze MGA ma sve
> > opodstatneni a vyplati se na ni *postavit db engine*, protoze i MS
> > SQLServer ji bude nakonec podporovat. Nikoliv ovsem jako InterBase,
> > Firebird, PostgreSQL nebo MySQL, ale ve stylu Oracle, coz znamena
> > *specialni* uroven izolace a vyzobavani dat z transakcniho logu (i.e.
> > starsi verze jsou v podstate ulozeny externe mimo databazi).
> > Implementace MS sice vypada rozumneji nez ta od Oracle, ale i tak mam
> > sve pochybnosti. Z pohledu architektury je to jak u Oracle tak u MS
> > obycejny bastl.
>
> su to dost silne slova na databazy ako MS SQL a Oracle
> ale mas samozrejme pravo na svoj nazor. Mozes uviest
> aj nejake porovnania vykonu tejto architektury s inymi
> architeturami napr. MS SQL?
Neda se porovnovat vykon architektury, ale pouze vykon serveru. Na
vykon serveru ma vliv mnoho veci, nejen konkretni implementace
architektury transakci, takze vykon architektury se neda objektivne
zmerit, a tudiz ani srovnavat. Daji se srovnavat pouze vlastnosti.
Nicmene ja nezpochybnuji pouzitelnost a funkcnost MVCC implementace u
Oracle a MS. Muj nazor na implementaci MVCC u Oracle a SQLServeru
2005 se opira o fakt, ze MVCC je u nich nabastlena na zcela odlisnou
architekturu zamku a transakcniho logu. Je to jako ucit stareho psa
novym kouskum, na ktere neni fyziologicky staveny. Da se to, ale neni
to proste ono. Napr. u Oracle je MVCC implementovana na urovni celych
db stranek, tedy do transakcniho logu je pri kazde zmene db stranky
ulozena predchozi verze teto stranky. engine pak pro transakce v MVCC
rezimu (je to jen jedna spec. uroven izolace, nikoliv obecna
vlastnost systemu) dohleda prislusnou verzi stranky v logu. Jaky to
ma dopad na spotrebu diskoveho prostoru netreba zduraznovat, nemluve
o dopad na spravce vyrovnavaci pameti, pocet I/O operaci atd.. A to
se zde vubec nebavime o integraci MVCC do zbytku systemu z pohledu
vyvojare aplikaci, ktera vypada jako kdyz se michaji hrusky s mrkvi.
Pristup MS je mnohem rozumnejsi, protoze provadi verzovani na urovni
radku jako FB, ale opet je to navesene na odlisnou architekturu, se
vsemi neduhy ktere z toho plynou.
S pozdravem
Pavel Cisar (ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix(tec)cz
Vse co potrebujete pro Firebird a InterBase
seznam tabulek
[*] Pesek Michal <michal.pesek(zv)mnul(tec)cz> - 15.10.2004 13:31:32
Vyzkousej ten command zadat i s jmenem database a vlastnikem.
Command:
select * from nazev_databaze.dbo.tabulka
Michal PEPR Pesek
Je spusteny FB1.5? (druhy pokus)
[*] Andreas Bednarek <bednarek(zv)digitus(tec)cz> - 15.10.2004 11:27:20
Ahoj,
FindWindow?
nemelo by to byt spise nejake FindServiceName() nebo tak neco?
A.B.
----- Original Message -----
From: "Dalibor" <dalibor(zv)torola(tec)cz>
To: <delphi-l(zv)clexpert(tec)cz>
Sent: Friday, October 15, 2004 7:47 AM
Subject: Re: Je spusteny FB1.5? (druhy pokus)> Dalo by se to zjistovat treba takhle
>
> function BeziFirebirdServer : boolean;
> var i : integer;
> begin
> i:=FindWindow('IB_Server',nil);
> if i=0 then i:=FindWindow('FB_Server', nil) ;
> if i=0 then i:=FindWindow('FB_Inet_server.exe', nil) ;
> if i=0 then i:=FindWindow('fbguard', nil) ;
> result:=i<>0;
> end;
>
> Synapse
[*] Vlastimil Burian <vlastax.b(zv)seznam(tec)cz> - 15.10.2004 13:13:31
proboha ... delat web at uz jakykoliv ve wordu ..... no comment
// Pri ukladani MS Word vytvoril adresar "\bug.files\" a do neho vlozil
obrazok
// "image001.gif" a "filelist.xml". V HTML dokumente sa na xml subor
odkazuje
seznam tabulek
[*] Petr Lupinek <plupinek(zv)synthesia(tec)cz> - 15.10.2004 12:25:25
Zdravim,
>poradil by pls nekdo jak se da zjistit jeke tabulky jsou v MS SQL databazi
?
>znam pouze nazev databaze a poteebuji vedet co v ni je
select TABLE_NAME from INFORMATION_SCHEMA.TABLES
S pozdravem
Ing. Petr Lupinek
datove komunikacni systemy
odbor Informatika
ALIACHEM a.s. o.z SYNTHESIA
tel.: 466825535
mob.: +420 736 505 512
Je spusteny FB1.5? (druhy pokus)
[*] Milan Tomes <delphi(zv)haida(tec)cz> - 15.10.2004 07:55:03
Ja to delam takto:
1. snazim se o pripojeni na port 3050 (popr. jiny dle konfigurace) - tusim,
ze je to primo doporuceny postup v dokumentaci
2. Verzi serveru s pripade korektniho pripojeni zjistit pomoci
TIBDatabaseInfo z IBX - property Version
S pozdravem
Milan Tomes
> [mailto:delphi-l-owner(zv)clexpert(tec)cz]On Behalf Of Dalibor
> Sent: Friday, October 15, 2004 7:47 AM
>
> > muzete mi prosim poradit jak ve sve D4 aplikaci zjistim zda je
> spusteny db
> server Firebird1.5 a o jakou verzi se presne jedna?Kolik uzivatelu a kteri maji spusteny exe soubor v
[*] Ondrej Kelle <o.kelle(zv)digitalpublishing.de> - 15.10.2004 13:49:35
> potreboval bych poradi, jak programove zjistim %subj%.
> Rad bych provadel automatickou aktualizaci, ale jestlize bude
> mit nekdo ten program spusteny, nepujde exe prepsat, takze
> bych potreboval vedet, koho musim upozornit, aby si jej zavrel.
Na toto som si napisal aplikaciu. Pouzivam API NetFileEnum level 3. Ta
funkcia vyzaduje ako parameter lokalnu cestu na servri, takze dana UNC cesta
musi byt "prelozena" do lokalnej cesty cez GetLocalShareInfo.
Problem je, ze tato funkcia vyzaduje user account, ktory je clenom skupiny
Administrators alebo Server Operators na danom servri. To som riesil tak, ze
som si napisal DataSnap appserver (COM server DLL), ktory je naistalovany na
servri v domene a bezi na nom socket server ako service pod System account.
Klienti (bezni uzivatelia domeny) potom vzdialene volaju metodu appservra
(cez TSocketConnection), ktora im vrati mena uzivatelov, ktori maju dany
subor na sieti otvoreny. Funguje to pre vsetky stroje v domene.
Klient je zaregistrovany v registry pod HKCR, aby sa dal rychlo spustit z
kontext menu Explorera. Funguje to bez problemov, akurat po uzavreti suboru
tam byva urcite oneskorenie (cca. 2-3 sekundy), pocas ktoreho sa subor este
javi ako otvoreny. Ak si spravne spominam, toto oneskorenie existuje uz vo
funkcii NetFileEnum a nema nic spolocne so vzdialenym volanim po sieti.
HTH
TOndrej
Kolik uzivatelu a kteri maji spusteny exe soubor v
[*] little_bobes(zv)centrum(tec)cz - 15.10.2004 13:09:30
Zdravim,
potreboval bych poradi, jak programove zjistim %subj%.
Rad bych provadel automatickou aktualizaci, ale jestlize bude mit nekdo ten
program spusteny, nepujde exe prepsat, takze bych potreboval vedet, koho
musim upozornit, aby si jej zavrel.
Predem dekuji
S pozdravem
Bob (D4 c/s, FB 1.5)IBO cislo TCP portu WAS: Je spusteny FB1.5? (druh
[*] Andreas Bednarek <bednarek(zv)digitus(tec)cz> - 15.10.2004 12:49:28
Ahoj,
pouzivam IBObjects (4.3A)
> 1. snazim se o pripojeni na port 3050 (popr. jiny dle konfigurace) -
> tusim,
> ze je to primo doporuceny postup v dokumentaci
a v tomhle mam trochu problem, protoze se mi nedari specifikovat cislo portu
v connection string. vypise mi to mmj. 'undefined service 3050/tcp'. Kdyz
pouziji misto portu nazev sluzby 'gds_db' nebo to uplne vynecham, tak je vse
ok. Ve vypisu 'netstat -a' je take uvedene 'gds_db' a nikoli cislo portu, po
zmene firebird.conf a nastaveni RemoteServicePort treba na 3051 uz sice
netstat vypisuje naslouchani na portu 3051, ale IBO se stejne nepripoji opet
s hlaskami
Unable to complete network request to host 'localhost'
Failed to locate host machine
Undefined service 3051/tcp
Tedy jakysi problem. Zrejme spis pro konferu IBObjects, snad kdyby nekdo nahodou vedel...
Bylo by mozne otestovat spojeni bez ucasti jakychkoli komponent, tedy treba pres nejake FB API (ktere nevim jak se pouziva:-) ?> 2. Verzi serveru s pripade korektniho pripojeni zjistit pomoci
> TIBDatabaseInfo z IBX - property Version
>
Je v IBO neco podobneho? (...uz to hledam...) Pripadne opet, slo by to pres nejake API?
Diky
A.B.OT CASE pro MSSQL
[*] Kalhous <kalhous(zv)eu(tec)cz> - 15.10.2004 11:13:18
Rozdilovy skript opravdu v CS nejde ale tim bych se netrapil. Zkousel jsem
kdysi nekolik
programu ktere to "umely" ale vysledky byly vzdy (jednalo se o dost slozitou
strukturu - stovky ulozenych procedur, pres 200 tabulek, na kazde hafo
triggeru) hrube neuspokojive. Mozna proto
tam kde se vyvyjeji velke databaze je na jejich udrzbu specialista ktery
prakticky nic jineho nedela. A rozhodne se nenudi.
> CS2 vypada skvele,zbezne jsem s tim zkousel vytorit na zkousku par
> drobnosti, ale nikde jsem nedostal odpoved(ani v jejich diskusi na webu)
> na
> to, zda je mozne nejakym zpusobem vygenerovat rozdilovy skript mezi
> verzemi
> DB
Kolik uzivatelu a kteri maji spusteny exe soubor v
[*] delphin(zv)post(tec)cz - 15.10.2004 13:31:33
> potreboval bych poradi, jak programove zjistim %subj%.
> Rad bych provadel automatickou aktualizaci, ale jestlize bude mit nekdo
ten
> program spusteny, nepujde exe prepsat, takze bych potreboval vedet, koho
> musim upozornit, aby si jej zavrel.
Tohle jen tak nepujde. Schudnejsi cesta je poslat si zpravu mezi instanceni
po siti pres mailsloty nebo UDP pakety.Firebird a GBAK na velkou GDB
[*] Petr Zahradnik <clexpert(zv)clexpert(tec)cz> - 16.10.2004 00:45:05
Mimochodem, Pavle, ted jsem si precetl jeste ten zbytek, tak nekolik
reakci:
> 1. Ne vsechny transakce mohou byt kratke.
Kazdy rozumny (dle meho nazoru) vyvojar ti rekne (a v kazde seriozni
technicke literature o relacnich databazich se doctes), ze transakce
ma byt co mozna nejkratsi.
> Zatimco transakce modifikujici data jsou typicky kratke, transakce
> ktere data zpracovavaji
Takze data, ktera data zpracovavaji, data nemodifikuji? Ja myslel, ze
kazda transakce hlavne modifikuje data...
> (napr. ucetni uzaverka, preceni skladu, vyhodnoceni obratu na
> zakaznickem uctu apod.) jsou casto i velmi dlouhe.
IMHO, kdyz delas ucetni uzaverku, nema nikdo co ve starych datech
hrabat. Tohle je operace, ktera se delaji v okamziku, kdy je prace s
konkretnimi daty hotova. Jinak si nedovedu predstavit, na co by ti
byla ucetni zaverka, kdyz by ti tam nekdo neco pod rukou zmenil.
Notabene na co by ti byla i tehdy, kdyz by ti to nekdo zmenil treba
pul hodiny nebo pul roku po te uzaverce. Takova ucetni uzaverka je ti
na dve veci v obou techto pripadech, takze nepomuze ani serializace.
IMHO, kdyz precenujes hromadne sklad (protoze kdyz delas jednu
polozku, netrva to dlouho, predpokladam, ze tim myslis cely sklad
hypermarketu), nema nikdo co v takovych datech hrabat. Predpokladam,
ze to delas jednou za rok nekdy v noci, protoze jinak si nedovedu ani
predstavit, ze tam nahodis serializaci a nechas zakazniky stat 4,5
hodiny u pokladen, nez ti tato transakce dojede...
IMHO, vyhodnoceni obratu na zakaznickem uctu neni zase az tak kriticka
operace. Kdyz dojde k nejake nepresnosti, neni to zase az takova
tragedie. Pokud takove vyhodnoceni obratu delas proto, ze prave mas na
drate zakaznika, ktery zadoni o vetsi rabat, a ty se chces presvedcit,
kolik odebral za posledni 3 mesice, pravdepodobne ti je uplne jedno,
ze mu nekde ve skladu zrovna ted delaji vydejku... proste nic se
nestane, kdyz tam nebude. Pokud to delas na konci mesice proto, abys
vyhodnotil nejake obdobi z duvodu treba nejake automaticke zmeny
rabatu, pak to opet delas nad uzavrenymi daty za minuly mesic. Je malo
pravdepodobne, ze nekdo neco stareho opravi zrovna ted, notabene
takova oprava stejne neni dost rozumna.
> 3. Jediny zpusob jak zajistit stabilitu dat v ramci transakce je
> striktni serializace transakci, tedy nulova paralelnost zpracovani.
Jiste, to mas pravdu. Zrovna jako treba jedina bezpecna sifra je
Vernamova sifra, kde je klic stejne dlouhy jako data a opravdu
nahodny. Jenze to neni snadno dosazitelne, proto se pouzivaji jine
sifrovaci algoritmy, ktere nejsou 100% bezpecne, ale lze pristoupit na
danou miru bezpecnosti. Kdyz budes vyhodnocovat napriklad bezpecnost
site (ale i treba sveho bytu), take nikdy nebude 100% bezpecna, ale
musis pristoupit na urcitou miru rizika, ktera je pro tebe prijatelna.
Stejne je to s transakcemi. Kdyz pristoupis na serializaci, pak budes
mit misto SQL Serveru pomale orezavatko. Proto nedelaji database
design programy, ale lidi, kteri musi databazi navrhnout tak, aby
nebyla nutna serializace, pripadne aby se maximalne omezila, pricemz
se prihlizi k tomu, ze kolize nebo nepresnost muze nastat, ovsem
hlavne jde o to, jak moc velky problem to bude, a jak pravdepodobne to
bude. Navrhnout databazi s tim, ze se nastavi serializace, to umi
kazdy trubka. Ale navrhnout databazi tak, aby byla dostatecne vykonna
a presto co nejmene kolizni, to uz neni tak jednoduche.
A az ti do toho vstoupi i replikace, tak se kolizim stejne nevyhnes.
Ja tvrdim jednu vec - je lepsi s kolizemi pocitat, byt na ne pripraven
a umet je resit, nez se jim snazit za kazdou cenu vyhnout (tedy i za
tu cenu, ze udelas z SQL Serveru to serializovane orezavatko).
Mas to asi tak jako ze je lepsi pocitat s tim, ze ti pocitac shori,
takze budes delat pravidelne zalohy a budes mit pripraveny plan
obnovy. Je to mnohem lepsi nez mnohem vetsi energii (treba nekonecnou)
vynakladat na to, aby se to nikdy nemohlo stat. Jenze ono se to stejne
stane a pak ani vlastne nevis, co budes delat...
> Interni "ucetnictvi" db enginu umoznuje paralelismus jen do prvni
> kolize. Zatimco cteci transakce se vzajemne neobtezuji, a mohou tedy
> stastne a spokojene bezet soucasne na plne obratky, staci jedna
> ktera zapisuje do oblasti zajmu ctecich transakci, a vsechno jde do
> haje.
Ne, ne, vsechno nejde do haje - v pripade, ze s tim pocitas a v
pripade, ze to je proste dane procento, kdy to lze tolerovat a skody
nejsou velike.
> Z pohledu architektury je to jak u Oracle tak u MS obycejny bastl.
Jo! Fuj! Nejlepsi je Firebird, ze? :-)
Petr Zahradnik, pocitacovy expert
==========================================================
Petr Zahradnik, Computer Laboratory
web: http://www.clexpert(tec)cz, e-mail: clexpert(zv)clexpert(tec)cz
==========================================================
MySQL komponenty
[*] Petr Vones <konference(zv)petrvones(tec)net> - 15.10.2004 13:05:29
From: "Vlastimil Burian" <vlastax.b(zv)seznam(tec)cz>
> stupidni dotaz - chci pracovat s MySQL v Delphi a nejak sem vcera nemohl
> najit dobre komponenty pro Delphi 7 (ent.) ... (kdysi sem mel Delphi 5 a pro
dbExpress ?
Petr Vones
Prepis z C++ do Delphi
[*] Martin Pisarik <martin.pisarik(zv)seznam(tec)cz> - 15.10.2004 12:25:24
Podle me je & bitovy AND
a && je logicky AND
tj. 7 & 4 = 4
ale 7 && 4 je ( true AND true) a to je true a to je 1
> No me v C++ and neprelozi. Pokud dam za and --> & tak 92.3 v zadnem
pripade,
> pokud --> && tak 92.3 taky ne.
> Nejdrive posli spravny kod a pak ti nekdo pomuze.
kopirovani souboru
[*] Dalibor Faltynek <dalibor.faltynek(zv)orgrez(tec)cz> - 15.10.2004 09:25:10
Ahoj, ja pouzivam vetsinou toto:
procedure CopyFile(FromFname, ToFname: string);
var
FromF, ToF: file;
NumRead, NumWritten: Integer;
Buf: array[1..2048] of Char;
begin
AssignFile(FromF, FromFName);
Reset(FromF, 1); { Record size = 1 }
AssignFile(ToF, ToFName); { Open output file }
Rewrite(ToF, 1); { Record size = 1 }
try
repeat
BlockRead(FromF, Buf, SizeOf(Buf), NumRead);
BlockWrite(ToF, Buf, NumRead, NumWritten);
until (NumRead = 0) or (NumWritten <> NumRead);
finally
CloseFile(FromF);
CloseFile(ToF);
end;{finally}
end;Firebird a GBAK na velkou GDB
[*] Winsoft <winsoft(zv)netkosice.sk> - 15.10.2004 23:47:01
> 1. Ne vsechny transakce mohou byt kratke. Zatimco transakce
> modifikujici data jsou typicky kratke, transakce ktere data
> zpracovavaji (napr. ucetni uzaverka, preceni skladu, vyhodnoceni
> obratu na zakaznickem uctu apod.) jsou casto i velmi dlouhe.
a teraz zhodnotme ako tento problem riesi MGA: poskytne sice
snapshot ale za cenu nasledneho zdlhaveho zbierania narobeneho
smetia. Takze ked robim uzavierku, najprv usetrim cas a neskor ho
stratim. Aky je potom z toho celkovy efekt? Nehovoriac o tom,
ze v dosledku takejto architektury ma system automaticky vecsiu
reziu vlastne pri kazdej databazovej operacii. Mne sa zda byt
vyhodnejsie minimalizovat transakcne problemy komplexne,
nie len zobrat jeden pripad (podla mna vobec nie typicky pripad)
pouzitia a na nom vybudovat architekturu databazy.
> 2. Transakce nejen zajistuji atomicitu zmen, ale *predevsim*
> stabilitu datoveho pohledu. Nenech se zmylit skutecnosti, ze
> transakce provadejici zmeny potrebuji spise atomicitu operaci,
> protoze transakce zpracovavajici data vyzaduji predevsim prave
> stabilitu dat.
ano, samozrejme, ale snapshot si viem zabezpecit aj sam - nacitam
data z databazy niekde do datasetu (myslim ten v .NET) a mam
snapshot. A nech ta uroven v databaze je hoci aj serializovana
ak to potrebujem.
> 3. Jediny zpusob jak zajistit stabilitu dat v ramci transakce je
> striktni serializace transakci, tedy nulova paralelnost zpracovani.
> Interni "ucetnictvi" db enginu umoznuje paralelismus jen do prvni
> kolize. Zatimco cteci transakce se vzajemne neobtezuji, a mohou tedy
> stastne a spokojene bezet soucasne na plne obratky, staci jedna ktera
> zapisuje do oblasti zajmu ctecich transakci, a vsechno jde do haje.
> Multigeneracni architektura velice ucinne izoluje transakce ktere
> pouze nebo predevsim ctou od zmen provedenych jinymi transakcemi,
> takze se navzajem neblokuji (pokud se ovsem spravne nastavi parametry
> transakci).
a myslis, ze snapshot citanie je akurat ta kriticka operacia ktoru treba
riesit? Na ukor inych operacii? Ja nevidim ziaden problem, ze ked idem
tlacit rozsiahlu zostavu, nacitam data do datasetu, odpojim sa
od databazy a mozem tlacit hoci aj tyzden tie data. A ten shaphot
mi ine neriesi, LEN to citanie dat. A aj to len vtedy ked nastane
taka konstelacia, ze treba citat vela zaznamov v transakcii, co
sa da IMHO velmi dobre eliminovat nacitanim si tych zaznamov
rovno do mojho programu. A pri zapisovani zaznamov v transakcii
zase len potrebujem serializaciu, cize ten shapshot ma nezachrani.
> 4. Clanek na ktery se odvolavas pouze dokazuje, ze MGA ma sve
> opodstatneni a vyplati se na ni *postavit db engine*, protoze i MS
> SQLServer ji bude nakonec podporovat. Nikoliv ovsem jako InterBase,
> Firebird, PostgreSQL nebo MySQL, ale ve stylu Oracle, coz znamena
> *specialni* uroven izolace a vyzobavani dat z transakcniho logu (i.e.
> starsi verze jsou v podstate ulozeny externe mimo databazi).
> Implementace MS sice vypada rozumneji nez ta od Oracle, ale i tak mam
> sve pochybnosti. Z pohledu architektury je to jak u Oracle tak u MS
> obycejny bastl.
su to dost silne slova na databazy ako MS SQL a Oracle
ale mas samozrejme pravo na svoj nazor. Mozes uviest
aj nejake porovnania vykonu tejto architektury s inymi
architeturami napr. MS SQL?
Ja mam pocit, ze v MS SQL to implementovali ako jednu
z moznosti k niekokym uz existujucim moznostiam hlavne
koli ulahceniu prechodu na MS SQL z inych databaz, nie
z nejakej nevyhnutnosti.
Erik
Cesta v servisni aplikaci
[*] Petr Vones <konference(zv)petrvones(tec)net> - 14.10.2004 12:41:38
From: "Kratochvil Milan" <mkratochvil(zv)farmtec(tec)cz>
> Predelavam jeden program na service a nemuhu nejak najit nahradu za
> Application.ExeName. Prosim o nakopnuti.
ParamStr(0)
Petr Vones
Firebird a GBAK na velkou GDB
[*] Marek Spisak <spishark(zv)post(tec)cz> - 15.10.2004 14:57:40
Stepan Dobias wrote:
>Uplne nerozumim pojmu Multigeneracni architektura? Mohl by mi nekdo tento
>termin objasnit?
>
Multigeneracni Architektura uzce souvisi s urovni izolace transakci.
IB/FB nepouziva zamky a transakcni protokol pro odstineni transakci. V
databazi je udrzovana historie verzi radku - od nejnovejsi k nejstarsi
tak, jak byla vytvorena jednotlivymi transakcemi. Diky teto historii
muze server pristoupit ke kterekoliv verzi radku, ktera je pro konkretni
transakci relevantni. Mezi vyhody patri velka propustnost systemu,
zvlaste u transakci s vyssi urovni izolace. Vyhodou je take moznost
zalohovat databazi za provozu. Nevyhodou je nutnost cisteni DB od
"spiny", tj. starych verzi radku.
Velice pekne je tato problematika popsana v knize Pavla Cisare Podrobna
prirucka InterBase/Firebird - Tvorba, administrace a programovani
databasi ISBN 80-7226-946-1
Marek
Firebird a GBAK na velkou GDB
[*] Milan Tomes <delphi(zv)haida(tec)cz> - 15.10.2004 07:43:02
Tuto zkusenost mame take - mame tabulku ve ktere je cca. 1mil. zaznamu a pri
jejim vyprazdneni si na nove otevreni musime nekolik hodin pockat. Tabulka
se skutecne otevre, ale bohuzel to trva takto dlouho :((( Stejne se to chova
pri gbaku. Mam za to, ze je to zpusobeno natural scanem, ktery probehne
vsechny zaznamy a rusi je, nicmene nechapu proc to trva takhle neskutecne
dlouho.
S pozdravem
Milan Tomes
> [mailto:delphi-l-owner(zv)clexpert(tec)cz]On Behalf Of Tomas Hulek
> Sent: Friday, October 15, 2004 7:31 AM
>
> Mam databazi, ktera ma 3,5GB a v ni ma nejvetsi tabulka neco malo pres 13
> milionu zaznamu.
> Tuto tabulku celkem bez problemu zazalohuju pomoci GBAK, ale vy
> chvili kdy z
> te velke tabulky smazu vetsi mnozstvi dat (cca 2/3), tak me GBAK tuto
> databazi proste nezazalohuje. Bud to vytuhne prave pri zalohovani
MDI aplikace - problem se zaviranim oken
[*] Ing. Igor Vodicka <vodicka(zv)sagit(tec)cz> - 15.10.2004 12:43:27
Velice se vsem omlouvam, ale 13. 10. jsem odesilal Adminovi na soukr. mail:
<<
Zdravim,
jsem aktivni uzivatel konference. V poslednich dnech se mi nepodarilo
odeslat do konference zadne zpravy, ale zpravy ostatnich ucastniku mi chodi
normalne.
O mych odeslanych zpravach neprijdou zadne chybove hlaseni nebo se nevraceji
zadne zpravy o nedoruceni, a presto ma zprava nedojde.
Partal jsem u nas, ale nic jsem neobjevil. Moje ostatni odchozi posta je
dorucovana normalne. Muzete se nejak podivat v cem muze byt problem. Do
konference jsem prihlaseny z teto adresy vodicka(zv)sagit(tec)cz. Mimochodem, ted
jsem si uvedomil, ze jsem dlouho nedostal test prihlaseni z konference.
>>
Teprve dnes se mi podarilo odeslat dotaz (zmenil jsem subj.). A take jsem
dostal "odpoved". Na predchazejici dotazy mi z konference zadne odpovedi
nedosly.
Jeste jednou vsem prominte.
Igor Vodicka
> -----Original Message-----
> From: delphi-l-owner(zv)clexpert(tec)cz [mailto:delphi-l-owner(zv)clexpert(tec)cz]On
> Behalf Of Milan Tomes
>
>
> Nevim jak ostatnim, ale uz mam docela plne zuby cist temer kazdy
> den jeden a
> ten samy dotaz... :(((
>
> S pozdravem
>
> Milan Tomes
>
> > [mailto:delphi-l-owner(zv)clexpert(tec)cz]On Behalf Of Ing. Igor Vodicka
> > Sent: Friday, October 15, 2004 9:11 AM
> >
> > V MDI aplikaci mam funkci, ktera zavira vsechna otevrena
> > childokna. Pouzivam
>
Kompatibilita IB/FB
[*] Pavel Cisar <pcb(zv)atlas(tec)cz> - 15.10.2004 09:33:11
Haj hou!
On 14 Oct 2004 at 23:28, Andreas Bednarek wrote:
> nevite prosim nekdo zda nekde existuje nejaky dokument sumirujici
> rozdily v kompatibilite mezi IB/FB?
>
> Pouzivam FB1.5 a zajima me kompatibilita s IB6.5 a vyse (tedy do 7.1?).
Specificky dokument o rozdilech pokud vim neni k dispozici. V knize
co vysla u Compure Pressu je popsan FB 1.0 a 1.5 (drobne odlisnosti
od reality, protoze kniha vysla o neco drive nez finalni FB 1.5) a IB
6.0, 6.5 a 7.0. Specificke vlastnosti jsou vzdy zvyrazneny.
Jinak je mozne si vzit dokumenty Release Notes pro FB 1.0, 1.5 a
1.5.1 a srovnat je s What's New pro IB 6.5, 7.0 a 7.1.
S pozdravem
Pavel Cisar (ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix(tec)cz
Vse co potrebujete pro Firebird a InterBase
Poznatek: WinXP SP2 a Skenovani portu
[*] delphi(zv)hon(tec)cz - 15.10.2004 08:51:07
Ahoj,
nepochopil jsem jestli Tve tvrzeni vychazi z jistoty, nebo se jen
domnivas, ze to tak funguje.
Jestli to prvni, je to nekde popsano na MSDN? Tohle by totiz
vyresilo muj problem s jednim mym programem, ktery to taky zkousi na vsechny
strany a dele to trva nez nabehne (ale ne vzdy).
Martin
----- Original Message -----
> Ahoj, takova zkusenost s SP2 na WInXP
> Pokud mate nejakou utilitku, ktera v siti prochazi vsechny PC a zjistuje
> treba pritomnost Firebird Serveru na portu 3050 a mate to udelane tak, ze
> vyuzivate vice threadu na konektovani(treba 20 najednou), tak po
> implementaci SP2 na WinXP se Vam brutalne skenovani zpomali.
> Jo tu udelane schvaleni proti virum, ktere takhle skenuji porty.
>
> Je to myslim omezeni, ze behem 20 vterin se muzete konektovat maximalne k
> 10 (neexistujicim) portum.
>
> Smula je ta, ze pokud se budete chtit konektnout behem te doby, byt k jiz
> existujicimu pripojeni, tak musite pockat, az se dokonektuje ty predchozi
> neuspesne konekty.
>
>
>
>
>
>
>
>
> Borland Delphi 2005
[*] Jiri Foldyna <jiri.f(zv)avizo(tec)cz> - 15.10.2004 12:27:25
> Petr Vones wrote:
> > From: "Jiri Foldyna" <jiri.f(zv)avizo(tec)cz>
> >>No, ja bych ocenil podobny nastroj, ktery by v jednom GUI
> umoznoval vyvoj
> >>novych veci v .NET (klidne v C#) a udrzbu starych ve Win32 (a Object
> > Zalezi na typu aplikaci co chces vyvijet, treba Compact
> Framework nebude
> > podporovan.
>
> hmm, skoda, to je jediny, co me zatim na .NETu laka :/
To bych ocenil i ja, mam novy Asus Mypal a jako hracka je to vyborne :-))
Zkousel jsem sice jen "hello world" ve Visual Studiu, ale vypada to docela
dobre pouzitelne (aspon na prvni pohled).
> >>(koneckoncu, bude to teprve ctvrty nebo paty, co znam :-)),
> vic me zdrzuje
> >>stridani vyvojovych prostredi s ruznym ovladanim. Takze
> ano, pokud to bude
> > To je opravdu jen vec zvyku.
>
> myslim, ze J.F. to myslel takhle: udrzovat stavajici Win32 +
> nove psat
> pro .NET = (v pripade dvou IDE) znacnej hokej v klavesa pri
> zmene IDE.
> Ja treba, kdyz potrebuju neco opravit v PCFANDU, tak mi
> nejvetsi potize
> dela jine rozlozeni DOSove klavesnice (to je preklepu a
> hledani...). V
> Pripade jednotneho IDE pro Win32 i .NET by podobne potize odpadly.
Bingo, to je presne ono. Stridat dve diametralne odlisna IDE je pro mne
cerna mura.
Zdravim
Jiri Foldyna
Simulacia kliknutia mysi
[*] mms(zv)szm(tec)com - 15.10.2004 09:39:11
Zdravim,
pomocou PostMessage sa snazim nasimulovat stisknutie laveho tlacitka mysi na
komponente tree.
lParam procedury PostMessage by mal ako LoWord obsahovat suradnicu X a ako
HiWord suradnicu Y.
A ja mam poziciu mysi ako TPoint kde x aj y je LongInt.
Ako je mozne suradnicu x a y dostat do parametru lParam?
dakujem
Milan Samak
ANN: Mytracker 1.00
[*] Burkovsky Ladislav <ladislav.burkovsky(zv)autinform.de> - 15.10.2004 08:51:07
Zdravim konferenciu,
pred dvoma rokmi som napisal tento softik
ak ma niekto zaujem ho pouzivat (vylepsit)
mate sancu pod http://sourceforge.net/projects/mytracker/
Laco
Borland Delphi 2005
[*] Zbysek Hlinka <konference(zv)hlinka(tec)cz> - 15.10.2004 22:10:54
> -----Original Message-----
> From: delphi-l-owner(zv)clexpert(tec)cz
> [mailto:delphi-l-owner(zv)clexpert(tec)cz] On Behalf Of Jiri Foldyna
> Sent: Friday, October 15, 2004 12:27 PM
>
> Bingo, to je presne ono. Stridat dve diametralne odlisna IDE
> je pro mne cerna mura.
Ovladani IDE Delphi a Visual studia nejsou zdaleka diametralne odlisna.
Vyresil jsem to tak, ze jsem se naucil ovladani VS, zavedl jsem jeho
emulaci i v Delphi a ted mam nejvetsi problemy (tedy preklepy) s rozdily
mezi =, ==, := a =.
S pozdravem
Zbysek Hlinka
E-mail: hlinka zavin. hlinka(tec)cz
seznam tabulek
[*] Matejcek Petr <konference(zv)crhov.komfi(tec)cz> - 15.10.2004 12:17:24
DD,
poradil by pls nekdo jak se da zjistit jeke tabulky jsou v MS SQL
databazi ?
znam pouze nazev databaze a poteebuji vedet co v ni je
diky
PM
Prepis z C++ do Delphi
[*] Jiri Cincura <diskuze(zv)cincura(tec)net> - 15.10.2004 12:23:24
Takze abych take rekl neco konferenci. Ten kod zde byl blbe (jak vstupy, tak
syntax). Tazatel uz to vyresil.
--
Jiri Cincura
e-mail: mailto:jiri(zv)cincura.net; mailto:xcincura(zv)informatics.muni(tec)cz
ICQ#: 314711544
web: http://www.cincura.net; http://photo.cincura.net
---
Nekdo vidi veci, ktere existuji, a pta se - proc?. Ja snim o vecech, ktere
nikdy neexistovaly a ptam se - proc ne? (Robert Kennedy)
MySQL komponenty
[*] Vlastimil Burian <vlastax.b(zv)seznam(tec)cz> - 15.10.2004 13:03:29
stupidni dotaz - chci pracovat s MySQL v Delphi a nejak sem vcera nemohl najit dobre komponenty pro Delphi 7 (ent.) ... (kdysi sem mel Delphi 5 a pro ne sem je sehnal hned) ... napiste mi prosim nejaky link na vami overene komponenty .. diky
C++ a Delphi v jednom souboru
[*] Jakub Cermak <cermiforum(zv)centrum(tec)cz> - 15.10.2004 21:20:51
Zdravim konferenci,
nekde jsem slysel, ze jde do 1 souboru napsat zdrojak pro Pascal/Delphi a
C++. Proste mi jde o to aby, kdyz ten soubor prelozim v Delphi, aby
prekladac "nevidel" na C++ kod a naopak.Odhaduju ze se to dela pomoci
komentaru, ale jak presne nemam tuseni. Nevite nekdo jak na to? Nejlepe
priklad
WinXP SP1, Delphi 6 Ent., C++ Builder 5
Jakub Cermak
ja.cermi(zv)centrum(tec)cz
ICQ 159971304
http://cermi.wz(tec)cz
Firebird a GBAK na velkou GDB
[*] petr palicka <palicka.petr(zv)seznam(tec)cz> - 15.10.2004 12:07:22
Stepan Dobias wrote:
> Uplne nerozumim pojmu Multigeneracni architektura? Mohl by mi nekdo tento
> termin objasnit?
viz dbsvet(tec)cz, kde je to pekne popsany, nebo hledej na ibphoenix(tec)cz, ale
jsou to vsecko dost stary clanky. mozna google :o)
peca
Ohlaseni nove verze Delphi
[*] Jan Novak <delfin4(zv)volny(tec)cz> - 15.10.2004 21:00:49
> bude z jedineho IDE podporovat vyvoj pro Win32 i .NET, Delphi i
> C#, ASP.NET, ADO.NET, VCL.NET a VCL for Win32.
devatero remesel, desata bida...
Firebird a GBAK na velkou GDB
[*] petr palicka <palicka.petr(zv)seznam(tec)cz> - 15.10.2004 07:53:02
Ahoj,
odvazim se tvrdit, ze to ma na svedomi MGA (multigeneracni
architektura). Jinymy slovy: server prochazi vsechny verze zaznamu a
odstranuje neplatne, coz mu da fakt zabrat. Tohle by mohl jisteji vedet
P.Cisar.
Nam se stalo, ze program pri stratu dela nejaky ten alter table.
Jenze zakaznik pracoval stylem: import z DOS aplikace, tisk sestavy,
prace v DOS, import z DOS... Cimz mel GDB 100MB a alter ty jedny
tabulky, ktera mela nevim kolik tisic zrusenych radku do druhyho dne
nedojel. Nastesti v tomto pripade slo smazat databazi a znovu
naimportovat data.
Peca
Firebird a GBAK na velkou GDB
[*] Pavel Cisar <pcb(zv)atlas(tec)cz> - 15.10.2004 09:29:10
Haj hou!
On 15 Oct 2004 at 7:31, Tomas Hulek wrote:
> chtel bych se podelit o svoji ne dobrou zkusenost se zalohovanim
> databaze pomoci nastroje GBAK u Firebirdu 1.5 Mam databazi, ktera ma
> 3,5GB a v ni ma nejvetsi tabulka neco malo pres 13 milionu zaznamu.
> Tuto tabulku celkem bez problemu zazalohuju pomoci GBAK, ale vy chvili
> kdy z te velke tabulky smazu vetsi mnozstvi dat (cca 2/3), tak me GBAK
> tuto databazi proste nezazalohuje. Bud to vytuhne prave pri zalohovani
> prave teto velke tabulky (GBAK poustim s parametrem -verbose) a nebo
> to zkonci s errorem deadlock ???
Muze za to Multigeneracni architektura, a odstranovani "smeti".
> Zkousel jsem poustet GBAK s parametry -garbage -ignore -limbo (pro
> jistotu vsechno) a vysledek je stejnej ! Misto na disku mam a PC je
> P4-2,60GHz, 1GB RAM
Parametr -garbage_collect obvykle pomuze, ale zalezi i na dalsich
okolnostech. Tento pripad je ponekud extremni. Parametr -
garbage_collect rovnez prilis nepomaha, pokud v prubehu zalohovani s
databazi pracuje jeste nekdo dalsi.
> Mate nekdo podobnou zkusenost a pokud mozno by mi poradil jak na to ?
Pokud zrusite vetsi mnozstvi dat v databazi, doporucuje se ihned
provest sweep (pomoci gfix), a pripadnou zalohu az po sweepu. Sweep
je v takovem pripade rychlejsi. Odstraneni smeti je rovnez rychlejsi,
pokud s databazi prave nikdo dalsi nepracuje. Dalsiho zrychleni
sweepu (ale i zalohovani) lze dosahnout pouzitim verze Classic v
lokalnim pripojeni (pouze Linux, nikoliv Classic na Windows!).
S pozdravem
Pavel Cisar (ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix(tec)cz
Vse co potrebujete pro Firebird a InterBase
Poznatek: WinXP SP2 a Skenovani portu
[*] Dalibor <dalibor(zv)torola(tec)cz> - 15.10.2004 08:11:04
Ahoj, takova zkusenost s SP2 na WInXP
Pokud mate nejakou utilitku, ktera v siti prochazi vsechny PC a zjistuje treba pritomnost Firebird Serveru na portu 3050 a mate to udelane tak, ze vyuzivate vice threadu na konektovani(treba 20 najednou), tak po implementaci SP2 na WinXP se Vam brutalne skenovani zpomali.
Jo tu udelane schvaleni proti virum, ktere takhle skenuji porty.
Je to myslim omezeni, ze behem 20 vterin se muzete konektovat maximalne k 10 (neexistujicim) portum.
Smula je ta, ze pokud se budete chtit konektnout behem te doby, byt k jiz existujicimu pripojeni, tak musite pockat, az se dokonektuje ty predchozi neuspesne konekty.seznam tabulek
[*] Petr Lupinek <plupinek(zv)synthesia(tec)cz> - 15.10.2004 12:31:26
Zdravim,
>poradil by pls nekdo jak se da zjistit jeke tabulky jsou v MS SQL databazi
?
>znam pouze nazev databaze a poteebuji vedet co v ni je
>select TABLE_NAME from INFORMATION_SCHEMA.TABLES
jeste to upresnim, predchozi dotaz vraci napr. i VIEW, pro tabulky je
potreba zuzit vyber takto:
select * from INFORMATION_SCHEMA.TABLES where TABLE_TYPE = 'BASE TABLE'
S pozdravem
Ing. Petr Lupinek
datove komunikacni systemy
odbor Informatika
ALIACHEM a.s. o.z SYNTHESIA
tel.: 466825535
mob.: +420 736 505 512
Je spusteny FB1.5? (druhy pokus)
[*] Dalibor <dalibor(zv)torola(tec)cz> - 15.10.2004 07:47:02
Dalo by se to zjistovat treba takhle
function BeziFirebirdServer : boolean;
var i : integer;
begin
i:=FindWindow('IB_Server',nil);
if i=0 then i:=FindWindow('FB_Server', nil) ;
if i=0 then i:=FindWindow('FB_Inet_server.exe', nil) ;
if i=0 then i:=FindWindow('fbguard', nil) ;
result:=i<>0;
end;
> muzete mi prosim poradit jak ve sve D4 aplikaci zjistim zda je spusteny db
server Firebird1.5 a o jakou verzi se presne jedna?
>
> Nejlepe pro systemy W98, 2k, XP ale alespon pro 2k, XP.
>
> Dekuji za radu
> A.B.
>OT CASE pro MSSQL
[*] Pavel Polak <pavelp(zv)bnsoft(tec)cz> - 15.10.2004 09:43:12
Zdravim,
CS2 vypada skvele,zbezne jsem s tim zkousel vytorit na zkousku par
drobnosti, ale nikde jsem nedostal odpoved(ani v jejich diskusi na webu) na
to, zda je mozne nejakym zpusobem vygenerovat rozdilovy skript mezi verzemi
DB(spravce verzi tam je, umi zobrazit rozdily ale to je vse co jsem
zjistil), vsichni rikaji asi to nejde, ale s jistotou to nikdo nerekl:)
samozrejme, radeji bych slysel, ze to nejak treba i trosku krkolomne jde...
Pavel Polak
> -----Original Message-----
> From: delphi-l-owner(zv)clexpert(tec)cz
> [mailto:delphi-l-owner(zv)clexpert(tec)cz]On Behalf Of Kalhous
> Sent: Friday, October 15, 2004 6:55 AM
> To: delphi-l(zv)clexpert(tec)cz
> Subject: Re: OT CASE pro MSSQL
>
>
> CaseStudio2 jsem s nadsenim pouzival a pouzivam dal, zivot bez CS2 si uz
> neumim predstavit. Pro ilustraci - velky model s vice nez 200 tabulek a
> zadne problemy. S oblibou a nadsazkou rikam, ze je to jeden z
> mala programu
> pro Windows ktery je opravdu pouzitelny. Naucit se v nem psat vlastni
> sablony a java skripty je snadne i diky podpore CharonWare (konference) a
> strucne receno - alespon pro IB jsem za leta nenarazil na neco co
> by neslo.
> Pravda je, ze helpy jsou ponekud strohe ale to se da prezit.
>
> ----- Original Message -----
> From: "Ing. Petr Kejval" <petr.kejval(zv)worldonline(tec)cz>
> To: <delphi-l(zv)clexpert(tec)cz>
> Sent: Thursday, October 14, 2004 9:44 AM
> Subject: OT CASE pro MSSQL
>
>
> > Dobry den,
> > sledoval jsem Vasi diskusi na tema CASE navrhovani DB a generovani DB.
> > V nasi firme hledame cenove dostupny CASE pro MSSQL Server
> 2000. Zatim se
> > rozhodujeme mezi Visiem od MS a Case Studiem 2 od CharonWare. Ma nekdo
> > zkusenosti s temito produkty? Poradil by mi, ktery vybrat
> (treba i jiny) a
> > proc?
> >
> > S pozdravem
> > Petr Kejval
> >
> >
> >
> >
>
>
ADMIN: Firebird a GBAK na velkou GDB
[*] Petr Zahradnik <clexpert(zv)clexpert(tec)cz> - 15.10.2004 20:24:28
Puvodni zprava ze dne 15.10.2004:
> Eriku, sevce, proc se radsi nedrzis sveho kopyta ? Alespon by jsi ze
> sebe nedelal verejne blazna.
Jsou vazne nutna takova slova??? Retoricka otazka - takze prosim
neodpovidat a zklidnit hormony, dekuji.
Jinak, kdyz uz na to musim koukat - "by jsi" se cesky pise "bys".
Petr Zahradnik, pocitacovy expert
==========================================================
Petr Zahradnik, Computer Laboratory
web: http://www.clexpert(tec)cz, e-mail: clexpert(zv)clexpert(tec)cz
==========================================================
MDI aplikace - problem se zaviranim oken
[*] Milan Tomes <delphi(zv)haida(tec)cz> - 15.10.2004 09:41:12
Nevim jak ostatnim, ale uz mam docela plne zuby cist temer kazdy den jeden a
ten samy dotaz... :(((
S pozdravem
Milan Tomes
> [mailto:delphi-l-owner(zv)clexpert(tec)cz]On Behalf Of Ing. Igor Vodicka
> Sent: Friday, October 15, 2004 9:11 AM
>
> V MDI aplikaci mam funkci, ktera zavira vsechna otevrena
> childokna. Pouzivam
Firebird a GBAK na velkou GDB
[*] Pavel Cisar <pcb(zv)atlas(tec)cz> - 15.10.2004 20:00:27
Haj hou!
On 15 Oct 2004 at 15:35, Winsoft wrote:
> > Multigeneracni Architektura uzce souvisi s urovni izolace transakci.
<snip>
> mne sa zda, ze tato architektura riesi problem, ktory by vlastne nemal
> byt problemom, lebo transakcie by mali byt kratke. V praxi sa samozrejme
> mozu take transakcie zist, ale stavat na nich architekturu databazoveho
> servera? MS SQL 2005 bude podporovat Snapshot Isolation,
> predpokladam, ze je to nieco obdobne, ak nie to iste viz.
> http://www.microsoft.com/technet/prodtechnol/sql/2005/SQL05B.mspx
Eriku, sevce, proc se radsi nedrzis sveho kopyta ? Alespon by jsi ze
sebe nedelal verejne blazna.
1. Ne vsechny transakce mohou byt kratke. Zatimco transakce
modifikujici data jsou typicky kratke, transakce ktere data
zpracovavaji (napr. ucetni uzaverka, preceni skladu, vyhodnoceni
obratu na zakaznickem uctu apod.) jsou casto i velmi dlouhe.
2. Transakce nejen zajistuji atomicitu zmen, ale *predevsim*
stabilitu datoveho pohledu. Nenech se zmylit skutecnosti, ze
transakce provadejici zmeny potrebuji spise atomicitu operaci,
protoze transakce zpracovavajici data vyzaduji predevsim prave
stabilitu dat.
3. Jediny zpusob jak zajistit stabilitu dat v ramci transakce je
striktni serializace transakci, tedy nulova paralelnost zpracovani.
Interni "ucetnictvi" db enginu umoznuje paralelismus jen do prvni
kolize. Zatimco cteci transakce se vzajemne neobtezuji, a mohou tedy
stastne a spokojene bezet soucasne na plne obratky, staci jedna ktera
zapisuje do oblasti zajmu ctecich transakci, a vsechno jde do haje.
Multigeneracni architektura velice ucinne izoluje transakce ktere
pouze nebo predevsim ctou od zmen provedenych jinymi transakcemi,
takze se navzajem neblokuji (pokud se ovsem spravne nastavi parametry
transakci).
4. Clanek na ktery se odvolavas pouze dokazuje, ze MGA ma sve
opodstatneni a vyplati se na ni *postavit db engine*, protoze i MS
SQLServer ji bude nakonec podporovat. Nikoliv ovsem jako InterBase,
Firebird, PostgreSQL nebo MySQL, ale ve stylu Oracle, coz znamena
*specialni* uroven izolace a vyzobavani dat z transakcniho logu (i.e.
starsi verze jsou v podstate ulozeny externe mimo databazi).
Implementace MS sice vypada rozumneji nez ta od Oracle, ale i tak mam
sve pochybnosti. Z pohledu architektury je to jak u Oracle tak u MS
obycejny bastl.
S pozdravem
Pavel Cisar (ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix(tec)cz
Vse co potrebujete pro Firebird a InterBase
Predani typu.
[*] Jiri Bouchala <bouchala(zv)starmon(tec)cz> - 15.10.2004 15:37:43
Tak jsem zjistil, ze TypeInfo je pseudofunkce a je vyhodnocena kompilatorem
pri kompilaci.
Proto je mozne ji predat typ. Pokud nekdo vi dalsi podrobnosti k tomuto
tematu (pseudofunkci, RTTI a predavani typu) podelte se o zkusenosti.
Jaky profiler ?
[*] Petr Vones <konference(zv)petrvones(tec)net> - 14.10.2004 12:45:39
From: <mad(zv)worldmail(tec)cz>
> jaky pouzivate profiler pro Delphi ? Pripadne vyhody a nevyhody ...
http://www.automatedqa.com/products/aqtime.asp
Petr Vones
OT CASE pro MSSQL
[*] Kalhous <kalhous(zv)eu(tec)cz> - 15.10.2004 06:54:58
CaseStudio2 jsem s nadsenim pouzival a pouzivam dal, zivot bez CS2 si uz
neumim predstavit. Pro ilustraci - velky model s vice nez 200 tabulek a
zadne problemy. S oblibou a nadsazkou rikam, ze je to jeden z mala programu
pro Windows ktery je opravdu pouzitelny. Naucit se v nem psat vlastni
sablony a java skripty je snadne i diky podpore CharonWare (konference) a
strucne receno - alespon pro IB jsem za leta nenarazil na neco co by neslo.
Pravda je, ze helpy jsou ponekud strohe ale to se da prezit.
----- Original Message -----
From: "Ing. Petr Kejval" <petr.kejval(zv)worldonline(tec)cz>
To: <delphi-l(zv)clexpert(tec)cz>
Sent: Thursday, October 14, 2004 9:44 AM
Subject: OT CASE pro MSSQL
> Dobry den,
> sledoval jsem Vasi diskusi na tema CASE navrhovani DB a generovani DB.
> V nasi firme hledame cenove dostupny CASE pro MSSQL Server 2000. Zatim se
> rozhodujeme mezi Visiem od MS a Case Studiem 2 od CharonWare. Ma nekdo
> zkusenosti s temito produkty? Poradil by mi, ktery vybrat (treba i jiny) a
> proc?
>
> S pozdravem
> Petr Kejval
>
>
> Odchyceni zmeny caption formu
[*] Vlastimil Burian <vlastax.b(zv)seznam(tec)cz> - 15.10.2004 13:39:34
bohuzel u sebe nemam delphi ale urcite pro to nebude existovat nejaka zprava
kterou by se dalo odchytit ... a pouzivat Application.OnMessage je prilis
drsne .... pokud by to bylo v normalni aplikaci tak bych se uchylil k Timeru
a v nem proste kontroloval jestli byl caption zmenen tim ze bych si ho po
startu apl. treba nekam ulozil chapes ... ty ale vytvaris komponentu nebo
jak to myslis ?> Muzete mi nekdo poradit, jak odchytit zmenu Caption formulare (TForm) v me
> komponente ?Firebird a GBAK na velkou GDB
[*] Tomas Hulek <hulek(zv)atlas(tec)cz> - 15.10.2004 07:31:00
Zdravim,
chtel bych se podelit o svoji ne dobrou zkusenost se zalohovanim databaze
pomoci nastroje GBAK u Firebirdu 1.5
Mam databazi, ktera ma 3,5GB a v ni ma nejvetsi tabulka neco malo pres 13
milionu zaznamu.
Tuto tabulku celkem bez problemu zazalohuju pomoci GBAK, ale vy chvili kdy z
te velke tabulky smazu vetsi mnozstvi dat (cca 2/3), tak me GBAK tuto
databazi proste nezazalohuje. Bud to vytuhne prave pri zalohovani prave teto
velke tabulky (GBAK poustim s parametrem -verbose) a nebo to zkonci s
errorem deadlock ???
Mate nekdo podobnou zkusenost a pokud mozno by mi poradil jak na to ?
Zkousel jsem poustet GBAK s parametry -garbage -ignore -limbo (pro jistotu
vsechno) a vysledek je stejnej !
Misto na disku mam a PC je P4-2,60GHz, 1GB RAM
th MDI aplikace - problem se zaviranim oken
[*] Ing. Igor Vodicka <vodicka(zv)sagit(tec)cz> - 15.10.2004 09:11:09
Ahoj do kofery!
V MDI aplikaci mam funkci, ktera zavira vsechna otevrena childokna. Pouzivam
nasledujici konstrukci:
for I := MDIChildCount-1 downto 0 do
MDIChildren[I].Close;
Childokno ma nadefinovanou udalost OnClose, kde provadim nasledujici test:
if MainForm.MDIChildCount=1 then //kdyz zustava posledni otevrene okno
begin
.
neco;
.
end;
Problem je ten, ze MDIChildCount se nesnizuje jak jsou postupne okna v cyklu
zavirana, ale zustava na hodnote puvodniho postu oken.
Nevite nekdo jak zaridit, aby se hodnota MDIChildCount aktualizovala? Delam
v D5 Ent na W2K.
Diky za kazde nakopnuti
Ing. Igor Vodicka
informacni systemy
Nakladatelstvi Sagit
Tel.: 59 6786 001
HTTP://www.sagit(tec)cz/
Borland Delphi 2005
[*] Petr Vones <konference(zv)petrvones(tec)net> - 15.10.2004 13:11:30
From: "petr palicka" <palicka.petr(zv)seznam(tec)cz>
> myslim, ze J.F. to myslel takhle: udrzovat stavajici Win32 + nove psat
> pro .NET = (v pripade dvou IDE) znacnej hokej v klavesa pri zmene IDE.
Osobne klavesove zkratky pouzivam minimalne (protoze si je nepamatuju) a vse
delam mysi z toolbaru.
Nicmene tady si lze zdarma stahnout doplnek do VS2003 kde je jsou klavesove
zkratky ve stylu Delphi IDE (a plno dalsich veci):
http://www.usysware.com/dpack/
Petr Vones
Cesta v servisni aplikaci
[*] Kratochvil Milan <mkratochvil(zv)farmtec(tec)cz> - 14.10.2004 12:31:37
Zdravim vsechny
Predelavam jeden program na service a nemuhu nejak najit nahradu za Application.ExeName. Prosim o nakopnuti.
Milan
Otevreni / Nacteni doc souboru
[*] Ales Vasicek <vasicek(zv)ecommerce(tec)cz> - 14.10.2004 23:10:27
Do richeditu asi tezko, kdyz jde o dokument MS Word. RichEdit zvlada (jak uz je z jeho nazvu patrne) pouze format rtf.
Ales
> -----Original Message-----
> From: Jiri Baudys [mailto:konference(zv)baudys.name]
>
> poprosim o radu, jestli nekdo nevite jak nacist doc soubor do
> RichEditu,
> event. Mema.Meno prvku vymenovaneho typu
[*] Jiri Bouchala <bouchala(zv)starmon(tec)cz> - 14.10.2004 14:09:48
Vse lze ziskat z RTTI za behu asi takto:
uses TypInfo;
type TMyType = ( prvy_clen, druhy_clen, treti_clen );
var OrdTypeInfo:PTypeInfo;
EnumName:string;
begin
OrdTypeInfo:=TypeInfo(TMyType);
EnumName:=GetEnumName(OrdTypeInfo, 1); //viz priklad 'druhy_clen'
end;
JB
poradi niekto, ako sa da zistit meno prvku vymenovaneho typu
za behu programu?
Mam napr. takyto typ:
TMyType = ( prvy_clen, druhy_clen, treti_clen );
Potreboval by som funkciu, ktora by mi na zaklade ordinalnej hodnoty
vratila dane meno prislusneho prvku.
Napr:
MenoPrvku := ReverseOrd( TMyType, 1 ); //vratilo by retazec 'druhy_clen'
funkcia GetEnumName() zda sa funguje len na triedy... :-(
seznam tabulek
[*] Matejcek Petr <konference(zv)crhov.komfi(tec)cz> - 15.10.2004 13:17:31
diky seznam tabulek uz mam ale kdyz chci provest select * from tabulka
tak to vzdy vyhazuje
Cannot execute command. Error:
Invalid object name 'tabulka'
Command:
select * from tabulka
za slovo tabulka zkousim davat ty nazvy co mi vyjedou ve sloupci TABLE_NAME
delam neco spatne ?
diky PM
Petr Lupinek napsal(a):
>jeste to upresnim, predchozi dotaz vraci napr. i VIEW, pro tabulky je
>potreba zuzit vyber takto:
>
>select * from INFORMATION_SCHEMA.TABLES where TABLE_TYPE = 'BASE TABLE'
>
>
>
>
>
>OT CASE pro MSSQL
[*] Jiri Baudys <konference(zv)baudys.name> - 14.10.2004 13:17:42
MySQL, Oracle, MSSQL, ODBC, SQLite.
Jirka
>Jenze to je jen pro MySQL (alespon jsem to tak pochopil z popisu), tedy
nikoli pro MSSQL.
>Ja zase bych rad kdyby to umelo FB, ale zase uz mame to CaseStudio2, takze
bych uz ted stejne nemenil.
>Peca
Jiri Baudys wrote:
> Osobne pouzivam DB Designer (http://www.fabforce.net/dbdesigner4/)
> hlavnim argumentem je cena, popr. i zdroje v delphi / kilixu.FB a slozitejsi updaty
[*] Martin Pisarik <martin.pisarik(zv)seznam(tec)cz> - 14.10.2004 13:19:42
A jak udelam toto?
update hrusky, ovoce set hrusky.snedl=ovoce.snedl where
ovoce.id_hrusky=hrusky.id
v mySQL to takto jde, ale u FB ani SQLlite jsem neprisel na to jak to
udelat, tak jsem nakonec musel pouzit tempovou tabulku.
Jde to nejak a nebo jsem opravdu tak neskromny kdyz chci aby SQL server umel
nastavit v jedne tabulce hodnotu v zavislosti na hodnote v jine tabulce?
>nicmene muzes:
>update hrusky set vyhodit=1 where id_hrusky in (select id_hrusky from ovoce
>where navyhozeni=1)
Borland Delphi 2005
[*] Slavomir Skopalik <skopalik(zv)elektlabs(tec)cz> - 14.10.2004 16:30:01
Me by spise zajimalo srovnani s Delphi 7 a 8.
Jakoby tam spousta veci z delphi 7 chybela
(napriklad IBX, Tchart, Indy, rave report, Quickreport, Apache...).
Pro .NET (pokud bych si to koupil) tak snad pro psani aspx stranek
v c#.
Duvod si to koupit je ale jedine ve win32 (a nejak si nejsem jist,
jestli bych si pomohl).
Slavek
> From: "Martin Pavera" <martin.pavera(zv)cmail(tec)cz>
> > Zajimaly by mne Vase nazory na nove Delphi 2005 ?
> > (V konferenci jsem zatim moc nazoru na nove Delphi nenasel...)
>
> Me by docela zajimalo, kolik lidi planuje pouzivat Delphi pro
> vyvoj .NET aplikaci.
>
> Petr Vones
>
>
>
>
>
> Cesta v servisni aplikaci
[*] tondrej(zv)t-online.de - 14.10.2004 13:49:46
> Predelavam jeden program na service a nemuhu nejak najit nahradu
> za Application.ExeName. Prosim o nakopnuti.
ParamStr(0) alebo GetModuleName(0)
HTH
TOndrej
Firebird a GBAK na velkou GDB
[*] Stepan Dobias <stepan.dobias(zv)del(tec)cz> - 15.10.2004 11:19:19
Uplne nerozumim pojmu Multigeneracni architektura? Mohl by mi nekdo tento
termin objasnit?
PS: K utilitam gfix a gbak pro FB1.0 bych podotknul jen tolik, ze jejich
pouziti mi pripada velmi zdlouhave (stejne velka DB na MS SQL-Serveru se pri
pouziti backupne za radove asi petinu casu nez na FB). A pouziti parametru
sweep u databaze s velikosti okolo 1,7 GB trva i desitky hodin.
Stepan
OT CASE pro MSSQL
[*] Milan Tomes <delphi(zv)haida(tec)cz> - 15.10.2004 09:47:12
S naprostou jistotou rikam - toto bohuzel NEJDE.
Z praxe ale poznavam, ze by to stejne nebylo mozne provest bez jedineho
rucniho zasahu.
S pozdravem
Milan Tomes
> [mailto:delphi-l-owner(zv)clexpert(tec)cz]On Behalf Of Pavel Polak
> Sent: Friday, October 15, 2004 9:43 AM
>
> CS2 vypada skvele,zbezne jsem s tim zkousel vytorit na zkousku par
> drobnosti, ale nikde jsem nedostal odpoved(ani v jejich diskusi
> na webu) na
> to, zda je mozne nejakym zpusobem vygenerovat rozdilovy skript
> mezi verzemi
Otevreni / Nacteni doc souboru
[*] Jiri Baudys <konference(zv)baudys.name> - 14.10.2004 17:10:04
Dobry den,
poprosim o radu, jestli nekdo nevite jak nacist doc soubor do RichEditu,
event. Mema.
Diky
jirka
Poznatek: WinXP SP2 a Skenovani portu
[*] TOROLA electronic - Bednarcik Dalibor <dalibor(zv)torola(tec)cz> - 15.10.2004 09:13:09
Ahoj,
primo z MS stranek
Limited number of simultaneous incomplete outbound TCP connection attempts
Detailed description
The TCP/IP stack now limits the number of simultaneous incomplete outbound
TCP connection attempts. After the limit has been reached, subsequent
connection attempts are put in a queue and will be resolved at a fixed rate.
Under normal operation, when applications are connecting to available hosts
at valid IP addresses, no connection rate-limiting will occur. When it does
occur, a new event, with ID 4226, appears in the system's event log.
jinak viz link
http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2netwk.mspx
> nepochopil jsem jestli Tve tvrzeni vychazi z jistoty, nebo se jen
> domnivas, ze to tak funguje.
> Jestli to prvni, je to nekde popsano na MSDN? Tohle by totiz
> vyresilo muj problem s jednim mym programem, ktery to taky zkousi na
vsechny
> strany a dele to trva nez nabehne (ale ne vzdy).
>
> Martin
>MySQL komponenty
[*] Fedor 'fi0dor' Tirsel <fi0dor(zv)fi0dor.info> - 15.10.2004 13:37:34
: stupidni dotaz - chci pracovat s MySQL v Delphi a nejak sem vcera nemohl najit
: dobre komponenty pro Delphi 7 (ent.) ... (kdysi sem mel Delphi 5 a pro ne sem
: je sehnal hned) ... napiste mi prosim nejaky link na vami overene komponenty
http://www.zeoslib.net/
:diky
S pozdravom...
--
Fedor 'fi0dor' Tirsel
www.fi0dor.info