RE: dbd::oracle behavior

[email protected] ("Carlson, John W.")
Newsgroups perl.dbi.users
Message-ID <B118D77A69C1724E8B2410B48F2B07F3011CEC7EF1CD@NSPEXMBX-A.the-lab.llnl.gov>
Uh.  I just installed DBD::Oracle 1.23 with a patch.  Should I install DBD::Oracle 1.22 instead?  What I the nature of the bug?
I am fairly new to the dbi-users group, and I haven't been watching the emails.

John

-----Original Message-----
From: John Scoles [mailto:[email protected]] 
Sent: Friday, February 05, 2010 5:07 AM
To: Matthew Maglinte
Cc: [email protected]; [email protected]
Subject: Re: dbd::oracle behavior

Hard to say what is going on here but me things you are running into the 
'ping' problem

Are you using Apache::DBI??

Many of these warehouse applictions reuse the same connection handel and 
to keep them alive they use $dbh->ping which runs a query to maintain 
the connection.

What version of DBD::Oracle are you using?

If you can upgrade to DBD::Oracle 1.22 (do not use 1.23 there is a bug 
in there that might be worse) or get the latest 1.24 version

that might solve your problem

cheers
John Scoles






Matthew Maglinte wrote:
> I'm a dba supporting a  warehouse database (production environment) 
> accessed via a custom application built on open source components, one of 
> which is dbd::oracle.
>
> Performance monitoring shows two queries continually consuming 
> considerable resources (cpu waits) - the query text resembling for the 
> most part 'column_info' and 'table_info'.  Over any given day, the 
> column_info select is executed +260 times an hour,  'table_info'  executed 
> +360 times an hour.
>
> Is this level of frequency intended?  And are these calls appropriate 
> (expected) for a static data dictionary environment?
>
> Any response that would help my understanding would be appreciated. 
> Thanks.
>
> Matt Maglinte
> DBA - PeMS/LCS
> Department of Transportation
> W:(916)445-0090
> [email protected]
>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.