Zlyhanie synchronizácie medzi databázami

Dobrý deň.
Po prerušení spojenia sa synchronizácia dát skončí s chybou. Keď synchronizuje niekoľko dní nejaký trezor a pred koncom dôjde k výpadku spojenia trvajúcemu cca 5 minút, zvyšok archívnych objektov sa nepodarí dokončiť. Bolo by možné doplniť nejaký parameter do ARCSYNCHRO, ktorým by sa povedalo, že sa má pokúšať opätovne nadviazať spojenie na obe databázy a pokračovať až po obnovení spojenia?
Ďakujem.

Dobry den.
Dakujem Vam za podnet.
Poprosil som kolegov, aby tuto vlastnost zaradili na zoznam vlastnosti pre dalsie verzie (tzv. wishlist).

D2000 ma v sucasnosti rozne mechanizmy pre zvysovanie urovne dostupnosti a spolahlivosti (redundancia aplikacnych serverov, redundancia procesov, redundancia archivov, redundancia komunikacnych tras vo vybranych komunikacnych protokoloch).

Pochopitelne ale nemame osetrene “vsetko”. Dostupnost databazy (konfiguracnej/monitorovacej) pre Kernel sa poklada za nevyhnutnu podmienku. Ak nie je splnena, pri strate konektivity kernel konci.

Podobne je to pre archiv. Nema databazu - nesnazi sa o reconnectovanie ani ine maskovanie vypadku. Konci. Podobne nastroj cfgsynchro (synchronizacia konfiguracnych databaz v redundancii). Strata konektivity sposobi chybu a koniec.

Taky DbManager sa napr. aktivne pokusa o znovunadviazanie rozpadnuteho spojenia. Ale ak bolo transakcne, vsetky operacie v ramci aktualnej transakcie skoncia neuspesne. Az nasledne (po ukonceni transakcie) sa da spojenie recyklovat na nieco ine. Tu teda nic nemaskujeme, aplikacia vie, ze je nieco zle.

Ak by sme chceli znovuobnovenie spojenia implementovat v Archive, tak by boli dalsie komplikacie, napr:

  • ak je archiv aktivny, po strate spojenia s DB sa ho snazi obnovit, ale ak sa mu to dlhsie nedari (co je dlhsie?), poziadavky sa hromadia vo frontach
  • takze sa napr. nemenia hodnoty archivnych objektov, nepocitaju statistiky - je vela aplikacii, kde to bude vadit (a v redundancii by preferovali pad archivu a automaticke prehodenie aktivnej instancie na druhy archiv)
  • pokial sa nedari obnovit spojenie dlhsi cas, tak fronta v pamati rastie, moze sposobit vyzratie pamate, pad archivu … dobre alebo zle?

Okrem toho, ze dodavame technologiu D2000 nasim partnerom, mame v sucastnosti nasadenych a supportovanych niekolko desiatok velkych systemov, vacsina s redundantnymi archivmi. V standardnom firemnom prostredi (ci uz servery dodavane nami alebo zakaznikom, ci uz fyzicke alebo virtualizovane) neevidujem za vyse 16 rokov (odkedy existuje arcsynchro) problemy so sietou/ archivmi / arcsynchro, ktore by si vyzadovali implementaciu reconnectovania. Ak boli pady alebo problemy s archivnou DB, tak sa riesila stabilita DB servera (napr. pre Oracle 11c).