$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

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;
[download]

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.