Повечето хора вероятно са запознати с новата функция на Oracle 12.1.0.2, опцията за база данни InMemory. Когато се използва тази опция на Oracle RAC, DBA може да посочи клаузата DUPLICATE, за да има обект да се дублира между хранилището на колони InMemory във всички случаи. Тази клауза е за проектирани системи на Oracle като Exadata. Въпреки това, в не-инженерни системи Oracle изглежда позволява тази клауза, но тя не работи, както може да се очаква. За да илюстрирате, следвайте този пример, който беше стартиран на база данни RAC с два възела на моя MacBook Pro с VirtualBox… определено не е проектирана система.
Първо се създава таблица и след това се променя за INMEMORY DUPLICATE.
SQL> създайте таблица db_objs 2 като изберете * От dba_objects;
Таблицата е създадена.
SQL> промяна на таблицата db_objs в паметта дубликат;
Таблицата е променена.
Не трябва ли задаването на тази клауза да доведе до грешка, тъй като това не е инженерна система?
Таблицата е проверена, за да покаже, че е посочен DUPLICATE.
SQL> изберете inmemory,inmemory_duplicate 2 от user_tables, където table_name='DB_OBJS';
INMEMORY INMEMORY_DUPL-------- -------------АКТИВИРАН ДУБЛИКАТ
Просто „изберете *“ от таблицата се издава на екземпляр 1. След това можем да проверим дали таблицата е InMemory.
SQL> изберете inst_id,owner,segment_name,populate_status,inmemory_duplicate 2 от gv$im_segments;
INST_ID OWNER SEGMENT_NA POPULATE_ INMEMORY_DUPL---------- ---------- ---------- --------- --- ---------- 1 SCOTT DB_OBJS ЗАВЪРШЕН ДУБЛИКАТ
Забележете, че резултатите по-горе показват, че сегментът е само в екземпляр 1. Същата таблица е заявена в екземпляр 2, но заявката GV$IM_SEGMENTS все още показва само екземпляр 1.
От пример 1:
SQL> изберете avg(object_id) от db_objs;
AVG(OBJECT_ID)-------------- 11095.2049
Изтекло:00:00:00.01
План за изпълнение----------------------------------------------------- -------------Хеш стойност на плана:1349857420
------------------------------------------------------- ----------------------------------------<пред>| Идентификатор | Операция | Име | Редове | Байтове | Цена (%CPU)| Време |
------------------------------------------------------- ----------------------------------------<пред>| 0 | ИЗБЕРЕТЕ ИЗЯВЛЕНИЕ | | 1 | 5 | 10 (0)| 00:00:01 | <пред>| 1 | СОРТИРАНЕ НА АГРЕГАТ | | 1 | 5 | | | <пред>| 2 | ПЪЛНА ПАМЕТ ДОСТЪП ДО ТАБЛИЦА | DB_OBJS | 21319 | 104K| 10 (0)| 00:00:01 |
------------------------------------------------------- ----------------------------------------
От пример 2:
SQL> изберете avg(object_id) от db_objs;
AVG(OBJECT_ID)-------------- 11095.2049
Изтекло:00:00:00.03
План за изпълнение----------------------------------------------------- -------------Хеш стойност на плана:1349857420
------------------------------------------------------- ----------------------------------------<пред>| Идентификатор | Операция | Име | Редове | Байтове | Цена (%CPU)| Време |
------------------------------------------------------- ----------------------------------------<пред>| 0 | ИЗБЕРЕТЕ ИЗЯВЛЕНИЕ | | 1 | 5 | 4 (0)| 00:00:01 | <пред>| 1 | СОРТИРАНЕ НА АГРЕГАТ | | 1 | 5 | | | <пред>| 2 | ПЪЛНА ПАМЕТ ДОСТЪП ДО ТАБЛИЦА | DB_OBJS | 21319 | 104K| 4 (0)| 00:00:01 |
------------------------------------------------------- ----------------------------------------
Така че от всеки от случаите, таблицата е била достъпна INMEMORY. Но можем да видим, че само екземпляр 1 има сегмента InMemory.
Всички знаци сочат, че клаузата DUPLICATE работи върху не-инженерна система, което знаем, че е грешка. DBA_TABLES изглежда показва, че DUPLICATE е в игра тук. Планът Explain осигурява съгласуваност. Но GV$IM_SEGMENTS не е съгласен и показва, че DUPLICATE не работи в тази система.
