пятница, 7 октября 2011 г.

Smart Cache для пессимистов



В своем сообщении о Smart Flash Cache я уже писал, что в подавляющем большинстве случаев Вам нет необходимости создавать на флэш-картах дисковые группы для размещения на них редо-логов.  Всё объяснялось достаточно просто – запись на дисковую подсистему происходит гораздо быстрее, чем во флэш-память за счет динамической памяти выполняющей для контролера роль обычного дискового кэша.
Правила, которые пока подтверждались на нагрузочных тестах. Вот, например, тест банковской OLTP на X2-8.  Суммарные показатели с двух узлов:

  • Avg log file parallel write:  0.75ms
  • physical read total IO requests/sec:  7,037.32
  • physical write total IO requests/sec:  6,212.48
  • Total I/O requests/sec: 13,249.80

13.2K IOPS - не бог весть, какая нагрузка для Exadata DBM, способной обработать до 1.5M IOPS, т.е. в 100 раз больше. Но это нагрузка реального приложения в пиковый момент, способная “согнуть в дугу” даже High End дисковые массивы.  

Конечно, у каждого правила есть исключения. Если их не видел на практике, то завсегда можно домыслить J По крайней мере мне часто задают вопрос, а что будет, если 512MB кэш динамической памяти контроллера переполнится из-за интенсивной прокачки данных. Вполне допускаю такой вариант, например, когда помимо OLTP нагрузки происходит интенсивное последовательное чтение. Хотя … хотелось бы всё же увидеть.

В общем, даже для пессимистов, которые могут не доверять вышеприведенным данным, в новой версии Exadata Storage Software 11.2.2.4.0 появилась возможность Smart Flash Log.
Ячейка Exadata умная, а потому умеет идентифицировать операции по записи редо.  Попросту с сих пор в Smart Flash Cache выделается некая область, которая содержит последние записи Redo Log.  Это не значит, что запись Redo теперь ведется только туда – нет, принципы не поменялись. Это страховка.  Запись Redo ведется параллельно в Flash Cache и на диск. Смысл?  - Куда быстрее запишет. Сразу после этого ответ об успехе возвращается процессу LGWR.

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

Надёжность данных в флэш? - Просто! В связи с тем, что ASM обеспечивает избыточность, то любая запись в redo будет параллельно производится в 2 или 3 ячейки. Т.е. сохранность записи в флэ-кэш будет обеспечиваться стандартными механизмами Oracle.
Однако, на текущий момент есть одна непонятность  -   в одних источниках сказано, что эта фича активизирована по умолчанию, а в другие требуют ручной активизации на ячейке.

P.S. Не доверяйте теоретикам, никогда не работавших с реальной Exadata и порой выдающих желаемое за действительное. Верьте фактам и цифрам.

четверг, 30 июня 2011 г.

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

суббота, 23 апреля 2011 г.

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

Многие многоопытные администраторы баз данных 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 со временем, которое необходимо для обращения к ней же с внешнего сервера БД. Огромная разница в латентности при практически совпадающем функционале.

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

воскресенье, 27 марта 2011 г.

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.