Total Recall или Вспомнить всё! (Часть 1)

Вы удивитесь, но речь пойдет не о фильме Пола Верховина с Арнольдом Шварценеггером в главной роли. Она пойдет о новой опции в версии Oracle Database 11g - Oracle Total Recall. Хотя, безусловно, какое-то отношение к триллерам и фантастике это решение имеет. Все мы помним, как хакеры в этих фильмах легко проникают в базу данных полиции и изменяют данные добропорядочного гражданина, делая его в один момент преступником - рецидивистом. Последнее время, когда все больше и больше персональных данных граждан находится в электронном доступе, вопрос отслеживания таких изменений встал очень остро. В мире были приняты ряд законов и актов требующих длительного (более 5 лет) хранения и аудита подобных данных и всех их изменений. Причем это касается не только больших корпораций аля страховые или медицинские, но и малый, и средний бизнес.

Я сразу вспоминаю случай из собственной практики, когда изучив логику бизнес-приложения, нерадивые сотрудники одной фирмы легко перебрасывали продажи (уже после их завершения) с одного покупателя на другого, изменяя, таким образом, задолженности этих клиентов перед фирмой. Этот "переброс" ничему в принципе не противоречил и допускался системой - ну решил клиент оформить все на другое юр.лицо, но никак не отслеживался. Когда мы предложили разработчикам системы начать отслеживать подобные операции, они разумно ответили, что "на каждый роток не накинешь платок" - и что нельзя программировать исходя из предположения, что люди начнут воровать. Самым логичным в той ситуации казалось просто поставить триггер на изменения нужных полей одной таблицы. Это один из вариантов в данном случае, но он лишен возможности централизованного управления - вы должны помнить, где у вас стоят триггера, чего и куда пишут. Да и наличие большого их количества сказывается на производительности. Другой вариант решения проблем с отслеживанием изменения данных - написание соответствующей функциональности со своим интерфейсом, своими таблицами и т.п. Но это сильно удорожает разработку любой системы - это раз. Доступ к таблицам изменения данных мы контролировать не можем - администратор системы может их легко изменить - это два. Да и если у вас в организации несколько баз и десятки приложений, то все это начнет рано или поздно вас утомлять - это три. Третий вариант, решения сторонних разработчиков для анализа REDO логов позволяет нам загрузить измененные данные в какую-нибудь отдельную базу данных, но мы лишаемся возможности работать с текущими данными, делать запросы, отслеживая изменения. Короче, ни один из способов в сумме не дает нам ни безопасности хранения данных, ни легкости их извлечения при этом существенно сказываясь на производительности системы.

Новая функция FLASHBACK DATA ARCHIVE входящая в опцию Oracle Total Recall позволяет преодолеть почти все эти ограничения.

Продолжение следует...

Не гонялся бы ты поп за дешевизною! (С)

Я иногда поигрываю в онлайн-игры. Ногами не бить!

И тут недавно у Sony Online Entertainment (SOE) и у представляемой фирмой Акелла русской версии игры Everquest2 начались проблемы. Невозможно играть, то персонажи пропадают, то зониться между локациями нельзя. Короче кошмар. Официальные представители ответили что-то невнятное.

«В общем, причину обнаружили - одна из основных баз данных при большом количестве игроков онлайн стала вставать "раком", при этом критичная загрузка от обычной отличается в 7-10 раз, т.е. создается ряд запросов, которые по каким-то причинам сразу не обрабатываются и пиковые моментальные нагрузки приводят к длительным лагам. В прайм-тайм это становится очевидно заметно. Сейчас инженеры SOE, которые занимаются поддержкой баз данных, пытаются решить этот вопрос. Сроки его решения я точно сказать не могу, но, надеюсь, что это произойдет в ближайшее время. Мы приносим свои извинения за временные неудобства и стараемся как можно быстрее решить этот вопрос.»
Источник: http://forums.akella-online.ru/showthread.php?t=20211

И тут на одном из компьютерных форумов, я наткнулся на чью-то реплику, мол SOE пожалело денег и мигрировало с Оракла на какую-то дешевку и теперь пожинает плоды этого. Я конечно же не поверил. Потому что, уж слишком безумным казалось мне портировать игру с одной базы данных на другую, когда она уже во всю в продакшене. Да и в менеджменте SOE тоже казалось сидят люди не глупые. Но оказалось, что это правда. Я нашел этот документ, крайне забавный. Они решили перейти на EnterpriseDB и сэкономить порядка 80% денежек. Причем так как эта база «Oracle compatible», то мол особо переписывать ничего не придется.

Ознакомиться с этим чудесными Case Study можно тут:
http://www.ameritas.co.uk/Documents/EnterpriseDB_Sony_Casestudy.pdf

В общем, не гонялся бы ты поп за дешевизною…