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!

Oracle PDB klónozás hálózati kapcsolat nélkül: Az XML alapú "Cold Clone" módszer

Oracle DBA-ként gyakran találkozunk olyan helyzetekkel, amikor a tankönyvi megoldások ("csinálj egy DB linket és klónozd át") nem működnek. Mit tehetünk, ha egy PDB-t kell átmozgatnunk egy teljesen izolált környezetbe, a forrás adatbázis NOARCHIVELOG módban fut, és szigorú elvárás, hogy az eredeti példány érintetlen maradjon?

A mai bejegyzésben egy klasszikus, "offline" migrációs forgatókönyvet veszünk végig lépésről lépésre. A feladatunk egy PDB1 nevű adatbázis átmásolása (klónozása) egy CDB1 környezetből egy másik szerveren futó CDB2-be.

A Kihívások

• Hálózati izoláció: A két szerver nem látja egymást, nincs CREATE DATABASE LINK lehetőség.
• NoArchivelog: A forrás adatbázis nincs archiváló módban, így "menet közbeni" (hot) mentés nem garantál konzisztenciát.
• No Unplug: Nem választhatjuk le (unplug) a PDB-t, mert a forrás oldalon az üzletmenetnek folytatódnia kell a másolás után azonnal.
• Windows környezet: A példában Windows szervereket és fájlrendszert használunk, de Linux környezetben is működik az eljárás.

0. Lépés: Az Előfeltételek (A "nulladik típusú" hibák elkerülése)

Mielőtt egyetlen parancsot is kiadnánk, egy kritikus dolgot ellenőriznünk kell: A Kompatibilitást.

A fizikai másoláson alapuló PDB mozgatás (plug-in) csak akkor működik zökkenőmentesen, ha:

• Architektúra: Azonos (pl. mindkettő 64-bit Windows). Az Endianness (bájtsorrend) egyezése kötelező.
• Verzió: A forrás és cél adatbázis fő verziója (pl. 19c) megegyezik.
• Patch Level: Ideális esetben a Release Update (RU) szint is egyezik.

Mi történik, ha nem egyeznek? Ha a verziók eltérnek (pl. régebbi RU-ról megyünk újabbra), a csatolás után az adatbázis gyakran RESTRICTED módban nyílik meg, és futtatni kell a datapatch utility-t vagy upgrade szkripteket. Ha az architektúra (OS) teljesen más, akkor ez a módszer nem működik, helyette a Data Pump (expdp/impdp) a barátunk.

I. A Forrás Szerver (CDB1) előkészítése

Mivel NOARCHIVELOG módban vagyunk, a fájlmásolás idejére az adatfájloknak inaktívnak, konzisztensnek kell lenniük. Ehhez a PDB-t írásvédetté (Read Only) tesszük az XML generálás idejére, majd lezárjuk a fizikai másoláshoz.

Helyszín: Forrás Szerver, SQL*Plus (vagy kedvenc eszközöd)

• Állítsuk le, majd nyissuk meg Read Only módban a PDB-t. Ez biztosítja a konzisztens állapotot (checkpoint) és, hogy ne írjon senki az adatbázisba.

ALTER PLUGGABLE DATABASE PDB1 CLOSE IMMEDIATE;
ALTER PLUGGABLE DATABASE PDB1 OPEN READ ONLY;

• Készítsük el a PDB leíró XML fájlt. Ez a fájl tartalmazza a PDB metaadatait (fájlok helye, GUID, stb.). Fontos: A DBMS_PDB.DESCRIBE használatával nem választjuk le (unplug) az adatbázist, csak készítünk róla egy leírást.

ALTER SESSION SET CONTAINER = PDB1;
SHOW CON_NAME -- Ellenőrzés: biztosan a PDB1-ben vagyunk?
EXEC DBMS_PDB.DESCRIBE(pdb_descr_file => 'F:\PDB_COPY\XML\PDB1.xml');
-- Az XML fájlt a hordozható meghajtóra (F:) generáljuk

• Zárjuk be a PDB-t a másoláshoz. Windows alatt a fájlok zárolva vannak, amíg az adatbázis nyitva van. A másoláshoz be kell zárnunk.

ALTER SESSION SET CONTAINER = CDB$ROOT;
ALTER PLUGGABLE DATABASE PDB1 CLOSE IMMEDIATE;

• Fájlmásolás (OS szinten). Most másoljuk át a teljes adatbázis könyvtárat a hordozható tárolóra (F:).

Forrás útvonal: E:\oracle\oradata\CDB1\PDB1 Cél útvonal: F:\PDB_COPY\PDB1

• Forrás újraindítása. Amint a másolás kész, a forrás szerveren az élet mehet tovább.

ALTER PLUGGABLE DATABASE PDB1 OPEN;

II. Átmozgatás

Fizikailag csatlakoztassuk át az F: meghajtót (USB diszk, SAN LUN, stb.) a cél szerverhez.

III. A Cél Szerver (CDB2) műveletek

A cél szerveren az adatbázis fájlok a D:\ meghajtón laknak majd, nem az E:\-en, mint a forráson. Ezt a konverziót kezelnünk kell.

Helyszín: Cél Szerver, SQL*Plus (CDB2)

• Kompatibilitás ellenőrzése. Mielőtt megpróbálnánk beolvasztani az adatbázist, kérdezzük meg az Oracle-t, hogy tetszik-e neki az XML és a fájlok állapota.

SET SERVEROUTPUT ON
DECLARE
  v_compatible BOOLEAN;
BEGIN
  -- Ellenőrizzük, hogy a PDB1 név és az XML fájl tartalma illeszkedik-e a CDB2-höz
  v_compatible := DBMS_PDB.CHECK_PLUG_COMPATIBILITY(
    pdb_descr_file => 'F:\PDB_COPY\XML\PDB1.xml',
    pdb_name       => 'PDB1'
  );
  IF v_compatible THEN
    DBMS_OUTPUT.PUT_LINE('Az XML kompatibilis, a PDB létrehozható.');
  ELSE
    DBMS_OUTPUT.PUT_LINE('Kompatibilitási problémák vannak! Lásd a PDB_PLUG_IN_VIOLATIONS nézetet.');
  END IF;
END;
/

• Ha a kimenet hibát jelez, nézzük meg a részleteket:

SELECT time, type, message, status, action 

FROM pdb_plug_in_violations 

WHERE name = 'PDB1' 

ORDER BY time;

• A PDB létrehozása (Klónozás). Itt történik a varázslat. Mivel a fájlok jelenleg az F: meghajtón vannak (másolat), de az XML eredetileg az E: meghajtóra hivatkozott, és mi véglegesen a D: meghajtóra akarjuk tenni őket, két konverziót kell használnunk:

AS CLONE: Ez jelzi az Oracle-nek, hogy ez egy új DB ID-val rendelkező másolat lesz, nem az eredeti mozgatása.

SOURCE_FILE_NAME_CONVERT: Megmondja, hogy az XML-ben lévő útvonalak (E:\...) helyett hol keresse most a fájlokat (F:\...).

FILE_NAME_CONVERT: Megmondja, hogy a jelenlegi helyről (F:\...) hova másolja őket véglegesen a COPY kapcsoló segítségével (D:\...).

CREATE PLUGGABLE DATABASE PDB1

  AS CLONE

  USING 'F:\PDB_COPY\XML\PDB1.xml'

  SOURCE_FILE_NAME_CONVERT = ('E:\oracle\oradata\CDB1\PDB1\', 'F:\PDB_COPY\PDB1\')

  FILE_NAME_CONVERT = ('F:\PDB_COPY\PDB1\', 'D:\oracle\oradata\CDB2\PDB1\')

  COPY; -- Ez végzi el a fizikai másolást F-ről D-re

• Megnyitás. Ha a CREATE sikeres volt, nyissuk meg az adatbázist.

ALTER PLUGGABLE DATABASE PDB1 OPEN;

• Ellenőrzés

SELECT name, open_mode, restricted FROM v$pdbs WHERE name = 'PDB1';

• Végül ne felejtsük el elmenteni az állapotot, hogy a CDB2 újraindításakor a PDB1 is automatikusan elinduljon:

ALTER PLUGGABLE DATABASE PDB1 SAVE STATE;

Összegzés

Ezzel a módszerrel sikeresen klónoztunk egy PDB-t hálózati kapcsolat nélkül, a fájlrendszeren keresztül, miközben az eredeti forrás adatbázist csak minimális időre kellett leállítani (a fájlmásolás idejére), és nem végeztünk rajta visszafordíthatatlan UNPLUG műveletet.

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

Szabadúszó, vizsgázott Oracle szakértőként szívesen segítek akár az Oracle adatbázisok klónozásával, másolásával 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!

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!

Megérkezett a 2025 októberi Oracle adatbázis DBRU frissítés (19c, 21c, 23ai/26ai)

 Megérkezett a legfrissebb, 2025. októberi Oracle Critical Patch Update (CPU). Ahogy már megszokhattuk, ez a negyedéves frissítési csomag tartalmazza a legújabb biztonsági javításokat és általános frissítéseket az Oracle adatbázis termékeihez, beleértve a 19c, 21c és a már 26ai-nak nevezett 23ai verziókat is.

Minden részletes információt a https://support.oracle.com oldalon, a "Critical Patch Update (CPU) Program Oct 2025 Patch Availability Document (DB-only) (Doc ID 3102899.1)" dokumentumban találtok meg. Ebben a bejegyzésben a szokásos módon kiemeljük a legfontosabb tudnivalókat.

A 3102899.1 dokumentum "3.1.7 Oracle Database" pontja alatt találhatóak az adatbázishoz köthető frissítések listája. Lássuk, mely fő verziókhoz érhető el javítás.

Oracle 26ai (korábban 23ai)

Érdekes változás, hogy a 23ai verziót a leírás már 26ai-nak nevezi, bár a frissítés számozása még 23.26.0.0.0. A legfontosabb tudnivaló ezzel a verzióval kapcsolatban továbbra is az, hogy a 23ai / 26ai kizárólag Cloud Services, Exadata és ODA Engineered Systems rendszereken érhető el. Hagyományos, ügyfél oldali (on-premise) telepítés továbbra sem elérhető.

Oracle 21c

A 21c verzióhoz kiadott frissítés pontos verziószáma: 21.20.0.0.251021. Ahogy azt már többször kiemeltük, a 21c nem LTS (Long-Term Support) verzió, és a támogatása hamarabb lejár, mint a 19c verzióé. Emiatt továbbra sem ajánljuk a 21c éles környezetben történő használatát. Ennek megfelelően most nem is térünk ki a patchek további részleteire, a pontos információk az elején említett support dokumentumban (Doc ID 3102899.1) megtalálhatóak.

Oracle 19c

Ahogy várható volt, a fókuszt ismét a 19c, mint jelenlegi LTS verzió kapja.

Elérhetőség 

A patchek már elérhetőek Linux x64 operációs rendszerekre. Az egyéb UNIX és Windows verziók elérhetőségét csak november 4-re ígérik. Fontos megjegyzés, hogy a Windows esetén a korábbi megjelenések alapján számítani kell arra, hogy ez a dátum még tovább csúszhat.

Ajánlott patchek listája 

A következő főbb patchek jelentek meg, amiket érdemes telepíteni:

• Database Release Update 19.29.0.0.251021 Patch 38291812 for Linux/UNIX (Ezt adatbázis HOME-ra kell telepíteni Linux/UNIX platformon)
• GI Release Update 19.29.0.0.251021 Patch 38298204 (Ezt Grid Infrastructure HOME-ra kell telepíteni Linux/UNIX platformon)
• Microsoft Windows 32-Bit and x86-64 BP 19.29.0.0.251021 Patch 38111211 (Ezt adatbázis HOME-ra kell telepíteni Windows platformon)
• OJVM Release Update 19.29.0.0.251021 Patch 38194382 (Ezt adatbázis HOME-ra kell telepíteni minden platformon)

Combo Patchek

Linux/Unix verziókra elérhetőek az úgynevezett Combo patchek is, amikben egybe csomagolják az OJVM és DBRU, illetve az OJVM és GI frissítéseket. A telepítés egyszerűsítése érdekében ezen patch-ek letöltését ajánljuk inkább az előzőek helyett:

• Combo OJVM Release Update 19.29.0.0.251021 and Database Release Update 19.29.0.0.251021 Patch 38273545 for Linux/UNIX
• Combo OJVM Release Update 19.29.0.0.251021 and GI Release Update 19.29.0.0.251021 Patch 38273558

Java frissítés

Fontos tudnivaló, hogy a DBRU patch telepítése után az ORACLE_HOME-ban található Java (JDK) soha nem a legutolsó verzió lesz, hanem jellemzően az eggyel régebbi. Amennyiben szeretnénk, hogy ez is az aktuális legfrissebb verzióra kerüljön (ami jelenleg a 8u471), akkor telepíteni kell még a következő patchet is:

• JDK8u471 Patch 38245243

Fontos megjegyzések a telepítéshez

Mint minden patch telepítésnél, most is érdemes észben tartani a legfontosabb szabályokat:

• A letöltésnél mindig figyeljünk a platformra és a bitszámra!
• A telepítéshez szükséges a legfrissebb 12.2.0.1.x Opatch utility, melyet a 6880880 patch letöltésével kaphatunk meg.
• A patch telepítési leírásokat (README) mindig alaposan nézzük át!
• Adatbázisok esetén nem csak a szoftver telepítést (opatch apply) kell elvégezni, hanem az adatbázisokon is szükséges a megfelelő telepítés elvégzése (lásd a leírásokban a datapatch részt).
• Először minden esetben teszt környezetre telepítsünk, és csak sikeres alkalmazás teszt után kövesse ezt az éles környezet!

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

Szabadúszó, vizsgázott Oracle szakértőként szívesen segítek akár az Oracle frissítések telepítésével 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!

Az Oracle Statspack riport legfontosabb szekciói DBA szemmel

Az előző bejegyzésünkben sikeresen telepítettük és beütemeztük az Oracle Statspack eszközét. Mostanra valószínűleg már összegyűlt néhány snapshot, és le is generáltad az első riportodat, ami egy spreport_JJJJMMDD_HHMI.txt nevű, meglehetősen hosszú szöveges fájl. Amikor először megnyitod, a több száz, vagy akár több ezer soros tartalom láttán könnyen elfoghat a pánik: "Jó ég, hol kezdjem?"

Ne aggódj! A Statspack riport olyan, mint egy EKG-lelet. Elsőre ijesztő kriksz-kraksznak tűnik, de ha tudod, melyik görbét és értéket kell figyelned, pillanatok alatt képet kapsz a "páciens" állapotáról.

Ebben a cikkben végigvezetlek a Statspack riport legfontosabb szekcióin, és megmutatom azt a gyakorlati módszert, amivel gyorsan és hatékonyan azonosíthatod a teljesítményproblémák gyökerét.

A Riport Felépítése – Madártávlat

Mielőtt a mélyére ásnánk, ismerkedjünk meg a riport főbb részeivel. Nem kell mindent azonnal megérteni, a cél a tájékozódás.

• Fejléc (Header): A riport elején található alapinformációk: adatbázis neve (DB Name), instance neve (Instance), Oracle verzió, a snapshotok kezdő és végpontja (Begin Snap, End Snap), és a köztük eltelt idő (Elapsed). Első lépésként mindig itt ellenőrizd, hogy a megfelelő időszakot vizsgálod-e!

• Load Profile (Terhelési Profil): Ez az adatbázis "műszerfala". Gyors áttekintést ad a vizsgált időszak terheléséről, például a másodpercenkénti tranzakciók számáról vagy a logikai/fizikai olvasásokról.

• Instance Efficiency % (Hatékonysági Mutatók): A klasszikus "health check" számok, mint a Buffer Hit %. Bár önmagukban nem mondanak el mindent, egy hirtelen esés egy korábbi állapothoz képest árulkodó jel lehet.

• Top 5 Timed Foreground Events: A RIPORT LEGFONTOSABB RÉSZE! Itt feketén-fehéren látszik, hogy az adatbázis mire várakozott a legtöbbet ahelyett, hogy hasznos munkát végzett volna.

• SQL Statistics (SQL Statisztikák): Itt találod a "bűnösöket", azaz azokat a konkrét SQL utasításokat, amik a legtöbb erőforrást fogyasztották vagy a legtöbb várakozást okozták.

• I/O Stats (I/O Statisztikák): Információk a tablespace-ek és adatfájlok I/O terheléséről. Segít azonosítani a "forró" (hot) adatfájlokat.

A Mélyvíz: A Kritikus Szekciók Elemzése

Most pedig nézzük a lényeget! Egy tapasztalt DBA a riport 80%-át átugorja, és egyből a kritikus részekre fókál.

A Kiindulópont: Top 5 Timed Foreground Events

Képzeld el, hogy az adatbázisod egy futó, aki megáll pihenni. A "Wait Event" (várakozási esemény) megmondja, hogy miért állt meg: vizet inni? cipőfűzőt kötni? vagy csak levegő után kapkod? A Top 5 Timed Events szekció pontosan ezt a listát adja meg: mire "várt" legtöbbet az adatbázis.

Itt van néhány a leggyakoribb és legkritikusabb események közül:

• CPU time: Ez technikailag nem várakozás. Azt mutatja, mennyi időt töltött a processz a CPU-n aktív munkával. Ha ez van a lista élén, az alapvetően jó jel, mert az adatbázis dolgozik. Azonban ha irreálisan magas, az utalhat egy nagyon rosszul megírt, pazarló SQL-re is.

• db file sequential read: Tipikusan egy indexen keresztüli olvasást jelez, amikor az adatbázis egyenként olvassa be a blokkokat. Ha ez az esemény dominál, az utalhat nem elég szelektív indexekre vagy olyan műveletekre, amik rengeteg sort olvasnak be egy indexen keresztül (pl. nested loop). Továbbá utalhat alacsony buffer cache memóriára, alacsony SGA beállításra.

• db file scattered read: Ez szinte mindig Full Table Scan-t (teljes táblaolvasást) jelent, amikor az Oracle egyszerre több blokkot olvas be a diszkről. Ha ez a legfőbb várakozás, szinte biztos, hogy hiányzik egy megfelelő index, vagy az optimalizáló valamiért nem használja a meglévőt.

• log file sync: A felhasználói session arra vár, hogy a commit parancsa véglegesítődjön, azaz a redo információ kiíródjon a redo log fájlba. Ha ez magas, az utalhat lassú I/O alrendszerre a redo logok alatt, vagy egy olyan alkalmazásra, ami túl gyakran, akár soronként hajt végre commit-ot. Továbbá utalhat nem megfelő méretű vagy számú redo log csoportra.

• enq: TX - row lock contention: Zárolási problémát jelez. Egy session egy olyan sorra vár, amit egy másik session éppen zárol. Ez egyértelműen alkalmazáslogikai vagy tranzakciókezelési hiba.

FONTOS MEGJEGYZÉS 12c, 18c, 19c verzió ESETÉN: Mint ahogy az előző cikkben a "19c 'Idle Event' Probléma és Javítása" részben tárgyaltuk, elengedhetetlen, hogy a Statspack konfigurációjából kizárjuk a tétlen (idle) várakozási eseményeket. Ha ezt a lépést kihagytuk, a Top 5 Timed Foreground Events lista tele lesz felesleges, "zaj" eseményekkel (pl. "Data Guard: Timer Idle"), amik nem hordoznak hasznos információt a teljesítményhangoláshoz, és teljesen használhatatlanná teszik ezt a kulcsfontosságú szekciót.

Nyomozás: Kössük össze a Várakozásokat az SQL-ekkel!

Miután azonosítottad a fő szűk keresztmetszetet (pl. db file scattered read), a következő lépés, hogy megtaláld a felelős SQL-t. Görgess lejjebb az SQL Statistics szekciókhoz.

A logika egyszerű:

Ha a top várakozás X, akkor keresd meg az "SQL ordered by X" részt.

• Ha a top várakozás a db file scattered read volt, akkor nézd meg az SQL ordered by Physical Reads listát. Az ott szereplő SQL-ek végezték a legtöbb fizikai olvasást, valószínűleg ezek okozzák a full table scaneket.

• Ha a CPU time volt a legmagasabb, akkor az SQL ordered by CPU Time és az SQL ordered by Gets (logikai olvasások) lesz a barátod. A rengeteg bufferből történő olvasás is komoly CPU terhelést jelent.

• Ha a log file sync a gond, akkor nem egy konkrét SQL-t kell keresni, hanem az alkalmazás commit logikáját kell megvizsgálni.

További Árulkodó Jelek

Miután megvan a fő gyanúsított (a top esemény és a top SQL), érdemes más szekciókban is megerősítést keresni. Például az Instance Activity Stats szekcióban keresd meg a parse count (hard) értéket. Ha ez a szám magas, az azt jelenti, hogy az alkalmazás nem használ bind változókat, és az Oracle-nek minden egyes SQL utasítást újra és újra le kell fordítania, ami feleslegesen terheli a rendszert.

A Gyakorlati Recept: Elemzés Lépésről Lépésre

Foglaljuk össze egy egyszerű, követhető folyamatba:

1. Kontextus Ellenőrzése: A riport fejlécében nézd meg az időszakot (Begin Snap, End Snap, Elapsed). Egy 15 perces és egy 24 órás riportot teljesen máshogy kell értékelni.

2. Terhelés Felmérése: Fuss át a Load Profile szekción. A látott terhelés (pl. tranzakciók száma) megfelel a napszaknak és az elvárásoknak?

3. Szűk Keresztmetszet Azonosítása: Menj egyből a Top 5 Timed Foreground Events részhez. Mi a legfőbb probléma? I/O? CPU? Zárolás?

4. Felelős SQL Megkeresése: A top esemény alapján keresd meg a hozzá kapcsolódó SQL-t az SQL Statistics megfelelő al-szekciójában. Az SQL_ID segítségével már konkrétan tudsz foglalkozni a problémás kódrészlettel.

5. Megerősítés: Keress további, a hipotézisedet alátámasztó adatokat más szekciókban (pl. magas hard parse szám, I/O anomáliák).

Összegzés

A Statspack riport elemzése elsőre ijesztő, de a fenti módszerrel egy logikus és hatékony diagnosztikai eszközzé válik. A lényeg szinte mindig a "Top Events → Top SQL" tengelyen mozog. Ha ezt a kapcsolatot megtanulod felismerni, a teljesítményproblémák 90%-ának gyökerét perceken belül azonosítani tudod.

Profi tipp: Ne csak akkor generálj riportot, amikor már baj van! Készíts riportokat egy átlagos terhelésű, "békeidős" időszakról is. Ez lesz a baseline, a viszonyítási alap. Amikor a felhasználók lassúságra panaszkodnak, egy új riportot a baseline-nal összehasonlítva azonnal látszani fog, hogy mi változott meg.

Remélem, ez a bejegyzés segített eloszlatni a Statspack riport körüli misztikumot. Amennyiben további kérdésed lenne, ne habozz hozzám fordulni!

Szabadúszó vizsgázott Oracle szakértőként szívesen segítek akár az Oracle Statspack telepítésével 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!