Większość ludzi prawdopodobnie zdaje sobie sprawę z nowej funkcji Oracle 12.1.0.2 — opcji bazy danych InMemory. Korzystając z tej opcji w Oracle RAC, administrator DBA może określić klauzulę DUPLICATE, aby obiekt był duplikowany w magazynie kolumn InMemory we wszystkich instancjach. Ta klauzula dotyczy systemów inżynieryjnych Oracle, takich jak Exadata. Jednak w systemach innych niż inżynierskie Oracle wydaje się dopuszczać tę klauzulę, ale nie działa ona tak, jak można by się spodziewać. Aby to zilustrować, wykonaj ten przykład, który został uruchomiony na dwuwęzłowej bazie danych RAC na moim MacBooku Pro z VirtualBox… zdecydowanie nie jest to system inżynieryjny.
Najpierw tworzona jest tabela, a następnie zmieniana na DUPLIKAT PAMIĘCI INFORMACJI.
SQL> create table db_objs 2 as select * From dba_objects;
Table created.
SQL> alter table db_objs inmemory duplicate;
Table altered.
Czy ustawienie tej klauzuli nie powinno powodować błędu, ponieważ nie jest to system inżynieryjny?
Tabela jest weryfikowana, aby pokazać, że określono DUPLICATE.
SQL> select inmemory,inmemory_duplicate 2 from user_tables where table_name='DB_OBJS';
INMEMORY INMEMORY_DUPL -------- ------------- ENABLED DUPLICATE
Proste „wybierz *” z tabeli jest wystawiane na instancji 1. Możemy wtedy zweryfikować, czy tabela jest w pamięci 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 Zauważ, że powyższe wyniki pokazują, że segment znajduje się tylko w instancji 1. Ta sama tabela jest wysyłana w instancję 2, ale zapytanie GV$IM_SEGMENTS nadal pokazuje tylko instancję 1.
Z instancji 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 |
---------------------------------------------------------------------------------------
Z przykładu 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 |
---------------------------------------------------------------------------------------
Tak więc z każdej instancji uzyskano dostęp do tabeli INMEMORY. Ale widzimy, że tylko instancja 1 ma segment InMemory.
Wszystkie znaki wskazują, że klauzula DUPLICATE działa w systemie innym niż inżynieryjny, o którym wiemy, że jest błędem. DBA_TABLES wydaje się wskazywać, że w grę wchodzi DUPLICATE. Plan wyjaśniania zapewnia zbieżność. Ale GV$IM_SEGMENTS nie zgadza się i pokazuje, że DUPLICATE nie działa w tym systemie.
