Licenční asymetrie, se kterou nikdo nepočítá: Autonomous AI Database versus Exadata Database Service

Skoro každý projekt Oracle Exadata Cloud@Customer, který vidíme, narazí na tutéž debatu. A skoro vždycky jsou to tři otázky zamotané do jedné.

Kde platforma běží? Kdo provozuje databázovou vrstvu? Jak se platí nárok na software Oracle?

Cloud@Customer odpovídá na první. Autonomous versus Exadata Database Service na druhou. License Included versus BYOL na třetí. Jsou nezávislé — a právě jejich sloučení do jediného rozhodnutí „Autonomous, nebo DBaaS?" vede k závěrům, které rozebíráme níže.

Začněme kategoriální chybou

Cloud@Customer není alternativou k Autonomous Database. Je to infrastruktura Exadata ve vlastnictví a správě Oracle, umístěná ve vašem datovém centru — a hostuje obě databázové služby, často na stejném racku a současně:

• ExaDB-C@C — Exadata Database Service on Cloud@Customer. Spoluřízená. Držíte root na databázových VM.
• ADB-C@C — Autonomous AI Database na Exadata Cloud@Customer. Plně řízená. Bez přístupu zákazníka k OS.

Obě jsou Database as a Service. Označovat jednu z nich za „DBaaS" v protikladu k té druhé je kategoriální chyba — a je zdrojem většiny zmatku.

Mýtus o RAC

V zasedačce uslyšíte tvrzení: „Autonomous nepotřebuje licence RAC, DBaaS je potřebuje povinně."

V tomto znění to není správně. Přesná verze zní:

V režimu License Included nevyžaduje ani jedna služba, abyste kupovali samostatnou trvalou licenci RAC — RAC je v předplatném tak jako tak. V režimu BYOL závisí požadavek na RAC na službě, topologii a alokované kapacitě. U Autonomous jde o kapacitní práh. U Exadata Database Service o otázku topologie.

Konkrétně v režimu BYOL:

• ADB-C@C vyžaduje nárok na RAC teprve tehdy, když jedna Autonomous Database překročí 16 OCPU, ekvivalentně 64 ECPU. Pod touto hranicí stačí Enterprise Edition.
• ExaDB-C@C vyžaduje nárok na RAC pro jakoukoli databázi se dvěma a více instancemi — bez prahu, bez výjimky.
• ExaDB-C@C na jednouzlovém VM clusteru nevyžaduje nárok na RAC vůbec. Oracle uvedl „VM Cluster on a Single VM" právě proto, aby jednoinstanční zátěže mohly běžet bez licencí RAC.

Pokud jste se z opatrnosti vyhýbali převodu OCPU na ECPU, přestaňte. Oracle publikuje prahovou hodnotu v obou metrikách a poměr pro RAC nad ní je 1 procesorová licence na 2 OCPU, resp. 8 ECPU.

Číslo, které skutečně vyčísluje vaši expozici

Jedna procesorová licence Oracle Database Enterprise Edition pokrývá 8 ECPU — ekvivalentně 2 OCPU — a to jak na Autonomous AI Database, tak na Exadata Database Service. Standard Edition 2 pokrývá 16 ECPU, ale je tvrdě omezena na 16 ECPU na jednu instanci Autonomous.

Dva důsledky, které se běžně přehlížejí:

1. Nárok se měří proti zapnutým ECPU napříč VM clustery, nikoli proti počtu databází. Konsolidace 80 databází na méně clusterů sama o sobě nesnižuje to, co musíte vlastnit. Snižuje to snížení zapnutých ECPU.
2. Zahrnuje špičkovou kapacitu dosaženou při škálování. Automatické škálování výpočetního výkonu u Autonomous může spotřebovat až trojnásobek nakonfigurovaného počtu ECPU. V režimu BYOL jde o tichou nadspotřebu, pokud na každé databázi nenastavíte explicitní limit BYOL ECPU. Viděli jsme to zapnuté v demo prostředích, aniž by si někdo uvědomil licenční dopad.

A teď ta asymetrie

Následující část obrací intuici většiny lidí naruby.

V režimu BYOL po vás Autonomous chce vlastnit Enterprise Edition a v podstatě nic dalšího. Spoluřízená služba po vás chce vlastnit každou option, kterou zapnete.

Pro jakékoli prostředí, které stojí na Partitioningu, Advanced Compression, In-Memory nebo Multitenantu — a to je většina vyzrálých prostředí Oracle — tedy platí, že Autonomous vyžaduje podstatně menší vlastněný nárok než Exadata Database Service pro tutéž zátěž. Instinkt, že „plně řízená služba musí být ta dražší", je v případě BYOL přesně obrácený.

Dvě provozní fakta, která mění architekturu

Rolling údržba infrastruktury není pro jednoinstanční databáze zadarmo. Oracle záplatuje infrastrukturu Exadata čtvrtletně, metodou rolling, vždy jeden databázový server — a rolling znamená, že virtuální stroje na aktualizovaném serveru se vypnou, zazáplatují a nastartují. Dvouuzlový RAC nebo Autonomous cluster to přežije bez výpadku. Jednouzlový VM cluster ne: jeho databáze se zastaví.

Je to podstatné, protože „jednouzlový VM cluster kvůli úspoře licencí RAC" je oblíbený a legitimní návrh. Jen není zadarmo. Vyměňujete nárok na RAC za runbook přepnutí Data Guard, který musíte vytvořit, otestovat a spustit před každým oknem údržby — a tato orchestrace je odpovědností vaší, ne Oracle.

Autonomous Data Guard chrání kontejner, nikoli databázi. Na Cloud@Customer se konfiguruje na Autonomous Container Database. Jednotkou přepnutí a převzetí je tedy celý kontejner a všechny databáze v něm. Databáze s odlišnými cíli RPO/RTO, odlišnými okny údržby nebo odlišnou kritičností nesmějí sdílet jeden kontejner. Vaše mapování databází na kontejnery je váš návrh obnovy po havárii a musí být rozhodnuto před migrací, ne objeveno po ní.

Ještě jedna past: PDB

Oracle Database 19c Enterprise Edition vám dává až tři uživatelské PDB na jednu CDB bez option Multitenant. Čtvrtá ji už vyžaduje — a Oracle limit technicky nevynucuje, takže její vytvoření prostě proběhne a tiše založí licenční expozici.

Pokud konsolidujete velké prostředí na hrstku kontejnerových databází ExaDB, tuto hranici překročíte. Buď vlastněte Multitenant, nebo nastavte MAX_PDBS=3 jako tvrdé zábradlí, nebo konsolidaci umístěte na Autonomous, kde je Multitenant zahrnut.

Jak se skutečně rozhodnout

Přestaňte licencování prezentovat jako „Autonomous versus DBaaS". Prezentujte je jako výpočet:

   Služba            (ADB-C@C nebo ExaDB-C@C)
 + Topologie         (jednouzlová, RAC, Data Guard, Active Data Guard)
 + Kapacita          (zapnuté ECPU, včetně špičky autoškálování)
 + Zapnuté options   (Multitenant, Partitioning, In-Memory, ...)
 + Komerční model    (License Included nebo BYOL)
 = Požadovaný nárok

A nezapomeňte na standby. Standby databáze Data Guard není pokryta desetidenní výjimkou pro failover — ta se vztahuje na nelicencovaný failover uzel v clusteru se sdíleným úložištěm, nikoli na standby s vlastní kopií dat. Každá standby nese stejný nárok jako její primary a její otevření v režimu read-only pro reporting vtahuje do hry Active Data Guard na obou stranách.

Poctivá výhrada

Nic z výše uvedeného není licenční stanovisko závazné pro Oracle. Poměry a seznamy zahrnutých položek žijí v Oracle Cloud Service Descriptions a v ceníku platném k datu vaší objednávky a Oracle je reviduje. Publikované údaje berte jako podklad pro otázku, ne jako odpověď: nechte si převodní poměr, prahovou hodnotu v ECPU, seznam zahrnutých options a řešení Multitenantu potvrdit písemně vůči vlastnímu objednávkovému dokumentu dřív, než zafixujete architekturu nebo vyřadíte licenci.

Technický důkaz vás také nezachrání. Nepokoušejte se dokládat nárok z V$OPTION, inicializačních parametrů, nainstalovaných binárek nebo počtu viditelných instancí — v cloudové službě je většina options technicky přítomna bez ohledu na to, za co platíte. Dokladem je licenční model evidovaný na zdroji, podepsaná objednávka a vaše vlastní supportní evidence.

---

Solutia s.r.o. navrhuje a migruje databázové platformy Oracle. Pokud dimenzujete licenční pozici BYOL pro Cloud@Customer a chcete si nechat propočet ověřit dřív, než doputuje na objednávku, ozvěte se nám (sales@solutia.cz).