О попаданиях в кэш

Подмножество столбцов в списке SELECT должно совпадать

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

Это правило описывает минимальное требование для попадания в кэш, но соблюдение этого правила не гарантирует попадания в кэш. Также применяются другие правила, перечисленные в этой таблице.

Столбцы в списке SELECT могут состоять из выражений в столбцах кэшированных запросов

Oracle Analytics Cloud может вычислять выражения на основе кэшированных результатов для получения ответа на новый запрос, но все столбцы должны быть в кэшированном результате. Например, запрос

SELECT product, month, averageprice FROM sales WHERE year = 2000

попадает в кэш для запроса

SELECT product, month, dollars, unitsales FROM sales WHERE year = 2000

так как averageprice можно вычислить на основе dollars и unitsales (averageprice = dollars/unitsales).

Фраза WHERE должна быть семантически одинаковой или логическим подмножеством

Чтобы запрос соответствовал требованиям попадания в кэш, ограничения фразы WHERE должны быть эквивалентны кэшированным результатам или подмножеству кэшированных результатов.

Фраза WHERE, которая представляет собой логическое подмножество кэшированного запроса, соответствует требованиям попадания в кэш, если данное подмножество соответствует одному из следующих критериев:

• Подмножество значений списка IN. Запросы, запрашивающие меньше элементов, чем в списке IN, квалифицируются для попадания в кэш. Например, следующий запрос:

  SELECT employeename, region
  FROM employee, geography
  WHERE region in ('EAST', 'WEST')

  соответствует требованиям попадания в кэш для следующего кэшированного запроса:

  SELECT employeename, region
  FROM employee, geography
  WHERE region in ('NORTH', 'SOUTH', 'EAST', 'WEST')

• Он содержит меньше (но идентичных) ограничений OR, чем в кэшированном результате.

• Он содержит логическое подмножество литерального сравнения. Например, следующий предикат:

  WHERE revenue < 1000

  соответствует требованиям попадания в кэш для сопоставимого запроса со следующим предикатом:

  WHERE revenue < 5000

• Отсутствует фраза WHERE. Если кэширован запрос без фразы WHERE, то запросы, которые удовлетворяют всем остальным правилам попаданий в кэш, считаются попаданиями в кэш независимо от их фразы WHERE.

Кроме того, столбцы, используемые во фразе WHERE, должны находиться в проекционном списке. Например, следующий запрос:

SELECT employeename
FROM employee, geography
WHERE region in ('EAST', 'WEST')

Не приводит к попаданию в кэш заполняющего запроса из предыдущего списка, так как REGION не находится в проекционном списке.

Запросы только для измерений должны быть полным совпадением

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

Запросы со специальными функциями должны быть полным совпадением

Другие запросы, которые содержат специальные функции, такие как функции временных рядов (AGO, TODATE и PERIODROLLING), функции ограничения и смещения (OFFSET и FETCH), функции взаимосвязи (ISANCESTOR, ISLEAF, ISROOT и ISSIBLING), внешние функции агрегации и, как правило, метрики фильтра также должны быть полным совпадением с проекционными столбцами в кэшированном запросе. В этих случаях фильтр также должен быть полным совпадением. Для метрик фильтра, если метрику фильтра можно переписать как фразу WHERE, тогда можно использовать кэш подмножества.

Набор логических таблиц должен совпадать

Чтобы соответствовать требованиям попадания в кэш, все входящие запросы должны иметь тот же набор логических таблиц, что и запись в кэше. Это правило позволяет избежать ложных попаданий в кэш. Например, SELECT * FROM product не совпадает SELECT * FROM product, sales.

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

Если логическая или физическая инструкция SQL ссылается на любую переменную сеанса, значения переменных сеанса должны совпадать. В противном случае нет попадания в кэш.

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

Эквивалентные условия соединения

Результирующая объединенная логическая таблица новой заявки запроса должна совпадать с кэшированными результатами (или их подмножеством), чтобы соответствовать критериям попадания в кэш.

Атрибут DISTINCT должен быть одинаковым

Если кэшированный запрос удаляет дубликаты записей с обработкой инструкции DISTINCT (например, SELECT DISTINCT...), то запросы кэшированных столбцов также должны включать обработку DISTINCT. Запрос для того же столбца без обработки DISTINCT — это кэш-промах.

Запросы должны содержать совместимые уровни агрегирования

Запросы, запрашивающие агрегированный уровень информации, могут использовать кэшированные результаты с более низким уровнем агрегирования. Например, следующий запрос запрашивает количество товаров, проданных на уровне поставщика, региона и города:

SELECT supplier, region, city, qtysold
FROM suppliercity

Следующий запрос запрашивает количество товаров, проданных на уровне города:

SELECT city, qtysold
FROM suppliercity

Второй запрос приводит к попаданию в кэш для первого запроса.

Ограниченное дополнительное агрегирование

Например, если запрос со столбцом qtyled кэширован, то запрос RANK(qtyled) приводит к кэшу-промаху. Кроме того, запрос, выполняемый qtysold на уровне страны, может получить попадание в кэш по запросу, выполняемому qtysold на уровне страны и региона.

Фраза ORDER BY должна состоять из столбцов в списке выбора

Запросы, упорядоченные по столбцам, которых нет в списке выбора, приводят к кэш-промахам.

Диагностика поведения попаданий в кэш

Чтобы лучше оценить поведение попаданий в кэш, задайте переменной сеанса ENABLE_CACHE_DIAGNOSTICS значение 4, как показано в следующем примере:

ENABLE_CACHE_DIAGNOSTICS=4