Oracle Datareader в .Net - слишком медленный (по сети)

Question

Прежде чем я получу "ты пробовал ODP.net?" ответы, да, я имею и использую это сейчас.

Я перемещаю данные с оракула на сервер SQL (не важно) и использую программу чтения данных при подключении к оракулу. Большие столы ползут. Иногда так плохо, как 10 записей в секунду. Когда я заметил проблемы с производительностью, я сократил исходный код до выполнения простых вызовов Reader.Read () по всей таблице, поэтому ничто иное не замедляет его. Я пробовал и MS и Oracle ODP .net клиентов. В настоящее время я использую 11g Instant Client, 64bit на win7 64bit, оперативную память на 8 гигов и все вкусности. Я использовал его в локальной сети, и в настоящее время я использую VPN, и производительность в основном такая же. Я настроил размеры Prefetch без результатов.

Я могу запустить функцию «Экспорт данных» в инструментах Oracle Sql DEveloper и экспортировать все данные для всей базы данных на той же машине, в той же сети, примерно в 100 раз быстрее.

Я могу скопировать свое приложение .net на сервер оракула и запустить на нем тот же тест производительности, и он заканчивается менее чем за секунду.

Таким образом, это не сама сеть, которая работает медленно, и это не количество данных (как продемонстрировал экспорт SqlDeveloper), и это не сам код .net и не oracle db (как продемонстрировано при его запуске на сервере). ), так что это должна быть какая-то комбинация Datareader, используемая в любой сети.

Это моя мгновенная установка клиента? Полноценный клиент работает лучше? 64-битный клиент все портит? Действительно в растерянности.

ОБНОВЛЕНИЕ:

С тех пор я запускаю то же самое приложение, скомпилированное для 32-разрядных, и запускаю на виртуальном компьютере экземпляр Windows XP, на котором установлен «полный» клиент Oracle (очевидно, 32-разрядная версия). Даже при сниженной производительности виртуальной машины она по-прежнему работала почти в 10 раз быстрее. Итак, определенно какая-то проблема с клиентом Instant, и я предполагаю, что именно 64-битный клиент Instant. Последним тестом, подтверждающим это, будет установка 32-разрядного мгновенного клиента на эту же машину и запуск его снова. Если я найду время ...

Answer 1

У меня похожая проблема с этим, но она периодически.У меня есть запрос Oracle, который обычно выполняется около 1 секунды, но иногда около обеда для запуска с использованием .Net требуется 30 секунд.Если в это время я запускаю его с помощью Oracle SQL Developer на той же машине, это все равно занимает 1 секунду.

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

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

РЕДАКТИРОВАТЬ: я обнаружил, что другой коллега делал большие копии файлов по сети во время замедления.Чтобы доказать это, я заставил его сделать это снова, и произошло то же самое, но в Oracle SQL Developer запрос все еще был быстрым.Таким образом, это комбинация сети и драйвера Oracle .Net.Я использую 64-битный BTW.

Answer 2

Попробуйте увеличить размер выборки . Чем выше значение, тем меньше ODP.net придется совершать в обоих направлениях, чтобы получить данные, и тем выше будет производительность по сети. (Обратите внимание, что AFAIK, если у вас включен пул соединений, это делается автоматически.)

Answer 3

boomhauer: вы дошли до сути этого? Я испытываю похожие проблемы. Я получил небольшое повышение, играя с Fetchsizes. В моей тестовой среде, которая на порядки меньше, чем prod, я вижу 1,8 секунды на ODP.net и 0,2 секунды на System.Data.OracleClient. Лучшее, что я могу получить, увеличив размер выборки, составляет 1,6 секунды.

Answer 4

«Я могу скопировать свое приложение .net на сервер Oracle и запустить тот же тест производительности на нем, который завершится менее чем за секунду.»

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

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

Но, как вы заметили, это не может объяснить разницу во времени. Приложения могут быть WAN недружественными. Как правило, это означает, что для отправки и получения информации требуется слишком много оборотов, а объем информации в каждом потоке данных может быть существенно большим, чем требуется. Вполне возможно, что лежащий в основе механизм рукопожатия от массового экспорта в ваше приложение будет совершенно другим. Один может запрашивать 100 записей за один раз, а другой может вытягивать каждую запись последовательно (отмечая разницу в скорости 100: 1). Постоянное применение рукопожатия к базе данных для единовременного извлечения записей может значительно увеличить ваши накладные расходы и привести к падению пропускной способности.