• Plzeňská 1270/97, Praha 5
  • info@digitec.cz
  • HOTLINE 24/7 +420 724 102 416
Datum přidání:
13.10.2020
Autor:
Roman Červenka
Správa databáze Oracle. Jak pracné je spravovat Oracle databázi ?
Správa databáze Oracle. Jak pracné je spravovat Oracle databázi ?

Odpověď není tak jednoduchá jak by se mohlo zdát. Samozřejmě záleží na zkušenostech administrátora i složitosti prostředí, ale náročnost a pracnost také dost ovlivňují nástroje které administrátor ke správě a monitoringu používá.

Zkušenosti a nástroje

I když méně zkušený administrátor používá ke správě velmi silné nástroje jako jsou například Enterprise Manager (Database Console) nebo třeba i TOAD, tak stejně tráví spoustu času hledáním na webu nebo v dokumentaci aby se ujistil co vlastně dělá a servisní zásahy často využívá k tomu aby si něco nového nastudoval. Tyto nástroje sice jeho práci urychlují a nemusí hledat syntaxe příkazů, ale daleko více času stejně stráví pochopením problému a zjišťováním co vlastně má udělat. Sebelepší nástroj pro správu DB tedy schopného administrátora nenahradí. Jsme si celkem jisti, že zkušený administrátor bez jakéhokoliv nástroje dokáže často najít a opravit závadu daleko rychleji než nezkušený administrátor s použitím jakéhokoliv nástroje. Navíc, snad každý zkušený administrátor má vlastní knihovnu užitečných skriptů a příkazů, které se mu za ty dlouhá léta nahromadili a které si dříve nebo později začal nějak poznamenávat, vypiplávat a strukturovat. Každý zkušený administrátor totiž ví, že se kdykoliv může dostat do situace, kdy žádný nástroj nebude k dispozici. Nezkušení administrátoři velmi často spoléhají na tyto nástroje a bez nich jsou ztraceni. Speciálně se jedná například o zmiňovaný Enterprise Manager (i Database Console), což je nástroj natolik robustní a designově složitý, že udržovat ho v chodu a na aktuální verzi je samo o sobě často náročnější než vlastní správa databáze. Oracle už to asi také zjistil a proto od verze 12c už Database Console nahradil Database Express, který je daleko stabilnější a prakticky bez údržby. Bohužel ale má z pohledu administrace jen zlomek možností DB konzole. Snad ho ale Oracle bude dále rozvíjet.

Enterprise Manager jako nástroj na hromadnou správu a monitoring stále zůstal, ale už jen jako draze placený produkt.

Složitost prostředí 

Je zřejmé, že správa obyčejné databáze, kterou uživatelé používají jen příležitostně se nedá srovnávat se správou klíčového systému pro stovky uživatelů, který běží v režimu 24/7. Kromě faktu, že větší zátěž prostě vždy generuje více problémů, také jde o to, že tyto systémy často mají také zvýšené nároky na dostupnost databáze. Znamená to, že často jsou v konfiguraci RAC, DataGuard a nebo třeba mají alespoň pasivní failover. A toto vše také zvyšuje pracnost správy. Naše zkušenost je, že například správa Oracle RAC se dvěma instancemi je opravdu téměř dvojnásobně pracná než single-instance databáze. Kromě zvýšené složitosti při patchování a nutnosti spravovat i Clusterware (GI) a ASM instanci, jde také o to, že tato konfigurace tam nebývá použita bezdůvodně a takové systémy bývají dost vytížené a generují často dost výkonnostních problémů. Navíc: pokud se s databází v takové konfiguraci něco stane, tak tyto HA komponenty často přinášejí zvýšenou pracnost nebo dokonce i vážné komplikaci v krajních situacích. Migrace nebo upgrady takových prostředí už naopak zvyšují pracnost výrazně více než dvojnásobně a to také kvůli vyššímu výskytu různých bugů.

DataGuard sám o sobě běžnou správu databáze obvykle výrazně nekomplikuje, ale jsou samozřejmě situace kdy by ho tam administrátor raději neměl. Kromě méně častých problému s přenosem a aplikováním logů jde opět hlavně o patchování a migrace.

V případě správy velkého množství databází je také velmi důležité udržet prostředí co nejvíce stejná. Ideální je potom když administrátor spravuje dokonce i strukturově stejné databáze. Máme osobní zkušenost, že spravovat 1500 databázových instancí (na separátních serverech), které jsou v 95% naprosto stejné a běží na nich i stejné aplikace, tak je reálně méně náročné než mít 50 databází s různými aplikacemi, různým způsobem používání a různými aplikačními požadavky. Když má toto obrovské množství databází stejné parametry, cesty, verze, patche, zálohy a hlavně používá propracovaný proaktivní monitoring, tak takovou správu zvládne tým 3 ostřílených administrátorů i s rezervou a jeden může odjet na dovolenou. Ke správě takového množství databází pak stačí už mít po ruce jen nějaký nástroj, který umí jakýkoliv příkaz spustit během pár minut na všech serverech. Když se pak na nějakém serveru provede jakýkoliv zásah, je potřeba to samé udělat hned proaktivně na všech serverech.

A kromě stejného prostředí je právě proaktivní monitoring velmi důležitý a těžko si lze představit že někdo bude pravidelně ručně kontrolovat všechny databáze.

Monitoring 

Podle našich zkušeností je dobrý monitoring naprosto klíčový nástroj pro správu databáze a výrazně ulehčuje všem administrátorům život. Bohužel ale platí, že čím lepší je monitorovací nástroj, tím méně je vidět potřeba a důležitost administrátora. Když se něco stane s databází a administrátor nic nehlídá, tak mu najednou volají desítky uživatelů a on je pak ta nejdůležitější osoba, která jejich problém vždy vyřeší. Když, ale administrátor používá správný proaktivní monitoring, tak k problému často ani nedojde, protože vše vyřeší ještě než se to stane a uživatelé mu pak jen závidí jakou má klidnou práci.

Existuje opravdu mnoho monitorovacích nástrojů, ale jsou v nich značné rozdíly nejen v tom co vše monitorují, jak jsou snadno modifikovatelné, ale i jak složitou mají architekturu, s čímž souvisí i stabilita a pracnost údržby. Králem všech monitorovacích nástrojů je Enterprise Manager, ale podle našich zkušeností kraluje hlavně kvůli svojí neúměrné velikosti, komplikovanosti a tomu, že je to Oracle produkt. V době, kdy Oracle vydával verzi 8i v roce 2000, tak zdaleka tolik nástrojů neexistovalo, ale jako administrátoři už jsme databáze potřebovali monitorovat, takže prakticky v každém týmu administrátorů vznikaly různé sady nástrojů a skriptů, které pravidelně kontrolovaly alespoň volné místo nebo chyby v alert logu. V těchto dobách jsme postupně všichni vylepšovali svoje monitorovací nástroje podle toho jak rostli naše zkušenosti s tím, co je důležité hlídat a jak jsme si chtěli ušetřit práci různými pravidelnými manuálními kontrolami. Naše nároky na monitorování se neustále zvyšovali jak jsme byli tlačeni spravovat databáze efektivněji a rychleji. Zkušenosti získané při řešení a odhalování různých problémů na různých prostředích a konfiguracích jsme okamžitě promítali do našich předpotopních monitorovacích nástrojů. Pokud se něco stalo jednou, museli jsme vždy počítat s tím, že se to může opakovat a než se to stane, tak to chceme určitě příště vědět.

Už od této doby máme naprosto jasnou představu o tom, jak by měl vypadat ideální monitorovací nástroj, který opravdu pozvedne efektivitu správy na další úroveň:

  • jednoduchost - nechceme si ještě přidělávat práci správou monitoringu
  • flexibilita - snad na každé databázi existují výjimky z obecných pravidel a nechceme je řešit
  • modifikovatelnost - když víme že mnoho problémů lze včas odchytit třeba na aplikační úrovni nebo OS, tak si tam jednoduše chceme doplnit vlastní kontroly
  • historie - nechceme pouze vidět že se něco zrovna děje, chceme vidět i dlouhodobou historii a trend
  • maximum informací - chceme mít maximum užitečných informací o databázi a jejím každodenním provozu
  • pouze to důležité - nechceme se ale zatěžovat tím, s čím stějne nikdo nic neudělá

Když pak přišla doba, kdy monitorovací nástroje začali získávat na důležitosti a mnoho z nich učarovalo svými barevnými grafy nejednomu managerovi, tak jsme se také rozhlíželi po nějakým univerzálním nástroji, který by nahradil naše sice vypiplané a perfektně funkční skripty, ale prezentované nepříliš vábivým obyčejným HTML. Sice jsme otestovali několik krásně vypadajících nástrojů, ale bohužel žádný z nich nesplňoval naše požadavky na funkčnost. To už se ale psal rok 2011 a my jsme se rozhodli, že léty propracovanou monitorovací logiku přepíšeme do mnohem více univerzálního nástroje, který bude schopen efektivně monitorovat jakékoli prostředí i konfiguraci a navíc bude vše prezentovat nějakým moderním způsobem. Jen tím nám může ušetřit náš čas v maximální možné míře. Za chvíli už to bude 10 let postupného vylepšování tohoto nástroje a nelitujeme té spousty času co jsme tomu věnovali.

Takže ?

I když se Oracle svými produkty neustále snaží nám administrátorům zjednodušovat práci, tak to rozhodně zatím nejde tím směrem, že by administrátoři měli méně práce a nebo dokonce nebyli potřeba. Možná se nám trošku zjednodušuje každodenní rutina, ale neustálý přísun nových technologií (Multitenant, Cloud, ...) a verzí nás nutí stále být ve střehu a řešit nové a nové problémy. 

Dnešní administrátoři nemusejí znát do detailu všechny ty Oracle technologie a komponenty k tomu, aby je mohli spravovat ve smyslu "udržovat v běhu", ale administrátor který naprosto přesně ví co dělá, zná důvod a ví co se při tom děje uvnitř, tak je stále v mnoha případech sám o sobě tím nejefektivnějším nástrojem pro správu databáze. Samozřejmě ale jen pokud ho nemusíte platit neustále - pouze když položí ruku na klávesnici a během pár minut udělá bez pomoci googlu vše co je potřeba. A ve spojení s perfektním proaktivním monitorovacím nástrojem nemusí zasahovat moc často.

Překvapuje nás, kolik firem svěřuje své klíčové databáze lidem, kteří se na těch systémech správu databáze teprve učí.

Naši administrátoři spravovali již přes 1500 databází!

Databázový administrátor je zodpovědný za hodně oblastí. Většina firem ale nepotřebuje pokrýt všechny tyto oblasti a stejně musí platit DBA na full time.

Nevíte co se děje s vaší databázi? My Vám to zjistíme.

Nikdo si neumí plně představit jak cenná data má, dokud o ně nepřijde.

Kolik administrátorů je potřeba na správu deseti firemních databází? Dva, aby se mohli zastupovat. Na správu jedné databáze jsou potřeba také dva.