1

Oracle datu bāzes sistēmas 18c tehniskā arhitektūra1

Oracle datu bāze sastāv vismaz no:1) vienas datu bāzes vadības instances. Tā izmanto aperatīvās atmiņas struktūras

un procesus.2) vienas datu bāzes. Datu bāze sastāv no fiziskiem failiem, ko sauc par datu

failiem, un tā var būt bez konteinera datu bāze vai vairāku nomnieku (multitenant) konteineru datu bāze. Oracle datu bāze savas darbības laikā izmanto arī vairākus datu bāzes sistēmas failus.

Viena instances (eksemplāra) datu bāzes arhitektūra sastāv no vienas datu bāzes vadības instances un vienas datu bāzes. Pastāv relācija “viens pret vienu” starp datu bāzi un datu bāzes vadības instanci. Vienā servera datorā var instalēt vairākas vienas instances datu bāzes. Katrai datu bāzei ir atsevišķas datu bāzes vadības instances. Šī konfigurācija ir noderīga, lai tajā pašā datorā palaistu dažādas Oracle datu bāzes versijas.Oracle Real Application Clusters (Oracle RAC) datu bāzes arhitektūra sastāv no vairākām instancēm, kas tiek palaistas atsevišķos serveru datoros. Visi koplieto vienu datu bāzi. Servera datoru klasteris vienā galā tiek parādīts kā viens serveris, bet otrā galā ir lietotāji un lietojumprogrammas. Šī konfigurācija ir paredzēta augstas pieejamības, mērogojamības un augstas veiktspējas nodrošināšanai.Klausītājs (listener)ir datu bāzes servera process. Tas saņem klienta pieprasījumus, izveido savienojumu ar datu bāzes vadības instanci un pēc tam veido klienta savienojumu ar servera procesu. Klausītājs var darboties lokāli datu bāzes serverī vai izpildīties attāli. Tipiskā Oracle RAC vidē tas tiek palaists attāli.

1 https://www.oracle.com/webfolder/technetwork/tutorials/architecture-diagrams/18/technical-architecture/database-technical-architecture.html

2

Datu bāzes vadības instance ietver:1) Oracle datu bāzes fona procesus;2) atmiņas struktūru kopu.

Galvenās atmiņas struktūras ir:1) System Global Area (SGA);2) Program Global Areas (PGAs).

Fona procesi darbojas uz datu bāzē saglabātajiem datiem (datu failiem) un izmanto atmiņas struktūras, lai veiktu savu darbu. Datu bāzes instance pastāv tikai atmiņā.Oracle Database izveido arī servera procesus, lai klientu programmu vārdā apstrādātu savienojumus ar datu bāzi un veiktu klienta programmu darbu, piemēram, analizētu (parse) un palaistu SQL priekšrakstus, kā arī izgūtu un atgrieztu rezultātus klienta programmās. Šie serveru procesu veidi tiek saukti arī par priekšplāna procesiem.

3

System Global Area (SGA) ir atmiņas apgabals, kas satur datus un vadības informāciju vienai Oracle datu bāzes vadības instancei. Visiem servera un fona procesiem ir koplietojams SGA. Startējot datu bāzes vadības instanci, tiek parādīts SGA piešķirtais atmiņas apjoms. SGA ietver šādas datu struktūras:1. Koplietojams pūls (shared pool): kešatmiņā tiek ievietotas dažādas konstrukcijas, kuras var koplietot lietotāji. Piemēram, koplietotā pūla krātuvēs tiek glabāta:

1) SQL vaicājumi;2) PL/SQL kods;3) sistēmas parametru vērtības;4) datu vārdnīcas informācija.

Koplietojamais pūls ir iesaistīts gandrīz visās darbībās, kas notiek datu bāzē. Piemēram, ja lietotājs izpilda SQL priekšrakstu, Oracle Database izmanto koplietojama pūlu.2. Atpakaļgaitas buferis (flashback buffer): ir papildu komponents SGA. Ja ir iespējota datu bāze Flashback Database, tiek sākts fona process ar nosaukumu Recovery Writer Process (RVWR). Tas periodiski kopē modificētos blokus no bufera kešatmiņas uz slēpto buferu un secīgi ieraksta Flashback datu bāzes datus no atgriezeniskās saites bufera uz Flashback datu bāzes žurnāliem, kas ir cirkulāri atkārtoti izmantotojami.3. Datu bāzes bufera kešatmiņa (database buffer cache): ir atmiņas apgabals, kurā glabājas no datu failiem nolasītās datu bloku kopijas. Buferis ir galvenā atmiņas adrese, kurā bufera pārvaldnieks īslaicīgi ievieto kešatmiņā pašlaik vai nesen lietoto datu bloku. Visi lietotāji, kas vienlaikus ir savienoti ar datu bāzes instanci, koplieto piekļuvi bufera kešatmiņai.4. Datu bāzes Smart Flash kešatmiņa (smart flash cache): ir papildu atmiņas paplašinājums datu bāzes buferim datu bāzes sistēmām, kas darbojas ar Solaris vai Oracle Linux. Tā nodrošina 2. līmeņa kešatmiņu datu bāzes blokiem. Tas var uzlabot atbildes laiku un vispārējo caurlaidspēju gan lasāmai tiešsaistes transakciju apstrādei

4

(OLTP), gan ad hoc vaicājumiem un lielapjoma datu modifikācijām datu noliktavas (Data Warehouse) vidē. Datu bāzes Smart Flash kešatmiņa atrodas vienā vai vairākās zibatmiņas (flash) diska ierīcēs, kas ir cietā stāvokļa atmiņas ierīces, kuras izmanto zibatmiņu. Datu bāzes Smart Flash kešatmiņa parasti ir ekonomiskāka par papildu galveno atmiņu, un tā ir ātrāka nekā diskdziņiem.5. Redo sistēmas žurnāls (log buffer): ir cirkulārs buferis SGA, kas satur informāciju par datu bāzē veiktajām izmaiņām. Šī informācija tiek glabāta Redo ierakstos. Atsaukšanas ievadnes satur informāciju, kas nepieciešama, lai rekonstruētu (vai atceltu) izmaiņas, kas datu bāzē veiktas ar datu apstrādes valodu (DML), datu definēšanas valodu (DDL) vai iekšējām operācijām. Ja nepieciešams, datu bāzes atkopšanai tiek izmantoti atsaukšanas ieraksti.6. Lielais pūls (large pool): ir papildu atmiņas apgabals, kas paredzēts atmiņas paplašināšanai un ir lielāks, nekā paredzētais apjoms koplietotojuma pūlam. Lielais pūls var nodrošināt lielus atmiņas papildinājumus:1) koplietotā servera un Oracle XA interfeisa lietotāja globālajam apgabalam (User Global Area). To izmanto, ja transakcijas mijiedarbojas ar vairākām datu bāzēm; 2) ziņojumu buferiem, kurus izmanto paralēlu priekšrakstu izpildei;3) buferus atkopšanas pārvaldnieka (RMAN) ievadizvades vajadzībām.7. Atmiņas zona (in-memory area): ir neobligāta komponente, kas ļauj objektus (tabulas, partīcijas un citus tipus) saglabāt atmiņā jaunā formātā, ko sauc par kolonnveida formātu. Šis formāts ļauj skenēt, savienot un apkopot failus daudz ātrāk nekā tradicionālais diska formāts, tādējādi nodrošinot ātru pārskatu sniegšanu un DML veiktspēju gan OLTP, gan DW vidēs. Šis līdzeklis ir īpaši noderīgs analītiskām lietojumprogrammām, kas darbojas dažās kolonnās, kas atgriež daudzas rindas, nevis OLTP, kas darbojas dažās rindās, kuras atgriež daudzas kolonnas.8. Kopīgais ievadizvades pūls jeb fonds (shared I/O pool SecureFiles): tiek izmantots lielām ievadizvades darbībām SecureFile lielos objektos (LOB). Tas ir paredzēta liela datu apjoma glabāšanai. Tas ir LOB krātuves parametrs, kas atļauj dedublēšanu, šifrēšanu un saspiešanu.9. Plūsmu jeb straumju pūls (streams pool): tiek izmantots Oracle Strams, Data Pump un GoldenGate integrētos datu iegūšanas un lietošanas procesos. Straumju pūls glabā buferētos rindas ziņojumus, un tas nodrošina atmiņu Oracle straumes izmantošanas procesiem un procesu lietošanai. Ja vien tas nav īpaši konfigurēts, Streams pūla lielums sākas ar nulli. Izmantojot Oracle plūsmas, pūla lielums dinamiski palielinās, kā nepieciešams.10. Java pūls: tiek izmantots visiem Java kodiem un datiem Java Virtual Machine (JVM). Java pūla atmiņa tiek izmantota dažādos veidos atkarībā no režīma, kurā darbojas Oracle datu bāze.11. Fiksēts SGA: ir iekšējā lietošanas atmiņa, kas satur vispārīgu informāciju par datu bāzes stāvokli un datu bāzes instanci, kā arī informāciju, kas tiek pārraidīta starp procesiem.

5

Programmas globālais apgabals (PGA) ir atmiņas apgabals, kas nav koplietojams un kurā ir dati un vadības informācija, ko izmanto tikai:

1) servera procesi;2) fona procesi.

DBS izveido servera procesus, lai klientu programmu vārdā apstrādātu savienojumus ar datu bāzi. Īpašā servera vidē katram serverim tiek izveidots viens PGA un sākts fona process. Katrs PGA sastāv no steka vietas un lietotāja globālās zonas (USER Global Area - UGA). PGA tiek atbrīvots, kad tiek pārtraukts saistītais serveris vai fona process, kas to izmanto.

Koplietotā servera vidē servera procesu koplieto vairāki klienta lietotāji. UGA tiek pārvietots uz SGA (koplietojams pūls vai liels pūls, ja tas ir konfigurēts), atstājot PGA tikai steka vietu.

Steka vieta ir atmiņa, kas piešķirta sesijas mainīgajiem un masīviem.Īpašā servera sesijā UGA sastāv no šādiem komponentiem:1) SQL darba apgabali: tie ir privātie PGA atmiņas piešķīrumi, ko izmanto SQL operācijām ar augstu atmiņas intensitāti. Kārtošanas apgabalu izmanto funkcijas, kas pasūta datus, piemēram, ORDER BY un GROUP BY. Jaucējzona (hešzona) tiek

6

izmantota tabulu jaukšanas savienojumu veikšanai. Bitkaršu (BITMAP) sapludināšanas apgabals tiek izmantots, lai sapludinātu datus, kas izgūti no vairāku bitkaršu indeksu skenējumiem.2) sesijas atmiņa: šī lietotāja sesijas datu glabāšanas zona tiek piešķirta sesijas mainīgajiem, piemēram, pieteikšanās informācijai un citai informācijai, kas nepieciešama datu bāzes sesijai. OLAP pūls pārvalda OLAP datu lapas, kas ir līdzvērtīgas datu blokiem.3) privāts SQL apgabals: šajā apgabalā ir informācija par analizētu SQL priekšrakstu un cita ar sesiju saistīta informācija apstrādei. Kad servera process izpilda SQL vai PL/SQL kodu, process izmanto privāto SQL apgabalu, lai saglabātu saistījuma mainīgo vērtības, vaicājuma izpildes stāvokļa informāciju un vaicājumu izpildes darba apgabalus. Vairāki privātie SQL apgabali vienā un tajā pašā vai dažādās sesijās var norādīt uz vienu izpildes plānu SGA. Pastāvīgais apgabals satur saistījuma mainīgās vērtības. Izpildes laika apgabalā ir iekļauta vaicājuma izpildes stāvokļa informācija. Kursors ir nosaukums vai turis uz noteiktu apgabalu privātajā SQL apgabalā. Kursoru var uztvert kā rādītāju klienta pusē un kā stāvokli servera pusē. Tā kā kursori ir cieši saistīti ar privātiem SQL apgabaliem, termini dažreiz tiek lietoti savstarpēji.

7

Fona procesi ir daļa no datu bāzes vadības instances un veic uzturēšanas uzdevumus, kas nepieciešami, lai darbinātu datu bāzi un palielinātu veiktspēju vairākiem lietotājiem. Katrs fona process veic unikālu uzdevumu, bet strādā ar pārējiem procesiem. DBS izveido fona procesus automātiski, startējot datu bāzes vadības instanci. Fona procesi ir atkarīgi no datu bāzē izmantotajiem līdzekļiem. Startējot datu bāzes instanci, automātiski tiek startēti obligātie fona procesi. Pēc nepieciešamības var sākt papildu fona procesus.Obligātie fona procesi ir pieejami visās tipiskajās datu bāzu konfigurācijās. Šie procesi pēc noklusējuma tiek palaisti lasīšanas/rakstīšanas datu bāzes instancē, kas sākta ar minimāli konfigurētu inicializācijas parametru failu. Tikai lasāma datu bāzes instance atspējo dažus no šiem procesiem. Obligātie fona procesi ir:

1) procesu pārraugs (PMON);2) procesu pārvaldnieka process (PMAN);3) klausītāja reģistrēšanas process (LREG);4) sistēmas pārraugs (SMON);5) datu bāzes rakstītāja process (DBWn);6) kontrolpunkta process (CKPT);7) pārvaldības pārraugs (MMON);8) pārvaldības pārraugs Lite process (MMNL);9) atjaunošanas process (RECO);10) žurnāla rakstītājs (LGWR).

Lielākā daļa neobligāto fona procesu ir specifiski uzdevumiem vai funkcijām. Daži izplatīti izvēles procesi ietver arhivēšanas procesus (ARCn), darbu rindas koordinatora procesu (CJQ0), atkopšanas rakstītāja procesu (RVWR), Flashback datu arhīva procesu (FBDA) un telpas pārvaldības koordinatora procesu (SMCO).Pakārtotie procesi ir fona procesi, kas veic darbu citu procesu vārdā; piemēram, rakstītāju process (Dnnn) un koplietojamo serveru process (Snnn).

8

Koplietojuma pūls

Koplietojams pūls (shared pool) ir sistēmas globālās atmiņas (System Global Area (SGA)) komponents, un tas ir atbildīgs par dažādu programmas datu veidu kešdarbību. Piemēram, koplietojamais pūls glabā analizēto SQL, PL/SQL kodu, sistēmas parametrus un datu vārdnīcas informāciju. Koplietojamais pūls ir iesaistīts gandrīz visās darbībās, kas notiek datu bāzē. Piemēram, ja lietotājs izpilda SQL priekšrakstu, DBS izmanto koplietojamaja pūlu.Koplietojuma pūls ir sadalīts vairākos apakškomponentos:1) bibliotēkas kešatmiņa (library cashe) ir koplietojama pūla atmiņas struktūra, kurā glabājas izpildāms SQL un PL/SQL kods. Šajā kešatmiņā ir koplietotie SQL un PL/SQL apgabali un vadības struktūras, piemēram, slēdzenes (locks) un bibliotēkas kešatmiņas turi (handles). Koplietojamā servera arhitektūrā bibliotēkas kešatmiņā ir arī lietotāja globālais apgabals (USER Global Area (UGA)). Kad SQL priekšraksts ir izpildīts, datu bāze mēģina atkārtoti izmantot iepriekš izpildīto kodu. Ja bibliotēkas kešatmiņā pastāv SQL priekšraksta analizētais attēlojums un to var koplietot, datu bāze atkārtoti izmanto šo kodu. Šo darbību sauc par mīksto analīzi (soft parse) vai bibliotēkas kešatmiņas trāpījumu (library cashe hit). Pretējā gadījumā datu bāzei ir jāizveido jauna lietojumprogrammas koda izpildāmā versija, kas pazīstama kā cietā analīze (hard parse) vai bibliotēkas kešatmiņas netrāpījums (miss).2) rezervēts pūls (reserved pool): ir atmiņas apgabals koplietojamā pūlā, ko datu bāze var izmantot, lai piešķirtu lielas blakusesošas atmiņas daļas. Datu bāze piešķir atmiņu no

9

koplietojamā pūla pa daļām. Šķelšana ļauj kešatmiņā ielādēt lielus objektus (virs 5 KB), nepieprasot vienu nepārtrauktu apgabalu. Šādā veidā datu bāze samazina iespēju zaudēt blakus esošo atmiņu fragmentācijas dēļ.3) datu vārdnīcas kešatmiņa (data dictionary cashe): saglabā informāciju par datu bāzes objektiem (t.i., vārdnīcas datiem). Šo kešatmiņu sauc arī par rindu kešatmiņu, jo tajā dati ir nevis buferi, bet gan rindas.4) servera rezultātu kešatmiņa: ir koplietotā pūla atmiņas pūls, kurā ir rezultātu kopas. Servera rezultātu kešatmiņā ir SQL vaicājumu rezultātu kešatmiņa un PL/SQL funkciju rezultātu kešatmiņa, kas koplieto vienu infrastruktūru. SQL vaicājumu rezultātu kešatmiņa saglabā vaicājumu un vaicājumu fragmentu rezultātus. Lielākā daļa lietojumprogrammu gūst labumu no šīs veiktspējas uzlabošanas. PL/SQL funkciju rezultātu kešatmiņa saglabā funkciju rezultātu kopas. Labi kandidāti rezultātu rakstīšanai kešatmiņā bieži tiek piesauktas funkcijas, kas ir atkarīgas no samērā statiskiem datiem.5) citi komponenti: iekļaut enqueues, slēgumus (latches), informācijas dzīves cikla pārvaldības (ILM) bitkaršu tabulas, aktīvās sesijas vēstures (ASH) buferus, kontrolpunktu rindu, nesen izmantotu (LRU) sarakstu un citas mazsvarīgas atmiņas struktūras. Enqueues ir koplietojamas atmiņas struktūras (slēdzenes), kas serializē piekļuvi datu bāzes resursiem. Tos var saistīt ar sesiju vai transakciju. Piemēri: Controlfile transakcija, Datafile, instances atkopšana, multivides atkopšana, transakciju atkopšana, darbu rinda utt. Slēgmehānismi tiek izmantoti kā zema līmeņa serializācijas kontroles mehānisms, ko izmanto, lai aizsargātu koplietojamo datu struktūras SGA no vienlaicīgas piekļuves. Piemēram, kešatmiņas buferi LRU ķēde, rindu kešatmiņas objekti, bibliotēkas kešatmiņas tapas un žurnālfaila paralēlais rakstīšana.

10

Datu bāzes vadības instance

Lielais pūls (large pool) ir papildu atmiņas apgabals, ko datu bāzes administrators var konfigurēt, lai nodrošinātu lielu atmiņas sadalījumu šādām vajadzībām:1) lietotāja globālā atmiņa (UGA): sesijas atmiņa koplietotajam serverim un Oracle 2) XA saskarnei (izmanto, ja transakcijas mijiedarbojas ar vairākām datu bāzēm);2) ievadizvades bufera apgabals: ievadizvades servera procesi, ziņojumu buferi, ko izmanto paralēlajās vaicājumu operācijās, buferi atkopšanas pārvaldnieka (RMAN) ievadizvades apakšprocesiem un uzlabotās rindas atmiņas tabulas glabāšana.3) brīvā atmiņa.Lielais pūls atšķiras no rezervētās vietas koplietotajā pūlā, kurā tiek izmantots tas pats nesen izmantotais (LRU) saraksts kā citā atmiņā, kas piešķirta no koplietojamā pūla. Lielajam pūlam nav LRU saraksta. Atmiņas daļas tiek sadalītas, un tās nevar atbrīvot, kamēr tās tiek izmantotas.Lietotāja pieprasījums ir atsevišķs API izsaukums, kas ir daļa no lietotāja SQL priekšraksta. Īpašā servera vidē viens servera process apstrādā viena klienta procesa pieprasījumus. Katrs servera process izmanto sistēmas resursus, ieskaitot centrālā procesora ciklus un atmiņu. Koplietojamā servera vidē tiek veiktas šādas darbības:1. Klienta pieteikums nosūta pieprasījumu datu bāzes instancei, un šo pieprasījumu saņem dispečers.2. Dispečers novieto pieprasījumu pieprasījuma rindā lielajā pūlā.3. Pieprasījumu paņēm nākamais pieejamais koplietotā servera process. Koplietotā servera procesi pārbauda, vai kopējā pieprasījuma rindā nav jaunu pieprasījumu, un

11

izvēlas jaunus pieprasījumus, sākot darbu. Viens koplietojamā servera process paņem vienu pieprasījumu rindā.4. Koplietojamā servera process veic visus nepieciešamos izsaukumus datu bāzei, lai pabeigtu pieprasījumu:1) vispirms koplietotā servera process piekļūst bibliotēkas kešatmiņai koplietojamajā pūlā, lai pārbaudītu pieprasītos vienumus; piemēram, tas pārbauda, vai tabula pastāv, vai lietotājam ir pareizās privilēģijas utt. 2) pēc tam koplietotā servera process piekļūst bufera kešatmiņai, lai izgūtu datus. Ja datu tur nav, koplietotā servera process piekļūst diskam. Katrs datu bāzes izsaukums var tikt apstrādāts citā koplietojamā servera procesā. Tāpēc pieprasījumus analizē vaicājumu, izgūst pirmo rindu, izgūst nākamo rindu un beigās aizver rezultātu kopu, lai to var apstrādāt cits koplietojams servera process. Tā kā katrs datu bāzes izsaukums var tikt apstrādāts citā koplietojamā servera procesā, lietotāja globālajam apgabalam (USER Global Area (UGA)) ir jābūt koplietojamās atmiņas apgabalam, jo UGA satur informāciju par katru klienta sesiju. UGA satur informāciju par katru klienta sesiju, un tai jābūt pieejamai visiem koplietotajiem servera procesiem, jo jebkurš koplietojams servera process var apstrādāt jebkuras sesijas datu bāzes izsaukumu.5. Pēc pieprasījuma pabeigšanas koplietojama servera process novieto atbildi dispečera atbildes rindā lielajā pūlā. Katram dispečeram ir sava atbildes rinda.6. Atbildes rinda nosūta atbildi dispečeram.7. Dispečers atgriež aizpildīto pieprasījumu atbilstošajai klienta lietojumprogrammai.

12

Datu bāzes bufera kešatmiņa, ko sauc arī par bufera kešatmiņu, ir atmiņas apgabals System Global Area (SGA), kurā glabājas no datu failiem lasīto datu bloku kopijas. Buferis ir datu bāzes bloka lieluma atmiņas daļa. Katram buferim ir adrese, ko sauc par datu bāzes buferadresi (DBA). Visi lietotāji, kas vienlaikus ir savienoti ar datu bāzes instanci, koplieto piekļuvi bufera kešatmiņai. Bufera kešatmiņas mērķis ir optimizēt fizisko ievadizvades apjomu un paturēt bieži pieejamos blokus bufera kešatmiņā un ierakstīt diska blokus, kuriem bieži piekļūst.Pirmo reizi, kad Oracle datu bāzes lietotāja procesam ir nepieciešams konkrēts datu kopums, tas meklē datus datu bāzes bufera kešatmiņā. Ja process atrod datus, kas jau atrodas kešatmiņā (kešatmiņas trāpījums (hit)), tas var nolasīt datus tieši no atmiņas. Ja process nevar atrast datus kešatmiņā (nav kešatmiņā (miss)), pirms piekļūšanas datiem datu bloks ir jākopē no datu faila diskā uz buferi kešatmiņā. Piekļūšana datiem, izmantojot kešatmiņas trāpījumu, ir ātrāka nekā piekļuve datiem, izmantojot kešatmiņas papildināšanu no faila.Buferus kešatmiņā pārvalda sarežģīts algoritms, kurā tiek izmantota nesen lietoto (Last Recently Used) sarakstu un veiksmju skaita skaitīšanu. LRU palīdz nodrošināt, ka nesen izmantotie bloki mēdz palikt atmiņā, lai samazinātu diska izmantošanu.Datu bāzes bufera kešatmiņa sastāv no:1) noklusējuma kopa (default pool) ir vieta, kur bloki parasti tiek ierakstīti kešatmiņā. Noklusējuma bloka lielums ir 8 KB. Ja vien nekonfigurējat atsevišķus pūlus manuāli, noklusējuma pūls ir vienīgais bufera pūls. Pārējo pūlu papildu konfigurācija neietekmē noklusējuma pūlu.2) uzturamais pūls (keep pool) ir paredzēts blokiem, kuriem piekļūst bieži, bet kuri ir novecojuši no noklusējuma pūla, jo trūkst vietas. Buferkopas glabāšanas mērķis ir saglabāt noteiktus objektus atmiņā, tādējādi izvairoties no ievadizvades darbībām.3) atritnes pūls (recycle pool) ir paredzēts blokiem, kas tiek lietoti reti. Aritnes pūls neļauj norādītajiem objektiem izmantot nevajadzīgo vietu kešatmiņā.4) nenoklusējuma buferu pūli (non-defaultbuffer pools) ir priekš tabultelpām, kas izmanto nestandarta bloku lielumus 2 KB, 4 KB, 16 KB un 32 KB. Katram bloka

13

lielumam, kas nav noklusējuma, ir savs pūls. Oracle Database pārvalda blokus šajos pūlos tāpat kā noklusējuma pūlā.5) datu bāzes Smart Flash kešatmiņa (flash cache) ļauj izmantot zibatmiņas ierīces, lai palielinātu bufera kešatmiņas efektīvo lielumu, nepievienojot vairāk galvenās atmiņas. Zibatmiņas kešatmiņa var uzlabot datu bāzes veiktspēju, jo datu bāzes kešatmiņas dati bieži tiek saglabāti zibatmiņā, nevis tiek nolasīti no magnētiskā diska. Kad datu bāze pieprasa datus, sistēma vispirms meklē datu bāzes bufera kešatmiņā. Ja dati netiek atrasti, sistēma meklē datu bāzes Smart Flash kešatmiņas buferī. Ja tur datus neatrod, tikai tad tas izskatās diska krātuvē. Residue Real Application Clusters vidē ir jākonfigurē zibatmiņas kešatmiņa vai nu visās instancēs, vai arī ne.6) flash bufera apgabals (flash buffer area) sastāv no Default Flash LRU Chain un KEEP Flash LRU Chain. Bez datu bāzes Smart Flash kešatmiņas, kad process mēģina piekļūt blokam un bloks bufera kešatmiņā nepastāv, bloks vispirms tiks nolasīts no diska atmiņas (fiziski nolasīts). Kad atmiņas bufera kešatmiņa būs pilna, buferis tiks izņemts no atmiņas, pamatojoties uz nesen izmantotu (LRU) mehānismu. Izmantojot datu bāzes viedās zibatmiņas kešatmiņu, kad tīrais atmiņas buferis ir novecojis, bufera saturu fona atmiņā ieraksta datu bāzes rakstītāja process (DBWn), un bufera galvene tiek paturēta atmiņā kā metadati, izmantojot DEFAULT FLASH, vai arī KEEP FLASH, atkarībā no objekta atribūta FLASH_CACHE vērtības, tiek saglabāts Flash LRU saraksts. KEEP flash LRU sarakstu izmanto, lai paturētu buferu galvenes atsevišķā sarakstā, neļaujot regulārajām buferu galvenēm tās aizstāt. Tādējādi zibatmiņas bufera galvenes, kas pieder objektam, kurš norādīts kā KEEP, mēdz ilgāk uzturēties zibatmiņas kešatmiņā. Ja objekta atribūts FLASH_CACHE ir iestatīts uz NONE, sistēma nesaglabā atbilstošos buferus zibatmiņas kešatmiņā vai atmiņā. Kad buferim, kas jau bija novecojis, vairs nav atmiņas, sistēma pārbauda zibatmiņas kešatmiņu. Ja buferis tiek atrasts, tas tiek nolasīts atpakaļ no zibatmiņas kešatmiņas, kas aizņem tikai daļu no diska nolasīšanas laika. Zibatmiņas kešatmiņas buferu konsistence starp Real Application Clusters (RAC) tiek saglabāta tāpat kā ar Cache Fusion. Tā kā zibatmiņas kešatmiņa ir paplašināta kešatmiņa un tiešais ceļš I/O pilnībā apiet bufera kešatmiņu, šis līdzeklis neatbalsta tiešo ceļu I/O. Ievērojiet, ka sistēma neievieto netīrus buferus zibatmiņas kešatmiņā, jo tai, iespējams, ir jāizlasa buferi atmiņā, lai tos pārbaudītu, jo rakstīšana uz zibatmiņas kešatmiņu neskaitās uz kontrolpunktu.

14

The In-Memory Area is an optional SGA component that contains the In-Memory column store (IM column store), which stores tables and partitions in memory using a columnar format optimized for rapid scans. The IM column store enables data to be simultaneously populated in the SGA in both the traditional row format (in the buffer cache) and a columnar format. The database transparently sends online transactional processing (OLTP) queries, such as primary key lookups, to the buffer cache, and analytic and reporting queries to the IM column store. When fetching data, Oracle Database can also read data from both memory areas within the same query. The dual-format architecture does not double memory requirements. The buffer cache is optimized to run with a much smaller size than the size of the database.You should populate only the most performance-critical data in the IM column store. To add an object to the IM column store, turn on the INMEMORY attribute for an object when creating or altering it. You can specify this attribute on a tablespace (for all new tables and views in the tablespace), table, (sub)partition, materialized view, or subset of columns within an object.The IM column store manages both data and metadata in optimized storage units, not in traditional Oracle data blocks. An In-Memory Compression Unit (IMCU) is a compressed, read-only storage unit that contains data for one or more columns. A Snapshot Metadata Unit (SMU) contains metadata and transactional information for an associated IMCU. Every IMCU maps to a separate SMU.The Expression Statistics Store (ESS) is a repository that stores statistics about expression evaluation. The ESS resides in the SGA and also persists on disk. When an IM column store is enabled, the database leverages the ESS for its In-Memory Expressions (IM expressions) feature. An In-Memory Expression Unit (IMEU) is a storage container for materialized IM expressions and user-defined virtual columns. Note that the ESS is independent of the IM column store. The ESS is a permanent component of the database and cannot be disabled. Conceptually, an IMEU is a logical extension of its parent IMCU. Just as an IMCU can contain multiple columns, an IMEU can contain multiple virtual columns. Every IMEU maps to exactly one IMCU, mapping to the same row set. The IMEU contains expression results for the data contained in its associated IMCU. When the IMCU is populated, the associated IMEU is also populated.A typical IM expression involves one or more columns, possibly with constants, and has a one-to-one mapping with the rows in the table. For example, an IMCU for an EMPLOYEES table contains rows 1-

15

1000 for the column weekly_salary. For the rows stored in this IMCU, the IMEU calculates the automatically detected IM expression weekly_salary*52, and the user-defined virtual column quarterly_salary defined as weekly_salary*12. The third row down in the IMCU maps to the third row down in the IMEU.The In-Memory area is sub-divided into two pools: a 1MB columnar data pool used to store the actual column-formatted data populated into memory (IMCUs and IMEUs), and a 64K metadata pool used to store metadata about the objects that are populated into the IM column store. The relative size of the two pools is determined by internal heuristics; the majority of the In-Memory area memory is allocated to the 1MB pool. The size of the In-Memory area is controlled by the initialization parameter INMEMORY_SIZE (default 0) and must have a minimum size of 100MB. Starting in Oracle Database 12.2, you can increase the size of the In-Memory area on the fly by increasing the INMEMORY_SIZE parameter via an ALTER SYSTEM command by at least 128MB. Note that it is not possible to shrink the size of the In-Memory area on the fly.An in-memory table gets IMCUs allocated in the IM column store at first table data access or at database startup. An in-memory copy of the table is made by doing a conversion from the on-disk format to the new in-memory columnar format. This conversion is done each time the instance restarts as the IM column store copy resides only in memory. When this conversion is done, the in-memory version of the table gradually becomes available for queries. If a table is partially converted, queries are able to use the partial in-memory version and go to disk for the rest, rather than waiting for the entire table to be converted.In response to queries and data manipulation language (DML), server processes scan columnar data and update SMU metadata. Background processes populate row data from disk into the IM column store. The In-Memory Coordinator Process (IMCO) is a background process that initiates background population and repopulation of columnar data. The Space Management Coordinator Process (SMCO) and Space Management Worker Processes (Wnnn) are background processes that do the actual populating and repopulating of data on behalf of IMCO. DML block changes are written to the buffer cache, and then to disk. Background processes then repopulate row data from disk into the IM column store based on the metadata invalidations and query requests.You can enable the In-Memory FastStart feature to write the columnar data in the IM Column Store back to a tablespace in the database in compressed columnar format. This feature makes database startup faster. Note that this feature does not apply to IMEUs. They are always populated dynamically from the IMCUs.

16

Datu bāze ir fizisko failu kopa, kas glabā lietotāja datus un metadatus. Metadati sastāv no:

1) datu bāzes struktūras informācijas;2) konfigurācijas informācijas;3) vadības informācijas par datu bāzes serveri.

Datu bāzi var noformēt kā:1) vairāku nomnieku (multitenant) konteinera datu bāzi (CDB); 2) datu bāzi bez konteinera (ne-CDB).

CDB sastāv no:1) viena CDB saknes konteinera (ko sauc arī par sakni);2) tieši no vienas spraudeņu datu bāzes (seed PBP);3) nulles vai vairāk lietotāju radītām spraudeņu datu bāzēm (ko sauc vienkārši par

PDBs);4) no nulles vai vairāk lietojumprogrammu konteineriem.

Visu CDB sauc par sistēmas konteineru. Lietotājam vai lietojumprogrammai PDBs tiek parādītas loģiski kā atsevišķas datu bāzes.CDB saknē, ko sauc par CDB $ROOT, ir vairāki datu faili, vadības faili, redo-log žurnālfaili, slēptie žurnāli un arhivētie redo žurnālfaili. Datu failos tiek glabāti Oracle izmantotie metadati un bieži lietotie lietotāji (lietotāji, kas ir zināmi katrā konteinerā), kas tiek kopīgoti ar visiem PDBs.Spraudeņu PBP, ko sauc par PBP $SEED, ir sistēmas piegādāta PBP veidne, kurā ir vairāki datu faili, kurus var izmantot jaunu PDBs izveidei.

17

Regulārajā PBP ir iekļauti vairāki datu faili, kuros ir dati un kods, kas nepieciešams lietojumprogrammas atbalstam, piemēram, programma Cilvēkresursi. Lietotāji mijiedarbojas tikai ar PDBs, nevis spraudņu PBP vai sakņu konteineru. CDB var izveidot vairākas PDBs. Viens no vairāku nomnieku arhitektūras mērķiem ir tas, ka katram PBP ir relācija “viens pret vienu” ar lietojumprogrammu.Lietojumprogrammas konteiners ir papildu PDBs kolekcija CDB, kurā tiek glabāti lietojumprogrammas dati. Lietojumprogrammas konteinera izveides mērķis ir vienas galvenās lietojumprogrammas definīcija. CDB var būt vairāki lietojumprogrammu konteineri.Datu bāze ir sadalīta loģiskās atmiņas vienībās, ko sauc par tabultelpām (tablespaces), kas kopā saglabā visus datu bāzes datus. Katru tabulas telpu veido viens vai vairāki datu faili. Saknes konteineram un parastajiem PDBs ir šādas tabultelpas: SYSTEM, SYSAUX, USERS, TEMP un UNDO (nav obligāta parastā PBP). Spraudņu PBP ir SYSTEM, SYSAUX, TEMP un UNDO tabultelpas.

A database is a set of physical files that store user data and metadata. The metadata consists of structural, configuration, and control information about the database server. You can design your database to be a multitenant container database (CDB) or a non-container database (non-CDB).A CDB is made up of one CDB root container (also called the root), exactly one seed pluggable database (seed PDB), zero or more user-created pluggable databases (simply referred to as PDBs), and zero or more application containers. The entire CDB is referred to as the system container. To a user or application, PDBs appear logically as separate databases.The CDB root, named CDB$ROOT, contains multiple data files, control files, redo log files, flashback logs, and archived redo log files. The data files store Oracle-supplied metadata and common users (users that are known in every container), which are shared with all PDBs.The seed PDB, named PDB$SEED, is a system-supplied PDB template containing multiple data files that you can use to create new PDBs.The regular PDB contains multiple data files that contain the data and code required to support an application; for example, a Human Resources application. Users interact only with the PDBs, and not the seed PDB or root container. You can create multiple PDBs in a CDB. One of the goals of the multitenant architecture is that each PDB has a one-to-one relationship with an application.An application container is an optional collection of PDBs within a CDB that stores data for an application. The purpose of creating an application container is to have a single master application definition. You can have multiple application containers in a CDB.A database is divided into logical storage units called tablespaces, which collectively store all the database data. Each tablespace represents one or more data files. The root container and regular PDBs have a SYSTEM, SYSAUX, USERS, TEMP, and UNDO tablespace (optional in a regular PDB). A seed PDB has a SYSTEM, SYSAUX, TEMP, and optional UNDO tablespace.

18

Koplietotā servera arhitektūrā klienti veido savienojumu ar dispečera procesu (Dnnn), kas katram savienojumam izveido virtuālu shēmu. Kad klients nosūta datus uz serveri, dispečers datus nogādā virtuālajā ķēdē un aktīvo shēmu uz kopējās rindas paņem dīkstāves koplietojamā servera process (Snnn). Tad Snnn nolasa datus no virtuālās ķēdes un veic datu bāzes darbu, kas nepieciešams, lai izpildītu pieprasījumu. Kad Snnn jānosūta dati klientam, Snnn ieraksta datus atpakaļ virtuālajā ķēdē un Dnnn nosūta datus klientam. Pēc tam, kad Snnn ir izpildījis klienta pieprasījumu, virtuālā shēma tiek nodota atpakaļ Dnnn un tā var brīvi rīkoties ar citiem klientiem.Snnn un Dnnn var darboties kā pavedieni vai kā operētājsistēmas procesi. Papildus datu bāzu instancēm Dnnn darbojas arī koplietojamos serveros.

In a shared server architecture, clients connect to a Dispatcher Process (Dnnn), which creates a virtual circuit for each connection. When the client sends data to the server, the dispatcher receives the data into the virtual circuit and places the active circuit on the common queue to be picked up by an idle Shared Server process (Snnn). The Snnn then reads the data from the virtual circuit and performs the database work necessary to complete the request. When the Snnn must send data to the client, the Snnn writes the data back into the virtual circuit and the Dnnn sends the data to the client. After the Snnn completes the client request, it releases the virtual circuit back to the Dnnn and is free to handle other clients.Both Snnn and Dnnn can run as threads or as operating system processes. In addition to database instances, Dnnn also runs on shared servers.For information about how Dnnn and Snnn interact with the Large Pool, see the Large Pool slide.

19