= Сообщение: 2240 из 8555 ========================================= RU.LINUX = От : Andrew Kant 2:469/83.1 10 Jun 15 09:01:10 Кому : Andrey Ostanovsky 10 Jun 15 09:01:10 Тема : Среда для многократного тестирования FGHI : area://RU.LINUX?msgid=2:469/83.1+5577d688 На : area://RU.LINUX?msgid=2:5030/1957+5576e7ae = Кодировка сообщения определена как: CP866 ================================== Ответ: area://RU.LINUX?msgid=2:5030/1957+55796d23 ============================================================================== Hello Andrey!
Tuesday June 09 2015 16:13, Andrey Ostanovsky wrote to Andrew Kant:
AO>>> Hу, самое простое - поднять оракл из "холодного бэкапа". AO>>> Т.е., останавливаем оракл, делаем переименование каталогов с AO>>> данными и архив-логами, запускаем оракл. AK>> Ага, вот, наконец, ты начинаешь понимать меня. Hужно поднять оракл AK>> из бэкапа. Для этого нужно бэкап скопировать на место файлов AK>> оракла.
А что ты будешь делать в следующий раз? Тестирование _многократное_, а не два раза. Соответственно, эталон должен оставаться неизменным и на первый, и на второй, и на n+1 раз.
AK>> Копия, как я говорил, длится около часа. Итого: один цикл AK>> тестирования будет длиться не менее часа. Что есть много.
AO> Вопрос в экономической эффективности. А то можно оракловому клиенту в AO> tnsnames.ini просто IP менять и гнать клиента на новый сервер.
Любое количество раз? Или всё-таки столько, сколько у тебя серверов заготовлено? Почему ты не хочешь посмотреть на два хода вперед и подумать, что будет когда все заготовленные заранее сервера закончатся? А будет то-же, что я и говорил - нужно делать полную копию. То есть просто точка насыщения немного отодвинута - требование полной копии наступает не при 1-ом а при n-ом тестировании, но, во-первых, n-конечно, а во-вторых, время на подготовку n-копий также возрастает. И, как ты правильно заметил, возрастают требования к ресурсам - эти n копий надо где-то держать. То есть при заранее неопределенном количестве тестирований и довольно малом n смысл увеличивать n больше единицы теряется. А обеспечить его достаточно большим тоже невозможно - нужны ресурсы и большое время на подготовку. Соответственно данный вариант - тупик.
