Тестирование SQL-запроса на Oracle, который включает в себя удаленную базу данных

Question

Наши базы данных для разработки (Oracle 9i) используют ссылку удаленной базы данных на удаленную общую базу данных.

Это решение было принято несколько лет назад, когда было непрактично размещать некоторые схемы базы данных на компьютере разработчика - они были слишком большими.

У нас есть определенные схемы на машинах разработки, и мы заставляем удаленные схемы выглядеть локальными, используя ссылки на базы данных Oracle, вместе с некоторыми синонимами на машинах разработки.

Проблема, с которой я столкнулся, заключается в том, что я хотел бы протестировать кусок SQL, который объединяет таблицы в схемах по обе стороны от ссылки на базу данных.

например. (упрощенный кейс):

   select a.col, b.col
   from a, b
   where a.b_id = b.id

• a находится в локальной базе данных
• b находится в базе данных удаления
• У меня есть синоним на DB локали, так что 'b' фактически указывает на b@remotedb.

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

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

Есть ли у кого-нибудь стратегии написания модульного теста для такого запроса, чтобы избежать проблем с производительностью использования ссылки на базу данных?

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

Answer 1

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

Answer 2

Скопируйте соответствующие данные в свою базу данных разработки и создайте таблицы локально.

В идеале просто создайте контрольный пример, который скажет вам:

1. SQL правильный (анализирует)
2. Он работает правильно с несколькими строками тестовых данных

Не поддавайтесь «давайте скопируем все», потому что это означает, что вы не будете иметь ни малейшего представления о том, что вы тестируете (и что вам не хватает).

Если сомневаетесь, создайте таблицу b только с одной записью. Если вы получили ошибку в этой области, добавьте больше строк, чтобы узнать, где это может произойти.

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

[EDIT] Вам нужна тестовая база данных. Не запускайте тесты для базы данных, которая может измениться. В идеале, тесты должны разбирать всю базу данных и воссоздавать ее с нуля (таблицы, индексы, данные, все) в качестве первого шага.

В этой базе данных тестов храните только четко определенные тестовые данные, которые изменяются только путем определения новых тестов (а не кем-то, "просто что-то делающим"). Если можете, попробуйте запустить свои тесты для базы данных в памяти.

Answer 3

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

То, что я пытаюсь сказать, это то, что вы можете / должны тестировать свой модуль (т. Е. Свой компонент, запрос или что-то, что вы определяете как блок) на контролируемом наборе данных, который будет имитировать различные «варианты использования» и один раз Вы завершаете тестирование до удовлетворительных результатов, затем вы можете перейти к интеграции + запуску интеграционных тестов.

Интеграционные тесты - вы можете запустить это в реальной среде, но только после того, как вы подтвердите модульное тестирование, что ваш компонент «пуленепробиваемый» (если это соответствует подходу / философии вашей компании :) - sys admin's Реакция: «Вы флиппин?»)

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

Answer 4

Я бы предложил материализованные взгляды. Это представления, которые хранят удаленные данные локально.