This content has been marked as final. Show 5 replies
What exactly is the problem you are trying to solve?
Scheduler combined with resource manager is a really powerful tool that can handle immense loads ....
Thanks for the quick response..
Here in DBMS_SCHEDULER with each job a process is created.. we are thinking of any possibility of multi-threaded approach..
what problem are you trying to solve? You make it sound like you are going to process data on a client using Java instead of doing data processing in the database.
Data processing by the database is very fast and will almost always be faster than on a client.
We are basically trying to purge huge amount of records in a multiple tables using concurrent approach where in we want user to specify number of concurrent threads/in this case processes to be mentioned by the user. The problem here is because it is configurable and can be set to any number and each of the job will again processes huge number of records. which will might result in performance issues. So that's the reason we are thinking of any light weight approach.
We were just trying to find out if there is any other possibility.
ok,1 person found this helpful
that is where resource manager kicks in.
Users scheduler their delete operations on an as needed basis. When the database has enough resources, it starts their jobs one by one until resource limits you set are reached.
You can give a performance guarantee to the regular users.
If you ask me, an excellent use case for the Oracle Scheduler.
The multi-threaded or lightweight multitasking solution where you speak about just saves on process creation but still has a lot of connection management overhead. Make sure that each job gets a reasonable amount of work to do. Also, take a look at light weight Scheduler Jobs. They cause less overhead on the database and you can have them run in parallel. This means that the same job can have multiple running instances, all processing their own part of the cake.