Don't ask to ask, just ask | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
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{ $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 In reply to Re: Re: Re: performance problem with oracle dbd
by jeremyh
|
|