Dotaz: memory advisor u oraclu

[tondo123456]

zdravim,

rad by som sa spytal par otazok ohladom oraclu a priradzovaniu memory, lebo ocividne mi tu nieco unika.

na niekolkych databazach sa snazim optimalizovat priradenu pamat. konkretne mi ide o nasledovne parametre:

memory_max_target memory_target sga_max_size sga_target pga_aggregate_limit pga_aggregate_target

oracle obsahuje roznych advisorov co sa tyka pamate, odporuca mi nasledovne hodnoty:

memory 2500m sga 1520m pga 896m

ake hodnoty by som teda mal nastavit do jednotlivych parametrov?

memory_max_target 2500m memory_target 2500m sga_max_size 2500m sga_target 1520m pga_aggregate_limit 2500m pga_aggregate_target 896m

je taketo nastavenie vzhladom na advisor adekvatne??

nakoniec by som este dodal ze ide o testovaci server s 10timi databazami. cpu nie je problem, databazy sa vacsinu casu aj tak flakaju. ale velmi dolezite pre mna je aby som vedel presne povedat kolko si databaza moze maximalne odkusnut z RAMky.

dakujem

Odpovědi

[Peter Golis]

Ako správca DB Oracle by si mal vedieť čo znamená interná pamäťová architektúra.

[tondo123456]

diky za odpoved

nie som db admin, mam nastarosti OS na ktorom tych 10 db bezi.

konkretnejsie to vyzera takto:

db server ma priradenych 24GB RAM bezi na nom 10 databaz kazda ma nastavene nasledujuce parametre: memory_target=2g, memory_max_target=2g v OS ale vidim ze kazda databaza ma alokovanych podstatne viac ~3 - 3,5GB a tato situacia ma trapi, nakolko 10x 3GB, mi na serveri s 24GB ram, databazy snazia naalokovat 30GB pamate, co znamena ze ide do heavy swappingu (na co sa stazuju aj samotne databazy v alert logoch.

preto zhanam rozumne parametre, ktorymi by som vedel obmedzit maximum pamate ktore si moze naalokovat jedna instancia.

[Peter Golis]

Ako správca OS by si mal vedieť čo je zdieľaná pamäť. Ona sa totižto zdieľa medzi procesmi.

Ohľadne nastavenia, tak skús kontaktovať správcu databázy ktorý ti potvrdí na základe štatistík využitia ako má byť nastavené využitie RAM databázami. A nech aj skontroluje či nejaké indexy nie sú poškodené, alebo chýbajúce. On ten vysoký load na diskoch nemusí byť vždy spôsobený swapovaním.

[Max]

Na to není jednoduchá odpověď. Není to je o tom, že si podle best practicles rozkrájíš paměť a hotovo.
Musíš znát paměťovou architekturu Oracle + musíš znát reálné provozní režie.

Zjednodušeně řečeno, Oracle má něco jako SGA a něco jako PGA. Obě arény do sebe slučují spousty různých paměťových bufferů a keší.

Když to hodně zjednoduším, tak pod PGA spadají režie související s klienty (tzn. kolik máš využitých session procesů apod.) a do SGA spadá cache ohledně db (kešování tabulek apod.).

Dále Oracle umožňuje něco jako Automatic Memory Management(AMM). Každá verze Oracle má tuto fci nějak upravenou, poladěnou, vylepšenou. Ohledně tohoto se používají hodnoty :

MEMORY_TARGET=
MEMORY_MAX_TARGET=

Rovnou říkám, AMM nepoužívat. Je to zabugovaný, mají v tom chyby, které se táhnou s verzí a nějak se to asi moc neřeší. Nám se na EE 12.2 stávalo třeba to, že všude bylo dost paměti a i přesto docházelo k odpojování klientů s hláškama, že paměť není. Výsledkem bylo, že to byl nějaký bug, asi rok starý.

Takže místo AMM používat ruční nastavení paměti. Tj. nedefinovat zmíněné dva parametry a místo toho si definovat aspoň tyto + omezení na procesy a sessions :

SGA_MAX_SIZE=
SGA_TARGET=
PGA_AGGREGATE_TARGET=
SESSIONS=
PROCESSES=

Dále čím víc ram máš pro DB vyhrazeno, tím víc se vyplatí nasadit Huge Pages. A toto je jedna z věcí, která není doporučována u AMM.
Já jsem u nás Huge Pages nasadil na dvounodovém clusteru a parádička.

Jinak, pokud se vymlouváš na to, že nejsi db správce, ale správce OS, tak na to nesahej. Pokud na to chceš sahat, tak se nevymlouvej, že nejsi db správce, protože jakmile nějaký takový zásah děláš, tak se na něj sám pasuješ a měl by jsi tím pádem vědět, co děláš a proč.
Zdar Max

[Ivan]

SGA - je shared memory, je to oblast pro buffer cache, a dalsi sdilene prostredky, jako jsou definice tabulek a predparsovane SQL dostazy.

PGA - private memory. Kazda session ma potrebuje nejakou pamet pro trideni a hash joiny. Vsechny sessions se musi nejak dohodnout aby jejich celkova alokace pameti vice-mene nepresahla tenhle limit. Pokud mas OTLP system, tak tuhle pamet moc nevyuzijes. Pokud provadis slozite analyticke dotazy, tak ji zase potrebujes hodne.

MEMORY_TARGET(AMM) je mod, kde si Oracle sam snazi rozdelit jeden region pameti pro oboji SGA+PGA.

Pokud je o vyuziti pameti tak, pro tebe se asi nejlepsi je prihlasit se do DB pres SQL Developer a vyklikat se AWR report. Anebo si udelej primo SQL dotaz na SGA/PGA advisor.

https://dbaclass.com/article/sga-target-advisory-oracle/

SGA advisor ti ukaze odhad o kolik stoupne/klesne pocet cteni z disku pokud zmenis velikost SGA(buffer cache)

PGA advisor ti ukaze kolik SQL dotazu bude potrebovat vyuzit TEMP tablespace pokud zmenis velikost PGA.

Obecne plati pravidlo, ze zadny DB server by nemel nikdy swapovat. Tahle cinnost kernelu je v pripade DB kontraproduktivni, protoze DB server ma vlastni cache kterou si spravuje. A nema smysl odlivat do swapu stranky cache, ktere obsahuji kopii dat z disku. Proto se pro SGA pouzivaji HugePages, ty maji velikost 2MB coz snizuje velikost TLB a navic jsou neswapovatelne - to zaruci ze cela SGA je vzdy v pameti.