2.5.9 embed x64 neotvori 32bit.databazu? (win10, c# .NET 4.8)

[Peter Turčan]

zdravim

mam apku .c# NET4.8 do teraz som pouzival x86 verzie embed kniznic firebird 2.5.x, 

chcem si apku rozbehat na 64bit, ale mi fbembed verzia firebirdu mi nechce otvorit DB, lebo vraj je nevalidny subor.

je vobec mozne fdb otvarat v 32 alebo 64bit verzii embed databazy podla potreby?

dakujem

Peter

[Jiří Činčura]

Databáze není závislá na platformě. Takže problém bude asi někde jinde. Nepíšeš jakou chybu dostáváš, bez toho se asi dál nedostaneme.

--
Mgr. Jiří Činčura
https://www.tabsoverspaces.com/

> --
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> „Firebird (CZ)“ ve Skupinách Google.
> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny,
> zašlete e-mail na adresu firebird_cz...@googlegroups.com.
> Chcete-li tuto diskusi zobrazit na webu, navštivte
> https://groups.google.com/d/msgid/firebird_cz/dc00d9b0-a246-4167-a8e6-64fb3e2f267bn%40googlegroups.com <https://groups.google.com/d/msgid/firebird_cz/dc00d9b0-a246-4167-a8e6-64fb3e2f267bn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Peter Turčan]

FBConnection.Open() hodi vynimku 

◢
$exception
{"file xxxx.FDB is not a valid database"}
FirebirdSql.Data.Common.IscException 

stacktrace je:   

   at FirebirdSql.Data.Client.Native.FesDatabase.ProcessStatusVector(IntPtr[] statusVector)

   at FirebirdSql.Data.Client.Native.FesDatabase.Attach(DatabaseParameterBuffer dpb, String dataSource, Int32 port, String database, Byte[] cryptKey)

   at FirebirdSql.Data.FirebirdClient.FbConnectionInternal.Connect()

a SQLSTATE = "HY000"

neviem, ci to pomoze

Dátum: sobota 5. decembra 2020, čas: 20:54:01 UTC+1, odosielateľ: ji...@cincura.net

[Peter Turčan]

a "FirebirdSql.Data.FirebirdClient.dll" mam nuget 7.1.1

Dátum: sobota 5. decembra 2020, čas: 21:47:00 UTC+1, odosielateľ: Peter Turčan

[Jiří Činčura]

To spíš vypadá, že ten soubor vůbec není FB databáze. Možná je poškozen (hlavička)?

--
Mgr. Jiří Činčura
https://www.tabsoverspaces.com/

> https://groups.google.com/d/msgid/firebird_cz/ef46da02-13c7-42dc-ae54-a3f2ae219544n%40googlegroups.com <https://groups.google.com/d/msgid/firebird_cz/ef46da02-13c7-42dc-ae54-a3f2ae219544n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Robert Kindl]

32 bit vs 64bit knihovna (nebo aplikace) nehraje roli. Podezrival bych poskozeni toho FDB souboru.

 

Pouziti FBEmbed totiz z vlastni velmi trpke zkusenosti nedoporucuji, protoze FB jednoduse vubec neni pripraveny na beh na klienstkych pocitacich.

Bohuzel. Temer kazdy necekany pad toho pocitace znamena vetsi nebo mensi poskozeni databaze.

A to z nekolika duvodu:

Disky vetsinou pouzivaji zapisovou kes, ale ta absolutne neni nijak zalohovana.

Klientske pocitace nejsou servery, jsou to casto levne a dosti nespolehlive pocitace.

Navic lidi vetsinou nemaji UPS, staci kdyz se vybije baterka v NTB, nebo vypadne na sekundu elektrika, vse se necekane vypne a poskozeni je na svete.

Bezny clovek si nedela zadne zalohy, a I kdyz by je delala aplikace sama, nedokaze je obnovit. A udelat automaticke obnoveni je docela problem a stejne se vzdycky neco ztrati (rollback).

 

A ta trpka zkusenost? Mam tu doslova stovky takto poskozenych databazi. Ano jsou to samozrejme jednotky procent vsech instalaci, ale porad je to dost aby to lidi vnimali negativne.

 

Proste sumarne: uz bych FBEmbeded nikdy na nic nepouzil.

 

Rob

--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny „Firebird (CZ)“ ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu firebird_cz...@googlegroups.com.

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/firebird_cz/dc00d9b0-a246-4167-a8e6-64fb3e2f267bn%40googlegroups.com.

[Peter Turčan]

tak nejaky problem bol v DB. ked som spravil backup&restore, tak to uz ide aj v 32 aj v 64bit verzii
ale pred tym to v 32bit.verzii islo. divne

Dátum: sobota 5. decembra 2020, čas: 22:02:35 UTC+1, odosielateľ: ji...@cincura.net

[Peter Turčan]

ok. lenze ak mam aplikaciu, ktora bezi na lokalnom PC a kde potrebujem lokalnu DB tak mi LAMA user nenainstaluje server (win servicu) a tam sa embed DB javi dobra volba. Prave na to je urcena, nie?

Ako by si to riesil inak?

Dátum: sobota 5. decembra 2020, čas: 22:33:11 UTC+1, odosielateľ: rob

[Robert Kindl]

No FBserver na klientskem pocitaci ti samozrejme nepomuze.

Ja to myslel tak, ze Firebird obecne proste neni staveny pro beh na klientskem pocitaci, ktery trpi jiz popsanymi neduhy.

Proste na serveru takovy problem obvykle neni:

Tam je zapisova cache bud vypnuta, nebo zalohovana specialni baterii na diskovem kontrolleru. A je tam UPS. A obecne spolehlivost takoveho stroje je uplne jinde.

 

A ten FBEmbed.dll prestoze se jevi jako ze by neco v tomto smeru mohl neco resit, tak neresi podle mne nic.

A soucasne vlastne nepotrebuju nic z toho co resi skutecny server – napr. multiuser prostredi atp.

 

A reseni? No nejak moc dobre reseni neexistuje – to, ze se po padu pocitace na disk zapise polovina ze zmen, ktere jsem udelal v posledni minute... s tim se vyrovna jen malo co.

 

Napr. plnotucny MSSQL server to asi dokaze – tak, ze zapisuje paralelne do transakniho LOGu (ve FULLRecovery rezimu) a z tohoto logu dokaze sam prehrat a konzistentne obnovit hlavni databazi. Nerikam, ze se to neda rozbit, ale rozhodne je to o 10000% robustnejsi reseni.

 

Obecne tedy je potreba mit nejaky“samoopravny” mechanismus, ktery bud bude vestaveny bud v “SQLserveru” a nebo v aplikaci.

Asi bych zkusil SQLite... tam je cilem prave to lokalni ulozeni dat a nikoliv “velky server” pro X uzivatelu.

Proste pokud si troufas vyresit detekci a backup/restore pomoci FB, klidne bez do toho. Ale to bez nejakych dalsich nastroju jako GFIX apod. v podstate nejde.

Ono dokonce i obycejne zazipovane XML (JSON) soubory budou lepsi nez nez FB, protoze tam mam aspon sanci v aplikaci jednoduse detekovat poskozeni toho ZIPu a pripadne se vratit k nejake predhozi verzi toho ZIP souboru (neboli zaloze).

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/firebird_cz/cc33b8a6-1603-4417-9a95-86a82ec715cdn%40googlegroups.com.

[okbob]

Dne sobota 5. prosince 2020 v 23:20:25 UTC+1 uživatel rob napsal:

No FBserver na klientskem pocitaci ti samozrejme nepomuze.

Ja to myslel tak, ze Firebird obecne proste neni staveny pro beh na klientskem pocitaci, ktery trpi jiz popsanymi neduhy.

Proste na serveru takovy problem obvykle neni:

Tam je zapisova cache bud vypnuta, nebo zalohovana specialni baterii na diskovem kontrolleru. A je tam UPS. A obecne spolehlivost takoveho stroje je uplne jinde.

s tim bude mit problem libovolna databaze. Pokud nemate jisteny disk, tak write cache na disku by mela byt vypnuta.

resp. provoz firebirdu se zapnutou nejistenou write cache mi nedava smysl. To si koledujete o velky problem. A poskozeni databaze muze nastat prakticky u jakekoliv databaze. Tam je Firebird asi v nevinne. Pokud se datove soubory nesyncnou na fsync (z duvodu cache), tak to nemusi prezit libovolna databaze.

[Jiří Činčura]

Pojdme si rozdelit pojmy a dojmy. Protoze je tady nekolik veci, ktere se michaji veci do sebe.

> Disky vetsinou pouzivaji zapisovou kes, ale ta absolutne neni nijak
> zalohovana.

Je treba rozlisit extra radice (napr. RAID) a jejich logiku ve spojeni s pritomnosti nebo absenci BBU. Opravdu tyto extra radice, v klientskych PC, vetsinou nedisponuji BBU a je tedy velmi pravdepodobne, ze se neco pokazi. Vetsinou je to ale napr. cele diskove pole nebo FS, ne jen jeden soubor skryte. Ale mozne je samozrejme cokoli.

Nicmene normalni klientske stanice, vetsinou maji nejake SSDcko v M.2 nebo SATA a tyhle disky (pokud vynecham nejake pochybne "vyrobce") i pri vypadku napajeni maji dostatek energie na zapsani prave te sve cache. Ale mozne je samozrejme cokoli.

No a ted Firebird ma neco cemu se rika forced writes a take careful writes. Prvni znamena, ze zapisy na disk nejsou nikde kesovane a jeste k tomu je to (zjednodusene receno) fsyncnuto. Vypnout se to da, ale potom si musim byt sakra jist (a i v tom pripade bych mel mit pripraven plan B), ze na to mam HW, OS a pripadne virtualizacni platformu. Druha vec rika, ze zapisy se deji tak, aby nemohlo dojit k logicke nekonzistenci souboru. Opet zjednodusene; nejdriv zapisu data a pak az ukazatele na data. Takze pri padu aplikace/serveru sice muzu prijit o data, ale soubor zustane logicky konzistentni (v souboru je bordel, mozna spatna data, ale nikdo na ne neukazuje).

> A ta trpka zkusenost? Mam tu doslova stovky takto poskozenych databazi.
> Ano jsou to samozrejme jednotky procent vsech instalaci, ale porad je
> to dost aby to lidi vnimali negativne.

Dohlizim na provoz asi 1400 Firebird DB a souhlasim, ze temer vsechna poskozeni co jsem zazil je mozne pripsat chybe HW. Ale urcite to neni tim, jestli to byl Firebird server nebo embedded.

> Napr. plnotucny MSSQL server to asi dokaze – tak, ze zapisuje paralelne
> do transakniho LOGu (ve FULLRecovery rezimu) a z tohoto logu dokaze sam
> prehrat a konzistentne obnovit hlavni databazi. Nerikam, ze se to neda
> rozbit, ale rozhodne je to o 10000% robustnejsi reseni.

Tak urcite. Nejprve tvrdis, ze se neco nezapise na disk a pak spolehas na transakcni log? A zapisy do transakcniho logu se nikdy magicky neposkodi? Transakcni log nebo MVCC to mas fuk. Jinak mimochodem nic jako paralelni zapis do tx logu neni - mame treba undo/redo/WAL log. A tak jako tak disk vzdy bude provadet jednu operaci za druhou.

> Obecne tedy je potreba mit nejaky“samoopravny” mechanismus, ktery bud
> bude vestaveny bud v “SQLserveru” a nebo v aplikaci.

V tom pripade si nepochopil jak funguje transakcni log v MS SQL a k cemu je nebo TIP ve Firebirdu. Nebo oboji. Dej mi 10 sekund a naborim obe DB k nepoznani.

> Asi bych zkusil SQLite... tam je cilem prave to lokalni ulozeni dat a
> nikoliv “velky server” pro X uzivatelu.

Zkusit se da cokoli.

> Ono dokonce i obycejne zazipovane XML (JSON) soubory budou lepsi nez
> nez FB, protoze tam mam aspon sanci v aplikaci jednoduse detekovat
> poskozeni toho ZIPu a pripadne se vratit k nejake predhozi verzi toho
> ZIP souboru (neboli zaloze).

Opravdu? Jednak misto XML/JSON muzu klidne ZIPovat tu DB a jsem tam kde jsem byl. Navic mam ACID, procedury, funkce, ... A jednak jakmile se nabori ten ZIP - pamatuj mozne je samozrejme cokoli - tak jeho rozbaleni bude v beznych podminkach nemozne. Ale pokud se "nastesti" nabori ve Firebird souboru jen datova stranka, muzu relativne trivialne DB "obnovit" a prijit jen o data v te strance. Coz asi uznas je docela dobry vysledek.


Shrnuto a podtrzeno: Pokud se bavime jen o HW chybach, je jedno jakou DB pouzivas. Pri trose (ne)stesti bude Firebird, MS SQL, SQLite, Postgres, DB2, Oracle v riti.

[Robert Kindl]

Ono zalezi na aplikaci, asi se tady nebavime o tom, ze by se v aplikaci
bezici na klientu pocitaly nejaky super dulezity bankovni transakce kde se
"nesmi nic ztratit a je to 24/7 system"...

Jako jednoduchy priklad aplikace muze byt treba nejaky seznam kucharskych
receptu. A co konkretne to znamena pro tu "spolehlivost" databaze?
A) uzivatel dokaze pochopit, ze kdyz mu vypadne proud nebo spadne pocitac
tak se udela "rollback" databaze do nejakeho KONZISTENTNIHO bodu v
minulosti. Rad sice nebude, ale ve sve podstate to oznaci jako svoji chybu
(nemam UPS, nemam spolehlivy pocitac...)

B) co ale nedokaze pochopit je kdyz aplikace nenastartuje a hodi "corrupted
database"... a nazdar... to jako si ma ten bezny uzivatel udelat obnovu sam
? Mozna kdyby mel za zadkem nejake IT oddeleni, ale I to by za chvili
prskalo, ze musej furt neco obnovovat. A ze zkusenosti vim, ze poskozeni te
Firebird Databaze je casto neopravitelne, data nekonzistentni, proste uloha
pro programatora na dlouhe zimni vecery aby to uvedl zase do nejakeho trochu
konzistentniho stavu.

C) Abych se ze stavu B dostal do stavu A tak musim delat nejaky pravidelny
zalohy, nebo snapshoty a hlavne automatizovane rozeznat tu poskoznou
databazi IHNED pri prvni startu aplikace (a ne po dalsich X hodinach prace -
protoze pak uz ten rollback pomoci obnovy nebude jednoduse mozny). A to je
dost tezko resitelne - hlavne programove a kdyby nic jineho tak to bude
brzdit kazdy start aplikace - tim ze se bude kontrolovat konzistence UPLNE
cele databaze.

A tady je to misto kde rikam, ze ZIPed-XML je podle mne jednoduchy - tam
konzistenci zkontroluju snadno - a pokud je to vadny vratim se k prechozimu
ZIPu (prechozi ulozene verzi databaze) to je samozrejme scenar, ktery nemusi
kazde aplikaci vyhovovat, ale na ty "recepty" bych to pouzil uplne klidne.
Ostatne neni Zipped XML nahodou napr. OpenOffice? MS Office? a vubec skoro
kazdy fileformat v posledni dobe? A kazda tato aplikace si poradi s
"padem" - nabidne automatickou obnovu - a o to mi prece jde - uzivatel mozna
prijde o poslednich par editaci, ale neprijde komplet o cely dokument a
nemusi delat zadny rucni obnovy, opravy apod!

A pokud se vysypal cely filesystem? No tak to mi samozrejme neni pomoci, ale
treba NTFS v tomhle smeru ma co nabidnout (transaction journal) a rozbit
uplne kompletne adresarovou strukturu neni az tak snadne.

K tomu MSSQL: tam lze prehrat transakce az do urciteho bodu - podle mne neni
vubec snadne toto rozbit. Nerikam, ze kdyz vezmu "random" binary writer a
budu prepisovat kusy toho souboru nebo pokud kdyz bude disk "chybovat a cist
nejaky garbage" tak se to s tim vyrovna - k tomu to urcene neni. Ale dokaze
se to bez problemu vyrovnat s tim, ze poslednich X transaknci je nekompletne
nebo nekonzistentne zapsanych - proste tyto transakce (a vsechny dalsi) se
rollbacknou pri startu databaze. Rozhodne nerikam, ze plnotucny MSSQL je
nejak extra vhodny na klientsky pocitac, ale rikam ze takovy system
existuje - ale bohuzel FB nic takoveho nenabizi.

Resp. ja opravdu netusim jak funguje TIP a/nebo jak ho pouzit. Nejaky tip
jak TIP pouzit aby se FB databaze tak snadno nekazily a bylo to spolehlive
aspon jako Office .docx soubor?

Diky
Rob

-----Původní zpráva-----
From: Jiří Činčura
Sent: Sunday, December 6, 2020 7:07 PM
To: fireb...@googlegroups.com
Subject: Re: 2.5.9 embed x64 neotvori 32bit.databazu? (win10, c# .NET 4.8)

--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny Firebird
(CZ) ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny,
zašlete e-mail na adresu firebird_cz...@googlegroups.com.

Chcete-li zobrazit tuto diskusi na webu, navštivte
https://groups.google.com/d/msgid/firebird_cz/bd0246e3-b250-430e-81e8-ca10b7e2ad32%40www.fastmail.com.

[Slavomir Skopalik]

Zde bych mel par poznamek:

1. Je trochu mimo misu srovnavat zip/xml jenz edituji primo v RAM proti
jakekoliv DB.

2. S DB muzete pracovat stejne jako se zipem (administrace systemu
Pohoda je dodnes moje nocni mura, jelikoz pri kazdem upgrade vytvari
novou DB a prekopirovava data).

  Nicmene prekopirovani Firebird DB pred jejim otevrenim neni zadny
problem. Lze pouzit stejne postupy jako u zipu.

  Nicmene, porad se bavime o velikostech max jednotek GB.

3. Konzistenci dat lze overit asynchrone a neblokovat uzivatele. Overeni
xml je velmi narocne (nutnost rozzipovat a aplikovat XSD validaci).

4. Pokud overeni trva dlouho (DB velikosti desitek ci stovek GB) je
iluzorni, ze by se data ve forme XML vesla do RAM

5. Selhani HW (ne disku jako takoveho) spolehlive poskodi cokoliv vcetne
NTFS (ReFS se umi poskodit zcela sam bez cizi pomoci).

  Ono totiz casto dojde k zapisu do uplne jineho sektoru, nez melo dojit.

  Mel jsem tu cest takove situace resit (napriklad radic prohlasil, ze
disky nejsou jeho a nerozumi jejich konfiguraci) a vetsi problem byl
poskladat souborovy system, nez databaze na nem ulozene.


Poznamka:

Osobne pro vyvoj pouzivam trick s nbackup, kdy aplikuji pocatek
nbackupu, fb pak vsechny zmeny uklada do delta souboru.

Potom staci zahodit delta soubor a jsem v puvodni stavu.

Nicmene moji motivaci nebyla ochrana proti poskozeni, ale abych se mohl
rychle vracet k puvodni DB kdyz ji sam pri vyvoji

znehodnotim. Velikosti DB jsou od desitek po stovky GB.

Slavek

Ing. Slavomir Skopalik
Executive Head
Elekt Labs s.r.o.
MASA - Collection and evaluation of data from machines and laboratories
http://eng.elektlabs.cz/products-and-services/masa
-----------------------------------------------------------------
Address:
Elekt Labs s.r.o.
Chaloupky 158
783 72 Velky Tynec
Czech Republic
---------------------------------------------------------------
Mobile: +420 724 207 851
icq:199 118 333
skype:skopaliks
e-mail:skop...@elektlabs.cz
http://www.elektlabs.cz

[Robert Kindl]

ad 1. Proc? Pro jednoduche veci to zcela postacuje. Stejne se dneska vetsina
veci dela pomoci nejakych mapperu, ktere ukladaji objekty do databaze,
rozdil v ulozeni do XML/JSON je dost maly. A zejmena pro SINGLE user
databazi na klientu je ukladani do plnotucne databaze v podstate totalni
overkill (bavim se porad o tom FBEmbeded, nikoliv o tom, ze bych nahrazoval
databazovy server).

ad 2. kopirovani neni problem - az na to, ze kopie poskozene databaze je k
nicemu, takze nejen ze budu mit poskozenou databazi, ale I zaloha bude
obsahovat poskozeny obsah

ad 3. to uz je pozde, tezko muzu uzivateli po 1,2,5, 10 minutach praci
oznamit "sorry, databaze je pokozena, zahodim vse co jsi behem poslednich X
minut udelal, rollback". To by byla doslova nocni mura.
Overovat XML nemusim, staci overit ZIP coz je dost trivialni a uz vubec na
to netreba XSD.

ad 4. viz. 3 - ZIP nemusim davat do pameti cely. Navic pro smysluplnou praci
i u databaze plati, ze bych mel mit zhruba tolik RAM kolik je "aktivni cast"
databaze. A porad nevim jaka databaze provozovana pomoci FBEmbeded bude mit
nekolik GB? Opakuji, ze se porad bavime o provozu aplikace na klientu - s
lokalnim ulozenim. Nikoliv o tom, ze nejaky notebook bude delat server pro
celou banku... ty doby jsou snad uz pryc...

ad 5. Tak selhani disku, radice, pameti urcite dokaze poskodit ledacos, to
se nijak nerozporuju. Jedine o cem se tady bavim je snaha udelat ukladani
dat na klientskem pocitaci co "nejspolehlivejsi" a odolne alespon na
trivialni vypnuti notebooku kvuli baterii, docasny vypadek elektriny, proste
to co na serveru neni tolik treba resit.

Trik s nbackup neznam - ale pripomina mi to alespon smer toho co by bylo
potreba - neznicit databazi (kdyz do ni nezapisuji, tak se nemuze znicit) -
a pak napr. aplikovat zmeny jednou za cas ze zmenoveho logu a takhle to
sunout vpred. Jen to asi bohuzel asi pripravene na nejaky kontinualni
provoz.

Rob


-----Původní zpráva-----
From: Slavomir Skopalik
Sent: Monday, December 7, 2020 12:36 AM

--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny Firebird
(CZ) ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny,
zašlete e-mail na adresu firebird_cz...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte

https://groups.google.com/d/msgid/firebird_cz/2fd26fbd-f382-f3eb-ad74-7ffa3e6923b3%40elektlabs.cz.

[Jiří Činčura]

> ad 1. Proc? Pro jednoduche veci to zcela postacuje. Stejne se dneska vetsina
> veci dela pomoci nejakych mapperu, ktere ukladaji objekty do databaze,
> rozdil v ulozeni do XML/JSON je dost maly. A zejmena pro SINGLE user
> databazi na klientu je ukladani do plnotucne databaze v podstate totalni
> overkill (bavim se porad o tom FBEmbeded, nikoliv o tom, ze bych nahrazoval
> databazovy server).

Ano, treba takove filtrovani v JSONu je uple v pohode, protoze mam indexy (ktere se idealne vlezou do pameti a nemusim tam mit cely soubor), ..., oh wait.

> ad 5. Tak selhani disku, radice, pameti urcite dokaze poskodit ledacos, to
> se nijak nerozporuju. Jedine o cem se tady bavim je snaha udelat ukladani
> dat na klientskem pocitaci co "nejspolehlivejsi" a odolne alespon na
> trivialni vypnuti notebooku kvuli baterii, docasny vypadek elektriny, proste
> to co na serveru neni tolik treba resit.

Pokud pri tom vypadku elektriny nedojde k nejakemu necekanemu chovani HW, tak se DB neposkodi, protoze kazdy DB engine s timhle pocita, je to zakladni vlastnost ACID. A je jedno jestli je to MS SQL, Firebird, Postgres nebo neco jineho.

[Robert Kindl]

>Ano, treba takove filtrovani v JSONu je uple v pohode, protoze mam indexy
>(ktere se idealne vlezou do pameti a nemusim tam mit cely soubor), ..., oh
>wait.

Nezlob se, ale to je asi stejne validni argument jako, ze nejde v MSWordu
vyhledavat, protoze to DOCX (zazipovane XML) by se muselo zindexovat a
neveslo by se do pameti...
A co teprve chudak nejaky search server, ktery tech DOCX ma plny archiv...

Tahle diskuse nema byt o jakemsi dokazovani si, ze na nekolika GB databazi
potrebuju poradny SQL - a hlavne poradny SERVER! a nikoliv FBEmbeded nebo
SQLite nebo XML - to nikdo nikdy nerozporoval.
Ja se bavim o jednoduche aplikaci, ktera ma bezet na klientskem desktopu a
uklada si lokalne data - obecne tedy o pouziti FBEmbeded...
Ono kdybych chtel byt trochu moderni, tak bych je ukladal ne lokalne, ale do
cloudu. Kdyz budu ukladat XML v ZIPu tak mi staci single blob nekde v cloudu
a jsem v pohode.
Takhle funguje treba google drive a spousta aplikaci si tam umi ulozit svoje
data (ano ja vim, ze si tam muzu ulozit zalohu FB databaze, ale opravdu je
tohle dobre reseni?)

>> ad 5. Tak selhani disku, radice, pameti urcite dokaze poskodit ledacos,
>> to
>> se nijak nerozporuju. Jedine o cem se tady bavim je snaha udelat ukladani
>> dat na klientskem pocitaci co "nejspolehlivejsi" a odolne alespon na
>> trivialni vypnuti notebooku kvuli baterii, docasny vypadek elektriny,
>> proste
>> to co na serveru neni tolik treba resit.

> Pokud pri tom vypadku elektriny nedojde k nejakemu necekanemu chovani HW,
> tak se DB neposkodi, protoze kazdy DB engine s timhle pocita, je to
> zakladni vlastnost ACID. A je jedno jestli je to MS SQL, Firebird,
> Postgres nebo neco jineho.

Ano a to je PRESNE to co tady od zacatku ROZPORUJU a psal jsem tu hned v
prvnim emailu. Nechci se tu zbytecne opakovat, vsichni vime,
ze doma nebo na notebooku bezny lidi nemaji radice diskovych poli, nemaji
Raid1, nemaji vypnute write cache, nemaji SSD a uz vubec ne M2 disky...
Nekteri ano - NTB vymenili, kdyz uz jeho baterie nevydrzela ani 10 minut a
pak se vypla nebo kdyz se pocitac samovolne restaroval 5x za vecer pri
brouzdani na internetu.
A kdyz aplikace tyhle pady nevydrzi...tak je to v ocich lidi chyba
aplikace - a ja rikam, je chyba FB, ze v tomhle vubec nepomaha...

Protoze ACID - zejmena ve vyznamu D=durability je ve firebirdu velmi
spatny - viz. zde
https://firebirdsql.org/file/documentation/papers_presentations/html/paper-fbent-acid.html
MGA muze byt uzasna vec, ale to okopirovani funkcionality ostatnimi podle
mne melo uplne jinou motivaci nez zajisteni Durability (konkretne to spis je
o reseni Snapshot Isolation).

Realne na kazde poskozeni FB reaguje exception (a nikoliv automatickou
opravou databaze) a tak to MGA proste zadnou Durability nezajistuje.
Namatkou par exception z posledni doby:
internal Firebird consistency check (wrong record length (183), file:
vio.cpp line: 1187)
Nebo:
database file appears corrupt wrong page type page 14349 is of wrong type
(expected 5, found 8)

Tech rozbitych FB databazi tu mam stovky a vsechny maji spolecny
jmenovatel - ty lidi delali na svem "KRASNEM UZASNEM DOMACIM" pocitaci po
dlouhe dobe poprve neco jineho nez pousteli browser ... a pak se jim
restartoval pocitac.
Vysvetluju si to tak, ze kdyz procesor videl ty 3 fotky z fotaku co ten
uzivatel dneska vyfotil, tak to radeji vzdal a vypnul se :-)

Takze naposledy, pokud je nejaka moznost ve firebirdu zapnout neco navic aby
se data nejak redundatne ukladala/logovaly transakce a nenicila tak snadno
databaze, budu rad pokud se o takove moznosti dozvim a zapnu ji...

Rob

[Slavomir Skopalik]

1. Vzdy force write ON

Meli ty poskozene DB toto nastaveno? Jaka byla verze FB?

2. Je to prave naopak, servery jsou na vypadek citlivejsi, jelikoz se
pouziva i nekolik GB RAM zalohovane baterii.

Pri vypadku teto baterie se ztrati veskere zapisy a dost nepekne to
rozbori nejen DB ale i file system.

3. FB bezne pouzivam i na PC, jenz se vypinaji sitovym vypinacem misto
shutdown a bez problemu.

Nicmene, muzete pouzit zmineny nbackup, mohlo by vam to teoreticky
pomoci (impkuje, ze file system zustane v pohode).

Dale bych upozornil, ze FB3 v podstate funguje az od verze 3.0.7. Dale
nejsou na skodu privatni buildy od IBPhoeninx.

U embeded verzi hrozi jine riziko a to, ze nezodpovedny programator
hrabne do RAM, kde me FB sva data.

Nicmene, toto je spolecne vsem inprocesses resenim.

https://www.firebirdsql.org/pdfmanual/html/nbackup-background.html

Slavek

[Robert Kindl]

ad 1. na Forced Write jsem nijak nesahal - mel by to byt default
gstat -h vypisuje:
Attributes force write
Takze ano - vzdy je nastaveno ForceWrite

Verze FBEmbeded je u starsich instalaci 2.5.3, nekde i novejsi 2.5.X, ale na
3.0 jsem zatim neprechazel v podstate z toho duvodu, ze bychom spise radeji
z toho celeho ten FBEmbeded vypustili (I kdyz k tomu asi tak snadno
nedojde).

ad 3. vsechno zalezi na aktivite, samozrejme neni problem kdyz se pocitac
vypne kdyz aplikace zrovna nic nedela. Jenze jak jsem uz psal - ty klientske
pocitace maji tendenci se vypinat pri zatezi, proste doslova lidem pod
rukama.

ad 4. Inprocess prepisovani pameti si nemyslim, ze by bylo duvodem - cele
aplikace je v .NET temer jedina unmanaged cast je prave ten FBEmbeded. Navic
v logu pred tim poskozenim je vzdy videt neocekavane ukonceni aplikace a i
uzivatele hlasi "pocitac se mi vypnul" - dokonce jsou i takovy lidi, ze z
toho vypinani obvinuji nasi aplikaci - protoze kdyz brouzdaj internetnem tak
jim to tolik nepada...

NBackup by mohl byt reseni pro nejake kontinualni zalohovani dat - diky za
tip.
Obecne zalohovani jsme samozrejme resili, ale jak jsem uz rikal - hlavnim
problemem neni zalohovani, ale detekce poskozeni pri startu aplikace - tak
aby uzivatel nepracoval s necim, co stejne bude potreba zahodit.

Rob


-----Původní zpráva-----
From: Slavomir Skopalik

Sent: Tuesday, December 8, 2020 11:58 AM

To: fireb...@googlegroups.com
Subject: Re: 2.5.9 embed x64 neotvori 32bit.databazu? (win10, c# .NET 4.8)

--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny Firebird
(CZ) ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny,
zašlete e-mail na adresu firebird_cz...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte

https://groups.google.com/d/msgid/firebird_cz/10672645-f646-8c8b-9b0b-e1fa8e67d07c%40elektlabs.cz.

[Jiří Činčura]

> Nezlob se, ale to je asi stejne validni argument jako, ze nejde v MSWordu
> vyhledavat, protoze to DOCX (zazipovane XML) by se muselo zindexovat a
> neveslo by se do pameti...
> A co teprve chudak nejaky search server, ktery tech DOCX ma plny archiv...

Ja se nezlobim. Jen mi prijde divne, proc treba takove to hledani ve Windows prave treba DOCX indexuje bokem... Mozna proto, ze ty indexy maji neco do sebe? Stejne tak treba SharePoint (i kdyz SharePoint je ostrov sam pro sebe).

> Protoze ACID - zejmena ve vyznamu D=durability je ve firebirdu velmi
> spatny - viz. zde
> https://firebirdsql.org/file/documentation/papers_presentations/html/paper-fbent-acid.html

Nejak jsem tam minul to, ze D je ve Firebirdu "velmi spatny". Muzes me na relevantni cast nasmerovat?

> Takze naposledy, pokud je nejaka moznost ve firebirdu zapnout neco navic aby
> se data nejak redundatne ukladala/logovaly transakce a nenicila tak snadno
> databaze, budu rad pokud se o takove moznosti dozvim a zapnu ji...

Pokud nehledas jen magicky switch, ktery vyresi vsechny tvoje problemy, ale jses ochoten i neco delat (a mozna neco hodne, podle toho o jakou aplikaci jde a co dela), napis mi email a ja ti ukazu, ze stejne stabilni vec jako XML muzes udelat i s FB databazi. Mozna to bude bolet, mozna se ti to nebude libit, ale predchozi architektonicka rozhodnuti nekdy boli.

[Robert Kindl]

ad indexovani, DOCX apod. - to je asi na samostatne diskusni vlakno, uz to
zacina byt offtopic

ad ACID Durability ve firebird - implementace spoleha na MGA a nikoliv na
logovani tak jak to delaji jinde (Oracle ARCHIVELOG mode, MSSQL -
FullRecoveryMode). A to ze to je nedostatecne mohu dokazat temi stovkami
incidentu s narusenymi databazi na klientskych desktopech pouzivajicich
FBEmbeded, detailnejsi rozbor proc to neni dostatecne pochopitelne nemam -
neni v mych silach hledat to ve zdrojovych kodech, ja jen vidim ten
vysledek - ktery neni uspokojivy.

ad magicky switch
- ve vedlejsi diskusi jsem se dozvedel o nBackup a FORCE WRITE (coz je
doslova magicky switch) - ani jedno sice neni resenim (protoze magicky FORCE
switch je nastaven spravne a nestaci to), ale diky za to
- ano jsem ochoten neco delat (neslo by tyhle narazky na neci lenost
vynechat?) - napr. delam to, ze se snazim problem vysvetlit a hledam reseni
a doufam, ze mi nekdo neco poradi.
Pokud tedy mas nejaky tip jak to "durability" vylepsit urcite si to rad
poslechnu/prectu.

Diky
Rob

-----Původní zpráva-----
From: Jiří Činčura

Sent: Tuesday, December 8, 2020 12:53 PM

To: fireb...@googlegroups.com
Subject: Re: 2.5.9 embed x64 neotvori 32bit.databazu? (win10, c# .NET 4.8)

--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny Firebird
(CZ) ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny,
zašlete e-mail na adresu firebird_cz...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte

https://groups.google.com/d/msgid/firebird_cz/a2d9ff86-d194-4daf-bb73-bee0dae40029%40www.fastmail.com.

[Jiří Činčura]

> ad ACID Durability ve firebird - implementace spoleha na MGA a nikoliv na
> logovani tak jak to delaji jinde (Oracle ARCHIVELOG mode, MSSQL - FullRecoveryMode).

Zajimalo by me, odkud lide berou, ze transakcni log je neco vic nez MVCC/MGA. Stejne tak zamykani a MGA/MVCC. Prece write-ahead logovani a shadow paging zajisti to same.

> A to ze to je nedostatecne mohu dokazat temi stovkami
> incidentu s narusenymi databazi na klientskych desktopech pouzivajicich

Nemuzes. Protoze nevis, jestli za to mohl Firebird nebo jineho, treba ten zminovany HW.

> - ano jsem ochoten neco delat (neslo by tyhle narazky na neci lenost
> vynechat?) - napr. delam to, ze se snazim problem vysvetlit a hledam reseni

Neslo. Protoze za poslednich (cojavim) 10+ let, mam pocit, ze kdykoli za mnou lide prijdou s nejakym problemem (jedno jestli C#, API, Firebird, ...), mysli, ze jim reknu at neco zmeni z true na false a jejich problem zmizne. Kdyz jim reknu realne reseni a uvidi, ze jim to bude trvat 3 tydny udelat, jsou z toho tak nejak smutni. Tak jsem tomu tady chtel predejit.

[Robert Kindl]

Ad MVCC/MGA
Podle mne to je neco uplne jineho nez logovani a resi to uplne jiny
problem - ACID isolation.
Ja mam konkretne docela obsahle zkusenosti s Oracle a MSSQL.
Oba systemy MVCC pouzivaji - nicmene na implementaci SNAPSHOT isolation modu
a na zajisteni ACID Durability pouzivaji logovani.
Firebird se tvari ze tim vyresi oboji, coz mozna muze omezene fungovat, ale
zcela jiste to nemuze byt tak robusni jako logovani MSSQL a Oracle jednoduse
z toho duvodu, ze tam staci logy zapisovat na jiny disk nez databazi (nebo
pripadne na nekolik disku paralelne v pripade Oracle) a jednoduse tak
docilim toho, ze kdyz se neco nabori ... tak v podstate totez mam ulozeno
jinde. Navic to rovnou slouzi i pro online zalohovani, pro "point-in-time"
restore atd.
Nakolik neco z toho je mozne ve Firebird to se priznam, ze netusim - mohu
napr. nejak obnovit JENOM z *.FDB souboru stav k "nejakemu" okamziku tj.
napr. ve 12:30 kdy vim, ze uzivatel vymazal nejaka dulezita data? Nebo
obnovit do stavu 10minut pred selhanim/vypadkem?

Samozrejme si uvedomuju, ze MSSQL a zejmena Oracle jsou trochu jina liga.
Ale to prece neni duvod k tomu, nesnazit se alespon v urcitych parametrech o
neco podobneho.

Takze otazka je jestli jak mi to MVCC muze pomoci s obnovenim tech
narusenych DB? Ted v nouzi pouzivam GFIX -m -f -ignore a pak GBAK, ale
nemuzu rict, ze by tou opravou vznikaly konzistentni data, rozhodne to neni
automatizovane pouzitelne...

A opet tedy: lze tedy nejak strucne rict, jak jinak bych mel problem detekce
poskozeni a automaticke obnovy resit?

Diky
Rob


-----Původní zpráva-----
From: Jiří Činčura

Sent: Tuesday, December 8, 2020 2:57 PM

To: fireb...@googlegroups.com
Subject: Re: 2.5.9 embed x64 neotvori 32bit.databazu? (win10, c# .NET 4.8)

--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny Firebird
(CZ) ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny,
zašlete e-mail na adresu firebird_cz...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte

https://groups.google.com/d/msgid/firebird_cz/3e058938-6fc5-432c-aa99-58548bb6894f%40www.fastmail.com.

[Jiří Činčura]

> Podle mne to je neco uplne jineho nez logovani a resi to uplne jiny
> problem - ACID isolation.

To je asi na diskuzi u piva, tady by to bylo na dlouho.

> Firebird se tvari ze tim vyresi oboji, coz mozna muze omezene fungovat, ale
> zcela jiste to nemuze byt tak robusni jako logovani MSSQL a Oracle jednoduse
> z toho duvodu, ze tam staci logy zapisovat na jiny disk nez databazi (nebo
> pripadne na nekolik disku paralelne v pripade Oracle) a jednoduse tak
> docilim toho, ze kdyz se neco nabori ... tak v podstate totez mam ulozeno
> jinde. Navic to rovnou slouzi i pro online zalohovani, pro "point-in-time"
> restore atd.

[1]
Ted jsem te pochopil! Ty resis dve veci dohromady. D u transakci a *zaroven* ulozeni/obnovu nejakych starych dat, u kterych aktualni transakce nehraje roli. Ale kazde z toho je neco jineho. D (v ACID) mi uz neresi co se stane tyden pote co transakce skoncila a nekdo nejak naboril DB. To je odlisny problem.

> Nakolik neco z toho je mozne ve Firebird to se priznam, ze netusim - mohu
> napr. nejak obnovit JENOM z *.FDB souboru stav k "nejakemu" okamziku tj.
> napr. ve 12:30 kdy vim, ze uzivatel vymazal nejaka dulezita data? Nebo
> obnovit do stavu 10minut pred selhanim/vypadkem?

Ano i ne. Udelat to jde. Ale Firebird k tomu nenabizi zadne nastroje (pokud by slo jen o FDB).

Jinak se da pouzit uz treba prave zminovany nbackup a delat inkrementalni zalohy a tim udelat PITR.

> Takze otazka je jestli jak mi to MVCC muze pomoci s obnovenim tech
> narusenych DB? Ted v nouzi pouzivam GFIX -m -f -ignore a pak GBAK, ale

MVCC nepomuze, protoze je to neco jineho. Viz [1].

> nemuzu rict, ze by tou opravou vznikaly konzistentni data, rozhodne to neni
> automatizovane pouzitelne...
>
> A opet tedy: lze tedy nejak strucne rict, jak jinak bych mel problem detekce
> poskozeni a automaticke obnovy resit?

Podobneho chovani jako DB soubor+log, kde ty chces alespon z jednoho neco vylovit, se da dosahnout treba pouzitim shadow files (prave treba na ruzne disky).
https://www.firebirdsql.org/pdfmanual/html/gfix-shadow.html#gfix-shadow-activate

[Robert Kindl]

Aha, no jasne, takze v tom je ten problem. Ja jak jsem zvykly z MSSQL/Oracle na ty logy tak jsem nedusledne rozlisoval ACID (transakce ano/ne), Recovery databaze po padu serveru (coz resi prave ten problem s writecache apod.) a Point-inTime-Restore ve smyslu obnovy databaze. A neumel jsem se asi vymacknout, co vlastne bych to od FB ocekaval za funkcionalitu.Je to skoda, ze tohle neni mozne, asi bohuzel bud budeme muset ten FB zkusit necim nahradit (netusim moc cim) a nebo skutecne zacit resit nejake detekce poskozeni databaze pri startu s pokusem o obnovu... Coz je blby kdyz se to ma delat pri kazdem startu aplikace....

Diky vsem za odpovedi.

--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny Firebird (CZ) ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu firebird_cz...@googlegroups.com.

Chcete-li zobrazit tuto diskusi na webu, navštivte https://groups.google.com/d/msgid/firebird_cz/00de022c-b4ae-4cf9-a7c5-c417cad9b72f%40www.fastmail.com.

[Jiří Činčura]

> zacit resit nejake detekce poskozeni databaze pri startu s pokusem o
> obnovu... Coz je blby kdyz se to ma delat pri kazdem startu aplikace....

Tak na to klidne nastartuj nove vlakno. To bude urcite zajimave i pro ostatni. A mozna i ostatni maji svoje zkusenosti.

[Slavomir Skopalik]

Zkusme to konstruktivne,

1. Aktualizuj

  Min na 2.5.9, nicmene tam uz nikdo nic opravovat nebude, respektive je to dost draze placeny.

  Nebo na 3.0.7 a pokud vytvoris test case, co rozbije DB je mozne to reportovat.

  Ja treba nasel jeden takovy a byl opraven. Kolega nasel takovy, ze FB prestal prijimat nove spojeni. Take opraveno.

2. co je spatne na nbackupu?

Slavek

Ing. Slavomir Skopalik
Executive Head
Elekt Labs s.r.o.
MASA - Collection and evaluation of data from machines and laboratories
http://eng.elektlabs.cz/products-and-services/masa
-----------------------------------------------------------------
Address:
Elekt Labs s.r.o.
Chaloupky 158
783 72 Velky Tynec
Czech Republic
---------------------------------------------------------------
Mobile: +420 724 207 851
icq:199 118 333
skype:skopaliks
e-mail:skop...@elektlabs.cz
http://www.elektlabs.cz

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/firebird_cz/CAC2Co4S_uj476ASXBOTbt42C4zftY2ARuO64k6fOSU%3DBeh5Bsw%40mail.gmail.com.

[Robert Kindl]

Ahoj, diky za informace.

 

Ono to zalezi na uhlu pohledu. Ja si treba z toho tveho popisu odnesl to, ze mate uplne stejny problem jako ja. Tj. obcas se narusi indexy, obcas je potreba vytahnout zalohu.

Ano jiste je to jen obcas, nic velkeho, jde to opravit, jde to vytahnout ze zalohy.

Ale kdyz to takhle valis par let rucne, zacne te to otravovat a zamyslis se jestli by to neslo automatizovat popr. udelat JESTE vice spolehlive – a to je to co tu resim.

 

Careful write je aplikacni pohled na vec, co je skutecne na disku je vec zapisove cache, ktera proste neni na klientech vypnuta a neni zalohovana a nemuzu bezny lidi k necemu takovymu nutit i kdyby sami chteli...

 

Nema smysl opakovat celou story, ty chyby jsou realitou a mam potvrzeny ze vesmes je to problem necekaneho vypnuti pocitace (baterka, proud, prehrati procesory, nestabilita PC...)

 

Rob

 

 

From: petr palicka

Sent: Wednesday, December 9, 2020 10:23 AM

To: Robert Kindl

Subject: Re: 2.5.9 embed x64 neotvori 32bit.databazu? (win10, c# .NET 4.8)

 

Ahoj,

    dovolím si do toho vstoupit, byť nijak neporadím. Ale Fb nespoléhá na MGA, nýbrž na "careful write". Tedy, to, že databáze je logicky konzistentní při výpadku v kterémkoli okamžiku zápisu změn! Fb nepotřebuje obludné transakční logy, ze kterých se MS SQL dává dohromady třeba i několik hodin. Hledej chybu někde jinde.
    Máme nějakých 2000 instalací SW a v mnoha případech bez správy a "ajťáka" za zadkem uživatele. Jediné průšvihy se ztrátou dat byly v případě selhání HW (chcípnul disk) nebo uživatele (nainstaloval si ransomware).Jinak jenom párkrát db shutdown, nebo pokakaný indexy, nic co by nezvládl backup/restore. Ale i lokálně jedeme Fb server, nikoli embeded – pro nás to je zbytečná komplikace, když uživatel chce i přístup po síti. A to ty Fb servery valej na klientských stanicích od laciných notebooků, přes win. home desktopy po terminálový servery a pár exotů má db i na linuxu. Problémy se občas řeší, občas se hledají zálohy apod, ale nijak masivně vzhledem k množství a rozličnosti instalací.
    Takže za me Firebird naprosto parádní a spolehlivá věc :)

Peca (Petr Palička)