SMLOUVA
SMLOUVA
o dodávce integrovaného databázového systému
uzavřená podle § 1746 odst. 2 zákona č. 89/2012 Sb., občanský zákoník,
mezi:
Českou národní bankou
Na Příkopě 28
115 03 Praha 1
zastoupenou: Ing. Xxxxxxxxxx Xxxxxxxxx, ředitelem sekce informatiky
a
Xxx. Xxxxxxx Xxxxxxxx, ředitelem sekce správní
IČO: 48136450 DIČ: CZ48136450
(dále jen „objednatel“).
a
Neit Consulting s.r.o. Washingtonova 1624/5 110 00 Praha 1
zástoupenou: Xxx. Xxxxxx Xxxxxx, jednatelem
IČO: 27369871
DIČ: CZ27369871
zapsán v obchodním rejstříku vedeném Městským soudem v Praze oddíl C, vložka 108964 (dále jen „zhotovitel“)
Preambule
Objednatel provozuje své klíčové databázově orientované informační systémy na platformě produktů společnosti Oracle. Provoz databází koncepčně směřuje od distribuovaného modelu (tj. řada fyzických či virtuálních serverů připojená k zrcadleným centrálním diskovým polím prostřednictvím sítě SAN („Storage Area Network“) k plně centralizovanému integrovanému systému, který umožní zvýšit efektivitu provozu Oracle databází z hlediska výkonnosti, bezpečnosti a nároků na jejich správu.
Objednatel očekává, že nabízený „Integrovaný Databázový Systém“ („IDS“) bude provozně spolehlivý a optimalizovaný pro provoz a správu Oracle databází a jeho průběžný rozvoj včetně na něm provozovaných programových prostředků (např. patchování, upgrade na podporované verze operačního systému a databází Oracle) bude realizovatelný v dlouhodobé perspektivě (minimálně po dobu 5 let).
IDS bude standardní, na trhu dostupné a dodávané zařízení/systém včetně služby jeho provozní podpory, nebude se jednat o specializované zařízení/systém vytvořené jednorázově pouze pro potřeby objednatele.
Vzhledem k zásadní důležitosti předmětného IDS pro provoz informačních systémů objednatele, stanovuje objednatel dále uvedené požadavky, lhůty, platební podmínky, smluvní pokuty a další smluvní ujednání, které z této důležitosti pro objednatele vycházejí.
I
Předmět plnění
1. Zhotovitel se zavazuje dodat a implementovat IDS, vypracovat dokumentaci skutečného stavu implementace IDS a zaškolit zaměstnance objednatele. IDS bude realizováno ve formě dvou vzájemně se zálohujících instalací implementovaných ve dvou geograficky vzdálených výpočetních centrech objednatele (článek II odst. 2). Dodávka IDS a jeho implementace bude realizována v souladu s přílohou č. 1 a dále musí splňovat funkční požadavky objednatele uvedené v příloze č 2. Implementace IDS musí být realizována také v souladu s návrhem technického řešení obsaženým v nabídce zhotovitele z realizovaného zadávacího řízení (příloha č. 8). Zaškoleni budou odborní zaměstnanci objednatele, kteří budou zajišťovat podporu provozu a administraci dodaného IDS.
2. Součástí plnění dle odstavce 1 je dodání administrátorské a uživatelské dokumentace výrobce IDS a dokumentace na IDS instalovaných programových prostředků.
3. Plnění podle odst. 1 a 2 bude realizováno v níže definovaných etapách, které budou
předmětem akceptace podle článku III a zahrnují:
1. etapa: Základní instalace IDS v instalačních lokalitách ČNB
První etapa bude sestávat z následujících činností (týká se obou instalačních lokalit a činnosti zabezpečuje zhotovitel v místě plnění (ne vzdáleně), není-li stanoveno jinak):
a. dodávka technických prostředků IDS (rack/y, servery/výpočetní jednotky, diskové kapacity, komponenty pro interní komunikační propojení komponent IDS včetně propojovací kabeláže a komunikační interface pro externí komunikaci IDS prostřednictvím LAN (datová, management/monitoring) atd.) v souladu se specifikací uvedenou v příloze č. 1 a za dodržení instalačních podmínek - viz příloha č. 6,
b. fyzická instalace a sestavení racku/ů pro IDS včetně jejich napojení do zálohované elektrické sítě. V instalační lokalitě 1 bude kromě instalace a sestavení racku provedeno jeho napojení do chladicího systému (teplá/studená ulička) včetně zatěsnění, kde objednatel zajistí potřebnou součinnost – viz též příloha č. 6, c. fyzická instalace výpočetních a diskových kapacit IDS do racků včetně jejich vzájemného interního komunikačního propojení,
d. konfigurace vnějšího komunikačního propojení IDS do LAN objednatele (datové propojení, propojení pro management a monitoring atd.), konfigurace firmware/BIOS, instalovaných diskových kapacit a interního komunikačního propojení IDS pro potřeby instalace programového vybavení IDS a databáze Oracle,
e. instalace a konfigurace programových prostředků IDS, tj. zejména operační systém, aplikačního software IDS, software pro administraci a monitoring IDS atd.,
f. instalace databázového software Oracle 12c v zhotovitelem podporované verzi s
aktuálním Patch Set Update („PSU“) - základní instalace HOME,
g. vytvoření prvotní prázdné databáze s optimálním nastavením pro maximalizaci výkonu IDS,
po realizaci výše uvedené prvotní instalace a zprovoznění IDS bude pracovníky
objednatele proveden výkonnostní test dle přílohy č. 3 za účelem ověření, že nabízené
IDS dosahuje výkonnosti, kterou zhotovitel deklaroval ve své nabídce v rámci zadávacího řízení a která je uvedena v čl. I odst. 8,
h. provedení testů výkonnosti dle přílohy č. 3.
2. etapa: Dokončení instalace IDS a migrace 3 vybraných databází objednatele do IDS
V případě úspěšné akceptace první etapy bude v této etapě dokončena instalace a konfigurace technických a programových prostředků IDS a provedena vzorová migrace vybraných databází objednatele. Tato etapa se bude sestávat z následujících kroků (týká se obou instalačních lokalit a činnosti zabezpečuje zhotovitel v místě plnění (ne vzdáleně), není-li stanoveno jinak):
a. dokončení instalace operačního systému a aplikace jeho extenzí/rozšíření -
napojení IDS na interní systémy objednatele:
i. zálohovací subsystém,
ii. zdroj přesného času,
iii. SIEM,
iv. HSM modul,
b. doplnění instalace databází – základní instalace HOME pro následující verzi databáze: 11.2.0.4 s aktuálním PSU,
c. instalace aplikačního programového vybavení zajišťující High Availability funkce (bezvýpadkovost) pro IDS na úrovni operačního systému a databáze Oracle,
d. aktivace dalších funkcí IDS:
i. vzdálené zrcadlení dat mezi databázemi Oracle instalovanými v IDS v obou instalačních lokalitách,
ii. aplikace pravidel resource managementu,
iii. aktivace a konfigurace konfiguračních nástrojů IDS pro potřeby technické
podpory pracovníků objednatele,
e. aktivace monitoringu a dohled funkčnosti IDS:
i. lokálně, tj. informace z monitorovacího systému (technické prostředky IDS, operační systém, databáze) budou dostupné pracovníkům objednatele DBA („DataBase Administrator“) v rámci jejich management konzole,
ii. vzdáleně, tj. informace z monitorovacího systému (technické prostředky IDS) budou systémem odesílány do vzdáleného centra podpory zhotovitele,
f. posledním krokem je zajištění migrace (asistence a supervize zhotovitele pro DBA objednatele při migraci vybraných databází a případné řešení vzniklých problémů) 3 definovaných databází objednatele do IDS se zohledněním minimalizace odstávek a případných specifik jednotlivých databází. V rámci této migrace není řešena kompatibilita kódu aplikací v migrovaných databázích s prostředím databáze instalované na IDS. Jedná se o vlastní proces migrace a nastavení provozní konfigurace migrovaných databází a systému řízení zdrojů
(resource management) pro jejich správný provoz v IDS. V rámci migrace musí být dodrženy licenční podmínky společnosti Oracle. Budou migrovány:
i. 1x stávající databáze ve verzi Oracle Enterprise Edition („EE“) ->
prostředí EE v IDS,
ii. 1x stávající databáze ve verzi Oracle Standard Edition („SE“) -> prostředí
EE v IDS,
iii. 1x databáze SE provozovaná v prostředí Linux RedHat s interakcí do OS (např. Java, HSM modul apod.) -> prostředí EE v IDS), což zejména zahrnuje:
1. návrh postupu převodu těchto databází do nového prostředí,
2. provedení migrace na IDS v jedné instalační lokalitě,
3. nastavení replikací dat těchto databází na IDS v druhé instalační lokalitě,
4. nastavení pravidel řízení zdrojů pro migrované databáze,
vlastní migrační kroky v rámci akcí dle tohoto písmena f. realizují zaměstnanci
objednatele dle navrženého postupu zhotovitele a pod jeho supervizí,
g. vypracování či kompletace dokumentace v českém případně anglickém jazyce u technických materiálů, na Internetu obecně dostupných manuálů či schémat atd., jejichž seznam je uveden níže:
i. zpracování popisu finálního stavu implementovaného IDS, který musí obsahovat všechny nezbytné informace pro instalaci technických a programových prostředků nad rámec jejich defaultního nastavení a pro migraci databází (skutečný stav zapojení, nastavení IDS, postupů při provozu, nastavení vzdáleného přístupu, nastavení účtů či bezpečnostních opatření atd.).
ii. základní dokumentace dodávaná výrobcem IDS (typicky např. Admin Guide, Implementation Guide, Licensing Guide apod.),
iii. zápisy z jednání a protokolů o implementaci, nastavení a předání funkčních celků IDS objednateli,
iv. zpracování zápisů/protokolů o zaškolení obsluhy IDS,
v. dokumentace pro podporu provozu IDS, není-li již obsažena výše:
1. postupy pro vypnutí/zapnutí IDS pro případ řízeného odstavení, tj. popis postupu řízeného vypnutí lokality tak, aby byl zajištěn provoz ve druhé instalační lokalitě.
2. havarijní postupy pro případ výpadku některých komponent dodaného IDS (obvyklé/očekávané závady), tj. popis pro administrátory IDS, co mají zajistit v případě výpadku některé z komponent na jednom z IDS (troubleshooting),
3. doporučené provozní postupy, tj. doporučení pro administrátory, jaké činnosti/kontroly by měly provádět rutinně denně/týdně/měsíčně na implementovaném IDS. Popis postupu komunikace s externí podporou IDS /zhotovitelem, tj.
komu/kdy/jak hlásit provozní závady (nesmí být v rozporu s čl. VI smlouvy a přílohou č. 4 smlouvy);
vi. popis vzdáleného monitoringu (health-check IDS), způsob zabezpečení
komunikace, eskalační a monitorovací procedury,
vii. základní popis procesů a cyklů patchování (upgrade, update), tj. uvedení standardní frekvence, proces jejich aplikace s rozdělením odpovědností (co zajišťuje objednatel, co zhotovitel, výrobce IDS aj.).
4. Během první i druhé etapy bude prováděno průběžně zaškolení maximálně 6 odborných zaměstnanců objednatele (4x role DBA, 2x vývojář databázových („DB“) aplikací) v délce, kterou určí zhotovitel tak, aby vyškolení zaměstnanci objednatele byli schopni zajišťovat běžný provoz a údržbu včetně konfigurace dodaných technických a programových prostředků IDS a při návrhu databázových aplikací využívat specifické funkce a vlastnosti IDS. Kromě dedikovaných školení s lektory/odbornými pracovníky zhotovitele lze za zaškolení považovat i účast pracovníků objednatele při implementaci IDS v ČNB, kdy pracovníci zhotovitele budou popisovat realizované kroky a předávat ústně příslušné know- how pracovníkům objednatele.
a) Skupina administrátorů DBA nemůže být z provozních důvodů školena najednou, školení
bude probíhat po dvojicích.
b) Školení je preferováno realizovat v prostorech objednatele. Může být realizováno i v prostorách připravených zhotovitelem mimo prostory objednatele, musí však být realizováno v lokalitě Praha v dosahu MHD.
c) Školícím jazykem může být čeština a angličtina. Preferován je český jazyk.
d) Zhotovitel zajistí případné potřebné školící materiály (český nebo anglický jazyk).
5. Během první a druhé etapy bude probíhat průběžná dodávka a aktivace potřebných licencí (software, služby, aktivace služeb či komponent IDS atd.) v závislosti na postupu implementace IDS v prostředí objednatele. Zhotovitel zodpovídá za to, že provoz programového vybavení instalovaného na implementovaných IDS je v těchto fázích v souladu s licenčními podmínkami použitého software či služeb.
6. Činnosti uvedené v odst. 3 tohoto článku se realizují v pracovní dny během standardní pracovní doby objednatele (7:45-16:15 - časové pásmo místa plnění), pokud se objednatel a zhotovitel nedohodnou jinak.
7. Zhotovitel se dále zavazuje poskytovat podporu pro dodané technické a programové prostředky v rozsahu podle článku VI. Podporu dodaných licencí databáze Oracle a dalších jejích Options v souvislosti s implementací a provozem IDS si bude zajišťovat objednatel.
8.Zhotovitel prohlašuje, že IDS dodané dle této smlouvy dosahuje výkonnost nejméně 390339.
9. Objednatel se zavazuje za poskytnuté plnění uhradit cenu dle čl. IV.
II
Lhůty a místa plnění
1. Smluvní strany se dohodly, že zhotovitel předá plnění dle čl. I odst. 1 a 2 nejpozději do 16 týdnů ode dne podpisu této smlouvy. První etapa plnění musí být dokončena a předána k akceptaci nejpozději do 12 týdnů ode dne podpisu smlouvy.
2. Místem plnění budou prostory výpočetního střediska v objektech objednatele:
• lokalita č. 1: Na Příkopě 28, 115 03 Praha 1;
• lokalita č. 2: pracoviště ČNB, Strojírenská 175, 155 21 Praha 5.
3. Poskytování provozní podpory IDS zahájí zhotovitel pracovní den následující po podpisu závěrečného akceptačního protokolu.
4. Objednatel se zavazuje umožnit zhotoviteli vykládku a úschovu prostředků IDS (viz článek I odst. 3, 1. etapa, písmeno a) v prostorách objednatele určených k instalaci v termínu, o kterém byl zhotovitelem zpraven nejméně tři pracovní dny předem. Objednatel převezme prostředky do úschovy a zajistí jejich bezpečné uskladnění do zahájení instalace.
5. Objednatel poskytne zhotoviteli potřebnou součinnost do dvou pracovních dnů následujících po doručení výzvy zhotovitele.
6. Objednatel prohlašuje, že:
• do konce roku 2017 má předplacenou podporu licencí společnosti Oracle pro objednatelem nyní provozované databáze Oracle,
• migraci zbývajících Oracle databází objednatele z distribuovaného modelu do nových IDS nad rámec dohodnutý v článku I odst. 3, 2. etapa, písm. f., provede bez zbytečného odkladu objednatel po finální akceptaci předmětu plnění, nejdéle však do 12 měsíců.
7. Zhotovitel prohlašuje, že technické prostředky IDS budou nové a nepoužité - nepočítají se výrobní procesy jako např. testy funkčnosti, nebo ověření funkčnosti v rámci případné kompletace IDS výrobcem či zhotovitelem před jejich dodáním.
III
Akceptace
1. Zhotovitel umožní objednateli kontrolovat průběh implementace IDS a za tím účelem
poskytne objednateli potřebnou součinnost.
2. Akceptační řízení bude prováděno pro každou etapu uvedenou ve článku II odst. 3, a to
podle přílohy č. 3 smlouvy.
3. Zhotovitel je oprávněn zahájit další etapu až poté, co objednatel akceptoval předchozí
etapu.
4. Plnění dle čl. I odstavců 1 až 5 této smlouvy bude předáno a převzato na základě závěrečného akceptačního protokolu, který podepíší pověřené osoby obou smluvních stran pokud:
a) IDS byl implementován v souladu s přílohami 1, 2 a 8 této smlouvy,
b) byly splněny podmínky akceptace dle přílohy č. 3,
c) zhotovitel dodal aktuální požadovanou dokumentaci – viz článek I odst. 3, 2. etapa, písm.
g.,
d) zhotovitel poskytl veškeré potřebné licence pro správný a bezproblémový provoz IDS, poskytl příslušný počet licencí pro databáze Oracle a jejich Options. Poskytnuté licence odpovídají licenčním ujednáním dle čl. XI.
5. Zhotovitel garantuje, že:
a) dodaný a implementovaný IDS je schopen rutinního provozu ve standardním systémovém prostředí objednatele (viz příloha č. 7), a to i za pravidelného nasazování aktualizací (update/upgrade/patch/hotfix) komponent systémového prostředí objednatele,
b) dodaný a implementovaný IDS je funkční dle předané dokumentace,
c) vzdálený monitoring IDS je správně zabezpečen,
d) IDS bude podporovaný a provozuschopný včetně jeho průběžného rozvoje min. po dobu 5 let.
IV
Cena plnění a platební podmínky
1. Cena plnění podle čl. I odst. 1 a 2 činí bez DPH celkem 38 775 732,86 Kč. Z toho činí cena školení bez DPH 200 000Kč. Specifikace ceny díla je obsažena v příloze č. 9.
2. Na cenu plnění dle odst. 1 tohoto článku poskytne objednatel zhotoviteli zálohu ve výši 50 % z ceny dle odst. 1, a to na základě zálohové faktury, kterou je zhotovitel oprávněn vystavit nejdříve v den podpisu akceptačního protokolu první etapy plnění.
3. Paušální cena za podporu ode dne zahájení poskytování podpory do 31. 12. 2017 činí měsíčně bez DPH:
a) technických prostředků IDS: 131 862,67 Kč,
b) programových prostředků IDS: 314 164,84 Kč.
4. Paušální cena za podporu od 1. 1. 2018 do 31. 12. 2018 činí měsíčně bez DPH:
a) technických prostředků IDS:131 862,67 Kč,
b) programových prostředků IDS: 314 164,84 Kč.
5. Paušální cena za podporu od 1. 1. 2019 do 31. 12. 2019 činí měsíčně bez DPH:
a) technických prostředků IDS: 131 862,67Kč,
b) programových prostředků IDS: 314 164,84 Kč.
6. Paušální cena za podporu od 1. 1. 2020 do 31. 12. 2020 činí měsíčně bez DPH:
a) technických prostředků IDS: 131 862,67 Kč,
b) programových prostředků IDS: 323 274,79 Kč.
7. Paušální cena za podporu od 1. 1. 2021 a dále činí měsíčně bez DPH:
a) technických prostředků IDS: 135 739,48 Kč,
b) programových prostředků IDS: 330 813,90 Kč.
8. Cena plnění podle odst. 1 tohoto článku bude uhrazena na základě daňového dokladu, ve kterém bude odečtena poskytnutá záloha a který je zhotovitel oprávněn vystavit nejdříve v den podpisu závěrečného akceptačního protokolu.
9. Paušální ceny podle odst. 3 až 7 budou hrazeny měsíčně na základě jednoho daňového dokladu vystaveného nejdříve ke dni uskutečnění zdanitelného plnění, kterým je poslední den kalendářního měsíce, za který se platí.
10. Výše paušální ceny podpory za období kratší, než je sjednané období, se vypočte jako
alikvotní část sjednané ceny.
11. K cenám bude účtována DPH v sazbě platné v den uskutečnění příslušného zdanitelného plnění.
12. Ceny plnění uvedené v odst. 1 až 7 tohoto článku zahrnují veškeré náklady zhotovitele
spojené s plněním podle této smlouvy.
13. Doklady k úhradě musí obsahovat údaje dle § 435 občanského zákoníku a evidenční číslo
smlouvy objednatele. Daňový doklad musí nadto obsahovat náležitosti stanovené zákonem
o DPH. Nebude-li doklad obsahovat uvedené náležitosti nebo bude-li obsahovat nesprávné údaje, je objednatel oprávněn doklad zhotoviteli vrátit, a to až do konce lhůty splatnosti. Nová lhůta splatnosti začne běžet dnem doručení bezvadného dokladu objednateli.
14. Doklady bude zhotovitel zasílat elektronicky na adresu xxxxxxx@xxx.xx, přičemž doklad musí být vložen jako příloha mailové zprávy ve formátu PDF. V jedné mailové zprávě smí být pouze jeden doklad. Mimo vlastní doklad může být přílohou mailové zprávy jedna až tři přílohy k dokladu ve formátech PDF, DOC, DOCX, XLS, XLSX. Nebude-li možné zaslat doklad k úhradě elektronicky, zašle zhotovitel doklad na adresu:
Česká národní banka
sekce rozpočtu a účetnictví odbor účetnictví
Na Příkopě 28
115 03 Praha 1
15. Splatnost dokladů je 14 dnů ode dne jejich doručení objednateli. Povinnost zaplatit je
splněna odepsáním příslušné částky z účtu objednatele ve prospěch účtu zhotovitele.
16. Ke konci kalendářního roku, nejdéle však do 31. 12., je zhotovitel povinen sdělit prostřednictvím e-mailu pověřené osobě objednatele buď, jakou část z uhrazené ceny za podporu programových prostředků v daném kalendářním roce tvoří cena nových verzí představujících jejich technické zhodnocení nebo že k technickému zhodnocení nedošlo.
17. Smluvní strany se dohodly, že objednatel je oprávněn započíst jakoukoli svou peněžitou pohledávku za zhotovitelem, ať splatnou či nesplatnou, oproti jakékoli peněžité pohledávce zhotovitele za objednatelem, ať splatné či nesplatné.
V
Součinnost, pověření zaměstnanci
1. Objednatel se zavazuje vytvořit zhotoviteli k plnění potřebné podmínky, zejména:
a) zajistit krátkodobé provozní odstávky informačních systémů dotčených migrací databází v rámci 2. etapy plnění (maximálně 1 hodina v pracovní dny v běžné pracovní době během jednoho kalendářního týdne). Delší odstávky je možné provádět jen během víkendu. Takovou odstávku je nutné avizovat nejméně 10 pracovních dnů dopředu;
b) poskytnout k nahlédnutí zhotoviteli orientační plán stávajícího propojení instalačních lokalit, případně používaných konvencí pro tvorbu jejich označování, používané konvence pro označování LAN, síťových hostnamů atd.;
c) umožnit prohlídky všech míst plnění s ohledem na fyzické umístění dodávaných technických prostředků IDS;
d) zajistit potřebné rekonfigurace všech technických a programových systémů dotčených přechodem na dodávané IDS (zálohování, SIEM, HSM);
e) přidělit IP adresy pro dodávané prostředky IDS, pro potřeby managementu IDS a migrovaných databází informačních systémů;
f) zajistit přístup odborných pracovníků zhotovitele na příslušná pracoviště objednatele;
g) v případě požadavku na 3- fázové napájení zajistit potřebné změny v silnoproudých rozvaděčích v místech instalace na své náklady.
2. Pověřenými pracovníky pro technická jednání a k předání a převzetí plnění jsou:
- za objednatele: Xxxxx Xxxxxxx, Xxxxx Xxxx, Xxxxxxxx Xxxxxxxx
- za zhotovitele: Xxxx Xxxxx Xxxxx
3. Pověřenými pracovníky pro jednání ohledně změn této smlouvy jsou:
- za objednatele: Xxxxx Xxxxxxx, Xxxxx Xxxx
- za zhotovitele: Xxx. Xxxxxx Xxxxxx.
VI
Provozní podpora
1. Provozní podpora bude poskytována v obou instalačních lokalitách.
2. Podmínky pro provozní podporu:
a) pro uskutečnění servisního zásahu odborných pracovníků zhotovitele v případě detekce
vady na technických či programových prostředcích IDS platí následující režim:
i. pro uskutečnění servisního zásahu odborných pracovníků zhotovitele v případě programových či technických prostředků IDS platí nepřetržitý režim, tj. pracovníci zhotovitele budou k dispozici po dobu 24 hodin a 7 dnů v týdnu,
ii. kontaktní osoby objednatele i zhotovitele včetně popisu procesu a výčtu použitých nástrojů pro hlášení závad jsou uvedeny v příloze č. 4,
iii. údržbu LAN či technických ochranných prostředků na perimetru objednatele
zajišťuje objednatel, a proto řešení závad v této komponentě zhotovitel nezajišťuje.
b) odstraňování kritických závad IDS:
Za kritickou závadu se považuje taková závada, která znemožňuje přístup k datům databází Oracle provozovaných na IDS, ať už v jedné nebo i v druhé instalační lokalitě. Mezi kritické závady dále patří také:
• přerušení vzdáleného zrcadlení mezi IDS v jednotlivých instalačních lokalitách;
které není způsobené na komunikační trase zajišťované objednatelem;
• zásadní výkonnostní problémy IDS – zpomalení zpracování databází;
• nefunkčnost software pro řízení a monitoring IDS;
• výpadek neredundantní části IDS nebo selhání redundance;
• detekce narušení konzistence /integrity dat zpracovávaných v databázích na IDS.
Odstranění kritických závad musí být zahájeno do 2 hodin od jejich nahlášení a na jejím odstranění musí zhotovitel pracovat bez zbytečného odkladu a přerušení a musí využít všech prostředků k dosažení nápravy. Nebude-li závada vyřešena do 4 hodin od jejího nahlášení, je zhotovitel povinen oznámit požadavek na řešení závady do supportních středisek výrobce IDS, a to nejpozději do 5 hodin od nahlášení závady
c) odstraňování nekritických závad IDS:
Za nekritickou závadu se považuje taková závada dodaných technických či programových prostředků IDS, která neohrožuje vlastní provoz těchto prostředků, například výpadek první z redundantních komponent (výpočetní či úložné kapacity, interní komunikační komponenty IDS).
Při vzniku nekritické závady IDS bude zahájeno řešení závady nejpozději do 4 hodin po jejím ohlášení zhotoviteli. Na jejím odstranění musí zhotovitel pracovat bez neodůvodněného přerušení a musí využít všech prostředků k dosažení nápravy.
3. O klasifikaci nahlášených vad (kritické/nekritické) rozhodují pracovníci objednatele (DBA).
4. Detekované závady mohou být dočasně vyřešeny nebo jejich důsledky mohou být potlačeny také například pomocí dočasného řešení – workaround. Pracovníci objednatele (DBA) rozhodují, zda workaround splňuje požadavek na dočasné vyřešení či potlačení důsledků závady umožňující další provoz IDS.
• Akceptovaný workaround splňuje závazek zhotovitele opravit nahlášenou závadu.
• Bez ohledu na akceptovaný workaround pokračuje zhotovitel v procesu nalezení systémového řešení trvale odstraňující / opravující nahlášenou závadu.
5. Požadavky na odstranění závad a na ostatní služby podle této smlouvy budou předávány písemně, a to na kontaktní e-mail zhotovitele. Kontaktní místo pro nahlášení závady musí být dostupné 24 hodin denně 7 dnů v týdnu. Kritické závady objednatel současně oznámí telefonicky na telefonní číslo zhotovitele. Přijetí požadavku je zhotovitel povinen potvrdit na kontakt objednatele nejpozději do 2 hodin od přijetí požadavku. Kontaktní e-mail, telefon a kontaktní osoby zhotovitele a objednatele jsou uvedeny v příloze č. 4.
6. Součástí podpory technických prostředků je i zajištění zabezpečeného lokálního/vzdáleného
dohledu.
7. Součástí podpory IDS je i zajištění pravidelného cyklu patch managementu v souladu s požadavky objednatele uvedenými v příloze č. 2.
8. Zhotovitel v rámci zajištění podpory zajistí náhradní díly, nové a opravné verze mikrokódu/firmware dodaných technických prostředků IDS a nové a opravné verze dodaných programových prostředků IDS včetně jejich implementace v cyklech a rozsahu dle doporučení jejich výrobce. Součástí podpory je také informování objednatele o vydání nových nebo opravných verzích a konzultace k těmto verzím.
9. Pokud závadu zjistí zhotovitel (např. prostřednictvím monitorovacího systému), oznámí ji neprodleně objednateli a další postup se řídí ustanoveními tohoto článku.
10. Zhotovitel je srozuměn s tím, že veškerá komunikace při hlášení a řešení závad bude mezi objednatelem a technickými pracovníky zhotovitele probíhat v českém nebo anglickém jazyce.
11. Služby poskytované zhotovitelem musí vyhovovat technickým a softwarovým specifikacím a požadavkům výrobce příslušného IDS.
12. Xxxxxxxxxx je povinen poskytovat podporu pro dodané technické a programové prostředky IDS pouze pracovníky, kteří mají příslušné certifikované školení. Xxxxxxxxxx je povinen toto na vyžádání objednatele doložit, a to nejpozději do 10 pracovních dnů.
13. Xxxxxxxxxx se zavazuje převzít od objednatele vyměněné vadné díly IDS.
14. Xxxxxxxxxx souhlasí s tím, že při výměně vadného disku či média pro uchovávání dat budou
na vadném disku či médiu smazána data tzv. degausserem (označováno též jako
„magnetická pec“). Smazání dat na disku zajišťují zaměstnanci objednatele. Jiné komponenty umožňující trvalý záznam dat nemagnetického charakteru (např. SSD, Xxxxx apod.) objednatel nevrací a zajistí sám jejich bezpečné smazání a likvidaci.
VII
Smluvní pokuty, úrok z prodlení
1. V případě, že se nepodaří zhotoviteli dosáhnout výkonnosti IDS dle čl. I odst. 8 zjištěné při výkonnostním testu do konce lhůty pro akceptaci 1. etapy plnění podle přílohy č. 3 má objednatel právo požadovat smluvní pokutu ve výši 500 000 Kč.
2. V případě prodlení zhotovitele v kterékoliv lhůtě dle čl. II odst. 1 má objednatel právo požadovat smluvní pokutu ve výši 5 000 Kč za každý den prodlení.
3. Objednatel má právo požadovat na zhotoviteli zaplacení smluvní pokuty:
a) ve výši 20 000 Kč za každou hodinu prodlení ve lhůtě pro potvrzení požadavku na řešení kritické závady IDS dle čl. VI odst. 5;
b) ve výši 20 000 Kč za každou započatou hodinu prodlení zhotovitele ve lhůtě pro zahájení řešení kritické závady IDS dle čl. VI odst. 2 písm. b);
c) ve výši 20 000 Kč za každou započatou hodinu prodlení zhotovitele ve lhůtě pro oznámení požadavku na řešení kritické závady IDS do supportních středisek výrobce IDS dle čl. VI odst. 2 písm. b);
d) ve výši 4 000 Kč za každou započatou hodinu neodůvodněného přerušení odstraňování kritické závady IDS dle čl. VI odst. 2 písm. b) zhotovitelem;
e) ve výši 2 000 Kč za každou započatou hodinu prodlení zhotovitele ve lhůtě pro zahájení řešení nekritické závady IDS dle čl. VI odst. 2 písm. c);
f) ve výši 1 000 Kč za každou započatou hodinu neodůvodněného přerušení odstraňování nekritické závady IDS dle čl. VI odst. 2 písm. c) zhotovitelem.
5. V případě porušení povinnosti zhotovitele dodržení standardního cyklu patchování (četnost menší než požadovaná) nebo v případě porušení povinnosti souladu s funkčními požadavky na patchování uvedené v příloze č. 2 (zejména požadavek na aplikaci kumulovaných patchů) má objednatel právo požadovat smluvní pokutu 10 000 Kč za každý jednotlivý případ porušení uvedených povinností.
6. V případě porušení povinnosti mlčenlivosti pracovníky zhotovitele dle článku IX má objednatel právo požadovat smluvní pokutu ve výši 20 000 Kč za každý jednotlivý případ porušení této povinnosti.
7. V případě, že zhotovitel nedodrží kterýkoli funkční či technický požadavek objednatele uvedený v příloze č. 2, vyjma případů uvedených v odst. 5 tohoto článku má objednatel právo požadovat smluvní pokutu 10 000 Kč za každý jednotlivý případ nedodržení požadavku. Smluvní pokutu je objednatel oprávněn uplatňovat do dvou let po závěrečné akceptaci plnění.
8. V případě prodlení objednatele s uhrazením daňového dokladu zaplatí objednatel zhotoviteli
úrok z prodlení podle předpisů občanského práva.
9. Smluvní pokutou není dotčen nárok na náhradu škody. Případná odpovědnost zhotovitele za škodu způsobenou neplněním povinností vyplývajících z této smlouvy je omezena celkovou částkou ve výši 20 mil. Kč, kterou smluvní strany považují za předvídatelnou škodu.
VIII
Vlastnictví, nebezpečí škody na věci
1. Vlastnictví k technickým prostředkům a právo užívání programových prostředků IDS dle
této smlouvy přechází na objednatele dnem podpisu závěrečného akceptačního protokolu.
2. Dnem převzetí prostředků objednatelem do úschovy přechází nebezpečí škody na těchto prostředcích na objednatele.
IX
Mlčenlivost, pojištění, bezpečnostní požadavky objednatele
1. Xxxxxxxxxx se zavazuje zajistit, že jeho pracovníci, kteří se budou na plnění podle této smlouvy podílet, zachovají mlčenlivost o všech informacích, se kterými se u objednatele seznámí a které nejsou veřejně dostupné, a že budou tyto informace používat jen v souladu s účelem této smlouvy. Jedná se zejména o informace, které zhotovitel získá při implementaci IDS, zejména topologie vnitřní sítě a IP plán, používané verze operačních systémů nebo provozní procesy objednatele. Povinnost mlčenlivosti není časově omezena.
2. Zhotovitel je povinen mít sjednáno pojištění odpovědnosti za škodu způsobenou třetí osobě v souvislosti s poskytováním plnění podle této smlouvy s tím, že pojištění bude sjednáno na pojistné plnění nejméně ve výši 20 mil. Kč a jeho spoluúčast nepřevyšuje 5 %.
3. Zhotovitel se zavazuje, že pojištění v uvedené výši a rozsahu zůstane účinné po celou dobu účinnosti této smlouvy, a do 5 pracovních dnů od výzvy objednatele bude zhotovitel povinen toto objednateli prokázat.
4. Zhotovitel se zavazuje v plném rozsahu dodržovat bezpečnostní požadavky objednatele,
které jsou uvedeny v příloze č. 5 této smlouvy.
X
Trvání smlouvy, výpověď, odstoupení od smlouvy
1. Smlouva v části týkající se provozní podpory je uzavřena na dobu neurčitou s šesti měsíční výpovědní dobou, která počne běžet prvním dnem měsíce následujícího po doručení písemné výpovědi druhé smluvní straně. Xxxxxxxxxx je oprávněn smlouvu vypovědět nejdříve po 5 letech ode dne podpisu závěrečného akceptačního protokolu.
2. Smluvní strany se dohodly, že objednatel je oprávněn kdykoliv v průběhu insolvenčního řízení zahájeného na majetek zhotovitele vypovědět tuto smlouvu, a to ve 14 denní výpovědní době, která počíná běžet dnem následujícím po doručení písemné výpovědi zhotoviteli.
3. Objednatel si vyhrazuje právo odstoupit od této smlouvy v celém či částečném rozsahu
v případě, že:
a) test výkonnosti IDS provedený v rámci akceptace 1. etapy plnění dle přílohy č. 3
smlouvy nedosáhne hodnoty dle čl. I odst. 8 smlouvy,
b) dodané IDS či některá z jeho komponent nebudou splňovat veškerou specifikaci dle přílohy č. 1 nebo veškeré požadavky dle přílohy č. 2 či nebudou v souladu s přílohou č. 8 této smlouvy a zjištěné odlišnosti nebudou napraveny do 30 dnů od jejich oznámení zhotoviteli,
c) zhotovitel bude v prodlení s dodávkou IDS delším než 30 dnů,
d) zhotovitel prokazatelně neřeší kritickou závadu (tj. nezahájí nebo bezdůvodně přeruší odstraňování závady) po dobu 24 hodin, resp. u nekritické závady po dobu 5 dnů.
4. Odstoupení od smlouvy je účinné doručením písemného oznámení o odstoupení zhotoviteli. Xxxxxxxxxx se zavazuje nejpozději do 60 dnů od účinnosti odstoupení od smlouvy zajistit na své náklady odvoz IDS.
XI
Licenční ujednání
1. Zhotovitel poskytuje objednateli nevýhradní a nepřevoditelnou a časově neomezenou licenci umožňující užívat předmětný SW.
2. Licence poskytnuté dle této smlouvy se vztahují i na veškeré poskytnuté aktualizace (tj.
update / upgrade / patch / hotfix atd.).
3. Objednatel není povinen licenci využít.
4. Právo užívání programových prostředků dle této smlouvy přechází na objednatele dnem podpisu závěrečného akceptačního protokolu. Objednatel se stane vlastníkem médií s programovými prostředky IDS a jeho dokumentace dnem převzetí plnění. V případě nutnosti užívat některý SW v průběhu provádění díla, zajišťuje potřebnou licenci na své náklady zhotovitel.
XII
Uveřejnění smlouvy a skutečně uhrazené ceny za plnění smlouvy
1. Xxxxxxxxxx si je vědom zákonné povinnosti objednatele uveřejnit na svém profilu tuto smlouvu včetně všech jejích případných změn a dodatků a výši skutečně uhrazené ceny za plnění této smlouvy.
2. Profilem objednatele je elektronický nástroj, prostřednictvím kterého objednatel, jako veřejný objednatel dle zákona č. 134/2016 Sb., o zadávání veřejných zakázek (dále jen
„ZZVZ“) uveřejňuje informace a dokumenty ke svým veřejným zakázkám způsobem, který umožňuje neomezený a přímý dálkový přístup, přičemž profilem objednatele v době uzavření této smlouvy je xxxxx://xxxx.xxx.xx/.
3. Povinnost uveřejňování dle tohoto článku je objednateli uložena § 219 ZZVZ.
4. Uveřejňování bude prováděno dle ZZVZ a příslušného prováděcího předpisu k ZZVZ.
XIII
Závěrečná ustanovení
1. Smlouva nabývá platnosti a účinnosti dnem podpisu oprávněnými zástupci obou smluvních
stran.
2. Smlouvu lze měnit nebo doplňovat pouze formou písemně uzavřených dodatků, podepsaných oběma smluvními stranami vyjma případů změn osob nebo jejich kontaktních údajů uvedených v článku V nebo v příloze č. 4, které budou prováděny písemným oznámením zaslaným prostřednictvím datové schránky nebo e-podatelny v případě e-mailů.
3. Smlouva je sepsána v českém jazyce. Komunikace mezi smluvními stranami ve věci smlouvy bude probíhat v českém nebo slovenském jazyce. Komunikace ve věcech technické podpory nebo dokumentace může probíhat i v anglickém jazyce.
4. Případný spor vzniklý z této smlouvy nebo v souvislosti s ní, bude rozhodován výlučně podle českého práva obecnými soudy v České republice.
5. Smluvní strany se dohodly, že se uplatnění domněnky doby dojití dle § 573 občanského zákoníku se vylučuje.
6. Práva a povinnosti vzniklé ze smlouvy mohou být postoupeny pouze po předchozím písemném souhlasu druhé smluvní strany. Za písemnou formu se v tomto případě nepovažuje e-mail či jiné elektronické zprávy.
7. Odpověď smluvní strany smlouvy podle § 1740 odst. 3 občanského zákoníku s dodatkem nebo odchylkou není přijetím nabídky, ani když podstatně nemění podmínky nabídky.
Příloha č. 1
Specifikace technických a programových prostředků IDS dodávaných zhotovitelem
Specifikace technických prostředků
Nabízená IDS platforma pro provoz Oracle databází požadovaná v poptávce je řešena pomocí dvou boxů Integrovaného systému Oracle Exadata Database Machine X6-2 v provedení Quarter Rack. Každý tento Integrovaný systém obsahuje dva databázové servery, tři Exadata Storage servery a vysokorychlostní vnitřní síťové propojení. Podrobnější popis je uveden
v Příloze 8. Návrh technického řešení.
Primární lokalita
Záložní lokalita
Disaster Recovery s využitím
Oracle DataGuard
V tabulce jsou uvedeny požadované výkonové a kapacitní parametry, parametry jsou uvedeny pro jednu lokalitu, druhá lokalita je identická:
Exadata Databace Machine X6-2 Quarter Rack, konfigurace jedné lokality: | |
Počet Databázových serverů, počty CPU jader, velikost RAM | 2x Databázový server , celkem 40 aktivovaných CPU jader Intel Xeon (celkový možný počet CPU jader je 88, 48 CPU jader bude deaktivovaných) Velikost RAM v každém DB serveru je 768GB, celkem RAM požadovaných 1,5 TB |
Počet Storage serverů, počty procesorových jader pro SQL offload na storage systému | 3x Exadata Storage server, celkem 60 procesorových jader pro SQL offload |
Storage kapacita - disky, flash cache | 288 TB raw kapacita disků (3 x 12 x 8TB) 85 TB čisté kapacity pro data bez použití komprese (při použití ochrany dat - trojnásobném zrcadlení dat ) 38,4 TB MVMe PCIe 3.0 flash karty pro použití funkce Inteligentní Flash cache |
Síťová připojení | 4x 10 Gb SFP + Short Wave (SW) transceivers 3x Management port 100/1000 RJ45 |
Specifikace programových prostředků/licencí
Ze zadávací dokumentace vyplývá následující požadovaný cílový stav licencí:
Požadovaný stav po migraci | ||
Název licence | typ licence | cílový počet |
Database Enterprise Edition | CPU | 46 |
Real Application Clusters | CPU | 40 |
Partitioning | CPU | 42 |
Tuning Pack | CPU | 44 |
Diagnostic Pack | CPU | 44 |
Database Standard Edition | CPU | 2 |
Pro dosažení cílového stavu jsme vzali v úvahu existující instalovanou bázi, kterou jsme se snažili co nejlépe využít k dosažení cílového stavu.
Využití instalované báze v projektu a migrace licencí | ||||
Název licence | Existující CPU licence | Existující NUP licence | Chybějící CPU do požadovaného stavu | Využitá CSI |
15483055, | ||||
14769029,14677816, | ||||
Database Enterprise Edition | 10 | 800 (ekvivalent 16 CPU) | 20 | 15679011, 14677816 |
Real Application Clusters | 0 | 0 | 40 | |
Partitioning | 10 | 368 (odpovídá 7 CPU a 18 NUP) | 25 | 14677816 |
Tuning Pack | 8 | 0 | 36 | |
Diagnostic Pack | 8 | 800 (odpovídá 16 CPU) | 20 | 14677816 |
Database Standard Edition One | 17732065,14677816, | |||
(Migrováno na DB EE) | 3 | 1440 | 19628570 | |
Database Standard Edition (ponechány) | 2 | 0 | 2 | 14677816 |
Následující licence navrhujeme migrovat standardním poměrem 50 NUP = 1 CPU:
Database Enterprise Edition 800 NUP (CSI 14677816) na 16 CPU, přičemž stávající výše technické podpory 4.849.468,96 Kč za aktuální rok 2017 zůstane nezměněna a její meziroční navýšení pro násedující roky je fixováno na 0% pro rok 2018, 0% pro rok 2019, 0% pro rok 2020 a pro rok 2021 je fixováno na 2%.
Technická podpora těchto licencí Database Enterprise Edition 800 NUP není zahrnuta v cenové tabulce Příloha č. 3 neboť jde o stávající technickou podporu, která nenavyšuje stávající celkové náklady na technickou podporu.
Obdobně navrhujeme migrovat Diagnostic Pack 800 NUP (CSI 14677816) na 16 CPU, přičemž stávající výše technické podpory 363.712,10 Kč za aktuální rok 2017 zůstane nezměněna a její meziroční navýšení pro násedující roky je fixováno na 0% pro rok 2018, 0% pro rok 2019, 0% pro rok 2020 a pro rok 2021 je fixováno na 2%.
Technická podpora těchto licencí Diagnostic Pack 800 NUP není zahrnuta v cenové tabulce Příloha č. 3 neboť jde o stávající technickou podporu, která nenavyšuje stávající celkové náklady na technickou podporu.
Dále navrhujeme migrovat stejným způsobem Partitioning 350 NUP (CSI 14677816) na 7 CPU, přičemž stávající výše technické podpory 557.690,18 Kč za aktuální rok 2017 zůstane nezměněna a její meziroční navýšení pro
násedující roky je fixováno na 0% pro rok 2018, 0% pro rok 2019, 0% pro rok 2020 a pro rok 2021 je fixováno na
2%.
Technická podpora těchto licencí Partitioning 350 NUP není zahrnuta v cenové tabulce Příloha č. 3 neboť jde o stávající technickou podporu, která nenavyšuje stávající celkové náklady na technickou podporu. Zbývajících 18 NUP Partitioning navrhujeme migrovat na 1 CPU Partitioning, přičemž v tabulce Příloha č. 3 uvádíme kredit ve výši 25.816 Kč za 18 NUP (kredit bude poskytnut jako sleva za poměrnou část licencí z ceny dalšího nového 1 CPU Partitioning)
Pro licence Database Standard Edition One používá Oracle druhý možný typ migrace tzv. NET-NET, kdy se od finální hodnoty cílového počtu licencí odčítá čtyřnásobek hodnoty stávající technické podpory migrovaných licencí.
Migrovat navrhujeme následující licence na 20 CPU Database Enterprise Edition:
Název licence | Počet | CSI | Stávající technická podpora |
Oracle Database Standard Edition One - CPU | 1 | 19628570 | 14 467,60 |
Oracle Standard Edition One - NUP | 1440 | 17732065 | 725 361,21 |
Oracle Standard Edition One - CPU | 1 | 14677816 | 29 090,17 |
Oracle Standard Edition One - CPU | 1 | 17732065 | 16 231,11 |
Celkový kredit | 3 140 600,35 |
Migrační kredit ve výši 3.140.600 Kč je uveden v tabulce Příloha č. 3 v oddílu 3 Případný kredit (sleva) za převod existujících Oracle DB SEO licencí zadavatele na DB EE licence.
Stávající poplatek technické podpory ve výši 785.150 Kč není zahrnut v cenové tabulce Příloha č. 3 neboť jde o stávající technickou podporu, která nenavyšuje stávající celkové náklady na technickou podporu. Stejně jako u předchozích položek je výše stávající technické podpory za aktuální rok 2017 zůstane nezměněna a její meziroční navýšení pro násedující roky je fixováno na 0% pro rok 2018, 0% pro rok 2019, 0% pro rok 2020 a pro rok 2021 je fixováno
na 2%.
Navrhovaná migrace výše uvedených licencí bude smluvně řešena smlouvou mezi ČNB a Oracle partnerem Neit Consulting a následně objednána partnerem Neit Consulting prostřednictvím distribuční sítě u Oracle Czech.
Technická podpora stávajících licencí je objednána u společnosti Oracle Czech do konce kalendářního roku 2017 a je placena kvartálně zpětně. K datu účinnosti migrace bude poměrná část technické podpory do konce roku 2017 za migrované licence fakturována Neit Consulting, který tuto poměrnou část transparentně bez navýšení přeúčtuje ČNB.
Technická podpora licencí (Oracle Premier Support a HW support and maintenance) vyjma služby Monitoring pro roky 2018 – 2021 může být řešena napřímo s Oracle Czech nebo s Neit Consulting dle rozhodnutí ČNB. Ze zadávací dokumentace není zcela jasná preference ČNB.
V tabulce jsou uvedeny počty dodávaných Oracle licencí a jejich cena bez technické podpory:
Oracle software licence celkem pro obě lokality:
Popis | Počet jednotek | Způsob licencování | Cena SW |
Oracle DB - Enterprise Edition | 20 | CPU | 7.612.646,40 Kč |
Oracle DB – Diagnostic Pack | 20 | CPU | 801.331,20 Kč |
Oracle DB - Tuning Pack | 36 | CPU | 1.442.396,16 Kč |
Oracle DB – Partitoning Option | 25 | CPU | 2.303.827,20 Kč |
Oracle DB - RAC | 40 | CPU | 7.372.247,04 Kč |
Exadata Storage SW (součástí IDS) | 72 | disk | 5.215.266,00 Kč |
Kredit za Migraci DB SEO | -3.140.600,36 Kč | ||
Kredit za Migraci Partitioning 18 NUP | -25.816 Kč | ||
CELKEM | 21.581.297,64 Kč |
Specifikace licencí či služeb nad rámec programových prostředků
Provozní podpora
Provozní podpora je poskytována v požadovaném režimu po dobu 24 hodin a 7 dnů v týdnu. Řešení kritické závady bude zahájeno do 2 hodin od nahlášení a na jejím odstranění bude zhotovitel pracovat bez zbytečného odkladu a přerušení. Nebude-li závada vyřešena do 4 hodin od jejího nahlášení, je zhotovitel povinen oznámit požadavek na řešení závady do supportních středisek výrobce IDS, a to nejpozději do 5 hodin od nahlášení závady.
Řešení nekritické závady bude zahájeno do 4 hodin od nahlášení a na jejím odstranění bude zhotovitel pracovat bez neodůvodněného přerušení.
Součástí dodávky je i monitorování HW součástí a včasné hlášení problémů (tzv. Platinum support), které mohou nastat a případné automatické objednání a dodání příslušných náhradních dílů.
V případě nutnosti vyměnit vadný díl je nutné vadný díl vrátit zhotoviteli. Objednatel je oprávněn učinit všechny kroky, které zajistí smazaní uložených dat.
POŽADAVKY OBJEDNATELE NA IDS
Příloha č. 2
V této příloze jsou uvedeny podrobné požadavky objednatele na předmět plnění – vlastní IDS.
1. POŽADAVKY NA IDS – VĚCNÉ POŽADAVKY
Níže v kapitolách 1. x jsou uvedeny základní věcné požadavky na poptávané IDS. Z pohledu objednatele se jedná o nejdůležitější požadavky, které mají umožnit splnit cíle uvedené v preambuli této smlouvy. V těchto oblastech je žádáno jejich 100% splnění, žádné alternativní řešení není akceptováno.
1.1. Bezodstávkové fault-tolerantní řešení
Definice „Bezodstávkovosti/zajištění provozu“:
1.1.1. Zajištění kontinuity provozu IDS nezávisle v každé lokalitě
V každé instalační lokalitě bude IDS navržen pro bezodstávkový provoz a to jak pro plánované rutinní činnosti, tak i pro neplánované události.
Plánovanými rutinními činnostmi se rozumí možnost SW záplatování, výměna vadných HW komponent nebo jejich doplnění. Neplánovanými událostmi se rozumí poruchy jedné komponenty v rámci redundantní skupiny (např. disk v rámci diskového pole, síťové rozhraní v rámci skupiny, serverová nebo dílčí jednotka v rámci dvojice apod.). Bezodstávkovým provozem se rozumí stav, kde platí, že pro každou spuštěnou databázi je trvale nejméně jedna databázová instance stále v provozu.
Z toho vyplývá, že IDS v každé lokalitě musí být navrženo jako soběstačné fault-tolerantní řešení, tedy bez tzv. single-point-of-failure. Veškeré důležité komponenty pro běh databází musí být zdvojeny. IDS musí obsahovat vhodný SW pro zajištěna kontinuity provozu v rámci jedné lokality.
1.1.2. Zajištění provozu v případě výpadku jedné lokality
Systém musí být dále navržen tak, aby byl v případě výpadku celého IDS či nemožnosti jeho
provozu v jedné lokalitě zajištěn provoz všech databází v lokalitě druhé, takže umožní
„sečtení“ provozu obou IDS v jedné lokalitě.
Zadavatel předpokládá, že při normálním provozu budou v jedné lokalitě aktivní (ostré) provozní databáze a ve druhé lokalitě budou aktivní vývojové a testovací databáze. Tyto databáze budou průběžně replikovány synchronně do opačné lokality a budou tak pasivně připraveny pro zajištění vysoké dostupnosti v rámci dvou lokalit.
Navržené řešení musí umožnit automatizovaný náběh replikovaných databázových instancí do
2 minut.
Z důvodu sloučení provozu všech databází (provozních i vývojových a testovacích) musí být IDS navržen s dvojnásobnou kapacitou CPU jader, pro která se využije licenční ustanovení
1) Výčet není úplný a vychází z aktuálních znalostí pracovníků objednatele či informací získaných z průběžného monitoringu rozvoje technologií v dané oblasti.
Oracle DB pro nouzový provoz v záložní lokalitě (nejvýše 10 dnů a nejvýše 10 využití v roce). Ostatní parametry IDS (velikost RAM, diskových polí) není potřeba pro účely sloučení všech databází zdvojovat.
Pro přenos dat mezi jednotlivými instalačními lokalitami IDS bude využita počítačová síť se dvěma nezávislými šifrovanými optickými trasami, každá s přenosovou kapacitou 10 Gbps.
Z toho vyplývá, že IDS v každé lokalitě musí mít odpovídající zejména výkonovou rezervu CPU jader. Databáze budou v obou střediscích (aktivní a/nebo pasivní), s kapacitou je tedy počítáno. U požadavku na velikost RAM je již s rezervou počítáno. Dále je nutné zajistit vhodný SW pro zajištění synchronní replikace databází mezi oběma lokalitami.
Zdůvodnění:
Výše uvedené požadavky jsou odůvodněny ve vztahu k zákonu o kybernetické bezpečnosti („ZoKB“) - záplaty, dostupnost KII a VIS informačních systémů – na daných IDS budou provozovány databáze také pro tyto informační systémy.
Dalším důvodem je požadavek na vysokou dostupnost některých informačních systémů,
kde z věcného funkčního hlediska či na základě dikce zákona je požadováno zajištění
„nepřetržitého provozu“, např. CEÚ2) (zákonná povinnost zajistit dostupnost 24x7).
V neposlední řadě je jedním z cílů implementace IDS i snížení náročnosti administrace databází Oracle, např. z důvodů hledání vhodných časů pro odstávky (patchování, opravy atd.).
Možná realizace:
Požadavky objednatele naplňují na HW úrovni např. zdvojení HW komponent a Hot-Plug technologie, lokální zabezpečení dat na discích technologií RAIDx atd.
Na úrovni programového vybavení IDS využití např. Unbreakable Linux Kernel.
Na úrovni databází pak „bezodstávkovost“ splňuje využití plnohodnotného Oracle RAC (Real Application Cluster) a Oracle DataGuard pro vzdálené zrcadlení dat.
1.2. Efektivita provozních nákladů
Definice „Efektivního systému“:
Navržený IDS musí být provozně efektivní, jak při jeho výchozí konfiguraci, tj. 40 Oracle CPU EE DB licencí (20 licencí pro každou instalační lokalitu), tak i v případě budoucího rozšíření výpočetních kapacit IDS. Dodavatel zajistí podporu pro tuto architekturu ze strany společnosti Oracle spočívající v tom, že případná nevyužitá, byť instalovaná, CPU/jádra či další relevantní HW komponenty není nutné licencovat (lze je „vypnout“ a toto „vypnutí“ vyhovuje licenčním podmínkám pro Oracle DB). Zároveň IDS umožňuje všechna licencovaná aktivovaná jádra instalovaná v dané lokalitě dynamicky využívat jako jeden celek pro potřeby k tomu vyladěných databází a stejně tak tomu bude i po případném rozšíření.
Zdůvodnění:
Základním cílem zadávacího řízení a této smlouvy, která z něj vychází, je umožnit konsolidaci 90 databází, které objednatel nyní provozuje na 172 procesorových jádrech (licenční pohled) – minimum ve verzích EE, většina ve verzích SE. V důsledku této konsolidace očekává objednatel efektivnější provoz v konsolidované databázové platformě díky vlastnímu konceptu stavby IDS, zejména díky možnosti sdílení CPU kapacity, použití novějších a výkonnějších
2) xxxx://xxx.xxxx.xx/xx/xxxxxxxx/xxxxxxx-xxxxxx/0000/xxxxxxxx-xxxx-xxxxxx-xxxxxxxxxx-xxxxx-00000
technologií IDS. Jako minimální počet pro výchozí konfiguraci IDS je objednatelem stanoveno
40 CPU EE Oracle DB licencí (80 jader). V případě případného budoucího rozšiřování
v horizontu 5 let nebo aktivace například různých disater recovery plánů (viz též požadavek ne
„bezodstávkovost“) chce objednatel mít možnost realizovat toto rozšíření IDS
s predikovatelným finančním rámcem.
1.3. Řízení systémových zdrojů
Definice „Řízení systémových zdrojů“:
IDS musí umožnit dynamické přidělování zdrojů aplikacím (jejich databázovým instancím) na základě vyhodnocování skutečné doby odezvy aplikace oproti hodnotě stanovené pro danou třídu kritičnosti aplikace. Zdroje jsou přidělovány z volných zdrojů a v případě, že tyto nejsou k dispozici, tak na úkor zdrojů využívaných aplikacemi zařazenými do tříd s nižší kritičností.
IDS musí umožnit vzájemně výkonově izolovat skupiny aplikací různých tříd (OLTP aplikace, analytické aplikace, aplikace patřící do KII podle ZoKB) z hlediska výkonu (workload isolation) a to bez nutnosti použití SW virtualizace.
Zdůvodnění:
Zákon o kybernetické bezpečnosti vyžaduje schopnost provozovatelů KII a VIS informačních systémů, aby jejich provoz byl oddělen od ostatních informačních systémů (oddělení prostředí, ochrana mezi vývojem a testem atd.). Kromě využití 2 instalací IDS pro různé typy provozu je řízení zdrojů IDS dalším nástrojem pro naplnění požadavků ZoKB.
Objednatel neumožňuje použití virtualizace, aby v rámci IDS bylo umožněno sdílení maximálního instalovaného výkonu pro náročné aplikace – virtualizace tento princip významně drobí.
Možná realizace:
Řešení výše uvedených požadavků lez realizovat například na úrovni Oracle DB 12c včetně možnosti řízení přidělování zdrojů IDS na úrovni jeho architektury.
1.4. Dodávka SW licencí
Definice „Dodávky SW licencí Oracle“:
Součástí dodávky IDS budou také SW licence pro databáze Oracle typu CPU EE včetně požadovaných Options, které budou provozovány na IDS.
Výchozí stav licencí, kterými disponuje objednatel, je dostupný na Internetu, konkrétně se jedná o 10 CPU EE, 800 NU EE, 3 CPU SE, 1440 NU SE a další Options viz popis výchozího a chtěného stavu níže.
• Z tohoto portfolia je nutno vyčlenit:
o 2 licence databáze Oracle CPU EE včetně option Partitioning,
o 4 licence databáze Oracle CPU EE včetně Diagnostic a Tuning pack. Licence pro Partitioning zde však není potřeba.
pro provoz „legacy“ aplikací objednatele, které nemohou být nyní migrovány do IDS
a které budou později v delším časovém horizontu nahrazovány novými aplikacemi.
• Dále je potřeba vyčlenit dvě licence databáze Oracle CPU SE pro potřeby interní aplikace nemigrovatelné z technických důvodů do IDS.
Inicializační stav potřebných licencí při implementaci IDS dle této smlouvy je stanoven expertním odhadem objednatele na 40x licence databáze Oracle typu CPU EE celkem pro obě instalační lokality – každá lokalita po 20 licencích. Současně s licencemi pro databáze budou poskytnuty licence na stejný počet CPU (CPU jader) i pro následující options: Partitioning, Diagnostic, Tunning Pack, Oracle RAC a případně další licence/komponenty/options atd., které dodavatel shledá jako nezbytné pro zajištění požadavků objednatele a chodu nabízených IDS. Níže jsou uvedeny informace o licencích options, kterými disponuje zadavatel (výchozí stav).
• Výchozí stav Partitioning: 17 CPU EE licencí,
o cílový stav 40 CPU EE licencí + licence pro legacy aplikace
• Výchozí stav Diagnostic Pack: 24 CPU EE licencí,
o cílový stav 40 CPU EE licencí + licence pro legacy aplikace
• Výchozí stav Tunning Pack: 8 CPU EE licencí,
o cílový stav 40 CPU EE licencí + licence pro legacy aplikace
• Výchozí stav Oracle RAC: 0 licencí,
o cílový stav 40 CPU EE licencí
Převodní postup i budoucí použití musí být v souladu s licenčními podmínkami společnosti Oracle. Případné odchylky musí být schváleny společností Oracle (nutno doložit souhlasem podepsaným oprávněnou osobou za společnost Oracle).
Podporu nových licencí databází Oracle a Options po prvním roce jejich používání a podporu existujících licencí ponechaných pro „legacy“ aplikace si bude dodavatel zajišťovat sám.
Zdůvodnění:
Převod a konsolidace licencí umožní objednateli snížit komplexnost licencování provozovaných databází a zlepšit možnosti objednatele při práci s externími klienty. Enterprise edice databází umožní lepší analýzu a design databázových aplikací a zpřesní nároky na jejich vývoj, dohled a provoz. Optimalizované aplikace také budou mít dopad na efektivní využití instalovaného výkonu IDS.
Možná realizace:
Vlastní realizace závisí plně na dodavateli a je možné ji provést různými způsoby, např. formou rozšíření počtu stávajících licencí (pořízení nových licencí, převod licencí typu SE na EE nebo NU na CPU atd.). Podmínkou je zachování 6 licencí CPU EE a některých Options (viz výše) a jedné licence SE tak, aby byly k použití v ČNB mimo dodávaný IDS.
1.5. Migrační proces – SW licence
Definice „Migračního procesu“:
Migrační proces bude z pohledu objednatele znamenat, že po nezbytnou dobu budou vedle sebe fungovat stávající prostředí pro provoz databází, které se bude postupně zmenšovat a nové prostředí IDS, kam budou migrované databáze postupně implementovány. Objednatel požaduje, aby dodavatel v rámci své nabídky navrhl postup jak toto přechodové období správně zalicencovat z pohledu databází Oracle s cílem minimalizovat finanční náklady s tím spojené. Objednatel nechce financovat dvě prostředí pro provoz databází Oracle současně.
V rámci nabídky musí dodavatelé doložit, že jimi navržený postup je v souladu s licenčními podmínkami společnosti Oracle nebo společností Oracle schválen.
Zdůvodnění:
Objednatel používá pouze legální SW a trvá na zajištění práv majitelů licencí databázového
SW.
Možná realizace:
Dodavatel zajistí např. poskytnutí dodatečných licencí nebo zajištění výjimky od společnosti Oracle (nutno doložit souhlasem podepsaným oprávněnou osobou za Oracle). Dodavatel využije stávající volné licence objednatele a převede je do IDS a tyto licence budou po dobu migrace aktivní jak ve starém prostředí, tak v IDS apod.
2. IDS – TECHNICKÉ POŽADAVKY
V této kapitole jsou popsány technické požadavky na poptávané IDS a případně další požadavky, kde jsou již možné různá alternativní řešení, které je pak posuzováno v rámci hodnotícího procesu v zadávacím řízení.
2.1 Základní technické požadavky
Je požadována dodávka IDS určených pro provoz konsolidované databázové platformy zde
standardně založené na databázi Oracle ve verzi 11g a 12.x.
Hardwarové komponenty použité v IDS budou certifikovány pro provoz databází společností Oracle v aktuálních podporovaných verzích.
Navrhované řešení IDS bude podporovat vysokou dostupnost provozu databází Oracle a odolnost proti výpadkům komponent či celých IDS v jedné instalační lokalitě (při výpadku celého IDS bude možno využít i druhou instalační lokalitu).
Z hlediska licencí databází Oracle budou dodávané IDS licencovány tak, aby umožnily provoz databáze Oracle ve verzi Enterprise Edition včetně požadovaných rozšíření (options) – viz kapitola 1.4 výše.
Následná provozní podpora implementovaných IDS bude realizována v celém dodaném stacku IDS (HW a jeho firmware, operační systém, dodaný aplikační SW pro chod IDS, Oracle DB) a zahrnuje zejména monitoring, patchování, odstraňování poruch, upgrade komponent IDS atd.
2.2 Požadavky na SW vybavení IDS
V současné době jsou informační systémy objednatele založené na databázi Oracle provozované v operačním systému RedHat Linux či Oracle Linux (Unbreakable Enterprise Kernel) provozovaných na komoditních serverech architektury x86/x64. Informační systémy tak mohou využívat i různé extenze tohoto operačního systému, popř. do tohoto systému jsou instalována různá rozšíření či ovladače externích komponent. Dodávané IDS musí tyto vlastnosti podporovat.
Objednatel realizuje projekt konsolidace existující instalace distribuovaných DB serverů, neprovádí projekt redesignu existujících aplikačních platforem či operačních systémů a HW platforem.
Z důvodu eliminace mimořádně vysokých interních nároků na interní kapacity v případě migrace databází a v nich provozovaných informačních systémů mezi platformami různých operačních systémů či výpočetních platforem, krátkého času pro realizaci nasazení IDS a využití stávajících produktů a extenzí 3. stran v operačních systémech (ovladače, drivery, volání operačního systému v aplikacích apod.) atd., požaduje objednatel, aby IDS využívaly nyní u objednatele provozované a podporované platformy:
• HW platforma IDS musí využívat platformu serverů založených na architektuře
x86/x64.
• Operační systém RedHat Enterprise Linux nebo Oracle Linux (v podporovaných verzích).
2.3 Požadavky na výkonnost a kapacitu IDS, řízení zdrojů
Dodané IDS musí pokrýt výkonnostní a kapacitní požadavky pro 98 databázových instancí – viz příloha č. 7 kapitola 1.4. Dále musí zajistit dostatečnou volnou kapacitu pro plánované nové aplikace.
Na základě expertních odhadů pracovníků objednatele jsou minimální výkonnostní parametry stanoveny tak, že požadovaný výpočetní výkon zajišťuje minimální počet 40 CPU jader na IDS v každé instalační lokalitě. Minimální výkonnost těchto CPU jader je stanovena na úroveň procesoru typu Intel Xeon E5-2699 v43). Je možno nabídnout i výkonnější verze procesorů dle xxxx://xxx.xxxxxxxxxxxx.xxx/xxxx_xxx_xxxx.xxxx či xxx.xxxx.xxx nebo jiné obecně dostupné a používané benchmarkové systémy.
Dodané IDS budou v každé instalační lokalitě vybavené alespoň 80 CPU jádry z důvodu připravenosti na zachování kontinuity provozu – viz kapitola 1.1 v této příloze. Čtyřicet (40) jader bude aktivních z licenčního pohledu společnosti Oracle, zbytek instalovaných jader (minimálně 40) z tohoto pohledu neaktivních, budou „deaktivované“.
Z hlediska dalších požadavků na kapacitu a výkonost IDS objednatel dále požaduje:
• Čistá kapacita diskového úložiště při aplikaci jejich ochrany a při odečtení různých režií uložení dat je min. 80 TB v každé instalační lokalitě.
o Požadovaná kapacita je dosažena bez použití HW či SW komprese, pokud není zabudována a defaultně aktivní přímo ve firmware komponent této diskové kapacity.
• Data jsou chráněna proti chybě zápisu či výpadku disků z instalované diskové kapacity nějakou formou ochrany, např. paritou/RAIDx aj. Mohou nastat až dvě chyby či výpadky současně v takové chráněné kapacitě, aniž by došlo ke ztrátě v ní uložených dat.
• Instalované diskové kapacity musí využít v maximální míře technologie zrychlující I/O
operace, např. cache, SSD disky, připojení pomocí rychlého rozhraní4) apod.
• LAN připojení do sítě minimálně 4x 10 Gbps Ethernet (konektor: 10GBASE-SR (viz xxxxx://xx.xxxxxxxxx.xxx/xxxx/00_Xxxxxxx_Xxxxxxxx#Xxxxxxx_xxxxx )) pro datové připojení v každé instalační lokalitě. Toto spojení lze využít pro zrcadlení IDS z jedné instalační lokality do druhé.
o Pozn.: Replikace dat mezi instalačními lokalitami může obecně využívat současné propojení přes DWDM, ale pro propojení nebude poskytnut samostatný vyhrazený kanál.
• Minimálně 2x 1 Gbps pro management v každé instalační lokalitě.
3) xxxx://xxx.xxxxxxxxxxxx.xxx/xxx.xxx?xxxxXxxxxxXxxxxX0-0000xx0x%00x0.00XXx&xxx0000
4) např. InfiniBand min. 40 Gbps, FC n x 16 Gbps vč. propojovacího subsystému atd.
• V každé instalační lokalitě 1,5 TB RAM celkem. Z toho minimálně 768 GB RAM souvislého prostoru, pokud je tato celková RAM rozdělena přes více výpočetních jednotek.
2.4 Bezpečnost IDS
IDS z pohledu bezpečnosti je chápán jako systém, v němž se mezi aplikační komunikace odehrává uvnitř jeho komponent a ochrana a zabezpečení se realizuje zejména na komunikačním přístupovém bodu IDS do LAN. Z tohoto konceptu vyplývají následující požadavky:
• Pro přístup pracovníků zhotovitele k IDS či monitorovacího systému IDS je nutné jejich přihlášení – osobní účty či logovatelné sudo – aby bylo dohledatelné, který uživatel příslušné akce prováděl.
• Databázové linky mezi databázemi instalovanými v IDS jsou realizovány uvnitř interního propojení komponent IDS, tj. data přenášená pomocí těchto linků nepoužívají externí datovou LAN síť ČNB. V případě nutnosti kontroly komunikace databází patřících do KII s databázemi mimo KII, je možno zadefinovat databázový link jako externí a potom ho vést přes síť LAN a kontrolovat na FW. Nebo je možno pro kontrolu komunikace využít interní firewall IDS, pokud jsou podporovány.
• Je k dispozici logování aktivit správci DBA nebo pracovníky zhotovitele realizovaných lokálně z LAN objednatele nebo vzdáleně přes monitorovací systém. Jsou logovány minimálně tyto informace:
o čas, kdy událost nastala,
o identifikace uživatele
o a typ akce, které prováděl.
• Záznamy a auditní logy jsou chráněny proti nahodilé modifikaci a neoprávněnému smazání na aplikační a infrastrukturní úrovni.
• Logy lze napojit na systém SIEM používaný objednatelem.
2.5 Monitoring IDS
IDS bude vybaven funkcí pro monitoring správného fungování instalovaných technických prostředků IDS, instalovaného operačního systému a databázového systému.
Objednatel požaduje, aby při implementaci a prvotním provozu IDS byl nasazen a provozován kompletní monitoring IDS (HW i SW) lokálně, tj. dohled bude realizován dedikovanými pracovníky objednatele zejména v roli DBA. Dále bude implementován monitoring technických prostředků IDS (bez přístupu k datům v databázích či citlivým údajům v operačním systému) kdy data z monitoringu a hlášení o vadách budou automatizovaně zasílány do vzdálených center podpory dodavatele.
2.5.1 Obecné požadavky na monitoring a správu, lokální monitoring
Obecné požadavky na monitoring IDS:
• Jeho provoz a dostupnost bude koncipována na 24x7 vyjma zamýšlených odstávek
z důvodu například patchování.
• IDS musí být připojitelný ke zdroji přesného času pomocí protokolu NTP.
• Komunikace s IDS z důvodu monitoringu se bude dít na oddělené síti od datové sítě (např. oddělení prostřednictvím VLAN) – IDS umožní rozlišení management síť/datová síť.
V rámci implementace IDS u objednatele bude monitorovací systém splňovat/podporovat následující požadavky.
• Lokálně realizovaný monitoring bude zejména zahrnovat monitoring:
o HW – správná funkčnost instalovaných komponent IDS, popřípadě tzv. pre-failure varování, přehledy o zatížení jednotlivých komponent IDS s historií,
o Operační systém – základní charakteristiky provozu – zaplněnost logů či file- systémů, stack procesů atd.,
o DB – informace budou získávány prostřednictvím Oracle Enterprise Manageru.
• Zabezpečení monitorovacího systému:
o Přístup k monitorovacímu systému bude pro pracovníky objednatele možný po dedikované LAN síti objednatele za využití standardních WWW prohlížečů (IE11, Firefox, Google Chrome v aktuálních verzích), je možno případně jako add-on doinstalovat Oracle JAVA JRE v aktuální podporované verzi.
o Je k dispozici logování aktivit realizovaných přes monitorovací systém – minimálně čas, identifikace uživatele a typ akce, které prováděl. Záznamy a auditní logy jsou chráněny proti jakékoliv modifikaci a neoprávněnému smazání na aplikační a infrastrukturní úrovni.
o Logy monitorovacího systému lze napojit na SIEM používaný v ČNB.
2.5.2 Vzdálený přístup/monitoring IDS, zabezpečení
Objednatel předpokládá, že v rámci implementace IDS bude využívat i služeb vzdáleného
monitoringu
Základní vzdálený monitoring a dohled nad technickými prostředky IDS – vše v režimu pouze pro čtení „read-only“ a bez přístupu k uživatelským datům či citlivým administrátorským datům v databázích provozovaných na IDS či citlivým datům DBA je povolen kontinuální a bez omezení.
V rámci realizace tohoto vzdáleného monitoringu IDS musí být známo a zabezpečeno:
• Musí být zdokumentován protokol a typ použitého zabezpečení této komunikace, použité klíče (druh, délka) pro šifrování komunikace atd.
• Pro přenos/komunikace dodavatele k IDS (a případně zpět) musí být použity algoritmy podle vyhlášky - viz Kryptografie dle § 25 odst. 2b + příloha 3 vyhlášky 316/2014 Sb. (minimálně úroveň TLS 1.0)).
o Musí být definovaný postup pro správu klíčů.
• Musí být zdokumentovány všechny zdroje komunikace na straně zhotovitele.
• Musí umožnit nastavit různé scénáře (úrovně přístupu) k jednotlivým vrstvám a komponentám IDS.
• Vzdálený monitoring (resp. přenos dat k vzdáleným supportním centrům) musí být jednoduše pracovníky objednatele vypnutelný.
Pro vzdálený monitoring objednatel preferuje, aby připojení dodavatele poskytující službu vzdáleného monitoringu či správy se objednatelem, bylo realizováno formou dedikované linky
/ připojení (zajišťuje dodavatel). Přístup přes standardní Internet není zakázán, ale není preferován.
Veškerá komunikace od zhotovitele bude ukončena na perimetru objednatel (DMZ – demilitarizovaná zóna). Kde bude provedena inspekce tohoto provozu s dalším iniciovaným spojením již do vnitřní sítě objednatele k IDS.
Zhotovitel garantuje, že v případě externí komunikace nejsou k zhotoviteli přenášena data z databází objednatele či jiná citlivá data IDS (např. osobní data administrátorů, hash účtů atd.), mohou se přenášet pouze technická konfigurační data jednotlivých komponent IDS – operační systém, Oracle atd.
2.6 Administrace IDS
Dodávaný IDS musí být koncipován tak, aby jeho administraci mohlo v celém jeho stacku provádět minimum zaměstnanců objednatele. V ideálním stavu by jeho plnou administraci zajišťovali administrátoři Oracle („DBA“). Objednatel požaduje, aby operační systém byl při implementaci nastaven a optimalizován pro provoz databáze Oracle a že nebude vyžadovat běžnou denní údržbu administrátora operačního systému.
IDS a jejich provozní procedury jsou zdokumentovány, tj. součástí dodávky budou dokumenty pro administrátory IDS – správa, troubleshooting atd.
2.6.1 Zabezpečení správy IDS – správa uživatelů
• Autentizace uživatelů realizující monitoring a správu:
o Built-in účty (operační systém, monitorovací systém atd.) musí umožnit některé z následujících aktivit – změna hesla, přejmenování, deaktivace – aby bylo omezeno riziko jejich zneužití.
o K žádné části systému není možné získat přístup s využitím autentizačních informací (hesel, kryptografických klíčů apod.), které není možné změnit. Tj. systém neobsahuje „hardcoded“ hesla, „maintenance backdooor“ apod.
o Hesla systémových, aplikačních, servisních účtů, která nejsou uživatelem rutinně typována, ani přenášena, a hesla k účtům poslední záchrany mohou mít nastavenou expiraci na dobu neurčitou, pokud jsou vytvořena generátorem náhodných hesel nebo jiným bezpečným způsobem, tj. s dostatečnou délkou (alespoň 20 znaků) a obsahující všechny skupiny znaků (malých, velkých písmen, číslic a nealfanumerických znaků).
2.6.2 Patchování
Zadavatel požaduje, aby nabízené IDS díky své konfiguraci a způsobu své správy poskytuje možnost zajistit aplikaci kumulovaného balíku patchů zahrnující celý stack dodávaného IDS, tj. od firmware komponent IDS, přes operační systém, aplikační software IDS, až k programovému vybavení databáze Oracle, ideálně vše bezodstávkově.
Zhotovitel připraví v nejméně čtvrtletních intervalech sadu patchů IDS vycházejících z aktuálního stavu IDS a doporučených patchů výrobce IDS. Zároveň pak objednateli konzultačně pomůže při jejich implementaci.
V případě provozní nutnosti bude možné připravené patche nebo jejich část po konzultaci se
zhotovitelem odebrat.
Zadavatel bude v pravidelných intervalech testovat zranitelnosti v instalovaných programových prostředcích IDS prostřednictvím systému qualys (xxx.xxxxxx.xxx). Zhotovitel při přípravě sady patchů zohlední i výsledky těchto testů, aby po aplikaci patchů byly zvládnuty nalezené zranitelnosti minimálně pro úroveň kritičnosti 4 a 5 z 5ti bodové škály.
Příloha č. 3
POPIS AKCEPTACE A AKCEPTAČNÍ KRITÉRIA
• Akceptační proces bude zahájen na základě oznámení zhotovitele zaslaného objednateli, že je možné zahájit akceptační proces. Proces bude zahájen nejpozději do 3 pracovních dní od odeslání oznámení.
• O akceptačním procesu a jeho výsledku bude sepsán akceptační protokol.
o Akceptační protokol podepisují pověřené osoby dle článku V, odst. 2.
o Akceptační protokol vyhotovuje objednatel.
1. ETAPA PROJEKTU
V rámci této první etapy projektu bude dodaný IDS zkompletován, nainstalován do základního stavu s jednou databází (HOME). Takto nainstalovaný IDS nebude v monitorovacím systému a lozích vykazovat chyby zpracování či poruchy instalovaných HW komponent IDS. Taktéž logy instalovaného operačního systému nebudou vykazovat chyby (varování jsou akceptovatelná).
Na takto implementovaném v IDS v každé instalační lokalitě bude proveden identický výkonnostní test, který dodavatel prováděl v rámci přípravy nabídky.
Věcný popis testu:
Cílem tohoto výkonnostního testu je zjištění počtu věcných transakcí, které lze průměrně kompletně vykonat za 1 minutu (Subject Transactions Per Minute, „STPM“) na předmětném IDS, který zhotovitel nabízí v rámci své nabídky v zadávacím řízení. Žádoucí je co nejvyšší hodnota STPM. Technicky se dokončením věcné transakce rozumí kompletní vykonání předepsaného sledu programových kroků v jazycích SQL a PL/SQL zapouzdřených v databázové proceduře.
Podrobný popis testu je uveden v příloze č. 3a smlouvy.
IDS implementované v první fázi projektu bude akceptováno, pokud budou splněny všechny níže uvedené podmínky.
• IDS je implementováno v souladu s přílohou č. 1 a 8 smlouvy a požadavky na konfiguraci technických prostředků IDS v souladu s přílohou č. 2 (osazení CPU, RAM, diskové kapacity).
• Technické prostředky IDS nevykazují chyby. Logy instalovaného operačního systému nebudou vykazovat chyby (varování jsou akceptovatelná).
• V průběhu realizace výkonnostního testu nebudou v Alert logu databáze Oracle na IDS žádná chybová hlášení.
• Výkonnostní test dosáhne shodného či lepšího výsledku, než který je uveden v čl. I odst.8 smlouvy.
Výkonnostní test může zhotovitel realizovat opakovaně (nejvýše 5x pro každou instalační lokalitu), nejpozději však do lhůty dokončení 1. etapy projektu – viz článek II, odst. 1.
2. ETAPA PROJEKTU
IDS implementované ve druhé fázi projektu bude akceptováno, pokud budou splněny všechny níže uvedené podmínky.
• IDS je implementováno v souladu s přílohou č. 1 a 8 smlouvy a požadavky v souladu s přílohou č. 2.
• Technické prostředky IDS nevykazují chyby. Logy instalovaného operačního systému nebudou vykazovat chyby (varování jsou akceptovatelná).
• Bude úspěšné provedení testů integrace IDS s komponentami systémového prostředí ČNB:
o Zprovoznění komponenty HSM, tj. funkčnost komunikace databázové aplikace
s HSM komponentou n IDS a funkčnost komunikace této komponenty s vlastním
HSM modulem po LAN.
o Funkčnost zálohování databází online i offline a to prostřednictvím zálohovacího systému HP DataProtector 9.07. Media agent DataProtectoru (=obsluha jednotlivých drivů VTL) může být připojen přímo k IDS, ale není to povinné (závisí na technickém návrhu zhotovitele). Každopádně se musí jednat o řešení v souladu
s certifikační maticí HP DataProtector. Z výkonnostního hlediska musí být zajištěna průchodnost tak, aby bylo dosaženo rychlosti zálohování jedné databáze při použití více kanálů (channel) nejméně 1 TB/hod. Celkově musí být propustnost IDS navržena tak, aby bylo možné provést zálohu 80 TB v čase kratším než 48 hodin.
o Funkční NTP
• Bude úspěšné ověření funkčních požadavků, zejména:
o Funkční využití external JAVA (=Java certifikovaná a instalovaná v prostředí operačního systému IDS) z databáze Oracle.
1. Pracovníci objednatele provedou instalace „external JAVA“, pak provedou spuštění skriptu operačního systému z prostředí JAVAy storované/uložené v databázi, test bude spočívat v připojení externí JAVAy do databáze pomocí JDBC driveru.
o Funkční „Bezodstávkové fault-tolerantní řešení“
o Funkční replikace dat mezi objekty (mezi IDS v obou směrech) nejméně pro jednu databázi
o Funkční přepínání zpracování mezi IDS v obou směrech (tedy i „návrat zpět“) nejméně pro jednu databázi
o Funkční přístup do filesystému z databáze
1. Vytvoření Oracle DIRECTORY na vyčleněném filesystému
2. Natažení BLOBu do testovací databáze podle xxxx://xxxxxxxxxxxxxxxxx.xxxx/0000/00/00/xxxxxxx-x-xxxx-xxxx-x-xxxx-xxxxxx- in-oracle/
o Funkční napojení na Oracle Enterprise Manager
o Funkční „Řízení systémových zdrojů“, tj. dynamické přerozdělování zdrojů aplikacím a výkonové izolování skupin aplikací různých tříd.
• Po realizace migrace 3 databází a aktivaci funkcí a služeb IDS v souladu s funkčními požadavky objednatele dle přílohy č. 2 a č. 8 nebudou v Alert logu databáze Oracle na IDS žádná chybová hlášení aspoň po dobu 3 dnů.
Příloha č. 3a
POŽADAVKY NA VÝKONNOSTNÍ TEST
Popis testu
Cílem tohoto testu je zjištění počtu věcných transakcí, které lze průměrně kompletně vykonat za 1 minutu (Subject Transactions Per Minute, STPM) na předmětném IDS. Žádoucí je co nejvyšší hodnota STPM. Technicky se dokončením věcné transakce rozumí kompletní vykonání předepsaného sledu programových kroků v jazycích SQL a PL/SQL zapouzdřených v databázové proceduře.
Prerekvizitou je databáze Oracle 12c Enterprise Edition. Žádné rozšiřující volby (options) nejsou explicitně vyžadovány. Databáze by měla mít k dispozici 20 CPU EE licencí, tj. 40 Intel cores, tj. 80 threads. Primární znaková sada databáze nechť je jednobajtová, doporučuje se EE8ISO8859P2. Při testu může databáze pracovat v NOARCHIVELOG módu a jako autonomní systém (tím se myslí bez synchronizace do záložní lokality). Pro sledování a vyhodnocování činnost databáze je doporučeno použít Oracle Enterprise Manager 12c s pořízenou volbou Diagnostics Pack for Oracle Database.
Do připravené databáze DBA vytvoří tabulkový prostor (tablespace) a uživatele, kterému přidělí předepsaná oprávnění. Při své činnosti se DBA řídí postupem uvedeným v příloze č. 3a.1. Připravenou databázi DBA předá Testerovi, který potupně vytvoří datové struktury, procedury a funkce. Tímto krokem je příprava testu dokončena. Při své činnosti se Xxxxxx řídí postupem uvedeným v příloze č. 3a.2.
Vlastní test sestává ze dvou samostatných částí, kde každá je zakončena vytvořením textového reportu, který dokumentuje její průběh a výsledek. Tyto dva reporty jsou očekávány jako příloha uchazečovy nabídky.
První část testu je pomocná a její reportovaný výsledek není předmětem vyhodnocení. V této části testu jsou vygenerována pseudonáhodná data do číselníkové tabulky. Jde o strukturu složenou z celočíselného primárního klíče, dále pak unikátního klíče, který je generován jako řetězec náhodné délky v rozmezí 16 až 32 znaků, a nakonec ještě popisu, který je generován jako řetězec náhodné délky v rozmezí 1000 až 4000 znaků. Tabulka je plněna z 0 na 20 milionů záznamů pomocí paralelních plánovaných úloh. Očekává se, že uchazeč v tomto kole dosáhne alespoň času (result _eta_avg) 01:26:57, respektive rychlosti 230000 (result_rows_per_minute). Uvedené hodnoty jsou součástí výstupního reportu. Při své činnosti se Xxxxxx řídí postupem uvedeným v příloze č. 3a.3.
Druhá část testu slouží ke stanovení hodnoty STPM, která je předmětem vyhodnocení. V této části testu jsou pak pseudonáhodně vylosovány množiny po dvaatřiceti klíčích z připraveného číselníku. Kompletní obsah každého z těchto 32 záznamů je načten do věty a tato věta je pak uložena do cílové tabulky. Každá cílová věta představuje jednu věcnou transakci (Subject Transaction, ST). Cílová tabulka je plněna z 0 na 5 milionů záznamů pomocí paralelních plánovaných úloh. Očekává se, že uchazeč v tomto kole dosáhne alespoň času (result _eta_avg) 00:14:17, respektive rychlosti 350000 (result_rows_per_minute). Uvedené hodnoty jsou součástí výstupního reportu. Při své činnosti se Xxxxxx řídí postupem uvedeným v příloze č. 3a.4.
Obě části testu mají určenou shodnou metodu provádění. Metoda nemá ambici být obecně optimální. Nejprve je postupně spuštěn požadovaný počet plánovaných úloh - ovšem tak, aby žádná nepřistoupila k vlastnímu výkonu, dokud nebudou aktivní všechny. Pak, jakmile očekávaná situace nastane, prakticky synchronně (přesněji běhen jedné sekundy), všechny úlohy svoji činnost zahájí. Skutečný počet plánovaných úloh (PPÚ) je pro první část testu striktně stanoven na 80. Vysvětlení, proč byla stanovena právě tato hodnota, je uvedeno na
konci následujícího odstavce. Pro druhou část testu není PPÚ nijak omezen. Uchazeč může PPÚ změnit pomocí hodnoty parametru degree-of-parallelism v tabulce PT.SP. Výchozí hodnota tohoto parametru je při instalaci odvozena a nastavena jako prostý součin databázových parametrů cpu_count a parallel_threads_per_cpu.
Pro zaručení shodného datového obsahu pro všechny uchazeče byl pro vytvoření tohoto obsahu použit generátor pseudonáhodných hodnot (normální rozložení pravděpodobnosti), který každou výstupní hodnotu odvozuje ze základního prvku posloupnosti, tzv. „semínka“, a to algoritmicky. Použití shodného „semínka“ pak zaručuje vytvoření shodné posloupnosti. Aby byla tato nutná podmínka splněna, byl pro první část testu pevně stanoven počet a hodnoty všech „semínek“.
Test má být realizován na IDS ve stejné nebo výkonnostně rovnocenné konfiguraci, která bude případně dodávána do ČNB.
Příloha č. 3a.1 – Systémová příprava prostředí (provádí DBA pomocí SQL*Plus)
1. Předpoklady
Splnění předpokladů uvedených v kapitole Popis testu. Viz výše.
2. Příprava prostředí
Poznámka č. 1: DBA bude provádět přidělení oprávnění na objekty uživatele SYS (viz odstavec č. 6 dále). K ověření přístupu na tyto objekty je třeba ověřit, že databázový parametr O7_DICTIONARY_ACCESSIBILITY je nastaven na hodnotu TRUE. Celý příkaz je případně zde: ALTER SYSTEM SET O7_DICTIONARY_ACCESSIBILITY=TRUE SCOPE=SPFILE;. K promítnutí
změny nastavení do databáze je pak třeba instanci restartovat.
Poznámka č. 2: DBA by měl překontrolovat hodnoty parametrů processes a job_queue_processes. Aby byl průběh testu korektní, MUSÍ být hodnota těchto parametrů pro první část testu větší nebo rovna 80 a pro druhou pak větší nebo rovna součinu parametrů cpu_count a parallel_threads_per_cpu. K získání optimálního výkonu se ovšem doporučuje tyto parametry nastavit na hodnotu 1000 a větší.
set serveroutput on size unl;
set lin 1200
set pages 2000
set trim on
Poznámka č. 3: DBA by měl rovněž překontrolovat, že databáze má k dispozici alespoň 64GB RAM. Nastavení memory_max_target i memory _target lze ponechat výchozí.
3. Nastavení parametrů tabulkového prostoru (TBS)
1. Název PT_DATA.
2. Velikost 1000 GB.
3. Absolutní cesta k umístění datových souborů (zakončená oddělovačem dle OS).
def p_nm=PT_DATA
def p_sz=1000
def p_ph=/{doplňte}/
4. Vygenerování DDL pro TBS
declare
p_nm dba_tablespaces.tablespace_name%type:='&p_nm.';
p_sz number(4):='&p_sz.'; -- size in GB
p_ph varchar2(1024):='&p_ph'; -- data file path
XBPFD constant number(7):=4194303; -- max blocks per data file
dfd varchar2(32767); -- data files definitions
nof number(4); -- number of data files
begin
xsz number(24); -- max size of one data file
select ceil(p_sz*1024*1024*1024/(to_number(value)*XBPFD))
, to_number(value)*XBPFD
into nof, xsz
from sys.gv_$parameter where name='db_block_size';
for i in 1..nof loop
dfd:=dfd||chr(13)||chr(10)
||case i when 1 then ' ' else ',' end||' '''||p_ph||p_nm||'_'
end loop;
||lpad(i, ceil(log(10, nof+1)), '0')||'.dbf'' size '||xsz;
create tablespace '||p_nm||' datafile'||dfd||'
dbms_output.put_line('
default compress;');
exception when others then
dbms_output.put_line(dbms_utility.format_error_stack||chr(13)||chr(10)
||dbms_utility.format_error_backtrace);
end;
/
5. Spuštění DDL pro TBS – vytvoření TBS PT_DATA
create user PT identified by "Xxxxxxx-xxx-Xxxxxx*1570796327"
default tablespace PT_data
temporary tablespace temp
quota unlimited on PT_data;
grant select_catalog_role to PT;
grant create session to PT;
grant create procedure to PT;
grant create table to PT;
xxxxx execute on dbms_lock to PT;
xxxxx execute on dbms_job to PT;
6. Vytvoření účtu uživatele PT včetně oprávnění Účet PT bude pro svoji práci používat Tester.
Konec přílohy, postupujte k příloze č. 3a.2.
Příloha č. 3a.2 - Aplikační příprava prostředí (provádí Tester pomocí SQL*Plus)
1. Předpoklady
Dokončení postupu dle přílohy č. 3a.1.
2. Příprava prostředí
set serveroutput on size unl;
set lin 100
set pages 1000
set trim on
alter session set nls_territory="CZECH REPUBLIC";
alter session set nls_language=ENGLISH;
alter session set nls_numeric_characters='.,';
alter session set nls_date_format='yyyy-mm-dd+hh24:mi:ss';
set role all;
Tester se do databáze připojí pod účtem uživatele PT.
3. Instalace datových struktur
-- standard library - properties create table sp
(id varchar2(64 byte) constraint nn_sp not null
,vs varchar2(64 byte) constraint nn_sp_vs not null
,constraint pk_sp primary key (id)
);
comment on table sp is 'standard library - properties'; comment on column xx.xx is 'identifier';
comment on column sp.vs is 'value as string';
-- standard library - log create table sl
(tm date default on null sysdate
,gr varchar2(64 byte) constraint nn_sl_gr not null
,tx varchar2(512 byte) constraint nn_sl_tx not null
);
comment on table sl is 'standard library - log'; comment on column xx.xx is 'date/time';
comment on column xx.xx is 'group'; comment on column sl.tx is 'text';
-- code list create table c0
(ii number(12) constraint nn_c0 not null
,id varchar2(32 byte) constraint nn_c0_id not null
,ds varchar2(4000 byte) constraint nn_c0_ds not null
,constraint pk_c0 primary key (ii)
,constraint uk_c0_id unique (id)
);
comment on table c0 is 'code list No. 0';
comment on column c0.ii is 'internal identifier'; comment on column x0.xx is 'internal';
comment on column c0.ds is 'description';
-- report
create table r32
(ii number(12) constraint nn_r32 not null
,c0 01 number(12),c0_id_01 varchar2(32),c0_ds_01 varchar2(4000)
,c0 02 number(12),c0_id_02 varchar2(32),c0_ds_02 varchar2(4000)
,c0 03 number(12),c0_id_03 varchar2(32),c0_ds_03 varchar2(4000)
,c0 04 number(12),c0_id_04 varchar2(32),c0_ds_04 varchar2(4000)
,c0 05 number(12),c0_id_05 varchar2(32),c0_ds_05 varchar2(4000)
,c0 06 number(12),c0_id_06 varchar2(32),c0_ds_06 varchar2(4000)
,c0 07 number(12),c0_id_07 varchar2(32),c0_ds_07 varchar2(4000)
,c0 08 number(12),c0_id_08 varchar2(32),c0_ds_08 varchar2(4000)
,c0 09 number(12),c0_id_09 varchar2(32),c0_ds_09 varchar2(4000)
,c0 10 number(12),c0_id_10 varchar2(32),c0_ds_10 varchar2(4000)
,c0 11 number(12),c0_id_11 varchar2(32),c0_ds_11 varchar2(4000)
,c0 12 number(12),c0_id_12 varchar2(32),c0_ds_12 varchar2(4000)
,c0 13 number(12),c0_id_13 varchar2(32),c0_ds_13 varchar2(4000)
,c0 14 number(12),c0_id_14 varchar2(32),c0_ds_14 varchar2(4000)
,c0 15 number(12),c0_id_15 varchar2(32),c0_ds_15 varchar2(4000)
,c0 16 number(12),c0_id_16 varchar2(32),c0_ds_16 varchar2(4000)
,c0 17 number(12),c0_id_17 varchar2(32),c0_ds_17 varchar2(4000)
,c0 18 number(12),c0_id_18 varchar2(32),c0_ds_18 varchar2(4000)
,c0 19 number(12),c0_id_19 varchar2(32),c0_ds_19 varchar2(4000)
,c0 20 number(12),c0_id_20 varchar2(32),c0_ds_20 varchar2(4000)
,c0 21 number(12),c0_id_21 varchar2(32),c0_ds_21 varchar2(4000)
,c0 22 number(12),c0_id_22 varchar2(32),c0_ds_22 varchar2(4000)
,c0 23 number(12),c0_id_23 varchar2(32),c0_ds_23 varchar2(4000)
,c0 24 number(12),c0_id_24 varchar2(32),c0_ds_24 varchar2(4000)
,c0 25 number(12),c0_id_25 varchar2(32),c0_ds_25 varchar2(4000)
,c0 26 number(12),c0_id_26 varchar2(32),c0_ds_26 varchar2(4000)
,c0 27 number(12),c0_id_27 varchar2(32),c0_ds_27 varchar2(4000)
,c0 28 number(12),c0_id_28 varchar2(32),c0_ds_28 varchar2(4000)
,c0 29 number(12),c0_id_29 varchar2(32),c0_ds_29 varchar2(4000)
,c0 30 number(12),c0_id_30 varchar2(32),c0_ds_30 varchar2(4000)
,c0 31 number(12),c0_id_31 varchar2(32),c0_ds_31 varchar2(4000)
,c0 32 number(12),c0_id_32 varchar2(32),c0_ds_32 varchar2(4000)
,constraint pk_r32 primary key (ii)
);
comment on table r32 is 'report with 32 times joined code list c0'; comment on column r32.c0 01 is '[code list No. 0]';
comment on column r32.c0_id_01 is '[code list No. 0].identifier'; comment on column r32.c0_ds_01 is '[code list No. 0].description'; comment on column r32.c0 02 is '[code list No. 0]';
comment on column r32.c0_id_02 is '[code list No. 0].identifier'; comment on column r32.c0_ds_02 is '[code list No. 0].description'; comment on column r32.c0 03 is '[code list No. 0]';
comment on column r32.c0_id_03 is '[code list No. 0].identifier'; comment on column r32.c0_ds_03 is '[code list No. 0].description'; comment on column r32.c0 04 is '[code list No. 0]';
comment on column r32.c0_id_04 is '[code list No. 0].identifier'; comment on column r32.c0_ds_04 is '[code list No. 0].description'; comment on column r32.c0 05 is '[code list No. 0]';
comment on column r32.c0_id_05 is '[code list No. 0].identifier'; comment on column r32.c0_ds_05 is '[code list No. 0].description'; comment on column r32.c0 06 is '[code list No. 0]';
comment on column r32.c0_id_06 is '[code list No. 0].identifier'; comment on column r32.c0_ds_06 is '[code list No. 0].description'; comment on column r32.c0 07 is '[code list No. 0]';
comment on column r32.c0_id_07 is '[code list No. 0].identifier'; comment on column r32.c0_ds_07 is '[code list No. 0].description'; comment on column r32.c0 08 is '[code list No. 0]';
comment on column r32.c0_id_08 is '[code list No. 0].identifier'; comment on column r32.c0_ds_08 is '[code list No. 0].description'; comment on column r32.c0 09 is '[code list No. 0]';
comment on column r32.c0_id_09 is '[code list No. 0].identifier'; comment on column r32.c0_ds_09 is '[code list No. 0].description'; comment on column r32.c0 10 is '[code list No. 0]';
comment on column r32.c0_id_10 is '[code list No. 0].identifier'; comment on column r32.c0_ds_10 is '[code list No. 0].description'; comment on column r32.c0 11 is '[code list No. 0]';
comment on column r32.c0_id_11 is '[code list No. 0].identifier'; comment on column r32.c0_ds_11 is '[code list No. 0].description'; comment on column r32.c0 12 is '[code list No. 0]';
comment on column r32.c0_id_12 is '[code list No. 0].identifier'; comment on column r32.c0_ds_12 is '[code list No. 0].description'; comment on column r32.c0 13 is '[code list No. 0]';
comment on column r32.c0_id_13 is '[code list No. 0].identifier'; comment on column r32.c0_ds_13 is '[code list No. 0].description'; comment on column r32.c0 14 is '[code list No. 0]';
comment on column r32.c0_id_14 is '[code list No. 0].identifier'; comment on column r32.c0_ds_14 is '[code list No. 0].description'; comment on column r32.c0 15 is '[code list No. 0]';
comment on column r32.c0_id_15 is '[code list No. 0].identifier'; comment on column r32.c0_ds_15 is '[code list No. 0].description'; comment on column r32.c0 16 is '[code list No. 0]';
comment on column r32.c0_id_16 is '[code list No. 0].identifier'; comment on column r32.c0_ds_16 is '[code list No. 0].description'; comment on column r32.c0 17 is '[code list No. 0]';
comment on column r32.c0_id_17 is '[code list No. 0].identifier'; comment on column r32.c0_ds_17 is '[code list No. 0].description'; comment on column r32.c0 18 is '[code list No. 0]';
comment on column r32.c0_id_18 is '[code list No. 0].identifier'; comment on column r32.c0_ds_18 is '[code list No. 0].description'; comment on column r32.c0 19 is '[code list No. 0]';
comment on column r32.c0_id_19 is '[code list No. 0].identifier'; comment on column r32.c0_ds_19 is '[code list No. 0].description'; comment on column r32.c0 20 is '[code list No. 0]';
comment on column r32.c0_id_20 is '[code list No. 0].identifier'; comment on column r32.c0_ds_20 is '[code list No. 0].description'; comment on column r32.c0 21 is '[code list No. 0]';
comment on column r32.c0_id_21 is '[code list No. 0].identifier'; comment on column r32.c0_ds_21 is '[code list No. 0].description'; comment on column r32.c0 22 is '[code list No. 0]';
comment on column r32.c0_id_22 is '[code list No. 0].identifier'; comment on column r32.c0_ds_22 is '[code list No. 0].description'; comment on column r32.c0 23 is '[code list No. 0]';
comment on column r32.c0_id_23 is '[code list No. 0].identifier'; comment on column r32.c0_ds_23 is '[code list No. 0].description'; comment on column r32.c0 24 is '[code list No. 0]';
comment on column r32.c0_id_24 is '[code list No. 0].identifier'; comment on column r32.c0_ds_24 is '[code list No. 0].description'; comment on column r32.c0 25 is '[code list No. 0]';
comment on column r32.c0_id_25 is '[code list No. 0].identifier'; comment on column r32.c0_ds_25 is '[code list No. 0].description'; comment on column r32.c0 26 is '[code list No. 0]';
comment on column r32.c0_id_26 is '[code list No. 0].identifier'; comment on column r32.c0_ds_26 is '[code list No. 0].description'; comment on column r32.c0 27 is '[code list No. 0]';
comment on column r32.c0_id_27 is '[code list No. 0].identifier'; comment on column r32.c0_ds_27 is '[code list No. 0].description'; comment on column r32.c0 28 is '[code list No. 0]';
comment on column r32.c0_id_28 is '[code list No. 0].identifier'; comment on column r32.c0_ds_28 is '[code list No. 0].description'; comment on column r32.c0 29 is '[code list No. 0]';
comment on column r32.c0_id_29 is '[code list No. 0].identifier'; comment on column r32.c0_ds_29 is '[code list No. 0].description'; comment on column r32.c0 30 is '[code list No. 0]';
comment on column r32.c0_id_30 is '[code list No. 0].identifier'; comment on column r32.c0_ds_30 is '[code list No. 0].description'; comment on column r32.c0 31 is '[code list No. 0]';
comment on column r32.c0_id_31 is '[code list No. 0].identifier'; comment on column r32.c0_ds_31 is '[code list No. 0].description'; comment on column r32.c0 32 is '[code list No. 0]';
comment on column r32.c0_id_32 is '[code list No. 0].identifier'; comment on column r32.c0_ds_32 is '[code list No. 0].description';
4. Instalace programových jednotek
-- standard library - get property
create or replace function spget(
) p_id xx.xx%type
return sp.vs%type is
begin select vs into vs from sp where id=p_id; return vs;
vs sp.vs%type;
exception when no_data_found then return null; end;
/
-- standard library - set property
create or replace procedure spset(
, p_id xx.xx%type
) p_vs sp.vs%type
Begin
is
update sp set vs=p_vs where id=p_id;
if sql%rowcount=0 then insert into sp values (p_id, p_vs); end if;
end;
/
-- standard library - logger create or replace procedure slwr(
p_gr xx.xx%type
, p_tx sl.tx%type
) is
pragma autonomous_transaction;
begin insert into sl (gr, tx) values (p_gr, p_tx); commit; exception when others then rollback; raise;end;
/
-- parking brake activity detector create or replace procedure pb(
p_id xx.xx%type -- title
) is begin
if spget(p_id)='Y' then
raise_application_error(-20001, 'Parking brake has applied.'); end if;
end;
/
-- pseudo-random string generator create or replace function rndstr(
p_l number -- min length
, p_h number -- max length
) return char is begin
return dbms_random.string('x', round(dbms_random.value(p_l, p_h))); end;
/
-- start synchronizator
create or replace procedure ssync( p_id xx.xx%type
) is begin
update sp set vs=vs-1 where id=p_id; commit;
while spget(p_id)>0 loop dbms_lock.sleep(1); end loop; end;
/
-- code list filler
create or replace procedure clf(
p_sx char -- sufix of table name "c" 0..7
, p_sd number -- seed for pseudo-random generator
, p_ii number -- last used internal id
, p_nob number -- number of batchs
, p_sob number -- size of one batch
) is
GR constant xx.xx%type:=$$PLSQL_UNIT||'('||p_sx||','||p_sd||','||p_ii||','
||p_nob||','||p_sob||')'; ii number(12):=p_ii;
tt xx.xx%type:='code-list-filler-'; -- title begin
ssync(tt||'ssync'); dbms_random.seed(p_sd); slwr(GR||'000000', 'job-start'); for i in 1..p_nob loop
pb(tt||'pb');
slwr(GR||lpad(i,6,'0'), 'batch-start'); execute immediate '
declare
type t_c is table of c'||p_sx||'%rowtype index by pls_integer; c t_c;
ii number(12):=:1; begin
for i in 1..'||p_sob||' loop ii:=ii+1; c(i).ii:=ii;
c(i).id:=rndstr(16, 32); c(i).ds:=rndstr(100, 4000); end loop;
forall i in 1..'||p_sob||'
insert into c'||p_sx||' values c(i); commit;
:1:=ii;
end;' using in out ii; slwr(GR||lpad(i,6,'0'), 'batch-stop');
end loop;
slwr(GR||'000000', 'job-stop'); dbms_random.terminate;
exception when others then slwr(GR||' ex'
, dbms_utility.format_error_stack||chr(13)||chr(10)
||dbms_utility.format_error_backtrace); dbms_random.terminate;
end;
/
-- code list fillers starter create or replace procedure clfs(
p_sx char -- sufix of table name "c" 0..7
, p_sd number -- seed base number
, p_nob number -- number of batchs
, p_sob number -- size of one batch
) is
DOP constant number(6):=80; -- NO MODIFY! -- spget('degree-of-parallelism'); GR constant xx.xx%type:=$$PLSQL_UNIT||'('||p_sx||','||p_sd||','||p_nob||','
||p_sob||')';
ii c0.ii%type:=0;
j user_jobs.job%type;
nob number(9):=0; -- number of batchs
nrb number(4):=mod(p_nob, DOP); -- number of remain batchs nwb number(9):=floor(p_nob/DOP); -- number of whole batchs sd number:=p_sd; -- seed for pseudo-random generator
tt xx.xx%type:='code-list-filler-'; -- title what varchar2(100);
begin
execute immediate 'truncate table c'||p_sx; spset(tt||'ssync', DOP);
spset(tt||'ref-date', sysdate); spset(tt||'num-of-rows', p_nob*p_sob); commit;
for i in 0..DOP-1 loop sd:=round(sd/power(2, 1/7)); ii:=ii+nob*p_sob;
nob:=nwb+case when i<nrb then 1 else 0 end; what:='clf('||p_sx||','||sd||','||ii||','||nob||','||p_sob||');'; j:=spget(tt||'job-no-'||i);
if j is null then
dbms_job.submit(j, what, xxxxxxx, 'to_date(''4000-01-01'')'); spset(tt||'job-no-'||i, j);
else
dbms_job.what(j, what); dbms_xxx.xxxx_date(j, xxxxxxx);
end if; commit; end loop;
exception when others then slwr(GR||' ex'
, dbms_utility.format_error_stack||chr(13)||chr(10)
||dbms_utility.format_error_backtrace); end;
/
-- report filler
create or replace procedure rf(
p_cc number -- number of rows in code list table "c0"
, p_sd number -- seed for pseudo-random generator
, p_ii number -- last used internal id
, p_nob number -- number of batchs
, p_sob number -- size of one batch
) is
GR constant xx.xx%type:=$$PLSQL_UNIT||'('||p_cc||','||p_sd||','||p_ii||','
||p_nob||','||p_sob||')';
type t_r is table of PT.r32%rowtype index by pls_integer; ii number(12):=p_ii;
r t_r;
tt xx.xx%type:='report-filler-'; -- title begin
ssync(tt||'ssync'); dbms_random.seed(p_sd); slwr(GR||'000000', 'job-start'); for j in 1..p_nob loop
pb(tt||'pb');
slwr(GR||lpad(j,6,'0'), 'batch-start'); for i in 1..p_sob loop
ii:=ii+1; r(i).ii:=ii; select ii, id, ds
into r(i).c0 01, r(i).c0_id_01, r(i).c0_ds_01
from c0 where ii=round(dbms_random.value(1, p_cc)); select ii, id, ds
into r(i).c0 02, r(i).c0_id_02, r(i).c0_ds_02
from c0 where ii=round(dbms_random.value(1, p_cc)); select ii, id, ds
into r(i).c0 03, r(i).c0_id_03, r(i).c0_ds_03
from c0 where ii=round(dbms_random.value(1, p_cc)); select ii, id, ds
into r(i).c0 04, r(i).c0_id_04, r(i).c0_ds_04
from c0 where ii=round(dbms_random.value(1, p_cc)); select ii, id, ds
into r(i).c0 05, r(i).c0_id_05, r(i).c0_ds_05
from c0 where ii=round(dbms_random.value(1, p_cc)); select ii, id, ds
into r(i).c0 06, r(i).c0_id_06, r(i).c0_ds_06
from c0 where ii=round(dbms_random.value(1, p_cc)); select ii, id, ds
into r(i).c0 07, r(i).c0_id_07, r(i).c0_ds_07
from c0 where ii=round(dbms_random.value(1, p_cc)); select ii, id, ds
into r(i).c0 08, r(i).c0_id_08, r(i).c0_ds_08
from c0 where ii=round(dbms_random.value(1, p_cc)); select ii, id, ds
into r(i).c0 09, r(i).c0_id_09, r(i).c0_ds_09
from c0 where ii=round(dbms_random.value(1, p_cc)); select ii, id, ds
into r(i).c0 10, r(i).c0_id_10, r(i).c0_ds_10
from c0 where ii=round(dbms_random.value(1, p_cc)); select ii, id, ds
into r(i).c0 11, r(i).c0_id_11, r(i).c0_ds_11
from c0 where ii=round(dbms_random.value(1, p_cc)); select ii, id, ds
into r(i).c0 12, r(i).c0_id_12, r(i).c0_ds_12
from c0 where ii=round(dbms_random.value(1, p_cc)); select ii, id, ds
into r(i).c0 13, r(i).c0_id_13, r(i).c0_ds_13
from c0 where ii=round(dbms_random.value(1, p_cc)); select ii, id, ds
into r(i).c0 14, r(i).c0_id_14, r(i).c0_ds_14
from c0 where ii=round(dbms_random.value(1, p_cc)); select ii, id, ds
into r(i).c0 15, r(i).c0_id_15, r(i).c0_ds_15
from c0 where ii=round(dbms_random.value(1, p_cc)); select ii, id, ds
into r(i).c0 16, r(i).c0_id_16, r(i).c0_ds_16
from c0 where ii=round(dbms_random.value(1, p_cc)); select ii, id, ds
into r(i).c0 17, r(i).c0_id_17, r(i).c0_ds_17
from c0 where ii=round(dbms_random.value(1, p_cc)); select ii, id, ds
into r(i).c0 18, r(i).c0_id_18, r(i).c0_ds_18
from c0 where ii=round(dbms_random.value(1, p_cc)); select ii, id, ds
into r(i).c0 19, r(i).c0_id_19, r(i).c0_ds_19
from c0 where ii=round(dbms_random.value(1, p_cc)); select ii, id, ds
into r(i).c0 20, r(i).c0_id_20, r(i).c0_ds_20
from c0 where ii=round(dbms_random.value(1, p_cc)); select ii, id, ds
into r(i).c0 21, r(i).c0_id_21, r(i).c0_ds_21
from c0 where ii=round(dbms_random.value(1, p_cc)); select ii, id, ds
into r(i).c0 22, r(i).c0_id_22, r(i).c0_ds_22
from c0 where ii=round(dbms_random.value(1, p_cc)); select ii, id, ds
into r(i).c0 23, r(i).c0_id_23, r(i).c0_ds_23
from c0 where ii=round(dbms_random.value(1, p_cc)); select ii, id, ds
into r(i).c0 24, r(i).c0_id_24, r(i).c0_ds_24
from c0 where ii=round(dbms_random.value(1, p_cc)); select ii, id, ds
into r(i).c0 25, r(i).c0_id_25, r(i).c0_ds_25 from c0 where ii=round(dbms_random.value(1, p_cc)); select ii, id, ds
into r(i).c0 26, r(i).c0_id_26, r(i).c0_ds_26
from c0 where ii=round(dbms_random.value(1, p_cc)); select ii, id, ds
into r(i).c0 27, r(i).c0_id_27, r(i).c0_ds_27 from c0 where ii=round(dbms_random.value(1, p_cc)); select ii, id, ds
into r(i).c0 28, r(i).c0_id_28, r(i).c0_ds_28
from c0 where ii=round(dbms_random.value(1, p_cc)); select ii, id, ds
into r(i).c0 29, r(i).c0_id_29, r(i).c0_ds_29
from c0 where ii=round(dbms_random.value(1, p_cc)); select ii, id, ds
into r(i).c0 30, r(i).c0_id_30, r(i).c0_ds_30
from c0 where ii=round(dbms_random.value(1, p_cc)); select ii, id, ds
into r(i).c0 31, r(i).c0_id_31, r(i).c0_ds_31
from c0 where ii=round(dbms_random.value(1, p_cc)); select ii, id, ds
into r(i).c0 32, r(i).c0_id_32, r(i).c0_ds_32
from c0 where ii=round(dbms_random.value(1, p_cc)); end loop;
forall i in 1..p_sob
insert into r32 values r(i); commit;
slwr(GR||lpad(j,6,'0'), 'batch-stop'); end loop;
slwr(GR||'000000', 'job-stop'); dbms_random.terminate;
exception when others then slwr(GR||' ex'
, dbms_utility.format_error_stack||chr(13)||chr(10)
||dbms_utility.format_error_backtrace); dbms_random.terminate;
end;
/
-- report fillers starter
create or replace procedure rfs(
p_cc number -- number of rows in code list table "c0"
, p_sd number -- seed base number
, p_nob number -- number of batchs
, p_sob number -- size of one batch
) is
DOP constant number(6):=spget('degree-of-parallelism');
GR constant xx.xx%type:=$$PLSQL_UNIT||'('||p_cc||','||p_sd||','
||p_nob||','||p_sob||')'; ii r32.ii%type:=0;
j user_jobs.job%type;
nob number(9):=0; -- number of batchs
nrb number(4):=mod(p_nob, DOP); -- number of remain batchs nwb number(9):=floor(p_nob/DOP); -- number of whole batchs sd number:=p_sd; -- seed for pseudo-random generator
tt xx.xx%type:='report-filler-'; -- title what varchar2(100);
begin
execute immediate 'truncate table r32'; spset(tt||'ssync', DOP);
spset(tt||'ref-date', sysdate); spset(tt||'num-of-rows', p_nob*p_sob); commit;
for i in 0..DOP-1 loop sd:=round(sd/power(2, 1/7)); ii:=ii+nob*p_sob;
nob:=nwb+case when i<nrb then 1 else 0 end; what:='rf('||p_cc||','||sd||','||ii||','||nob||','||p_sob||');'; j:=spget(tt||'job-no-'||i);
if j is null then
dbms_job.submit(j, what, xxxxxxx, 'to_date(''4000-01-01'')'); spset(tt||'job-no-'||i, j);
else
dbms_job.what(j, what); dbms_xxx.xxxx_date(j, xxxxxxx);
end if; commit; end loop;
exception when others then slwr(GR||' ex'
, dbms_utility.format_error_stack||chr(13)||chr(10)
||dbms_utility.format_error_backtrace); end;
/
5. Inicializace dat
-- standard library – properties – default degree-of-parallelism
insert into sp
select 'degree-of-parallelism', cpu*thrd dop from
, (select value cpu from sys.v_$parameter where name='cpu_count')
( select value thrd from sys.v_$parameter
insert into sp values ('code-list-filler-pb', 'N');
where name='parallel_threads_per_cpu');
insert into sp values ('report-filler-pb', 'N');
commit;
6. Parametrizace plánovaných úloh (volitelně)
Skutečný počet plánovaných úloh (PPÚ) je pro první část testu striktně stanoven na 80. Vysvětlení, proč byla stanovena právě tato hodnota, je uvedeno na konci následujícího odstavce. Pro druhou část testu není PPÚ nijak omezen. Uchazeč může PPÚ změnit pomocí hodnoty parametru degree-of-parallelism v tabulce PT.SP jak je naznačeno v ukázce skriptu na konci tohoto odstavce. Výchozí hodnota tohoto parametru je při instalaci odvozena a nastavena jako prostý součin databázových parametrů cpu_count a parallel_threads_per_cpu.
Pro zaručení shodného datového obsahu pro všechny uchazeče byl k vytvoření tohoto obsahu použit generátor pseudonáhodných hodnot (normální rozložení pravděpodobnosti), který každou výstupní hodnotu odvozuje ze základního prvku posloupnosti, tzv. „semínka", a to algoritmicky. Použití shodného „semínka" pak zaručuje vytvoření shodné posloupnosti. Aby byla tato nutná podmínka splněna, byl pro první část testu pevně stanoven počet a hodnoty všech „semínek“.
col name for a30 col value for a5
select name, value from sys.v_$parameter
where name='cpu_count' union all
select name, value from sys.v_$parameter
where name='parallel_threads_per_cpu' union all
select id, vs from PT.sp where id='degree-of-parallelism';
7. Konec přílohy, postupujte k příloze č. 3a.3.
Příloha č. 3a.3 – První část testu (provádí Tester pomocí SQL*Plus)
1. Předpoklady
Dokončení postupu dle přílohy č. 3a.2.
2. Příprava prostředí
Použijte pokyny uvedené v příloze č. 3a.2, odstavec č. 2.
3. Kontrola parametrizace
Pro tuto část testu nelze nastavení měnit. Podrobnosti viz příloha č. 3a.2, odstavec č. 6.
4. Spuštění první části testu (dále jen test)
Spustíme program, který zajistí vytvoření/naplánování úloh. Uvedené argumenty a jejich hodnoty jsou povinné.
1. Sufix jména číselníku cx, tedy 0 = c0.
2. Báze pro dělení čísel užívaných jako „semínko“ pro generátor pseudonáhodných čísel.
3. Počet dávek – celkový počet řádek / velikost dávky.
4. Velikost dávky – celkový počet řádek / počet dávek.
exec clfs(0, 1570796327, 2000, 10000);
Součin 3. a 4. argumentu definuje celkový počet řádek – zde 2000 * 10000 = 20 milionů.
5. Sledování průběhu testu (volitelně)
col gr for a40
col tx for a20
select * from (
select * from sl
where tm>=(
select to_date(vs) rd from sp
where rownum<20;
) order by tm desc
) where id='code-list-filler-ref-date'
Průběh testu lze sledovat pomocí dotazů do tabulky XX.XX.
6. Detekce ukončení zpracování testu – dokončení všech plánovaných úloh
col running for 999999
select count(*) running from user_jobs
where what like 'clf(0,%' and this_date is not null;
Ukončení testu můžeme nejlépe detekovat pomocí dotazu do pohledu USER_JOBS, kde musí být ukončeny všechny úlohy obsahující v názvu (WHAT) znaky „clf(0,“:
RUNNING
0
Po ukončení všech úloh musí výpis vypadat takto:
7. Sběr statistik
slwr('stats(PT,C0)', 'stop');
dbms_stats.gather_table_stats('PT','C0');
slwr('stats(PT,C0)', 'start');
begin
Upozornění: Tento krok je možno zahájit pouze v případě, že jsou všechny plánované úlohy již bezpečně ukončeny. V opačném případě může dojít k zneplatnění výsledků celého testu!
end;
/
8. Výstupní report první části testu
Výstup bude zapsán do textového souboru rr-1.txt. Obsah tohoto souboru přiložte k nabídce.
set newp none set echo off set feed off set ver off
set mark html off spool off set lin 100
set pages 100 set trim on set trims on
alter session set nls_territory="CZECH REPUBLIC"; alter session set nls_language=ENGLISH;
alter session set nls_numeric_characters='.,';
alter session set nls_date_format='yyyy-mm-dd+hh24:mi:ss'; set role all;
--
col name for a32 col value for a20
--
spool rr-1.txt
prompt prompt
prompt First Test Phase Results prompt
prompt
with qn as (
select tm, rd, tm-rd sp from sl
, (select to_date(vs) rd from sp where id='code-list-filler-ref-date') where tm>=rd and gr like 'CLF(0%' and tx='job-start'
), qx as (
select tm, rd, tm-rd sp from sl
, (select to_date(vs) rd from sp where id='code-list-filler-ref-date')
) where tm>=rd and gr like 'CLF(0%' and tx='job-stop'
select * from (
select 'job_count' name, to_char(count(*)) value from qn union all select 'job_start_first', to_char(min(tm)) value from qn union all select 'job_start_last', to_char(max(tm)) from qn union all
select 'job_start_avg', to_char(min(rd)+avg(sp)) from qn union all select 'job_stop_first', to_char(min(tm)) value from qx union all select 'job_stop_last', to_char(max(tm)) from qx union all
select 'job_stop_avg', to_char(min(rd)+avg(sp)) from qx union all select 'result_required_rows', vs from sp
where id='code-list-filler-num-of-rows' union all
select 'result_eta_avg', regexp_substr(numtodsinterval(avg(qx.sp)-avg(qn.sp), 'day') , '[0-9] [0-9:]{8}') from qn, qx union all
select 'result_rows_per_minute', to_char(round(nor/(24*60*(x-n)))) from (select avg(sp) n from qn )
, (select avg(sp) x from qx )
, ( select to_number(vs) nor from sp
where id='code-list-filler-num-of-rows') union all select 'stats_start' name, to_char(min(tm)) value from sl
, (select to_date(vs) rd from sp where id='code-list-filler-ref-date') where tm>rd and gr='stats(PT,C0)' and tx='start' union all
select 'stats_stop', to_char(max(tm)) from sl
, (select to_date(vs) rd from sp where id='code-list-filler-ref-date') where tm>rd and gr='stats(PT,C0)' and tx='stop' union all
select 'stats_num_rows', to_char(sum(num_rows)) from user_tab_statistics where table_name='C0' union all
select 'stats_blocks', to_char(sum(blocks)) from user_tab_statistics
where table_name='C0' union all
order by 1;
spool off
) where table_name='C0'
select 'stats_avg_row_len', to_char(avg(avg_row_len)) from user_tab_statistics
9. Konec přílohy, postupujte k příloze č. 3a.4.
Příloha č. 3a.4 – Druhá část testu (provádí Tester pomocí SQL*Plus)
1. Předpoklady
Dokončení postupu dle přílohy č. 3a.3.
2. Příprava prostředí
Použijte pokyny uvedené v příloze č. 3a.2, odstavec č. 2.
3. Kontrola parametrizace
Použijte pokyny uvedené v příloze č. 3a.2, odstavec č. 6.
4. Spuštění druhé části testu (dále jen test)
Spustíme program, který zajistí vytvoření/naplánování úloh. Uvedené argumenty a jejich hodnoty jsou povinné.
1. Počet řádek tabulky c0, které mají být poskytnuty pro test. Maximální hodnota tedy nesmí přesáhnout celkový počet řádek v číselníku.
2. Báze pro dělení čísel užívaných jako „semínko“ pro generátor pseudonáhodných čísel.
3. Počet dávek – celkový počet řádek / velikost dávky.
4. Velikost dávky – celkový počet řádek / počet dávek.
exec rfs(20000000, 1979079357, 5000, 1000);
Součin 3. a 4. argumentu definuje celkový počet řádek – zde 5000 * 1000 = 5 milionů.
5. Sledování průběhu testu (volitelně)
col gr for a45
col tx for a20
select * from (
select * from sl
where tm>=(
select to_date(vs) rd from sp
where rownum<20;
) order by tm desc
) where id='report-filler-ref-date'
Průběh testu lze sledovat pomocí dotazů do tabulky XX.XX.
6. Detekce ukončení zpracování testu – dokončení všech plánovaných úloh
col running for 999999
select count(*) running from user_jobs
where what like 'rf(%' and this_date is not null;
Ukončení testu můžeme nejlépe detekovat pomocí dotazu do pohledu USER_JOBS, kde musí být ukončeny všechny úlohy obsahující v názvu (WHAT) znaky „rf(10“:
RUNNING
0
Po ukončení všech úloh musí výpis vypadat takto:
7. Sběr statistik
dbms_stats.gather_table_stats('PT','R32');
slwr('stats(PT,R32)', 'start');
begin
Upozornění: Tento krok je možno zahájit pouze v případě, že jsou všechny plánované úlohy již bezpečně ukončeny. V opačném případě může dojít k zneplatnění výsledků celého testu!
end;
slwr('stats(PT,R32)', 'stop');
/
8. Výstupní report druhé části testu
Výstup bude zapsán do textového souboru rr-2.txt. Obsah tohoto souboru přiložte k nabídce.
set newp none set echo off set feed off set ver off
set mark html off spool off set lin 100
set pages 100 set trim on set trims on
alter session set nls_territory="CZECH REPUBLIC"; alter session set nls_language=ENGLISH;
alter session set nls_numeric_characters='.,';
alter session set nls_date_format='yyyy-mm-dd+hh24:mi:ss'; set role all;
--
col name for a32 col value for a20
--
spool rr-2.txt
prompt prompt
prompt Database parameters prompt
prompt
select name, value from sys.v_$parameter where name in (
'cpu_count', 'db_name', 'memory_max_target', 'memory_target'
, 'parallel_threads_per_cpu', 'processes') order by 1;
prompt prompt
prompt Second Test Phase Results prompt
prompt
with qn as (
select tm, rd, tm-rd sp from sl
, (select to_date(vs) rd from sp where id='report-filler-ref-date') where tm>=rd and gr like 'RF(%' and tx='job-start'
), qx as (
select tm, rd, tm-rd sp from sl
, (select to_date(vs) rd from sp where id='report-filler-ref-date') where tm>=rd and gr like 'RF(%' and tx='job-stop'
)
select * from (
select 'job_count' name, to_char(count(*)) value from qn union all select 'job_start_first', to_char(min(tm)) value from qn union all select 'job_start_last', to_char(max(tm)) from qn union all
select 'job_start_avg', to_char(min(rd)+avg(sp)) from qn union all select 'job_stop_first', to_char(min(tm)) value from qx union all select 'job_stop_last', to_char(max(tm)) from qx union all
select 'job_stop_avg', to_char(min(rd)+avg(sp)) from qx union all select 'result_required_rows', vs from sp
where id='report-filler-num-of-rows' union all
select 'result_eta_avg', regexp_substr(numtodsinterval(avg(qx.sp)-avg(qn.sp), 'day') , '[0-9] [0-9:]{8}') from qn, qx union all
select 'result_rows_per_minute !STPM!', to_char(round(nor/(24*60*(x-n)))) from
, (select avg(sp) x from qx )
(select avg(sp) n from qn )
, ( select to_number(vs) nor from sp
select 'stats_start' name, to_char(min(tm)) value from sl
where id='report-filler-num-of-rows') union all
, (select to_date(vs) rd from sp where id='report-filler-ref-date')
where tm>rd and gr='stats(PT,R32)' and tx='start' union all
select 'stats_stop', to_char(max(tm)) from sl
, (select to_date(vs) rd from sp where id='report-filler-ref-date')
where tm>rd and gr='stats(PT,R32)' and tx='stop' union all
select 'stats_num_rows', to_char(sum(num_rows)) from user_tab_statistics
where table_name='R32' union all
select 'stats_blocks', to_char(sum(blocks)) from user_tab_statistics
where table_name='R32' union all
select 'stats_avg_row_len', to_char(avg(avg_row_len)) from user_tab_statistics
order by 1;
spool off
) where table_name='R32'
9. Konec přílohy, tímto je test dokončen.
Kontakty pro poskytování provozní podpory
Kontaktní osoby objednatele:
Xxx. Xxxxxxxx Xxxxxxxx
Telefon: x000 0 0000 0000, x000 000 000 000
E-mail: xxxxxxxx.xxxxxxxx@xxx.xx Role: správce DBA
Xxx. Xxx Xxxxxx
Telefon: x000 0 0000 0000, x000 000 000 000
Role: správce DBA
Xxx. Xxxxx Xxxx
Telefon: x000 0 0000 0000, x000 000 000 000
Role: vedoucí referátu aplikačního systémového prostředí
Xxx. Xxxxx Xxxxxxx
Telefon: x000 0 0000 0000, x000 000 000 000
Role: ředitel odboru infrastruktury a provozu IT
Kontakt pro potvrzení přijetí požadavku:
Fax: x000 000 000 000 nebo x000 000 000 000
případně telefonicky nejméně jedné kontaktní osobě objednatele
Příloha č. 4
Kontaktní osoby/centrum zhotovitele:
Způsob poskytování servisních služeb
Incidenty jsou Objednatelem hlášeny na Zhotovitele následujícím způsobem:
• Incident ohlásí Objednatel Zhotoviteli jedním z následujících způsobů:
o e-mailem na adresu xxxxxxx.xxx@xxxx.xx,
o telefonicky na hotline x000 000 000 000.
• Incident zaeviduje Xxxxxxxxxx do své evidenční databáze.
• Přidělí incident k řešení a informuje Xxxxxxxxxxx o zaevidování incidentu, a probíhá jeho řešení.
• Po jeho vyřešení informuje Xxxxxxxxxx Objednatele.
• Objednatel provede kontrolu vyřešení incidentu.
Technický kontakt a eskalace
Zhotovitel | |
Level 3 Level 2 Level 1 | technický kontakt, zodpovědný za poskytování služeb servisní podpory projektový manažer Xxxx Xxxxx Xxxxx, x000 000 000 000, xxxx.xxxxx.xxxxx@xxxx.xx |
Business Development Manager | |
jednatel |
Eskalace Objednatele u Zhotovitele
Objednatel předá požadavek na řešení problému technickému kontaktu Zhotovitele v případě, kdy nebyly během doby odezvy věnovány řešení problému dostatečné aktivity, nebo pokud pracovníci servisní podpory Zhotovitele nereagují podle očekávání. Pokud problém není vyřešen, eskaluje Objednatel problém na Level 2 Zhotovitele. Pokud problém není vyřešen, eskaluje Objednatel problém na Level 1 Zhotovitele.
Eskalace Zhotovitele u Objednatele
Objednatel zajistí vhodný a vzájemně písemně odsouhlasený způsob řešení, který může Zhotovitel využít k řešení problémů, které znemožňují nebo omezují poskytování servisních služeb. Objednatel se zavazuje, že pracovníci Zhotovitele budou mít vždy k dispozici aktualizovaný seznam osob, které je třeba v takové situaci kontaktovat.
Bezpečnostní požadavky objednatele
Příloha č. 5
1. Zhotovitel odpovídá za to, že do objektů objednatele (dále jen „ČNB“) budou vstupovat nebo vjíždět pouze jeho pracovníci, kteří jsou jmenovitě uvedeni v písemném seznamu, schváleném ČNB (dále jen „seznam“). Tato povinnost se vztahuje i na posádky vozidel zhotovitele vjíždějících do garáží ČNB za účelem složení a naložení nákladu. Seznam zhotovitel předloží ČNB nejpozději v den podpisu smlouvy.
2. Seznam bude obsahovat tyto položky: jméno, příjmení a číslo průkazu totožnosti pracovníků zhotovitele. Součástí seznamu je ,,Prohlášení o získání souhlasu subjektů osobních údajů se zpracováním osobních údajů v ČNB ve smyslu zákona č.101/2000 Sb., o ochraně osobních údajů“. Zhotovitel v něm prohlásí a nese odpovědnost za to, že jeho pracovníci uvedení v seznamu vydali souhlas se zpracováním osobních údajů Českou národní bankou v rozsahu: jméno, příjmení a číslo průkazu totožnosti. Důvodem předání těchto osobních údajů je zajištění evidence osob vstupujících do objektu ČNB a správy přístupového systému ČNB.
3. Požadavky na případné doplňky a změny schváleného seznamu pracovníků zhotovitele je nutno neprodleně oznámit ČNB. Případné doplňky a změny podléhají schválení ČNB. Osoby neschválené ČNB nemohou vstupovat do objektů ČNB, přičemž ČNB si vyhrazuje právo neuvádět důvody jejich neschválení.
4. Při příchodu do objektů ČNB pracovníci zhotovitele sdělí důvod vstupu, prokáží se osobním dokladem a podrobí se bezpečnostní kontrole. Osoby, které nejsou uvedeny na seznamu, nebudou do objektu ČNB vpuštěny.
5. Schválení pracovníci zhotovitele musí dbát pokynů bankovních policistů, které se týkají režimu vstupu, pohybu a vjezdu do objektu ČNB. Pracovníci zhotovitele budou do prostorů ČNB vstupovat a v těchto prostorách se pohybovat v režimu návštěv, to znamená vždy pouze v doprovodu zaměstnance ČNB nebo zaměstnance referátu bankovní policie ČNB.
6. V případě mimořádné události se pracovníci zhotovitele musí řídit pokyny bankovních policistů nebo dozorujícím zaměstnancem ČNB a dále instrukcemi vyhlašovanými vnitřním rozhlasem.
7. Pracovníci zhotovitele nesmí vnášet do prostor ČNB nebezpečné předměty, jako jsou střelné zbraně, výbušniny apod. O tom co je a není nebezpečný předmět, rozhodují bankovní policisté v souladu s vnitřními předpisy ČNB.
8. ČNB si vyhrazuje právo nevpustit do objektů ČNB pracovníka zhotovitele, který je zjevně
pod vlivem alkoholu, drog nebo jiné omamné látky.
9. Bez písemného povolení ČNB je zakázáno fotografování a pořizování videozáznamů
z interiéru objektů ČNB.
10. Ve všech prostorech objektů ČNB je přísný zákaz kouření a používání otevřeného ohně. Pracovníci zhotovitele se musí zdržet poškozování či zcizení majetku ČNB, a dále zdržet se nevhodného chování vůči zaměstnancům a návštěvníkům ČNB.
11. Pracovníci zhotovitele uvedení na seznamu se musí před započetím výkonu práce v objektech ČNB prokazatelně seznámit, ve smyslu předpisů o požární ochraně, bezpečnosti a hygieně práce, se specifikami daných objektů ČNB (např. způsob vyhlášení požárního poplachu, určení ohlašovny požáru, seznámení s únikovými cestami, poplachovými směrnicemi, evakuačním plánem, umístěním věcných prostředků požární
ochrany apod.). ČNB je oprávněna kdykoliv podrobit kontrole kterékoliv pracovníka
zhotovitele uvedeného na seznamu z dodržování těchto předpisů a ustanovení.
Příloha č. 6
Podmínky pro transport a instalaci IDS u objednatele (dále jen „ČNB)
IDS budou umístěny ve výpočetních střediscích ČNB v Praze. Obě střediska jsou vybavena
obdobně, nicméně z hlediska instalační připravenosti jsou zde drobné rozdíly.
V prostoru je zajištěno chlazení a nepřetržité napájení (UPS), požární signalizace a samozhášecí systém. Z provozního hlediska je nutné počítat s tím, že v objektu ústředí je vstupní teplota nasávaného vzduchu do zařízení kolem 25°C, ve druhém objektu kolem 23°C.
Technické údaje k nosnosti podlahových konstrukcí v místech plnění a další informace
k možnostem instalace.
1) prostor instalace – Senovážná 3, Praha 1 (místnost VP304)
K instalaci je vyhrazena plocha stojanu RN28
Dle statického posudku je možné zatížení prostoru do celkové hmotnosti 750 kg (včetně
stojanu). Pro instalaci je k dispozici 1 stojan výrobce Triton (42U, hmotnost cca 100 kg). Stojan má rozměry 80 x 100 x 197 cm (š x h x v) a je vybaven 2x PDU (každé PDU vybaveno 18xC14+3xC20, jištění 20A, 1 fázové).
Stojan je napojen na systém „teplé uličky“ a musí tedy být zajištěna cirkulace vzduch
„zepředu dozadu“.
Pokud nebude využit nabízený stojan, musí být součástí dodávky stojan nový a současně musí být součástí dodávky i jeho začlenění do teplé uličky s důsledným oddělením studené a teplé zóny, tak aby nedocházelo ke zkratu přiváděného a odváděného vzduchu (zatěsnění uličky). Pro instalaci atypického stojanu do stávajícího systému je připraven prostor (viz obrázek) s
rozměry: výška 197cm, šířka 80cm, hloubka maximálně 130cm. Jiné než uvedené rozměry otvoru (000x00) xxxxxxxx nevylučujeme, ale jsou v naprosté zodpovědnosti zhotovitele. Netěsnosti mezi studenou a teplou zónou plynoucí z rozdílných rozměrů musí být zaslepeny a utěsněny tak, aby nedošlo ke vzduchovému zkratu. Finální zaslepení musí být provedeno opakovaně rozebíratelné bez poškození stávajících konstrukcí teplé uličky. Konstrukce zaslepení bude lakovaný plech (odstín RAL 7035 stejný jako u stávající konstrukce nebo v odstínu nového stojanu) ke stávající konstrukci šroubovaný. Těsnění bude provedeno těsnícími páskami nalepenými na zaslepovacím plechu. Do konstrukce teplé uličky je možné vyvrtat nezbytný počet otvorů pro sešroubování. Není přípustné konstrukci upravovat řezáním, případně vystříháváním plechových částí konstrukce. Při práci na zaslepení musí být nečistoty průběžně odsávány.
Mezi železobetonovou deskou a deskami zdvojené podlahy jsou umístěny rozvody napájení, samozhášecího systému, požární signalizace, detekce úniku kapalin a v minimální míře slaboproudé rozvody datové komunikace. Jejich konkrétní umístění bude prezentováno při prohlídce místa plnění.
Silnoproudé napájení: pro instalaci je k dispozici:
- 2 nezávislé přívody napájení 230V, 1 fázové, jištění 20A
- 2 nezávislé přívody napájení 230V, 3 fázové, jištění 3x20A
Ve všech případech zakončené „rozvodnou krabicí“ ve zdvojené podlaze. Jiné než uvedené potřeby je potřeba konzultovat se objednatelem.
Při výměně stojanu lze využít PDU specifikovaná výše (zhotovitel zajistí případné úpravy pro uchycení PDU do jiného stojanu)
Zhotovitel zajišťuje:
- transport zařízení do prostoru instalace
- případné dodání stojanu a případné zasazení/zatěsnění do „teplé uličky“ ČNB zajišťuje
- zapojení do „rozvodných krabic“
- připojení do infrastruktury ČNB (LAN)
2) prostor instalace – Xxxxxxxxxxxx 000, Xxxxx 5 (místnost PP117)
K instalaci je možné využít prostor pro jeden stojan o rozměrech obdobných jako ve druhém objektu, tj. přibližně výška 197cm (max. 210 cm), šířka typicky 80cm, hloubka maximálně 130cm (stojan musí být zajištěn zhotovitelem) v místnosti PP117. Jediným omezením je zachování dostatečného servisního prostoru pro již instalované stojany a technologie ze všech stran včetně zajištění přístupu k čidlům EPS a kohoutům na potrubích. V tomto místě plnění se nepředpokládá žádné přemisťování stávajících technologií a stojanů.
V tomto objektu není k dispozici žádný stojan a musí tedy být součástí dodávky.
V současné době je chlazení zajištěno nafukováním chladného vzduchu do zdvojené podlahy. V budoucnu se předpokládá stejný systém jako v Senovážné, tedy systém teplé a studené uličky.
Mezi železobetonovou deskou a deskami zdvojené podlahy jsou umístěny rozvody napájení, samozhášecího systému, požární signalizace, detekce úniku kapalin a v minimální míře slaboproudé rozvody datové komunikace.
Rovnoměrné zatížení nosné konstrukce – drátkobeton C16/20 = 500 kg/m2
Plošná zatížitelnost zdvojené podlahy ADS 40/L-500 (vodivě pospojováno) = 1600 kg/m2
Silnoproudé napájení: pro instalaci je k dispozici:
- 2 až 4 nezávislé přívody napájení 230V, 1 fázové, jištění 16A
- 2 nezávislé přívody napájení 230V, 3 fázové, jištění 3x20A
Ve všech případech zakončené „rozvodnou krabicí“ ve zdvojené podlaze. Jiné než uvedené potřeby je potřeba konzultovat se objednatelem.
Zhotovitel zajišťuje:
- transport zařízení do prostoru instalace
- dodání stojanu ČNB zajišťuje
- zapojení do „rozvodných krabic“ připojení do infrastruktury ČNB (LAN)
3) transportní trasy – Senovážná 3, Praha 1
A) vstup do objektu ČNB z ulice Senovážná chodbou v přízemí přes bezpečnostní branku š. 100 cm na podestu schodiště D – užitné rovnoměrné zatížení podlahy = 450 kg/m2, povrch: keramická mozaiková dlažba – replika provedená na zakázku (zajistit ochranu před poškozením – viz pozn.); následně osobním výtahem (nosnost 630 kg, podlaha z keramické dlažby, š. dveří 80 cm) nebo nákladním výtahem (nosnost 2000 kg) na podestu schodiště D ve vloženém patře – užitné rovnoměrné zatížení podlahy = 450 kg/m2, povrch: keramická mozaiková dlažba – replika (viz pozn.); odtud po zdvojené podlaze do prostor počítačového sálu
B) vstup do objektu ČNB z ulice Senovážná chodbou v přízemí přes bezpečnostní branku š. 100 cm na podestu schodiště D – užitné rovnoměrné zatížení podlahy = 450 kg/m2, povrch: keramická mozaiková dlažba – replika (viz pozn.); následně po schodišti D na podestu ve vloženém patře; odtud stejné jako u trasy A
Pozn. – před a při provádění transportu technologického zařízení musí být zajištěna ochrana stávající keramické mozaikové dlažby pomocí desek z překližky o min. tl. 20 mm, pod které bude ještě položena netkaná silnější textilie. Při transportu musí být poloha koleček přepravního zařízení vedena středem položených desek, aby se zamezilo pružné lokální deformaci keramické dlažby, jež by mohla zapříčinit uvolnění dlažby od podkladu, poškození spárování nebo jednotlivých částí mozaikové dlažby !!!
Obecně lze říci, že transportní trasa umožňuje bezproblémový transport zařízení o základně cca 100x80 cm a výšce maximálně 195 cm. Zejména vyšší zařízení budou mít problém při průchodu dveřmi.
4) transportní trasy – Strojírenská 175, Praha 5
A) vstup do objektu ČNB z ulice Strojírenská chodbou v přízemí přes bezpečnostní branku na podestu hlavního schodiště – užitné rovnoměrné zatížení podlahy = 500 kg/m2, povrch: keramická dlažba (nutné zajistit ochranu před poškozením – viz pozn. v bodu 3)
); dále pak chodbou se zdvojenou podlahou – užitné rovnoměrné zatížení podlahy = 1600
kg/m2 až do prostor počítačového sálu
B) vstup do objektu ČNB z ulice Za archívem (do ulice Za archívem je povolen vjezd pro vozidla do 3,5 t) chodbou v přízemí – užitné rovnoměrné zatížení podlahy = 500 kg/m2, povrch: betonová mazanina s protiprašným povrchovým nátěrem; dále průchodem přes osobonákladní výtah (nosnost 1600 kg) do chodby se zdvojenou podlahou – užitné rovnoměrné zatížení podlahy = 1600 kg/m2 až do prostor počítačového sálu.
Obecně lze říci, že transportní trasa umožňuje bezproblémový transport zařízení o základně cca 100x80 cm a výšce maximálně 195 cm. Zejména vyšší zařízení budou mít problém při průchodu dveří.
Příloha č. 7
STANDARDNÍ SYSTÉMOVÉ PROSTŘEDÍ OBJEDNATELE
Níže je uveden stručný výtah z popisu standardního systémového prostředí objednatele. Nejedná se o úplný popis, ale o výtah informací relevantních k danému zadávacímu řízení na dodávku a implementaci IDS.
1. OBECNÉ INFORMACE
V ČNB jsou v provozu dvě výpočetní střediska. Obě tato střediska jsou provozována systémem aktiv-aktiv, tj. v obou střediscích jsou zpracovávány různé informační systémy. Běžný uživatel není schopen rozlišit, ve kterém středisku je jeho požadavek zpracován.
1.1. Komunikační infrastruktura/SAN
Jedno výpočetní středisko je umístěno v budově ústředí v Praze 1 a druhé v Praze 5 - Zličín. Druhé z výpočetních středisek je též koncipováno jako tzv. nouzové záložní pracoviště ČNB pro případ, kdy bude budova ústředí ČNB mimo provoz (dále jen ZP). Obě střediska jsou plnohodnotně vybavena jak po stránce komunikační (LAN, SAN), tak i po stránce zpracování a uložení dat (servery, disková pole, magnetopáskové knihovny). Z kapacitního hlediska převažuje (počty serverů, objemy dat) objekt ústředí, ve kterém jsou také umístěny systémy nevyžadující zdvojení (méně významné IS, systémy pro testování a vývoj apod.).
Obě výpočetní střediska jsou propojena optickými vlákny (single mode) dvěma nezávislými trasami. Jedna z tras je dlouhá 22,0 km, druhá trasa je dlouhá 24,4 km. Obě trasy jsou rovnocenné z hlediska přenášených protokolů (TCP/IP, FC) a přibližně i objemu přenášených dat. Na obou koncích jsou umístěny multiplexory DWDM.
Všechny prvky SAN (FC direktory) jsou ve shodné HW a SW konfiguraci. Jsou vytvořeny dva vzájemně oddělené fabricy, každý z nich je tvořen dvěma FC direktory umístěnými v jiné lokalitě. Každý z fabriců využívá obě optické komunikační trasy mezi objekty.
Páteřní optické rozvody v rámci objektu ústředí jsou 62,5 um, v objektu ZP Zličín jsou 50 um (typ vlákna OM3). Multimode páteřní optická kabeláž je zpravidla zakončena konektory typu SC na patch panelech v objektu ústředí. Ostatní kabeláž je zakončena konektory typu LC (patch panely v objektu ZP Zličín, prvky SAN v obou objektech).
1.2. Standardní komunikační vybavení
• LAN - strukturovaná kabeláž pro připojení uživatelů umožňující připojení rychlostí minimálně 100 Mbit/s. Standardní provedení je metalické, optická vlákna jsou typem doplňkovým;
• Páteřní LAN – Gigabit Ethernet až 10 Gbps;
• aktivní síťové prvky – platforma CISCO, plně přepínaná síť;
• LAN, MAN, WAN – multiplexory typu DWDM;
• Ethernet dle ISO 802.3 pro připojení uživatelských stanic;
• Protokol TCP/IP;
• Přesný čas – NTP
Jako zdroj přesného času je použit SNTP (Simple Network Time Protocol) server MTS (Moba Time Server). Server je synchronizován externím časovým signálem s GPS (Global Positioning System). Protokolem NTP (Network Time Protocol) se pak synchronizují další síťová zařízení. Struktura synchronizace je hierarchická.
1.3. Aplikace a systémové služby
• Backup – HP Data Protector v9.07,
• Zdroj přesného času – protokol NTP,
• SIEM – HP ArcSight v6.9.1,
1. konektor pro sběr logů z RHEL (Syslog+audit): 7.3.0
2. konektor pro sběr logů z Oracle DB: do verze 11: 7.2.3
3. konektor pro sběr logů z Oracle DB 12c: 7.1.7 (flex)
• HSM Thales (aktuálně 64bitová verze SW SecurityWorld 11.72.00 pro Linux a HSM
Thales nShield Connect 6000 (firmware 2.51.12).
Pozn.: Verze aplikací a služeb jsou platné ke dni vyhlášení zadávacího řízení. Později může být aplikován minoritní update či patch, který může uvedenou verzi povýšit.
1.4. Přehled provozovaných databází
Typ.<skupina>.<poč. jader> | Lokalita | Typ DB | Edice | Licence | Počet Jader | RAM [GB] | HDD [GB] |
Provoz.0.10 | Senovážná | OLTP | EE | NU | 1,25 | 10 | 600 |
Provoz.0.10 | Senovážná | ARCHIV | EE | NU | 1,25 | 2 | 400 |
Provoz.0.10 | Senovážná | OLTP | EE | CPU | 1,25 | 7 | 200 |
Provoz.0.10 | Senovážná | OLTP | EE | CPU | 1,25 | 4 | 300 |
Provoz.0.10 | Senovážná | OLTP | EE | NU | 1,25 | 4 | 300 |
Provoz.0.10 | Senovážná | OLTP | EE | CPU | 1,25 | 2 | 100 |
Provoz.0.10 | Senovážná | OLTP | EE | CPU | 1,25 | 2 | 100 |
Provoz.0.10 | Senovážná | ARCHIV | EE | CPU | 1,25 | 2 | 150 |
Provoz.1.3 | Senovážná | DWH | EE | CPU | 1,50 | 12 | 600 |
Provoz.1.3 | Senovážná | DWH | EE | CPU | 1,50 | 8 | 350 |
Provoz.10.17 | Senovážná | OLTP | EE | CPU | 2,13 | 4 | 500 |
Provoz.10.17 | Senovážná | OLTP | EE | CPU | 2,13 | 4 | 500 |
Provoz.10.17 | Senovážná | OLTP | EE | CPU | 2,13 | 4 | 500 |
Provoz.10.17 | Senovážná | OLTP | EE | CPU | 2,13 | 4 | 500 |
Provoz.10.17 | Senovážná | CATALOG | EE | 2,13 | 3 | 50 | |
Provoz.10.17 | Senovážná | OLTP | EE | 2,13 | 2 | 100 | |
Provoz.10.17 | Senovážná | OLTP | EE | NU | 2,13 | 4 | 300 |
Provoz.10.17 | Senovážná | OLTP | EE | NU | 2,13 | 4 | 100 |
Provoz.2.4 | Senovážná | OLTP | EE | NU | 1,00 | 4 | 250 |
Provoz.2.4 | Senovážná | DWH | EE | NU | 1,00 | 12 | 1200 |
Provoz.2.4 | Senovážná | OLTP | SE | NU | 1,00 | 4 | 100 |
Provoz.2.4 | Senovážná | OLTP | EE | CPU | 1,00 | 3 | 60 |
Provoz.3.7 | Senovážná | OLTP | EE | NU | 1,40 | 4 | 350 |
Provoz.3.7 | Senovážná | OLTP | EE | NU | 1,40 | 4 | 150 |
Provoz.3.7 | Senovážná | OLTP | EE | NU | 1,40 | 6 | 150 |
Provoz.3.7 | Senovážná | OLTP | EE | NU | 1,40 | 4 | 150 |
Provoz.3.7 | Senovážná | OLTP | EE | NU | 1,40 | 3 | 100 |
Provoz.4.9 | Senovážná | OLTP | EE | NU | 2,25 | 12 | 550 |
Provoz.4.9 | Senovážná | OLTP | SE | NU | 2,25 | 12 | 100 |
Provoz.4.9 | Senovážná | DWH | SE | NU | 2,25 | 4 | 100 |
Provoz.4.9 | Senovážná | OLTP | SE | NU | 2,25 | 2 | 150 |
Provoz.4.9 | Senovážná | OLTP | SE | NU | 2,25 | 2 | 150 |
Provoz.5.10 | Senovážná | OLTP | EE | CPU | 1,11 | 4 | 15000 |
Provoz.5.10 | Senovážná | OLTP | EE | 1,11 | 3 | 40 | |
Provoz.5.10 | Senovážná | OLTP | SE | 1,11 | 2 | 10 | |
Provoz.5.10 | Senovážná | OLTP | SE | NU | 1,11 | 2 | 50 |
Provoz.5.10 | Senovážná | OLTP | SE | NU | 1,11 | 2 | 10 |
Provoz.5.10 | Senovážná | OLTP | EE | 1,11 | 4 | 100 | |
Provoz.5.10 | Senovážná | OLTP | SE | NU | 1,11 | 3 | 10 |
Provoz.5.10 | Senovážná | OLTP | EE | NU | 1,11 | 9 | 500 |
Provoz.5.10 | Senovážná | DWH | SE | NU | 1,11 | 14 | 800 |
Provoz.6.4 | Senovážná | DWH | SE | NU | 2,00 | 6 | 3000 |
Provoz.6.4 | Senovážná | OLTP | SE | NU | 2,00 | 6 | 1000 |
Provoz.7.6 | Senovážná | OLTP | SE | NU | 1,50 | 12 | 400 |
Provoz.7.6 | Senovážná | OLTP | SE | NU | 1,50 | 4 | 100 |
Provoz.7.6 | Senovážná | OLTP | EE | NU | 1,50 | 8 | 500 |
Provoz.7.6 | Senovážná | OLTP | SE | NU | 1,50 | 6 | 100 |
Provoz.8.2 | Senovážná | DWH | EE | NU | 1,00 | 4 | 700 |
Provoz.8.2 | Senovážná | DWH | EE | NU | 1,00 | 4 | 700 |
Provoz.9.5 | Senovážná | DWH | EE | NU | 5,00 | 30 | 1500 |
Provoz.11.12 | Senovážná | OLTP | EE | CPU | 12,00 | 20 | 2000 |
Test.0.21 | Zličín | OLTP | EE | NU | 1,00 | 4 | 500 |
Test.0.21 | Zličín | OLTP | EE | CPU | 1,00 | 10 | 1000 |
Test.0.21 | Zličín | OLTP | EE | NU | 1,00 | 2 | 200 |
Test.0.21 | Zličín | OLTP | SE | NU | 1,00 | 2 | 50 |
Test.0.21 | Zličín | OLTP | EE | CPU | 1,00 | 2 | 100 |
Test.0.21 | Zličín | OLTP | SE | NU | 1,00 | 2 | 20 |
Test.0.21 | Zličín | OLTP | EE | CPU | 1,00 | 2 | 100 |
Test.0.21 | Zličín | OLTP | EE | CPU | 1,00 | 4 | 500 |
Test.0.21 | Zličín | OLTP | EE | CPU | 1,00 | 4 | 500 |
Test.0.21 | Zličín | DWH | EE | NU | 1,00 | 4 | 500 |
Test.0.21 | Zličín | OLTP | EE | NU | 1,00 | 2 | 100 |
Test.0.21 | Zličín | DWH | EE | NU | 1,00 | 6 | 1200 |
Test.0.21 | Zličín | DWH | SE | NU | 1,00 | 2 | 200 |
Test.0.21 | Zličín | OLTP | EE | CPU | 1,00 | 2 | 50 |
Test.0.21 | Zličín | DWH | EE | NU | 1,00 | 4 | 700 |
Test.0.21 | Zličín | OLTP | EE | NU | 1,00 | 3 | 150 |
Test.0.21 | Zličín | OLTP | SE | NU | 1,00 | 3 | 50 |
Test.0.21 | Zličín | OLTP | SE | NU | 1,00 | 2 | 50 |
Test.0.21 | Zličín | OLTP | SE | NU | 1,00 | 4 | 100 |
Test.0.21 | Zličín | OLTP | EE | NU | 1,00 | 2 | 300 |
Test.0.21 | Zličín | DWH | SE | NU | 1,00 | 2 | 250 |
Vývoj.0.14 | Zličín | OLTP | EE | CPU | 0,70 | 10 | 1000 |
Vývoj.0.14 | Zličín | OLTP | EE | NU | 0,70 | 2 | 100 |
Vývoj.0.14 | Zličín | OLTP | SE | NU | 0,70 | 2 | 20 |
Vývoj.0.14 | Zličín | OLTP | SE | NU | 0,70 | 2 | 100 |
Vývoj.0.14 | Zličín | OLTP | EE | NU | 0,70 | 2 | 50 |
Vývoj.0.14 | Zličín | OLTP | EE | NU | 0,70 | 4 | 200 |
Vývoj.0.14 | Zličín | OLTP | EE | CPU | 0,70 | 4 | 500 |
Vývoj.0.14 | Zličín | OLTP | EE | CPU | 0,70 | 4 | 500 |
Vývoj.0.14 | Zličín | DWH | EE | NU | 0,70 | 4 | 500 |
Vývoj.0.14 | Zličín | OLTP | SE | NU | 0,70 | 3 | 15 |
Vývoj.0.14 | Zličín | OLTP | SE | NU | 0,70 | 2 | 150 |
Vývoj.0.14 | Zličín | OLTP | EE | NU | 0,70 | 3 | 200 |
Vývoj.0.14 | Zličín | OLTP | SE | NU | 0,70 | 3 | 400 |
Vývoj.0.14 | Zličín | OLTP | SE | NU | 0,70 | 2 | 50 |
Vývoj.0.14 | Zličín | OLTP | EE | NU | 0,70 | 2 | 200 |
Vývoj.0.14 | Zličín | DWH | SE | NU | 0,70 | 12 | 800 |
Vývoj.0.14 | Zličín | OLTP | SE | NU | 0,70 | 2 | 50 |
Vývoj.0.14 | Zličín | OLTP | EE | NU | 0,70 | 2 | 300 |
Vývoj.0.14 | Zličín | DWH | SE | NU | 0,70 | 2 | 50 |
Vývoj.0.14 | Zličín | OLTP | EE | NU | 0,70 | 2 | 100 |
Celkem | 126 438 47635 | ||||||
Server | DB | cpu_count | typ CPU | operační paměť [GB] |
SRV1 | DB1 | 8 | Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz | 16 |
DB2 | ||||
SRV2 | DB3 | |||
SRV3 | DB4 | 4 | Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz | 12 |
DB5 | ||||
DB6 | ||||
DB7 | ||||
DB8 | ||||
DB9 | ||||
DB10 | ||||
SRV4 | DB11 | 4 | Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz | 16 |
DB12 | ||||
DB13 | ||||
SRV5 | DB15 | 4 | Intel(R) Xeon(R) CPU X5660 @ 2.80GHz | 16 |
SRV6 | DB16 | 4 | Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz | 24 |
DB17 | ||||
DB18 | ||||
DB19 | ||||
DB20 | ||||
DB21 | ||||
DB22 | ||||
DB23 | ||||
SRV7 | DB24 | 4 | Intel(R) Xeon(R) CPU E5-2407 v2 @ 2.40GHz | 32 |
DB25 | ||||
DB26 | ||||
DB27 | ||||
DB28 | ||||
DB29 | ||||
SRV8 | DB30 | |||
SRV9 | DB31 | 8 | Intel(R) Xeon(R) CPU X5560 @ 2.80GHz | 36 |
SRV10 | DB32 | 8 | Intel(R) Xeon(R) CPU X5672 @ 3.20GHz | 24 |
SRV11 | DB33 | 12 | Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz | 16 |
SRV12 | DB34 | 12 | Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz | 16 |
SRV13 | DB35 | 4 | Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz | 20 |
DB36 | ||||
SRV14 | DB37 | |||
SRV15 | DB38 | 2 | Intel(R) Xeon(R) CPU E5-2430 v2 @ 2.50GHz | 8 |
SRV16 | DB39 | 8 | Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz | 24 |
DB40 | ||||
DB41 | ||||
DB42 | ||||
DB43 | ||||
SRV17 | DB44 | |||
SRV18 | DB45 | 2 | AMD Opteron(tm) Processor 254 | 10 |
DB46 | ||||
SRV19 | DB47 | 8 | Intel(R) Xeon(R) CPU X5670 @ 2.93GHz | 20 |
SRV20 | DB48 | |||
SRV21 | DB52 | |||
DB53 | ||||
DB54 | ||||
DB55 | ||||
SRV22 | DB56 | 4 | Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz | 8 |
DB57 | ||||
SRV23 | DB58 | 8 | Intel(R) Xeon(R) CPU X5670 @ 2.93GHz | 18 |
DB59 | ||||
SRV24 | DB60 | 16 | Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz | 25 |
SRV25 | DB64 | 8 | Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz | 16 |
DB65 | ||||
DB66 | ||||
SRV26 | DB67 | |||
DB68 | ||||
DB69 | ||||
SRV27 | DB70 | 8 | Intel(R) Xeon(R) CPU X5670 @ 2.93GHz | 5 |
SRV28 | DB71 | 4 | Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz | 10 |
SRV29 | DB72 | |||
SRV30 | DB73 | 24 | Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz | 22 |
DB74 | ||||
DB75 | ||||
DB76 | ||||
SRV31 | DB77 | |||
DB78 | ||||
DB79 | ||||
SRV32 | DB80 | 8 | Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz | 8 |
SRV33 | DB81 | |||
SRV34 | DB82 | 8 | Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz | 16 |
DB83 | ||||
SRV35 | DB84 | |||
SRV36 | DB85 | 4 | Intel(R) Xeon(R) CPU X5670 @ 2.93GHz | 25 |
SRV37 | DB86 | |||
DB87 | ||||
DB88 | ||||
DB89 | ||||
SRV38 | DB90 | 8 | Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz | 20 |
DB91 | ||||
DB92 | ||||
DB93 | ||||
DB94 | ||||
DB95 | ||||
DB96 | ||||
DB97 | ||||
DB98 |
| |||
2. ZDROJE SYSTÉMOVÉHO PROSTŘEDÍ NABÍZENÉ PRO ZHOTOVITELE
Zhotovitel může v rámci realizace této smlouvy využít následující prvky a komponenty standardního systémového prostředí ČNB.
• DMZ – jeden fyzický server pro každou instalační lokalitu – výška serveru 1U, standardní
x86, 1x CPU (min. 4-jádrové), 2x 1GB připojení LAN, 2x 146 GB HDD.
• Na výpočetních sálech ČNB jeden vybavený kabinet/rack (42U).
Instalační lokality - propojení
• Pro správnou funkci clusterů („stěhování“ IP adres clusterových skupin) jsou lokality propojeny protokolem TCP/IP na úrovni L2 z hlediska rozhraní Ethernet.
o Pro případné datové připojení může být IDS v každé lokalitě použito nejvýše 2x 10Gbit/s (IPv4).
o Pro management IDS bude poskytnuto separátní LAN připojení (VLAN) pro management síť.
• SAN je realizována mezi objekty s připojením 8 Gbit/s v rámci lokality. SAN je mezi
lokalitami propojena celkem 4x8 Gbit/s (prostřednictvím DWDM).
o Pro případné připojení může být IDS v každé lokalitě použito nejvýše 8 portů (4+4 každý z jiného fabricu SAN z důvodu redundance). Propojení mezi lokalitami může být použito pro zrcadlení IDS, ale ČNB nebude poskytovat žádnou kapacitu na diskových polích. Z FC kapacity mezi objekty může být trvale využito 2x 8Gbit/s pro potřeby přenosu dat mezi IDS a zbylá kapacita může být využita pro vykrytí špičkových přenosů v rozsahu nejvýše 20 minut za den.
Pozn.: Objem archivních redologů všech databází je cca 1 TB/ den (průměr včetně víkendů). Denní maximum za měsíc listopad 2016 byly cca 3 TB.
3. NÁVRH TECHNICKÉHO ŘEŠENÍ
Příloha č. 8
Navrhovaná platforma IDS pro provoz Oracle databází požadovaná v poptávce je řešena pomocí dvou boxů Integrovaného systému Oracle Exadata Database Machine X6-2 v provedení Quarter Rack. Každý tento Integrovaný systém obsahuje dva databázové servery, tři Exadata Storage servery a vysokorychlostní vnitřní síťové propojení.
Schéma doporučené topologie databází je zakreslen v následujícím obrázku. Na jednotlivých lokalitách je možno vytvářet produkční prostředí, odpovídající prostředí DR, test či vývoj. Jednotlivým databázovým úlohám je možno přidělovat výkon prostředky, které jsou popsány níže.
Oracle Exadata Database Machine – Infrastruktura pro Oracle databáze
Mnohaleté zkušenosti společnosti Oracle umožnily navrhnout řešení problematiky efektivního provozu databázových systémů současně na úrovni serverů, datových úložišť i operačního systému a databázového software. Jsme proto schopni nabídnout databázové řešení, které přináší maximální výkon, škálování výkonu a je schopno zajistit maximální dostupnost – dokáže tolerovat poruchu hardwaru na úrovni serverů i úložišť. Nabízený Integrovaný systém je certifikovaný pro provoz Oracle Databáze 11gR2 a 12c.
Kvalita databázové služby není jenom o silném výkonu hardware nebo jenom o výkonu databázového serveru, ale výkonu celé infrastruktury včetně storage systému a síťového propojení.
Nabízíme úplný předkonfigurovaný a vyladěný databázový systém, kde díky použití homogenních technologií a centrální správě pomůže administrátor plnit několik rolí nebo pracovat daleko rychleji a efektivněji.
I když je nabízený databázový systém vytvořen jako specializovaný předintegrovaný systém poskytující vysoký výkon pro databázové úlohy, je vnitřně postaven s využitím standardních komponent (Oracle Databaze, servery x86/x64, operační systém Oracle Linux ), což umožňuje jeho snadné zapojení do stávající infrastruktury.
Řešení, které nabízíme, přináší mnoho výhod:
Konsolidace serverů, storage systému a síťové infrastruktury do jednoho
integrovaného a plně vyladěného prostředí - certifikovaného prostředí pro provoz Oracle DB.
Některé datově náročné databázové operace jsou z databázových serverů přesunuty přímo na storage systémy. Tímto dosahuje mnohem vyšších výkonů než tradiční přístup stavěných IT infrastruktur, můžeme lépe optimalizovat nutný počet licencí databáze Oracle.
Snížení provozních nákladů – výrazné snížení spotřeby elektrické energie, nároků na prostor a chlazení, zjednodušení provozu a údržby
Výrazně zjednodušená správa (jednotný nástroj pro správu databáze, serverů, storage serveru, operačního systému a databáze jako celku)
Vysoká dostupnost a spolehlivost celého řešení již v rámci single rack – všechny komponenty zdvojené v případě poruchy výměna za chodu
Plné pokrytí kapacitních a výkonnostních požadavků na databázovou platformu Prostředí umožňující flexibilní poskytování databázových služeb (jednotka výkonu /
jednotka nákladů)
Oracle Exadata Database Machine byla vůbec prvním integrovaným systémem Oracle a je proto také v současnosti nejrozšířenější. Počet instalací překročil 20.000 systémů celosvětově a v České republice již 32 instalací. Mezi referenční zákazníky z oblasti finančních institucí v České republice patří společnosti: Equabank, J&T banka a Moneta Money bank.
Integrovaný systém je navržený pro databázové aplikace s vysokými požadavky na výkon a dostupnost. Je možné jej použít pro provoz transakčních aplikací, datových skladů i jako konsolidované prostředí kombinující obojí. V závislosti na zvoleném modelu obsahuje různý počet databázových serverů s procesory Intel Xeon a speciální Exadata Storage Servery, sloužící jako sdílená úložiště dat. Nabízené konfigurace jsou přitom sestaveny tak, aby byla vždy zajištěna vyváženost výkonu databázových serverů a Storage Serverů a nevznikala tak úzká hrdla. Díky technologii Real Application Clusters je možné využít současně výkon více serverů pro provoz společné databáze.
Vysoká dostupnost databázového systému
Platforma Oracle Exadata Database Machine je automaticky („out of the box“) odolná proti výpadku libovolné komponenty. Všechny komponenty jsou zdvojené, počínaje napájením, sběrnicí, síťovými připojeními, disky, databázovými a storage servery.
Napájení – odolnost systému proti výpadku napájení je garantována zdvojenými Power Distribution Units (PDU) a zdvojeným, „hot-swappable“ napájením serverů
Síťové připojení – sběrnice Infiniband a připojení k sběrnici je zdvojené, stejně tak je zdvojené připojení k síti Ethernet (jak 10Gb porty, tak porty 1Gb).
Disky – disky jsou zrcadleny v režimu „high redundancy“, s využitím Oracle ASM. Výpadek disku je řešen online, bez přerušení databázových služeb.
Storage servery – disky jsou dále zrcadleny mezi jednotlivými storage servery, systém je tedy odolný i proti výpadku celého storage serveru, opět bez přerušení databázových služeb. Unikátní vlastnosti Oracle Databáze ve spojení s integrovaným systémem Exadata lze využít i pro zajištění vysoké úrovně ochrany dat – tzv. Disaster Recovery. Přímo prostředky Oracle Database je zajištěn synchronní či asynchronní přenos změn z primárního datového centra do záložního centra. Data jsou tak neustále chráněna a i v případě přírodní katastrofy, která by vedla k úplné odstávce primárního datového centra. Během řádově minut lze zajistit obnovení provozu ze záložního centra, a to především bez ztráty dat. Tento přístup vede oproti tradičním technikám zrcadlení diskových polí k nižším požadavkům na přenosovou kapacitu mezi lokalitami, i k vyšší ochraně dat díky neustálé kontrole jejich konzistence.
Primární lokalita Záložní lokalita
Disaster Recovery s využitím Oracle
DataGuard
Pro zajištění Disaster Recovery pro Mission Critical databáze navrhujeme implementovat standardní standby databáze v záložní lokalitě s využitím Oracle Data Guard. Oracle Data Guard v režimu physical standby podporuje všechny vlastnosti Oracle včetně komprese HCC, při současném zachování vysokého transakčního výkonu.
Oracle Data Guard zvyšuje robustnost celého řešení, neboť zajišťuje detekci, prevenci a automatickou opravu porušených databázových bloků na primární databázi. Oracle Data Guard podporuje HARD validaci dat („Oracle Hardware Assisted Resilient Data“), která je automaticky prováděna Oracle Exadata storage servery.
Kromě zajištění Disaster Recovery je využití Oracle Data Guard výhodné i pro rychlé vytváření databázových klonů na záložní lokalitě (typicky pro preprodukční databáze), pro možnost zálohování na záložní lokalitě (tj. snížení zátěže na primární lokalitě) a pro provádění upgradů na vyšší verze s minimalizací odstávky (tzv. „rolling upgrades“).
Oracle Data Guard je součástí Oracle Database Enterprise Edition, v případě nasazení této topologie není již třeba dalších HW komponent ani SW licencí.
Požadavky na výkonnost a kapacitu IDS
V následující tabulce jsou uvedeny požadované parametry výkonové a kapacitní, parametry jsou uvedeny pro jednu lokalitu, druhá lokalita je identická:
Exadata Databace Machine X6-2 Quarter Rack, konfigurace jedné lokality: | |
Počet Databázových serverů, počty CPU jader, velikost RAM | 2x Databázový server , celkem 40 aktivovaných CPU jader Intel Xeon (celkový možný počet CPU jader je 88, 48 CPU jader bude deaktivovaných) Velikost RAM v každém DB serveru je 768GB, celkem požadovaných 1,5 TB RAM v jedné lokalitě |
Počet Storage serverů, počty procesorových jader pro SQL offload na storage systému | 3x Exadata Storage server, celkem 60 procesorových jader pro SQL offload |
Storage kapacita - disky, flash cache | 288 TB raw kapacita disků (3 x 12 x 8TB) 85 TB čisté kapacity pro data bez použití komprese (při použití ochrany dat - trojnásobném zrcadlení dat ) 38,4 TB MVMe PCIe 3.0 flash karty pro použití |
funkce Inteligentní Flash cache | |
Síťová připojení | 4x 10 Gb SFP + Short Wave (SW) transceivers 3x Management port 100/1000 RJ45 |
Oproti běžným architekturám nabízí dále platforma Oracle Exadata Database Machine několik unikátních technologií, zajišťujících vyšší výkon databázových operací:
Smart Scan - odsunutí části databázové logiky přímo na Exadata Storage Servery. Storage Servery jsou schopny významně urychlit složité analytické operace a zmenšit objem dat přenášených do databázových serverů, protože přímo na úrovni datového úložiště mohou předfiltrovat data ještě před tím, než jsou poslány do databázového serveru. Toto předfiltrování probíhá s vysokou mírou paralelizace a tudíž i vysokým výkonem.
Storage Index – Storage Index je paměťová struktura, kterou si automaticky vytvářejí jednotlivé Exadata Storage Servery. Ta obsahuje pro určité rozsahy datových bloků minimální a maximální hodnoty některých sloupců tabulek. Storage Server může pomocí této struktury zcela eliminovat fyzické čtení určitého datového bloku z disku, pokud pomocí Storage Indexu zjistí, že blok nemůže obsahovat hledaná data.
Hybrid Columnar Compression – tato unikátní technologie umožňuje spojit výhody osvědčené Oracle Database a speciálních tzv. sloupcových databází. Umožňuje uložit vybrané tabulky či partitions fyzicky po sloupcích (místo obvyklého uložení po řádcích) a zkomprimovat. Protože sloupcové uložení zajistí vyšší podobnost dat uložených u sebe, dosahují použité algoritmy kompresního poměru 10:1 až 15:1, ale v některých případech i 50:1. Použití komprese je z pohledu aplikace zcela transparentní, i nad komprimovanými tabulkami lze využít plnou funkcionalitu Oracle Database.
Inteligentní Flash Cache – Storage servery obsahují transparentně řízenou vrstvu Flash paměti, pomocí které mohou významně zvýšit výkon při práci s daty z pohledu počtu I/O operací za sekundu. Storage Servery navíc získávají z databázových serverů dodatečná metadata o typu ukládaných a načítaných datových bloků a mohou tak inteligentně řídit strategii cachování.
Výkon nabízeného řešení IDS byl otestován dle scénářů testů viz. Příloha3 návrhu smlouvy na systému Oracle Exadata Database Machine X6-2 prostorách demo centra společnosti Arrow pracovníky ČNB v průběhu měsíce dubna 2017.
Zde jsou uvedeny naměřené výsledky: První test:
Druhý test:
Bezpečnost IDS
Nabízená architektura konsolidace databází na infrastrukturu Exadata Database Machine definuje metody oddělení uživatelských prostředí a práv uživatelů k jednotlivým databázím a datům v souladu s doporučením, které jsou zmíněny Zákoně o kybernetické bezpečnosti.
Jedná se o aplikace následujících metod:
• Oddělené prostředí pro každou pracovní roli
• Vytvoření v operačním systému oddělených účtů, skupin a databázových
ORACLE_HOME
• Oddělení databázového úložiště vytvořením oddělených diskových skupin
• Vytvoření řízeného administrátorského přístupu k diskovým skupinám
• Definice více virtuálních lokálních sítí (VLANs / VLAN Tagging) plus možnost routování
Možnost vytvoření oddělených prostředí bude v Oracle Exadata Database Machine řešena prostředky Oracle Database, Exadata Storage Serveru a operačního systému, tedy prostředky které mají výrazně nižší režii, než obvyklá virtualizace serverů. Jde především o tyto technologie:
Oracle Database Resource Manager umožňuje řídit přidělování systémových zdrojů mezi jednotlivé databázové úlohy uvnitř jedné databáze. Lze tak například garantovat, že určitá databázová úloha, (např. operace prováděné určitým uživatelem) budou mít rezervovanou definovanou část procesorového výkonu.
Instance Caging umožňuje definovat maximální počet procesorových jader dostupných konkrétní databázové instanci a dovoluje tak řídit přístup k CPU mezi více databázovými instancemi běžícími na stejném serveru.
Exadata I/O Resource Manager zajišťuje rozdělování výkonu Exadata Storage mezi jednotlivé databázové úlohy. Lze tak zajistit rozdělení disponibilního výkonu jak mezi úlohy běžícími nad jednou databází, kde tento mechanismus úzce spolupracuje s databázovým Resource Managerem popsaným výše a přebírá přiřazení úloh do tzv. Consumer Groups. Stejně tak je ale možné definovat rozdělení disponibilního výkonu mezi různé databáze uložené na Exadata Storage.
Monitoring IDS
Správa a monitoring Integrovaného databázového systému Exadata Database Machine (všech HW komponent, OS, databází) je zajištěna z jedné konzole nástrojem Enterprise Manager. Po zaškolení a přidělení práv je schopen pracovník v roli databázového administrátora (DBA) spravovat a monitorovat celý IDS.
Oracle Enterprise Manager umožňuje administrátorovi i proaktivně spravovat celý IDS, sledovat nejenom telemetrické parametry, ale i výkonové parametry databázové infrastruktury a následně realizovat opatření.
Systém Exadata Database Machine je možno připojit na Oracle dohledové centrum a vzdáleně monitorovat technické prostředky. Monitoring je jednosměrný, tedy pouze v režimu čtení
„read-only“ bez možnosti přístupu k uživatelským a citlivým administrátorským datům. Komunikace je prostřednictvím „secure gateway“ jejíž instalace je v ceně úvodní instalace systému. Vzdálený monitoring je možno kdykoli vypnout.
Administrace a patchovani IDS
Koncept IDS Oracle Exadata Database Machine je navržen tak, aby se minimalizovala provozní údržba a potřebné úkony mohl provádět po zaškolení administrátor Oracle databází (DBA). Pro Integrovaný systém Exadata Database Machine je čtvrtleně připravován kumulovaný a výrobcem otestovaný balík opravných patchů všech komponent IDS (firmware, OS, databáze Oracle). Pokud se dodrží doporučená konfigurace, je možno tento kumulovaný balík patchů aplikovat bezodstávkově. Dodavatel je připraven při implementaci patchů pomoci.
Příloha č. 9
Cenové podmínky
Cenová tabulka
Integrovaný Databázový Systém (IDS)
IDS - dodávka a instalace | ||
1 | dodávka, instalace a aktivace IDS | Cena v Kč bez DPH |
a | Cena za dodané technické prostředky IDS (rack, výpočetní + úložné + komunikační prvky) + jejich instalace | 15 412 935,48 |
b | Dovoz, instalace, případné úpravy racků v instalační lokalitě č. 1 | 481 499,74 |
c | SW Licence spojené s IDS - např. Operační systém, aplikační SW IDS (High Availabilty (HA), Monitoring atd.), licence pro využití služeb IDS atd. - podrobný seznam/typ/identifikace pořizovaných licencí bude uvedena zhotovitelem v příloze č. 1 smlouvy | 5 215 266,00 |
d | Služba softwarové instalace IDS (1. etapa projektu nad rámec již uvedený v řádcích a) - b) této tabulky) | 400 000,00 |
e | Služba dokončení instalace IDS, aktivace funkcí (2. etapa projektu vyjma písmena f.) | 450 000,00 |
f | Služba migrace 3. vybraných databází zhotovitele do IDS ( 2. etapa projektu, písmeno f.) | 250 000,00 |
g | Zaškolení odborných pracovníků objednatele (4x DBA, 2x vývojáři databázových aplikací) | 200 000,00 |
IDS - dodávka, instalace a aktivace (1a+1b+1c+1d+1e+1f+1g) | 22 409 701,22 | |
SW licence - Oracle | ||
2 | Nově pořizované SW licence "Oracle DB a její Options" nad rámec převáděných současných legacy licencí Oracle a některých jeho Options ve vlastnictví objednatele (viz kapitola 1.4 v příloze č. 2 návrhu smlouvy). podrobný seznam/typ/identifikace pořizovaných licencí bude uvedena zhotovitelem v příloze č. 1 smlouvy | Cena v Kč bez DPH |
a | Oracle DB - EE | 7 612 646,40 |
b | Oracle DB - Diagnostick Pack | 801 331,20 |
c | Oracle DB - Tuning Pack | 1 442 396,16 |
d | Oracle DB - Partitioning Option | 2 303 827,20 |
e | Oracle DB - RAC | 7 372 247,04 |
f | Ostatní Oracle licence neuvedené v bodech a,b,c,d,e | 0,00 |
SW licence (2a+2b+2c+2d+2e+2f) | 19 532 448,00 | |
Případný credit (sleva) za převod existujcích Oracle DB SE licencí zadavatele na Oracle DB EE licence | ||
3 | Kreditované položky … | Cena v Kč bez DPH |
a b | Oracle DB SE a DB SEO | 3 140 600,36 |
Partitioning | 25 816,00 | |
3 166 416,36
Pozn.: Aplikavaný kredit je pak v celkovém součtu TCO brán se záporným znaménkem.
Licence Oracle pro přechodné migrační období | ||
4 | Licence Oracle a příslušných Options případně další licence nutné pro pokrytí migračního období v souladu s požadavkem v kapitole 1.5 přílohy č. 2 návrhu smlouvy podrobný seznam/typ/identifikace pořizovaných licencí bude uvedena zhotovitelem v příloze č. 1 smlouvy | Cena v Kč bez DPH |
a | ||
SW licence pro migrační období (4a + … ) | 0,00 | |
Podpora IDS | ||||
5 | Podpora provozu IDS v roce 2017 (od 1.10.2017) | Cena v Kč bez DPH za měsíc | Počet měsíců | Cena v Kč bez DPH za definované období |
a | Podpora HW + HA a monitoring | 131 862,67 | 3 | 395 588,02 |
b | Podpora SW - operační systém, aplikační SW IDS (HA, Monitoring) | 92 454,18 | 3 | 277 362,54 |
c | Podpora SW - nově kupované licence DB Oracle a Options | 221 710,66 | 3 | 665 131,98 |
Podpora za definovanou část roku 2017 (5a+5b+5c) | 1 338 082,53 | |||
6 | Podpora provozu IDS v roce 2018 | Cena v Kč bez DPH za měsíc | Počet měsíců | Xxxx v Kč bez DPH za definované období |
a | Podpora HW + HA a monitoring | 131 862,67 | 12 | 1 582 352,06 |
b | Podpora SW - operační systém, aplikační SW IDS (HA, Monitoring) | 92 454,18 | 12 | 1 109 450,16 |
c | Podpora SW - nově kupované licence DB Oracle a Options | 221 710,66 | 12 | 2 660 527,90 |
Podpora za rok 2018 (6a+6b+6c) | 5 352 330,12 | |||
7 | Podpora provozu IDS v roce 2019 | Cena v Kč bez DPH za měsíc | Počet měsíců | Cena v Kč bez DPH za definované období |
a | Podpora HW + HA a monitoring | 131 862,67 | 12 | 1 582 352,06 |
b | Podpora SW - operační systém, aplikační SW IDS (HA, Monitoring) | 92 454,18 | 12 | 1 109 450,16 |
c | Podpora SW - nově kupované licence DB Oracle a Options | 221 710,66 | 12 | 2 660 527,90 |
Podpora za rok 2019 (7a+7b+7c) | 5 352 330,12 | |||
8 | Podpora provozu IDS v roce 2020 | Cena v Kč bez DPH za měsíc | Počet měsíců | Xxxx v Kč bez DPH za definované období |
a | Podpora HW + HA a monitoring | 131 862,67 | 12 | 1 582 352,06 |
b | Podpora SW - operační systém, aplikační SW IDS (HA, Monitoring) | 94 912,81 | 12 | 1 138 953,66 |
c | Podpora SW - nově kupované licence DB Oracle a Options | 228 361,98 | 12 | 2 740 343,74 |
Podpora za rok 2020 (8a+8b+8c) | 5 461 649,47 | |||
9 | Podpora provozu IDS v roce 2021 | Cena v Kč bez DPH za měsíc | Počet měsíců | Cena v Kč bez DPH za definované období |
a | Podpora HW + HA a monitoring | 135 739,48 | 12 | 1 628 873,82 |
b | Podpora SW - operační systém, aplikační SW IDS (HA, Monitoring) | 95 601,06 | 12 | 1 147 212,74 |
c | Podpora SW - nově kupované licence DB Oracle a Options | 235 212,84 | 12 | 2 822 554,05 |
Podpora za rok 2021 (9a+9b+9c) | 5 598 640,60 | |||
61 878 765,71
CELKOVÁ NABÍDKOVÁ CENA v Kč bez DPH