Wednesday, February 11, 2026

Exadata 25.2 New Features for TEMP operations

В продолжение предыдущего поста https://exadata-dba.blogspot.com/2026/02/mainworkloadtypeanalytic.html немного про новые возможности Экза-софта 25.2:  

 
1. Изменился алгоритм кеширования временных ТЕМР-сегментов

Большие и сложные SQL-запросы как правило создают большой объем временных/промежуточных данных, которые возникают на этапах Hash Join, Sort, Group By. До каких-то объемов ТЕМР за счёт Flash Cache в Экзадате удаётся поддерживать приемлемую производительность. Но когда временные сегменты ТЕМР не помещаются в свободное место в Flash Cache и выталкивается на шпиндельные диски, это намного увеличивает время построения отчётов.

Проблема с кеширование ТЕМР (выталкиванием ТЕМР на диск) в ячейках Экзадаты возникает из-за того, что временные сегменты ТЕМР не используются повторно. Временные ТЕМР-сегменты требуются только той сессии, которая их создала, и никогда не понадобятся другим сессиям. Поэтому в промышленных условиях, когда FC заполнен полезными данными - блоками таблиц, индексов, IM-представление данных - содержимое ТЕМР представляется менее полезным кандидатом на кеширование, чем остальные данные. Приоритет у таблиц, индексов, IM - вышет. Поэтому при достаточности свободного пространства в FC временные ТЕМР-сегменты вынужденно выталкивались на шпиндельные диски.

Ранее эта проблема решалась путем покупки Extreme Flash-ячеек исключительно под размещение ТЕМР.
Был ещё вариант - отрезать кусочек от Flash Cache и построить на этом месте отдельную ASM-группу, в которую положить ТЕМР-файлы. И надо сказать, что даже такой неоднозначный шаг приносил положительные результаты.


В новой версии Оракл сделал шаг в сторону решения этой проблемы:

"Starting with Exadata System Software 25.2 and Oracle Database 23ai,
Exadata uniquely reclaims the flash space that was occupied by prior temp I/O writes,
without persisting this data to hard disk. This instant flash reuse capability
eliminates hard disk writes and ensures efficient temp data caching,
even as query workloads scale across many RAC instances and databases.
As a result, analytics queries are up to 1.6x faster.

Переведу:
Начиная с Exadata System Software 25.2 и Oracle Database 23ai
Exadata повторно использует пространство во флэш-памяти занятое предыдущими
операциями ввода-вывода в TEMP без сохранения этих данных на жестком диске.
Эта возможность немедленного повторного использования флэш-памяти исключает
необходимость записи на жесткий диск и обеспечивает эффективное кэширование
врЕменных данных. В результате аналитические запросы выполняются до 1,6 раз быстрее.


В версии Oracle Exadata System Software 25.2.0 представлены оптимизации,
позволяющие серверу хранения удалять данные TEMP из флэш-кэша сразу после того,
как пользовательская сессия завершает операцию с ТЕМР.
Эта уникальная возможность Exadata оптимизирует использование пространства флэш-кэша
и повышает общую производительность системы, избегая ненужных дисковых операций ввода-вывода
и немедленно освобождая ценные ресурсы флэш-кэша для повторного использования другими клиентами.

Поскольку в Экзадате кешированием данных управляет СУБД (а не селлы), то для использования этой возможности требуется Oracle Database с патчем 38068007.


2. Изменился приоритет операций В/В в ТЕМР
Второй пункт является в некотором смысле продолжением первого, Оракл повысил приоритет операций В/В в табличные пространства ТЕМР:

"Smart Flash Cache plays a crucial role in delivering high
performance for analytics, AI, and mission-critical workloads.
With Exadata System Software 25.2, Exadata automatically prioritizes
temporary I/O and flashback log writes above other types of large write I/O,
such as I/O related to ASM resync and rebalance operations.
This ensures active database queries are always given the highest priority access to Flash Cache resources.
Other large writes are cached only if there is available flash capacity."

"ExaSoft 25.2 автоматически отдаёт приоритет операциям ввода-вывода в ТЕМР и операциям записи Flashback
по сравнению с другими типами операций записи больших объёмов данных,
такими как операции повторной синхронизации и балансировки ASM.
Это гарантирует, что активныt запросs к БД всегда будут иметь наивысший приоритет обращении в Flash Cache.
Другие операции записи больших объёмов данных кэшируются только при наличии доступной флэш-памяти."


Ранее Exa-софт не различал разные типы больших операций записи: все большие операции записи должны были использовать одни и те же ресурсы флэш-кэша независимо от их относительного влияния на производительность.

В версии 25.2.0 изменились алгоритмы приоритизации больших объемов записи в Exadata Smart Flash Cache.
В рамках этой схемы приоритет отдается большим объемам записи, связанным с определенными операциями,
которые стабильно обеспечивают наибольший выигрыш в производительности. Список приоритетов в первую очередь включает большие операции записи, связанные с временными сегментами (TEMP) и журналированием ретроспективных данных (DB Flashback).

Приоритет больших операций записи в Exadata Smart Flash Cache устанавливается только тогда,
когда заполненность кэша превышает 50%, либо по общему использованию пространства кэша,
либо по использованию пространства кэша, выделенного соответствующей группе Exadata I/O Resource Management (IORM).
Если загрузка ниже порогового значения 50%, все большие операции записи имеют те же возможности использовать кэш, что и раньше.
После того, как заполненность кэша превысит 50%, использовать кэш разрешено только приоритетным большим операциям записи.

MAIN_WORKLOAD_TYPE=ANALYTIC

 The following initialization parameter is new in Oracle Database 19c, Release Update 19.21:

 MAIN_WORKLOAD_TYPE=OLTP|ANALYTIC

 

3.2.3 Optimizing Exadata Smart Flash Cache for Analytical Workloads

По умолчанию Exadata Smart Flash Cache отдает предпочтение кэшированию часто используемых данных и ограничивает кэширование данных с низким потенциалом повторного использования, таких как temporary segments. Причём, temporary segments – это первые кандидаты на вытеснение, когда возникает потребность в пространстве для многократно используемых данных. Этот подход к кешированию данных хорошо работает для OLTP-нагрузок. Однако, аналитические запросы обычно недоиспользуют возможности Exadata Smart Flash Cache из-за слабого кеширования ТЕМР в процессе обработки больших join- и sort-операций с временными сегментами. Для лучшего использования Exadata Smart Flash Cache для аналитических нагрузок Exa-софт появился параметр main_workload_type=OLTP|ANALYTIC который задаёт тип нагрузки для данной БД.

Включить использование этой возможности:

SQL> alter system set main_workload_typeANALYTICS ;

Параметр динамический.

Exadata 25.2 New Features for TEMP operations

В продолжение предыдущего поста https://exadata-dba.blogspot.com/2026/02/mainworkloadtypeanalytic.html немного про новые возможности Экза-со...