Školení správců RD Školící materiál projektu TF04

Administrace RD2 Úkoly správce RD Dohled nad funkčností infrastruktury –Databáze, Konektivity, Dalších komponent RD Dohled nad zabezpečením –Nastavování uživatel práv, Detekce průniků, Kontrola činnosti Nahrávání dat od poskytovatelů Sledování výkonu serverů

Administrace RD3 Cíle školení Seznámení s infrastrukturou RD Základní přehled Oracle serveru Struktura RD Víceúrovňové zabezpečení dat Distribuce dat na více serverů, replikace Monitorování databáze a uživatelů Dávkové zpracování dat Data recovery XML a Oracle

Infrastruktura RD

Administrace RD5 Infrastruktura RD 10 x PC s 1-2 x Intel 64bit Xeon Operační systém GNU/Linux –Red Hat Enterprise (certifikace pro Oracle) –Fedora (free verze Red Hat) 2 x Oracle server 10g Release 2 Enterprise Edition 2 x Oracle Application server

Administrace RD6 Internet Interní DB s osobními daty a produkty Aplikace … … správce … … RD Interní AS DMZ DB pouze s replikou produktů Firewall (Intranet/DMZ) Firewall (DMZ/Intranet) Web Server (HTTPS)SFTP Server DMZ AS

Administrace RD7 Infrastruktura RD, INTDB Počítač INTDB –OS Red Hat Enterprise –DB Oracle Server 10g EE (Named user license) Intranet, nedostupné z Internetu Databáze obsahuje citlivé soukromé údaje o pacientech a firmách. –Nutné zabezpečení dat

Administrace RD8 XML Produkty XML L0L1 Číselníky Repozitoř L2 Infrastruktura RD, INTDB Správce

Administrace RD9 Infrastruktura RD, INTAPP Počítač INTAPP –Red Hat Enterprise –Oracle Application Server 10g Intranet, nedostupné z Internetu –Slouží výhradně pro připojování správcovských aplikací

Administrace RD10 Infrastruktura RD, DMZDB Počítač DMZDB –OS Red Hat Enterprise –Oracle Server 10g EE (Processor license) DMZ dostupné z Internetu pouze nepřímo –prostřednictvím aplikačního Oracle serveru –prostřednictvím web serveru Databáze neobsahuje citlivé soukromé údaje o pacientech a firmách. Pouze agregovaná data z registrovaných případů.

Administrace RD11 Produkty XML L0L1 Číselníky Repozitoř L2 Produkty Číselníky Repozitoř Uživatelé Jednosměrná replikace Infrastruktura RD, DMZDB

Administrace RD12 Infrastruktura RD, DMZAPP Počítač DMZAPP –Red Hat Enterprise –Oracle Application Server 10g DMZ, nedostupné z Internetu –Jeden z možných způsobů zprostředkování přístupu k DB zvenčí

Struktura Oracle serveru

Administrace RD14 Struktura DB Oracle ukládá data více uživatel Dvojí členění úložného prostoru –Logické – schémata – podle vlastníka –Fyzické – tabulkové prostory – podle místa uložení

Administrace RD15 Struktura DB – schémata Sdružují data jednoho vlastníka Logicky oddělené –Uživatelé standardně vidí jen všechna data svého schématu –Cizí data vidí jen na základě vlastníkem explicitně přiděleného oprávnění SYSTEMSCOTTJANMZDRG… SYSSYSTEMMZDRGSCOTTJAN …

Administrace RD16 Struktura DB – tab. prostory (tablespaces) Sdružují data bez ohledu na vlastníka Fyzicky oddělené v různých úložištích –Samostatně spravovatelné –Online/Offline –Kvóty uživatel x ts SYSTEMUSERSTEMPUNDOMZDRG… SYSSYSTEMMZDRGSCOTTJAN

Administrace RD17 Tabulkové prostory Oracle databáze se skládá z jednoho nebo více tabulkových prostorů –SYSTEM – nezbytný tab. Prostor pro běh DB, obsahuje metadata o struktuře DB (datový slovník) –USERS – standardní defaultní prostor určený pro ukládání dat uživatel –TEMP – standardní dočasný prostor pro dočasná data serveru, vytvářená a rušená při vyhodnocování příkazů uživatel –UNDO – obsahuje původní data běžících transakcí, realizuje ROLLBACK transakcí, FLASHBACK dotazy

Administrace RD18 Tabulkový prostor SYSTEM Musí být přítomný v každé databázi Nejde odstranit Nelze změnit na offline (ALTER TABLESPACE system OFFLINE; skončí chybou) Vytváří se automaticky při vytvoření databáze Obsahuje datový slovník

Administrace RD19 Datový slovník DB Popisuje strukturu všech objektů (tabulek, indexů, pohledů, procedur, … v DB) Uložený v prostoru SYSTÉM –DICT[IONARY] – seznam všech pohledů slovníku –USER_* – seznam všech uživatelem vlastněných objektů –ALL_* – seznam všech uživatelem viditelných objektů –DBA_* – seznam všech objektů –V$* – seznam dynamicky se měnících objektů

Administrace RD20 Datový slovník DB USER_* –USER_OBJECTS – seznam všech objektů všech typů, jen jméno, typ objektu, status objektu a základní údaje o jeho vytvoření –USER_TABLES, USER_INDEXES, USER_VIEWS, … – detailní popis objektů jednoho typu

Administrace RD21 Datový slovník DB ALL_* –ALL_OBJECTS – seznam všech objektů všech typů, jen jméno, typ objektu, status objektu a základní údaje o jeho vytvoření –ALL_TABLES, ALL_INDEXES, ALL_VIEWS, … – detailní popis objektů jednoho typu Navíc sloupec OWNER, určující vlastníka

Administrace RD22 Datový slovník DB DBA_* –DBA_OBJECTS – seznam všech objektů všech typů, jen jméno, typ objektu, status objektu a základní údaje o jeho vytvoření –DBA_TABLES, DBA_INDEXES, DBA_VIEWS, … – detailní popis objektů jednoho typu Navíc sloupce s údaji nedostupnými pro běžné uživatele, některé pohledy

Administrace RD23 Datový slovník DB V$* –Dynamicky se měnící data, uložená jen v paměti serveru Seznamy přihlášených uživatel Seznamy existujících zámků na datech …

Administrace RD24 Tabulkový prostor UNDO Slouží k uchovávání undo informací Nelze zde vytvářet jiné objekty – např. tabulky nebo indexy Nemůže být odstraněn, pokud obsahuje nějakou informaci potřebnou ke zotavení běžící transakce Je možné mít více undo TS a přepínat mezi nimi (RD používá pouze jeden)

Administrace RD25 Tabulkový prostor TEMP Může obsahovat pouze dočasné objekty po dobu session Nelze použít pro uchování trvanlivých dat Oracle ho využívá např. při třídících operacích požadovaných uživateli, kteří jej mají přiřazen Musí být dost velký, aby mohl uložit potřebná tříděná data

Administrace RD26 Tabulkový prostor MZDRG –Defaultní prostor pro ukládání dat uživatele MZDRG –Obsahuje data RD (vlastněná tímto uživatelem) –Kvótu zde by neměl dostat žádný z uživatel DB, ani ti, kteří s daty RD pracují –Pro provoz RD musí být ONLINE

Administrace RD27 Struktura DB – úložiště Data tab. prostorů se ukládají do fyzických úložišť (souborů, diskových oddílů, …) Jeden prostor může mít přiděleno více úložišť Pokud dochází místo, je možné přidat další úložiště SYSTEMUSERSTEMPUNDOMZDRG… SYSSYSTEMMZDRGSCOTTJAN s01. dbf s02. dbf u01. dbf t01. dbf undo. dbf m01. dbf m02. dbf …

Administrace RD28 Struktura DB Každý uživatel může mít stanovenu pro každý tabulkový prostor kvótu –maximální prostor, který může v DB v daném tabulkovém prostoru zabrat UNLIMITED – neomezená (pouze velikostí úložiště pod ním) Konkrétní velikost – 10M, 1024M, … Žádnou –MZDRG má neomezenou kvótu ve svém prostoru –Pro dočasné prostory se kvóty nepřidělují –Kvóta se počítá vlastníkovi tabulky, ne tomu, kdo data vkládá Uživatelé, kteří s daty uživatele MZDRG jen pracují nepotřebují mít v DB žádné kvóty

Administrace RD29 Struktura DB Popis logické struktury DB v pohledu –DBA_USERS Popis fyzické struktury DB v pohledech –DBA_TABLESPACES –DBA_DATA_FILES –DBA_TEMP_FILES –DBA_SEGMENTS –DBA_TS_QUOTAS

Administrace RD30 Proč samostatný prostor MZDRG Fyzicky odděluje data RD od ostatních –Zabraňuje závislosti RD na ostatních aplikacích, které případně v DB běží. –RD dostupná i v případě nutnosti odpojit jiný prostor –Dovoluje ukládat data na samostatná úložiště Dovoluje samostatné zálohování a obnovu dat.

Administrace RD31 Alokace dat Tabulkový prostor je rozdělen na bloky pevné délky (8KB, 16KB, …) Každý datový objekt (tabulka, index) si v tabulkovém prostoru vytváří vlastní segment – spojový seznam obsazených úseků Jeden úsek je alokován v jednom souboru Jednotlivé úseky mohou být alokovány v různých souborech tabulkového prostoru

Administrace RD32 Alokace dat

Administrace RD33 Instance serveru Na jednom stroji může současně běžet více serverů Oracle Není to vhodné kvůli sdílení výkonu a zdrojů (CPU, MEM, I/O) Jeden server je tvořen tzv. instancí – komplexem datových souborů, běžících procesů a alokované sdílené paměti

Administrace RD34 Instance serveru Využití paměti Oracle na serveru –Programový kód –Informace o připojených sezeních, pokud nejsou právě aktivní –Informace potřebné během vykonávání programu (např. současný stav dotazu0 Informace, které jsou sdíleny mezi jednotlivými procesy (např. informace o zámcích) Datové záznamy

Administrace RD35 Instance Oracle, paměť System Global Area (SGA) –Sdílí se mezi všemi serverovými a background procesy, obsahuje database buffer cache, redo log buffer, shared pool, large pool (je-li nastaveno), java pool, data dictionary cache a další informace. Program Global Areas (PGA) –privátní pro každý serverový i background proces, existuje jedna PGA pro každý proces. Obsahuje stack areas, data areas.

Administrace RD36 Instance Oracle, paměť System Global Area –Database buffer cache –Redo log buffer –Shared pool –Large pool –cache datového slovníku –Informace zámcích –…

Administrace RD37 Instance Oracle, procesy Dedikované server procesy –Obsluhují vždy jedinou klientskou session –Vhodné pro klienty, kteří velmi vytěžují zdroje serveru

Administrace RD38 Instance Oracle, procesy Sdílené server procesy –Obsluhují více klientů zároveň –Vhodné pro velké množství klientů, kteří požadují služby serveru s velkými prodlevami

Administrace RD39 Instance Oracle Procesy na pozadí –Starají se o ukládání změněných dat do souborů, správu žurnálů, Archivaci žurnálů …

Struktura RD

Administrace RD41 Cíle RD Dvě verze –Původní RD Ukládání výkazů o výkonech dle VZP –Nová RD Ukládání výkazů o registrovaných případech Zpracovávání výkazů Poskytování statistických dat o registrovaných případech

Administrace RD42 Struktura RD Obě verze z velké části oddělené –Samostatná primární data Jiný formát vstupů Jiné entity Jiné zpracování –Sdílené části a moduly, které se sdílet vyplatí Číselníky VZP Import číselníků

Administrace RD43 Stávající představa datových sad

Administrace RD44 Předpokládaní uživatelé RD plátci – zdravotní pojišťovny spotřebitelé – pacienti poskytovatelé zdravotní péče administrativa – státní správa a samospráva (včetně ČSÚ, ÚZIS, SZÚ) zdravotnický průmysl – výrobci zdravotnického vybavení (nástrojů, přístrojů), zdravotnických prostředků, léků a materiálu dodavatelé softwaru, hardwaru, komunikací, bezpečnostních systémů

Administrace RD45 Předpokládaní uživatelé RD vývojové firmy v oblasti informačních systémů, informačních technologií, medicínských expertních systémů, lékařské informatiky, … akademická obec – specializované ústavy Akademie věd, lékařské fakulty univerzit,... developeři – projekční a stavební firmy, architekti finanční instituce (banky, komerční pojišťovny) politické subjekty (strany, hnutí, …)

Administrace RD46 Typy uživatelů RD Správce – administrátor –Má – jako jediný – plný přístup k datům, uloženým v RD –Má odpovědnost za chod RD a její dostupnost a funkčnost pro jiné uživatele Smluvní dodavatel dat –Poskytuje a opravuje svoje vstupní data v požadovaném formátu

Administrace RD47 Typy uživatelů RD Smluvní uživatel vlastních dat (každý smluvní dodavatel) –Různé profily podle uzavřené smlouvy stupeň agregace zobrazovaných dat repertoár produktů Smluvní uživatel vybraných dat –Různé profily podle uzavřené smlouvy stupeň agregace zobrazovaných dat repertoár produktů teritórium (okres, kraj, region)

Administrace RD48 Typy uživatelů RD Smluvní uživatel všech dat (zákonné výjimky – MZ ČR) –Různé profily podle uzavřené smlouvy stupeň agregace zobrazovaných dat repertoár produktů teritorium (okres, kraj, region) Nesmluvní uživatel (široká veřejnost – spotřebitelé) –Jeden profil vybraná agregovaná data vybrané produkty vybraná lokalizace produkce

Administrace RD49 Navrhované produkty RD Produkty a služby RD mohou být vztaženy ke kombinaci různých hledisek –podle místa: Česká republika  kraj  okres  poskytovatel –podle formy: ambulantní  jednodenní  hospitalizační  ostatní –podle problému: diagnóza  výkon

Administrace RD50 Vykazování - datové sady Registrovaný případ –Vztahuje se k určitému zdravotnímu problému pacienta –Dělí se na epizody zdravotní péče různých forem (ambulantní, hospitalizační, …) –Ty se dále dělí na dílčí epizody zdravotní péče –V rámci dílčích epizod ZP se vykazují provedená vyšetření a zákroky pomocí zdravotních služeb

Administrace RD51 Vykazování – datové sady Problém se zákonem na ochranu osobních údajů –Nutný dva explicitní souhlasy pacienta S registrací a zpracováním údajů pacienta zdravotním střediskem – poskytovatelem dat S registrací a zpracováním údajů pacienta provozovatelem RD Nutná vysoká úroveň zabezpečení dat proti neoprávněnému přístupu k nim

Administrace RD52 Vykazování – formát dat Oproti formátu vykazování VZP byl zvolen formát XML –Textový dokument –je možné jej zobrazit v libovolném textovém editoru. –Nativní podpora kódování češtiny – jazyk XML dovoluje deklarovat použitou kódovou stránku (UTF-8, CP-1250, ISO- LATIN2, …). –Hierarchická struktura – odpovídá hierarchické povaze vykazovaných dat –Definovatelná sémantika obsahu – každá část textu může být uzavřena do speciálních značek a, které určují význam hodnoty, uzavřené mezi nimi.

Administrace RD53 Vykazování – formát dat Oproti formátu vykazování VZP byl zvolen formát XML –Srozumitelnost pro lidskou obsluhu – v případě potřeby je snadné data prohlédnout a zkontrolovat ručně. –Snadné generování na straně softwaru poskytovatele dat –soubory se dají snadno vytvářet v libovolném programu. –Podpora validace obsahu – XML soubor může odkazovat na jiný XML soubor, popisující v jazyce XML Schema pravidla pro syntaktickou kontrolu obsahu dokumentu. Umístěním schématu na Internet je možné vůči jednomu exempláři ověřovat všechny na něj odkazující dokumenty. –Existující software třetích stran pro zpracování a manipulaci se soubory –XML soubory je možné zpracovávat a transformovat v řadě aplikací třetích stran. Přímou podporu zpracování a vytváření XML dat má i Oracle samotný.

Administrace RD54 Struktura RD Obdoba OLAP databází –Tři vrstvy dat L0 – primární XML soubory L1 – relační data transformovaná do struktury datových sad L2 – zpracované statistické údaje (+číselníky, +repozitoř) –Dvoje datové pumpy L0  L1 L1  L2

Administrace RD55 Struktura RD XML Produkty XML L0L1 Číselníky Repozitoř L2 Správce

Administrace RD56 Struktura RD Proč třívrstvá architektura dat v DB? –Flexibilita Možnost přizpůsobení neustále se měnícím, dlouho nefinálním zadáním Při změně formátu XML nutné změnit pouze datovou pumpu L0  L1 (XML data se uchovávají v původní podobě bez ohledu na svoji strukturu) Všechna syntakticky validní data jsou V L0 vždy k dispozici, je možné je znovu zpracovat na základě změněných pravidel

Administrace RD57 Struktura RD Proč třívrstvá architektura dat v DB? –Flexibilita Při změně datových sad (například v případě rozhodnutí o uchovávání dat v předzpracované anonymní statistické podobě) je nutné změnit pouze strukturu L1 a datové pumpy Všechna sémanticky validní data jsou V L1 vždy k dispozici, je možné je znovu statisticky zpracovat na základě změněných pravidel

Administrace RD58 Struktura RD Proč třívrstvá architektura dat v DB? –Flexibilita Při změně produktů je nutné změnit pouze strukturu L2 a datovou pumpu L1  L2

Administrace RD59 Struktura RD Veřejná data –Části L2 –Číselníky VZP (výkony, MKN10) –Číselníky zdravotních služeb –Číselníky ICD-9-CM, ICD-10-PCS –Repozitoř

Zabezpečení RD

Administrace RD61 Víceúrovňové zabezpečení RD Vyplývá z povahy dat –V databázi Intranetový server s úrovněmi L0, L1 i L2 –Pouze administrátor –Neviditelná z internetu –Nemožnost se připojit z Internetu ani nepřímo Server v DMZ s jednosměrnou replikou L2, číselníky a repozitoří –Uživatelé –Role –Virtuální privátní databáze

Administrace RD62 Víceúrovňové zabezpečení RD Vyplývá z povahy dat –Mimo databázi Firewall mezi Intranetem a DMZ –Pouze jednosměrné propojení mezi servery –Nabourání DMZ serveru neohrozí data v Intranetu Firewall mezi DMZ a Internetem –Pouze povolené typy připojení »HTTPS pro připojení k Webovému serveru »FTPS pro upload XML dat

Administrace RD63 Internet Interní DB s osobními daty a produkty Aplikace … … správce … … RD Interní AS DMZ DB pouze s replikou produktů Firewall (Intranet/DMZ) Firewall (DMZ/Intranet) Web Server (HTTPS)SFTP Server DMZ AS

Administrace RD64 Víceúrovňové zabezpečení RD Zabezpečení před ztrátou dat –Redundantní uložení dat LVM RAID 1 s databázovými soubory –Poškození jednoho disku neohrozí data v DB AUTOMATIC REDOLOG MODE v DB –Zajistí možnost online zálohování –Zajistí možnost obnovení DB k okamžiku poškození Úroveň L0 s XML daty –Zajistí evidenci všech podkladů –Ostatní data možno přegenerovat

Administrace RD65 Víceúrovňové zabezpečení RD Zabezpečení před neoprávněným přístupem a manipulaci s daty během přenosu –Asymetrické šifrování XML dat během přenosu

Administrace RD66 Víceúrovňové zabezpečení RD Zabezpečení před neoprávněným přístupem a manipulaci s daty během přenosu –Komprese XML pro snížení redundance a zvýšení náhodnosti –RSA klíče s délkou minimálně 2048 bitů –Veřejné klíče poskytovatelů podepsány certifikační autoritou Pouze provozovatelem RD Uznávanými autoritami (I. CA, …) Nepřímo prostřednictvím provozovatele RD

Administrace RD67 Víceúrovňové zabezpečení RD Pouze provozovatelem RD Veřejný klíč provozovatele RD 2 RD Veřejný klíč provozovatele RD 1 RD

Administrace RD68 Víceúrovňové zabezpečení RD Přímo uznávanými autoritami (I. CA, …) Veřejný klíč provozovatele RD 2 I. CA Veřejný klíč provozovatele RD 1 I. CA

Administrace RD69 Víceúrovňové zabezpečení RD Nepřímo prostřednictvím provozovatele RD Veřejný klíč provozovatele RD 2 Veřejný klíč provozovatele RD 1 RD I. CA RD I. CA

Administrace RD70 Import dat do RD Dodavatel: odeslání (zašifrovaného a podepsaného) souboru em na vyhrazenou adresu Správce: Přijetí souboru Správce: Potvrzení přijetí Správce: Nahrání (dosud zašifrovaného a podepsaného) XML souboru na pro ten účel vytvořený SFTP server v DMZ Správce: odeslání potvrzení o nahrání, případně chybového hlášení odesilateli

Administrace RD71 Import dat do RD Dodavatel: Nahrání (dosud zašifrovaného a podepsaného) XML souboru na pro ten účel vytvořený SFTP server v DMZ Správce: odeslání potvrzení o nahrání, případně chybového hlášení odesilateli

Administrace RD72 Import dat do RD Dávkové zpracování XML souborů, nahraných na SFTP server –Stažení do Intranetu, dešifrování, ověření podpisu, ověření validity oproti XML Schema definici –Nahrání do L0 (1:1) –Ověření sémantiky dat, nahrání do L1 –Zpracování do L2 –Replikace L2 na server v DMZ

Distribuce a replikace dat

Administrace RD74 Replikace dat Důvody –Zabezpečení osobních údajů před neoprávněným průnikem –Pokud se podaří chybou SW či implementace napadnout server v DMZ, nedojde ke zveřejnění chráněných dat –Poškození lze snadno opravit obnovením z primární kopie v databázi v Intranetu

Administrace RD75 Replikace dat Co replikovat –Číselníky veřejné –Produkty částečně veřejné, částečně dostupné jen smluvním zákazníkům –Repozitoř Veřejné definice medicínských pojmů

Administrace RD76 Replikace dat Jak replikovat (možnosti) –Pomocí DB LINK a triggerů, které opakují změny v tabulkách RD do vzdálených tabulek na serveru v DMZ Každá aktualizace se provádí současně dvojmo Spojení se provádí z Intranetu do DMZ Tabulka Link Tabulka Trigger

Administrace RD77 Replikace dat Databázový link –Jednosměrný odkaz z jedné databáze (Intranet) do druhé (DMZ) Možnost manipulovat s daty ve vzdálené databázi pomocí tohoto linku –UPDATE SET … –INSERT ITNO VALUES( …) –DELETE FROM WHERE …

Administrace RD78 Replikace dat Jak replikovat (možnosti) –S využitím replikačních možností, implementovaných Oracle Serverem Standardní využití pro poskytnutí přístupu ke stejným datům na více místech (lokálně) –Snížení zátěže jednotlivých serverů –Změny aplikované na jednu repliku jsou (mohou být) následně aplikovány na ostatní kopie

Administrace RD79 Replikace dat Replikace Oracle umožňuje replikovat: –Tabulky (pro účely RD nejpodstatnější) –Indexy –Balíky –Pohledy –Triggery –Synonyma

Administrace RD80 Replikace dat Replikované objekty jsou sdružené do replikačních skupin –Je jednodušší spravovat více objektů najednou Tří skupiny –RG_CIS (číselníky) –RG_PROD (produkty) –RG_REPO (repozitoř)

Administrace RD81 Replikace dat Oracle podporuje 2 základní typy kopií dat: –master – obsahuje úplnou kopii všech objektů replikační skupiny (master group). –snapshot – obsahuje kopie dat z propojené master kopie. Může obsahovat všechny, nebo jen podmnožinu objektů z replikační skupiny (snapshost group).

Administrace RD82 Replikace dat Je podporována i tzv. multimaster replikace, která povoluje více rovnoprávných kopií –Aplikace mohou aktualizovat jakoukoliv replikovanou tabulku ve kterékoliv kopii. –Zajištěna je konzistence globálních transakcí a integrita dat. –Pro účely RD komplikované, replikace dat z DMZ do Intranetu dokonce nežádoucí

Administrace RD83 Replikace dat Jednodušší je tzv. snapshot replikace, která replikuje změny v master kopii do všech snapshot kopií –V nastavených časových intervalech –Ihned na základě asynchronního požadavku administrátora –Spojení se provádí z DMZ do Intranetu Tabulka Link Mat view Mat. view log

Administrace RD84 Produkty XML L0L1 Číselníky Repozitoř L2 Produkty Číselníky Repozitoř Správce Uživatelé Jednosměrná replikace

Role a oprávnění

Administrace RD86 Správa uživatel Smluvní uživatelé RD mají své vlastní účty –V replice dat v DMZ –Ne v primární databázi –Práce s daty, vlastněnými někým jiným Pouze taková práva, jaká jim vlastník přidělil Ochrana před (ne)úmyslnou chybou aplikace Ochrana před změnou struktury dat (ALTER)

Administrace RD87 Správa uživatel Ke každému profilu uživatele existuje odpovídající role Tuto roli má smluvní uživatel přidělenu příkazem GRANT Role obsahuje právě všechna práva, nezbytná pro získání povolených údajů

Administrace RD88 Správa uživatel Uživatel ANONYM Role RD_PUBLIC Role RD_JmProfilu RD_PUBLIC RD_VLASTNIRD_VSECHNO ANONYMFNKVFNMOTOLMZCR

Administrace RD89 Správa uživatel Tím, že má každý uživatel přidělenu roli odpovídající jeho profilu –Se zjednodušuje správa uživatel –Všechna potřebná oprávnění uživatel získá najednou Role samy o sobě nestačí na –Situace, kdy různí uživatelé mají mít přístup k různým řádkům téže tabulky

Virtuální privátní DB

Administrace RD91 Virtuální privátní databáze Na rolích nezávislé definování přístupu k řádkům a sloupcům tabulek a pohledů Umožňuje jemněji určovat přístup k datům Omezení přístupu k řádkům –Na základě přidělené politiky lze každý dotaz nad danou tabulkou automaticky přeformulovat – doplnit o WHERE podmínku, která z dotazu odstraní nežádoucí řádky

Administrace RD92 Virtuální privátní databáze Produkty SELECT * FROM Produkty SELECT * FROM Produkty SELECT * FROM Produkty WHERE ZZ=‘FNMOTOL’ SELECT * FROM Produkty WHERE Kraj=‘PRAHA’

Audit DB

Administrace RD94 Audit DB Proč provádět Audit? –odrazení uživatelů od nevhodných akcí –zjištění zodpovědnosti za podezřelé akce –prověření podezřelých aktivit –upozornění na neautorizované akce –sledování aktivit v databázi

Administrace RD95 Audit DB Co auditovat? –SQL dotazy Nesnaží se někdo přistupovat k datům, pro které nemá oprávnění? –Oprávnění –Jednotlivé tabulky –Aktivitu v síti –Jemnozrnné auditování (FGA)

Administrace RD96 Audit DB Na co dát pozor? –Auditování DB představuje jistou režii v zátěži serveru Nutno volit kompromis mezi rozsahem akcí, které chceme hlídat a zpomalením, které tím způsobíme Standardně hlídat jen základní aspekty (existují pokusy o neoprávněné přístupy k datům?) Nebo nic. Teprve v případě podezření zvýšit detailnost kontroly

Administrace RD97 Audit DB [NO]AUDIT objekt [BY {SESSION|ACCESS}] [WHENEVER [NOT] SUCCESSFUL] AUDIT SELECT TABLE, INSERT TABLE, DELETE TABLE, EXECUTE PROCEDURE BY ACCESS WHENEVER NOT SUCCESSFUL;

Administrace RD98 Audit DB Kde hledat výsledky? –Tabulka SYS.AUD$ –Pohledy DBA_AUDIT_TRAIL, DBA_COMMON_AUDIT_TRAIL Pozn: Pokud je audit DB zapnut, vždy se auditují –Připojení k DB s admin. Právy –Startup a Shutdown databáze

Administrace RD99 Audit DB Jak zapnout podporu auditu v DB? –Nastavením inicializačního parametru AUDIT_TRAIL DB OS XML NONE

Administrace RD100 Jemnozrnný audit DB Pomocí balíku DBMS_FGA –BEGIN DBMS FGA.ADD_POLICY( object_schema => 'MZDRG', object_name => ‘MF_REPOZITOR', policy_name => 'chk mzdrg repo', audit_condition => 'name like ''DRG%''', audit_column => NULL, handler_schema => NULL, handler_module => NULL, enable => TRUE, statement_types => 'SELECT, DELETE', audit_trail => DBMS FGA.DB); END;

Oracle Scheduler

Administrace RD102 Scheduler Využívá se pro vykonávání asynchronních operací v RD –Nahrání souboru do úrovně L1 (L2) ve stanovené době Nezatěžuje se server ve špičkách Správce nemusí čekat na zpracování všech importovaných údajů

Administrace RD103 Scheduler Nutné zajistit spouštění JOBů –O to se starají samostatně běžící procesy –Pokud nejsou spuštěny, JOB nebude proveden Nutné kontrolovat, zda nedošlo k zablokování JOBu. –Pokud se systém pokusí JOB opakovaně neúspěšně spustit, označí jej jako poškozený a jeho spouštění se zablokuje

XML

Administrace RD105 XML RD využívá nativní schopnost serveru ukládat, zpracovávat a prohledávat XML dokumenty –Každý validní XML dokument je v DB uchováván v nezměněné podobě v tabulce MF_L0_XMLFILE Pokud dojde ke změně pravidel pro nahrávání, mohou být všechna data do dalších úrovní znovu nahrána z těchto dat

Administrace RD106 XML Data jsou následně zpracována pomocí XML dotazů uvnitř serveru a v relační podobě nahrána do úrovně L1 Oracle podporuje ukládat –libovolné XML dokumenty do sloupců s typem XMLType –XML dokumenty, vyhovující danému XML schematu

Administrace RD107 XML Registrace nového XML Schema –dbms_xmlschema.registerSchema( ' getDocument('import.xsd'), TRUE, TRUE, FALSE, FALSE ); –Sloupec je možné spojit s tímto schematem pomocí klauzule XMLSCHEMA " ELEMENT "import"

Administrace RD108 XML Používá se volný dokument bez uvedení XML Schema –Validace oproti XML Schema lze snadno provést mimo databázi –V databázi bude nutné ukládat XML data s různými verzemi schématu tak, jak se bude formát vyvíjet

Zálohování a obnova dat

Administrace RD110 Zálohování a obnova Proč zálohovat –Ochrana před ztrátou nebo poškozením dat uživatelskou chybou selháním klientské aplikace selháním instance DB aplikace selháním disku …

Administrace RD111 Zálohování a obnova Prevence ztráty dat HW chybou –Oracle instance může běžet ve více režimech NOARCHIVELOG MODE –Žurnálové (redo-log) soubory se nezálohují –Existuje jen několik posledních instancí »Stačí na opravu DB po výpadku proudu –Dovoluje pouze offline zálohování ARCHIVELOG MODE –Zálohování všech vytvořených redo-log žurnálů –V případě chyby je možné data restaurovat do stavu, v jakém byly okamžik před havárií –Je možné zálohovat online databázi a rekonstruovat samostatně tabulkové prostory a/nebo soubory

Administrace RD112 Zálohování a obnova STARTUP RECOVER ALTER TABLESPACE {BEGIN|END} BACKUP

Administrace RD113 Zálohování a obnova Pravidelné zálohování dat na BACKUP server –RMAN – nástroj pro zálohování a obnovu CLI i GUI rozhraní –Možné a doporučené nastavit JOB pro CRON v OS serveru, využívající CLI rozhraní

Administrace RD114 Zálohování a obnova Informace o zálohách se udržují v samostatné repozitoři (katalogu) Inkrementální zálohování po blocích, což urychluje proces zálohování a šetří místo na discích Udržuje sám přehled o existujících zálohách souborů

Administrace RD115 Zálohování a obnova Je možné udržovat samostatnou databázi s informacemi o zálohách Nyní se tyto informace udržují přímo v řídících souborech RD

Administrace RD116 Zálohování a obnova Typy záloh –FULL (kompletní DB) –INCREMENTAL (pouze změněná data) Offline záloha –$ rman –RMAN> connect target –RMAN> Shutdown immediate; –RMAN> Startup mount; –RMAN> Backup database; –RMAN> Alter database open;

Administrace RD117 Zálohování a obnova Obnova –$ rman –RMAN> connect target –RMAN> restore database;

Administrace RD118 Zálohování a obnova Inkrementální záloha –$ rman –RMAN> connect target –RMAN> backup incremental level 0 tag = tydne database; –$ rman –RMAN> connect target –RMAN> backup incremental level 1 for recover of copy with tag tydne database;

Administrace RD119 Zálohování a obnova Inkrementální obnova –$ rman –RMAN> connect target –RMAN> recover copy of database with tag tydne; Rychlejší inkrementální záloha pomocí sledování změn bloků –SQL> alter database enable block change tracking using file ’jmeno_souboru_pro_sledovani_zmen’;