Настройка/удаление схемы Oracle для построения CI без фрагментации каталога

Я хотел бы, чтобы сборка CI (например, Hudson) устанавливала и демонтировала схему Oracle 11g как часть ночного цикла сборки/тестирования для довольно ванильного приложения JSF/JPA.

Самый очевидный способ сделать это — удалить и заново создать все таблицы. Хотя это выглядит довольно стандартно (по крайней мере, это то, что инструменты Hibernate/JPA сделают автоматически для вас), администраторы баз данных Oracle предупреждали меня, что каталог Oracle будет фрагментирован после повторяющихся циклов создания/удаления объектов. В конце концов это вызовет проблемы с производительностью, потому что табличное пространство SYSTEM не может быть дефрагментировано/объединено.

Мои вопросы:

  • действительно ли фрагментация вызывает беспокойство, или вам не о чем беспокоиться в типичной среде разработки веб-приложений?
  • если фрагментация действительно вызывает беспокойство, есть ли лучший способ снести и воссоздать схему в Oracle, чем DROP TABLE/CREATE TABLE?

Спасибо!


continuous-integration hibernate oracle jpa
person wrschneider    schedule 29.11.2011    source источник

Ответы (2)


arrow_upward
7
arrow_downward

Не верьте этим администраторам баз данных

По крайней мере, с 10g и выше при использовании локально управляемых табличных пространств (LMT) это не должно быть проблемой.

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

person a_horse_with_no_name    schedule 29.11.2011
comment
LMT сами по себе должны устранить любую проблему, связанную с фрагментацией, предполагая, что табличное пространство SYSTEM управляется локально. Для меня не очевидно, что ASM что-то добавляет. И ASM, как правило, является гораздо более спорной технологией с политической и технической точек зрения, так как все дело в том, чтобы позволить администраторам баз данных выполнять больше задач по управлению хранением, что означает передачу этой ответственности группам, которые делают это сегодня. LMT, с другой стороны, являются явно превосходной заменой старых табличных пространств, управляемых словарем (DMT). - person Justin Cave; 30.11.2011
comment
@JustinCave: спасибо за подсказку. Я удалил комментарий о ASM (в любом случае, не был уверен) - person a_horse_with_no_name; 30.11.2011

arrow_upward
2
arrow_downward

Я нахожусь в процессе внедрения процесса сборки CI для своего второго проекта Oracle. Я не думаю, что удаление и воссоздание всего нанесет какой-либо вред (как указано выше a_horse_with_no_name). Я рад слышать, что вы думаете о расширении CI на объекты базы данных — слишком многие команды этого не делают.

Другой подход может состоять в том, чтобы восстанавливать базу данных из последней резервной копии каждую ночь (или использовать базу данных ретроспективной копии) и переносить ваше приложение из «производственной резервной копии» в текущее состояние разработки при каждом запуске CI. Таким образом, код, который в конечном итоге будет применяться в рабочей среде, будет каждую ночь тестироваться на чем-то, что в значительной степени идентично рабочей среде. Это небольшое изменение в мышлении, но не слишком большое, если вы уже думаете о CI.

Если вы хотите попробовать миграционный подход, у меня есть инструмент, над которым я работаю, который может помочь: http://dbgeni.com Он все еще находится в стадии разработки, но я разработал его с учетом непрерывной интеграции и управления изменениями базы данных с учетом миграций.

person Stephen ODonnell    schedule 29.11.2011