Евгений Ульянов

+1 к Алексей, проще с ant'а переезжать именно на gradle - сохраняется некоторая процедурность и свобода.

Но рассчитывайте, что придется достаточно хорошо въезжать, это потребует времени.

Если есть возможность изменить classpath при запуске приложения, то сохраните измененный класс в отдельный jar-ник и поставьте этот jar-ник в classpath'е до исходного (который вы передалали).

Загрузчик первым найдет ваш класс, загрузит его и уже не будет грузить исходный класс.

Покажите вывод команды dir в папке "poi-3.10-FINAL"

Мне кажется, что на таком рынке, как США, можно быть востребованным в любом стеке технологий (главное - растить из себя хорошего специалиста).

Год на обучение - может быть достаточно (для Junior как минимум), если позволит склад ума и характера - быстро схватывать, анализировать, понимать, докапываться до сути происходящего.

На вашем месте я бы больше смотрел в сторону Java или C#. Если будете быстро въезжать в Java - то попробуйте Scala.

Но главное - попробуйте приобрести живой опыт разработки (присоединитесь к какому-нибудь проекту на GitHub'е, или фриланс) - готовые проекты котируются куда выше, чем "разработка в академических целях".

Ну, если говорить о гипервизоре в моем понимании - то это хост, который имеет возможность запускать внутри себя процессы других хостов, управляя ресурсами, которые предоставляются этим хостам.

СХД - это ничто иное, как дисковое хранилище, не привязанное к определенному хосту - т.е. вы можете подключить к одному СХД множество потребителей (по Ethernet, тогда это NAS, или по Fibrechannel).

IMHO, главным преимуществом использовании СХД для гипервизора является HA - вы подключаете несколько гипервизоров (для простоты предположим, что гипервизор развернут на физическом сервере) к одному СХД; ваши виртуальные хосты лежат на СХД, т.е. доступ к виртуальным дискам есть у всех хостов. При падении одного хоста вы сможете очень быстро поднять все упавшие виртуальные машины на живом хосте.

Описанный вами случай не особо применим к СХД; если запускаемое ПО не требует инсталляции на каждом конкретном хосте (работает "из папки") - то вы можете положить его на обычный сетевой диск и дать доступ к нему нужным потребителям. Естественно встает вопрос рабочей папки, конкурентного обращения к файлам программы, etc.

Короче, с помощью СХД вы не сможете взять любое ПО и быстро превратить в SaaS :)

Про разделение системных ресурсов - все зависит от настроек гипервизора. Вы можете жестко фиксировать ресурсы за запущенным виртуальным хостом, можете выдавать по требованию.

Беглый гугл показал, что Control File создается вместе с базой. Почему он не создался - я бы посмотрел в права доступа на папки.

Вот тут - подробное описалово, как создать файл с нуля (если он поврежден и у вас не бэкапа) - docs.oracle.com/cd/B28359_01/server.111/b28310/con...

Если мне не изменяет память, Lockdown mode можно снять напрямую на хосте (воткнув в сервер монитор + клавиатуру).

Или это физически невозможно в вашем случае?

Подслушано у друга: "Если у вас есть проблема, которую вы хотите решить регулярными выражениями - у вас уже две проблемы".

Попробуйте вот так:

"qwertyqw".replace("qwe", "1").replace("ty", "2");

Запускал под VMware разнообразный зоопарк - все работало отлично, + было удобно все администрировать, настраивать HA и прочее.

У последней vSphere вроде как есть Applience для резервного копирования VM.

Вот здесь можно почитать: https://blogs.vmware.com/vsphere/2013/11/vdp-advanced-5-5-ga.html

А есть требования по отказоустойчивости, простою?

Если требуется 24х7, то либо создавать для каждой базы Standby, либо поднимать RAC. С RAC'ом, насколько я слышал (сам не реализовывал), бывает очень много странных танцев с бубном, но зато вы получите балансировку нагрузки + устойчивость к отказам (если приложение сможет работать с RAC, оперативно переключаясь на другую ноду).

По поводу хранения - если у вас не High-end СХД с хорошими вычислительными мощностями, то лучше собирайте 1+0; если случится авария на 5 или 6, то велик риск смерти еще одного диска в группе, пока на Hot spare будут восстанавливаться данные; скорее всего, 600 Gb винчестеры у вас SATA и около 7200 rpm, так что они будут очень медленные.

В любом случае, бэкапы стоит продумать, хотя бы редкие; даже имея хорошую СХД и RAID большой избыточности, вы не застрахованы от смерти контроллера.

А если автоматизировать на ночь заливку dump'а? В таком случае даже 5 часов не проблема - пусть себе спокойно переливает с production к developer'ам.

Или production ночью критичен для такой нагрузки?

При таком подходе все равно остается проблема разворачивания копии за давнее число, но тут уже больше в железо упирается... Bottleneck в дисках?

А насколько часто нужно эту операцию производить? Если для отказоустойчивости, то не думали в сторону Standby-базы в режиме Mirror к основной?

При этом все транзакции, совершаемые на основной базе, будут автоматически применяться на Standby; базу можно будет использовать для Read-only операций (к примеру, отчетность), и оперативно превратить в production, если возникнет необходимость.

Не работал с Partitions, так что по этой теме не возьмусь отвечать.

Однако, если проблемы именно с построением отчетности, и требуется ускорить именно отчеты за текущий месяц, возможно, стоит попробовать Materialized Views? Не думали в эту сторону?