Gjelder for:
Oracle-database – 12.1.0.2
Forfatter:
Mahesh Reddy M
Innledning:
Med Oracle-database 12c In-Memory kan én enkelt database nå effektivt støtte blandede arbeidsbelastninger og gi optimal ytelse for transaksjoner, samtidig som den støtter analyse og rapportering i sanntid. In-Memory gir både datatorg og datalagre mulighet til å levere mer adhoc-analyse, slik at sluttbrukere kan kjøre flere virksomhetsspørringer på like lang tid som det tar å kjøre bare én. Med disse funksjonene kan du lagre kolonner, tabeller, partisjoner og materialiserte visinger i et kolonneformat i minnet, i stedet for det vanlige radformatet. In-Memory-kolonnelageret (IM-kolonnelager) var den viktigste funksjonen i 12.1.0.2-oppdateringssettet.
Arkitektur for Oracle-database 12c In-Memory:
Vanligvis lagres data kun i et radformat, men en In-Memory-database lagrer data kun i kolonneformat. Derfor støtter Oracle-database 12c dobbel formatarkitektur.
- Når det blir bedt om data for lese-/skriveoperasjoner (datamanipuleringer), lastes dataene inn i det tradisjonelle radlageret (hurtigbuffer)
- Når det blir bedt om data for skrivebeskyttede operasjoner, fylles dataene ut i et nytt In-Memory-kolonnelager. Denne utfyllingen inkluderer selvfølgelig omforming fra radformat til kolonneformat.
- Når en transaksjon som inkluderer innsettinger, oppdateringer eller slettinger, blir igangsatt, vil de nye dataene vises umiddelbart og samtidig i både radlageret og In-Memory-kolonnelageret. Dette gjør at begge lagrene er konsekvente når det gjelder transaksjoner
In-Memory-kolonnelageret:
Database In-Memory bruker et In-Memory-kolonnelager, en ny komponent i System Global Area (SGA), som kalles In-Memory-området. Data i IM-kolonnelageret befinner seg ikke i det tradisjonelle radformatet, men bruker i stedet et nytt kolonneformat. IM-kolonnelageret erstatter ikke hurtigbufferen, men utfyller den. Dermed kan data nå lagres i minnet i både et radformat og i et kolonneformat
In-Memory-området er et statisk utvalg i SGA, og størrelsen på dette er kontrollert av initialiseringsparameteren INMEMORY_SIZE (standard 0). Gjeldende størrelse på In-Memory-området er synlig i V$SGA
IM-kolonnelageret er delt inn i to utvalg:
- 1 MB utvalg – lagrer de faktiske dataene i kolonneformat
- 64 k utvalg – lagrer metadata om objektene.
Vi kan se mengden tilgjengelig minne i hvert utvalg ved hjelp av spørringen nedenfor
SQL> select * from v$inmemory_area;
| POOL |
ALLOC_BYTES |
USED_BYTES |
POPULATE_STATUS |
CON_I |
| 1 MB POOL |
2.5767E+11 |
2.3569E+11 |
DONE |
1 |
| 64 KB POOL |
6.4408E+10 |
876347392 |
DONE |
1 |
| 1 MB POOL |
2.5767E+11 |
2.3569E+11 |
DONE |
Andre |
| 64 KB POOL |
6.4408E+10 |
876347392 |
DONE |
Andre |
| 1 MB POOL |
2.5767E+11 |
2.3569E+11 |
DONE |
3 |
| 64 KB POOL |
6.4408E+10 |
876347392 |
DONE |
3 |
Tabell 1: Tilgjengelig minne i hvert utvalg
Aktiver IM-kolonnelager:
INMEMORY_SIZE-parameteren er et statisk utvalg, så eventuelle endringer vil ikke tre i kraft før databaseforekomsten startes på nytt. Den blir heller ikke berørt eller kontrollert av automatisk minnehåndtering (AMM). Størrelsen på In-Memory-området må være minst 100 MB.
sql> ALTER SYSTEM SET SGA_TARGET=500G SCOPE=SPFILE;
sql> ALTER SYSTEM SET INMEMORY_SIZE=300G SCOPE=SPFILE;
sql>SHUTDOWN IMMEDIATE;
sql>STARTUP;
ORACLE-forekomsten er startet.
Totalt System Global Area 4,2950E+11 byte
Fast størrelse 7 677 400 byte
Variabel størrelse 2,0938E+10 byte
Databasebuffere 8,5899E+10 byte
Omgjøringsbuffere 529 190 912 byte
In-Memory-område 3,2212E+11 byte
Database montert.
Database åpnet.
Vi kan se In-Memory-innstillingene ved hjelp av spørringen nedenfor
SQL> SHOW PARAMETER INMEMORY
NAME TYPE VALUE
---------------------------------- ----------- -----
inmemory_clause_default string
inmemory_force string DEFAULT
inmemory_max_populate_servers integer 1
inmemory_query string ENABLE
inmemory_size biginteger 300G
inmemory_trickle_repopulate_servers_ integer 1
percent
optimizer_inmemory_aware boolean TRUE
Vi kan også angi inmemory_size-parameteren på CDB- og PDB-nivå. Hvis du stiller denne parameteren inn på PDB-nivå, trenger du ikke starte forekomsten eller PDB på nytt. Summen av alle PDB-verdiene er mindre enn eller lik CDB-verdien.
Vi kan aktivere og deaktivere In-Memory-alternativet på PDB-nivå, som vist nedenfor
Koble til PDB, og kjør deretter kommandoen nedenfor
Deaktiver:
Alter system set inmemory_size=0; eller
Alter system reset inmemory_size;
Aktiver:
Alter system set inmemory_size=20G;
In-Memory-prioritetsnivåer:
IM-kolonnelageret skal fylles ut med de mest ytelseskritiske dataene i databasen. Mindre ytelseskritiske data kan ligge på en flash eller disk. Hvis databasen din er liten nok, kan du fylle ut alle tabellene i IM-kolonnelageret. Database In-Memory legger til et nytt INMEMORY-attributt for tabeller og materialiserte visninger.
Vi kan aktivere INMEMORY-attributtet på
tabellområde, tabell, (del)partisjon og materialisert visning.
Hvis du aktiverer dette attributtet på tabellområdenivå, blir alle tabeller og materialiserte visninger i tabellområdet aktivert for IMCOLUMN-lager som standard.
alter tablespace quest INMEMORY;
Hvis du aktiverer dette attributtet på tabellnivå, må alle kolonner i tabellen fylles ut i IMCOLUMN-lageret. Det er imidlertid mulig å bare fylle ut delsett av kolonnene i IMCOLUMN-lageret.
Alter table quest_tab INMEMORY NO Inmemory (EMP);
På samme måte for partisjonert tabell
Alter table quest_tab INMEMORY MODIFY Partition quest_part_1 No Inmemory;
Bakgrunnsprosesser:
IMCO: IMCO-bakgrunnsprosessen starter utfylling (forhåndsutfylling) av aktiverte In‑Memory-objekter med LOW/MEDIUM/HIGH/CRITICAL (lav/middels/høy/kritisk) prioritet.
SMCO: SMCO starter slaveprosesser (Wnnn) dynamisk for å implementere disse oppgavene.
Wnnn: Wnnn-prosesser utfører oppgaver i minnet relatert til utfylling eller ny utfylling av In-Memory-aktiverte objekter.
Objekter fylles ut i kolonnelageret enten i en prioritert liste umiddelbart etter at databasen er åpnet, eller etter at de er skannet (spurt) for første gang. Utfyllingsrekkefølgen til objektene er kontrollert av nøkkelordet PRIORITY, som har fem nivåer. Standard PRIORITY er NONE, noe som betyr at et objekt bare fylles ut etter at det er skannet for første gang
Ulike prioritetsnivåer som kontrolleres av PRIORITY-delsetningen i INMEMORY-setningen
Prioritetsnivå Beskrivelse
CRITICAL (Kritisk) objektet fylles ut umiddelbart etter at databasen åpnes
HIGH (Høy) objektet fylles ut etter at alle kritiske objekter er fylt ut
MEDIUM (Middels høy) objektet fylles ut rett etter at alle objekter med kritisk eller høy prioritet er fylt ut
LOW (Lav) objektet fylles ut rett etter at alle objekter med kritisk, høy eller middels prioritet er fylt ut
NONE (Ingen) objekter fylles bare ut etter at de er skannet for første gang (standard)
Objekter som er mindre enn 64 KB, fylles ikke ut i minnet ettersom minne blir tilordnet i blokker på 1 MB, og vil sløse mye plass i IM-kolonnelageret.
Eks: alter table quest inmemory priority critical;
In-Memory-komprimeringsteknikker:
IM-kolonnelageret bruker spesielle komprimeringsformater som er optimalisert for tilgangshastighet, i stedet for lagringsreduksjon. Databasen øker hastigheten på følgende måter:
- Komprimeringsformatene gjør at databasen kan redusere mengden behandlet minne fra hver kolonne. SQL kjøres direkte på de komprimerte kolonnene.
- Databasen bruker SIMD-vektorinstruksjoner (array) for å behandle et array av kolonneverdier i én enkelt CPU-klokkesyklus. Databasen kan lagre mange verdier i en vektor, noe som maksimerer ytelsesfordelene med SIMD-vektorbehandling.
In-Memory-komprimering blir spesifisert med nøkkelordene MEMCOMPRESS, en delsetnings av INMEMORY-attributtet. Det er seks nivåer, og hvert nivå gir forskjellige komprimerings- og ytelsesnivåer.
Ingen Memcompress: data fylles ut til In-Memory uten komprimering.
Memcompress for DML: hovedsakelig for DML-ytelse og minimal komprimering.
Memcompress for lav spørring: optimalisert for ytelsen til spørringer (standard).
Memcompress for høy spørring: optimalisert for ytelsen til spørringer og for å spare plass
Memcompress for lav kapasitet: mer plassbesparende sammenlignet med høy og lav spørring
Memcompress for høy kapasitet: optimalisert for å spare plass og litt mindre ytelse.
Komprimeringsforhold kan variere fra 2–20 X, avhengig av hvilket komprimeringsalternativ som er valgt, datatypen og innholdet i tabellen.
Eks: alter table quest inmemory memcompress for query high;
In-Memory-kolonnelager på RAC:
I et klyngemiljø har hver node sitt eget kolonnelager. Hver node i klyngen bør opprettholde samme størrelse som IM-kolonnelageret. Alle objekter som er fylt ut i minnet, vil som standard bli distribuert på tvers av alle IM-kolonnelagrene i klyngen. Distribusjonen av objekter på tvers av IM-kolonnelagrene i en klynge blir kontrollert av to ekstra delsetninger i INMEMORY-attributtet: DISTRIBUTE og DUPLICATE (kun utviklede systemer).
Distribusjon:
Objektene som distribueres på tvers av klyngen, kontrolleres av distribusjonsdelsetningen. Du kan distribuere objektene på følgende måter
Distribuering etter radområde – distribuerer objektene til ulike noder etter rad
Distribuering etter partisjon – distribuerer partisjonene til noder i klyngen
Distribuering etter delpartisjon – distribuerer delpartisjonen til ulike noder.
Eks: alter table quest inmemory distribute by partition;
Her er det viktig å si at Oracle In-Memory RAC er
SN-arkitektur (shared-nothing) for spørringer, for eksempel hvis du oppretter en spørring mot In-Memory-dataobjekter (ta utgangspunkt i at objekter blir distribuert i to IM-kolonnelagre), og får kun tilgang til dataene i affinitetsnoden, dvs. deler ikke IMCU-ene (In-Memory-komprimeringsenheter) på tvers av forekomstene i klyngen.
Dermed kan du stille inn
graden av parallellisme (DOP) til AUTO. Koordinatoren for den parallelle spørringen identifiserer den andre forekomsten av IMCU-plassering. Hvis du ikke kan stille inn DOP på AUTO, vil ikke koordinatoren for den parallelle spørringen bruke de andre forekomstene av IMCU-er.
still inn graden av parallellisme til auto
alter system set parallel_degree_policy=AUTO scope=both sid='*';
Duplikat:
Objektene blir kopiert til alle forekomster for å gjøre dem mer tilgjengelige. Du kan bruke den dupliserte delsetningen for å spesifisere at In-Memory-tabellen er lagret i alle forekomster i klyngen. Dette alternativet fungerer ikke for systemer som ikke er profesjonelt kontrollerte.
Eks: alter table quest inmemory duplicate all;
oppgavetabellen er lagret i alle forekomster.
Overvåke In-Memory-objekter:
Oracle introduserer to nye V$-visninger for overvåking av In-Memory-objekter
v$IM_SEGMENTS eller v$IM_USER_SEGMENTS og v$IM_COLUMN_LEVEL.
Ved hjelp av disse visningene kan vi finne ut hvor mange objekter som er fylt ut i IMCOLUMN-lageret for øyeblikket.
EX:
angi linjestørrelse 256
angi sidestørrelse 999
velg segment_name,ROUND(SUM(BYTES)/1024/1024/1024,2) "DATA GB",
ROUND(SUM(INMEMORY_SIZE)/1024/1024/1024,2) "IN-MEM GB",
ROUND(SUM(BYTES-BYTES_NOT_POPULATED)*100/SUM(BYTES),2) "% IN_MEM",
ROUND(SUM(BYTES-BYTES_NOT_POPULATED)/SUM(INMEMORY_SIZE),2) "COMP RATIO"
fra V$IM_SEGMENTS
gruppe etter eier, segment_name
rekkefølge etter SUM(bytes) desc;
SEGMENT_NAME ORIG GB IN-MEM GB % IN_MEM COMP RATIO
H_LINEITEM 317.27 68.2 88.77 4.13
H_PARTSUPP 35.17 21.04 100 1.67
EX:
angi linjestørrelse 256
angi sidestørrelse 999
angi bekreftelse av
kolonneobjekt format a30
VELG owner||'.'||table_name OBJECT,
inmemory INMEMORY,inmemory_priority PRIORITY,
inmemory_distribute DISTRIBUTE,inmemory_compression COMPRESSION,
inmemory_duplicate DUPLICATE
FRA all_tables
der owner='QUEST'
REKKEFØLGE ETTER inmemory, owner||'.'||table_name;
OBJECT INMEMORY PRIORITY DISTRIBUTE COMPRESSION DUPLICATE
H_NATION ENABLED CRITICAL AUTO FOR QUERY HIGH NO DUPLICATE
H_REGION ENABLED CRITICAL AUTO FOR QUERY HIGH NO DUPLICATE
H_CUSTOMER
H_SUPPLIER
I eksemplet ovenfor vil du legge merke til at to av tabellene – Customer (Kunde) og Supplier (Leverandør) – ikke har en verdi for INMEMORY-kolonnen. INMEMORY-attributtet er et attributt på segmentnivå. Både Customer (Kunde) og Supplier (Leverandør) er partisjonerte tabeller, og er derfor logiske objekter. INMEMORY-attributtet for disse tabellene vil bli registrert ved partisjons- eller delpartisjonsnivået i *_TAB_ (SUB) PARTITIONS.
Tre ekstra kolonner – INMEMORY_PRIORITY, INMEMORY_DISTRIBUTE og INMEMORY_COMPRESSION – har også blitt lagt til i *_TABLES-visningene for å angi gjeldende In-Memory-attributter for hver tabell.