DBMS_JOB (proc_1/sec) versus pl/sql wrap that calls proc_1 in a loop

Question

Hello,
What implementation will have a better performance, in terms of using oracle resources(connections)?
I have Implementation # 1 deployed to an Oracle 10g database.
The DBA has complained that Implementation # 1 consumes too many resources to get a connection and Implementation # 2 is better because there will be one connection every 5 minutes.
Thanks.
Implementation # 1
DBMS_JOB.SUBMIT(
job_no,
'BEGIN proc_1; END;',
SYSDATE,
'SYSDATE + 1/86400', // every second
TRUE );
Implementation # 2
DBMS_JOB.SUBMIT(
job_no,
'BEGIN PKG_JL.RUN(300,1,'proc_1'); END;',
SYSDATE,
'SYSDATE + 1/288', // every 5 min
TRUE );
where pkj_jl is:
PACKAGE BODY PKG_JL
IS
PROCEDURE run ( an_loop_count IN NUMBER
          , an_sleep_seconds IN NUMBER default 1
          , av_sql IN varchar2)
AS
     BEGIN
          for x in 1..an_loop_count
          loop
               --<<sleep_loop>>
               BEGIN
               execute immediate 'BEGIN '||av_sql||' ; END;';
               dbms_lock.sleep(an_sleep_seconds);
               EXCEPTION
                    WHEN OTHERS THEN dbms_output.put_line( 'Exception caught, sleep '||an_sleep_seconds|| ' second(s), try again.'||substr(sqlerrm,1,250) );
                    dbms_lock.sleep(an_sleep_seconds);
               END sleep_loop ;
          end loop ;
     EXCEPTION
          WHEN OTHERS THEN RAISE ;
     END run ;
END pkg_jl ;

Answer 1

ionelion wrote:
The business behind this 1 second job is an external process (a box passing by a bar code reader generates an event that is inserted in an event table TMSEVENTS). So this process only inserts rows into a table? When and how does it commit that insert? Does it do any other database activity/transactions?
The event generated by the external process will be processed by a PL/SQL procedure in my database and may take longer than one second.Why does this PL/SQL procedure only need to process a single row at a time? Why cannot it pick up a number of rows to process and process these in a fast and tight processing loop?
What the DBA has complained is the number of connections/unit of time created by the oracle job. He suggested that instead of 300 connections in 5 minutes (generated by DBMS_JOB) to use a new dbms_job that will execute every 5 minutes and call the same SP in a loop for 300 times with a sleep period of 1 second.
So my question is what implementation is better for oracle? 1 sec job or 5 min job?Neither. If I understand your process flow correctly, there is an external process throwing data into the database. This data needs to be processed as close to real-time as possible.
I would use Advance Queue feature of Oracle. I would want background server processes that listen on a queue for data process requests, dequeue the request, and process the request. This then provides a pool of processes that can dequeue and process requests - in parallel.
The external process now needs to enqueue processing requests - where that request will be dequeued and processed by this pool of processes.
This provides a scalable architecture. More external processes can be used to submit (enqueue) data processing requests. More dequeue processes can be created to allow for more requests to be processed in parallel. This also supports RAC - allowing you to scale horizontally (more db servers) and not just vertically (increase the size/capacity of the single db server).
You can roll this yourself, without using AQ. The issue is serialisation of the server worker processes looking at whatever object (e.g. table) for work to do (new rows inserted and not yet processed). You will need to find a way where there's minimal serialisation when multiple workers look for new rows to process, and process the oldest rows first. Not an impossible task, but a complex one - that using AQ eliminates as it handles that complexity for you.
And if I'm not mistaken, AQ is also available on XE. Which means this type of processing architecture you can use on XE and scale all the way up to the Enterprise and RAC editions of Oracle.