Крах хранилища данных КУГИ

Привет.

Как я уже говорил ранее, я работаю над проектом автоматизации деятельности КУГИ Санкт-Петербурга. И основное направление этой деятельности - управление городской собственностью. Задач много, и все их перечислять сейчас нет никакой необходимости.
А конкретно сегодня мне хотелось остановиться на событии, которое произошло еще в начале марта... Числа эдак 2 или 3.
Событие это можно было обозначить одним емким словом, которое в переводе с русского на русский означает

"полное прекращение какой-либо полезной деятельности".

Субъектов деятельности был сервер хранилища данных КУГИ.
Остановлюсь на этом понятии подробнее.
КУГИ, как орган государственной власти, подчиняется вышестоящим властным структурам. А как реализуются функции управления???? ВЕРНО. По-разному. Но один из способов - периодический контроль деятельности подчиненных, основанный на предоставлении отчетов о деятельности.
Для получения такой отчетности наша проектная группа разработала и внедрила в КУГИ Хранилище данных.
Принцип его формирования виден на рисунке.

Что можно понять из этого наскального рисунка? Автор вложил следующий смысл.

1. Имеем несколько оперативных баз данных. С ними работают пользователи и регистрируют в них результаты своей повседневной деятельности.
2. Наша задача заключается в том, чтобы сведения об этих результатах были превращены в отчеты о деятельности. При этом эти отчеты должны быть:

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

Этого можно добиться, если информацию их оперативных баз данных перенести в нужный момент времени в отчетную базу и сохранять там эту информацию без изменения.

Так мы ввели понятие "СРЕЗ".

Срез - это обработанная процедурами ETL(extract, transform, load) и загруженная в хранилище данных информация из оперативных баз данных. В последствии информация среза не модифицируется и сохраняется в неизменном виде. Эта информация будет отражать состояние дел на момент в области управления имуществом на момент ее обработки и загрузки. Если в последствии для формирования того или иного отчета мы будем использовать "срез" к примеру от 01.04.2009, то получим согласованные данные на эту дату. И сколько раз бы мы не запускали один и тот же отчет для одного и того же среза  в разное время, мы всегда будем получать одинаковые данные.

Для построения хранилища мы используем Oracle WareHouse Builder. Это средство позволяет проектировать хранилище и процедуры преобразования данных из источников в целевую базу данных. Подробнее см. здесь www.oracle.com/global/ru/solutions/business_intelligence/dw_home.html Как показано на рисунке, процедуры ETL очищают данные, согласуют их между собой (оперативных баз-то много) и переносят в целевую базу или хранилище данных.
Вся эта кухня успешно функционировала с 2008 года. Пока не случился физический крах сервера хранилища.
Знающий человек скажет, ну и что... Должен быть backup, можно восстановиться на момент падения и т.п.
ВСЕ ВЕРНО, но ... вообще дело было так.

Хронология событий..
1. Объема своего дискового массива на сервере для хранения срезов стало не хватать.
2.  Системные админы КУГИ (которые должны обеспечивать эксплуатацию оборудования и серверного хозяйства) подключили сервер к внешнему дисковому массиву и выделили для хранилища на внешнем массиве какой-то раздел (гигов 300- 400).
3. Базовый админ КУГИ добавил в TBS еще пару datafiles, которые расположил на внешнем массиве.
4. В эти файлы началась писаться какая-то информация процедурами ETL при снятии срезов.
5. Пользователи счастливы..
<skipped>
6. Системный админ перегружает внешний массив, забыв что у него есть новый потребитель в виде сервера базы данных храналища.
7. Сервер Oracle хранилища начинает ругаться в alert_log, что произошел error операционной системы и два datafiles не доступны для чтения. И, как следствие, переводит из в OFFLINE.
8. У базового админа много дел и в alert_log он не смотрит...
9. Пользователи уже сдали свои годовые отчеты, хранилище до середины марта им не нужно и они счастливы.
10. Не установленный следствием "нехороший человек" удаляет все архивные логи, за период 3 недель, которые необходимы для восстановления двух переведенных в offline файлов.
<skipped> проходит 3 недели
11. Первое обращение в системе отчетности выявляет проблему. Один TBS, в котором хранятся срезы по финансовой тематике, содержит offline файлы данных.
12. Пользователи перестают быть счастливы.
13. Админы перестают быть счастливы.
14. "Нехороший человек" затаился...
 

Всех "спасло" только следующее:
1. Наша проектная группа не стала впадать в отчаянье.
2. Мы понимали, что datafiles, которые переведены в OFFLINE, на самом деле содержат хорошие и согласованные данные, т.к. записи в эти файлы до падения не производилось в течении двух недель (слои никто не формировал).
3. Надо было объяснить нашу позицию из п.2 серверу ORACLE, который упорно считал, что данные NEED RECOVERY. Его мнение основывалось на SCN, которые у двух файлов отличались от всех остальных.
Покопавшись в инете мы нашли структуру DATFILES и определили, где надо изменить байты, поправив SCN.

15. После тайных манипуляций и корректировки файлов СЛУЧИЛОСЬ ЧУДО - база открылась. За чудо СПАСИБО нашему сотруднику.
16. Мы сопоставили ряд отчетов, получаемых из восстановленного хранилища с бумажными копиями, сохранившимися у пользователей. Результаты совпадали.
17. Пользователи счастливы.
18. Админы счастливы.
19. "Нехороший человек" затаился.
20. Ждем выводы по п.6.и 8.

Желаю всем удачи, не желаю попадать в подобные ситуации, надеюсь, что со временем мне доведется исправить п. 20 хронологии событий и описать принятые меры, которые позволили бы исключить подобные стрессы из нашей жизни.