Autor Téma: ADO, jak spravne detekovat a osetrit restart sql serveru nebo vypadek sluzby  (Přečteno 7414 krát)

Offline rob.

  • Nováček
  • *
  • Příspěvků: 34
  • Karma: 0
Ahoj,
pouzivam D2007+ADO. Mozna je to hloupa otazka ale nevim jak spravne detekovat, ze napr. byl sql server restartovan (jen restart sluzby behem par s). Protoze moje aplikace to nezjisti a pri prvnim query.open skonci na "neuspesnem pripojeni". Cekal bych ze pri restartu serveru bude na adoconnection vyvolana nejaka udalost - treba ondisconnect ale to se nestane. ADOConnection zustava aktivni i kdyz server nebezi. Napada me pouziti bloku try... ale pouzivat to pred kazdym query open ? a pokud selze zkusit pripojit a znovu nacist vsechny Adotable a otevrit vsechny Adoquery? To mi prijde jako prasecina. Diky za tipy a snad to neni moc debilni dotaz ale nic rozumneho jsem nevygoogloval.

Offline rob.

  • Nováček
  • *
  • Příspěvků: 34
  • Karma: 0
jen upresnuji dotaz - jak v bezici aplikaci zdetekovat a co nejelegantneji obnovit spojeni na databazi pri restartu mssql serveru? Protoze prestoze spojeni ado connection pri restartu "nespadne" tak po restartu nefunguje.

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 1754
  • Karma: 77
    • Verze Delphi: D2007, XE3, DX10
jen upresnuji dotaz - jak v bezici aplikaci zdetekovat a co nejelegantneji obnovit spojeni na databazi pri restartu mssql serveru? Protoze prestoze spojeni ado connection pri restartu "nespadne" tak po restartu nefunguje.
S MSSQL jsem toho moc nenadelal, ale rekl bych, ze se co do moznosti moc nebude lisit od ostatnich SQL server resp. od TCP/IP serveru obecne, protoze to bys neco urcite vygooglil.

IMHO plati, ze pokud se serverem neoperujes, tak dysfunkci nezjistis. Takze standardni reseni, jak zkratit chybovou latenci, je periodicka kontrola funkcionality => watch dog.

A u bezobsluzne aplikace mechanismus pro automaticke zotaveni z chyby, u desktopove aplikace bych se omezil na chybove hlaseni, ze mu to prestalo fungovat, at si to spravi a jde nakopat DB admina, ze mu v pracovni dobe restartuje server  pod rukama ;)


Offline Mi.Chal.

  • Guru
  • *****
  • Příspěvků: 566
  • Karma: 23
Samo se to AFAIK nezjistí, já jsem to řešil tak, že se v jiném threadu periodicky občas poslal dotaz do db a buď to prošlo nebo ne. ADO má ješte takovou bugofeaturu, že na TAdoConnection je defaultně nastaveno keepConnection na true a pokud spojení spadne, tak následná operace vyhodí chybu, ale už se nezkusí znovu připojit. Takže po chybě je potřeba nastavit na false a po obnoveném spojení zase přenastavit na true (jinak se bude připojovat pokaždé znovu a to zase dost zdržuje).

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 1754
  • Karma: 77
    • Verze Delphi: D2007, XE3, DX10
Samo se to AFAIK nezjistí, já jsem to řešil tak, že se v jiném threadu periodicky občas poslal dotaz do db a buď to prošlo nebo ne.
Mam dojem, ze to bylo u DB/2, kde select nestacil, protoze si to nejak cachovali a kdyz se ten select ptal na to samy, ta s DB vubec nic nedelali.
Ve watch-dogu jsme museli delat update. Jestli si to pamatuju, tak kazdy klient si zapisoval cas posledniho testu.

Offline Mi.Chal.

  • Guru
  • *****
  • Příspěvků: 566
  • Karma: 23
Mam dojem, ze to bylo u DB/2, kde select nestacil, protoze si to nejak cachovali a kdyz se ten select ptal na to samy, ta s DB vubec nic nedelali.

Tak to musel být prudce inteligentní systém. Jak to vědělo, že tam ty data nezměnil třeba nějaký jiný klient? A i tak stejný dotaz nemusí znamenat stejný výsledek - třeba "Select GetDate()" vrátí každou chvíli něco jiného.

Offline Radek Červinka

  • Administrátoři
  • Padawan
  • *****
  • Příspěvků: 1692
  • Karma: 69
    • Verze Delphi: D5,D2007, DXE, DXE2 + 2 poslední (Tokyo)
    • O Delphi v češtině
No já jsem s D2007 a ADO řešil stejný problém, nakonec to máme momentálně řešené jako globální ovladač vyjímek, který hlídá specifickou vyjimku a zaroven pred urcitymi pasazemi kodu navic provedu SELECT 1, kteryzto budto zhuci nebo nezhuci.

No a v tom ovladaci se zkusim pripojit, pokud nejde - dialog s dotazem na usera.

Dalsi krok bude doufam UniDAC a papa ADO.
Embarcadero MVP - Czech republic

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 1754
  • Karma: 77
    • Verze Delphi: D2007, XE3, DX10
Tak to musel být prudce inteligentní systém. Jak to vědělo, že tam ty data nezměnil třeba nějaký jiný klient? A i tak stejný dotaz nemusí znamenat stejný výsledek - třeba "Select GetDate()" vrátí každou chvíli něco jiného.
Asi byl, my tenkrat nemeli cas to zkoumat. Meli jsme tam watch-dog na principu selectu a stejne nejaky FW nekdy v noci bez realneho provozu po cca 2 hodinach spojeni na DB zahodil pro neaktivitu. Resili jsme to updatovanim obsahu tabulky.

Ale na druhou stranu ten system bezel  radu let v rezimu 7x24 na nekolika mistech po svete bez sebemensich problemu.

Offline rob.

  • Nováček
  • *
  • Příspěvků: 34
  • Karma: 0
dekuji vsem ya odpovedi. Jsem ted pryc takze vyzkousim az zitra, ale napada me - kdyz budu pravidelne testovat dostupnost serveru - kdyz to bude prilis casto, bude to v siti generovat "zbytecny" traffic a pokud to bude mene
casto tak to zas castecne postrada smysl protoze vypadek muze zrovna nastat v tom testovacim intervalu pred vlastnim zapisem do db. Neslo by treba pouzit nejakou udalost Adoquerz resp Adotable, jako beforeopen, kde
bz se spojeni otestovalo a pripadne zresetovalo, mozna je to uplna blbost nemam ted jak vyzkouset. Takz jsem jeste vcera v rychlosti narazil na problem, ye kdyz jsem testovaci open dal do try bloku,
tak to stejne vyvolalo vzjimku ktera nebyla zachycena - ceskou hlasku "neuspesne pripojeni" s mbIconErrorem - to je asi zale
zitost driveru, kterou nejde potlacit. Jak potlacit toto chzbove hlaseni - try blokem to nejde, tedy snad jsem v rychlosti nic neprehledl. dekuji za odpovedi.

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 1754
  • Karma: 77
    • Verze Delphi: D2007, XE3, DX10
kdyz budu pravidelne testovat dostupnost serveru - kdyz to bude prilis casto, bude to v siti generovat "zbytecny" traffic a pokud to bude mene
casto tak to zas castecne postrada smysl protoze vypadek muze zrovna nastat v tom testovacim intervalu pred vlastnim zapisem do db.
V oblasti spolehlivosti neni jisteho nic. Normalni je zkoumat koeficient pohotovosti, jestli je pro dany zamer dostatecny nebo ne.

Neslo by treba pouzit nejakou udalost Adoquerz resp Adotable, jako beforeopen, kde
bz se spojeni otestovalo a pripadne zresetovalo,
To michas jabka s hruskama: kdyz udelas nejakou akci pres query/table, tak nemusis nic zjistovat, protoze ona se bud provede nebo spadne. A jestli spadne, tak musis resit (automaticke) zotaveni z poruchy tj. zkusit obnovit spojeni a akci zopakovat a ev. prohlasit potize za nezotavitelne. V kazdem pripade nekam logovat, aby se vedelo, ze nekde neco hnije.

Periodicke testovani ma smysl tam, kde funkcionalitu neoveruje prirozeny trafic aplikace. Napr. jak jsem psal, kdyz se nam stavalo, ze v noci nekdy neprobihaly zadne transakce a zahazoval nam spojeni po cca 2 hodinach firewall.

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 1754
  • Karma: 77
    • Verze Delphi: D2007, XE3, DX10
Takz jsem jeste vcera v rychlosti narazil na problem, ye kdyz jsem testovaci open dal do try bloku,
tak to stejne vyvolalo vzjimku ktera nebyla zachycena - ceskou hlasku "neuspesne pripojeni" s mbIconErrorem - to je asi zale
zitost driveru, kterou nejde potlacit. Jak potlacit toto chzbove hlaseni - try blokem to nejde, tedy snad jsem v rychlosti nic neprehledl. dekuji za odpovedi.
Chces rict, ze jsi spravne umistil block try-except
Kód: [Vybrat]
try
  ...
  tady neco udelam s DB
  ...
except on E:Exception do
  begin
    LogException(E, .....);
    ...
  end;

a nezachytilo ti to exception tj. tvoje exeption nesla tudy, kde ja mam zapsano LogException :o

Nebo mas na mysli, ze prestoze jsi catchnul exception, ze ti na to reaguje debugger dialogem (kdyz to spoustis v IDE?)
« Poslední změna: 19-02-2013, 14:49:08 od pf1957 »

Offline rob.

  • Nováček
  • *
  • Příspěvků: 34
  • Karma: 0
tak se omlouvam za mystifikaci, krivdil jsem try ...except, nasel jsem jedno misto kde jsem do toho hrabl jeste pred try, ten kod je bugr tak jsem to prehledl, omlouvam se. Tim pada muj druhy dotaz ohledne potlaceni chyby. Co se tyce ostatniho budu hledat nejake kompromisni reseni na zaklade odpovedi. Takze kdyz to shrnu, ADO nema zadne integrovane funkce pro osetreni vypadku /restartu serveru a musi se to nejak odprasit :-).

Offline Mi.Chal.

  • Guru
  • *****
  • Příspěvků: 566
  • Karma: 23
Takze kdyz to shrnu, ADO nema zadne integrovane funkce pro osetreni vypadku /restartu serveru a musi se to nejak odprasit :-).

Tak co bys tam chtěl? Prostě provedeš nějakou akci a buď to projde nebo ne a můžeš to zkusit znovu.

Offline Radek Červinka

  • Administrátoři
  • Padawan
  • *****
  • Příspěvků: 1692
  • Karma: 69
    • Verze Delphi: D5,D2007, DXE, DXE2 + 2 poslední (Tokyo)
    • O Delphi v češtině
Takze kdyz to shrnu, ADO nema zadne integrovane funkce pro osetreni vypadku /restartu serveru a musi se to nejak odprasit :-).

Tak co bys tam chtěl? Prostě provedeš nějakou akci a buď to projde nebo ne a můžeš to zkusit znovu.

Něco takého? http://www.da-soft.com/anydac/unified-api.html#recovery

případně Unidac: http://forums.devart.com/viewtopic.php?t=22537
Embarcadero MVP - Czech republic

Offline rob.

  • Nováček
  • *
  • Příspěvků: 34
  • Karma: 0
naprosto presne, to bych tam chtel a na to jsem se vlastne ptal jestli u ado neco takoveho jako u toho ANYDAC neni, spis me prekvapilo ze ado takove situace nema nijak podchyceny a musi se brutalne neco zapsat aby se zjistilo ze je server hin.

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 1754
  • Karma: 77
    • Verze Delphi: D2007, XE3, DX10
spis me prekvapilo ze ado takove situace nema nijak podchyceny a musi se brutalne neco zapsat aby se zjistilo ze je server hin.
Prece kdyz nekdo chce prodavat komponenty, ktere maji free alternativu, tak musi neco pridat, ne? Proc by si to jinak nekdo kupoval?

Offline rob.

  • Nováček
  • *
  • Příspěvků: 34
  • Karma: 0
diky za vsechny tipy, jeste bych se rad zeptal na jednu vec, uz mam osetreny vypadek spojeni - v try bloku zachyceni a v pripade selhani jsem si napsal funkci reconnect, ktera spojeni obnovi se vsemi datasety. Vse funguje. zaznam se ulozi a jede se dale. Ale zjistil jsem, ze kdyz se sql server behem prace s programem vypne (a zustane vypnuty), program mi i v tom try bloku zatuhne na tak dlouho dokud se server nezapne, treba 10 minut - potom aplikace odtuhne a teprv zachyti vyjimku a provede obnoveni. Cekal bych, ze po vyprseni nejakeho timeoutu nastane vyjimka, ktera se v try bloku zachyti a podle toho se zaridim - zkusim pripojeni pozdeji apod, jenomze vyjimka nenastane program je tuhy tak dlouho dokud se server nezapne, teprve pak nastane vyjimka. Kdyz je server vypnuty uz pri spusteni programu tak to jde zachytit normalne, zobrazim hlasku ze je nedostupny atd, popisovany problem nastane pouze kdyz se sql server vypne pri aktivnim spojeni.

Offline Radek Červinka

  • Administrátoři
  • Padawan
  • *****
  • Příspěvků: 1692
  • Karma: 69
    • Verze Delphi: D5,D2007, DXE, DXE2 + 2 poslední (Tokyo)
    • O Delphi v češtině
U ADOConnection se da speecifikovat CommandTimeOut a ConnectionTimeOut. Mozna i to same primo u Query.
Embarcadero MVP - Czech republic

Offline vladyk

  • Příspěvků: 32
  • Karma: 0
Ještě to někoho zajímá?  :)

...pouziti bloku try... ale pouzivat to pred kazdym query open ?...

Já tedy nevím jak kdo, ale osobně mám jakékoliv Query "zapouzdřené" ve funkci, která je idiotensicher a vrací jednu z množiny hodnot "TQueryResult". Zas takové zdržení to v běhu aplikace není a robustnost je výrazně vyšší, což je pro mne rozhodující. A pokud je aplikace bezobslužná a výsledkem je nějaký ten "qrErrorX", tak není problém dopsat k tomu obsluhu, klidně i s timerem (ke zdržení a robustnosti stejný postoj).

Mám nasazené nějaké datové "mixery", které po nocích přenášejí ekonomická (=citlivá) data mezi účetními programy různých firem a za léta provozu to spadlo jen párkrát - když autor některého účetnictví něco změnil a neohlásil to. A v tom případě bylo v logu napsáno "změna datové struktury"...

RomanZ

  • Host
Přesně jak píše vladyk, taky mám ve zvyku psát "jakékoliv Query "zapouzdřené" ve funkci".
Přesněji - mám funkci, do které předávám SQL a SQL parametry jako parametry. Jde o to, že pak mám ošetření všech SQL záležitostí na jednom místě a nemíchá se to s obchodní logikou.
Totiž ono kromě výpadku nebo nedostupnosti SQL serveru je třeba myslet i na ošetření dalších chyb, na transakce, na ošetření deadlocků apod., takže ten kód pro komunikaci s databází je s rostoucími zkušenostmi stále složitější a není šikovné ho udržovat na více místech.

Offline vladyk

  • Příspěvků: 32
  • Karma: 0
...ten kód pro komunikaci s databází je s rostoucími zkušenostmi stále složitější a není šikovné ho udržovat na více místech.

Tesat :)

Já jsem se s léty dopracoval do stavu, kdy prakticky každé (zájmové) tabulce v katalogu odpovídá v Delphi konzoli nějaký objekt, ten obsluhují nějaké na míru uplácané funkce (LoadXObject, InsertOrUpdateXObject...) a v těch je zašitá ta "idiotensicher" univerzální funkce OpenOrExecSimpleXQuery. A výsledky funkcí jsou obvykle nějaké množiny stavů, kterým odpovídají nějaké datové (výčtové) typy. Pak se dá velmi snadno reagovat na jakýkoliv podchycený stav celé databáze a na obsluhu stačí vyhodnotit pár bajtíků.

 

S rychlou odpovědí můžete používat BB kódy a emotikony jako v běžném okně pro odpověď, ale daleko rychleji.

Upozornění: do tohoto tématu bylo naposledy přispěno před 120 dny.
Zvažte prosím založení nového tématu.

Jméno: E-mail:
Ověření:
Kolik je šest plus čtyři (slovem):