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!
Nincsenek megjegyzések:
Megjegyzés küldése