Comments 9
почему число сессий не равно количеству ядер? из-за ожидания ответа от сервера?
мимо не JAVA кодер
мимо не JAVA кодер
Зависимость между количеством ядер и сессий не прямая. Oracle и OS распределяют сами. Я, конечно, не могу сказать точно как, сужу по результату. Давал и 150 сессий — работало, правда без особого улучшения по сравнению с 25, но и не умирало. Тут ведь и обращения к дискам и swap памяти. Самое простое поиграть с параметром на вашей машине, благо, это очень просто…
Для большинства подобных случаев хватит dbms_parallel_execute, который работает под любой версией Oralce. Он достаточно прост и понятен, умеет прерывать и возобновлять процесс.
Если есть координирующий процесс и размер порций работы одинаковый и не слишком большой, то использование dbms_app_info кажется излишним. Главный поток может просто смотреть, сколько выполнено и сколько осталось.
Если есть координирующий процесс и размер порций работы одинаковый и не слишком большой, то использование dbms_app_info кажется излишним. Главный поток может просто смотреть, сколько выполнено и сколько осталось.
dbms_parallel_execute работает начиная с 11g Release 2. Том Кайт предлагал параллелизм в ранних версиях тоже делать вручную. Вот ссылка. Мой метод — это один из возможных. Кроме того, речь идет об pipelined функциях, это другая реализация параллелизма, не только деление на порции, но и обработка каждой строки. По поводу DBMS INFO, это только для красоты, можно включать при отладке, чтобы посматривать, как идут процессы.
хинт /* parralels */ это вообще не из этой оперы. Он выполняет параллелизацию запроса, наример сканы, сортировки и группировки, инсерт, балк лоад и т.п.
Вы неправы, это как раз имеет отношение к pipelined функциям. Посмотрите У Барлесона
Любопытно, есть несколько вопросов.
1. Как вы пришли к решению создавать ХП, а не отдавать параллелизм на сторону приложения?
2. К примеру, если в одном потоке транзакция аварийно откатывается, данные автоматически становятся несогласованными? Как вы обрабатываете такие случаи? Или бизнес-логика в вашем примере не критична и допускает просто повторный запуск процедуры?
1. Как вы пришли к решению создавать ХП, а не отдавать параллелизм на сторону приложения?
2. К примеру, если в одном потоке транзакция аварийно откатывается, данные автоматически становятся несогласованными? Как вы обрабатываете такие случаи? Или бизнес-логика в вашем примере не критична и допускает просто повторный запуск процедуры?
1. Я думаю, что Oracle лучше разберется с параллельностью сессий, он это делал хорошо еще когда Явы не было. И кроме того, когда с данными работают максимально близко(внутри самой базы), я считаю это здоровей всего.
2. Тут решение за Вами. В моем случае, все равно, то, что отработало, второй раз не попадет в селект, но если важно, можно придумать как реагировать на падение одного или нескольких процессов. Лучше всего отлавливать exception в Jave…
2. Тут решение за Вами. В моем случае, все равно, то, что отработало, второй раз не попадет в селект, но если важно, можно придумать как реагировать на падение одного или нескольких процессов. Лучше всего отлавливать exception в Jave…
Кроме того, сервер базы — это обычно сильный компьютер с несколькими ядрами, а точно есть зависимость между параллельностью процессов и многоядерностью.
Sign up to leave a comment.
Параллельная обработка большого селекта в нескольких сессиях