Ускорение интеграционных тестов, основанных на базе данных Oracle

Question

У нас есть сервер базы данных Oracle, специально предназначенный для наших модульных тестов. Есть ли способ настроить Oracle специально для такого рода целей? Поскольку данные постоянно выбрасываются (так как это просто тестовые данные). Интересно, есть ли способ разместить базу данных Oracle в памяти и подключиться без стека TCP / IP, чтобы ускорить эти тесты?

Есть предложения?

Answer 1

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

Answer 2

Если зависание является этапом очистки / сброса базы данных, и у вас Enterprise Edition, посмотрите на FLASHBACK DATABASE как (потенциально) более быстрый способ сброса базы данных до фиксированной точки.

В худшем случае вам не нужно тратить время на создание сценариев очистки / сброса.

Answer 3

Стек TCP / IP вряд ли сильно увеличит ваши накладные расходы. Однако вы можете запустить экземпляр Oracle на том же сервере, что и ваши тестовые примеры, и получить доступ через ORACLE_SID (который, я считаю, использует межпроцессное взаимодействие на уровне ОС).

Однако, прежде чем рассматривать изменения в Oracle, я посмотрю, какие тесты запускаются на вашем сервере непрерывной интеграции. Если вы этого еще не сделали, это означает разделение интеграционных тестов (для которых требуется серверная часть) и модульных тестов (которые не требуются) и запуск их по разным графикам. Редко есть причина запускать полный набор интеграционных тестов для каждого изменения.

Далее: вы используете какой-либо объектно-реляционный картограф для доступа к вашей базе данных? Если да, и вы не полагаетесь на какие-то специфические особенности Oracle, вы можете заменить Oracle базой данных в памяти (вы не говорите, какой язык используете, так что это может или не может быть вариантом).

И, наконец, рассмотрите возможность использования средства импорта / экспорта Oracle для полной перестройки базы данных при каждом запуске интеграционного теста. Вероятно, это быстрее и определенно более стабильно, чем попытка удалить все созданные вами строки (это предполагает, что ваши интеграционные тесты начинаются с предварительно заполненных данных; если нет, просто удалите и пересоберите схему).

Answer 4

Я столкнулся с аналогичной проблемой и смог ускорить юнит-тесты, перенеся табличное пространство журналов повторов, отмены и пользователей на RAM-диск. Вы можете попробовать бесплатную версию программного обеспечения ramdisk. Коммерческие версии , которые периодически создают резервные копии файлов, также очень дешевы.
В моем случае модульные тесты только проверяют целостность данных, и, следовательно, эта стратегия имеет низкий уровень риска, даже если она не повторяет настройки производства. У нас есть отдельная шкала и стратегия испытаний производительности.

Answer 5

Есть много вещей, которые вы можете сделать с экземпляром Oracle для сценария, о котором вы упомянули, например, использование правильной стратегии блокировки / уровня изоляции, отключение всех видов отмененных журналов и т. Д. Вам следует обратиться к хорошей книге по настройке Oracle для это (мне нравится тот, который написал Марк Гарри, но я не уверен, насколько он актуален).

Есть еще одна вещь, которая может быть важна: если вы постоянно добавляете и удаляете данные из вашей базы данных (я имею в виду «полностью очистить базу данных»), убедитесь, что вы правильно настраиваете параметр хранения для каждой таблицы. Если у вас есть свободное место, рассмотрите возможность назначения начального экстента, равного максимальному размеру для ваших тестовых случаев. (Либо в сценарии создания базы данных, либо определите один раз, а затем просто переведите таблицы с опцией повторного использования хранилища.) Затем при запуске тестовых примеров базе данных не нужно выделять дополнительное пространство для хранения.

Answer 6

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

   ALTER INDEX index_name REBUILD

Перестроит индексы без их удаления и повторного создания..