Если армия поддата, это - НАТО виновато!
ОК, CIO Сбербанка может и не разбираться в устройстве бд. Но кем же надо быть, чтоб вот так подставляться и трубить о полной профнепригодности своих подчиненных а значит и себя самого?;)
Виктор Орловский написал 07.07.2012 00:44 +4
Процессинг (система называется Way4) работает на базе данных Oracle (11 версии) обслуживает 70 млн карт, около 15 млн онлайн транзакций в день.
Oracle пишет логи в онлайн журналы, которые затем автоматически (типа FIFO буфера) сбрасываются на диски. Таким образом, журналы никогда не переполняются. По какой - то причине (пока не понятно по какой) СУБД перестал удалять события из журналов. После чего не прошел один из checkpoint-ов в системе и она перестала отвечать на действия администратора. Систему перевели на резервный комплекс и запустили recovery базы. Recovery остановился посередине пути и не был завершен. После чего возобновили Recovery процедуру, но уже в полуручном режиме, убрав параллельную (многпроцессорную) обработку. Поэтому получилось долго (последовательная обработка recovery и большой объем данных в требующих "наката" в базу).
Причины, почему такое произошло с базой данных сейчас выясняем - для этого обрабатываем все системные логи - что достаточно трудоемко и не тривиально
Причину обязательно установим. Нам это крайне важно для устранения причин инцидента
из каментов к этому
Вообще конечно красота. В стране с ядреной кнопкой валят процессинг (самое дорогое что есть у девушки!) ведущего банка и на голубом глазу такое вещают.
Виктор Орловский написал 07.07.2012 00:44 +4
Процессинг (система называется Way4) работает на базе данных Oracle (11 версии) обслуживает 70 млн карт, около 15 млн онлайн транзакций в день.
Oracle пишет логи в онлайн журналы, которые затем автоматически (типа FIFO буфера) сбрасываются на диски. Таким образом, журналы никогда не переполняются. По какой - то причине (пока не понятно по какой) СУБД перестал удалять события из журналов. После чего не прошел один из checkpoint-ов в системе и она перестала отвечать на действия администратора. Систему перевели на резервный комплекс и запустили recovery базы. Recovery остановился посередине пути и не был завершен. После чего возобновили Recovery процедуру, но уже в полуручном режиме, убрав параллельную (многпроцессорную) обработку. Поэтому получилось долго (последовательная обработка recovery и большой объем данных в требующих "наката" в базу).
Причины, почему такое произошло с базой данных сейчас выясняем - для этого обрабатываем все системные логи - что достаточно трудоемко и не тривиально
Причину обязательно установим. Нам это крайне важно для устранения причин инцидента
из каментов к этому
Вообще конечно красота. В стране с ядреной кнопкой валят процессинг (самое дорогое что есть у девушки!) ведущего банка и на голубом глазу такое вещают.