Hlavní navigace

Katastrální úřad bude mít plánovanou odstávku, systémy nepojedou několik dní

Sdílet

Redakce 17. 10. 2019

Během prodlouženého víkendu bude IT oddělení naplno pracovat nejen na CzechPOINTu, ale i na Českém úřadu zeměměřičském a katastrálním (ČÚZK). Odstávka systémů začíná už 25. 10. 2019, aby se vše s mírnou rezervou stihlo.

Od 25.10.2019 08:00 do 28.10.2019 cca 12:00 nepojedou externí systémy:

  • Dálkový přístup, včetně webový služeb (WS DP, WS GP)
  • Návrh na vklad, včetně webových služeb (WS NV)

Pozn.: Aktuálně ještě řešíme provoz Nahlížení do KN, byť v omezené formě.

S tím souvisí i omezení provozu na všech pracovištích, kde v pátek 25. 10. 2019 budou fungovat pouze podatelny. Nebudou se vydávat žádné výstupy z KN a nepůjde platit kartou.

V pátek 25. 10. 2019 nepůjdou naše výstupy získat ani na CzechPOINTu a notářů.

Za komplikace tímto způsobené se omlouváme a děkujeme za pochopení.

Aktualita byla přidána uživatelem Kamil Zmeškal prostřednictvím funkce Přidat novou aktualitu.

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 17. 10. 2019 16:58

    Kamil Zmeškal

    Navrhují to překvapivě normálně myslící lidé, byť to jsou státní úředníci :-)

    Ve zkratce, jedná se o upgrade několika databází Oracle z 10g na 12c. Databáze jsou propojené replikacemi, navíc s několika dalšími systémy (RÚIAN/ISÚI, Nahlížení do KN, .... ) a je to napojené na ISZR a další systémy. To vše mimo jiné způsobuje, že se nelze v případě nečekaných problémů vrátit zpět. Jakmile proběhne transakce mající vliv na externí systém, zaevidujeme podání, vydáme ven nějakou informaci, .... , tak se už se nemůžeme nikdy vrátit zpět, protože vše je "někde" vidět" a nejen proto se musíme po dobu migrace úplně odříznout.

    K tomu máme ten bonus, že díky zrušení podpory některých technologií v Oracle 12c a také několika bugům, musíme udělat velký zásah do datového modelu. Je to z hlediska zásahu do struktury dat největší principiální změna od počátku ISKN. Takže se mimo jiné po provedení vlastní migrace Oracle, databáze a úpravách modelu musí znovu kompletně sestavit replikace, spatial indexy atd., což nejsou věci na minuty. Harmonogram je napjatý.

    Velmi hrubou představu si lze udělat z popisu úkolu a přílohy č. 6 naší zadávačky na veřejnou zakázku, v rámci které se mimo jiné tato akce řeší.

    Tohle fakt není o nějaké postupné migraci a přehazování služeb v cloudu. Bohužel na podrobnější vysvětlování, proč to nelze dělat za provozu, zde není prostor.

    17. 10. 2019, 17:02 editováno autorem komentáře

  • 17. 10. 2019 15:37

    bez přezdívky

    Ja bych byl s hodnocenim opatrnej, nezname detaily a souvislosti a je mozne ze se planovane sdrcnulo vicero ukonu (treba i na HW) do jedineho prodlouzeneho vikendu. Navic statni sprava miva u spousty veci vyrazne jine pozadavky nez soukromy sektor. Navic realny vypadek muze byt vyrazne kratsi a oni se jen sichruji pro pripad problemu.

  • 17. 10. 2019 13:50

    Jan Forman

    Vždycky mě vrtá hlavou, kdo tyhle systémy navrhuje... v čem je problém udržet to v provozu?
    Chápal bych nějaké minutové dropy, kvůli přehazování služeb v cloudu, ale hodiny, dny? Bože co to je?

  • 25. 10. 2019 11:25

    mikiqex

    Přeji pevné nervy, o bugách vím své. Migrovali jsme z 11g na 12c a právě "katastrální" databáze (importy VFK), začala mít problémy mj. se spatial indexy, s čímž nám kvůli provozu na UNIXu nepomohl ani Oracle; měl patche jen pro Linux a Windows. Řešením byla čistá instalace a následná migrace schémat.