ORA-00439: feature not enabled: Server Flash Cache

Порекомендовал я на одной БД воспользоваться преимуществами флеш кеша.
http://docs.oracle.com/cd/E11882_01/server.112/e25494/memory005.htm#BABHEDBH

Заказчик купил карточку, задал параметры

db_flash_cache_file=/ssd/flashfile.dbf
db_flash_cache_size=36g
И перестартовал БД.  В результате получилось:

ORA-00439: feature not enabled: Server Flash Cache

Оказывается - баг:  Bug 12949806 - FLASH CACHE CHECK IS AGAINST ENTERPRISE-RELEASE  !
Сейчас против этого бага Оракл предлагает патч 12949806.
Окончательно бещают исправить в 11.2.0.4.

 

{[ERROR] Need at least 4363 MB free space on cell. Found only 3961 MB.

I decided to patch our 1/4 Exadata and have run prerequisits:

# patchmgr -cells cell_group -patch_check_prereq

and have got the result in all cells:

ed01cel03: [ERROR] Need at least 4363 MB free space on cell. Found only 3961 MB.

The disk examination on the cell shows :
 [root@ed01cel02 ~]# df -h

Filesystem Size Used Avail Use% Mounted on

/dev/md5   9.9G 5.6G  3.8G   59%   /
- OS Watcher 729Мб, /opt/oracle.oswatcher/osw/archive

- the one big file in strange place, I suppose I should remove this file and all the directory _patch_hctap_:
[root@ed01cel01 _p_]# pwd
/root/_patch_hctap_/_p_

[root@ed01cel01 _p_]# ls -l

total 1241168

-rw-r--r-- 1 root root 1267945472 Aug 1 10:20 11.2.3.1.1.120607.iso

 

Looking for solution I found interesting lines in patchmgr utility:

-cleanup
Clean up all patch files and temporary content on all cells.
If this step can be done manually if patch fails by removing
directory /root/_patch_hctap_ on each cell.

O, my mistake ! I forgot to run:   ./patchmgr -cells cell_group -cleanup

before      # patchmgr -cells cell_group -patch_check_prereq

 

In patchmgr I found other similar messages:

 

- [ERROR] Patch or rollback failed. Please run cleanup before retrying.

- Only if the cleanup fails from prior launch point, use -reset_force instead of -cleanup and then retry.

 

The summary: Don't forgot to run ./patchmgr  -cleanup !

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.