= Сообщение: 2257 из 8555 ========================================= RU.LINUX = От : Andrew Kant 2:469/83.1 11 Jun 15 16:24:46 Кому : Andrey Ostanovsky 11 Jun 15 16:24:46 Тема : Среда для многократного тестирования FGHI : area://RU.LINUX?msgid=2:469/83.1+55798df7 На : area://RU.LINUX?msgid=2:5030/1957+55796d23 = Кодировка сообщения определена как: CP866 ================================== ============================================================================== Hello Andrey!
Thursday June 11 2015 14:07, Andrey Ostanovsky wrote to Andrew Kant:
AO>>> mv /home/oracle /home/oracle.001 && mv /home/oracle.etalon1 AO>>> /home/oracle AK>> А что ты будешь делать в следующий раз? Тестирование AK>> _многократное_, а не два раза. Соответственно, эталон должен AK>> оставаться неизменным и на первый, и на второй, и на n+1 раз.
AO> Достаточно одного раза, чтобы проверить алгоритм, т.к. дальше проблема AO> перетекает в техническое русло: циферку в расширении .001 я ведь не зря AO> написал. :) Буквочку n+1 я тоже не зря написал, а ты все равно не понял, что твое решение немасштабируемо.
AO> С учетом времени копирования около 3 часов: за вечер-ночь AO> пяток копий подготовить можно. Если девелоперы собираются так AO> косячить ежедневно - то записать копирование в кроновый скрипт. Они не косячат, а что-то отлаживают. И, конечно, можно им сказать "один раз в сутки", но зачем, если есть вариант сделать эффективнее?
AK>>>> Копия, как я говорил, длится около часа. Итого: один цикл AK>>>> тестирования будет длиться не менее часа. Что есть много. AO>>> Вопрос в экономической эффективности. А то можно оракловому AO>>> клиенту в tnsnames.ini просто IP менять и гнать клиента на новый AO>>> сервер. AK>> Любое количество раз? Или всё-таки столько, сколько у тебя серверов AK>> заготовлено? Почему ты не хочешь посмотреть на два хода вперед и AK>> подумать, что будет когда все заготовленные заранее сервера AK>> закончатся?
AO> "Мы все умрем", и обойти эту точку - еще никому не удавалось. Речь идет AO> о гипотетическом решении, или об экономически оправданном? :)
Есественно об экономически оправданном. Более того, начиная тред я уже обрисовал это решение. Вот получил дополнительные варианты (хотя идея та-же - использовать не копии базы а снэпшоты файловой системы с базой, создание их намного эффективнее копирования). Получил также предложения, которые экономически нецелесообразны, так как требуют больших расходов (флэшбэк дб на уровне оракла). Если придумаешь принципиально новый вариант - буду рад послушать.
