De fleste kender nok til den nye Oracle 12.1.0.2-funktion, InMemory-databaseindstillingen. Når du bruger denne mulighed på Oracle RAC, kan DBA angive DUPLICATE-sætningen for at få et objekt til at blive duplikeret i InMemory-kolonnelageret i alle tilfælde. Denne klausul er for Oracles udviklede systemer som Exadata. Men i ikke-konstruerede systemer ser Oracle ud til at tillade denne klausul, men den virker ikke, som man kunne forvente. For at illustrere det, følg dette eksempel, som blev kørt på en to-node RAC-database på min MacBook Pro med VirtualBox... absolut ikke et udviklet system.
Først oprettes en tabel og ændres derefter til INMEMORY DUPLICATE.
SQL> create table db_objs 2 as select * From dba_objects;
Table created.
SQL> alter table db_objs inmemory duplicate;
Table altered.
Skulle indstillingen af denne klausul ikke give en fejl, da dette er et ikke-konstrueret system?
Tabellen er verificeret for at vise, at DUPLICATE er angivet.
SQL> select inmemory,inmemory_duplicate 2 from user_tables where table_name='DB_OBJS';
INMEMORY INMEMORY_DUPL -------- ------------- ENABLED DUPLICATE
Et simpelt "vælg *" fra tabellen udstedes på instans 1. Vi kan derefter bekræfte, at tabellen er InMemory.
SQL> select inst_id,owner,segment_name,populate_status,inmemory_duplicate 2 from gv$im_segments;
INST_ID OWNER SEGMENT_NA POPULATE_ INMEMORY_DUPL
---------- ---------- ---------- --------- -------------
1 SCOTT DB_OBJS COMPLETED DUPLICATE Bemærk, at resultaterne ovenfor viser, at segmentet kun er i instans 1. Den samme tabel er forespurgt i instans 2, men forespørgsel på GV$IM_SEGMENTS viser stadig kun instans 1.
Fra eksempel 1:
SQL> select avg(object_id) from db_objs;
AVG(OBJECT_ID) -------------- 11095.2049
Elapsed: 00:00:00.01
Execution Plan ---------------------------------------------------------- Plan hash value: 1349857420
---------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 5 | 10 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 5 | | |
| 2 | TABLE ACCESS INMEMORY FULL| DB_OBJS | 21319 | 104K| 10 (0)| 00:00:01 |
---------------------------------------------------------------------------------------
Fra eksempel 2:
SQL> select avg(object_id) from db_objs;
AVG(OBJECT_ID) -------------- 11095.2049
Elapsed: 00:00:00.03
Execution Plan ---------------------------------------------------------- Plan hash value: 1349857420
---------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 5 | 4 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 5 | | |
| 2 | TABLE ACCESS INMEMORY FULL| DB_OBJS | 21319 | 104K| 4 (0)| 00:00:01 |
---------------------------------------------------------------------------------------
Så fra begge forekomster blev tabellen tilgået INMEMORY. Men vi kan se, at kun instans 1 har segmentet InMemory.
Alle tegn peger på, at DUPLICATE-klausulen arbejder på et ikke-konstrueret system, som vi ved er en fejl. DBA_TABLES lader til at indikere, at DUPLICATE er i spil her. Forklarplanen giver overensstemmelse. Men GV$IM_SEGMENTS er uenig og viser, at DUPLICATE ikke virker i dette system.