Exadata X5-2

В продолжение http://exadata-dba.blogspot.ru/2014/08/in-memory-option.html 

Близится OpenWorld и звезды все плотнее сходятся в одну точку:
в июле Intel уже выпустил очередную серверную версию процессоров на ядре Haswell-EP:
Xeon E5-2600 V3 (предыдущая была v2 = Экзадата Х4-2), и они уже доступны для заказа:
http://www.cpu-world.com/news_2014/2014080502_Xeon_E5-2600_v3_CPUs_are_available_for_pre-order.html

http://iintel.ru/processors/svezhie-dannye-o-intel-xeon-e5-2600-v3.html 

Новые ЦПУ будут по 14-18 ядер (было 12), 35-45 MB L3 кэш (было 30), отпускная цена на них выросла на 6%.

Как пишут более осведомленные (напомню, что Ivy Bridge это Х4-2):

"Compared to Ivy Bridge:
- Approximately 8% better vector processing performance.
- Up to 6% faster single-threaded performance.
- 6% faster multi-threaded performance.
- A 6% increase in sequential CPU performance (eight execution ports per core versus six).
- Total performance improvement on average is about 3%.

So it is up to DDR4 to bring any real difference.
DDR4 is around 50-100% faster than DDR3 on paper."

Переход на DDR4 у Intel ожидается в 1 квартале 2015.
4-х сокетные версии процов тоже в 1 квартале 2015.

Осталось подождать конца сентября.
Ну в крайнем случае - до НГ.
Ну а там и конец Q1 2015 не за горами :) !

Ну и еще одна интересная ссылка:
http://iintel.ru/processors/intel-xeon-e5-2600-v3-novyj-processor-dlya-oracle.html

ORA-31623: a job is not attached to this session via the specified handle

Yesterday did the impdp on our Exadata:

[oracle@ed02dbadm01 fns]$ cat imp.par 

[oracle@ed02dbadm01 fns]$ cat imp.par

userid=yu/yu

directory=fns

sqlfile=ddl.sql

job_name=yu

EXCLUDE=USER:" in ('SYS','SYSTEM','OUTLN','ORDDATA','OLAPSYS','MDDATA','SYSMAN','MGMT_VIEW','FLOWS_FILES','APEX_PUBLIC_USER','APEX_030200','OWBSYS','OWBSYS_AUDIT','SCOTT') "

LOGTIME=ALL

Import not worked, the import log :

Import: Release 12.1.0.1.0 - Production on Thu Aug 7 18:06:21 2014

UDI-31623: operation generated ORACLE error 31623

ORA-31623: a job is not attached to this session via the specified handle

ORA-06512: at "SYS.DBMS_DATAPUMP", line 3874

ORA-06512: at "SYS.DBMS_DATAPUMP", line 5161

ORA-06512: at line 1

Alert log :

Thu Aug 07 17:55:48 2014

DW00 started with pid=197, OS id=57824, wid=1, job YU.YU

Shared IO Pool defaulting to 512MB. Trying to get it from Buffer Cache for process 57824.

Thu Aug 07 17:55:56 2014

opidrv aborting process DM00 ospid (57808) as a result of ORA-447

The solution was found in Internet, the MOS have no information about this error:

[oracle@ed02dbadm01 fns]$ set|grep NLS

NLS_DATE_FORMAT='DD.MM.YYYY HH24:MI:SS'

[oracle@ed02dbadm01 fns]$ export NLS_DATE_FORMAT='YYYYMMDD HH24:MI'

This solution works !

Disk Swap Service

As we all know we can increase the storage system space in our Exadata with 3 ways:

- add a cell to our Exadata

- upgrade Exadata: 1/8 => 1/4  => 1/2 => Full

- add Expansion Rack

Now Oracle allows one another way - change HP disks to HC (4T size) on the same Exadata. 

This process is called "Disk Swap Service" and is allowed for X2,X3,X4 machines.

Only hard disks are swapped, flash disks are not touched, they remain.

For 1/4 you need to buy 37 disks (36 will be installed and one is spare).

For 1/2 - 85 and for Full - 169 new 4T disks.

The swapping is carried by ACS.

You need the 11.2.3.3.1 Exadata software version or later (July 2014 Exadata Quarterly Full Stack Patch).

Details are in Oracle note:

Oracle Exadata Database Machine Disk Swap Service Process (Doc ID 1544637.1)

In-Memory Option меняет вид следующей Экзадаты

Ранее я уже описал свои предположения о технических характеристиках Экзадаты Х5-2.

Добавим несколько слов о том, как опция In-Memory изменит облик следующего поколения Экзадат (чисто мои предположения, возражения приветствуются). 

IMO реализована в виде специализированных процессов (в количестве CPU_COUNT/2),

которые после старта инстанса строят Columnar Store в IM-пуле (оперативной памяти) сервера.

Очевидно, что процесс построения CS 

-  требует много ЦПУ

- предельно сильно нагружает ввод-вывод, потому что выполняется полное табличное сканирование больших объемов данных. 

- и сопровождается большим объемом блокировок из-за массовой вставки блоков в буферный кэш.

Оракл не зря ограничил количество этих процессов величиной CPU_COUNT/2, чтоб оставить место для работы остальных процессов БД. Также очевидно, что сканирование больших сегментов + подъем их в память на серверах стандартной архитектуры приведет к 100%+ загрузке ввода вывода на длительный период - на много часов, потому что требуется просканировать все исторические таблицы, поднять их в память и построить из них CS-сегменты.

После старта инстанса эта работа будет происходить на фоне активных чтений с дисков в буферный кэш (в интересах OLTP-приложений), хард парсинга, и т.д. Т.е. после старта инстанса загруженность серверов БД будет около 100% на протяжении многих часов.

Вероятно также будут заметные проблемы с блокировками.

В общем, будет наблюдаться самый худший сценарий, аналогичный одновременному выполнению OLTP и DWH в одном сервере в одной БД.

1.

Селлы в Экзадате всегда недогружены, а БД-ноды всегда перегружены.

Отсюда один шаг до очевидного предположения :

В Экзадате сканированием табличных сегментов и преобразованием их в CS будут заниматься селлы. Скорее всего Оракл добавит дополнительный функционал в серверные процессы СХД, чтобы СХД формировала CS-сегменты и раздавала их серверам БД прямо в In-Memory-пул, других вариантов нет.

2.

Применительно к Экзадате мне кажется, что Оракл не будет создавать два формата Columnar Store - один для НСС, а второй для IMO. Это сложно и для разработки и для эксплуатации и для техподдержки, и главное, для оптимизатора и выполнения SQL. Скорее всего формат Columnar Store один, а НСС - это Columnar Store,  дополнительно сжатый gz или bz. Т.е внутри это один и тот же оптимально построенный CS. Не может быть двух оптимальных CS у одного Оракла. Если таблицы уже находятся в НСС-формате, то работа селлов будет заключаться в распаковке и передаче CS в IM-пул - минимальный объем работ. Не верится, что Оракл будет переупаковывать данные из одного формата в другой.

3.

Серверов БД бывает много, например 8 штук, как в случае Full Rack, или еще больше, если связать несколько Экзадат.

Это означает,  что все 8 IM-пулов всех 8 серверов БД будут хранить одни и те же данные, т.е. содержимое памяти у всех 8 серверов будет 8-кратно дублировано. В случае объединения нескольких Экзадат эта пропорция еще более ухудшается.

Поэтому для улучшения масштабирования Оракл может применить еще одно решение на Экзадате: IM-пул может быть выделен в физической памяти селла или на флэш-дисках. В этом случае расход памяти будет однократный, чтение с дисков - тоже. Каждый селл будет хранить свою часть IM-пула автоматически, читая primary-экстент соответствующей таблицы.

Количество серверов хранения больше, чем серверов БД (отношение 14 к 8), поэтому 

- хранить в их памяти CS-сегменты еще более надежно, чем в серверах БД,

- при выходе из строя одного селла производительность всей Экзадаты пострадает в меньшей степени, чем при выходе из строя одного сервера БД, потому что теряется меньше данных

- также в сервере хранения проще,легче,быстрее восстановить утраченные сегменты, чем в сервере БД,

- серверов хранения больше, чем серверов БД и им не требуется дополнительно хранить и обслуживать SGA в своей оперативной памяти, поэтому они могут хранить больше CS-данных, чем серверы БД.

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

Сейчас Оракл и разрешил политику DUPLICATE для CS-сегментов только на Экзадате (однократное выполнение дискового сканирования).

В не-Экзадатовских RAC разрешена только политика
DISTRIBUTE   AUTO | BY { ROWID RANGE | PARTITION | SUBPARTITION } - что означает, что каждая БД-нода содержит только свою часть таблицы и соответственно сканирует свою долю экстентов.

4.

С учетом Flash Cache Persistence (сохранения содержимого FC после рестарта селл) производительность Экзадаты должна пострадать в гораздо меньшей степени, чем производительность стандартных архитектур. OLTP-операции будут получать данные из FC и не будут создавать сколько-нибудь заметную нагрузка на жесткие диски. Поэтому деградации производительности для OLTP-операций на Экзадате будет незаметно.

Временно (на несколько часов) пострадают операции Smart Scan которые также выполняют сканирующие операции, аналогичные операциям построения CS-сегменов.