Hvordan konfigurerer jeg Oracle-database 12c In-Memory-indstillingen

Gælder for: 
Oracle-database – 12.1.0.2

Forfatter:

Mahesh Reddy M

Indledning:

Med introduktionen af Oracle-database 12c In-Memory, kan en enkelt database nu effektivt understøtte blandede belastninger, ved at levere optimal ydeevne til transaktioner med samtidig understøttelse af analyse og rapportering i realtid. In-Memory gør det muligt for både datamarts og data warehouse at levere mere ad hoc-analyse, hvilket giver slutbrugere mulighed for at stille flere forretningsrelevante forespørgsler på samme tid, som det tager at køre bare én nu. Med disse funktioner kan du gemme kolonner, tabeller, partitioner og materialiserede visninger i hukommelsen i et kolonneformat i stedet for det typiske rækkeformat. In-Memory Column Store (IM-kolonnelager) var hovedfunktionen i 12.1.0.2-patchsættet.

Oracle Database 12c In-Memory-arkitektur

Normalt gemmes data kun i RÆKKE-format, hvorimod In-Memory kun gemmer data i kolonneformat. Oracle-database 12c understøtter således dobbeltformat-arkitektur.

1. Når der anmodes om data til læse/skrivehandlinger (datamanipulationer), indlæses de i det traditionelle rækkelager (buffer-cachelager)
2. Når der anmodes om data til skrivebeskyttede handlinger, fyldes de i et nyt In-Memory-kolonnelager. Denne udfyldning inkluderer naturligvis en transformering fra række- til kolonneformat.
3. Når en transaktion, der inkluderer indsættelser, opdateringer eller sletninger, bliver sendt, vil de nye data blive vist med det samme og i både rækkelageret og In-Memory-kolonnelageret samtidigt. Derfor er begge lagre transaktionskonsistente

In-Memory-kolonnelageret:

Database In-Memory bruger et In-Memory-kolonnelager, som er en ny komponent i SGA (System Global Area), der kaldes In-Memory-området. Data i IM-kolonnelageret er ikke placeret i det traditionelle rækkeformat, i stedet bruger det et nyt kolonneformat. IM-kolonnelageret erstatter ikke buffer-cachelageret, men fungerer som et supplement, så data nu kan gemmes i hukommelsen i både række- og kolonneformat

In-Memory-området er en statisk pool i SGA, hvis størrelse styres af initialiseringsparameteren INMEMORY_SIZE (default 0). Den aktuelle størrelse af In-Memory-området er synlig i V$SGA

IM-kolonnelager underopdelt i to puljer:

1. 1 MB pulje – Gemme de faktiske kolonneformaterede data
2. 64 k pulje--- Gemme metadataene for objekterne.

Vi kan se den mængde hukommelse, der er tilgængelig i hver pulje, ved hjælp af nedenstående forespørgsel

SQL> vælg * fra v$inmemory_area;
 

POOL	ALLOC_BYTES	USED_BYTES	POPULATE_STATUS	CON_I
1MB POOL	2.5767E+11	2.3569E+11	DONE	1
64KB POOL	6.4408E+10	876347392	DONE	1
1MB POOL	2.5767E+11	2.3569E+11	DONE	2
64KB POOL	6.4408E+10	876347392	DONE	2
1MB POOL	2.5767E+11	2.3569E+11	DONE	3
64KB POOL	6.4408E+10	876347392	DONE	3

Tabel 1: Tilgængelig hukommelse i hver pulje

Aktivér IM-kolonnelager:

Som en statisk pulje vil eventuelle ændringer af INMEMORY_SIZE-parameteren ikke træde i kraft, før databaseforekomsten genstartes. Det påvirkes eller kontrolleres heller ikke ved automatisk hukommelsesstyring (AMM). In-Memory-området skal have en minimumstørrelse på 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-forekomst er startet.

Samlet System Global Area 4.2950E+11 byte
Fast størrelse 7677400 byte
Variabel størrelse 2.0938 E+10 byte
Databasebuffere 8.5899E+10 byte
Annuller Fortryd-buffere 529190912 byte
In-Memory-område 3.2212 E+11 byte
Database tilsluttet.
Database åbnet.

Vi kan se In-Memory-indstillingerne ved hjælp af nedenstående forespørgsel

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å indstille inmemory_size-parameteren på CDB-og PDB-niveau. Hvis du indstiller denne parameter på PDB-niveau, behøver du ikke at genstarte forekomsten eller PDB. Summen af alle PDB-værdier er mindre end eller samme værdi som CDB-værdien.

Vi kan aktivere og deaktivere In-Memory på PDB-niveau som vist nedenfor

Opret forbindelse til PDB, og udfør derefter følgende kommando

Deaktiver:

Alter system set inmemory_size=0; eller

Alter system reset inmemory_size;

Aktiver:

Alter system set inmemory_size=20G;

Prioritetsniveauer for In-Memory:

IM-kolonnelageret skal udfyldes med de mest ydelseskritiske data i databasen. Mindre ydelseskritiske data kan være placeret på billigere flash eller disk. Du kan selvfølgelig, hvis din database er lille nok, fylde alle dine tabeller i IM-kolonnelageret. Database In-Memory tilføjer en ny INMEMORY-egenskab til tabeller og materialiserede visninger.

Vi kan aktivere INMEMORY-egenskaben på

Tabelplads, tabel, (under)partition og materialiseret visning.

Hvis du aktiverer denne egenskab på tabelplads-niveau, vil alle tabeller og materialiserede visninger i tabelplads blive aktiveret til IMKOLONNE-lager som standard.

alter tablespace quest INMEMORY;

hvis du aktiverer denne egenskab på tabelniveau, betyder det, at alle kolonnerne i tabellen skal udfyldes i IM-KOLONNE-lageret. Det er dog muligt kun at fylde delmængder af kolonner ind i IMKOLONNE-lageret.

Alter table quest_tab INMEMORY NO Inmemory (EMP);

På samme måde for partitioneret tabel

Alter table quest_tab INMEMORY MODIFY Partition  quest_part_1 No Inmemory;

Baggrundsprocesser:

IMCO: IMCO-baggrundsprocessen starter udfyldningen (for-udfyldningen) af in memory-aktiverede objekter med prioritetenLAV/MELLEM/HØJ/KRITISK.

SMCO: SMCO splitter slaveprocesser (Wnnn) dynamisk for at implementere disse opgaver.

Wnnn: Wnnn-processer udfører in-memory-udfyldning, og in-memory genudfylder opgaver til udfyldelse eller genudfyldelse af in-memory-aktiverede objekter.

Objekter udfyldes i IM-kolonnelageret enten i en prioriteret liste, umiddelbart efter, at databasen er åbnet, eller når de er blevet scannet (forespurgt) for første gang. Den rækkefølge, som objekter udfyldes i, styres af nøgleordet PRIORITET, som har fem niveauer. Standardprioriteten er INGEN, hvilket betyder, at et objekt kun udfyldes, når det scannes for første gang.

Forskellige prioritetsniveauer, der styres af underreglen PRIORITET under INMEMORY-reglen
Prioritetsniveau Beskrivelse

KRITISK Objektet udfyldes umiddelbart efter, at databasen er åbnet

HØJ Objektet udfyldes efter, at alle KRITISKE objekter er blevet udfyldt                                             

MELLEM Objektet udfyldes efter, at alle KRITISKE og HØJE objekter er blevet udfyldt

LAV Objektet udfyldes efter, at alle KRITISKE, HØJE og MELLEM objekter er blevet udfyldt.

INGEN Objekter udfyldes kun, når de er blevet scannet for første gang (standard)

 Objekter, der er mindre end 64 KB, udfyldes ikke i hukommelsen, da de vil spilde store mængder plads inde i IM-kolonne ageret, da hukommelsen allokeres i dele af 1 MB.

Eks.: alter table quest inmemory priority critical;

In-Memory komprimeringsteknikker:

IM-kolonnelageret bruger specielle komprimeringsformater, der er optimeret til adgangshastighed frem for reduktion af storage. Databasen øger hastigheden på følgende måder:

• Komprimeringsformaterne gør det muligt for databasen at reducere den mængde hukommelse, der behandles for hver kolonne. SQL udføres direkte på de komprimerede kolonner.
• Databasen bruger SIMD-vektor (array)-instruktioner til at behandle en række kolonneværdier i en enkelt CPU-klokcyklus. Databasen kan lagre mange værdier i en vektor, hvilket maksimerer ydelsesfordelene ved SIMD-vektorbehandling.

In-memory-komprimering er specificeret ved brug af nøgleordet MEMCOMPRESS, en underregel for INMEMORY-egenskaben. Der er seks niveauer, som hver giver forskellige komprimeringsniveauer og ydeevner.

Ingen Memcompress: Data udfyldes til In-Memory uden komprimering.

Memcompress til DML: Den er primært til DML-ydelse og minimal komprimering.

Memcompress til Lav forespørgsel: Optimeret til forespørgselsydelse (standard).

Memcompress til Høj forespørgsel: Optimeret forespørgselsydelse og pladsbesparende

Memcompress til Lav kapacitet: Mere pladsbesparende sammenlignet med Høj og Lav forespørgsel

Memcompress til Høj kapacitet: Optimeret til pladsbesparelse og lidt mindre ydeevne.

Komprimeringsforhold kan variere fra 2X – 20X, alt afhængigt af den valgte komprimeringsfunktion, datatypen og indholdet af tabellen.

Eks.: alter table quest inmemory memcompress for query high;

In-Memory-kolonnelager på RAC:

I et klyngemiljø har hver node sit eget kolonnelager. Hver node i klyngen bør have samme størrelse som IM-kolonnelageret. Som standard vil alle objekter, der udfyldes i hukommelsen, blive fordelt på tværs af alle IM-kolonnelagre i klyngen. Fordelingen af objekter på tværs af IM-kolonnelagrene i en klynge styres af to yderligere underregler for INMEMORY-egenskaben: FORDEL OG KOPIÉR (kun udviklede systemer).

Fordel:

Objekterne, der er fordelt på tværs af klyngen, styres af Fordel-underreglen. Du kan fordele objekterne på følgende måder

Fordel efter rækkeordnet udvalg – Fordel objekterne efter rækkeordnet til forskellige noder

Fordele efter partition – fordele partitionerne til noder inden for klyngen

Fordele efter underpartition – fordele underpartitionen til forskellige noder.

Eks.: alter table quest inmemory distribute by partition;

Her er det vigtigt at sige, at Oracle In-Memory-RAC er shared-nothing-arkitektur for forespørgsler. Dvs. hvis du fremsætter en forespørgsel om in-memory-dataobjekter (antag, at objekterne er fordelt i to IM-kolonnelagre), kan du kun få adgang til dataene i den tilhørende node, hvilket betyder, at du skal undgå at dele IMCUs (ikke-hukommelses komprimeringsenheder) på tværs af forekomsterne i klyngen.

Så du kan indstille graden af parallelitet (DOP) til Auto. Den parallelle forespørgselskoordinator identificerer de øvrige forekomster af IMCUs placering. Hvis du ikke kan indstille DOP til AUTO, vil den parallelle forespørgselskoordinator ikke bruge de andre IMCU-forekomster.

indstil graden af parallel til Auto

alter system set parallel_degree_policy=AUTO scope=both sid='*';

Kopier:

For at øge tilgængeligheden kopieres objekterne til alle forekomster. Du kan bruge kopiér underregel til at angive, at inmemory-tabellen lagres i alle forekomster i klyngen. Denne indstilling vil ikke fungere med ikke-udviklede systemer.

Eks.: alter table quest inmemory duplicate all;

       quest-tabellen gemmes ved alle forekomster.

Overvågning af In-memory-objekter:

Oracle introducerer to nye V$views til overvågning af inmemory-objekter

v$IM_SEGMENTS eller  v$IM_USER_SEGMENTS og v$IM_COLUMN_LEVEL.

Ved at bruge disse visninger, kan vi finde ud af, hvor mange objekter der er udfyldt i IMKOLONNE-lageret.

EKS.:

set linesize 256

set pagesize 999

select 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

gruppér efter ejer, segment_name

sorter efter 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

EKS.:

set linesize 256

set pagesize 999

indstil verificering fra

col OBJECT format a30

SELECT owner||'.'||table_name OBJECT,

inmemory INMEMORY,inmemory_priority PRIORITY,

inmemory_distribute DISTRIBUTE,inmemory_compression COMPRESSION,

inmemory_duplicate DUPLICATE

FROM all_tables

where owner='QUEST'

ORDER BY 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 bemærke, at to af tabellerne – Kunde og Leverandør – ikke har en værdi for INMEMORY-kolonnen. INMEMORY-egenskaben er en egenskab på segmentniveau. Både Kunde og Leverandør er partitionerede tabeller og er derfor logiske objekter. INMEMORY-egenskaben for disse tabeller vil blive registreret på partitions- eller underpartitionsniveau i _TAB_(UNDER)PARTITIONER.

Tre ekstra kolonner – INMEMORY_PRIORITET, INMEMORY_FORDEL og INMEMORY_KOMPRIMERING – er også blevet føjet til * _TABEL-visningerne for at angive de aktuelle inmemory-egenskaber for hver tabel.