2013-05-30 2 views
0

Я разрабатываю хранимую процедуру Java, которая вызывается внутри другой процедуры PL/SQL. В коде JAVA мне нужно выбрать ~ 500 столбцов, которые возвращают ~ 5000 строк и обрабатывают данные (сгенерируйте XML с помощью StAX в BLOB размером ~ 8 МБ). Обработка имеет только линейную сложность, и нет никаких затрат времени или памяти.Почему один и тот же код в oracle хранит java-процедуру медленнее, чем в обычной java?

Когда я запускаю код на своем рабочем столе и подключаюсь к удаленному серверу БД, он работает через ~ 3 секунды. Когда я развертываю программу в БД в качестве хранимой процедуры Java, она запускается через ~ 14 секунд.

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

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

Любые идеи, как может быть проблема?

То, что я не могу сделать, это:

  • использование стандартных инструментов картографирования DB-XML, поскольку это не только простое преобразование, но есть бизнес-логика позади него
  • переписать алгоритм чистого PL/SQL, поскольку есть много объектно-ориентированные функции используются, и было бы слишком трудно писать и поддерживать его в процедурном
  • разместить код на сервер приложений, как это только один шаг обработки данных в PL/SQL
+0

Вы пытались [профиль] (http://docs.oracle.com/cd/B28359_01/appdev.111/b28419/d_profil.htm) ваш код pl/sql? – tbone

+0

Какие версии JVM с обеих сторон? Настройки размера кучи? Вы пытались напрямую вызвать хранимую процедуру java (= без PL/SQL)? – Beryllium

+0

Время ~ 14 секунд - это не время всей процедуры, это всего лишь время java-кода за одним вызовом в PL/SQL. Из кода Java я не вызываю никаких PL/SQL-процедур, просто один большой выбор с только для чтения только для результатов. Выбор выполняется в ~ 250 мс. – ondrej

ответ

1

Возможности, не исключенные из информации, которую вы опубликовали: более быстрый настольный процессор и/или сервер БД при более высокой нагрузке.

+0

+1: V. хорошие базовые очки для проверки. Мне было бы интересно узнать, что такое серверный процессор, поскольку недавняя тенденция в многоядерных процессорах оставила нам больше, но относительно слабые ядра. –

Смежные вопросы