http://www.perlmonks.org?node_id=345490


in reply to performance problem with oracle dbd

Try AutoCommit => 0 in the $dbh = DBI->connect( ...

Then you'll need to explicitly do a $dbh->commit; at least once after all the inserts ( or periodically, every so many inserts, etc.)

Replies are listed 'Best First'.
Re: Re: performance problem with oracle dbd
by tito (Novice) on Apr 15, 2004 at 18:33 UTC
    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...
      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{
      begin
      p_do_insert;
      end;
      } );

      $sth_do_insert->execute;

      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

      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', '127.0.0.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...