Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses

Re: Re: performance problem with oracle dbd

by tito (Novice)
on Apr 15, 2004 at 18:33 UTC ( #345493=note: print w/replies, xml ) Need Help??

in reply to Re: performance problem with oracle dbd
in thread performance problem with oracle dbd

Thanks for the suggestion but I'm mimicing what the real apps is doing and my pl/sql test code is doing exactly the same thing (commiting after every insert). Maybe what I can do is do a commit after the loop ends for both perl and sqlplus and see if the slow down is comparable...
  • Comment on Re: Re: performance problem with oracle dbd

Replies are listed 'Best First'.
Re: Re: Re: performance problem with oracle dbd
by jeremyh (Beadle) on Apr 15, 2004 at 19:48 UTC
    In that case, is the pl/sql code a stored procedure? If so, then that gives it a performance advantage over DBD which must be prepared at run-time. And the simple solution might be to just create a stored procedure that does your insert and then call it from perl:

    $sth_do_insert = $dbh->prepare( q{
    } );


    if you need to pass the stored procedure some parameters, look at perldoc DBI and it should tell you how.


    (Below are some thoughts if you can't do the stored procedure idea)

    Also, a stored procedure will run in the schema of it's owner, which may have a different database environment than your perl script DBD login (things like the default tablespace).

    Are you running the script on the machine that the DB is on? If not, sqlnet communication my slow things down quite a bit, although I wouldn't think an insert would be affected by that (I've seen a huge difference in query performance).

    Try to trace both sessions in oracle and see what the differences are:

    SQLPLUS> exec sys.dbms_system.set_sql_trace_in_session('&sid', '&serial', TRUE);

    where sid is the session ID and serial is the serial# (the & makes sqlplus prompt you for them, it is not part of the value); find these in v$session.

    run the same command with FALSE as the 3rd param to turn off the trace.

    Look for the trace files in your trace dump dest in init.ora

Re: Re: Re: performance problem with oracle dbd
by aquarium (Curate) on Apr 16, 2004 at 03:30 UTC
    Can you please show us the sqlplus code you are using...thanks.
      set head off set feedback off set verify off set pagesize 0 Declare p_time_stamp number(10); p_acct_count number(20); p_original_count number(10); CURSOR curs_max_timestamp IS SELECT max(acct_time_stamp) FROM accounting; begin open curs_max_timestamp; fetch curs_max_timestamp into p_time_stamp; p_time_stamp := p_time_stamp + 500; open curs_acct_count; -- zxzx insert test fetch curs_acct_count into p_original_count; p_acct_count :=0; -- zxzx insert test While ( p_acct_count <= 1500) LOOP INSERT INTO NPMADMIN.ACCOUNTING ( ACCT_STATUS_TYPE, NAS_USER_NAME, NAS +_IDENTIFIER, NAS_IP_ADDRESS, ACCT_SESSION_ID, FRAMED_IP_ADDRESS, SERVICE_TYPE, FRAMED_PROTOCOL, MED +IUM_TYPE, NAS_PORT_TYPE, NAS_PORT, NAS_PORT_ID, NAS_REAL_PORT, ACCT_DELAY_TIME, ACCT_SESSION_TI +ME, ACCT_TIME_STAMP, RATE_LIMIT_RATE, RATE_LIMIT_BURST, POLICE_RATE, POLICE_BURST, FILTER_I +D, FORWARD_POLICY, HTTP_REDIRECT_PROFILE_NAME, CONTEXT_NAME, SESSION_TIMEOUT, IDLE_TIMEOU +T, RB_DHCP_MAX_LEASES, MULTICAST_SEND, MULTICAST_RECEIVE, MULTICAST_MAX_GROUPS, IGMP_PROFILE_ +NAME, QOS_POLICING_POLICY_NAME, QOS_METERING_POLICY_NAME, QOS_PQ_POLICY_NAME +, ATM_PROFILE_NAME, PPPOE_URL, PPPOE_MOTM, PPPOE_IP_ROUTE, PPP_DNS_PRIMARY, PPP_DNS_SECONDARY, PPP_NB +NS_PRIMARY, PPP_NBNS_SECONDARY, ACCT_TERMINATE_CAUSE, SESSION_ERROR_MSG, ACCT_REAS +ON, ACCT_INPUT_OCTETS_64, ACCT_OUTPUT_OCTETS_64, ACCT_INPUT_PACKETS_64, ACCT_OUTPUT_PACKETS_64, +ACCT_MCAST_INPUT_OCTETS_64, ACCT_MCAST_OUTPUT_OCTETS_64, ACCT_MCAST_INPUT_PACKETS_64, ACCT_MCAST_OUTPUT_PACKETS_64 ) VALUES ( 'Start', 'joe', 'ser-1', '', '0B00FFFF90000010-40647961', NUL +L, 'Outbound-User' , NULL, 'DSL', 'Virtual', 201392128, '12/1 clips 20013', NULL, NULL, N +ULL, p_time_stamp , NULL, NULL, NULL, NULL, NULL, NULL, NULL, 'BASIC', NULL, NULL, 1, NU +LL, NULL, NULL , NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NU +LL, NULL, NULL , NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL); p_time_stamp := p_time_stamp + 30; commit; p_acct_count := p_acct_count + 1; end loop; end; / exit;
      This annonymous block is called from a shell script with the simple line of sqlplus user/id@database @test.sql I am running both perl and sql code on the same server. I've also found some info on the web and metalink that indicates OCI calls (which dbd::oracle wraps) does have a performance problem in 8i but no info on 9i - maybe this is an OCI issue. running out of clues...

        Ah. This makes things a lot clearer. Basically Roy is right.

        With your PL/SQL code you are shipping everything to the Oracle server. Oracle runs all the inserts. Finished.

        With your perl code you're sending a single insert to the Oracle server. Oracle is doing the insert and telling your Perl program is succeeded. 1500 times. The extra communication overhead with each execute will almost certainly be what is slowing you down.

        If the speed of multiple inserts is going to be an issue for your application it will probably be simplest to slap a lump of PL/SQL into a $dbh->do and let Oracle do it server side.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://345493]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (5)
As of 2018-04-22 03:16 GMT
Find Nodes?
    Voting Booth?