Kényszerpályán az Oracle Standard Edition 2 felhasználók a modern multi-chip processzorok világában?

Fontos figyelmeztetés: Rögtön a cikk elején le kell szögeznünk egy alapvető ökölszabályt: az Oracle licencelési szabályainak megértése és betartása minden esetben a végfelhasználó (az ügyfél) kizárólagos felelőssége. Nagyon fontos kiemelni, hogy az alábbi cikkben leírtak kizárólag a szerző saját szakmai véleményét és személyes licence-értelmezését tükrözik. Ez az értelmezés nem biztos, hogy minden pontban megegyezik az Oracle hivatalos álláspontjával vagy egy esetleges licenc-audit során a License Management Services (LMS) által alkalmazott jogi értelmezéssel.

Aki ma Oracle Database 19c Standard Edition 2 (SE2) adatbázishoz keres megfelelő, modern fizikai szervert, hamar egy komoly dilemmával találja szembe magát. Az Oracle sajnos nem ad naprakész, pontos útmutatást vagy egyértelmű "fehérlistát" arról, hogy a legújabb – sok esetben chiplet (multi-chip) technológiát használó – processzor-architektúrákat hogyan kell értelmezni licencelés szempontjából.

Az egyetlen konkrét tény és hivatalos fogódzó, amire támaszkodhatunk, az az aktuális "Oracle License Definitions and Rules Booklet" (angolul: https://www.oracle.com/contracts/docs/lic_definitions_and_rules_v031526.pdf, magyarul: https://www.oracle.com/contracts/docs/lic_definitions_and_rules_v031526_hu_hun.pdf). Ebben a dokumentumban három, egymással szorosan összefüggő szabály definiálja a kereteket. Ezek együttes értelmezése okozza a jelenlegi fejtörést.

Először is, hogyan definiálja a dokumentum a foglalatot (socket)?

"Socket: is defined as a slot that houses a chip (or a multi-chip module) which contains a collection of one or more cores. Regardless of the number of cores, each chip (or multi-chip module) shall count as a single socket. All occupied sockets on which the Oracle Program is installed and/or running must be licensed."

Másodszor, mekkora lehet az a szerver, amire az SE2 egyáltalán telepíthető?

"Oracle Database Standard Edition 2 may only be licensed on servers that have a maximum capacity of 2 sockets"

És harmadszor, a legkritikusabb pont, a multi-chip modulokra vonatkozó kivétel az SE2 licencelésnél:

"When licensing Oracle Programs with Standard Edition 2, Standard Edition One or Standard Edition in the product name (...), a processor is counted equivalent to an occupied socket; however, in the case of multi-chip modules, each chip in the multi-chip module is counted as one occupied socket."

A nagy licencelési paradoxon: Kapacitás vs. Elfoglalt foglalat

Ha figyelmesen olvassuk a fenti definíciókat, észrevehetünk egy óriási ellentmondást, egy igazi jogi paradoxont. A Socket definíciója szerint: "each chip (or multi-chip module) shall count as a single socket". Ebből logikusan következhetne, hogy egy fizikailag egyfoglalatos szerver alaplapjába helyezett multi-chip modul (MCM) a "maximum 2 foglalatos kapacitás" szabály szempontjából csupán 1 foglalatnak számít, és legfeljebb csak több licencet kellene fizetnünk a benne lévő chipek után, igaz?

Sajnos a biztonságos értelmezés (és a nemzetközi licenc-szakértők többségének álláspontja) nem ez.

A probléma a harmadik szabálynál, az SE2 specifikus kivételnél csapódik le. Ott az Oracle kimondja: MCM esetén minden egyes chip egy elfoglalt foglalatnak (occupied socket) számít.

Tegyük fel, hogy van egy egyfoglalatos szerverünk, benne egy 4 chipletet tartalmazó modern processzorral. Az SE2 szabály szerint ezen a szerveren 4 elfoglalt foglalat van. Ekkor jön az auditáló könyörtelen logikája: Hogyan futhatna az SE2 egy olyan szerveren, aminek a maximális kapacitása elvileg 2 foglalat, ha a saját szabályaink szerint épp most számoltunk össze rajta 4 elfoglalt foglalatot? Ha 4 elfoglalt foglalat van benne, akkor a kapacitása minimum 4.

Ezzel a logikai lépéssel az MCM processzorok azonnal, visszavonhatatlanul megsértik az SE2 "maximum 2 socket kapacitású szerver" hardveres alapfeltételét. Az eredmény: a Standard Edition 2 használata az adott gépen szabálytalanná válik. Emiatt a paradoxon miatt van az, hogy aki nyugodtan akar aludni, és el akarja kerülni a csillagászati büntetéseket egy esetleges audit során, annak kizárólag a valódi, fizikai "single-chip" processzorok jöhetnek szóba SE2 alá.

Az I/O chiplet csapdája

A helyzetet ráadásul tovább súlyosbítja a modern chiplet alapú gyártástechnológiák egy másik sajátossága is. A legújabb processzorok a számítási magok mellett már külön I/O chipleteket is tartalmaznak, gyakran egy tokozáson belül akár többet is. És itt jön az igazi feketeleves: az Oracle definíciója nem tesz különbséget a lapkák funkciója között!

A licencelési szabályzat nem kizárólag "számítási" (compute) chipekről beszél, hanem általánosságban bármilyen "chipről". Így a legszigorúbb (és egy audit során a legvalószínűbb) értelmezés szerint ezek az I/O chipletek is mind egy-egy külön foglalatnak (socketnek) számítanak az SE2 licencelés során, még tovább növelve a "fiktív" foglalatok számát egyetlen fizikai processzoron belül.

Jogosan merül fel a kérdés: ezen trendek mellett eljön az az idő a közeljövőben, amikor már egyáltalán nem is fogunk tudni fizikai szervert választani ehhez a kiadáshoz?

Ebben a blogbejegyzésben erre a nyugtalanító kérdésre keressük a válaszokat. Megvizsgáljuk, hogy mi a helyzet ma, milyen lehetőségeink maradtak az aktuális processzorok piacán (keresve a "szent grált", a tisztán single-chip megoldásokat), és megpróbáljuk felvázolni, mit tartogat a jövő a Standard Edition felhasználók számára.

Az AMD EPYC helyzete: Ahol a chiplet már régen a standard

Kezdjük a piac áttekintését az AMD-vel, a történetük ugyanis viszonylag rövid, ugyanakkor rendkívül tanulságos. Az AMD volt az a gyártó, aki a szerverpiacon elsőként állt át tömegesen a chiplet (MCM) architektúrára az EPYC processzorcsaláddal. Ennek köszönhetően hatalmas magszámokat értek el, viszont az Oracle SE2 licencelés szempontjából ezzel gyakorlatilag "ki is árazták" magukat a szóba jöhető opciók közül.

Fontos tény: már egyetlen modern AMD EPYC processzor sem "single-chip" (egylapkás) felépítésű. Kivétel nélkül mindegyik több chipletet tartalmaz. Ha szeretnénk pontosan ellenőrizni, hogy egy adott EPYC processzor hány chipletből épül fel, az angol nyelvű Wikipedia kiváló és naprakész forrásként szolgál a témában: https://en.wikipedia.org/wiki/Epyc.

Mégsem teljesen reménytelen a helyzet?

Bár az egylapkás processzorokról az AMD esetében le kell mondanunk, létezik egy érdekes "kiskapu", ami a legkisebb, belépő kategóriás processzoraiknál mégis életképes megoldást jelenthet.

Vegyük például a 4. generációs EPYC (Zen 4) kínálatából a 4124P, 4244P, 4344P, 4364P, 8024P, 8024PN, vagy az 5. generációs (Zen 5) kínálatból a 4245P, 4345P modelleket. Ezeknek a processzoroknak a felépítése megegyezik abban, hogy pontosan 1 db számítási (CCD) és 1 db I/O (IOD) chipletet tartalmaznak. Azaz összesen 2 chipletből állnak.

Mi történik, ha egy ilyen processzort választunk? Ha ezt a 2 chipletet tartalmazó processzort egy olyan szerverbe tesszük, amelynek alaplapja szigorúan csak 1 fizikai processzorfoglalattal (1-socket) rendelkezik, a licencelési matematika hirtelen a mi oldalunkra áll.

Az Oracle szabálya szerint a processzorban lévő 2 chiplet miatt ezen a szerveren 2 "elfoglalt foglalat" (occupied socket) van. Mivel a szerver fizikailag is csak ennyit bír el (hiszen csak 1 fizikai foglalata van, amit tele is tettünk ezzel az 1 db CPU-val), a szerver "maximális kapacitása" pontosan 2 foglalat marad. Így hajszálpontosan, de teljesen legálisan megfelelünk a "maximum 2 socket" korlátnak!

Megéri ez nekünk?

Bár licencelési szempontból ez az összeállítás szabályos, fel kell tennünk a kérdést: üzletileg megéri?

Ha Processzor (CPU) alapon licencelünk: Ez a legfájdalmasabb forgatókönyv. Mivel az Oracle szerint 2 elfoglalt foglalatunk van, a mindössze 1 db fizikai processzorunkra 2 db SE2 Processzor licencet kell vásárolnunk. Tekintve, hogy ezek az AMD CPU-k viszonylag alacsony magszámúak (4-8 mag), a licencdíjhoz viszonyított teljesítményarány nagyon kedvezőtlen lesz.

Ha Felhasználó (NUP - Named User Plus) alapon licencelünk: Itt fordul a kocka! Ha az adatbázis felhasználóinak száma alacsony, és megéri a NUP alapú licencelés, akkor ez a belépő szintű AMD MCM architektúra tökéletes választás lehet. Költséghatékonyan kapunk egy rendkívül modern, gyors technológiát, anélkül, hogy megsértenénk az Oracle szigorú hardveres szabályait.

Az Intel útvesztője: Keresd a monolitikus tűt a szénakazalban

Az Intel háza táján a helyzet lényegesen bonyolultabb. A legnagyobb problémát az információ hiánya jelenti. Az Intel hivatalos termékspecifikációs oldalain (ARK) – és sokszor még a Wikipédián sem – lehet egyértelműen megtalálni, hogy egy adott Xeon processzor típus fizikailag hány chipletből áll. Az Intel ezt az információt láthatóan nem érzi fontosnak kommunikálni, ami alapjaiban nehezíti meg a feladatunkat, hiszen már az Intel is régóta gyárt multi-chip (MCM) processzorokat.

Egyetlen hivatalos forrásként talán az alábbi Intel support oldal említhető: https://www.intel.com/content/www/us/en/support/articles/000099181/processors/intel-xeon-processors.html. Ezen az oldalon a 4. generációs (Sapphire Rapids) Xeonokat már multi-chip modulként hivatkozzák. Bár tegyük hozzá gyorsan: a 4. generációban még szép számmal akadnak monolitikus típusok is, de mivel mi a jövőt és a leginkább aktuális hardvereket vizsgáljuk, ezekre most nem térünk ki. Fókuszáljunk a legmodernebb, 5. és 6. generációra!

A 6. generáció (Sierra Forest és Granite Rapids): A végállomás?

Kezdjük rögtön a legkorszerűbb, csúcskategóriás 6. generációs Xeonokkal ("Sierra Forest" és "Granite Rapids"). Az architektúrák mélyebb részleteiről itt tájékozódhatunk: Sierra Forest Wikipedia és Granite Rapids Wikipedia.

És itt jön a hidegzuhany: Ezen modern csúcsprocesszorok közül EGYIK SEM FELEL MEG az SE2 licenceknek!

Miért? Mert felépítésükből adódóan mindegyik tartalmaz minimum 1 db számítási és 2 db különálló I/O chipletet. Ez már eleve 3 chip egyetlen foglalatban. A korábban bemutatott Oracle definíció alapján ez egy egyfoglalatos szerverben is 3 "elfoglalt foglalatnak" minősül, amivel azonnal és menthetetlenül túllépjük az SE2 "maximum 2 socket kapacitású szerver" szabályát.

Ez az a pont, ahol sok IT szakember valóban úgy érezheti, hogy az Oracle Standard Edition 2 licenccel zsákutcába került a modern hardverek világában.

Szerencsére a helyzet nem teljesen reménytelen. A jelenlegi kínálatban két teljesen járható, biztonságos "menekülőút" is létezik.

A kiút 1. iránya: Az 5. generációs (Emerald Rapids) processzorok

Amíg az 5. generációs Xeonok elérhetőek a piacon, kiváló alternatívát nyújtanak, mert esetükben az Intel még nem alkalmazott különálló I/O chipleteket. Azonban itt is résen kell lenni!

A szabály a következő: az 5. generációs modellek közül az LCC (Low Core Count) és az MCC (Medium Core Count) típusok még egyetlen, monolitikus chipet tartalmaznak. Ezek tökéletesen megfelelnek, és 1 foglalatnak számítanak. Ezzel szemben az XCC (Extreme Core Count) típusok már több chipből épülnek fel, így azok tiltólistásak az SE2 számára!

De hol találjuk meg, hogy melyik processzor LCC, MCC vagy XCC, ha az Intel honlapja hallgat erről? Szerencsére a nagy szervergyártók dokumentációi a segítségünkre sietnek. A HPE például a szervereinek hivatalos specifikációjában tételesen listázza ezt az információt. A https://www.hpe.com/psnow/doc/a50004307enw dokumentumban gyönyörűen ki lehet keresni az egyes processzorokról, hogy melyik lapkadizájnt használják. Ennek a "trükknek" a segítségével találhatunk rendkívül erős, sokmagos processzorokat, amelyek még mindig "single-chip"-nek, azaz egyetlen foglalatnak számítanak az Oracle szemében.

A kiút 2. iránya: A belépő szintű Xeon 6300-as (Raptor Lake) széria

Ha mindenképpen a legújabb, 6. generációs technológiára vágyunk, a megoldást a belépő szintű szerverek piacán találjuk: ez az Intel Xeon 6300-as széria.

Ezek a processzorok a "Raptor Lake" architektúrára épülnek, aminek a legnagyobb előnye jelen esetben az, hogy a felépítése kizárólag monolitikus (egylapkás). Ráadásul ezeket a processzorokat a gyártó eleve úgy tervezte, hogy csak és kizárólag 1 processzorfoglalattal rendelkező szerverekbe telepíthetők.

Egy monolitikus chip egy maximum 1-foglalatos szerverben: ez a konfiguráció minden szempontból, kikezdhetetlenül megfelel a Standard Edition 2 szigorú szabályainak. Az ide tartozó processzorok pontos listáját itt érdemes böngészni: https://en.wikipedia.org/wiki/Raptor_Lake#Server_processors.

Az Oracle által diktált irányok: Célzott terelés az Appliance és a Felhő felé

Ha egy lépést hátralépünk, és megnézzük ezt az egész hardveres és licencelési káoszt, hamar kirajzolódik a nagyobb kép. Ne legyenek illúzióink: az Oracle nagyon is tisztában van a processzorpiac változásaival. A szigorú szabályok megtartása nem a véletlen műve; két nagyon határozott irányba próbálják terelni (vagy mondjuk ki: kényszeríteni) a Standard Edition felhasználókat.

1. irány: Az Oracle Database Appliance (ODA) "kiskapuja"

Az első hivatalos Oracle válasz a "min futtassam a Standard Edition adatbázisomat?" kérdésre a saját mérnöki rendszerük, az Oracle Database Appliance (ODA).

A sors iróniája, hogy az aktuális ODA szerverek belsejében bizony multi-chip AMD EPYC processzorok dübörögnek. Hogyan lehetséges ez, ha az előbb részletesen leírtuk, hogy az SE2 tiltja ezt a kapacitást?

A válasz egyszerű: az Oracle teremtett egy külön licencelési kiskaput, ami kizárólag az ODA szerverekre vonatkozik. A licencszabályzat megengedi, hogy az ODA gépeken az SE2 adatbázis (legyen szó 19c-ről vagy a legújabb 26ai-ról) multi-chip CPU-kon is fusson.

Ám ennek ára van, méghozzá egy beépített "büntetőszorzó" a Processzor licencelésben: ODA esetén Processzor alapú licencelésnél 8 processzormagonként kell 1 db SE2 Processzor licenccel rendelkeznünk.

Ha tehát veszünk egy 32 magos ODA szervert, arra rögtön 4 db SE2 Processzor licencet kell rátennünk. Szerencsére az ODA platform hivatalosan támogatja a kapacitás-menedzsmentet. Ennek köszönhetően szoftveresen korlátozhatjuk az adatbázist mondjuk 16 magra (így csak 2 licencet kell vennünk), a gépben lévő további, felszabaduló erőforrásokat pedig más, nem adatbázis alapú szolgáltatásokra, alkalmazások futtatására allokálhatjuk.

Ha pedig NUP alapon licencelünk, itt is él a minimum 10 NUP / fizikai szerver szabály. A hivatalos licencelési leírás itt érhető el: Oracle Database Appliance Licensing Overview.

Mi a bökkenő az ODA-val?

Leginkább az árcédula és a technológiai váltás kényszere. A legkisebb, belépő szintű ODA szerver (az X11-S) listaára terméktámogatás (support) nélkül is 24 000 USD felett kezdődik. Ez az összeg jócskán túlmutat egy átlagos SE2 ügyfél 1 db fizikai szerverre szánt beszerzési költségkeretén. Ráadásul sok cég egyáltalán nem akar egy teljesen új, egyedi (engineered) technológiát és menedzsment-ökoszisztémát bevezetni az amúgy bejáratott, meglévő hardver- és operációs rendszer platformjai közé.

2. irány: Irány az Oracle Cloud!

A másik erőltetett irány a felhő. Az Oracle üzenete a sorok között olvasva egyre egyértelműbb: ne akarj saját hardvert, ne bajlódj a processzorok chiplet-számolgatásával, ne küzdj az auditok rémével. Költözz fel a teljes adatbázis-infrastruktúráddal az Oracle Cloud Infrastructure (OCI) felhőbe, ahol dedikált PaaS (Platform as a Service) szolgáltatásként, tiszta és átlátható (bár sokszor más jellegű megkötésekkel járó) elszámolásban használhatod az adatbázisodat és még a meglévő Oracle licencedet is hozhatod.

Konklúzió: Merre tovább, Standard Edition?

Több mint 25 éve dolgozom Oracle adatbázis technológiákkal, és ez idő alatt mindig is teljes mellszélességgel kiálltam mellettük, különösen a kisebb és közepes ügyfelek technológiai támogatásakor. Ha összegeznem kellene az eddig leírtakat, kettős érzés van bennem.

Aki eddig már komolyan befektetett az Oracle technológiákba és az SE2 licencekbe, annak – ahogy a fentiekben láthattuk – szerencsére még mindig léteznek on-premise, saját szerveres megoldások. De ne ringassuk magunkat illúziókba: az irányvonal kristálytiszta, és az írás már a falon van. Nagyon közel állunk ahhoz az időszakhoz, amikor az Oracle Database Appliance lesz gyakorlatilag az egyetlen komolyabb számítási kapacitással bíró hardvereszköz, amit saját magunk telepíthetünk és üzemeltethetünk on-premise környezetbe. A független szerverpiacon ugyanis a monolitikus processzorok lassan teljesen a legalsó, belépő szintre szorulnak vissza, vagy – a technológiai fejlődés ezen szakaszában – teljesen el is fognak tűnni.

Várhatunk-e enyhülést az Oracle részéről a licencfeltételekben? Ismerve a gyártó történelmét és üzletpolitikáját: az Oracle-re soha nem volt jellemző, hogy lazítanának a felhasználási és licencelési szabályokon, így én erre a jövőben sem számítanék.

Marad tehát a másik hivatalos út, az Oracle Cloud. Ez a lépés viszont csak akkor válik igazán hatékony és megtérülő választássá, ha az ügyfél a teljes, adatbázisra épülő egyéb architektúráját (alkalmazásszerverek, backend rendszerek) is hajlandó és képes a felhőbe költöztetni.

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

Szabadúszó, vizsgázott Oracle szakértőként szívesen segítek akár az új szerver környezeted megtervezésében, Oracle Database Appliance (ODA) környezet megvalósításában vagy akár az Oracle felhőbe költözésben.

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!

Teszten gyors, élesen lassú? Van megoldás! SQL Plan Baseline másolása adatbázisok között Oracle Standard Edition-ben.

Mi is az SQL Plan Baseline?

Oracle Standard Edition (SE) környezetben az adatbázis teljesítményhangolása sokszor igazi kihívást jelent. Míg Enterprise Edition alatt kényelmesen nyúlhatunk a Diagnostic és Tuning Pack nyújtotta eszközökhöz, addig SE-ben ezek a kényelmi funkciók licencelési okokból nem elérhetőek.

Azonban van egy kiváló és gyakran alulértékelt eszköz a kezünkben, ami Standard Edition esetén is használható a végrehajtási tervek (execution plan-ek) rögzítésére: ez pedig az SQL Plan Baseline (SQL Plan Management).

Ebben a bejegyzésben egy klasszikus problémára mutatok be egy működő megoldást: Mi a teendő, ha egy lekérdezés a teszt/fejlesztői adatbázison tökéletesen fut, de az éles környezetben az Optimizer valamiért egy teljesen más, rossz plan-t választ neki?

A megoldás: áthozzuk a jól teljesítő plan-t az egyik adatbázisból, betöltjük a cél adatbázisba, és fixáljuk, hogy az Optimizer garantáltan ezt használja a jövőben.

A sikeres másolás és működés feltételei

Mielőtt belevágunk a technikai lépésekbe, fontos tisztázni, hogy az áthozott Baseline csak akkor fog működni a cél adatbázison, ha az alábbi feltételek hiánytalanul teljesülnek:

• optimizer_use_sql_plan_baselines paraméter: Ennek az initora / spfile paraméternek TRUE értéken kell lennie a cél adatbázison (ez az alapértelmezett beállítás, de érdemes leellenőrizni a show parameter optimizer_use_sql_plan_baselines paranccsal).
• Adatbázis verzió egyezés: Ideális esetben a forrás és a cél adatbázis verziója (és patch szintje) megegyezik. Egy régebbi verzióból újabba történő mozgatás általában működik, de visszafelé kompatibilitási problémák léphetnek fel.
• Objektumok fizikai megléte: A cél adatbázison is léteznie kell minden érintett táblának, nézetnek, és ami a legfontosabb: az indexeknek, amiket a jó plan használni akar. Ha a teszt rendszeren van egy index, ami az élesről hiányzik, a Baseline nem fog tudni reprodukálódni.
• Pontos SQL szöveg egyezés: Az SQL utasítás szövegének (SQL_TEXT) karakterre pontosan meg kell egyeznie a két rendszeren. A szóközök, sortörések és a kisbetű/nagybetű eltérések is számítanak!
• Azonos parsing schema: A lekérdezést futtató felhasználónak (és a default sémának) egyeznie kell, hogy a táblanevek feloldása ugyanazokra az objektumokra mutasson.

A másolás folyamata lépésről lépésre

(Megjegyzés: Az alábbi kódblokkokban szereplő konkrét azonosítókat – mint például az SQL_ID, SQL_HANDLE, PLAN_NAME – minden esetben cseréld ki a te saját rendszeredből kinyert valós értékekre!)

A folyamatot két részre bontjuk: mit kell csinálnunk a forrás (pl. teszt) adatbázison, és mit a cél (pl. éles) adatbázison.

1. Műveletek a Forrás adatbázison (ahol a jó plan található)

Először is keressük ki a kívánt lekérdezés SQL_ID-ját (például a V$SQL nézetből), majd töltsük be a memóriából (Cursor Cache) egy új Baseline-ba:

DECLARE
  l_plans_loaded  PLS_INTEGER;
BEGIN
  l_plans_loaded := DBMS_SPM.load_plans_from_cursor_cache(
    sql_id => 'f9zrm235uxz05' -- FIGYELEM: Cseréld ki a saját lekérdezésed SQL_ID-jára!
  );
  DBMS_OUTPUT.put_line('Betöltött plan-ek száma: ' || l_plans_loaded);
END;
/

Ellenőrizzük, hogy elkészült-e a Baseline, és jegyezzük fel a PLAN_NAME és SQL_HANDLE értékeket, mert ezekre a későbbiekben szükségünk lesz:

SELECT count(*) FROM dba_sql_plan_baselines;
SELECT plan_name, sql_handle, sql_text, enabled, accepted, fixed, reproduced FROM dba_sql_plan_baselines WHERE created > sysdate-1;

Hogy az Optimizer a cél rendszeren (és itt is) mindenképpen ezt a tervet preferálja, "Fixáljuk" (rögzítsük) a Baseline-t. Az imént lefuttatott lekérdezésből kapott értékeket itt kell felhasználnunk:

DECLARE
  l_plans_altered  PLS_INTEGER;
BEGIN
  l_plans_altered := DBMS_SPM.alter_sql_plan_baseline(
    sql_handle      => 'SQL_386dcefdd6d9ed0e',  -- FIGYELEM: Cseréld ki a saját sql_handle értékedre!
    plan_name       => 'SQL_PLAN_3hvffzrbdmv8f7e560d95', -- FIGYELEM: Cseréld ki a saját plan_name értékedre!
    attribute_name  => 'fixed',
    attribute_value => 'YES'
  );
  DBMS_OUTPUT.put_line('Módosított plan-ek: ' || l_plans_altered);
END;
/

A Baseline-ok közvetlenül nem exportálhatók, ezért létre kell hoznunk egy úgynevezett "staging" (átmeneti) táblát. Ebben a példában egy BASELINE_MOVE nevű felhasználóhoz hozzuk létre a táblát (Természetesen itt tetszőleges sémát, tábla nevet és táblateret is választhatsz):

BEGIN
  DBMS_SPM.CREATE_STGTAB_BASELINE(
    table_name      => 'SPM_STAGETAB',
    table_owner     => 'BASELINE_MOVE',
    tablespace_name => 'USERS'
  );
END;
/

Csomagoljuk (Pack) bele a fixált Baseline-unkat az imént létrehozott staging táblába (itt is a saját azonosítóinkat kell megadni):

DECLARE
  my_plans NUMBER;
BEGIN
  my_plans := DBMS_SPM.PACK_STGTAB_BASELINE(
    table_name  => 'SPM_STAGETAB',
    table_owner => 'BASELINE_MOVE',
    enabled     => 'yes',
    plan_name   => 'SQL_PLAN_3hvffzrbdmv8f7e560d95', -- FIGYELEM: Cseréld ki a saját plan_name értékedre!
    sql_handle  => 'SQL_386dcefdd6d9ed0e'  -- FIGYELEM: Cseréld ki a saját sql_handle értékedre!
  );
  DBMS_OUTPUT.put_line('Csomagolt plan-ek: ' || my_plans);
END;
/

2. Az adatok átmozgatása (Export / Import)

A staging táblát át kell vinnünk a cél adatbázisba. Ezt megtehetjük Data Pump (expdp/impdp) segítségével is, de ha egyszerűbb (vagy nem férünk hozzá a szerver fájlrendszeréhez), a jól bevált hagyományos exp/imp kliens parancsok is tökéletesek – arra figyeljünk, hogy az export/import kliens verziója lehetőleg egyezzen az adatbázis verziójával.

Operációs rendszer parancssorban (Forrás oldal):

exp BASELINE_MOVE@forras_db tables=SPM_STAGETAB file=SPM_STAGETAB.dmp log=exp_baseline.log

Operációs rendszer parancssorban (Cél oldal):

imp BASELINE_MOVE@cel_db tables=SPM_STAGETAB file=SPM_STAGETAB.dmp log=imp_baseline.log

3. Műveletek a Cél adatbázison (ahol a rossz plan fut)

Miután az import lezajlott, jelentkezzünk be a cél adatbázisba. Érdemes megnézni, vannak-e már korábbi Baseline-ok:

SELECT count(*) FROM dba_sql_plan_baselines;

Csomagoljuk ki (Unpack) a Baseline-t az importált staging táblából az adatbázis Data Dictionary-jébe:

SET SERVEROUTPUT ON
DECLARE
  l_plans_unpacked  PLS_INTEGER;
BEGIN
  l_plans_unpacked := DBMS_SPM.unpack_stgtab_baseline(
    table_name  => 'SPM_STAGETAB',
    table_owner => 'BASELINE_MOVE'
  );
  DBMS_OUTPUT.put_line('Kicsomagolt plan-ek: ' || l_plans_unpacked);
END;
/

Ellenőrizzük, hogy a Baseline sikeresen létrejött-e és aktív-e az új környezetben:

SELECT sql_handle, plan_name, enabled, accepted, fixed, origin, reproduced 
FROM dba_sql_plan_baselines 
WHERE created > sysdate-1;

Fontos: A REPRODUCED oszlop értéke YES kell, hogy legyen. Ez jelenti azt, hogy az Optimizer sikeresen újra tudta építeni az áthozott tervet a cél adatbázis meglévő objektumai és indexei alapján.

Ha a feltételek adottak voltak, és a lekérdezés legközelebb lefut, az adatbázis már ezt, a rögzített Baseline-t fogja használni!

Mit tegyünk, ha mégsem vált be? (Rollback)

Ha bármilyen oknál fogva a Baseline problémát okoz, vagy mégsem hozza a várt teljesítményt az adott rendszeren, egyszerűen kidobhatjuk a rendszerből a következő PL/SQL blokk futtatásával:

SET SERVEROUTPUT ON
DECLARE
  drop_result PLS_INTEGER;
BEGIN
  drop_result := DBMS_SPM.DROP_SQL_PLAN_BASELINE(
    sql_handle => 'SQL_386dcefdd6d9ed0e',  -- FIGYELEM: Cseréld ki a saját sql_handle értékedre!
    plan_name  => 'SQL_PLAN_3hvffzrbdmv8f7e560d95'  -- FIGYELEM: Cseréld ki a saját plan_name értékedre!
  );
  DBMS_OUTPUT.put_line('Törölt plan-ek száma: ' || drop_result);
END;
/

Remélem, ez a kis útmutató sokatoknak segít a Standard Edition alatti teljesítményhangolás rögös útján. Ha kérdésetek van, vagy elakadtatok a folyamat közben, tegyétek fel kommentben!

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

Szabadúszó, vizsgázott Oracle szakértőként szívesen segítek Oracle adatbázis hangolással, tuningal kapcsolatban is.

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!

Végre itt van! Letölthető az Oracle Database 26ai LTS Linux x64-re

Hosszú várakozás után elérkezett a pillanat: végre megjelent és letölthető az Oracle legújabb Long Term Support (LTS) verziója, a 26ai, Linux x64 platformra (On-Premise)!

Ez egy mérföldkőnek számító esemény az adatbázis-adminisztrátorok és üzemeltetők életében, hiszen hosszú ideje vártunk arra, hogy a legújabb innovációkat a saját adatközpontjainkban is használhassuk. De mit is jelent ez pontosan, és hogyan érdemes nekilátni az átállásnak?

23c? 23ai? Nem, ez már a 26ai!

Az első és legfontosabb tisztázandó kérdés a verziószám körüli kavarodás. Sokan emlékezhetnek rá, hogy ezt a kiadást eredetileg Oracle 23c néven harangozták be. Később, a mesterséges intelligencia fókuszának erősödésével átnevezték 23ai-ra, végül pedig a mostani megjelenéssel megkapta a 26ai elnevezést.

Fontos hangsúlyozni: a motorháztető alatt az alapok azonosak. Ez a verzió az eredeti 23c/23ai egyenes ági folytatása és véglegesítése, csupán a név változott, hogy tükrözze a kiadás évét és az AI képességek integrációját.

Új, mégis kiforrott? A "Cloud-first" előnye

Bár On-Premise környezetbe csak most érkezett meg, ez a szoftver valójában már 2023 óta élesben fut. Eddig kizárólag az Oracle Cloud (OCI), Exadata és ODA (Oracle Database Appliance) környezetekben volt elérhető.

Miért jó hír ez nekünk, földi halandóknak, akik saját vasakon futtatjuk az adatbázisokat?

Személyes szakértői véleményem, hogy bár a 26ai egy "friss" telepítőnek tűnik, nem kell tartanunk a verzióváltásokkor szokásos kezdeti gyerekbetegségektől és komolyabb bugoktól. Gondoljunk bele: a felhőben futó szerverek alatt is Linux x64 dolgozik. Ez azt jelenti, hogy az Oracle mérnökei és a cloud ügyfelek már közel 3 éve tesztelik, nyúzzák és patchelik ezt a kódbázist éles környezetben. A kritikus hibákat, amelyektől egy "v1.0-ás" megjelenésnél félnénk, a felhős környezetekben már régen javították. Így mi most egy kifejezetten stabil, érett verziót kapunk kézhez.

Hogyan alakul a jövő? Roadmap és Támogatás

Az új verzió megjelenése mindig felveti a kérdést: mikor kell váltani? Nézzük a számokat és a hivatalos támogatási ciklusokat (lásd a mellékelt roadmap-et):

Forrás: Oracle Support Note 742060.1

Oracle 19c: A jelenlegi legelterjedtebb LTS verzió támogatása (Premier Support) egészen 2029. december 31-ig tart.

Oracle 26ai: Az új LTS verzió Premier Support vége jelen állás szerint 2031. december 31.

Mit jelent ez a gyakorlatban? Nincs ok pánikra, és nem szükséges azonnal, kapkodva "in-place" upgrade-et végezni a jövő héten. A 19c még évekig biztonságos hátországot nyújt.

Ugyanakkor a 2031-es dátum kapcsán érdemes egy kis spekulációba bocsátkozni. Ha visszatekintünk a korábbi, rendkívül sikeres LTS verziókra (mint a 11gR2 vagy a 19c), láthatjuk, hogy az Oracle hajlamos volt a támogatási ciklusokat jelentősen meghosszabbítani az eredeti tervekhez képest. Bár ez csak spekuláció, nem lennék meglepve, ha a 26ai életciklusa is hasonlóan alakulna a jövőben.

Mi a teendő most?

Bár a kényszer nem azonnali, az upgrade tervezést mindenképpen érdemes elkezdeni.

Ez különösen igaz azokra a szoftverfejlesztő cégekre és vállalkozásokra, akik Oracle adatbázisra épülő alkalmazásokat szállítanak. Itt az idő letölteni a 26ai-t, felhúzni egy tesztkörnyezetet, és megvizsgálni, hogyan viselkedik rajta az alkalmazásunk, illetve kihasználni az új funkciókat (pl. JSON Relational Duality, AI Vector Search).

Én már tesztelek!

Jómagam nem vártam tovább: már el is kezdtem a telepítési eljárások és az upgrade lehetőségek tesztelését a laboromban. Folyamatosan gyűjtöm a tapasztalatokat a migrációs útvonalakról és a teljesítményről.

Ha a te cégednél is aktuális kérdés az adatbázis jövője, vagy bizonytalan vagy a frissítési stratégiában, fordulj hozzám bizalommal! Szívesen segítek a tervezésben és a saját adatbázis upgrade folyamataid támogatásában, hogy az átállás zökkenőmentes legyen.

Hasznos linkek és letöltés

Az alábbi hivatalos források segítenek az elindulásban:

Letöltés (Linux x64): Oracle Database 26ai szoftver letöltése

Telepítési útmutató: Hivatalos Oracle Install Guide

Szakértői segítség:

A verzióváltás vagy a patch telepítés bonyolult feladat lehet. Szabadúszó, vizsgázott Oracle szakértőként szívesen segítek a feladatok tervezésében, kivitelezésében.

Szolgáltatásaim többek között 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
• Backup, recovery tervezés
• Oracle Hardening, audit beállítások

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!