prehľad background procesov na Ora11g2 inštancii
Aby som mal rýchlu referenciu, hlavne čo sa týka nepovinných processov.
Background procesy spolu so SGA tvoria inštanciu. V zásade sa dajú rozdeliť na:
- povinné (mandatory) – bežia vždy, keď je database startup
- nepoviné (optional) – podľa konfigurácie a požiadavkov
Všeobecne sa dajú vylistovať pomocou utilít OS (ps), alebo dotazom do systémového katalógu (V$SESSIONS, V$PROCESS). Katalógový view V$PROCESS je obzvlášť užitočný – obsahuje i identifikátory procesov v rámci inštancie, v rámci OS, pamäťové nároky v SGA, cesty k tracelogom jednotlivých procesov a pod…
$ ps -ef | grep ora_ | grep SID
SQL> SELECT sid, name FROM v$session WHERE type = 'background';
Zoznam a popis povinných procesov
SMON
Jest system monitor. Nastupuje pri havárii inštancie (napr. vypnutie elektriky) – tzv. INSTANCE CRASH RECOVERY.
- štartuje automaticky v niekoľkominútovom intervale (kde sa to nastavuje? nerozumiem…)
- prevádza údržbu po štarte, ešte pred OPEN stavom
- kontroluje, či existujú komitnuté transakcie, ktoré nie sú v datafiles; ak áno, použije redology a transakcie zapíše do datafiles
- kontroluje, či existujú nejaké nekomitnuté transakcie, ktoré už sú zapísané v datafiles; ak áno, tak ich odvolá pomocou rollback segmentov (undo tables)
- upratuje bordel v extentoch (???)
- 1 SMON na 1 inštanciu (platí aj pre RAC)
PMON
Jest proces monitor. Stará sa hlavne o klientské prístupy (sessions) a upratuje ich.
- štartuje každé 3 sekundy
- ak je nejaké session, ktorá bola predčasne ukončená, pmon odroluje zmeny back
- stará sa u uvoľnovanie buffer cache po skončení sessions
- obhospodaruje dispatcher na shared serveri
- 1 pmon na 1 inštanciu (jak je to v RAC?)
CKPT
Čekpoint. Stará sa o konzistenciu dát. Nerozumiem celkom, aký vzťah má s DBW a LGWR (je im nadriadený a volá ich?). Asi áno, vzhľadom k tomu, že synchronizuje SCN medzi redologom a datafiles.
- respawnuje každú sekundu (LOG_CHECKPOINT_TIMEOUT; LOG_CHECKPOINT_INTERVAL)
- koná vždy, keď sa zaplní db buffer cache (takže asi áno, zavolá DBW)
- vždy pri switchi redologov, automatickom i manuálnom (ALTER SYSTEM SWITCH LOGFILE)
- súvisí s DB recovery – MTTR (mean time to recover)
- 1 ckpt na 1 inštanciu
DBW
Je Database Writer (alebo Data Buffer Writer). Zapisuje údaje z bufferu do datafiles (dirty blocks) a to vždy, keď:
- dochádza k switchu redo logs, t.j. pri default checkpointe
- je prekročený prah veľkosti dirty block v bufferu
- sa DB shutdownuje, alebo tablespace sa alteruje na OFFLINE/BEGIN BACKUP
- nejaký proces nemôže nájsť čistý buffer block pre nové dáta. Typicky je vracaný nejaký veľký resultset z dotazu do SGA a Oracle nemá kde alokovať pamäť (vyflushovať dirty blocks)
V inštancii môže fungovať až 20 DBW procesov {DBW0-9; DBWa-j}, ale nie je to obvyklé, normálny stav je 1 inštancia/1 DBW. Pokiaľ ich je viac, tak sa môžu trieskať o ten istý data block, čomuž sa predchádza parametrom DB_BLOCK_LRU_LATCHES.
LGWR
Je Log Writer pre redology. Zapisuje dáta z redo bufferov do redologov. Je volaný ďaleko častejšie, nž DBW, pretože redology sú malé (kB až pár málo MB) a prepisujú sa rýchlo. V dobe, keď LGWR zapisuje do redologu, je tento označený ako CURRENT (možné stavy – CURRENT, INACTIVE, ACTIVE).
Kedy sa zapisuje:
- každé 3 sekundy (fakt, to sa mi nezdá? preveriť)
- keď je relo buffer plný z 1/3, alebo keď dosiahne jeho objem 1MB
- keď checkpoint (buď explicitný, alebo pri switchu redologov)
- keď je potvrdená transakcia (ROLLBACK/COMMIT)
RECO
Recoverer pre transakcie v distribuovaných databázach (two phase commit transactions). V prípade, že niečo zlyhá (napr. sieťové spojenie) a jedna z fází commitu zostane nepotvrdená, tak RECO upratuje – rozhoduje o dokončení 2. commitu, alebo rollbacku.
Zoznam nepovinných procesov, menej popisu
ARC
Archiver – archivuje redology po switchu do priestoru na to urečeného (ARCHIVELOG ON). Môže ich byť viac (ARC0-9) a ich počet omedzuje direktíva LOG_ARCHIVE_MAX_PROCESSES
CJQ
Coordinated Job Queue – stará sa o spúšťanie jobov, ktoré sú nadefinované v JOB$
TRWR
Trace writer, zápis do trasovacích súborov, len 1 proces na inštanciu.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
locky
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
LMON, LMD, LCK
Lock Monitor – šéfuje globálne locky, hlavne procesov v inštancii. Len 1 proces na 1 inštanciu; Lock Manager Daemon; Lock Process (až 10 na inštanciu) – správa lockov procesov.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
pamäť
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
MMAN, MMON, MMNL
Managery pre správu pamäte (SGA) s rôznymi kompetenciami. Memory manager – nafukuje a sfukuje súčasti SGA (java pool, data buffer a pod.) podľa potreby. Memory monitor – monitoruje a zbiera štatistiky pre AWR. Memory manager light zbiera štatistiky o sessions history.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
asm
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
ASMB, RBAL
Procesy pre ASM. ASMB sa stará o diskové zdroje a ich synchronizáciu. Zabezpečuje heartbeat v clusteri. RBAL vykonáva rebalancing.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
shared, paralelizácia
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
D(nnn)
Dispatcher, až do tisíc procesov (parameter MAX_DISPATCHERS). Radí klientské požiadavky (sessions) do fronty na spracovanie, t.j. komunikátor medzi klientskými programami a shared serverovými procesmi.
S(nnn)
Shared server processes, až do 1000.
P(nnn)
Paralel execution, až do 1000 procesov.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
data guard
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
DMON
Data Guard Monitor – hlavný proces a hlavný broker. Štartuje automaticky, pokiaľ beží DG. Jeden proces na 1 inštanciu.
NSV(n)
DG Netserver. Stará sa o konektivitu medzi databázami. Môže ich byť toľko, koľko databáz.
DRC(n)
Je proces na slave databázi, ktorý prijím aspojenie z master databáze (spojenie od NSV).
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
data pump
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
DM(n)
Datapump master, šéfovací proces, ktorý úkoluje datapump workera a zároveň obhospodaruje požiadavky klientov. Vytvára a ruší master table.
DW(n)
Datapump worker – to je hlavný makač, loaduje a unloaduje dáta a metadáta, ktoré poručí master.
A naostatok obrázok procesov z ofiko Oracle doku:
