пятница, 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 и порой выдающих желаемое за действительное. Верьте фактам и цифрам.