www.oracle-szakerto.hu Open in urlscan Pro
2a00:1450:4001:811::2013  Public Scan

Form analysis
2 forms found in the DOM

https://www.oracle-szakerto.hu/search

<form action="https://www.oracle-szakerto.hu/search" class="gsc-search-box" target="_top">
  <table cellpadding="0" cellspacing="0" class="gsc-search-box">
    <tbody>
      <tr>
        <td class="gsc-input">
          <input autocomplete="off" class="gsc-input" name="q" size="10" title="search" type="text" value="">
        </td>
        <td class="gsc-search-button">
          <input class="gsc-search-button" title="search" type="submit" value="Keresés">
        </td>
      </tr>
    </tbody>
  </table>
</form>

Name: contact-form —

<form name="contact-form">
  <p></p> Név <br>
  <input class="contact-form-name" id="ContactForm1_contact-form-name" name="name" size="30" type="text" value="">
  <p></p> E-mail <span style="font-weight: bolder;">*</span>
  <br>
  <input class="contact-form-email" id="ContactForm1_contact-form-email" name="email" size="30" type="text" value="">
  <p></p> Üzenet <span style="font-weight: bolder;">*</span>
  <br>
  <textarea class="contact-form-email-message" cols="25" id="ContactForm1_contact-form-email-message" name="email-message" rows="5"></textarea>
  <p></p>
  <input class="contact-form-button contact-form-button-submit" id="ContactForm1_contact-form-submit" type="button" value="Küldés">
  <p></p>
  <div style="text-align: center; max-width: 222px; width: 100%">
    <p class="contact-form-error-message" id="ContactForm1_contact-form-error-message"></p>
    <p class="contact-form-success-message" id="ContactForm1_contact-form-success-message"></p>
  </div>
</form>

Text Content

ORACLE DBA BLOG MAGYARUL

Megoldások Oracle adatbázis üzemeltetéséhez és optimalizáláshoz.




SZÜKSÉGE VAN ORACLE SEGÍTSÉGRE?


SZÜKSÉGE VAN ORACLE SEGÍTSÉGRE?

Forduljon hozzám bizalommal e-mailben: palffy.peter@oracle.szakerto.hu. Több
mint 20 éves tapasztalattal rendelkezem az Oracle adatbázisok telepítése,
üzemeltetése, karbantartása, hibaelhárítása és optimalizálása terén.

További információt a szolgáltatásaimról itt talál.






2024. MÁJUS 13., HÉTFŐ


ÚJ NEVET KAPOTT A KÖVETKEZŐ LTS ORACLE ADATBÁZIS VERZIÓ: 23AI




AZ ORACLE DATABASE 23AI: AZ AI-VEL MEGTÁMOGATOTT ADATBÁZIS

Az Oracle nemrégiben bejelentette az Oracle Database 23ai verziót, amely a
mesterséges intelligencia (AI) területén hozott újításokat. Korábban a 23c néven
volt ismert ez a verzió, de a fókuszváltás miatt átnevezték 23ai-re. Ez a
változás nem meglepő, hiszen az AI és az adatok intelligens kezelése az egyik
legfontosabb fejlesztési terület napjainkban. 


PÁR KIEMELT TÉMA, AMI MIATT FONTOS SZÁMUNKRA AZ 23AI VERZIÓ.



 * Long Term Support (LTS): Az Oracle Database 23ai a következő hosszú távú
   támogatott verzió. A 23ai normál támogatása 2029 áprilisig szól, a
   kiterjesztett támogatás pedig 2032 áprilisig. A 19c verzió meghosszabbított
   normál támogatása 2026 április 30-ig van érvényben, tehát 2 évünk van, hogy
   az éles rendszereinkkel az új verzióra áttérjünk. Az LTS verziók stabilak,
   biztonságosak és hosszú távon támogatottak.
 * AI Vector Search: Az AI Vector Search lehetővé teszi, hogy generatív AI
   folyamatokat hozz létre az üzleti adataidból közvetlenül az adatbázisban. Az
   egyszerűen használható vektor képességek lehetővé teszik a fejlesztők
   számára, hogy olyan AI alkalmazásokat építsenek, amelyek kombinálják a
   relációs adatbázis feldolgozást a hasonlóság kereséssel és kinyeréssel.
 * JSON Relational Duality: Az Oracle Database 23ai-ban az úttörő JSON
   Relational Duality funkció segítségével könnyedén létrehozhatsz egyetlen
   indexet több tábla és nézet fölött. Ez nagyban megkönnyíti az adatok
   kezelését és lekérdezését.
 * Transparent Application Continuity: Ez a funkció védelmet nyújt az
   alkalmazásoknak az alapvető szoftverek, hardverek, kommunikációs és tárolási
   rétegek hibái ellen. Az alkalmazásoknak nem kell leállniuk, ha az
   adatbázisban probléma merül fel.
 * Oracle Globally Distributed Database with RAFT: Az Oracle Database 23ai-ban
   bevezették a Raft replikációt, amely lehetővé teszi a gyors failover-t a
   csomópont vagy adatközpont kiesése esetén anélkül, hogy adatvesztés történne.
 * Több mint 300 új funkció. Nekem az egyik kedvencem (amit mint DBA már 20 éve
   hiányolok) a "Schema privileges". Tervezek nemsokára egy külön bejegyzést
   azon fukciókról, amiket mi adatbázis adminisztrátorok már vártunk.


ELÉRHETŐSÉG

Az Oracle Database 23ai már elérhető az Oracle Exadata Cloud@Customer, az OCI
Exadata Database Service és az OCI Base Database Service platformokon. Emellett
elérhető az Azure Oracle Database Service-ben is. A fejlesztők számára az Oracle
Database 23ai már elérhető az Always Free Autonomous Database-ben, valamint
letölthető az Autonomous Database 23ai Container Image és az Oracle Database
23ai Free verzióból.
Az Oracle jelenlegi ígérete szerint a helyben telepíthető verziók (EE, SE2) is
hamarosan megjelennek, első körben Linux, majd a következő hónapokban a további
platformokra is. Már nagyon várjuk!


ORACLE VERZIÓ ELNEVEZÉS TÖRTÉNELEM

Végül egy kis történelem, hogy miként nevezte korábbi adatbázis verzióit az
Oracle. Érdekes látni, hogy mikor mi volt a prioritás, mik voltak a
kimaradhatatlan hívószavak.
 * Oracle 8i, 9i: Az "i" itt az "Internet" rövidítése volt. Az Oracle 8i verzió
   az internetes alkalmazások fejlesztésére fókuszált, és olyan funkciókat
   tartalmazott, amelyek segítették az online alkalmazások kialakítását és
   kezelését.
 * Oracle 10g, 11g: A "g" itt a "Grid computing" rövidítése. A 10g verzió
   bevezette a grid alapú adatbázis-kezelést, amely lehetővé tette az
   adatbázisok skálázását és optimalizálását több szerveren.
 * Oracle 12c, 18c, 19c: A "c" itt a "Cloud" szót jelenti. Ezek a verziók a
   felhőalapú adatbázis-kezelésre összpontosítottak, és olyan funkciókat hoztak,
   amelyek lehetővé tették az adatbázisok könnyebb telepítését és kezelését a
   felhőben.



Szabadúszó, vizsgázott Oracle szakértőként szívesen segítek az Oracle 23ai
verzió átállás tervezésében, kivitelezésében.


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éljad!

Posted by Pálffy Péter at 8:57 Nincsenek megjegyzések:
Küldés e-mailbenBlogThis!Megosztás a TwitterenMegosztás a FacebookonMegosztás a
Pinteresten




2024. MÁJUS 9., CSÜTÖRTÖK


MEGÉRKEZETT A 2024 ÁPRILIS ORACLE JAVÍTÓKÉSZLET




LETÖLTHETŐ A 19.23.0.0.240416 ORACLE PATCH

Április közepén megjelent az Oracle negyedéves javítócsomagja a 19c
adatbázisokhoz, mely a 19.23-as verziót hordozza. A frissítés Windows platformra
szokás szerint pár hetet késett, de május elején ez is elérhetővé vált.

Fontos megjegyezni, hogy az Oracle javítókészletek kizárólag a
https://support.oracle.com oldalról tölthetőek le, a telepítéshez így feltétel
az aktív Oracle support előfizetés.

A szükséges patchek megtalálása nem mindig egyszerű feladat, ezért
összeállítottam egy listát a Windows és Linux/ Unix platformokra vonatkozó
pontos patch számokról:

Windows:

 * Microsoft Windows BP 19.23.0.0.240416 Patch 36219938
 * OJVM Release Update 19.23.0.0.240416 Patch 36199232
 * JDK8u411 Patch 36195566
 * OPatch 12c Release 1 patch 6880880 a 12.2.0.1.0 verzió kiválasztásával.

Linux / Unix:

 * Combo OJVM Release Update 19.23.0.0.240416 and Database Release Update
   19.23.0.0.240416 Patch 36209492, amennyiben nincsen Grid Infrastructure
   telepítve.
 * Combo OJVM Release Update 19.23.0.0.240416 and GI Release Update
   19.23.0.0.240416 Patch 36209493, amennyiben Grid Infrastructure is van
   telepítve
 * JDK8u411 Patch 36195566
 * OPatch 12c Release 1 patch 6880880 a 12.2.0.1.0 verzió kiválasztásával.

Ha a jövőben szeretnéd könnyedén megtalálni az aktuális negyedéves patchek
listáját, akkor itt egy módszer a keresésre:

 1. Látogassunk el a https://support.oracle.com oldalra.
 2. A keresőmezőbe írjuk be a "CPU db-only 2024 apr" kifejezést (a 2024 áprilisi
    javítások kereséséhez). A keresési kifejezésben a dátumot természetesen
    mindig a keresett negyedévhez kell igazítani. Tehát pl a következő júliusi
    patch esetén "CPU db-only 2024 jul".
 3. A keresési találatok elején meg kell jelennie a "Critical Patch Update (CPU)
    Program Apr 2024 Patch Availability Document (DB-only)" dokumentumnak.
    Nyissuk meg ezt a dokumentumot.
 4. Kattintsunk a "3.1 Oracle Database" -re, majd a "Section 3.1.7 "Oracle
    Database"" -re, végül a "3.1.7.4 Oracle Database 19" -re.
 5. Itt már láthatóak a konkrét patchek linkjei.

Fontos megjegyzések:

 * A letöltésnél 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 mindig alaposan nézzük át
 * Adatbázisok esetén nem csak a szoftver telepítést 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

Remélem, ez a bejegyzés hasznos volt az Oracle 19.23-as negyedéves
javítócsomagjával kapcsolatos információk megismerésében. Amennyiben további
kérdésed lenne, ne habozzon hozzám fordulni!

Szabadúszó vizsgázott Oracle szakértőként szívesen segítek akár az Oracle
javítókészletek telepítésével kapcsolatban.

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éljad!


Posted by Pálffy Péter at 13:15 Nincsenek megjegyzések:
Küldés e-mailbenBlogThis!Megosztás a TwitterenMegosztás a FacebookonMegosztás a
Pinteresten




2024. FEBRUÁR 29., CSÜTÖRTÖK


AZ ORACLE XE ÚJ NEVE: 23C FREE


Az Oracle Database Express Edition (XE) még 2023 során névváltozáson esett át,
és már Oracle 23c Free néven elérhető. Ez a korlátozott funkcionalitású,
ingyenes verzió továbbra is ideális választás kisebb, nem kritikus adatbázisok
számára, de fontos megjegyezni, hogy nem jár hozzá hivatalos Oracle támogatás,
tehát nem kapunk még biztonsági javításokat sem.

Mik a 23c Free korlátozásai?
 * A user adatok maximális mérete az adatbázisban: 12 GB
 * Maximum kettő CPU mag használható
 * Maximum 2 GB RAM használható
 * Egy szerverre csak 1 példányban telepíthető
 * Nincs Oracle Support

Milyen platformokon érhető el a 23c Free?

 * Az Oracle 23c Free Windows és Linux platformokon érhető el.

Fontos megjegyzések az upgrade-del kapcsolatban:
 * A korábbi XE verziókról (11g, 18c, 21c) a 23c Free-re történő upgrade nem
   automatikus, nincsen upgrade utility. Sőt óvatlan telepítéskor akár a korábbi
   XE adatbázisunkat is elveszíthetjük!
 * Az Oracle hivatalosan az export-import műveletet ajánlja az upgrade
   elvégzéséhez.
 * Kiemelten fontos, hogy az export fájlt hova mentjük el. A 23c Free telepítése
   csak a korábbi XE eltávolítása után kezdődhet és az eltávolításkor könnyen
   törlődhet az állományunk!
 * A közeljövőben egy újabb blogbejegyzésben részletesen írok majd az upgrade
   folyamatról.


Használja a 23c Free-t kisebb adatbázisaihoz, és kövesse a blogomat a további
frissítésekért!

További információk:
 * Oracle 23c Free dokumentáció: https://www.oracle.com/database/free/

Szabadúszó vizsgázott Oracle szakértőként szívesen segítek Önnek az Oracle 23c
Free-vel vagy az upgrade folyamatával kapcsolatban.


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

Kérem, vegye fel velem a kapcsolatot e-mailben a palffy.peter@oracle-szakerto.hu
címen, ha bármilyen kérdése van, vagy árajánlatot szeretne kérni.


Szívesen segítek Önnek elérni az Oracle adatbázisaival kapcsolatos céljait!

Posted by Pálffy Péter at 14:17 Nincsenek megjegyzések:
Küldés e-mailbenBlogThis!Megosztás a TwitterenMegosztás a FacebookonMegosztás a
Pinteresten




ÜDVÖZLÖM ÖNT AZ ORACLE DBA MAGYARUL BLOGON!


Pálffy Péter vagyok, szabadúszó Oracle adatbázis szakértő, több mint 20 éves
tapasztalattal. Blogom célja, hogy megoldásokat nyújtson Önnek az Oracle
adatbázisok telepítése, üzemeltetése, karbantartása, hibaelhárítása és
optimalizálása során felmerülő problémákra.

Szolgáltatásaim:

 * Oracle adatbázis környezetek kialakítása: Segítek Önnek az Oracle adatbázis
   telepítésében, konfigurálásában és a szükséges hardver- és
   szoftverkövetelmények meghatározásában.
 * Verziókövetés: Biztosítom az Oracle adatbázis verziófrissítéseinek
   zökkenőmentes lebonyolítását, minimalizálva az állásidőt.
 * Üzemeltetés és karbantartás: Átalánydíjas szolgáltatás keretében vállalom az
   Oracle adatbázis rendszerek teljes körű üzemeltetését és karbantartását.
 * Hibaelhárítás: Gyors és hatékony megoldást kínálok az Oracle adatbázisokkal
   kapcsolatos hibák diagnosztizálására és javítására.
 * Mentési rendszer kialakítása: Biztonságos mentési stratégiát dolgozok ki az
   adatvesztés kockázatának minimalizálása érdekében.
 * Hardening beállítás: Megerősítem az Oracle adatbázis biztonságát a bevált
   hardening technikák alkalmazásával.
 * Teljesítményhangolás: Optimalizálom az Oracle adatbázis teljesítményét,
   javítva a lekérdezési sebességet és a válaszidőt.
 * Oracle adatbázis licence tanácsadás és értékesítés: Segítséget nyújtok az
   Önnek megfelelő Oracle adatbázis licence kiválasztásában, és hivatalos Oracle
   partnerként gondoskodom a licencek beszerzéséről is.


Akár átalánydíjas szolgáltatás keretében, akár egyedi eseti megbízások alapján
is állok rendelkezésére. Szakértelmemmel és tapasztalatommal hatékonyan megoldom
az Oracle adatbázisával kapcsolatos problémáit, hogy Ön zavartalanul
folytatthassa munkáját.

Keressen bizalommal, ha:

 * Kérdése van Oracle adatbázis üzemeltetésével vagy karbantartásával.
 * Hibaelhárítási segítségre van szüksége.
 * Optimalizálni szeretné az Oracle adatbázis teljesítményét.
 * Biztonságosabbá szeretné tenni az Oracle adatbázisát.

Kérem, vegye fel velem a kapcsolatot a palffy.peter@oracle-szakerto.hu email
címen, ha további információra van szüksége, vagy árajánlatot szeretne kérni.

Posted by Pálffy Péter at 11:41 Nincsenek megjegyzések:
Küldés e-mailbenBlogThis!Megosztás a TwitterenMegosztás a FacebookonMegosztás a
Pinteresten




2015. OKTÓBER 2., PÉNTEK


ORACLE STANDARD EDITION 2 (SE2) LICENCE VÁLTOZÁSOK


Úgy egy éve lehet sejteni, hogy az Oracle valamire készül a Standard Edition
környékén. Tavaly megjelent a 12c legfrissebb verziója (12.1.0.2.0), ami akkor
valamiért csak Enterprise kiadásban volt elérhető. Korábban mindig egy telepítő
készleten volt a Standard Edition és az Enterprise is, csak telepítéskor volt
szükséges megadni, milyen kiadást is szeretnénk. Most viszont a telepítő csak
Enterprise verziót engedett telepíteni, Standard Edition-t egyáltalán nem volt
lehetőség installálni. Sokan azonban erre a verzióra vártak, hogy végre
elkezdhessenek komolyan gondolkodni a 11g->12c váltásban.


Idén szeptemberben aztán végre megjelent a 12.1.0.2.0 verzió Standard Edition
telepítő, illetve megkaptuk a választ, hogy miért is kellett várni. Az Oracle
teljesen átformálja a Standard Edition licencek lehetőségeit. A változások
minden olyan jelenleg Standard Edition, vagy Standard Edition One adatbázist
használó ügyfelet érintenek, akik szeretnék a 12.1.0.2 vagy a majd megjelenő
újabb verziókat használni. Az új feltételek sajnos sok felhasználót negatívan
fognak érinteni.


Mi is a változás? Először is teljesen megszűnik a korábbi Standard Edition (SE)
és Standard Edition One (SE One) licenc, és jön helyette egy új, melyet Standard
Edition 2-nek (SE 2) neveztek el. Az új 12.1.0.2.0 verziótól csak az új
licenccel szabályos a használat. A korábbi Standard Edition-t használók
ingyenesen migrálhatnak az új licencre, az éves support díjban sem lesz nekik a
jövőben változás, tehát a Standard Edition 2 árazása egyezik a korábbi Standard
Edition-el. Az SE One felhasználóknak sajnos drágulni fog a követés, amennyiben
kérik a migrálást SE 2 licencre. A jelenlegi One felhasználóknak így még időben
el kell gondolkodniuk pénzügyileg is, hogy milyen feltételekkel mikor szeretnék
(ha szeretnék) a migrálást elvégezni.


Az új Standard Edition 2 licenc sajnos több pontban sokkal szigorúbb, mint a
korábbi Standard Edition, így biztosra vehető, hogy egy alapos hardver
felülvizsgálat is szükséges a felhasználó környezetében, mert nagyon könnyen
előfordulhat, hogy az új licenc feltételekkel már nem üzemelhet az adatbázis a
régi környezetben. Akár hardver cserére, vagy új licencek vásárlására is szükség
lehet.
Lássuk, mik is ezek a szigorítások, változások, a korábbi Standard Edition
fényében.


 * Named User Plus (NUP) licenc esetén már nem elég a korábbi minimális 5
   NUP/ügyfél, hanem minimum 10 NUP/szerver licenc szükséges. Nem is a minimum
   10 itt a kemény változás, hanem a szerverenként minimum 10! Tehát ahány
   fizikai szerveren futhat Oracle adatbázis, minimum annyiszor 10 db NUP licenc
   szükséges! Mint azt tudjuk, a teszt környezetek is számítanak!

 * A fizikai szerver, amin az adatbázis fut, maximum 2 CPU foglalatos lehet,
   több foglalat (socket) üresen sem lehet! Korábban ugye ez 4 volt. Tehát aki
   2-nél több foglalatos szervert használ jelenleg, az felkészülhet a szerver
   cseréjére.

 * RAC opció továbbra is használható, de itt is bejött egy szigorítás. RAC
   esetén a 2 db fizikai szerverben csupán 1-1 CPU lehet. A szerver lehet max 2
   foglalatos, de csak 1-ben lehet ténylegesen CPU.

 * Korlátozásra került a használható processzor szálak száma is, korábban ilyen
   egyáltalán nem volt. 1 gép esetén ez maximum 16 szál, míg 2 gép RAC esetén
   8-8 szál használható maximum. Itt nem arra kell gondolni, hogy a cpu nem
   lehet erősebb ennél, hanem az adatbázis egyszerűen szoftveresen lesz
   korlátozva, és nem fog több szálat használni. Processzor szálnak a hyper
   threading szálak is számítanak, így egy erősebb gép esetén elgondolkodtató,
   érdemes-e egyáltalán a hyper threading használata. 






Fontos megjegyzés, hogy a CPU foglalatok száma a fenti korlátozások esetében
mindig a tényleges fizikai szerverre vonatkoznak (ez eddig is így volt)! Tehát
hiába virtualizálunk (semmilyen virtualizáció, még Oracle VM sem!), az nem
megoldás egy 2-nél több foglalatos szerver esetén. Ha a virtualizációról szó
esett, akkor itt egy kis kitérővel megemlíteném, hogy a VmWare alapú
virtualizációt az Oracle továbbra sem fogadja el, mint hard paritioning! Tehát
VmWare esetén, ha CPU alapú Oracle licencet választunk, akkor a teljes fizikai
gépet kell licencelni, illetve az összes fizikai szervert, amin az Oracle
adatbázis futhat. Standard Edition 2 esetén továbbra is a CPU licence egy CPU
foglalatra vonatkozik, core-ok számától függetlenül.


Sajnos kijelenthetjük, hogy a fenti változások szinte mindenkit érintenek, akik
Standard Edition-t  (vagy One-t) használnak, és szeretnének az új verzióra
váltani. Az új verzió telepítése előtt így feltétlen szükséges egy alapos
felmérés, tervezés, amibe célszerű egy licenc szakértőt is bevonni.


Ha valaki elakadt, mit is tegyen, keressen nyugodtan!

Posted by Pálffy Péter at 9:07 Nincsenek megjegyzések:
Küldés e-mailbenBlogThis!Megosztás a TwitterenMegosztás a FacebookonMegosztás a
Pinteresten




2014. FEBRUÁR 6., CSÜTÖRTÖK


LINUX HUGEPAGES BEÁLLÍTÁSA ORACLE ADATBÁZIS SZÁMÁRA


     Előző alkalommal leírtam, hogy bizonyos körülmények között mennyire hasznos
lehet a Hugepages beállítása, most pedig egy konkrét példát hozok a
konfigurációra.


Kiinduló környezet:
     Virtuális környezetben (Természetesen Oracle Virtualbox) került telepítésre
egy CentOS 5.10 64 bit 6 Gbyte memóriával, az adatbázis pedig egy 11gR2,
létrehoztam egy PROBA nevű adatbázist. Az adatbázist direkt AMM-el hoztam létre,
azaz a MEMORY_TARGET init.ora paraméter beállításával az adatbázist összesen 4G
memória felhasználásra bíztattam. Korábban már megbeszéltük, hogy AMM esetén nem
lehet Hugepages-t beállítani, ezért is kezdem innét.


Vágjunk bele!
     Első lépésben a legfontosabb dolog, hogy az AMM-et megszüntessük. Az AMM-et
a memory_max_target és a memory_target initora paraméterek szabályozzák. Sys
vagy system felhasználóval belépve először leellenőrizzük a jelenlegi
memory_target beállításokat, majd töröljük őket az spfile-ból, végül beállítjuk
az új sga_target és pga_aggregate_target értékeket. Íme a szükséges utasítások:

SQL> select NAME,VALUE from v$parameter where name like 'memory%target';
NAME
--------------------------------------------------------------------------------
VALUE
--------------------------------------------------------------------------------
memory_target
4294967296
memory_max_target
4294967296

SQL> alter system reset memory_target scope=spfile;
System altered.
SQL> alter system reset memory_max_target  scope=spfile;
alter system reset memory_max_target  scope=spfile
*
ERROR at line 1:
ORA-32010: cannot find entry to delete in SPFILE
SQL> alter system set sga_target=3G scope=spfile;
System altered.
SQL> alter system set pga_aggregate_target=1G scope=spfile;
System altered.
SQL> 



     A memory_max_target paraméter törlésénél a hiba teljesen normális, mivel az
spfile-ban eleve nem volt meg ez a paraméter, értékét a memory_target
beállításból kapta. Azért vettem bele most a leírásba, hogy ha valakinél ez is
szerepelne, akkor azt is feltétlen törölni kell! Az SGA méretét a jelen
beállítással 3Gbyte-ra, a PGA méretét pedig 1Gbyte-ra állítottam. (Figyelem! Ez
az SGA/PGA arány most csak találomra lett beállítva, mivel az adatbázis üres,
nem használja semmi. Az SGA/PGA arányt minden esetben egyedileg, az aktuális
adatbázis felhasználásához szükséges hangolni! )

     Illetve, ha már init.ora paramétereket állítunk, akkor állítsuk be a
következőt is:


alter system set use_large_pages=only scope=spfile;


     A use_large_pages=only paraméterrel beállítjuk, hogy az adatbázis csak
Hugepages memória területet használhasson az SGA számára. Ezzel elkerüljük, hogy
a beállított, lefoglalt Hugepages terület helyett mégis a hagyományos memória
területre kerüljön az SGA. Amennyiben nincs jogosultsága, vagy nincs elegendő
hely a Hugepages memóriában, akkor az adatbázis elindítása az ORA-27137 hibába
fog ütközni.
     Az adatbázis újraindítása után ellenőrizzük le, hogy sikerültek-e a
beállítások.

SQL> select NAME,VALUE from v$parameter where name in
('sga_target','memory_target','memory_max_target','pga_aggregate_target');
NAME
--------------------------------------------------------------------------------
VALUE
--------------------------------------------------------------------------------
sga_target
3221225472
memory_target
0
memory_max_target
0
pga_aggregate_target
1073741824
SQL> 



     Következő lépésben ellenőrizzük a szerver jelenlegi Hugepages beállításait,
illetve ellenőrizzük a fizikai memória méretét. A /proc/meminfo -ban minden
számunkra szükséges információ megtalálható. Fontos, hogy biztosak legyünk a
fizikai memória és a Hugepagesize (a Huge memória lap) pontos méretével
kapcsolatban.


[oracle@centos-proba ~]$ grep MemTotal /proc/meminfo 
MemTotal:      6113212 kB
[oracle@centos-proba ~]$ grep Huge /proc/meminfo 
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
Hugepagesize:     2048 kB


     Látszik, hogy a szerverben tényleg 6 Gbyte memória van, hogy a Hugepagesize
tényleg 2 Mbyte, illetve jelenleg nincs HugePages terület beállítva.

     És akkor most számolunk kicsit. Mekkora is legyen a Hugepages terület?
Korábban írtam, hogy csak az SGA terület kerülhet Hugepages-be, a PGA nem. Tehát
jelen esetben nagyon egyszerű, a Hugepages területnek 3 Gbyte-nak kell lennie,
mivel annyi az SGA is. Amennyiben a szerveren több adatbázis is fut, akkor az
összes SGA területet pontosan össze kell adni, és akkora Hugepages területre
lesz szükségünk. Pontosan számoljunk, és ne felejtsük el, hogy a fizikai
memóriában maradjon hely az összes adatbázis PGA területére, illetve az
operációs rendszeren futó összes egyéb programnak is. Tehát


Hugepages memória terület < (Fizikai memória - sum(PGA) - operációs rendszernek
és egyéb programoknak szükséges memória)


     A Hugepages terület méretét a vm.nr_hugepages kernel paraméter segítségével
lehetséges beállítani. A paraméter a Hugepage lapok számát adja meg, tehát nem
méretet, hanem a szükséges lapok számát kell megadunk. vm.nr_hugepages =
sum(SGA)/Hugepagesize. Jelen esetben ez (3221225472/1024)kbyte/2048kbyte= 1536.
Ami fontos még, hogy érdemes a HugePages területet ennél pár lappal nagyobbra
venni, hogy maradjon üres memória lap. Tehát legyen jelen esetben 1540.
     A kernel paramétert a /etc/sysctl.conf állománmyban állíthatjuk be a
legegyszerűbben, tehát adjuk hozzá a következő sort (természetesen root
jogosultság szükséges)


vm.nr_hugepages=1540


     A kernel paramétert megpróbálhatjuk reboot nélkül is beállítani, de ez
valószínű nem lesz sikeres, mivel a kernel a Hugepages területet csak akkor
tudja lefoglalni, ha van éppen a fizikai memóriában ennyi összefüggő szabad
terület. Azért egy próbát megér, root felhasználóval futtassuk a következő
parancsot:


# sysctl -p

     Majd ellenőrizzük, hogy sikerült-e lefoglalni a memória területet:

[root@centos-proba ~]# grep Huge /proc/meminfo 
HugePages_Total:  238
HugePages_Free:   238
HugePages_Rsvd:      0
Hugepagesize:     2048 kB


     Látszik, hogy csak 238 lapot sikerült lefoglalni, a szükséges 1540 helyett.
Egy szerver reboot megoldja a problémánkat, de figyeljünk arra, hogy az Oracle
adatbázis automatikus indulását még kapcsoljuk ki. Reboot után a következő a
helyzet:


[oracle@centos-proba ~]$ grep Huge /proc/meminfo 
HugePages_Total:  1540
HugePages_Free:   1540
HugePages_Rsvd:      0
Hugepagesize:     2048 kB


     Látszik, hogy sikeresen lefoglaltuk a szükséges területet, és jelenleg a
teljes terület szabadon használható (mivel nem fut az adatbázisunk).
     Állítsuk be, hogy az oracle user tudja használni ezt a területet. Ehhez a
memlock ulimit paramétert (soft és hard) kell beállítanunk. Ezt minimum akkorára
állítsuk, amennyi a Hugepages terület mérete, de feltétlenül kisebb legyen, mint
a teljes fizikai memória. A paramétert kbyte-ban kell megadni, és a
/etc/security/limits.conf állományban lehetésges beállítani. Tehát adjuk hozzá a
következő sorokat (természetesen root jogosultság szükséges):


oracle soft   memlock 4194304
oracle hard  memlock 4194304


     Így 4 Gbyte -ra állítottam az oracle user számára. Amennyiben nem oracle
user futtatja az adatázist, akkor értelem szerűen az adott user számára kell a
paramétert beállítani. Az oracle userrel történő ismételt belépés után
ellenőrizzük a paraméter beállítását:


[oracle@centos-proba ~]$ ulimit -Sl
4194304
[oracle@centos-proba ~]$ ulimit -Hl
4194304


     Ezzel lényegében elkészültünk az alap beállítással. Próbáljuk meg
elindítani az adatbázist, és ellenőrizzük, hogy tényleg a Hugepages-t
használja-e. Amennyiben beállítottuk a use_large_pages=only paramétert, és
elindult az adatbázis, akkor biztosak lehetünk benne, hogy Hugepages-t
használunk, különben a már említett  ORA-27137 hibát kapnánk. Azért ennél többet
is ellenőrizhetünk. Nézzük meg a szokásos /proc/meminfo mit árul el most a
rendszerről.


[oracle@centos-proba ~]$ grep Huge /proc/meminfo 
HugePages_Total:  1540
HugePages_Free:   1253
HugePages_Rsvd:   1250
Hugepagesize:     2048 kB


     Mit is tudunk ebből kiolvasni. Látszik, hogy a teljes Hugepages terület a
már korábban beállított 1540 lap, ez jó. Látszik, hogy van 1253 még jelenleg
üres lap, ami ezért van, mert még csak most indítottuk az adatbázist, és
egyszerűen még nem használ minden memóriát, mert nem volt rá szükség. Továbbá az
1253 üres nem használt lapból 1250 foglalva van már, más processz nem veheti el.
A Hugepages használata az adatbázis alert.log-ban is látható, ahol minden
általunk beállított paraméter szépen ellenőrizhető.


Starting ORACLE instance (normal)
************************ Large Pages Information *******************
Parameter use_large_pages = ONLY
Per process system memlock (soft) limit = 4096 MB

Total Shared Global Region in Large Pages = 3074 MB (100%)

Large Pages used by this instance: 1537 (3074 MB)
Large Pages unused system wide = 3 (6144 KB)
Large Pages configured system wide = 1540 (3080 MB)
Large Page size = 2048 KB
********************************************************************


     A 6-os RedHat verziótól (Tehát Oracle Linux 6 és CentOS 6 is, Illetve SLES
11 szintén) bevezették a Transparent HugePages lehetőséget, ami alap
értelmezésben be is van kapcsolva. Ez dinamikus Hugepages allokációt tesz
lehetővé, ami elsőre nagyon jól hangzik, azonban sajnos jelenleg nem működik jól
az Oracle adatbázissal (11g és 12c sem), tehát ezt ki kell kapcsolni, mielőtt
bármit tennénk. A beállítás ellenőrzését a következő utasítással lehet
elvégezni:


cat /sys/kernel/mm/transparent_hugepage/enabled


     Amennyiben always vagy madvise, az nekünk sajnos nem jó. A következő
scripttel lehetséges a kikapcsolása (ezt célszerű egy ec scriptbe berakni, hogy
boot-kor életbe lépjen):


if test -f /sys/kernel/mm/transparent_hugepage/enabled; then
   echo never > /sys/kernel/mm/transparent_hugepage/enabled
fi
if test -f /sys/kernel/mm/transparent_hugepage/defrag; then
   echo never > /sys/kernel/mm/transparent_hugepage/defrag
fi




Posted by Pálffy Péter at 14:20 Nincsenek megjegyzések:
Küldés e-mailbenBlogThis!Megosztás a TwitterenMegosztás a FacebookonMegosztás a
Pinteresten




2014. JANUÁR 29., SZERDA


ORACLE ADATBÁZIS ÉS A LINUX HUGEPAGES


     A napokban hívtak egy gyakran nagyon belassuló Red Hat 5 Linux-on futó
Oracle 11.2.0 SE adatbázis szervert megvizsgálni. Sokadszorra találkozom a
problémával, hogy a szerver a látszólag helyes memória beállítások ellenére
intenzíven, egyre nagyobb mértékben használja a swap-et, és az I/O nagy
százaléka már csak erre megy el. Az adatbázis persze egyre lassabban válaszol,
csörögnek telefonon a felhasználók, hogy "lefagyott a program!".  A szerver csak
az adatbázist futtatja, így nem nagyon lehet másra kenni a túlzó memória
felhasználást.
     A vizsgálat során természetesen kiderült, hogy azok a memória beállítások
mégsem teljesen megfelelőek. Kiderült, hogy nemrég egy új modul lett az
alkalmazásban beüzemelve, ami valószínűleg nagyobb PGA területet igényel, és a
sok felhasználó miatt rendszeresen túl allokál a PGA (Megjegyzés, hogy az Oracle
12c-ben már a PGA_AGGREGATE_LIMIT paraméter gondoskodhat erről a problémáról, de
ezt majd egy másik alkalommal részletezem). Az adatbázis memória paramétereinek
átgondolását most nem részletezném, az majd egyszer egy külön téma lesz, most
másról szeretnék írni. A problémás szerveren a legnagyobb lassulást az okozta,
hogy az Oralce SGA nagy része kikerült a swap területre, miközben a kernel még
 pl. rengeteg filesystem cache-t is a memóriában tartott (swappiness kernel
paraméterről szintén majd egy következő alkalommal). Tehát, ha el tudjuk érni,
hogy az SGA ne kerülhessen swap területre, akkor sokat javulhat az ilyen
helyzetekben adatbázisunk elérhetősége. Különösen fontos lehet ez egy olyan
környezetben, ahol az adatbázisunk egy szerveren osztozik más memória intenzív
alkalmazásokkal. A megoldás a Hugepages beállítása lehet.
     Mi az a Hugepages? Normál esetben az Oracle adatbázis SGA területe a
hagyományos memória területre kerül, ami 4K méretű lapokból (pagesize) áll, és a
kernel dönti el, hogy az aktuális lap éppen swap, vagy a fizikai memóriában
legyen. Nagyobb SGA méret esetén érezhető, hogy a 4K lapméret elég kicsi, így
nagyon sok lapot kell nyilvántartani. A sok lap nyilvántartása több memóriát, és
több processzoridőt igényel a kernel számára. Ha a memóriában foglalunk
területet a Hugepages számára, akkor ott a lapméret 2M lesz (ez a linux kernel
alapértelmezése x86_64 környezetben, de bizonyos CPU-k támogatják az 1G méretet
is, cpuinfo pdpe1gb). Azt hiszem rögtön érthető, hogy ez mennyivel
barátságosabb, hiszen az új lapméret 512 db korábbi lapnak felel meg. Mondjuk
egy 8G SGA terület a 4k lapokkal több mint 2 millió lapot tartalmaz, addig
Hugepages esetében csupán 4096-ot. Viszont a legfontosabb, hogy a Hugepages
terület csak a fizikai memóriában lehet, tehát a kernel semmilyen körülmények
között nem írhatja ki a swap területre. A gyakorlatban ez annyit tesz, hogy boot
után rögtön elfoglalásra kerül a megadott méretű memória terület. Tehát ez a
fizikai memória mindenképp lefoglalásra kerül, még akkor is, ha épp nem fut
adatbázisunk. Fontos megemlíteni, hogy mivel csak az oracle felhasználónak adunk
jogot a memória területre, ezért nem járhatunk úgy, hogy pl. a szerveren futó
java alkalmazás elhasználja a memóriát előlünk. Azt hiszem ez elég jól hangzik,
de sajnos van egy dolog, amiről le kell cserébe mondanunk. Az Oracle adatbázis
csak az SGA területet tudja Hugepages memóriában tárolni, a PGA-t nem. Ebből
adódik, hogy az Oracle 11g-ben megjelent Automatic Memory Management (AMM,
MEMORY_TARGET, MEMORY_MAX_TARGET) funkciót nem tudjuk használni. Tehát nem
lehetséges az Oracle szerverre bízni az SGA - PGA memória méretek dinamikus
állítását, hanem nekünk kell kiszámítani, hogy mennyi SGA-ra, és mennyi PGA-ra
lesz szükségünk. Olyan dinamikus környezetekben, ahol gyakran van szükség az SGA
/ PGA memória arányának a változtatására, sajnos nem ajánlatos a módszer.
További hátránya, hogy egy bekapcsolt, üzemelő szerveren szinte képtelenség a
Hugepages terület növelése. Tehát, ha növelni szeretnénk az adatbázis SGA
területét, ahhoz növelnünk kell a Hugepages területet (hacsak eleve nem volt
nagyobb területünk), ami valószínűleg csak a szerver újraindításával
lehetséges. 


Összefoglalva


Előnyök:

 * jelentősen nagyobb lapméret miatt hatékonyabb, gyorsabb memória kezelés
 * garantáltan mindig a fizikai memóriában van az SGA
 * a szerveren garantált memória terület az adatbázis SGA számára


Hátrányok:

 * Nem lehetséges az Oracle AMM használata
 * Az SGA, PGA méretek pontos méretezést igényelnek
 * Oracle memória paraméterek megváltoztatása után fontos a Hugepages
   beállításokat utánállítani
 * Hugepages terület valószínűleg csak szerver újraindítással növelhető




Ha tetszik a Hugepages, és szeretnéd kipróbálni saját környezetedben is, akkor
látogass vissza pár nap múlva! Nemsokára felteszek egy step by step leírást, ami
egy 6Gb memóriával ellátott CentOS 5.10 64 bit-en futó Oracle 11gR2 adatbázis
Hugepages beállítását tartalmazza.



Posted by Pálffy Péter at 15:33 Nincsenek megjegyzések:
Küldés e-mailbenBlogThis!Megosztás a TwitterenMegosztás a FacebookonMegosztás a
Pinteresten


Régebbi bejegyzések Főoldal

Feliratkozás: Bejegyzések (Atom)


KERESÉS EBBEN A BLOGBAN






BLOGARCHÍVUM

 * ▼  2024 (4)
   * ▼  május (2)
     * Új nevet kapott a következő LTS Oracle adatbázis v...
     * Megérkezett a 2024 április Oracle javítókészlet
   * ►  február (2)

 * ►  2015 (1)
   * ►  október (1)

 * ►  2014 (3)
   * ►  február (1)
   * ►  január (2)




KAPCSOLATFELVÉTEL



Név




E-mail *




Üzenet *











ORACLE DATABASE 12C ADMINISTRATOR CERTIFIED PROFESSIONAL MINŐSÍTÉSEM


Oracle Database 12c Administrator Certified Professional



ORACLE DATABASE 11G ADMINISTRATOR CERTIFIED PROFESSIONAL MINŐSÍTÉSEM


Oracle Database 11g Administrator Certified Professional




Üzemeltető: Blogger.



Diese Website verwendet Cookies von Google, um Dienste anzubieten und Zugriffe
zu analysieren. Deine IP-Adresse und dein User-Agent werden zusammen mit
Messwerten zur Leistung und Sicherheit für Google freigegeben. So können
Nutzungsstatistiken generiert, Missbrauchsfälle erkannt und behoben und die
Qualität des Dienstes gewährleistet werden.Weitere InformationenOk