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!