IBH в базе Essbase

Редко, но можно столкнуться с проблемой появления некорректных (дефектных) заголовков блоков - invalid block headers (IBH), которая описывается в логе приложения Essbase примерно так:

[Wed May 16 22:51:58 2012]Local/AppName/Cube/admin@Native Directory/Error(1006068)

Недопустимый статус транзакции для блока. Для поиска и устранения проблемы воспользуйтесь служебными программами поиска и устранения IBH.

Причинами могут быть:

1. Какой-то сторонний процесс пытается получить доступ с блокировкой к файлам базы данных (куба) Essbase. Например, антивирус или ПО резервного копирования
2. Служба Essbase была остановлена во время извлечения данных или выполнения расчетов. Иными словами, некорректная остановка или "падение" базы данных
3. Проблемы с дисковой подсистемой сервера. Например, ошибки в работе RAID-массивов, bad blocks на накопителях информации
4. Закончилось место на диске
5. Сильная фрагментация диска
6. Сильная фрагментация базы данных (куба)
7. Использование Direct I/O 
8. Слишком маленький кэш данных куба
9. Подобные ошибки встречались в Essbase 6.х и 7.х
    

После проверки всех пунктов из списка выше для решения проблемы можно выполнить на проблемной базе данных (кубе) MaxL скрипт:

alter application 'AppName' disable connects;

alter system logout session on database 'AppName'.'Cube';

alter database 'AppName'.'Cube' validate data to local logfile 'f:\IBH.log';

alter database 'AppName'.'Cube' repair invalid_block_headers;

alter application 'AppName' enable connects;

Этот скрипт проверяет куб на наличие IBH и записывает найденные блоки в указанный лог-файл, а затем удаляет дефектные блоки из базы данных (куба).

Иногда после выполнения скрипта необходимо выполнить реструктуризацию куба, чтобы indeх файл был перестроен с учетом исправления IBH. В идеале - выгрузить данные из куба, очистить его и загрузить данные обратно.

UPD: Кроме того, имеет смысл иметь опцию в essbase.cfg:

IBHFIXTHRESHOLD AppName Cube 10

Эта команда говорит Essbase, что нужно проверять наличие IBH на кубе (это происходит и без указания опции в явном виде) и, в случае превышения порога 10% (пример), базу данных следует корректно остановить. Это сделано, с целью показать, что критическая масса IBH накоплена, и нужно что-то делать. Однако, в EPM 11 за работоспособность Essbase отвечает сервис OPMN, который регулярно пингует службу OLAP-сервера и может заставить запуститься приложение заново.

Наш соратник Евгений Расюк добавляет, и я его поддерживаю:

• Всегда нужно иметь бэкап с выгруженными данными в текст. Это хоть и долго, на гораздо надежнее простого копирования файлов куба - "это видимость бэкапа" - в таком случае все проблемы (например, IBH) будут также занесены в бэкап
• Нужно стараться проектировать модели таким образом, чтобы исключить кастом расчеты на агрегируемых уровнях