Gyártói Oracle Support vs. Szakértői DBA Támogatás: Mi a különbség?

Sokszor találkozom azzal a felvetéssel IT vezetői vagy cégvezetői oldalon, hogy "Nekünk van érvényes, élő Oracle Support szerződésünk, miért van szükségünk még egy külsős DBA csapatra is?"

Ez egy teljesen jogos kérdés, aminek a megválaszolásához először tisztáznunk kell a két "support" közötti alapvető különbséget. A félreértés súlyos üzemeltetési kockázatokhoz és felesleges költségekhez vezethet.

A Kötelező "Belépőjegy": A Gyártói Oracle Support

Amikor egy cég megvásárolja és fenntartja a hivatalos, gyártói Oracle Support szerződést (ami a support.oracle.com portálon keresztül érhető el), azzal valójában egy szoftverkövetési és terméktámogatási licencet vesz.

Mit tartalmaz ez a support?

• Hozzáférést a Patchekhez: Ez a legfontosabb. Innen tölthetők le a kritikus biztonsági frissítések (Critical Patch Updates / DBRU-k) és hibajavítások.
• Verziókövetést: Jogosultságot biztosít az adatbázis-szoftver újabb verzióira való frissítésre.
• Service Request (SR) nyitása: Lehetőséget ad arra, hogy egyedi, mélyen a szoftverben gyökerező hibák (bugok) esetén közvetlenül az Oracle mérnökeivel vegyük fel a kapcsolatot.

Mit NEM tartalmaz a gyártói support?

És itt jön a lényeg: A gyártói support nem proaktív. Az Oracle nem fog szólni, hogy a te rendszered lassú. Nem fogják monitorozni az adatbázisod állapotát, és nem fogják telepíteni azokat a patcheket, amikért fizetsz.

A gyártói support egy reaktív szolgáltatás: biztosítja a szerszámokat (a patcheket) és egy telefonszámot, amit felhívhatsz, ha már nagy a baj (és bizonyítani tudod, hogy az egy szoftver-bug).

A Valódi Működés Záloga: A Szakértői DBA Támogatás (amit mi nyújtunk)

A mi professzionális Oracle Support szolgáltatásunk nem helyettesíti, hanem kiegészíti a gyártói szerződést. Mi vagyunk az a szakértői csapat, amely a gyártótól kapott "szerszámokat" a gyakorlatban, az ügyfél rendszereire szabva, proaktívan és biztonságosan alkalmazza.

Gyakorlatilag mi vagyunk a "profi pilóta" ahhoz a komplex repülőgéphez, amihez az Oracle a kézikönyvet és az alkatrészeket biztosítja.

Mi az, amit egy ilyen szolgáltatás nyújt a gyártói supporton felül?

• Proaktív Monitoring (7x24): Folyamatosan figyeljük a rendszert. Nem akkor derül ki, hogy megtelt egy tablespace, amikor leáll az éles alkalmazás, hanem órákkal (vagy napokkal) azelőtt jelezzük és megoldjuk.
• Patch Menedzsment: Nem elég letölteni a negyedéves DBRU-t. Azt tesztkörnyezetben telepíteni, validálni, majd az éles rendszeren minimális állásidővel (vagy anélkül) telepíteni – na, ez a valódi DBA feladat.
• Teljesítményhangolás: A gyártói support nem foglalkozik azzal, hogy a fejlesztő által írt SQL lekérdezés miért fut 40 másodpercig 1 másodperc helyett. Mi igen. Felkutatjuk a szűk keresztmetszeteket és optimalizáljuk a működést.
• Azonnali Hibaelhárítás: Ha "megmagyarázhatatlan" Oracle hibákba (ORA-XXXXX) ütközik az alkalmazás, mi azonnal rendelkezésre állunk, és évtizedes tapasztalattal derítjük fel a probléma okát.

"De van Rendszergazdánk!" – A Generalista vs. Specialista esete

Egy másik gyakori érv, hogy "Ezeket megoldja a rendszergazda." A rendszergazdák (system administratorok) fantasztikus munkát végeznek, de ők jellemzően generalisták. Mélyen érteniük kell a hálózatokhoz, a tűzfalhoz, a Windows/Linux szerverekhez, a mentésekhez és még ezer másik dologhoz.

Az Oracle adatbázis-kezelés (DBA) egy külön, mély szakterület.

Egy rendszergazdától elvárni, hogy mélyrehatóan értsen az Oracle patch-elés buktatóihoz, a lekérdezés-optimalizáláshoz vagy egy komplex RMAN mentési stratégia felépítéséhez, olyan, mintha egy kiváló háziorvostól várnánk el, hogy végezzen el egy nyitott szívműtétet. Mindkettő orvos, de a specializáció mélysége teljesen más.

KKV-dilemma: Miért nem éri meg a saját DBA?

Felmerülhet a kérdés, hogy egy közepes vagy akár kisebb vállalkozás (KKV) miért nem vesz fel egyszerűen egy saját, főállású Oracle DBA-t?

A válasz prózai: nem költséghatékony.

Egy tapasztalt, senior Oracle DBA (aki nemcsak egy verzióhoz ért, hanem otthon van a 11g-től a 23ai-ig, és látott már RAC-ot, Data Guardot) az egyik legdrágább erőforrás az IT-piacon.

Egy KKV-nak pedig egyszerűen nincs annyi napi szintű, komplex DBA feladata, ami egy ilyen szakember 8 órás munkaidejét kitöltené. A legtöbb idejében "unatkozna" (miközben a cég fizeti a prémium bérét), vagy ami még rosszabb, rábíznának rendszergazdai feladatokat, amivel a speciális tudása lassan elkopik.

• A kiszervezett, proaktív DBA szolgáltatás (mint a mienk) ennek a költségnek a töredékéért biztosít:
• Folyamatos rendelkezésre állást (szabadság, betegség megoldott).
• Magas szintű szakértelmet (nem egy, hanem egy egész csapat tudását kapja meg).
• Költséghatékonyságot (csak azért a szolgáltatásért fizet, amire valóban szüksége van).

Összegzés

A gyártói Oracle Support egy kötelező alap, a "belépőjegy". De a rendszerek stabil, gyors és biztonságos működéséhez – a valódi üzletmenet-folytonossághoz – elengedhetetlen a proaktív, szakértői DBA támogatás. Ez az a szolgáltatás, ami leveszi a terhet az IT-csapat válláról, és garantálja, hogy az adatbázis ne problémaforrás, hanem az üzlet stabil alapja legyen.

Stabil és gyors Oracle adatbázisra van szüksége ahelyett, hogy folyamatosan a hibákkal küzdene? Ismerje meg professzionális Oracle Support és DBA szolgáltatásainkat!

DBMS_OPTIM_BUNDLE: Az Oracle DBA-k rejtett aduásza (19c, 21c, 23ai, 26ai)

 A hiányzó láncszem a DBRU patch után

Oracle DBA-ként mindannyian rendszeresen patch-elünk. Telepítjük a legújabb Release Update (RU) vagy Release Update Revision (RUR) csomagokat, hogy biztonságban tartsuk rendszereinket és javítsuk a hibákat. De mi történik az optimalizálóval (CBO – Cost-Based Optimizer) kapcsolatos javításokkal?

A legtöbb DBA meglepő módon nem tud róla, vagy nem használja azt a beépített csomagot, ami pontosan ezeknek az optimalizálási javításoknak a központi menedzselésére szolgál: ez pedig a DBMS_OPTIM_BUNDLE.

Pedig a használata óriási előnyökkel járhat, különösen a modern, Oracle 19c, 21c, valamint a 23ai (és annak legújabb, már 26ai néven futó Long Term Support) verzióin. Sokan felteszik az RU-t, és csodálkoznak, hogy egy-egy optimalizálási hiba miért nem javult meg. A válasz gyakran itt rejlik.

Mi az a DBMS_OPTIM_BUNDLE és miért kritikus?

Az Oracle (különösen a 12c verzió óta) óvatos az optimalizáló viselkedésének megváltoztatásával. Egy új patch telepítése során az Oracle alapértelmezetten nem aktiválja automatikusan azokat az optimalizáló (CBO) hibajavításokat, amelyek megváltoztathatják a meglévő SQL futtatási terveket (execution plans).

Miért? A futtatási terv stabilitásának (plan stability) megőrzése érdekében. Egy patch telepítése nem okozhat váratlan, tömeges teljesítményromlást (plan regression) csak azért, mert a CBO hirtelen "okosabb" lett.

Itt jön képbe a DBMS_OPTIM_BUNDLE. Ez a PL/SQL csomag egy kapcsolótábla. Lehetővé teszi számunkra, hogy DBA-ként tudatosan és kontrolláltan döntsünk arról, hogy az adott adatbázisban telepített RU-val érkező összes CBO hibajavítást (a "bundle"-t) bekapcsoljuk-e.

Ha ezt nem tesszük meg, az adatbázisunk ugyan naprakész lesz biztonsági szempontból, de az optimalizálója "régi" logikával fog működni, figyelmen kívül hagyva azokat a javításokat, amiket már telepítettünk.

Mikor futtassuk? A tökéletes időzítés

A DBMS_OPTIM_BUNDLE aktiválásának két kiemelten javasolt időpontja van:

1. DBRU (Release Update) telepítés után

Ez a leggyakoribb eset. Közvetlenül egy RU telepítése és az adatbázis(ok) megnyitása után (post-patch lépésként). Amikor feltelepíted az új RU-t (pl. 19.26-ről 19.29-ra), az új optimalizáló-javítások bekerülnek az adatbázisba, de "kikapcsolt" állapotban. A DBMS_OPTIM_BUNDLE futtatása az a lépés, amivel "élesíted" ezeket a javításokat.

2. Verzióváltás (Upgrade) után

A másik kritikus időpont, amikor egy újabb főverzióra frissítesz (pl. 19c-ről 26ai-ra).

Ez annyira fontos, hogy maga az Oracle is kiemelten ajánlja a hivatalos dokumentációban. A 26ai Upgrade Guide szerint a frissítés befejező, "Post-Upgrade" lépései között szerepel az optimalizáló-javítások engedélyezése, hogy az adatbázis azonnal ki tudja használni az új verzió CBO-fejlesztéseit.

Hivatalos Oracle 26ai ajánlás: "After the upgrade is complete, enable optimizer fixes... Run the DBMS_OPTIM_BUNDLE.ENABLE_OPTIM_FIXES PL/SQL procedure..."

(Forrás: Oracle 26ai Upgrade Guide - Recommended Practices)

Automatikus aktiválás: Így csináld!

Szeretnénk, ha az optimalizáló javításai állandóan, az adatbázis újraindítása után is aktívak maradnának. Ezt a DBMS_OPTIM_BUNDLE.ENABLE_OPTIM_FIXES procedúrával érhetjük el.

Futtasd a következő parancsot SYS felhasználóval (vagy megfelelő jogosultsággal):

execute dbms_optim_bundle.enable_optim_fixes('ON','BOTH', 'YES');

Mit jelentenek a paraméterek?

'ON': A legfontosabb kapcsoló. Ezzel engedélyezzük a bundle-ben lévő összes javítást. (Az 'OFF' értelemszerűen kikapcsolná őket).

'BOTH': Meghatározza, hogy a javítások a szekvenciális (SERIAL) és a párhuzamos (PARALLEL) futtatásokra is érvényesek legyenek. Ez a leggyakoribb és javasolt beállítás.

'YES': Ez a paraméter biztosítja a perzisztenciát. Ha 'YES'-re állítjuk, a beállítás túléli az adatbázis újraindítását is. Lényegében az adatbázis belső konfigurációját módosítja (erről mindjárt).

A háttér: Pár szó a _fix_control paraméterről

A DBMS_OPTIM_BUNDLE csomag valójában egy felhasználóbarát "burkoló" (wrapper) az Oracle rejtett (_fix_control) inicializációs paramétere körül.

Régebben az egyes hibajavításokat (bug fixek) egyenként kellett ki- vagy bekapcsolni ezzel a paraméterrel, ami rendkívül bonyolulttá tette a menedzselést (pl. _fix_control='1234567:OFF').

Amikor a fenti dbms_optim_bundle parancsot futtatjuk a 'YES' opcióval, az Oracle valójában beállít egy init.ora paramétert, ami az adatbázis indításakor betöltődik, és aktiválja az összes, bundle-höz tartozó javítást. Nem kell többé kézzel vadásznunk a _fix_control beállításokra.

Vészfék: Hogyan lehet kikapcsolni?

Bármi megtörténhet. Ha az új javítások bekapcsolása után (és a tesztelés során) azt tapasztaljuk, hogy egy-egy fontos SQL teljesítménye drámaian romlott (plan regression), gyorsan vissza kell tudnunk állni.

A kikapcsolás logikusan történik, lényegében az enable_optim_fixes parancs "ellentettjével":

execute dbms_optim_bundle.enable_optim_fixes('OFF','BOTH', 'YES');

Ez a parancs (a 'YES' paraméter miatt) szintén perzisztensen kikapcsolja a teljes optimalizáló-javítócsomagot, visszaállítva az adatbázist a patch előtti optimalizálási viselkedésre.

A legfontosabb szabály: TESZTELJ!

Ez a cikk legfontosabb bekezdése.

SOHA NE ÉLESÍTSD A DBMS_OPTIM_BUNDLE-T KÖZVETLENÜL ÉLES (PRODUCTION) RENDSZEREN TESZTELÉS NÉLKÜL!

Miért? Mert az optimalizáló-javítások célja pont az, hogy megváltoztassák a futtatási terveket. A legtöbb esetben jobbra. De mindig fennáll a kockázata, hogy egy eddig "tökéletesen" futó (bár lehet, hogy rossz statisztika miatt) SQL terve hirtelen megváltozik, és teljesítményromlást okoz.

A helyes eljárás:

• Klónozd az éles adatbázist egy TESZT vagy UAT környezetbe.
• Telepítsd az új DBRU-t (vagy végezd el az upgrade-et) a teszt környezetben.
• Mérj! Futtasd le a kulcsfontosságú üzleti folyamatokat, batch futásokat. Használj AWR riportokat vagy SQL Performance Analyzer (SPA) eszközt, hogy rögzítsd az alapállapotot (baseline).
• Aktiváld a DBMS_OPTIM_BUNDLE-t a teszt rendszeren (a fent leírt ...('ON','BOTH','YES') paranccsal).
• Mérj újra! Futtasd le ugyanazokat a folyamatokat.
• Elemezz! Keress SQL plan változásokat és regressziókat. Ha találsz romló SQL-t, azt célzottan kezeld (pl. SQL Patch, SQL Plan Management (SPM)), mielőtt élesben gondolkodnál.

Csak a sikeres tesztelés és az esetleges regressziók javítása után végezd el a műveletet az éles rendszeren (természetesen egy karbantartási időablakban).

Összegzés

A DBMS_OPTIM_BUNDLE egy rendkívül hatékony, mégis méltatlanul elhanyagolt eszköz az Oracle DBA-k arzenáljában. Ha eddig csak telepítetted a DBRU-kat vagy frissítettél verziót, de sosem aktiváltad az optimalizálási javításokat, akkor az adatbázisod valójában nem használja ki a patch-elésben rejlő összes lehetőséget.

Kezeld tudatosan, teszteld alaposan, és használd a 19c, 21c, 23ai és 26ai adatbázisaid teljesítményének maximalizálására!

Segítségre lenne szükséged?

Szabadúszó, vizsgázott Oracle szakértőként szívesen segítek akár az Oracle hangolással kapcsolatban.

Oracle DBA Szolgáltatásaim a következőket tartalmazzák:

• Telepítés és konfigurálás
• Adatbázis migrálás
• Hibaelhárítás és optimalizálás
• Tanácsadás és oktatás

Vedd fel velem a kapcsolatot e-mailben a palffy.peter@oracle-szakerto.hu címen, ha bármilyen kérdésed van, vagy árajánlatot szeretnél kérni.

Segítek elérni az Oracle adatbázisokkal kapcsolatos céljaid!