Oracle 12c: опция in-Memory Column Store и технологии кэширования

Эффект от использования этой опции высок. Однако, функций в приложении может быть немного, а подходящих для этой опции функций ещё меньше.

Кэширование в Oracle Database 12с

In-Memory Column Store (IMCS)

Эта технология появилась в 12c версии базы данных Oracle.

Преимущества технологии:

• может применяться и с OLTP-системами и в хранилищах данных
• существенное ускорение выполнения произвольных запросов на больших таблицах с любым набором столбцов при отсутствии индексов
• более быстрое выполнение DML-команд за счет отсутствия не нужных для этой опции индексов
• полная прозрачность для приложений, в том числе Oracle e-Business Suite, Siebel
• простота применения, конфигурирования и оценки результата использования
• полная поддержка в RAC и при параллельной обработке без необходимости дублирования содержимого пула в разных экземплярах RAC
• полная поддержка в CDB/PDB
• отсутствие необходимости настройки плана выполнения SQL команд, в случае если все объекты, используемые командой, обслуживаются новой опцией
• нет необходимости перестраивать объекты или менять процедуры резервирования базы данных.

Поддерживаемые объекты:

• heap-organized таблицы, наборы их столбцов, секции и подсекции;
• материализованные представления.

Эта опция не обслуживает:

• столбцы LONG, LONG ROW, out-of-line LOB
• объекты небольшого размера (до 64 Кб)
• объекты схемы SYS, располагающиеся в табличных пространствах SYSTEM или SYSAUX
• физические резервные базы данных в режиме Active Data Guard.

Скорость выборки, соединения, фильтрации данных на больших объемах может увеличиться в сотни раз. Использование опции не накладывает ограничения на внесение изменений в таблицы. Скорость операций DML может увеличиться в несколько раз за счет удаления аналитических индексов, которые становятся не нужны для операций выборки, если таблица обслуживается этой опцией.

Тестирование производительности

В статье Query Optimization in Oracle 12c Database In-Memory приведены оценки эффективности использования IM на реально используемых данных объемом 1Тб, размещенных в IM-пуле размером 156Гб с уровнем компрессии 1:7 с рабочей нагрузкой из 32 аналитических запросов на одном экземпляре и 4 экземплярах RAC. При чтении данных с диска среднее время выполнения составило 12037 на одном экземпляре, 12284 на 4-экземплярах с распараллеливанием. При чтении данных из памяти 12011 и 12278 соответственно. При использовании IM-пула 4233 и 4230 соответственно. Без использования IM-опции время выполнения запросов дольше примерно в 3 раза.

На искусственных тестах с выборкой 20 столбцов из одной таблицы SELECT '20 столбцов' FROM tab WHERE столбец < значение:

На соединении таблицы самой с собой SELECT '5 столбцов' FROM tab a, tab b WHERE a.col1 < значение AND a.col50=b.col51:

Механизм работы

Опция не влияет на способ хранения данных в табличных пространствах. Данные хранятся в блоках базы данных в обычном виде. При внесении изменений используется кэш буферов и прямые вставки. Администратор баз данных конфигурирует пул в SGA, в который помещаются данные, которые должна обслуживать новая опция и выборка данных идет из этого пула. Изменения в данные вносятся в блоки таблиц, которые располагаются в кэше буферов. Синхронизация изменений в блоках с данными в новом пуле выполняется автоматически. Новая опция может обслуживать часть таблиц, при этом одна команда SQL может работать с таблицами, использующими новую опцию и не использующими её без деградации производительности.

После выделения нового пула параметром инициализации INMEMORY_SIZE можно указать какие таблицы, столбцы, секции таблиц будут обслуживаться новой опцией. Недостаток этого пула в том, что он не поддерживается опцией ASMM: его размер не подстраивается автоматически и администратор базы данных должен сам указывать его размер.

Новый пул не использует алгоритм LRU при работе с объектами и если в пуле недостаточно места, то объект может частично поместиться в пуле, поэтому администратору нужно следить за свободным местом в пуле. Если запрос не может получить все данные объекта из пула, оставшаяся часть будет выбираться из кэша буферов, флэш-кэша или из файлов табличных пространств. Запрос при этом будет выполнен без ошибки, но время выполнения запроса может увеличиться. Если нужно изменить размер пула, то для инициализации пула придётся перегрузить экземпляр. Новая опция работает в конфигурации CDB/PDB и можно указать объем памяти, который будет использовать объекты для каждой PDB.

Объекты для обслуживания новой опцией могут располагать в пуле только часть столбцов, при этом могут использоваться разные алгоритмы сжатия данных при размещении в пуле, позволяющие достичь компрессии в 2-10 раз. Объем места, занимаемого объектом можно оценить процедурой DBMS_COMPRESSION.GET_COMPRESSION_RATIO. Также можно получить данные по объему памяти в пуле, занимаемому объектами через представление V$IM_SEGMENTS.

Администратор базы данных может решить на основе тех запросов, которые существуют в базе данных какие объекты или их части — столбцы, секции таблиц ввести под обслуживание новой опцией, а какие не вводить. Если большинство запросов к таблицам идут в OLTP-стиле: выборка одной или нескольких строк, то более эффективным является использование индексов и выборка данных из кэша буферов. Если запросы идут в стиле DSS: в выборке используется большое количество строк, соединений с другими таблицами, то использование новой опции будет более эффективным.

Для введение объекта под обслуживание новой опцией можно использовать команду ALTER TABLE tab INMEMORY. При первом обращении к таблице (атрибут PRIORITY=NONE) или при запуске экземпляра базы данных (атрибут PRIORITY=LOW,MEDIUM,HIGH,CRITICAL), из блоков таблицы выбираются строки и размещаются в IM-пуле. В пуле выделяются области памяти, называемые In-Memory Colomn Units (IMCU) экстентами размером 1Мб. Количество IMCU можно получить запросом:

SELECT COUNT(IMCU_ADDR) FROM V$IM_HEADER WHERE IS_HEAD_PIECE=1;

Сколько строк размещено в каждом IMCU можно увидеть в представлении V$IM_HEADER. Распределение памяти IM-пула можно увидеть в представлении V$INMEMORY_AREA. Для одного объекта может быть выделено несколько IMCU, они образуют в пуле in-memory column store segment. Данные из каждого столбца таблицы хранятся слитно. Размер IMCU минимального размера 1Мб, что больше размера блока базы данных (обычно 8-32Кб) и сканирование IMCU более быстро, чем выборка данных из блоков в кэше буферов. Так как один IMCU не может хранить данные из нескольких объектов, то имеет смысл использовать новую опцию с объектами, размер которых не сильно меньше 1Мб. Размер IMCU и количество строк, которое они хранят, выбирается динамически на основе размера таблицы, её структуры и объема свободной памяти в пуле. Данные в IMCU могут помещаться в сжатом виде, который задаётся на уровне объекта, секции, столбца.

В IM-пуле также выделяется память под хранение Transactional Snapshot Metadata Units (SMU) с экстентами размером 64Кб. SMU хранят метаданные об IMCU.

Выделением IMCU занимается фоновый процесс-координатор IMCO, работающий циклами в 2 минуты. Наполнением IMCU данными занимаются фоновые процессы SMCO и Wnnn. Если данные в объектах меняются, то изменения отражаются в SMU на основе тех изменений, которые были внесены в блоки объекта. Записи в IMCU, соответствующие изменившимся строкам помечаются как устаревшие. Процессы IMCO/SMCO/Wnnn выполняют обновление IMCU на основе журнала изменений. Обновление IMCU происходит, если:

• имеется большое количество изменений строк, относящихся к IMCU
• размер журнала изменений вырос
• получено уведомление от других экземпляров RAC.

Если в пуле недостаточно свободного места, то в пуле размещается только часть объекта. При обращении к такому объекту часть данных выбирается из пула, часть из кэша буферов, флэш-кэша или из файлов данных.

Информацию о статусе загрузки данных объекта в IM-пул объекта (STARTED, COMPLETED) можно узнать так:

SELECT SEGMENT_NAME, POPULATE_STATUS, INMEMORY_SIZE, BYTES_NOT_POPULATED FROM V$IM_SEGMENTS;

Работа DML операций

Если на объекте проводится операция DML, то записи в IMCU, затронутые DML-операцией, помечаются как stale в SMU. Данные об изменениях в объекте сохраняются в SMU-части IM-пула и называется журналом изменений. При последующих запросах, которые должны видеть изменившиеся данные, неизменившиеся данные считываются из IMCU, а при выборке stale записей используется журнал изменений или блоки сегмента объекта, в том числе находящиеся в кэше буферов. IM-пул обеспечивает режим целостности по чтению на основе SCN.

Оценить количество stale-записей можно так:

SELECT OBJD, (SUM(INVALID_ROWS)/SUM(TOTAL_ROWS))*100 PCT_INVALID FROM V$IM_SMU_HEAD GROUP BY OBJD ORDER BY 2 DESC;

Stale-записи обрабатывается фоновыми процессами Wnnn. Такая обработка называется trickle repopulation. Процент от общего количества процессов Wnnn, которые будут использоваться только для обработки stale-записей, а не только для формирования IMCU в режимах population и repopulation, устанавливается параметром инициализации INMEMORY_TRICKLE_REPOPULATE_SERVERS_PERCENT. Диапазон значений от 0 до 50, то есть не больше половины всех процессов Wnnn. Общее количество процессов Wnnn устанавливается параметром инициализации INMEMORY_MAX_POPULATE_SERVERS.

Обработка stale-записей после обновлений строк может быть довольно тяжелой операцией, поэтому рекомендуется располагать данные в таблицах, например, путем выбора опций секционирования так, чтобы изменения вносились не по всем блокам таблицы. При большом объеме изменений также рекомендуется выбирать подходящий тип сжатия: MEMCOMPRESS FOR DML. Если объем обновления значений строк в таблице командами UPDATE большой, то, возможно, стоит отказаться от обслуживания столбцов или настраивать количество фоновых процессов Wnnn, выделенных для trickle repopulation параметром инициализации INMEMORY_TRICKLE_REPOPULATE_SERVERS_PERCENT.

Также поддерживаются операции прямой загрузки в таблицы. Прямые вставки в таблицы формируют блоки в сегменте таблицы. Журнал изменений IM-пула не заполняется. После прямой вставки объем данных, который отсутствует в IM-пуле отражается в столбце BYTES_NOT_POPULATED представления V$IM_SEGMENTS. Заполнение IMCU новыми данными будет выполнено процессами Wnnn в режиме, называемом repopulation, по правилам PRIORITY — либо в порядке приоритета, либо после первого обращения к данным, если приоритет не установлен.

DDL операции над объектами, использующими пул работают без ограничений. Команды ALTER TABLE MOVE, SPLIT / MERGE PARTITION приводят к удалению IMCU, затрагиваемых командой. Они начнут создаваться и заполняться в зависимости от свойства PRIORITY: либо при обращении к данным, либо в следующем цикле IMCO в соответствии с приоритетом. Удаление или добавление столбцов в таблице приведет к обновлению (repopulation) соответствующих IMCU.

Параметры инициализации

SQL> show parameter inmem
NAME                                 TYPE        VALUE
------------------------------------ ----------- -------
inmemory_clause_default              string
inmemory_force                       string      DEFAULT
inmemory_max_populate_servers        integer     2
inmemory_query                       string      ENABLE
inmemory_size                        big integer 304M
inmemory_trickle_repopulate_servers_ integer     1
percent
optimizer_inmemory_aware             boolean     TRUE

Если нужно, чтобы вновь создаваемые таблицы по умолчанию обслуживались новой опцией с желаемыми параметрами, это можно сделать динамическим параметром инициализации:

ALTER SYSTEM SET INMEMORY_CLAUSE_DEFAULT = "INMEMORY MEMCOMPRESS FOR QUERY LOW PRIORITY CRITICAL NO DUPLICATE";

Также можно указать опции по умолчанию, которые будут устанавливаться для вновь создаваемых таблиц, если при их создании явно указать опцию INMEMORY:

ALTER SYSTEM SET INMEMORY_CLAUSE_DEFAULT = "MEMCOMPRESS FOR QUERY LOW";

Также можно установить это значение на уровне сессии командой ALTER SESSION.

Также можно установить опции на уровне табличного пространства, которые будут использоваться по умолчанию для объектов, создаваемых в этом табличном пространстве:

ALTER TABLESPACE tbs INMEMORY MEMCOMPRESS FOR CAPACITY HIGH PRIORITY LOW;

Динамическим параметром inmemory_force можно отключить опцию. У этого параметра два значения: DEFAULT и OFF. Установка значения в OFF очищает IM-пул.

Если нужно отключить только использование опции для выполнения запросов без очистки IM-пула и изменения работы фоновых процессов, то это можно сделать на уровне сессии или системы (всех экземпляров) динамическим параметром inmemory_query. У этого параметра инициализации два значения ENABLE и DISABLE.

Параметр inmemory_max_populate_servers по умолчанию устанавливается на основе количества процессоров или размера PGA_AGGEGATE_TARGET.

Также имеется большое количество параметров, контролирующих работу IM. Посмотреть их можно так:

set linesize 1000
set pagesize 50000
SELECT KSPPINM, KSPPDESC FROM x$ksppi WHERE KSPPINM LIKE '%inmem%';

Оценка эффективности применения с помощью in-Memory Advisor

Для оценки того, какие объекты имеет смысл ввести под обслуживание новой опцией, можно использовать in-Memory Advisor, который входит в лицензию на Database Tuning Pack. Скачать набор скриптов для установки этого адвайзера можно по ссылке со страницы документа технической поддержки 1965343.1 Адвайзер может быть установлен на базы данных начиная с версии 11.2.0.3, что может помочь оценить возможность использования IM-пула перед миграцией на версию 12c.

Адвайзер захватит рабочую нагрузку, которая есть на базе данных, выделит из неё аналитические запросы из общей активности на базе данных на основе SQL plan cardinality, использования parallel query, повторяемости запросов и других характеристик. Также можно использовать SQL Tuning Sets, данные по рабочей нагрузке из AWR (в AWR сохраняются не все аналитические запросы, а только топовые).

Адвайзер выдаёт отчёт в формате HTML с рекомендуемым размером IM-пула, списком таблиц, которые можно разместить в IM-пуле, параметры компрессии для них и оценку прироста производительности. Также генерируется sql-скрипт c набором команд ALTER TABLE ... INMEMORY ..., которым можно применить рекомендации в 12с.

Пример отчёта. Красным прямоугольником выделено суммарное время выполнения команд, которые были проанализированы, синим время запросов, которые адвайзер отнёс к аналитическим и по которым сформировал результат анализа:

После реализации рекомендаций можно будет использовать SQL Performance Analyzer для практической проверки рекомендаций.

Ввод объектов под обслуживание IMCS

В командах создания объекта CREATE или изменения ALTER можно указать опцию INMEMORY или NO INMEMORY. Опционально можно задать следующие опции:

1. Приоритет, в соответствии с которым, данные объекта помещаются в IM-пул.
   1. PRIORITY NONE: означает, что данные попадут в пул после первого обращения к объекту. Серверный процесс не занимается заполнением IM-пула. Данные в пул помещают фоновые процессы IMCO/SMCO/Wnnn, и на это может потребоваться время.

   При этом план выполнения запроса уже будет использовать IM-пул (TABLE ACCESS INMEMORY FULL), даже если он ещё не заполнен. Запрос будет выбирать данные с диска или кэша буферов, а из IM-пула только ту часть, которая успела в него загрузиться. Эффективность выполнения такого запроса может быть низкой, пока начальная загрузка объекта в IM-пул не завершится. Если бы объект не обслуживался IM-пулом (NO INMEMORY), то план выполнения запроса мог использовать индексы (если они есть) и, возможно, выполнялся бы более эффективно, чем полное сканирование таблицы когда её большая часть ещё не загружена в IM-пул.

   Ещё нужно принять во внимание следующее: при использовании PRIORITY NONE и использовании менеджера ресурсов базы данных загрузка данных в IM-пул выполняется из под группы потребителей ресурсов того пользователя, который первым обратился к объекту и инициировал начало загрузки объекта в IM-пул. Загрузка данных из этого объекта в IM-пул и выполнение запросов пользователя могут выполняться медленнее, если сработают ограничения менеджера ресурсов, наложенные на группу пользователя.

   Для других значений PRIORITY загрузка данных в IM-пул выполняется из-под группы потребителей ресурсов ORA$AUTOTASK.

   Можно поменять группу потребителей ресурсов для операций заполнения IM-пула:

   exec DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(
   attribute => 'ORACLE_FUNCTION', value => 'INMEMORY', consumer_group => 'BATCH_GROUP');

   2. PRIORITY CRITICAL/HIGH/MEDIUM/LOW: задают очередность, в соответствии с которой, данные из объектов будут подгружаться в пул фоновыми процессами после запуска экземпляра или после ввода объекта под обслуживание опцией. Обращение к объекту для запуска загрузки не требуется.
2. Тип сжатия данных в IM-пуле для IMCU этого объекта. Без сжатия NO MEMCOMPRESS. Со сжатием MEMCOMPRESS FOR и один из типов:
   1. DML — минимальное сжатие, для таблиц, в которых часто меняются строки
   2. QUERY LOW (значение по умолчанию) — для максимизации скорости выборки.
   3. QUERY HIGH — для большей экономии памяти. Режимы QUERY используют техники dictionary-encoding, run-length encoding, bit packing.
   4. CAPACITY LOW — после применения техник из QUERY данные сжимаются алгоритмом OZIP, который обеспечивает быструю декомпрессию данных. Однако, для обработки условий, заданных во фразе WHERE запроса данные должны быть разжаты, что требует большого объема вычислений.
   5. CAPACITY HIGH — для сжатия используется алгоритм, который разжимает данные намного медленнее OZIP.

   Тип сжатия можно выбирать разным для разных столбцов или секций. Уровень сжатия зависит от данных и варьируется от 2 до 20 раз.

   Уровень компрессии можно оценить заранее на основе анализа части данных объекта процедурой DBMS_COMPRESSION.GET_COMPRESSION_RATIO.

   Уровень компрессии для объектов в IM-пуле можно узнать так:

   SELECT SEGMENT_NAME, BYTES, INMEMORY_SIZE, INMEMORY_COMPRESSION, BYTES/INMEMORY_SIZE COMP_RATIO FROM V$IM_SEGMENTS;

   Тип сжатия, установленный на уровне столбца можно узнать из столбца INMEMORY_COMPRESSION представления V$IM_COLUMN_LEVEL.

3. Для RAC можно указать опции:
1. дублирования IMCU на экземплярах RAC. Эта опция работает только на программно-аппаратных комплексах Oracle Exadata, Oracle SuperCluster и т.п. и игнорируется на остальных системах.
• NO DUPLICATE: IMCU не дублируются на экземплярах RAC
• DUPLICATE: IMCU зеркалируются на один из экземпляров. В случае падения/остановки одного из экземпляров RAC это поможет уменьшить влияние падения/остановки экземпляра на работоспособность новой опции.

• DUPLICATE ALL: IMCU дублируются на всех экземплярах RAC. Это полезно для dimention-таблиц относительно небольшого размера. Дублирование fact-таблиц большого размера приведет к неразумному использованию памяти.

2. DISTRIBUTE

• AUTO (значение по умолчанию): данные объекта распределяются между IM-пулами экземпляров в зависимости от свойств объекта
• BY PARTITION или BY SUBPARTITION
• BY ROWID RANGE

Данные распределяются между экземплярами RAC, это позволяет экономить память. Параллельные запросы используют данные из всех экземпляров путем запуска параллельных процессов на этих экземплярах. Нужно использовать автоматическое определение уровня параллелизма (AUTO DOP), так как при ручном задании уровня параллелизма, параллельные процессы могут запуститься только на части экземпляров и IM-пулы на оставшихся экземплярах не будут использоваться.

Значения параметров, установленных на уровне таблиц, можно узнать так:

SELECT table_name, inmemory_compression, inmemory_priority, inmemory_distribute, inmemory_duplicate FROM dba_tables;

Использование IMCS с частью объекта

Можно использовать IM-пул для ханения данных по части столбцов. Для этого нужно на уровне таблицы указать опцию INMEMORY и исключить часть столбцов. Пример:

CREATE TABLE tab1 (c1 NUMBER, c2 CHAR(2), c3 DATE) INMEMORY NO INMEMORY (c1);

Можно включить или исключить столбцы, а также изменить свойства INMEMORY отдельно для каждого столбца:

ALTER TABLE tab1 NO INMEMORY (c2);
ALTER TABLE tab1 INMEMORY MEMCOMPRESS FOR DML (c3);
ALTER TABLE tab1 INMEMORY MEMCOMPRESS FOR QUERY HIGH (c2);

Изменение типа компрессии не приводит к пересозданию существующих IMCU и действует только для создаваемых вновь и repopulated IMCU.

Аналогично для секций секционированной таблицы:

CREATE TABLE countries_part ... PARTITION BY LIST .. 
      ( PARTITION p1 .. INMEMORY PRIORITY HIGH,
        PARTITION p2 .. INMEMORY MEMCOMPRESS FOR CAPACITY LOW);

Аналогично для материализованных представлений:

ALTER MATERIALIZED VIEW mv INMEMORY;

После того, как объект введён под обслуживание опции можно удалить аналитические индексы, то есть те, которые не используются декларативными ограничениями целостности. При доступе к объектам в IM-пуле индексы не используются. Перед удалением индексов можно пометить их INVISIBLE, убедиться, что на обычной нагрузке нет деградации производительности и удалить индексы. Удаление аналитических индексов повысит производительность операций DML над таблицей, так как их не нужно обновлять.

Анализ эффективности применения

Эффективность выполнения запроса можно оценить так:

set timing on
set autotrace on
SELECT max(prod_id) FROM sales;
ALTER SESSION SET INMEMORY_QUERY=DISABLE; 
SELECT max(prod_id) FROM sales;
ALTER SESSION SET INMEMORY_QUERY=ENABLE;

Оценка использования пула по плану выполнения:

Если запрос обращается к IM и не-IM таблицам, то IM-пул используется по возможности:

Если в SELECT во фразе WHERE используется фильтрация по значению столбца, по которому создан индекс, оптимизатор может выбрать план, который не использует IM-пул несмотря на то, что данные из таблицы в нём размещены. Удаление индекса по столбцу поможет оптимизатору создавать план выполнения, использующий IM-пул.

Использование IM-пула не означает, что будет идти сканирование всех IMCU, относящихся к объекту. При работе с IMCU используются алгоритмы, позволяющие исключать из сканирования IMCU, в которых находятся данные, не удовлетворяющие условиям запроса. Для этого используются данные по минимальным и максимальным значениям для каждого столбца в каждом IMCU. Эти данные видны в столбцахMINIMUM_VALUE, MAXIMUM_VALUE представления V$IM_COL_CU. Также используются техники bloom-фильтрации, in-Memory Aggregation (Vector group-by, Key vector, Vector transform).

Опции Adaptive plans, Adaptive Cursor Sharing, SQL Plan Management, Parallel Query работают с новой опцией.

Анализ эффективности с помощью SPA

Для проверки эффективности настроек IMCS можно использовать SQL Performance Analyzer (SPA). На входе SPA принимает SQL Tuning Set (STS), содержащий команды, которые нужно проанализировать; имя параметра инициализации действие которого нужно проанализировать — inmemory_query с двумя анализируемыми значениями disable и enable; в качестве анализируемой метрики можно указать Elapsed time:

Дальше SPA выполняет два прохода по каждой команде из STS. Результат можно посмотреть на странице SPA:

Загрузка базы данных в rкэш буферов 12с

Full Database in-Memory Caching

В 12c появилась ещё одна техника кэширования данных, которая не связана с IMCS. Если кэш буферов каждого экземпляра больше примерно 80% размера базы данных (используемых блоков данных), за исключением SYSAUX и временных табличных пространств, то блоки загруженные в кэш буферов, из него не вытесняются. LOB'ы с атрибутом NOCACHE (значение по умолчанию для LOB) в кэш буферов не загружаются. Большие таблицы в этом режиме могут полностью размещаться в кэше буферов, даже если их размер превышает 10% кэша буферов. База данных 12c использует такой режим работы по умолчанию.

Найти размер базы данных можно так:

select sum(bytes) from cdb_segments where tablespace_name<>'SYSAUX';

Если не хочется менять атрибут NOCACHE для LOB'ов, можно его игнорировать:

STARTUP MOUNT;
ALTER DATABASE FORCE FULL DATABASE CACHING;

Параметр инициализации DB_CACHE_SIZE необязательно устанавливать, можно использовать SGA_TARGET.

Вернуться в обычный режим командой:

ALTER DATABASE NO FORCE FULL DATABASE CACHING;

Узнать установленный режим работы можно так:

SELECT force_full_db_caching FROM v$database;

Режимы для основной и резервных баз данных устанавливаются независимо. Изменение режима сохраняется в control-файле.

В обоих режимах (FORCE FULL и NO FORCE FULL), предварительной загрузки блоков в кэш буферов не происходит, блоки подгружаются в кэш буферов по мере обращения к ним.

Большие таблицы и кэш буферов в 12с

Automatic Big Table Caching

Если оперативной памяти на компьютере недостаточно и условия использования Full Database in-Memory Caching не выполняются, в 12c можно использовать Automatic Big Table Caching. Она по умолчанию отключена. Эта опция позволяет выделить часть кэша буферов под хранение блоков больших таблиц параметром инициализации DB_BIG_TABLE_CACHE_PERCENT_TARGET. В зарезервированной этим параметром инициализации части кэша буферов блоки будут вытесняться не поблочно (по алгоритму LRU для каждого блока), а на основе частоты доступа к объекту (TEMPERATURE из представления V$BT_SCAN_OBJ_TEMPS). Если таблица не может полностью поместиться в зарезервированную часть, то помещается часть таблицы, оставшаяся часть будет считываться с диска.

Можно зарезервировать под кэширование блоков больших таблиц от 0 до 90% кэша буферов. Включение FORCE FULL DATABASE CACHING запрещает функционирование Automatic Big Table Caching.

Дополнительные материалы

Ссылки:

1. Oracle Database In-Memory: In-Memory Aggregation
   Oracle Whitepaper, январь 2015
2. Oracle Database In-Memory Advisor Best Practices
   Oracle Whitepaper, февраль 2015
3. Oracle Database In-Memory
   Oracle Whitepaper, июль 2015
4. Oracle Database In-Memory Advisor
   Oracle Whitepaper, 2015
5. Oracle Database In-Memory Configuration, Population & Querying
   Maria Colgan, Master Product Manager, Oracle, 2014
6. Oracle Database In-Memory & The Optimizer
   Maria Colgan, Master Product Manager, Oracle, 2014
7. Oracle In-Memory Database
   Calgary Oracle Users Group, 11 декабря 2014
8. Query Optimization in Oracle 12c Database In-Memory
   Dinesh Das, Jiaqi Yan, Mohamed Zait, Satyanarayana R Valluri, Nirav Vyas, Ramarajan Krishnamachari, Prashant Gaharwar, Jesse Kamp, Niloy Mukherjee // Proceedings of the VLDB Endowment, Vol. 8, No. 12
9. In-Memory Series
   Hatem Mahmoud Oracle's Blog, 23 декабря 2015