Friday, November 2, 2012

Exadata features 11.2.2.4 and 11.2.3.2: smart flash logging and write-back smart flash cache

Несколько слов про фичи системы хранения Экзадаты:

- smart flash logging (11.2.2.4)
- write-back smart flash cache (11.2.3.2)

1. 
Возможность smart flash logging появилась в версии 11.2.2.4 (октябрь 2012) и разрешает записывать redo logs в flash cache. Смысл этой возможности - ускорить commit ( = уменьшить log file sync). По команде commit log buffer пишется на жесткие диски и в flash cache одновременно. Если дисковая система перегружена, то flash cache ответит быстрее и пользовательский процесс продолжит свою работу.
Под smart flash logging -опцию выделяется 512Мб флеш кеша на каждом storage cell.
В результате smart flash logging возрастает износ flash-памяти.
Standby redo логи также покрываются этой технологией.

Для полноты картины надо сказать, что поверх физических дисков в каждом storage cell стоит RAID-контроллер с 512Мб кеш-памяти, защищенной батарейкой, поэтому запись на физические диски фактически означает запись кеш RAID-контроллера, т.е. по-идее должна выполняться достаточно быстро..
 
Эта возможность включается автоматически при создании специального объекта flashlog:

CREATE FLASHLOG [ALL [FLASHDISK]] [attribute=value] [,attribute=value] ...
Examples:
CREATE FLASHLOG ALL
CREATE FLASHLOG ALL SIZE=1G
CREATE FLASHLOG CELLDISK='fd1,fd2'
CREATE FLASHLOG CELLDISK='fd1,fd2' SIZE=1G

Отключается она удалением flashlof: "drop flashlog all".

Посмотреть параметры этого объекта можно командой list flashlog detail:

CellCLI> list flashlog detail
         name:                   bip1cel01_FLASHLOG
         cellDisk:               FD_06_bip1cel01,FD_14_bip1cel01,FD_07_bip1cel01,FD_15_bip1cel01,FD_03_bip1cel01,FD_01_bip1cel01,FD_04_bip1cel01,FD_13_bip1cel01,FD_10_bip1cel01,FD_00_bip1cel01,FD_12_bip1cel01,FD_09_bip1cel01,FD_05_bip1cel01,FD_11_bip1cel01,FD_08_bip1cel01,FD_02_bip1cel01
         creationTime:           2012-08-08T13:04:26+02:00
         degradedCelldisks:
         effectiveSize:          512M
         efficiency:             100.0
         id:                     dec8c793-bf95-4d41-978b-f8712e383282
         size:                   512M
         status:                 normal


Итак, что мы видим: FLASHLOG - это специальный объект в FC, под который отводися по 32Мб из каждого флеш диска, что составляет по 512Мб на сервер хранения.

Статистики эффективности этого объекта описаны в документации "Exadata Storage Server Software User's Guide", "7 Monitoring and Tuning Oracle Exadata Storage Server Software", "Monitoring Flash Log with Metrics" :
 


Table 7-4 Flash Log Metrics and Descriptions
Metric Description
FL_ACTUAL_OUTLIERS This metric shows the number of redo writes written to flash and disk that exceeded the outlier threshold.
FL_BY_KEEP This metric shows the number of redo data bytes saved on flash due to disk I/O errors.
FL_DISK_FIRST This metric shows the number of redo writes first written to disk.
FL_DISK_IO_ERRS This metric shows the number of disk I/O errors encountered by Flash Log.
FL_EFFICIENCY_PERCENTAGE This metric shows the efficiency of Flash Log expressed as a percentage.
FL_EFFICIENCY_PERCENTAGE_HOUR This metric shows the efficiency of Flash Log over the past hour expressed as a percentage.
FL_FLASH_FIRST This metric shows the number of redo writes first written to flash.
FL_FLASH_IO_ERRS This metric shows the number of flash I/O errors encountered by Flash Log.
FL_FLASH_ONLY_OUTLIERS This metric shows the number of redo writes written to flash that exceeded the outlier threshold.
FL_IO_DB_BY_W This metric shows the number of megabytes written to hard disk by Flash Log.
FL_IO_DB_BY_W_SEC This metric shows the number of megabytes written per second were written to hard disk by Flash Log.
FL_IO_FL_BY_W This metric shows the number of megabytes written to flash by Flash Log.
FL_IO_FL_BY_W_SEC This metric shows the number of megabytes written per second were written to flash by Flash Log.
FL_IO_W This metric shows the number of writes serviced by Flash Log.
FL_IO_W_SKIP_BUSY This metric shows the number of redo writes that could not be serviced by Flash Log because too much data had not yet been written to disk.
FL_IO_W_SKIP_BUSY_MIN This metric shows the number of redo writes during the last minute that could not be serviced by Flash Log because too much data had not yet been written to disk.
FL_IO_W_SKIP_LARGE This metric shows the number of large redo writes that could not be serviced by Flash Log because the size of the data was larger than the amount of available space on any flash disk.
FL_PREVENTED_OUTLIERS This metric shows the number of redo writes written to disk that exceeded the outlier threshold. These writes would have been outliers if not for Flash Log.

Пример с продуктива:

CellCLI> list metriccurrent where objectType='FLASHLOG'
         FL_ACTUAL_OUTLIERS              FLASHLOG        0 IO requests
         FL_BY_KEEP                      FLASHLOG        0
         FL_DISK_FIRST                   FLASHLOG        45,809,503 IO requests
         FL_DISK_IO_ERRS                 FLASHLOG        0 IO requests
         FL_EFFICIENCY_PERCENTAGE        FLASHLOG        100 %
         FL_EFFICIENCY_PERCENTAGE_HOUR   FLASHLOG        100 %
         FL_FLASH_FIRST                  FLASHLOG        2,127,006 IO requests
         FL_FLASH_IO_ERRS                FLASHLOG        0 IO requests
         FL_FLASH_ONLY_OUTLIERS          FLASHLOG        5 IO requests
         FL_IO_DB_BY_W                   FLASHLOG        5,057,869 MB
         FL_IO_DB_BY_W_SEC               FLASHLOG        0.000 MB/sec
         FL_IO_FL_BY_W                   FLASHLOG        5,177,941 MB
         FL_IO_FL_BY_W_SEC               FLASHLOG        0.002 MB/sec
         FL_IO_W                         FLASHLOG        47,936,509 IO requests
         FL_IO_W_SKIP_BUSY               FLASHLOG        0 IO requests
         FL_IO_W_SKIP_BUSY_MIN           FLASHLOG        0.0 IO/sec
         FL_IO_W_SKIP_LARGE              FLASHLOG        0 IO requests
         FL_PREVENTED_OUTLIERS           FLASHLOG        17,693 IO requests



Важное значение имеют метрики, точнее их отношение:  
FL_IO_W - всего операций записи,
FL_DISK_FIRST - первым возвратил ответ диск и
FL_FLASH_FIRST - первым возвратил ответ flashlog.

Под OUTLIERS подразумеваются операции log file sync которые выполнялись более 500мс.   

2.
Вторая возможность - это write-back smart flash cache доступна начиная с версии 11.2.3.2. Он не имеет никакого отношения к smart flash logging.
 
В версии до 11.2.3.2 при поступлении команды на запись cellsrv выполняет запись на жесткие диски (а фактически, в 512Мб кеш RAID-контроллера) и затем решает - кешировать или нет эти данные в flash cache (записывать их в flash cache или нет). Таким образом, если блок может кэшироваться в flash cache, то сервер БД ждёт подтверждения от диска. Если дисковая система в данные момент занята, то сервер БД ждет ее освободждения.
Возможность write-back smart flash cache означает выполнение записи в кеш RAID-контроллера и в flash cache одновременно. Если дисковая система перегружена, то flash cache ответит быстрее.
Подчеркну еще раз (как я сам понимаю) - ВСЕ операции записи теперь вначале записываются в FC, и только потом (при необходимости) в фоновом порядке переносятся на диск!
 
В результате такой политики записи: 
- данные которые необходимо кешировать в flash cache уже находятся в нем. бесполезные данные будут перезаписаны в следующем цикле перезаписи.
- возрастает потребление и износ flash cache.
- потребление flash cache возрастает при операциях DML по причине зеркалирования в ASM. Т.е. модифицированные блоки будут кешированы в ДВУХ или ТРЕХ серверах хранения. Блоки, которые кешированы по причине SELECT (прочитанные с диска) - будут кешированы только в ОДНОМ сервере хранения (primary копия заркала), до тех пор, пока они не будут модифицированы.
 
Появление версии 11.2.3.2 совпало с выходом Экзадаты Х3-2. Т.е. 11.2.3.2 - минимальная версия для Х3-2, которая не ней доступна. А в Х3-2 Оракл в 4 раза увеличил размер flash cache который к тому же стал на 40% быстрее. Также в версии 11.2.3.2 появилось важное изменение - данные записанные в flash cache сохраняются в нем после перезагрузки сервера (persistent FC). Технология изменилась с SLC на MLC.

 

2 comments:

  1. Не совсем понятно, кто же кого ждет,
    тем более что у F20-карточки тоже есть кеш в 256МБ (по 64МБ на каждый FMOD).

    А насчет того, что в Х3-2 flash cache стал на 40% быстрее - наверное, не стоит повторять то, что впаривает маркетинг Oracle :)

    ReplyDelete
  2. Статья полезная, однако есть две существенных ошибки:
    1. Область для flashlogs НЕ является частью FC. FC и flashlog area - две отдельные не пересекающиеся области во флэш-памяти.
    2. Запись блоков “в 512M кеш RAID-контроллера” без записи на диск невозможна ввиду отсутствия такой команды в операционной системе. Этот кеш используется только аппаратно при команде IO для диска.

    Замечание про write-back FC:
    К сожалению, Oracle не опубликовал алгоритма сохранения на диски модифицированных блоков controlfiles и data files, находящихся в FC. Этот алгоритм очень важен ввиду того, что флэш-память гораздо менее надёжна, чем дисковая. Скорее всего, при записи во FC используется стратегия “двойного огня”, о которой упоминал Кевин Клоссон. То есть, одновременно выдаются команды записи во FC и на диск, только подтверждение на сервер БД всегда выдаётся после завершения записи во FC, а не по первому дошедшему до цели, как это сделано во flashlog.

    ReplyDelete

Note: Only a member of this blog may post a comment.

Does DEALLOCATE UNUSED or SHRINK SPACE will free space occupied by LOB segment?

Lets check how it works. My env is DB 19.20@Linux-x64 1) I created the table with 4 LOB columns of 4 different LOB types: BASICFILE BLOB, BA...