= Сообщение: 2221 из 8623 ========================================= RU.LINUX = От : Andrew Kant 2:469/83.1 08 Jun 15 14:40:38 Кому : Vova Uralsky 08 Jun 15 14:40:38 Тема : Среда для многократного тестирования FGHI : area://RU.LINUX?msgid=2:469/83.1+557584ad На : area://RU.LINUX?msgid=2:5030/257+5575918a = Кодировка сообщения определена как: CP866 ================================== Ответ: area://RU.LINUX?msgid=2:5030/257+5575b05f ============================================================================== Hello Vova!
Monday June 08 2015 12:40, Vova Uralsky wrote to Andrew Kant:
AK>> внесенным изменениям, то есть, грубо говоря, если меняли два часа, AK>> то и откатывать будет два часа (надо все изменения накатить со AK>> знаком
VU> К счастью это несовсем так, если один блок поменялся 100 раз, VU> восстанавливаться он будет только один раз. С чего ты взял, что один? Берутся все реду-логи с текущего момента до момента отката, и в обратном порядке накатываются. Представь себе, что ты вносил изменения неделю, сколько будет реду-логов? Вот столько надо их и перелопатить, чтоб вернуть всё взад. Понятно, что обработка реду-логов происходит быстрее, чем их генерация (не надо лишние селекты делать, вычисления итп - бери данные и пиши на диск), но все равно, время этого процесса не детерминировано, и может быть сколь угодно большим. Это я про вариант flashback database (откат на Point-in-time) говорю, остальные не решают поставленной задачи и могут дать только частичный откат.
VU> Если, правда, там делается VU> что-то вроде UPDATE tab1 SET col1=col1 WHERE 1=1 ; то -- да. С VU> бэкапа VU> подняться будет быстрее. Вот поэтому данный вариант сраз был отвергнут, как не удовлетворяющий условию "быстро".
VU> ОК, если бы я такое дома делал ;-), я бы сварганил "крутящиеся VU> зеркала". VU> Допустим, диск А у нас эталонный, а диски B и C являются зеркалами диска VU> A. При необходимости потестировать откалываем, допустим, копию C и VU> монтируем; пускаем оракела, тестируем, по окончании возвращаем в VU> зеркало. Если не сложилось и надо срочно тестировать снова, возвращаем C VU> в зеркало и вынимаем оттуда B. VU> Пока тестируем на B, С пересоздаётся. А третье тестирование? Ждем, пока зеркало синхронизировалось? А это по времени как раз соизмеримо с полным копированием. Можно, конечно, добавить D (а потом E итп), но тогда время подготовки эталона (первоначального) стремится к бесконечности :)
Так что только снэпшоты на уровне файловой системы: время создания нового снэпшота - секунды, пользуемся им, закончили тестирование - удаляем снэпшот, делаем новый. Можно, конечно, снэпшоты стораджа (на уровне железа), но это уже дороговато получается, да и управлять ими из скриптов неудобно.
