Oracle анонсировал 1000-ю инсталляцию Exadata!

27 июня Oracle анонсировал 1000 инсталляцию Oracle Exadata Database Machine у своих клиентов. На текущий момент Exadata используется в 23 различных отраслях в 67 странах мира.
По данным одного из моих коллег у конкурента Exadata в области корпоративных хранилищ Teradata за 30 лет работы 1000 заказчиков и 2500 инсталляций.
1000 инсталляций за чуть более чем 3 года для принципиально нового продукта ... по моему, неплохо А? ;)

http://www.oracle.com/us/corporate/press/422468

Такой большой и очень умный

Многие многоопытные администраторы баз данных Oracle, рассуждая о возможном использовании флэш модулей, расположенных на ячейках Экзадаты, демонстрируют действительно незаурядные фантазии ;) Я попробую показать, что лучше всего эти модули использовать именно так, как по умолчанию их кон фигурируют инженеры Oracle, т.е. как Smart Flash Cache. Но сначала всё-таки давайте узнаем, что же это такое.

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

Когда размер имеет значение

Всем известно, что все современные процессоры имеют несколько уровней кэш. Самые производительные оснащаются КЭШем сразу трёх уровней. Что бы показать тенденцию рассмотрим процессор Intel Xeon X7560, используемый в Exadata модели X2-8.

Уровень	Размер	Латентность (циклы)
L1	32+32 KB на ядро	4
L2	256 KB на ядро	9
L3	24 MB всего (3 МБ на ядро)	63

Вывод из этого прост и вполне очевиден – чем дальше уровень кэш от места, где непосредственно используются данные, тем более медленная, а значит, дешевая память в нем используется. Но главное, все же ни в этом – разница в размерах этих КЭШей составляет порядок.

Если сопоставить размеры оперативной памяти в серверах базы данных с размером Flash Cache на ячейках Exadata, то мы получим следующее:

Модель	Конфигурация	Размер RAM	Размер Flash Cache
X2-8	FULL	2TB	5.3TB
X2-2	FULL	768GB	5.3TB
X2-2	HALF	384GB	2.6TB
X2-2	QUARTER	192GB	1.1TB

Учитывая, что размер буферов СУБД для OLTP приложений в таких конфигурациях вряд ли будет превышать 20-30% от общего размера памяти, мы как раз и получаем те самые доказанные практикой соотношения в порядок. При этом, следуя приведенным выше канонам стоимость памяти на основе FLASH существенно дешевле динамической памяти, используемой в серверах БД.

В этой связи не совсем понятно, какой смысл приобретать high-end дисковые массивы с кэш из дорогой динамической памяти, максимальный размер которой измеряется сотнями гигабайт, что сопоставимо с конфигурируемым размером кэша буферов?! С моей точки зрения в таких случаях гораздо эффективней потратить деньги на увеличение оперативной памяти серверов, а в дисковом массиве оставить размер кэш, который покроет потребности для обеспечения быстрых операций записи.

Но вернемся в к Экзадате, которая следуя “классическим канонам”  кэширования, имеет правильный кэш.  Вторая отличительная особенность этого кэш угадывается в его названии - SMART FLASH CACHE.

Почему кэш SMART?

Строя интеллектуальный сторадж, который умеет обращаться с сохраняемой на нём информации ни как с обезличенным набором битов и байтов, а как с данными СУБД Oracle, было трудно отказаться от соблазна “интеллектуализировать” и алгоритм кэширования.

Ячейки Exadata относятся к кэшированию данных избирательно, отдавая приоритет блокам, к которым с большой вероятностью потребуется повторный доступ. Здесь работают во многом похожие алгоритмы на те, которые определяют правила сохранения данных в КЭШе буферов экземпляра СУБД.

Поэтому данные, которые читаются большими порциями, кэшироваться не будут, если только на уровне сегмента не определить атрибут CELL_FLASH_CACHE KEEP. Всё очень знакомо, неправда ли? "Издревле" подобной операцией пользовались для того, что бы закрепить блоки определенного сегмента в КЭШе экземпляра самой СУБД.

CREATE TABLE pt (c1 number)

  PARTITION BY RANGE(c1)

   (PARTITION p1 VALUES LESS THAN (100)

     STORAGE (CELL_FLASH_CACHE DEFAULT),

    PARTITION p2 VALUES LESS THAN (200)

     STORAGE (CELL_FLASH_CACHE KEEP));

ALTER INDEX tkbi STORAGE (CELL_FLASH_CACHE NONE);

У CELL_FLASH_CACHE  может быть три значения, по названиям которых можно угадать политики, которые они определяют - KEEP, NONE, DEFAULT.  А еще есть хинты…

Я не буду в подробностях вдаваться во все тонкости работы SMART FLASH CACHE, скажу лишь, что эффективность его работы действительно потрясающая.

Посмотрите на AWR отчеты Ваших OLTP систем и найдите время, которое тратится на одиночную операцию чтения. Сколько? На практике испытаний с использованием high end дисковых массивов знаю, что эта величина чаще всего крутится около значения в 5мс. (Ну и где эффект быстрого, но “маленького” КЭШ этих дорогих железок?)

А теперь давайте глянем на пример тяжелого испытания OLTP системы на Exadata X2-8. Около 15 тысяч одновременных сессий с СУБД, выполняющих около 4M logical reads/с при 14K IOPS для всей СУБД.

Пусть Вас не вводит в заблуждение число 1мс – если не округлять, то у нас получится 6192с/7445684 = 0.83мc. (Посчитал и понял, что пример неудачный :) - чаще всего этот показатель составляет около 0.7мс)

Не почувствовать разницу легко, если она почти на порядок :)

А еще флэш память Exadata ячеек можно сконфигурировать как диски ASM… И в этом месте у администраторов СУБД Oracle начинают чесаться руки. 

“Иногда лучше молчать, чем говорить” (с) <- это я про себя.

Сразу следуют вполне естественные предложения:

-          “А давайте на ASM Flash-дисках разметим редологи!”

-          “А можно создать на нем табличное пространство для горячих объектов?”

-          “А что если туда забабахать Database Smart Flash Cache?”

-          …

Всё это конечно можно, но зачем? Oracle создал действительно сбалансированную конфигурацию вплоть до тонкостей. Не трогайте ничего, до тех пор, пока действительно не будете понимать, к каким последствиям приведут Ваши действия.

И все же?! А что если редологи туда? В ответ приведу данные из того же отчета. Cессии на экземпляре генерировали redo порядка 6МБ/с.

А если посчитаем без округлений: 2126c/3458313 = 0.61мс!!!

- Ууупс! А чего так быстро? А всё дело в другом КЭШе :) В обычном кэше, который есть на большинстве дисковых контроллеров. На дисковых контроллерах, которые находятся в каждой ячейке Exadata есть КЭШ из динамической памяти размером 512МБ. Итого 512МБ * 14 ячеек = 7ГБ на конфигурацию FULL. Оказывается вполне достаточно, что бы покрыть потребности в записи такого объема redo (стоит учесть, что второй узел в этом тесте генерировал почти столько же redo).

 И только не нужно меня убеждать в том, что скорость записи на FLASH будет превосходить скорость записи в динамическую память :)

Поехали дальше… 

Как на счет табличного пространства с горячими объектами? Наверное, будет работать быстрее, чем с FLASH CACHE, но только до тех пор, пока FLASH CACHE не разогреется. Относительно времени жизни экземпляра СУБД Oracle это преимущество будет несоизмеримо мало, а после кратковременной эйфории начинется глубокое похмелье - на FLASH дисках данные же нужно дублировать! В результате для горячих объектов будет использоваться в два раза больше дорогой FLASH памяти, что существенно снижает эффективность ее использования. Этого мы добивались?

Ну а желание разместить на FLASH дисках ячеек Database Smart Flash Cache легко бьется другим конём – давайте подумаем и сопоставим время, которое необходимо для обращения к FLASH-карте размещенной в слоте PCI из самой ячейки Exadata со временем, которое необходимо для обращения к ней же с внешнего сервера БД. Огромная разница в латентности при практически совпадающем функционале.

Еще варианты будут?

Different types of Oracle Database compression in the same data segment

Hi there!


Do you know that Oracle Database could store blocks with different type of compression in the same segment? (unpartitioned table or partition/subpartition)

Simple example using Exadata.

SQL*Plus: Release 11.2.0.2.0 Production on Sat Mar 19 17:37:41 2011

Copyright (c) 1982, 2010, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options
SQL> set linesize 500
SQL> create table vd.test_compress as select * from dba_objects;

Table created.

SQL> alter table vd.test_compress compress for OLTP;

Table altered.

SQL> insert /*+ APPEND */ into vd.test_compress select * from dba_objects;

647847 rows created.

SQL> alter table vd.test_compress compress for QUERY LOW;

Table altered.

SQL> insert /*+ APPEND */ into vd.test_compress select * from dba_objects;

647850 rows created.

SQL> alter table vd.test_compress compress for QUERY HIGH;

Table altered.

SQL> insert /*+ APPEND */ into vd.test_compress select * from dba_objects;

647848 rows created.

SQL> alter table vd.test_compress compress for ARCHIVE LOW;

Table altered.

SQL> insert /*+ APPEND */ into vd.test_compress select * from dba_objects;

647847 rows created.

SQL> alter table vd.test_compress compress for ARCHIVE HIGH;

Table altered.

SQL> insert /*+ APPEND */ into vd.test_compress select * from dba_objects;

647851 rows created.

SQL> commit;

Commit complete.

SQL> select
  2  case DBMS_COMPRESSION.GET_COMPRESSION_TYPE ('VD', 'TEST_COMPRESS', ROWID)
  3  when 1 then '1 - No Compresson'
  4  when 2 then '2 - OLTP'
  5  when 4 then '4 - Query High'
  6  when 8 then '3 - Query Low'
  7  when 16 then '6 - Archive High'
  8  when 32 then '5 - Archive Low'
  9  END "Compression Type",
 10  count( distinct DBMS_ROWID.ROWID_BLOCK_NUMBER (ROWID, 'SMALLFILE')) blocks
 11  from vd.test_compress
 12  group by DBMS_COMPRESSION.GET_COMPRESSION_TYPE ('VD', 'TEST_COMPRESS', ROWID)
 13  order by 1;

Compression Type      BLOCKS
----------------- ----------
1 - No Compresson       2653
2 - OLTP                 700
3 - Query Low            232
4 - Query High            35
5 - Archive Low           35
6 - Archive High          21

6 rows selected.