# ocrconfig -add +DATA
PROT-30: The Oracle Cluster Registry location to be added is not usable.
PROC-50: The Oracle Cluster Registry location to be added is inaccessible on nodes ....

# ocrconfig -add +RECO
PROT-30: The Oracle Cluster Registry location to be added is not usable.
PROC-50: The Oracle Cluster Registry location to be added is inaccessible on nodes ....

The reason: ASM diskgroup DATA and RECO are not mounted on one/some nodes.

Solution: mount these diskgroups:

$ sqlplus / as sysasm
SQL> alter diskgroup DATA mount;
or 
$ asmcmd mount DATA

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_type = ANALYTICS ;

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

Exadata Scrubbing

 

1. Появление сбойных секторов на диске автоматически запускает дополнительный scrubbing:

8.2.4 Adaptive Scrubbing Schedule
In release 12.1.2.3.0, if a bad sector is found on a hard disk in a current scrubbing job, Oracle Exadata System Software will schedule a follow-up scrubbing job for that disk in one week. When no bad sectors are found in a scrubbing job for that disk, the schedule will fall back to the scrubbing schedule specified by the hardDiskScrubInterval attribute.If the user has changed the hardDiskScrubInterval to less than or equal to weekly, Oracle Exadata System Software will use the user-configured frequency instead of the weekly follow-up schedule even if bad sectors are found.
Exadata adaptively and automatically increase the frequency of scrubbing on that disk until all corruptions are repaired.

2. Scrubbing - не применяется к Flash-селлам

3. Работу по восстановлению избыточности выполняет ASM:  
If scrubbing detects a sector is corrupted, the storage server requests ASM to repair the sector from one of the mirrors on another storage server. This is reason why multiple ASM-mirrors are essential.
Получается, что если ASM остановлен, то Scrubbing не может исправить данные на дисках

4. Scrubbing is an automated process on Exadata that kicks in when the disks are idle ( less than 25% busy )

5. How do you see if scrubbing is in action?

CellCLI> list metriccurrent where name = 'CD_IO_BY_R_SCRUB_SEC' and metricObjectName like 'CD.*'

CD_IO_BY_R_SCRUB_SEC    CD_00_exadbm01celadm01  115 MB/sec  <<< scrubbing sectors at a rate of around 115MB/s.
CD_IO_BY_R_SCRUB_SEC    CD_01_exadbm01celadm01  118 MB/sec
CD_IO_BY_R_SCRUB_SEC    CD_02_exadbm01celadm01  117 MB/sec
     ...
The cell above represents an idle cell. If it were under load, the values on the right would drop to 0 MB/sec.

6. Hard disk drives in the High Capacity storage servers connect to a disk controller, which includes a 2G cache. AWR is reporting the number of IOPS serviced by the disk controller cache, not the physical IOPS serviced by the disk itself.

Exadata X10M

Появились данные о том, как выглядит Экзадата Х10М-2 (то, что она уже есть - несомненно, вероятно пока работает только в Oracle Cloud):

DB node Unit -------- CPU ---------- ------------ RAM -------------- -------- PCIe- ---------- Ethernet 
E5-2L     2  2*AMD EPYC 9334 32-Core 384|512|768|1536|1920|3072|6144 x16 8GTs|16GTs|32GTs v5.0 6*25/10/1
E5-2L     2  2*AMD EPYC 9J14 96-Core 384|512|768|1536|1920|3072|6144 x16 8GTs|16GTs|32GTs v5.0 6*25/10/1
Cell                                                                                           H.Disk Flash
X10-2L HC 2  2*AMD EPYC 9334 32-Core 128|192|256|768|1536            x16 8GTs|16GTs|32GTs v5.0 12*22T  6 *7.68T 
X10-2L EF 2  2*AMD EPYC 9334 32-Core                 1536            x16 8GTs|16GTs|32GTs v5.0    -   10 *7.68T  

Основные изменения: переход на процессоры AMD (вероятно потому, что у AMD больше ядер). 

 Переход на AMD не удивляет - ещё весной 2022 года стало известно, что в своём облаке Оракл использует Экзадаты X9M на процессорах AMD, однако в on-premise Оракл эту модель не предлагает:
https://blogs.oracle.com/database/post/ ... ucture-x9m
https://www.oracle.com/a/ocom/docs/engi ... x9m-ds.pdf 

DB node Unit -------- CPU ---------- ------------ RAM -------------- -------- PCIe- ---------- Ethernet 
E4-2c     1  2*AMD EPYC 7J13 64-Core             1536|2048           x16 8GTs|16GTs v4.0       2*25/10/1  << X9M-2

 

Оракл считает, что достоинством AMD является большое количество ядер. В своём облаке Оракл назначил цену за физическое AMD-ядро в два раза меньше, чем за ядро Intel.

Основный изменения в X10M-2:

Серверы БД получат по 192 физических ядра (2 процессора по 96 ядер) и 6Т оперативной памяти, шина PCIe 5 поколения, 6 портов Ethernet 25Гбит/10Гбит/1Гбит. Некоторые серверы БД станут двух-юнитовыми.
Вызывает вопросы модель "E5-2L 2*AMD EPYC 9334 32-Core" - вероятно это сервер для тех, кому не требуется много ядер/лицензий на СУБД Оракл? Непонятная модель, поживём -увидим.

Селлы (ячейки хранения) получат шпиндельные диски по 22Т. Для компенсации возросшего объема шпиндельных дисков флеш-карт станет 6 штук, объем каждой по 8Т. Ядер и оперативной памяти в каждом селле также станет больше. В Х10М-2 исчез РМЕМ (потому что PMEM - это технология Intel). Вместо PMEM ожидаем память CXL.

Минимальная версия Экза-софта, способная работать на X10M-2 - это версия 23.1. Версия 23.1 работает на Oracle Linux 8.7 and UEK6 (5.4.17).

Поддерживаемые версии Oracle Database и Oracle Grid Infrastructure (GI): 19.15 и 21.6.
Иными словами: если ваша база ниже, чем 19.15 или 21.6, то на Х10М-2 такая БД работать не сможет. БД версий 11.2 и 12.1 и 12.2 также не смогут работать на X10M-2. Поэтому прежде, чем поставить 23.1 на свои Х5,Х6,Х7 и т.д. - предварительно обновите ваши БД до 19.5 или выше.

Обновиться на 23.1 можно только с версии 21.2.10 (March 2022) или более поздней.

Ну и несколько слов о перспективах:
- Seagate выпустит HDD емкостью 50 Тбайт в 2026 году https://servernews.ru/1088153
- AMD представила 128-ядерные EPYC Bergamo https://servernews.ru/1088342, https://servernews.ru/1088121

В общем, шпиндельные диски еще поживут.
Ядер в процессорах тоже станет больше.

 

PMEM -> XRMEM

 С января 2023 года Оракл переименовал PMEM в XRMEM.

Т.е. те, после обновления БД на январсий пачсет 2023 в статистиках вместо PMEM будет XRMEM (и в AWR-отчёте тоже).

Block Change Tracking

Начиная с 19.16 BCT-файл будет кешироваться в Flash Cache.

Начиная с 19.17 CTWR назначает операциям В/В высокий приоритет при высокой загрузке В/В.

Exadata on AMD cores - next X10 generation ?

Exadata Cloud Infrastructure X9M Database Server:
- 126 AMD EPYC™ Processor cores
- 1.35 TB Memory

Exadata-on-AMD  Data Sheet

 

Is scrubbing performed only on spindle HDD disks ?

Query from customer: Do I understand correctly that Scrubbing is performed only on HDD disks ? Those on Flash Storage cells scrubbing is not performed?

Answer: Yes, scrubbing is configured on spindle HDDs only.

The number of Exadata storage indexes raised to 24 per table

" ... the limit of 8 has been lifted in recent versions of the Exadata software up to 24."

 https://connor-mcdonald.com/2019/11/19/exadata-storage-indexes/

inmemory_force = CELLMEMORY_LEVEL

The Oracle Database InMemory feature requires the amount of physical memory from the database server to place IM Cache and some amount CPU resources.

The Exadata has the ability to use InMemory database feature on the cells. To use InMemory feature on cells you should enable the INMEMORY_SIZE at the Database nodes. So, Exadata owners still need to spend the amount of physical memory on the Database servers and memory on the cells.

The 19.8 PSU have brought the new great feature: inmemory_force = CELLMEMORY_LEVEL which offload 100% IM load to the cell level that significantly improve offloading for IM operations.

Starting with PSU 19.8, you can use the CellMemory feature without enabling the IM column store on the DB level. Starting with PSU 19.8 you can use combination of parameters

INMEMORY_FORCE=CELLMEMORY_LEVEL +  INMEMORY_SIZE=0

to enable IM column store at cell level and minimize IM Cache memory consumption at DB level.

From my point of view this feature will greatly improve the scalability of Exadata database machine for IM operations, because the more cells the more physical memory, IM-cache and CPU cores. This feature bring the more value to the Exadata cells.

 

More 500 Exadata racks in the Russia

По сообщению компании Оракл в России за 10 лет продано более 500 стоек Экзадат:

"В России развернуто более полутысячи комплексов и рост продаж год от года исчисляется двузначными цифрами. "

Exadata X8-2/X8M-2 don't support 1GbE client network

 One our Exadata customer started using Exadata from X3-2 model, seven years ago.
Now it still using 1GbE (copper Gigabit Ethernet ) in its enterprise network.

But today 1GbE for Exadata X8-2/X8M-2 is the problem: as became known Exadata X8-2/X8M-2 don't support 1GbE. 

Here answer from the SR: 

" We have checked on this whether any of the ports on X8s are supported to run at 1GbE, and the answer was 'no', we don't test at 1GbE, thus we don't support 1GbE. This is for both "copper"/RJ-45 10GBase-T, and the SFP28 with 10GbE transceivers. While the underlying hardware may/does support 1GbE, as an engineered system, X8s/X8Ms do not support the same. "


But the good news: "Don't support" doesn't mean "don't work" !!!

The documentation say the X8-2 server support the 1GbE copper:
https://docs.oracle.com/cd/E93361_01/html/E93391/gtaii.html

And the Exadata's rear pannel view shows 1GbE:
https://support.oracle.com/handbook_partner/Systems/Exadata_X8_2/images/X8_2_rear_zoom.html


 




So we asked our engineer to test 1GbE ports on X8-2 and he confirmed ports NET1/NET2 working at 1GbE .  He manually set 1GbE on ports and copied some files through these ports:

[root@node8 ~]# ethtool eth1
Settings for eth1:
        Supported ports: [ TP ]
        Supported link modes:   1000baseT/Full
                                10000baseT/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  1000baseT/Full
                                10000baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 12
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: Unknown
        Supports Wake-on: d
        Wake-on: d
        Current message level: 0x00000000 (0)

        Link detected: yes