инструктор УКЦ ФОРС,
Oracle Certified Master
Версия 12с (12.1.0.1) базы данных компании Oracle появилась несколько лет назад. Основное новшество в этой версии, заявленное при её выходе — Multitenant container database (CDB/PDB).
Несколько позже вышло обновление к версии 12c Release 1 (12.1.0.2.0). Ко времени выхода обновленной версии новые возможности 12с были описаны на конференциях пользователей, описаны в white papers, в курсе Oracle University D77758GC10 — Oracle Database 12c: New Features for Administrators, вышедшем в мае 2013 года.
Мало кто ожидал, что в обновлении 12c появится что-то новое, так как в предыдущих версиях базы данных сколько-нибудь существенных новшеств в обновлениях не появлялось. Однако, в версии 12.1.0.2.0 появилось новшество, которое может существенно ускорить работу с данными в базе. Опция называется "in-Memory Column Store". Oracle интегрировал в свою базу данных технологии, которые до этого использовались в Oracle TimesTen In-Memory Database. Сейчас и флагманский продукт Oracle имеет функционал In-Memory Database.
Появление версии 12c Release 1 прошло не так заметно, как выпуск 12c, и новая технология освещалась не так широко. Oracle University выпустил обновление курса D77758GC20 — Oracle Database 12c: New Features for Administrators, добавив в него главы по новым возможностям версии 12.1.0.2. В этой статье мы рассмотрим использование новой технологии и обзор других возможностей по кэшированию данных, которые появились начиная с версии 11g.
Технологии ускорения выполнения команд с помощью кэширования данных в оперативной памяти стали появляться в предыдущих версиях.
В 11 версии — SQL Query Result Cache, OCI Client Query Cache и PL/SQL Function Cache.
В 12 версии — in-Memory Column Store, Full Database In-Memory Caching и Automatic Big Table Caching.
Каждую из этих опций можно использовать отдельно от других опций. Наибольший интерес представляет in-Memory Column Store, её использование прозрачно для приложений и позволяет ускорить работу не только аналитических запросов, но и DML-команд. Опция может применяться и в хранилищах данных и в OLTP-системах.
SQL Query Result Cache кэширует результат выборки данных в SGA. Результат доступен другим сессиям. Команда, которая использует результат не обязательно должна быть такой же. Например, запрос:
SELECT prod_subcategory, revenue
FROM (SELECT /*+ RESULT_CACHE */ p.prod_category, p.prod_subcategory,
sum(s.amount_sold) revenue
FROM products p, sales s
WHERE s.prod_id = p.prod_id AND
s.time_id BETWEEN to_date('01-JAN-2006','dd-MON-yyyy') AND
to_date('31-DEC-2006','dd-MON-yyyy')
GROUP BY ROLLUP(p.prod_category, p.prod_subcategory))
WHERE prod_category = 'Women';
сможет использовать кэшированные данные, если выбирать данные по prod_category = 'Man'. Результат in-line view будет браться из кэша.
Также кэш будет наполняться выборками, использующими binding variables, результат будет кэшироваться для каждого набора значений переменных привязки отдельно.
Использование этого типа кэширования в OLTP-системах требует аккуратности, так как может привести к замедлению работы. Например, при первом выполнении вышеприведенного запроса оптимизатор не сможет использовать view merging, predicate push-down, column projection. Это может привести к деградации скорости первого выполнения запроса. Замедлением можно было бы пренебречь, но после внесения изменений в таблицы результат кэширования инвалидируется и количество повторных запросов, которые успеют воспользоваться кэшем может быть небольшим.
В DSS-системах, обрабатывающих большие объемы данных также есть особенности. На каждом экземпляре RAC кэш приватный и не передается процессам других экземпляров. Параллельные запросы могут заполнять кэш на экземпляре, где работает процесс-координатор, но отдельные параллельные процессы не могут использовать результаты кэширования.
Эта опция работает аналогично SQL Query Result Cache, только кэш выделяется на стороне клиента. Может быть полезным для использования на промежуточном уровне — серверах приложений. Эффективен для запросов, часто повторяющихся за короткое время. Например, сотня запросв за несколько секунд. Кэш может использоваться несколькими сессиями, созданными одним процессом в операционной системе клиента. Включить этот тип кэширования можно параметрами инициализации экземпляра базы данных CLIENT_RESULT_CACHE_SIZE, CLIENT_RESULT_CACHE_LAG или параметрами OCI_RESULT_CACHE_MAX_SIZE и OCI_RESULT_CACHE_MAX_RSET_ROWS в файле sqlnet.ora конкретных клиентов.
Эта опция позволяет кэшировать результаты выполнения функций PL/SQL в SGA и использовать для разных сессий. Результат функции должен определяться только параметрами, передаваемыми в неё и данными в таблицах, которые могут использоваться для вычисления результата. В качестве параметров функции и результата не поддерживаются LOBs, REF CURSOR, записи и объектные типы.
Наибольшее ускорение работы достигается, если функция обрабатывает данные из таблиц. Для использования этой опции нужно добавить метку в определение пакета или функции:
CREATE OR REPLACE FUNCTION func (emp_no NUMBER)
RETURN VARCHAR2
RESULT_CACHE RELIES_ON (emp)
IS
result VARCHAR2(50);
BEGIN
SELECT name INTO result
FROM emp
WHERE empno = emp_no;
RETURN result;
END;
Эффект от использования этой опции высок. Однако, функций в приложении может быть немного, а подходящих для этой опции функций ещё меньше.
Эта технология появилась в 12c версии базы данных Oracle.
Преимущества технологии:
Поддерживаемые объекты:
Эта опция не обслуживает:
Скорость выборки, соединения, фильтрации данных на больших объемах может увеличиться в сотни раз. Использование опции не накладывает ограничения на внесение изменений в таблицы. Скорость операций 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 происходит, если:
Если в пуле недостаточно свободного места, то в пуле размещается только часть объекта. При обращении к такому объекту часть данных выбирается из пула, часть из кэша буферов, флэш-кэша или из файлов данных.
Информацию о статусе загрузки данных объекта в IM-пул объекта (STARTED, COMPLETED) можно узнать так:
SELECT SEGMENT_NAME, POPULATE_STATUS, INMEMORY_SIZE, BYTES_NOT_POPULATED FROM V$IM_SEGMENTS;
Если на объекте проводится операция 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, который входит в лицензию на 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 для практической проверки рекомендаций.
В командах создания объекта CREATE или изменения ALTER можно указать опцию INMEMORY или NO INMEMORY. Опционально можно задать следующие опции:
При этом план выполнения запроса уже будет использовать 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 до 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.
Данные распределяются между экземплярами RAC, это позволяет экономить память. Параллельные запросы используют данные из всех экземпляров путем запуска параллельных процессов на этих экземплярах. Нужно использовать автоматическое определение уровня параллелизма (AUTO DOP), так как при ручном задании уровня параллелизма, параллельные процессы могут запуститься только на части экземпляров и IM-пулы на оставшихся экземплярах не будут использоваться.
Значения параметров, установленных на уровне таблиц, можно узнать так:
SELECT table_name, inmemory_compression, inmemory_priority, inmemory_distribute, inmemory_duplicate FROM dba_tables;
Можно использовать 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 работают с новой опцией.
Для проверки эффективности настроек IMCS можно использовать SQL Performance Analyzer (SPA). На входе SPA принимает SQL Tuning Set (STS), содержащий команды, которые нужно проанализировать; имя параметра инициализации действие которого нужно проанализировать — inmemory_query с двумя анализируемыми значениями disable и enable; в качестве анализируемой метрики можно указать Elapsed time:
Дальше SPA выполняет два прохода по каждой команде из STS. Результат можно посмотреть на странице SPA:
В 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), предварительной загрузки блоков в кэш буферов не происходит, блоки подгружаются в кэш буферов по мере обращения к ним.
Если оперативной памяти на компьютере недостаточно и условия использования 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.