Re^3: Query takes 895ms in TOAD but 42s in DBI

I don't know what settings the DBD::Oracle module provides but I have seen a mention of RowCache in DBI that you could give a go. Also it would be interesting to test the speed of the different forms of fetch like the bind_columns variant for example :

$sth_dipp = $dbh_ideas->prepare(q{DECLARE dipp PacProject.dipp_project
+_cur; BEGIN pacproject.get_dipp_projects(:dipp); END;});
$sth_dipp->bind_param_inout(":dipp",\$s_dipp_proj,0,{ora_type => ORA_R
+SET});
$sth_dipp->execute;

my ($name, $code, $RA, $manager);
$sth_dipp->bind_columns(\($name, $code, $RA, $manager));


while ( $sth_dipp->fetch ){
    $name ||= 'Unknown';
    $code ||= 'Unknown';
    $RA ||= 'Unknown';
    $manager ||= 'Unknown';

    print qq|$name,$code,$RA,"$manager"\n|;    
}
[download]

Comment on Re^3: Query takes 895ms in TOAD but 42s in DBI Download Code

Replies are listed 'Best First'.
Re^4: Query takes 895ms in TOAD but 42s in DBI by perrin (Chancellor) on Dec 03, 2008 at 16:22 UTC
The bind_columns approach is the fastest. You can see benchmarks on some of this here.	[reply]
Re^5: Query takes 895ms in TOAD but 42s in DBI by joec_ (Scribe) on Dec 04, 2008 at 10:17 UTC
Hi When i try to implement the above code (bind_columns), i get a "`DBD::Oracle::st bind_columns failed: Statement has no result columns to bind (perhaps you need to successfully call execute first) [for Statement "DECLARE dipp PacProject.dipp_project_cur; BEGIN pacproject.get_dipp_projects(:dipp); END;" with ParamValues: :dipp=DBI::st=HASH(0x945129c)]`". I am returning a cursor from my PLSQL. Is it possible to bind columns to a cursor? TIA - Joe.	[reply] [d/l]
Re^6: Query takes 895ms in TOAD but 42s in DBI by kubrat (Scribe) on Dec 04, 2008 at 11:52 UTC
The only time I have seen this error was wheh calling bind_columns() before the execute() method. I don't quite understand your SQL because I am more of a Postgres man myself. Perhaps, someone with Oracle expetience can give a better advice. In Postgres you first declare your cursor which doesn't return any results - it's just a $dbh->do call which either succeedes or fails: `DECLARE my_cursor AS SELECT * FROM foo ;` [download] Then you execute another query to begin fetching results from the cursor, for example: `FETCH ALL FROM my_cursor;` [download] And it's here where I will use bind_coulumns() and fetch(). So, basically, the sql has to return rows for the bind_columns() call to work. What I don't understand is how does your original code work if the sql doesn't return any rows? Or perhaps it does but not immediately.	[reply] [d/l] [select]


There's more than one way to do things
	PerlMonks