Budoucnost využívání rodných čísel

Aktualizace 05.06.2023

Aktualizovaná verze tohoto článku vyšla 05.06.2023 na serveru Lupa.cz pod názvem Rodná čísla se měla utlumit, ne jen zmizet z občanek. Jaké identifikátory stát používá?

Aktualizace 28.05.2023

Níže uvedený text je z roku 2020 a proto nezahrnuje poslední důležitou část - Ověřovací portál pro soukromoprávní sféru (spuštěn 1.7.2022) a princip BSI, kterou popisuji na serveru Lupa.cz v článku Jak se vypořádat s koncem rodných čísel v občanských průkazech?

---

O vhodnosti používání rodných čísel jako (skoro) unikátních identifikátorů fyzických osob se diskutuje poměrně dlouhou dobu, úvahy o zrušení role rodného čísla RČ jako identifikátoru se objevují minimálně 10 let. RČ jsou uváděna v některých veřejných rejstřících, například ve výpisu z katastru nemovitostí, jsou součástí DIČ podnikajících fyzických osob nebo se objevují v číslech zdravotního pojištění a dalších místech.

Proč ale rodné číslo budí takové emoce?

• není to bezvýznamový identifikátor, dá se z něj odvodit pohlaví a datum narození,
• naopak je díky jeho konstrukci při znalosti data narození snadno predikovatelné - zaznamenali jsme pokusy, kdy automat pro zjištění RČ postupně zkoušel pro datum narození všechna čísla odpovídající bezezbytkovému celočíselnému dělení 11 (je jich pouze 909), dokud se pro danou osobu netrefil) ,
• není snadno revokovatelné a při jeho zneužití nelze jednoduše získat nové.

To ale i další faktory je činí nevhodnými pro používání jako identifikátory osob.

První krok k omezení používání rodných čísel přinesly Základní registry (ZR), které byly zřízeny zákonem 11/2009 Sb. Jedním z jejich z cílů bylo omezení významu rodného čísla při komunikaci v rámci státní správy a samosprávy a jejich agendových informačních systémů (AIS). K tomu se využívají dva identifikátory – ZIFO a AIFO.

ZIFO – Zdrojový identifikátor fyzické osoby

ZIFO je neveřejný identifikátor a používá se výhradně ke generování AIFO. Je to náhodný řetězec vytvářený pomocí generátoru náhodných čísel v HSM. Je dostatečně dlouhý, aby nebyla možná jeho zpětná rekonstrukce z AIFO. Skládá se ze dvou částí (ZIFO-A, ZIFO-B), jejichž délka v součtu činí 12928 bitů (bez kontrolních údajů). Jeho generování má v kompetenci Úřad pro ochranu osobních údajů prostřednictvím informačního systému (IS) ORG.

Tyto identifikátory nejsou použitelné jak při komunikaci v rámci státní správy a samosprávy (mimo jejich speciální funkci pro generování AIFO v ORG), tak v soukromoprávní oblasti nebo při komunikaci občana se státní správou.

AIFO – Agendový identifikátor fyzické osoby

AIFO jsou bezvýznamové identifikátory a jsou jedinečné pro osobu a agendu, což znamená, že osoba „Josef Novák“ má v agendě evidence obyvatel jiné AIFO než v agendě katastru nemovitostí. Odvození AIFO ze ZIFO zajišťuje informační systém ORG a probíhá v HSM. Algoritmus vyžívá posloupnosti 3 standardních kryptografických funkcí, jejich výstupem je 128 bitů (bez kontrolních údajů). Ztráta věrohodnosti jedné z funkcí bezprostředně neohrožuje věrohodnost AIFO.

Když chce agenda katastru nemovitostí provést dotaz do evidence obyvatel, tak provede dotaz pro AIFO, které má pro osobu Josef Novák přiděleno (např. 123456), převodník ORG transparentně na pozadí při komunikaci přes eGSB/ISSS přeloží AIFO Jana Nováka v agendě katastru nemovitostí na AIFO agendy evidence obyvatel a do IS evidence obyvatel dotaz na pro Josefa Nováka doputuje pod jeho AIFO v dané agendě (např. 987654). 

Kdyby se k sobě, např. díky úniku dat, dostala data různých agend, nepůjdou přes AIFO nijak propojit - v agendě katastru nemovitostí má Jan Novák AIFO 123456 a v agendě evidence obyvatel má Jan Novák AIFO 987654. Propojení dokáže udělat pouze ORG, který ale zase neobsahuje žádné osobní údaje a je to zjednodušeně řešeno jen databáze ZIFO a k nim vydaným AIFO pro jednotlivé AIS. AIFO tak chrání před neoprávněným sdružováním dat.

Pozn.: celé je to podstatně komplikovanější, na pozadí probíhají další kontroly, např. v Registru práv a povinností, zda daná agenda (resp. činnostní role, pod kterou je zasílán dotaz) má na požadovaná data nárok. Není to tak, že libovolný AIS může číst libovolné údaje. Přístup k jednotlivým údajům je položkově přesně vymezen v zákoně. Vše je auditováno, každé volání i odpověď má jednoznačnou identifikaci (GUID), viz popis hlaviček eGon služeb.

AIFO jsou ze zákona neveřejné a není je možné používat pro účely uvádění na podáních (v případě katastru návrh na vklad) nebo na výstupech (v případě katastru list vlastnictví). Jsou velmi dobře využitelná v rámci státní správy, ale nejsou použitelná v soukromoprávní oblasti nebo při komunikaci občana se státní správou.

Vztah mezi ZIFO a AIFO:

AIFO je využitelné pouze jako interní identifikátor OVM a to ještě ne ve všech případech (např. katastr nemovitostí stále eviduje několik desítek tisíc fyzických osob, u nichž se nepodařilo ztotožnění proti základním registrům a nebylo získáno jejich AIFO).

ZIFO ani AIFO nejsou veřejné identifikátory a nemohou nahradit rodná čísla. Proto byly navrženy další identifikátory.

KIFO – Klientský identifikátor fyzické osoby

KIFO jsou veřejné identifikátory, jejichž použití je omezeno na jeden rezort (finanční správa, zdravotnictví, …). Toto omezení je podstatné a je dáno tím, aby se z KIFO nestal plošný identifikátor, jakým je RČ. Jako příklad KIFO lze uvést číslo pacienta resortu zdravotnictví nebo DIČ podnikající fyzické osoby.

KIFO smí existovat pouze tehdy, když jej resort nebo OVM může vydávat na základě zákona, ve kterém musí být stanoveny podmínky vydávání a užívání. Resort vydávající tento identifikátor musí zajistit službu převodu KIFO na AIFO (a zpět), pro agendy vykonávané v rámci resortu resortními OVM.

Hlavním účelem je možnost jejich používání soukromou sférou, například soukromými zdravotnickými zařízeními při komunikaci s resortem zdravotnictví.

KIFO je veřejný identifikátor a může být uváděn na resortních dokumentech, dokladech (průkaz pojištěnce), informačních tabulích atd. Může se ukládat v informačních systémech.

KIFO je v principu pro jednu osobu trvalé a nemusí být zaveden mechanismus jeho pravidelné obměny. Musí ale být zaveden mechanizmus jeho revokace a přidělení nového při případném zneužití a proto musí počítat s historickými hodnotami.

SIFO – Stykový identifikátor fyzické osoby

SIFO jsou stejně jako KIFO veřejné identifikátory. Příkladem SIFO je číslo občanského průkazu nebo číslo cestovního pasu.

Oproti KIFO, které jsou omezeny na jeden resort, jsou SIFO vydávány fyzickým osobám plošně a centrálně a jsou tak využitelné přes více resortů. Proto se na ně vztahují přísnější podmínky:

• nesmí se ukládat do informačních systémů za účelem identifikace fyzické osoby, ale musí být na vstupu převedeny na AIFO nebo KIFO a IS musí dále pracovat pouze s těmito identifikátory,
• musí mít omezenou platnost (10 let).

Stejně jako v případě KIFO musí existovat mechanizmus jeho revokace a přidělení nového při případném zneužití (ztráta nebo odcizení občanského průkazu), včetně evidence historických hodnot.

Zmíněné omezení ukládání SIFO do informačních systémů se týká výhradně účelu dohledávání dané osoby v IS. Pokud ale agenda pro své další fungování, například pro účely vydávání údajů na výpisech, SIFO potřebuje, tak ho ukládat může. V tom případě se identifikátor nevystupuje v roli SIFO. V případě katastru se může jednat např. o list vlastnictví, aby si kupující mohl na jeho základě potvrdit, že jedná s osobou v katastru zapsanou jako vlastník nemovitost.

Pokud vám odstavec výše přijde nesrozumitelný, tak ho zkusím zjednodušeně připodobnit, jak by to mohlo po zavedení probíhat v praxi (neuvažuji teď výjimky jako např. cizinci atd.):

• na katastr dorazí návrh na vklad, v seznamu účastníků budou uvedena čísla cestovních dokladů (pasů),
• katastr podle čísel dokladů provede dotaz do základních registrů, aby zjistil AIFO účastníků návrhu na vklad a čísla identifikačních dokladů (ZR vrací všechny platné doklady),
• zjištěná AIFO a čísla občanských průkazu si uloží do ISKN,
• číslo občanského průkazu se bude zobrazovat a vydávat ve výstupech (např. výpis z katastru nemovitostí neboli „LVčko“).

Katastr by měl (převážně z výkonostních důvodů) uložené číslo občanského průkazu, ale toto číslo by neplnilo roli SIFO – nedalo se podle něj přímo vyhledávat.  Pokud by někdo chtěl vyhledávat osobu, nezadal by rodné číslo, ale číslo dokladu (a bude moci zadat i číslo pasu, které katastr uloženo nemá). Katastr následně provede dotaz do ZR/ROB, aby pro dané číslo dokladu zjistil AIFO a měl tak identifikátor fyzické osoby, o kterou se jedná. Následně podle AIFO zjistí všechna vlastnictví nemovitostí a jiné právní vztahy.

Protože katastr odebírá notifikace o změnách, tak se bude automaticky aktualizovat číslo občanského průkazu při jeho změně. Vyhledávání ale bude fungovat i pomocí historických čísel.

Uvedený postup má jeden další pozitivní boční efekt. Všechny dotazy do ZR/ROB se ukládají a občan si následně může vyžádat informaci (nebo je mu automatizovaně 1x ročně odeslána do datové schránky), který AIS na něj vznesl dotazy. Protože se ze SIFO na AIFO budou převádět všechny dotazy, bude mít daný občan poměrně slušnou evidenci toho, kdo se na něj kdy ptal (další evidence je ještě v rámci GDPR).

Pozn.: Výpis o využití údajů z registru obyvatel se tím stane poměrně nepřehledným a dlouhým a bylo by zřejmě vhodné ho převést do nějaké interaktivní formy s možností filtrování a třídění.

Jaký je aktuální stav a co dál?

V roce 2019 Ministerstvo vnitra zpracovalo koncepci řešení minimalizace využívání RČ a předložilo ji do mezirezortního připomínkového řízení. Vláda ji usnesením č. 28/2020 vzala na vědomí a členové vlády a vedoucí ústředních správních úřadů dostali za úkol zpracovat do 31.03.2020 přehled právních předpisů v jejich působnosti, na které bude mít dopad.

Resorty mají do konce září 2020 zpracovat analýzu a do konce prosince 2020 Ministerstvo vnitra předloží vládě souhrnný materiál koncepce zavedení nových elektronických identifikátorů fyzických osob. 

Musí být provedena novelizace jednotlivých předpisů a musí vzniknout služby pro převod SIFO/KIFO (včetně historických) na AIFO. Podle upravené legislativy a nových služeb se musí upravit jednotlivé agendové IS, jejich výstupy atd.
Pozn.: V případě identifikačních dokladů (občanský průkaz, cestovní pas) současné služby ISZR umožňují vyhledávání pouze pomocí platných údajů a vracejí též pouze platná data. 

Pokud platí plán ukončení uváděných rodných čísel v občanských průkazech od roku 2022, je toho na práci více než dost. Legislativa se může nepříjemně táhnout, OVM budou čekat na vydání specifikací nových služeb a jejich vystavení na testovací prostředí ISZR.

Jednotlivé resorty budou dle svých potřeb (a nutných zákonných zmocnění) pro identifikaci osob na rozhraní občan-resort využívat KIFO (zřejmě např. Finanční správa) nebo SIFO (např. katastr). Komunikace mezi úřady už dnes většinově probíhá přes AIFO. 

Vzhledem k tomu, kolik let se o této problematice mluví, bylo by dobré řešení dotáhnout do zdárného konce, byť to jednoduché nebude. Stejně nás to nemine.

Rodná čísla jako taková ale nezanikají. Stále se budou zapisovat např. do matrik. Dochází „pouze“ k jejich postupné minimalizaci v roli interních nebo veřejných identifikátorů.

Konec přihlašovacích jmen a hesel ke službám státní správy?

V České republice je od 1.7.2018 účinný zákon č. 250/2017 Sb. (Zákon o elektronické identifikaci, dále jen zákon), který upravuje elektronickou identifikaci v návaznosti na Nařízení Evropského parlamentu a Rady (EU) č. 910/2014 ze dne 23. července 2014 o elektronické identifikaci a službách vytvářejících důvěru pro elektronické transakce na vnitřním trhu.

V § 2 toho zákona je stanoveno:

Prokázání totožnosti s využitím elektronické identifikace

Vyžaduje-li právní předpis nebo výkon působnosti prokázání totožnosti, lze umožnit prokázání totožnosti s využitím elektronické identifikace pouze prostřednictvím kvalifikovaného systému elektronické identifikace (dále jen „kvalifikovaný systém“).

Podle tohoto § mohou poskytovatelé online služeb (service provider, SeP), u kterých dochází k ověření totožnosti, umožnit přihlašování (identifikaci a autentizaci) uživatelů s využitím elektronické identifikace výhradně pomocí kvalifikovaného systému elektronické identifikace. Výjimkou jsou pak případy, kdy zvláštní právní předpis nestanoví pouze požadavek ověření totožnosti, ale současně stanoví způsob prokázání totožnosti fyzické osoby.

Informace Ministerstva vnitra pro správce informačních systémů veřejné správy:

Od 1. července 2020 jste povinni, pokud nabízíte online služby, při nichž dochází k ověření totožnosti, které vyžaduje právní předpis nebo výkon působnosti, umožnit přihlášení prostřednictvím kvalifikovaného systému elektronické identifikace, resp. prostředku pro elektronickou identifikaci vydaného kvalifikovanými správci (identity providery), kteří jsou připojeni k Národnímu bodu pro identifikaci a autentizaci.

eIdentita

Národní bod pro identifikaci a autentizaci (NIA) nabízí k 3.3.2020 dva kvalifikované systémy s prostředky pro elektronickou identifikaci:

• Občanský průkaz s aktivovaným čipem (eOP) vydaný po 1. 7. 2018,
• Uživatelský účet (jméno + heslo+ sms, UPS).

Připravuje se rozšíření těchto systémů o soukromoprávní kvalifikované správce, z nich nejzajímavější budou zřejmě banky. Své želízko v ohni má též První certifikační autorita, a. s.

V § 27 odstavci 2) zákona bylo současně zavedeno přechodné opatření, které umožnilo po dobu 2 let ode dne nabytí účinnosti zákona využívat i jiný způsob prokázání totožnosti s využitím elektronické identifikace, než je kvalifikovaný systém:

Po dobu 2 let ode dne nabytí účinnosti tohoto zákona lze umožnit prokázání totožnosti, které vyžaduje právní předpis nebo výkon působnosti, s využitím elektronické identifikace, při kterém se nepoužije kvalifikovaný systém.

Mezi jiné způsoby například patří vydávání vlastních přihlašovacích údajů (typicky jméno a heslo), využívání certifikátů nebo používání autentizačních služeb třetích stran (MojeID).

Do seznamu kvalifikovaných systémů s prostředky pro elektronickou identifikaci nejsou zařazeny Datové schránky (DS), resp. Autentizační služba portálu veřejné správy (AS-PVS). Pro uživatele Datových schránek využívajících Mobilní elektronický prostředek (MEP) se chystá jeho využití jako dalšího IdP, s možností převodu identity z Datových schránek. Pravděpodobně se o tomto způsobu dozvíme více na letošní konferenci ISSS.

MEP a možnost převodu identity z DS do NIA

Jako malý paradox může působit, že DS/AS-PVS zřejmě nepůjdou po 1.7.2020 pro přihlášení vyžadující ověření totožnosti použít (bude to možné se zavedením MEP do NIA jako dalšího IdP), ale stále bude možné založit si prostředek pro elektronickou identifikaci UPS a následně ho aktivovat ověřením datovou schránkou fyzické osoby.

Zmíněné přechodné opatření dle § 27 odst. 2) však končí 30.6.2020 a od 1.7.2020 jsou úřady povinny pro online služby, při nichž dochází k ověření totožnosti, umožnit přihlášení prostřednictvím kvalifikovaného systému elektronické identifikace. Současně jsou povinny ukončit ověřování totožnosti vlastními systémy, případně systémy třetích osob nesplňujícími požadavky na kvalifikované systémy podle zákona o elektronické identifikaci.

Jaký je však praktický dopad konce přechodného období? Budou se hromadně rušit jména a hesla při autentizaci ke službám státní správy? Odpověď se dá rozdělit pro dvě hlavní oblasti/části.

První oblast se týká služeb, které podle právního předpisu a výkonu působnosti nevyžadují prokázání totožnosti. Zde je odpověď jednoduchá – k prokázání totožnosti pomocí elektronické identifikace lze dále využívat i jiné prostředky než kvalifikovaný systém elektronické identifikace. Jako příklad lze uvést registraci na Geoportál Zeměměřického úřadu.

Druhá oblast se týká služeb, které podle právního předpisu nebo výkonu působnosti vyžadují prokázání totožnosti. Zde je odpověď na první pohled také jednoduchá – k prokázání totožnosti pomocí elektronické identifikace lze od 1.7.2020 využívat pouze prostředky kvalifikovaného systému elektronické identifikace. Jako příklad lze uvést online registraci do Služby sledování změn, u které je prokázání totožnosti stanoveno v § 20 odst.1) vyhlášky č. 358/2013 Sb. (Vyhláška o poskytování údajů z katastru nemovitostí, dále jen vyhláška). Dalším příkladem může být požadované prokázání totožnosti pro poskytnutí duplikátu písemností v elektronické podobě ze sbírky listin katastru podle § 7 vyhlášky. V těchto případech by ČÚZK od 1.7.2020 neměl umožňovat použití jména a hesla pro přihlášení k Dálkovému přístupu do KN za účelem získání duplikátu písemností v elektronické podobě ze sbírky listin.

Dálkový přístup do KN

To je zásadní změna s dopadem na osoby, které by si například chtěly online zřídit Službu sledování změn nebo v Dálkovém přístupu online zakoupit kopii listiny. Musely by jako první získat jeden z kvalifikovaných prostředků pro elektronickou identifikaci.

Je ale odpověď na druhou část tak jednoznačná? Co je přesně myšleno prokázáním totožnosti podle § 2 zákona? Který okamžik?

Pokud se jedná o zřízení služby, je požadavek na prokázání totožnosti pouze pomocí kvalifikovaného systému elektronické identifikace jasný. Co když ale byla při zřízení služby totožnost takto prokázána (případně před 1.7.2020 jiným způsobem) a následně byl uživateli přidělen jiný autentizační prostředek, např. přihlašovací jméno a heslo? Považuje se každá následná autentizace pomocí toho přiděleného prostředku také za prokazování totožnosti a neměla by tedy být nadále umožněna?

Jeden pohled je, že každá autentizace ke službě, které podle právního předpisu nebo výkonu působnosti vyžaduje prokázání totožnosti, znamená vždy opakované prokázání totožnosti.

Druhý pohled může být, že totožnost byla přeci ověřena při založení služby a následná autentizace již ověření totožnosti žadatele není. Proti tomuto pohledu jde ale fakt, že pokud by autentizace pomocí přiděleného prostředku mimo kvalifikovaný systém nebyla vždy ověřením totožnosti, tak by se nemusela rušit, jak uvádí Ministerstvo vnitra.

Rádi bychom Vás tedy touto cestou informovali, že v souladu s ustanovením § 27 odst. 2 zákona č. 250/2017 Sb., o elektronické identifikaci, ve znění pozdějších předpisů (dále jen „zákon o elektronické identifikaci“), se blíží konec přechodného období, ve kterém jste mohli ověřovat totožnost osob při přihlašování k Vámi nabízeným online službám vyplývajícím ze zákona či z výkonu působnosti (z výkonu veřejné moci) prostřednictvím vlastních systémů (např. vydávání vlastních přihlašovacích údajů ke službám), případně prostřednictvím systémů třetích osob, které nesplňují požadavky na kvalifikované systémy elektronické identifikace.

Je na místě upozornit, že do konce června 2020 jste povinni ukončit ověřování totožnosti vlastními systémy, případně systémy třetích osob nesplňujícími požadavky na kvalifikované systémy podle zákona o elektronické identifikaci, pokud však Vámi dosud používaný systém elektronické identifikace nevyžaduje explicitně právní předpis.

Prokázání totožnosti se týká i Machine-to-machine komunikace, typicky webových služeb (WS). Znovu jako příklad použiji duplikát písemností v elektronické podobě ze sbírky listin, který lze získat i pomocí webových služeb dálkového přístupu. V případě WS ale nelze pro autentizaci použít NIA, využívají se vlastní systémy. Znamená to přestat poskytovat přes WS služby, které vyžadují prokázání totožnosti?

Opět se vracíme k tomu, co se za prokázání totožnosti považuje a který je to okamžik - zda prokázání totožnosti proběhlo již při vytvoření účtu, nebo je za ni považována i každá následná autentizace uživatele k tomuto účtu. Co když úřad vydal přihlašovací údaje po předchozím ověření totožnosti?
Ve skutečnosti, pokud úřad vydá přihlašovací údaje a neprovede před tím ověření totožnosti, tak autentizace pomocí těchto přihlašovacích údajů ani ověřením totožnosti být nemůže. Z toho plyne, že za ověření totožnosti je považována i každá autentizace již ověřeného uživatele, jinak by nebyl požadavek ji rušit. Cílí na tento výklad ministerstvo vnitra?

Celá problematika autentizace k online službám vyžadující prokázání totožnosti je poměrně komplikovaná. Bude velmi záležet na zvoleném výkladu a často i na přesném znění právního předpisu, který prokázání totožnosti vyžaduje.

eIdentita - výběr způsobu přihlášení 

Umožnění prokázání totožnosti přes kvalifikované systémy je bez pochyb správná cesta, která zjednoduší přístup uživatelů ke státním online službám. Obecně by bylo dobré, kdyby přihlašování přes kvalifikované systémy byla co nejvíce podporovaná cesta i pro přihlášení ke službám (nebo online založení), které nevyžadují ověření totožnosti. 

Pokud bude ale v případě prokázání totožnosti znamenat „umožnit pouze“ zrušení možnosti použít již vydané přihlašovací údaje nebo jiné prostředky a tak de facto zamezí přístupu většině existujících uživatelů a bude je nutit si pořídit kvalifikovaný systém (v současné době eOP nebo UPS), nebude to zřejmě veřejností vnímáno dobře. 

Jak na sebe narazilo nařízení EU a německé a české právo

aneb když se nedaří dohody na mezinárodní úrovni a občasné jsou v pasti…

Níže uvedený text je v rámci snahy o snadnější čitelnost upravena část důvodové zprávy návrhu na změnu vyhlášky č. 357/2013 Sb., o katastru nemovitostí. Pro zájemce je plný text dostupný ve veřejném eKLEPu pod ID KORNBF7JRXNU.

Dne 17. 8. 2015 vstoupilo v účinnost nařízení Evropského parlamentu a Rady (EU) č. 650/2012 o příslušnosti, rozhodném právu, uznávání a výkonu rozhodnutí a přijímání a výkonu veřejných listin v dědických věcech a o vytvoření evropského dědického osvědčení (dále jen „Nařízení“).

V souvislosti s aplikací Nařízení však vyvstal zásadní praktický problém, pokud jde o zápis nabytých práv do katastru nemovitostí na základě evropských dědických osvědčení. Konkrétně jde o odlišné pojímání označení majetku, který tvoří pozůstalost podle německého a českého práva. Ačkoli v obou státech se uplatní v dědickém právu zásada univerzální sukcese, německé soudy na jejím základě považují za nepřípustné uvádět jednotlivé předměty pozůstalosti v evropském dědickém osvědčení.

Na druhé straně podle českého práva nelze provést vklad vlastnického práva do katastru nemovitostí na základě listiny, ve které není dotčená nemovitost náležitě označena.

Katastrální úřady proto návrhy vklad doložené evropským dědickým osvědčením vydaným Spolkovou republikou Německo zamítají.

Ministerstvo spravedlnosti se opakovaně pokusilo věc řešit na expertní i politické úrovni, avšak doposud se nepodařilo německou stranu o změně jejich postupu přesvědčit. Reakce německé strany byla vždy nekompromisní – německé orgány jsou přesvědčeny, že Nařízení nenutí členské státy přizpůsobit svou vnitrostátní praxi či právní úpravu.

Interpretace Nařízení ze strany německých soudů má v praxi negativní dopad na dědice (české, německé i ze třetích států), kteří se tak dostávají do patové situace. Česká republika není jediným státem EU, kde je třeba tento problém řešit, s obdobnými obtížemi se setkávají občané a úřady též např. v Rakousku, Chorvatsku, Polsku nebo na Slovensku. Ani tyto státy nebyly schopny dosáhnout jakékoli dohody s německou stranou a rozhodly se řešit tuto problematiku v rámci svých vnitrostátních právních řádů. Vzhledem ke společným hranicím České republiky se Spolkovou republikou Německo a velkému množství smíšených rodin žijících v obou státech se problémy s uplatňováním evropských dědických osvědčení stávají stále palčivějšími a je zapotřebí najít reálné a účinné řešení pro občany, kteří jsou momentálně v neřešitelné situaci.

Navrhovanou změnou jsou tak nově stanoveny listiny pro zápis práv do katastru nemovitostí v případě univerzální sukcese s mezinárodním prvkem. Aplikace tohoto ustanovení je možná pouze za podmínek, že se jedná o univerzální sukcesi, v listině nejsou uvedena práva nebo nemovitosti, na něž se univerzální sukcese vztahuje, a zároveň jejich uvedení v listině brání právní řád členského státu EU, ve kterém byla tato listina vydána.

Proč byla v Nahlížení do KN neaktuální data

Na Twitteru jsem slíbil, že napíši něco k problému, díky kterému byla na Nahlížení do KN  (dále jen Nahlížení) neaktuální data. Ostřílené Oraclisty prosím o shovívavost, protože jsem v rámci čtivosti občas něco zjednodušil.

Pokud čirou náhodou Nahlížení neznáte, tak se ve zkratce jedná o www aplikaci, ve které můžete získat vybrané údaje týkající se vlastnictví parcel, staveb, jednotek evidovaných v katastru nemovitostí, informace o stavu řízení a další užitečné informace.  

Architektura replikací

Nahlížení má svoji samostatnou databázi, do které se replikují data z interní databáze ISKN:

Replikuje se cca 200 databázových tabulek, replikace probíhají každé 2 hodiny a jsou založeny na Oracle Materialized View. Pro zachování logické konzistence dat a cizích klíčů (Foreign Key) jsou všechny tabulky umístěny v jedné  replikační skupině (Materialized View Group), což znamená, že se v rámci jednoho průběhu replikací musí úspěšně zreplikovat všechny tabulky v dané skupině, jinak replikace zhavarují. Takže systém vše nebo nic. 

Pozn.: ve skutečnosti je replikační model košatější. Replikačních skupin tam mámě několik, včetně opačného směru, a ještě se do Nahlížení replikují data z databáze ISÚI.

Kódové stránky

Další věc, která je v tomto případě podstatná, je tzv. character set databáze, což je zjednodušeně řečeno kódová stránka. Protože v době vzniku ISKN nebyla v Oracle rozumná podpora pro Unicode, tak databáze ISKN využívá EE8ISO8859P2 se single-byte  kódováním (každý znak je uložen právě v jednom byte). 

Nahlížení je novější a využívá character set AL32UTF8, což odpovídá Unicode ve verzi 6.2 a je doporučován samotným Oracle. Tento character set je vícebytový (Multibyte) a využívá proměnnou délku kódování (Variable-width encoding), kdy je každý znak podle potřeby uložen v 1-4 byte.  

Pozn 1.: české znaky se tuším vejdou do 2 byte, ale ruku do ohně za to teď nedám.
Pozn 2.: jsou i Multibyte kódování s pevnou délkou, např. UTF-32.

V Oracle se velikost sloupců pro ukládání textu (typicky VARCHAR2) dá definovat dvěma způsoby - v bytech nebo znacích (Char). Velikost v bytech je maximální počet byte, které do sloupečku půjdou uložit, velikost ve znacích udává maximální počet znaků.

V Singlebyte databázi (EE8ISO8859P2) je to jedno, ale v Multibyte (AL32UTF8) je to podstatné, protože do sloupečku s definicí "VARCHAR2 9 Byte" nejde vložit řetězec "nahlížení", neboť má sice jen 9 znaků, ale jeho skutečná reprezentace má délku 12 byte (3 byte navíc jsou díky 3 českým znakům, každý je reprezentován 2 byte). Proto je v obou databázích  ISKN a Nahlížení použita definice pomocí znaků (Char), což eliminuje problém s rozdílnou délkou skutečného uložení řetězců.

Vznik chyby a její příčina

V pátek 8.2.2019 nám dopoledne začal systém indikovat, že se nedaří provést replikace z ISKN do Nahlížení. Replikace končily na chybu:

ORA-12008: error in materialized view or zonemap refresh path

ORA-06512: at "SYS.DBMS_SNAPSHOT_KKXRCA", line 2952

ORA-06512: at "SYS.DBMS_SNAPSHOT_KKXRCA", line 2370

ORA-12899: value too large for column "ISKN"."AK_JINE_PRAV_VZTAHY"."POPIS_PRAVNIHO_VZTAHU" (actual: 4379, maximum:

4000)

Jednalo se o sloupec tabulky AK_JINE_PRAV_VZTAHY, do kterého se ukládá popis jiného právního vztahu a který je v obou databázích definován shodně, jak délka 4000, tak jednotky Char: 

SQL> desc AK_JINE_PRAV_VZTAHY

Name                    Type

---------------------------------------

ID                      NUMBER(30)

VERZE                   NUMBER(30)

OPSUB_ID_K              NUMBER(30)

TYPRAV_KOD              VARCHAR2(4 CHAR)

POPIS_PRAVNIHO_VZTAHU   VARCHAR2(4000 CHAR)

TEL_ID                  NUMBER(30)

(zkráceno...)

V ten okamžik jsme začali jsme tušit větší problém. Po detailním trasování jsme zjistili, že problém dělá řádek, který má v ISKN délku 3963 znaků a měl by se tedy do 4000 znaků v Nahlížení, kde jeho velikost díky českým znakům v AL32UTF8 naskočila na 4379 byte, s rezervou vejít. 

Zapojili jsme do pátrání i pracovníky podpory české pobočky Oracle a ti po dalším zkoumání přišli s tím, že Oracle sice povolí pro datový typ VARCHAR2 použít maximální velikost 4000 Char, ale ve skutečnosti je strop na 4000 byte, bez ohledu na použití jednotky char. Je to interní limit, což je v případě vícebytového AL32UTF8 docela průšvih. 

Zrádné je to navíc v tom, že se na limit narazí, až pokud se blíží oné maximální velikosti 4000. Pokud je sloupec definován jako "VARCHAR2 500 CHAR", tak se do něj v AL32UTF8 bez problémů 500 českých znaků uloží, přestože zabírají například 560 byte. V našem případě byla velikost problémového záznamu v ISKN (Singlebyte EE8ISO8859P2) 3963 znaků, ale po přenosu do Nahlížení se díky Multibyte AL32UTF8 zvětšila na 4379 byte a narazilo se na strop 4000 byte.

Hledání řešení

Možných řešení bylo několik.

1) Změna character set databáze

Character set se v Oracle definuje při vytváření databáze a následně jíž nejde jednoduše změnit. Je potřeba vytvořit databázi novou, přeexportovat data atd. Je šílená práce, která by v případě Nahlížení trvala několik dnů (export dat, nová databáze, import dat, vše znovu nastavit atd) a musela by se ještě předem důkladně vyzkoušet. 

Existují sice nějaké neoficiální postupy jak to změnit, ale to si nemůžeme u takového systému jen tak dovolit. V Oracle 12c se také objevil oficiální nástroj Database Migration Assistant for Unicode, pomocí kterého by měl jít character set změnit, ale od jeho použití nás v produkčním prostředí odrazovali samotní pracovníci Oracle, protože je (zatím) velmi problémový a plný chyb. Vše by se muselo nejprve vyzkoušet na kopii databáze a ani tak by jistota funkčnost nebyla a navíc jsme nechtěli přecházet z Unicode zpět.

2) Změna parametru max_string_size

Další možností bylo změnit parametr max_string_size na hodnotu "extended", což zvýší limit ze 4000 byte na 32767 byte, což by bohatě stačilo:
STARTUP UPGRADE;
ALTER SYSTEM SET max_string_size=extended;
@?/rdbms/admin/utl32k.sql
SHUTDOWN IMMEDIATE;
STARTUP;

Jenže je zde obdobný problém jako u předchozího řešení. Po dlouhém zkoumání opět samotný Oracle tento postup nedoporučil, protože součástí změny je nutnost spustit script utl32k.sql pro úpravu Oracle Dictionary (katalog - interní tabulky popisující strukturu samotné databáze), na který v Oracle Supportu zrovna chvála není:

Důsledkem by také byla byla fragmentace řetězců v databázi. Zároveň bychom museli změnit inicializačního parametr "compatible", který mám vliv i na chování CBO optimalizátoru dotazů. takže to není bez důkladného testování možné. Opět tedy několik dnů testování a zkoušení, navíc s nejistým výsledkem.

Pozn.: Pokud by databáze byla vytvořena přímo s parametrem max_string_size nastaveným na extended, tak by odpadl problém s fragmentací řetězců a nemusel by se spouštět script utl32k.sql. To je ale jen teoretická možnost, protože to znamená vytvořené nové databáze, viz předchozí řešení 1). Navíc jsme od pracovníků podpory Oracle dostali následující informaci:

"ani po delším pátrání se mi nepodařilo najít reference na použití max_string_size = extended. To znamená, že nemůžeme vyloučit komplikace, bugy apod.".

3) Redefinice MVIEW AK_JINE_PRAV_VZTAHY

Jako jednoduché řešení se nabízelo vytvořit v Nahlížení znovu Materialized View pro dotčenou tabulku AK_JINE_PRAV_VZTAHY  tak, že by se problémový sloupec rozdělil na dvě části, každá o velikosti 4000 CHAR. Reálně by se tedy, díky limitu, do každé části vešlo až 2000 českých znaků, celkem 4000 znaků, což je maximum, které lze v ISKN zapsat:

create mview as 

select id,

substr(popis_pravniho_vztahu,1,2000) as popis_pravniho_vztahu, substr(popis_pravniho_vztahu,2001) as popis_pravniho_vztahu_1,

…. from ak_jine_prav_vztahy@iskni 

To však narazilo z více důvodů. Prvním důvodem byla nutnost upravit aplikaci, která by musela interně oba sloupce zase zpět spojovat. To by nějakou dobu zabralo, ale asi by to šlo za víkend provést a otestovat (+ předělat  MVIEW, i to nějakou dobu trvá, protože by se musela znovu přenést všechna data). 

Druhý důvod byl závažnější. V Nahlížení je na replikované tabulky navázáno přes databázové triggery hlídání přicházejících změn, na jejichž základě se následně provádějí další změny v grafické části (mapě). Novou definicí MVIEW bychom tedy přišli o možnost zpracovat o změny, které v tu dobu již byly nachystané v replikační frontě v ISKN a příslušná část grafiky by se musela kompletně od začátku znovu spočítat, což je časově velmi náročná akce (dny) a navíc jsme neměli vyzkoušen postup, kdy se přepočte jen jedna část. 

4) Aplikační úprava problémového textu v ISKN

Toto řešení by spočívalo v tom, že by se v ISKN upravil problematický text tak, aby se i s českými znaky v Nahlížení vešel do 4000 byte. Použil by se standardní postup přes aplikaci ISKN, jako každá jiná změna v ISKN. Takže založit řízení a provést aktualizaci dat se vším, co k tomu formálně patří. To by ale znamenalo čekat až do pondělí, protože o víkendu nikoho z daného katastrálního pracoviště, které daný jiný právní vztah zapsalo, neseženeme, a do práce nenaženeme.

Následně jsme si ale uvědomili, že bychom tím problém vlastně nevyřešili. Datový model ISKN je navržen takovým způsobem, aby bylo možné zjistit stav data k jakémukoli času. Proto je možné dělat např. výpisy KN k zpětně. Funguje to tak, že pro každou entitu (jiný právní vztah, parcela, stavba, ...) existují 3 tabulky:

• AK_JINE_PRAV_VZTAHY
• AK_JINE_PRAV_VZTAHY_B
• AK_JINE_PRAV_VZTAHY_M

Tabulka AK_JINE_PRAV_VZTAHY (bez suffixu) slouží k uložení aktuálně platných dat, tzv. přítomnost.
Tabulka AK_JINE_PRAV_VZTAHY_B (budoucnost) slouží k vytváření budoucího stavu dat, který bude platit po tzv. zplatnění řízení (navrhují se v ní změny dat).
Tabulka AK_JINE_PRAV_VZTAHY_M (minulost) slouží k uložení již neplatných dat a využívá se právě pro zpětné výpisy, zjištění vývoje změn atd.

Zaměstnanec při zápisu změny navrhne v _B tabulce stav, jak by data měla vypadat. Poté proběhne kontrola jiným pracovníkem a pokud je úspěšná, tak se provede zplatnění řízení, což znamená, že se z přítomnostní tabulky (bez suffixu) data přesunou do minulostní (suffix _M) a z budoucnosti (suffix _B se přesunou do přítomnosti).
Z toho plyne, že bychom aplikační aktualizací problém s délkou textu jen přesunuli z tabulky pro přítomnost (AK_JINE_PRAV_VZTAHY) do tabulky pro minulost (AK_JINE_PRAV_VZTAHY_M).

Pozn.: Rozdělení na 3 tabulky a ne např. použitím atributu v jedné tabulce je dáno historicky. Bylo na zvoleno začátku tvorby ISKN (1997) pro optimalizaci výkonu, protože většina dotazů je na přítomnost, která oddělením od minulosti není velká. 
V ISKN se následně pro přístup využívají tzv. Partitioned views, což v současné době není doporučované technika a působí problémy při migraci na vyšší verze (zhavaroval na ní pokus o přechod na Oracle 11, protože se k takovýmto view přistupuje přes opět hodně zabugovaný JPPD).  Aktuálně se v rámci migrace na Oracle 12c připravuje změna založena na sloučení těchto 3 tabulek do jedné s využitím Oracle Partitioningu, což udělá docela vítr v datovém modelu a celé aplikaci, ale je to koncepční řešení.

5) Úprava problémového textu v ISKN na úrovni databáze

Protože jsme administrátoři, tak můžeme provést update záznamu na úrovni databáze. pomocí SQL příkazu. Jenže to si nemůžeme jen tak dovolit. Někdo ten záznam vytvořil, je za jeho obsah odpovědný a my bychom mu to změnili. Záznam vznikl na základě nějaké listiny, která byla doručena spolu s  návrhem na vklad. Zasáhnout do zapsaného textu není tak jednoduché a mohlo by to znamenat problém, přestože bychom to provedli v dobré víře zprovoznění replikací.

Problém je v tom, že změna by se projevila nejen v Nahlížení, ale i v ISKN, ze kterého pracovníci vydávají veřejné listiny, a také ve výstupech Dálkového přístupu, které mají také charakter veřejné listiny a jsou opatřeny kvalifikovanou pečetí.

Další komplikací by mohlo být, pokud by někdo v rozmezí od okamžiku zápisu daného textu v ISKN do provedení této "tvrdé" opravy na úrovni databáze získal Výpis z KN,  ať už z Dálkového přístupu nebo na přepážce, případně by odebral data ve výměnném formátu nebo jako geodet přes WS GP. Pokud bychom do textu sáhli takto natvrdo, mimo aplikační logiku, tak by se při vyhotovení výpisu ke zpětnému časovému okamžiku toulaly po světě dva výpisy z KN s platností ke stejnému časovému okamžiku, ale s jinými texty. U výměnného formátu bychom zase porušili logiku změnových vět.

Ačkoli by tedy technicky tato změna byla jednoduchá (jeden SQL příkaz), tak z formálního hlediska zase tak jednoduchá není.  

Řešení 

Nějak jsme situaci ale vyřešit museli. Replikace stály už více jak 24 hodin, což není dobré ani pro uživatele, ani pro systém, protože se hromadí data v replikačních frontách a následné spuštění replikací je o to delší.

Varianty 1) a 2) byly hodně rizikové. Komplikuje je také fakt, že v databázi  s replikacemi se nemůžete jen tak v případě problémů vrátit v čase zpět. Kdyby se nějaký problém objevil po tom, co by úspěšně do Nahlížení proběhly replikace z ISKN nebo ISÚI, tak už by se nešlo vrátit zpět a následně zkusit jiné řešení, protože by se replikace rozsynchronizovaly (v ISKN nebo ISÚI  by byla data, která by se tvářila, že už jsou zreplikovaná i v Nahlížení, ale tam by díky vrácení v čase se zpět nebyla). Data by se musela  přenést všechna znovu (provést tzv. complete refresh, který přenese vše, ne pouze fast refresh, který přenáší jen změny). Complete refresh je na dlouho a ještě komplikovaný tím, že ve zdrojové databázi (ISKN, ISÚI) nesmí v tu dobu pro aktuálně přenášení MVIEW probíhat žádné změny. Následně by se v Nahlížení musela kompletně znovu spočítat grafika, viz konec bodu 3). V neposlední řadě bychom vrácením se zpět také přišli o všechna data pořízení přímo v Nahlížení.

Varianta 3) by sice byla funkční a bez problémů, ale časově velmi náročná (dny) a řešila by jen jednu tabulku. Varianta 4) by nepomohla a tak nám po dlouhém zvažování (pořád jsme přemýšleli nad 1) a 2) ) zbyla varianta 5).

Varianta 5) také nebyla ideální, nicméně jsme se pro ni rozhodli s tím, že nám umožní vyřešit co nejrychleji aktuální problém a získáme čas na provedení koncepčního řešení.

Přemýšleli jsme, co s tím, jak změnit text, aby z toho nebyl problém. Nakonec jsme se rozhodli, že zkusíme jen odstranit diakritiku. Nejprve jsme zkontrolovali, že se odstraněním diakritiky nijak nezmění význam textu. Pak jsme prověřili vydané výpisy, výstupy výměnného formátu atd., viz popis ve variantě 5). Naštěstí proběhl jen relativně krátký časový okamžik a ještě to bylo v pátek. Odešlo sice vyrozumění o zápisu daného řízení a s ním výpis, ale to je kontrolovaný a podchycený proces. Do karet nám také hrál fakt, že se by se "jen" odstranila diakritika, takže i kdyby byl výpis vydaný, nebyl by to takový průšvih, nicméně příjemné by to nebylo.

Museli jsme také ověřit, že daným zásahem nezpůsobíme nějakou aplikační nekonzistenci. Některé akce v ISKN jsou hlídány přes databázové triggery a jejich nové spuštění by mohlo vyvolat např. duplicity v navázaných datech atd.

Po prověření jsme požádali vedení o schválení provedené této "tvrdé" úpravy přímo v databázi a po vysvětlení situace, našich zjištění a možných řešení jsme obdrželi souhlas. Zazálohovali jsme tedy měněný záznam a provedli jeho aktualizaci jednoduchým příkazem:

update ak_jine_prav_vztahy set

popis_pravniho_vztahu=convert(popis_pravniho_vztahu,'US7ASCII')

where id=1234

Za dalších 30 minut už všechny replikace na Nahlížení úspěšně proběhly. 

Závěr

Řešení tedy bylo triviální a otázka 5 sekund. Než jsme k němu ale dospěli, tak to trvalo 1.5 dne (1/2 pátku a sobotu) perné práce, protože jsme museli zkoumat možné varianty, ověřovat je atd.

Není to ale řešení trvalé a teď zvažujeme co dál. Naštěstí pravděpodobnost, že by se situace mohla opakovat velká není (délka textu byla opravdu extrémní). Do definitivního vyřešení jsme přijali i organizační opatření. Zatím váháme, zda se v rámci připravovaného cross-platform upgrade (v rámci konsolidace prostředí přechod databáze Nahlížení z Linuxu na AIX) pustit do řešení podle poznámky v bodu 2), které by bylo sice systémovější, ale s možnými problémy, nebo zda půjdeme řešením 3) a sloupec (vlastně sloupce, celkem takových s VARCHAR2(4000) máme v různých tabulkách 4) v Nahlížení rozdělíme na 2. Pokud bychom to dělali řízeně, s prázdnou replikační frontou, tak bychom nepřišli o žádné změny a nebylo by nutné přepočítávat grafickou část.

---

Pár zajímavostí a poznámek pod čarou

1) Kdybychom nebyli "pokrokoví" a databází Nahlížení udělali také v Singlebyte kódování a nikoli Unicode s proměnnou délkou, tak jsme si tyto problémy ušetřili, obzvláště v kombinaci s replikacemi databází databází s různým character set.

2) Pokud vás zajímá, na čem ztroskotal náš předchozí pokus o upgrade ISKN na Oracle 11g nebo  problematika Partiton Views zmíněná v řešení 3) s bugy JPPD, tak si přečtete naši podrobnou analýzu. Výživné a velmi poučné čtení.

3) Chyba "ORA-12899: value too large for column"  se při replikacích začala objevovat až po nedávné migraci (prosinec 2018) databáze Nahlížení na Oracle 12.2. Ten samý problém ale byl i v předchozích verzích, jenže Oracle při replikacích chybu nehlásil, ale data prostě bez jakéhokoli upozornění ořezal, což je ještě horší.

4) Tvrdým limitem 4000 byte pro VARCHAR2 byli překvapení i samotní pracovníci podpory Oracle. Nemohli ve svých interních systémech dohledat hlášený obdobný problém, což zase překvapilo nás. Zřejmě se kombinace tak dlouhých VARCHAR2 položek v kombinaci s proměnnou délkou kódování a znaky, které se nevejdou do 1 byte, tak často neobjevuje a používá se spíše CLOB.

5) Chování Oracle při použití Multibyte s proměnnou délkou (Nahlížení, AL32UTF8) je opravdu zákeřné, příklad:
(funkce length(rpad('X',4000,'X')) doplní řetězec "X" až do délky 4000 znaků dalšími "X")

SQL> select length(rpad('X',4000,'X')) as delka from dual;

DELKA

--------------------------

                      4000 (očekávaný výsledek)

Když místo US znaku X použijete znak český, tak najednou dostanete pouze 2000 znaků (reprezentovaných 4000 byte): 

SQL> select length(rpad('Ň',4000,'Ň')) as delka from dual;

DELKA

--------------------------

                      2000 

Pro mě neočekávaný výsledek, který je daný tím, že interní reprezentace v rámci implicitního kurzoru pro 2000 českých znaků je v Multibyte 4000 byte a Oracle to prostě na 2000 znacích bez uzardění ořízne. Když ten samý dotaz spustíte v Singlebyte databázi (ISKN, EE8ISO8859P2), tak je vše OK:

SQL> select length(rpad('Ň',4000,'Ň')) as delka from dual;

DELKA

--------------------------

                      4000 

Dotaz vypadá nevinně a různý výsledek v různých databázích docela zaskočí. Na takových věcí pak narazíte spousty, pokud už víte, co hledat. 

6) V dokumentaci Oracle se píše: 

The VARCHAR2 datatype stores variable-length character strings. When you create a table with a VARCHAR2 column, you specify a maximum string length (in bytes or characters) between 1 and 4000 bytes for the VARCHAR2 column. 

Je to zavádějící a jak jsem psal, překvapilo to i samotné pracovníky Oracle. Tohle vám prostě nedocvakne, když o tom nevíte. O nutnosti používat v Multibyte jednotky Char jsme věděli (narazili jsme na to v replikacích již dříve u kratších polí), ale o tvrdém limitu 4000 byte při použití Char ne. Chtělo by to velké červené varování.

7) Z mého textu mohlo zdát, že Oracle je ten nejvíce zabugovaný SW na světě a je prakticky nepoužitelný. Přesto si myslím, že Oracle je v oblastí SQL databází špička, daleko před ostatními (např. technologie RAC), a jinou databází bychom si nijak nepolepšili. Bugy jsou všude a u nás většinou bohužel narazíme na nějaké speciality, které se jinde neřeší. Navíc český support se opravdu snaží. Ale je pravda, že si Oracle jak za licence, tak služby supportu, nechá řádně zaplatit.

8) K druhé větě v odstavci Řešení - někteří uživatelé jsou tak nedočkaví, že se občas stane situace, že náš zaměstnanec zplatní řízení a než připraví a odešle účastníkům řízení vyrozumění o zápisu (to jde i Datovou schránkou), tak se data stihnou zreplikovat na Nahlížení (replikace mohou proběhnout třeba za 5 minut), kde si uživatelé hlídají jejich řízení/LV a volají našemu zaměstnanci, kdy si mohou přijít pro výsledek atd. :-)

Mají být všechna data státu zdarma?

Velmi často se někde objeví názor, že by měl stát dávat všechna data, která má, a které nepodléhají utajení, zdarma. Prakticky to samé platí i pro poskytované služby. Na jednu stranu je to představa poměrně líbivá, i pro mě. Jsem informatik a v datech se rád hrabu, takže bych s tím souhlasil. Na první poslech logicky zní i argument typu "zaplatili jsme si to z daní", který je občas v těchto souvislostech slyšet. Proti faktu, že by to mohlo rozjet další podnikání a služby občanům, také nelze nic namítat. Bohužel to má ale i druhou stránku, kterou si lidé hned neuvědomí.

Stanovené příjmy

O tomhle faktu se moc veřejně neví, nebo jsem na něj alespoň zatím nikde, u podobných diskuzí,  nenarazil. Státní úřady, přinejmenším některé, mají ze zákona, který reprezentuje Zákon o státním rozpočtu, stanoveny příjmy, které musí splnit (lidově řečeno "vybrat peníze"). Jsou dvoje typy příjmů - daňové (typicky správní poplatky) a nedaňové, mezi které patří příjmy za úplatu (neplést s úplatkem :-), pojem je opakem k bezúplatně poskytovaným věcem).

ČÚZK měl pro rok 2017 rozpočtem stanoveny následující podmínky (zdroj Výroční zpráva ČÚZK za rok 2017):
"Schválený státní rozpočet pro kapitolu 346 Český úřad zeměměřický a katastrální na rok 2017 byl stanoven ve výši 700 mil. Kč pro příjmy a v objemu 3 048,8 mil. Kč pro výdaje. Rozpočet daňových příjmů zahrnující správní poplatky byl stanoven ve výši 550 mil. Kč, jeho plnění dosáhlo objemu 651,8 mil. Kč, tj. 118,5 %. Nedaňové příjmy v roce 2017 byly kapitole stanoveny ve výši 150 mil. Kč a byly naplněny objemem 237,7 mil. Kč, tj. plnění na 158,5 %. "

Pokud tyto stanovené příjmy nejsou splněny, tak dochází směrem k nám ke krácení výdajů ze státního rozpočtu, což má přímý dopad do investičních činností atd. a není to příjemná situace. Takže i státní úřady jsou nuceny vybrat peníze za svoji činnost a pokud se tak nestane, jsou penalizovány. Není to tak, že je jedno, kolik příjmů mají. Pokud bychom měli všechna data poskytovat zdarma, tak o část těchto příjmů přijdeme. To by bylo třeba zohlednit ve státním rozpočtu, aby s tím počítal. To se ale dnes neděje a i proto se musíme snažit data prodávat.

Je to komplikované i tím, že zdaleka nemůžeme být tak pružní, jako soukromé firmy. Nemůžeme si udělat "Black friday". Nemůžeme jednoduše upravit výši správních poplatků a úplat. To, co soukromá firma je schopna udělat lusknutím prstu, musí státní instituce prohnat přes zákony a vyhlášky, což je věc minimálně na 1/2 roku, když to jde velmi dobře. Naše ceny jsou stanoveny vyhláškou 358/2013 Sb., o poskytování údajů z katastru nemovitostí.

Problém z příjmů byla také jeden ze zásadních připomínek, které jsme v roce 2017 zasílali při připomínkování návrhu usnesení vlády ČR  "o zveřejňování dat, která jsou vedena v informačních systémech veřejné správy spravovaných ústředními správními úřady, jako otevřených dat".

Obecný přístup

I kdyby se problém příjmů vyřešil, tak zde je podle mě ještě závažnější otázka. Opravdu chceme, aby byla všechna státní data zdarma? Z jakého důvodu? Pořízení dat něco stojí, zadarmo nic není. Státní úřady mohou všechna data dávat zdarma, ale tím se se sníží příjmy rozpočtu a pravděpodobně se tak budou muset zvýšit daně, aby tento výpadek pokryly. 

Co je ale správná cesta? Mají všichni plošně platit za něco, co je nezajímá? Proč by si to nemohli zaplatit pouze Ti, kterých se to týká? Já nechci z daní platit data pro Pepíka z Horní dolní. Jsem zastáncem toho, že by daně měly být stanoveny tak, aby pokrývaly pouze široké plošné výdaje státu, u kterých by bylo ve výsledku dražší platit položkově. Za věci, které plošné nejsou, by měly platit jen zájmové osoby, ne všichni. Jaké procento lidí je využije? Bude to většina obyvatel? To mi připomíná spíše socialismus. 

Závěr 

Poskytovat plošně státní data mi z výše uvedeného důvodu nedává smysl. Je ale určitě obtížné najít tu správnou hranici, aby byly spokojeny obě strany, jak stát, tak jeho obyvatelé. Tato problematika není jednoduchá a celá věc není tak černobílá, jak by se na první pohled mohlo zdát.

PS: Pokud chceme data zdarma, musíme ulevit státnímu rozpočtu. Můžete to udělat i vy, třeba tím, že si zřídíte jako fyzické osoby datovou schránku. V našem případě to v našem rozpočtu (nikoli v rozpočtu státu, ale i tak je to celkově levnější) ušetří náklady na poštovné (zdroj Výroční zpráva ČÚZK za rok 2017) a budeme je moci použít na jiné věci:

Služby pošt byly čerpány ve výši 138,1 mil. Kč a vykázaly po loňském snížení opět nárůst o 2 mil. Kč oproti roku 2016

Otevřenost katastru v EU

Občas se vyskytnou diskuze, zda je správně, že je katastr nemovitostí v České republice veřejný a otevřený. Kolegové prošli lokální katastry (land register, LR) některých států a vyrobili přehled, jak je to v EU (+ i někde jinde). Výsledek jejich zkoumání naleznete v tabulce s přehledem otevřenosti katastru v EU.

Raději upozorňuji, že je to pojato zjednodušeně a získáním informací se myslí výpis na jednotlivou nemovitost. Mnohde totiž vůbec nelze nijak získat žádný přehled vlastnictví ani kopii listiny. Někde to získat lze, ale po prokázání právního zájmu (pro listiny to platí s tímto omezením dokonce i na Slovensku, pro přehled vlastnictví zase v Rakousku). 

Primárním zdrojem dat byla stránka http://www.doingbusiness.org/.  

Jak jsem hledat problém s uváznutím (deadlock) v aplikaci Návrh na vklad

ČÚZK vytvořil a provozuje www aplikací Návrh na vklad, která umožňuje uživatelů připravit formulář s návrhem na vklad do katastru nemovitostí. Její součástí jsou i webové služby, které pro generování návrhů využívají např. banky. Vývoj a provoz této aplikace mám na starost se svým týmem.

Při provozu jsme registrovali, že se občas vyskytuje chyba ORA-00060: deadlock detected while waiting for resource, což je problém s uváznutím, kdy se databázové transakce uzamknou proti sobě a ani jedna nemůže pokračovat dál.

Vytvořit deadlock je poměrně jednoduché. Stačí si otevřít dvě session a navodit například následující stav:

Krok	Transakce 1	Transakce 2	Popis
1	UPDATE platy SET plat=1000 WHERE zamestanec_id=1		Transakce 1 si v tabulce PLATY uzamkne záznam pro zaměstnance s ID 1
2		UPDATE odmeny SET castka=2000 WHERE zamestanec_id=10	Transakce 2 si v tabulce ODMENY uzamkne záznam pro zaměstnance s ID 10
3	UPDATE odmeny SET castka=500 WHERE zamestanec_id=10		Transakce 1 se pokouší v tabulce ODMENY uzamknout záznam pro zaměstnance s ID 10, což se ji nedaří, protože zámek drží transakce 2 a transakce 1 tedy musí čekat na dokončení transakce 2.
4		UPDATE platy SET plat=300 WHERE zamestanec_id=1	Transakce 2 se pokouší v tabulce PLATY uzamknout záznam pro zaměstnance s ID 1, což se ji nedaří, protože zámek drží transakce 1 a transakce 2 tedy musí čekat na dokončení transakce 1.

V tento okamžik jsou obě transakce zacyklené. Transakce 1 čeká na dokončení transakce 2, ale ta zase čeká na dokončení transakce 1 a problém s uváznutím je na světě:

(obrázek z http://oracledbpro.blogspot.com/)

Oracle tento stav pomocí backgroud procesu DIAx detekuje, provede roolback příkazu, který ho způsobil a vyhlásí chybu ORA-00060: deadlock detected while waiting for resource.

Malá odbočka. Ohledně deadlocku v Oracle panuje několik mýtů, které je vhodné vyjasnit:

• Oracle neprovede kill žádné session,
• Oracle provede rollback příkazu, ale neprovede rollback celé transakce,
• Oracle background proces PMON (Process Monitor) neuvolní předchozí zámky.

Deadlock se nemusí týkat jen řádků tabulce. Je to jeden ze synchronizačních problému a takto se může uzamknout prakticky cokoli. Hodně se to řeší v operačních systémech a je to velmi zajímavá problematika.

Zpět k naší aplikaci. Chyba ORA-00060 se nám občas vyskytovala v situaci, kdy uživatel, nebo automatický proces, mazal návrh na vklad. Vyskytovala se poměrně zřídka, ale časem začala narůstat na několik výskytů denně. 99 % bylo vyvoláno z automatického procesu, bez vlivu na uživatele, který chybu ani nepoznal.

Pokud se problém s deadlockem vyskytuje v aplikaci, tak je jeho příčina nejčastěji buď chyba v návrhu aplikace nebo chyba v datovém modelu. Většinou se špatně hledá.

Naše aplikace má jednoduchý datový model, který se skládá z cca 70 tabulek. Chyba se vyskytovala při mazání jedné z tabulek NEMOVITOSTI, STAVBY nebo PARCELY. Datový model této části vypadá zhruba takto:

část datového modelu

Při kontrole mazací procedury jsem nenarazil na problém, tak jsem se zaměřil na datový model. Ten jsem prošel, ale také mě nic do oka netrklo, tak jsem musel zkoumat dál. Oracle při výskytu chyby zapíše událost do alert logu (píši se zde všechny důležité události, která v databázi vznikly) a vytvoří trace soubor:

ukázka alert logu

ukázka trace (mívá jednotky až stovky MB)

Otevřel jsem trace a viděl, že problém v tomto případě vznikl při mazání záznamů z tabulky STAVBY:

mazané tabulky

Znovu jsem prověřil danou část modelu, ale vše vypadalo OK. Pátral jsem tedy dál. V trace je graf deadlocku:

Z něj jde vyčíst, že je problém v resource se jménem TM-003f719d-00000000 (viz (1)), kdy transakce má zámek typu SX a čeká na typ SSX. Zámek typu SX, na rozdíl od SSX, může získat pouze jedna transakce. Podle toho, že se nečekalo na uzamknutí řádků (viz (2)), bylo jasné, že se jednalo o problém přímo s uzamknutím celého databázovém objektu (tabulka, index, ...). Jak ho ale zjistit? 

Struktura jména resource TM-003f719d-00000000 mi nic neříkala a nedokázal jsem odvodit, z čeho je složena. Oracle má sice metadata o svých objektech, ale jsou to ID typu NUMBER (sloupec OBJECT_ID), takže tudy cesta nevedla:

pohled DBA_OBJECTS 

Po dalším pátrání na Oracle Metalinku se mi podařilo dohledat dokument Doc ID 62365.1, ve kterém se píše:

dokument Doc ID 62365.1

Takže TM je typ zámku a 003f719d je ID objektu, ale v HEX formátu (pozn.: také mě to mohlo napadnout :-) ). Převedl jsem tedy 003f719d do desítkové soustavy (4157853) a podíval se do metadat, kterému databázovému objektu patří:

identifikace objeku

Problém tedy vznikl při pokusu o uzamknutí tabulky PARCELY_PARCELY.  Při kontrola dalších trace se vždy jednalo pouze o tuto tabulku. Struktura tabulky je jednoduchá, její účel je pouze vazba mezi původními a nově vznikajícími parcelami. Má jen dva sloupce VZNIKAJICI_PARCELY_ID a PUVODNI_PARCELY_ID a oba se přes cizí klíče (FK) odkazují do tabulky PARCELY. Proč se ale zamykala celá? 

Podíval jsem se na indexy a bylo jasno. Tabulka měla sice složený index nad oběma sloupci, ale ne nad sloupcem PUVODNI_PARCELY_ID:

indexy na tabulce PARCELY_PARCELY

To je sice v pořádku pro logiku aplikace, protože se k tabulce vždy přistupuje i přes VZNIKAJICI_PARCELY_ID, ale problém vznikne, když se má mazat záznam v tabulce PARCELY (kde se maže i při mazání STAVBY nebo NEMOVITOSTI). Oracle se musí v ten okamžik podívat do tabulky PARCELY_PARCELY, zda tam nejsou záznamy, které by mazání bránily. Pokud se kontroluje obsah sloupce VZNIKAJICI_PARCELY_ID, tak použije index a je to OK. Ale pokud se kontroluje obsah sloupce PUVODNI_PARCELY_ID, tak se díky chybějícímu indexu uzamkne celá tabulka, což je problém. Aplikace sama o sobě index na tom sloupci nepotřebuje, ale Oracle už ano. 

Řešení bylo jednoduché - vytvoření nového indexu nad sloupcem PUVODNI_PARCELY_ID. Oracle tak při kontrole FK využije index, uzamkne pouze dané záznamy a nikoli celou tabulku. Tohle pracovníkovi při návrhu databáze nedošlo a bývá to poměrně častá chyba. Po vytvoření indexu chyba zmizela, jako mávnutím kouzelného proutku. Problém byl vyřešen a tím mé pátrání skončilo. 

Na závěr bych chtěl dodat, že by z toho mohl plynout závěr, že by se měl na každý sloupec, který obsahuje FK, udělat index a byl by pokoj. Mělo by tedy stačit zkontrolovat, např. jednoduchým dotazem do metadat Oracle, zda každý takový sloupec index má. To ale není dobrý přístup. Sice se vyhnete těmto problémům, ale budete nutit Oracle tento index udržovat, což stojí nějaké zdroje (disk, I/O, CPU). Je to třeba posuzovat případ od případu. Pokud se například odkazujete na číselníkovou položku, která se nemaže (číselníkové položky se typicky jen zneplatní), tak index potřeba není, protože tam žádná kontrola neprobíhá.