su.dbms.sql

 
 - SU.DBMS.SQL ------------------------------------------------------------------
 From : Lilya A. Kozlenko                    2:5025/17      07 Mar 2001  12:32:19
 To : All
 Subject : Re: безопасность превыше всего?
 -------------------------------------------------------------------------------- 
 

 
 <dontsov@home.com> wrote in message news:9842qv$101v$1@ddt.demos.su...
 
 > Можно и третий резервный сервер поставить.
 > У нас венец паранои - сервер, задублированнный Vinca CoStandbyServer
 > (на бинарном уровне переписывающий RAID volume на второй комп),
 > реал-тайм же репликация на третий сервер, и каждые шесть часов -
 > backup третьего сервера на dumps файл-сервер в другом здании,
 > с зипованием и хранением оных за последние несколько дней.
 > За год было 15 секунд простоя.
 
 Если задача действительно критична к отклику равному 15 секунд,
 тогда такое решение оправдано, если же нет, то вероятно это лишнее.
 Real-time тоже бывает разный, если он жесткий и последствия простоя
 катастрофические, то ичего не поделаешь, придется платить эту цену.
 
 У меня сейчас хранятся 2 копии дампа за последние 3 дня. В принципе,
 по хорошему история более длинная нужна, но здесь вопрос решается
 тем, что мы храним пришедшие к нам дампы несколько месяцев. Hу а
 собственная система контроля версий базы данных (аналог cvs-а по
 функциям, по реализации - cvs + административная схема + набор
 информации о проектах) в состоянии выдать стартовую схему на любую
 фиксированную метку времени (точно так, как это cvs умеет). Так что здесь
 вопросы контроля процесса разработки схемы в некотором виде решены.
 Поэтому мне 3-х последовательных дампов и хватает. Что же касается
 прецедентов, то самым тяжелым случаем был просой в течение 2-х часов
 основного сервера, и то на резервном все нужное развернули за пол часа,
 когда сильно сбойнула оракловая база. От отказов никто не застрахован.
 Что касается модификации изменений, то у нас в проекте сделана система
 журналирования. И никакие данные вобщем-то не удаляются пользователем,
 просто их версии уходят в журнал, и всякая модификация любого объекта
 также порождает версию. Поэтому вредитель в данном случае конечно может
 сделать нехорошее дело, только напрямую в журнале покопаться у него прав
 нет само собой, а какие процедуры откуда стартуют - ну покопаться никто
 не запрещает (а там аудит из-за угла и ... это самое ... :) ).
 
 --
  Regards, Lilya Kozlenko
 --- Microsoft Outlook Express 5.50.4522.1200
  * Origin: RELEX Inc. (2:5025/17@fidonet)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор