Параллельная обработка большого селекта в нескольких сессиях

[SaturnTeam]

почему число сессий не равно количеству ядер? из-за ожидания ответа от сервера?
мимо не JAVA кодер

[jvs]

Зависимость между количеством ядер и сессий не прямая. Oracle и OS распределяют сами. Я, конечно, не могу сказать точно как, сужу по результату. Давал и 150 сессий — работало, правда без особого улучшения по сравнению с 25, но и не умирало. Тут ведь и обращения к дискам и swap памяти. Самое простое поиграть с параметром на вашей машине, благо, это очень просто…

[sparhawk]

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

Если есть координирующий процесс и размер порций работы одинаковый и не слишком большой, то использование dbms_app_info кажется излишним. Главный поток может просто смотреть, сколько выполнено и сколько осталось.

[jvs]

dbms_parallel_execute работает начиная с 11g Release 2. Том Кайт предлагал параллелизм в ранних версиях тоже делать вручную. Вот ссылка. Мой метод — это один из возможных. Кроме того, речь идет об pipelined функциях, это другая реализация параллелизма, не только деление на порции, но и обработка каждой строки. По поводу DBMS INFO, это только для красоты, можно включать при отладке, чтобы посматривать, как идут процессы.

[Ivan22]

хинт /* parralels */ это вообще не из этой оперы. Он выполняет параллелизацию запроса, наример сканы, сортировки и группировки, инсерт, балк лоад и т.п.

[jvs]

Вы неправы, это как раз имеет отношение к pipelined функциям. Посмотрите У Барлесона

[onehell]

Любопытно, есть несколько вопросов.
1. Как вы пришли к решению создавать ХП, а не отдавать параллелизм на сторону приложения?
2. К примеру, если в одном потоке транзакция аварийно откатывается, данные автоматически становятся несогласованными? Как вы обрабатываете такие случаи? Или бизнес-логика в вашем примере не критична и допускает просто повторный запуск процедуры?

[jvs]

1. Я думаю, что Oracle лучше разберется с параллельностью сессий, он это делал хорошо еще когда Явы не было. И кроме того, когда с данными работают максимально близко(внутри самой базы), я считаю это здоровей всего.
2. Тут решение за Вами. В моем случае, все равно, то, что отработало, второй раз не попадет в селект, но если важно, можно придумать как реагировать на падение одного или нескольких процессов. Лучше всего отлавливать exception в Jave…

[jvs]

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