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-сегменов.

The hidden space in Exadata, part 1

The very few people are aware about unallocated (free) space on the local disks of DB nodes of Exadata.

Connect to db node, run the vgdisplay and look the "Free PE" line. I'll show the X2-2 example:

[root@dbm1db02 ~]# vgdisplay
  --- Volume group ---
  VG Name               VGExaDb
  System ID            
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  13
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                3
  Open LV               3
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               556.80 GB
  PE Size               4.00 MB
  Total PE              142541
  Alloc PE / Size       39424 / 154.00 GB
  Free  PE / Size       103117 / 402.80 GB


As you can see we have 103117 free Physical Extent (PE Size =  4.00 MB).

Let use it:

[root@dbm1db02 ~]# lvcreate -l 103117 -n LVStore VGExaDb
  Logical volume "LVStore" created

I created the  " LVStore" - new logical volume in "VGExaDb" disk group.

You can see it in another way:

[root@dbm1db02 ~]# ls -l /dev/VGExaDb/
lrwxrwxrwx 1 root root 28 Jun 11 22:30 LVDbOra1 -> /dev/mapper/VGExaDb-LVDbOra1
lrwxrwxrwx 1 root root 29 Jun 11 22:30 LVDbSwap1 -> /dev/mapper/VGExaDb-LVDbSwap1
lrwxrwxrwx 1 root root 28 Jun 11 22:30 LVDbSys1 -> /dev/mapper/VGExaDb-LVDbSys1
lrwxrwxrwx 1 root root 27 Aug  2 16:57 LVStore -> /dev/mapper/VGExaDb-LVStore

The disk group VGExaDb now have no free space:

[root@dbm1db02 ~]# vgdisplay
  --- Volume group ---
  VG Name               VGExaDb
  System ID            
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  14
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                4
  Open LV               3
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               556.80 GB
  PE Size               4.00 MB
  Total PE              142541
  Alloc PE / Size       142541 / 556.80 GB
  Free  PE / Size       0 / 0

Let use new volume:

[root@dbm1db02 ~]# mkfs -t ext3 /dev/mapper/VGExaDb-LVStore
 
mke2fs 1.39 (29-May-2006)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
52805632 inodes, 105591808 blocks
5279590 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
3223 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
    102400000

Writing inode tables: done                           
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information:
done

This filesystem will be automatically checked every 29 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
[root@dbm1db02 ~]#
[root@dbm1db02 ~]# mkdir /store
[root@dbm1db02 ~]# e2label /dev/mapper/VGExaDb-LVStore store
[root@dbm1db02 ~]# vi /etc/fstab
[root@dbm1db02 ~]# mount /store 
[root@dbm1db02 ~]# df -h /store
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VGExaDb-LVStore
                      397G  199M  377G   1% /store

As you can see the X2-2 users can have additional 377g as new file system.

On the X4-2 Exadata you will have about 1.5T of additional space:

[root@ed02dbadm01 ~]# vgdisplay
  --- Volume group ---
  VG Name               VGExaDb
  System ID            
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  9
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                5
  Open LV               4
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               1.63 TB
  PE Size               4.00 MB
  Total PE              428308
  Alloc PE / Size       428308 / 1.63 TB
  Free  PE / Size       0 / 0

[root@ed02dbadm01 ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VGExaDb-LVStore
                      1.5T 1017G  375G  74% /store


Or you can go other way and extend / or /u01 using this unallocated space.

Standby for Exadata on non-Exadata storage

> is it possible to have standby for Exadata on non-Exadata storage ( EMC, HP ...) 

  

Физический стендбай для Эзадаты МОЖНО держать на обычном х86-64 сервере с обычным хранилищем. НСС-сегменты нормально обновляются процессом Redo Apply, т.е. изменения в НСС-сегментах будут применяться к стендбаю, т.е. стендбай будет актуальным. Операция Redo Apply выполняется над НСС-данными без декомпрессии.

Однако, при выполнении SELECT к НСС-сегментам будут происходить ошибки.

Но и в этом случае есть выход: операция Alter Table Move разожмет НСС-сегменты и превратит их в блоки сжатые OLTP-компрессией.

И тогда все ваши данные станут вам доступны.

Вот таков официально заявленный функционал.

---------------------------------------------------

Yes. 

It is possible to run physical standby for Exadata on non-Exadata equipment.

Take

- any server x86-64 (Supermicro for example)

- any 64-bit Linux   (5.9 or 6.4 for example)

- Oracle RDBMS of the same version as on the Exadata

You can ommit ASM and RAC on non-Exadata equipment and get single instance on file system.

You can copy database with RMAN as DUPLICATE ... or restore from backup and setup redo shipping and redo apply.

HCC-segments are updatable with Redo Apply, so your standby will be actual and be able to run behind production.  Redo Apply is performed on the HCC-data without decompression.

You'll get the error after you run SELECT to the HCC-segments.

But in this case you have a backdoor: Alter Table Move will decompress your HCC-segments into OLTP-compresses blocks and you'll be able to run SELECT against former HCC-segments.