$ENV{'ORACLE_HOME'} is set correctly right before the connection attempt
(it missing would result in an additional warning in the trace).
that's not necessarily true.
Also,
the same script run from bash does successfully connect (same users, all
envs set in script).
I did an additional in
set ORACLE_HOME so that OCI libraries
below DBD::Oracle notice this variable.
Double check the way you set your environment.
And if that's the case, watch the new culprit under 2.0:
http://perl.apache.org/docs/2.0/user/troubleshooting/troubleshooting.html#C_Libraries_Don_t_See_C__ENV__Ent
Fabian Kreitner wrote:
[...]
$ENV{'ORACLE_HOME'} is set correctly right before the connection attempt
(it missing would result in an additional warning in the trace). Also,
the same script run from bash does successfully connect (same users, all
envs set in script).
read the info at the link I
kely) or you failed to set ORACLE_HOME so that OCI libraries
below DBD::Oracle notice this variable.
Double check the way you set your environment.
$ENV{'ORACLE_HOME'} is set correctly right before the connection attempt
(it missing would result in an additional warning in the trace)
iables and then tries a connect.
(...)
!! ERROR: 12154 'Error while trying to retrieve text for error
ORA-12154 (DBD ERROR: OCIServerAttach)'
Either you removed message files from your Oracle installation (not
very likely) or you failed to set ORACLE_HOME so that OCI lib
variables and then tries a connect.
>
> (...)
> !! ERROR: 12154 'Error while trying to retrieve text for error
> ORA-12154 (DBD ERROR: OCIServerAttach)'
Either you removed message files from your Oracle installation (not
very likely) or you failed to set ORACL
euid=40019
install_driver: DBD::Oracle version 1.12 loaded from
/opt/ainea/perl/lib/site_perl/5.8.0/i686-linux/DBD/Oracle.p
<- install_driver= DBI::dr=HASH(0x82f1c6c)
-> connect for DBD::Oracle::dr (DBI::dr=HASH(0x82f1c6c)~0x834e818
'PERG' 'pid_10023' **** H
> > > >I'm having a problem on Windows 2000 where DBD::Oracle works fine from
> > > >perl on the command prompt but not from inside mod_perl. I think it is a
> > > >problem loading DLLs but I can't figure out what's different running under
>
On Wed, 30 Oct 2002, Larry Leszczynski wrote:
> Hi Perrin -
>
> > >I'm having a problem on Windows 2000 where DBD::Oracle works fine from
> > >perl on the command prompt but not from inside mod_perl. I think it is a
> > >problem loading DLLs but I can'
Hi Perrin -
> >I'm having a problem on Windows 2000 where DBD::Oracle works fine from
> >perl on the command prompt but not from inside mod_perl. I think it is a
> >problem loading DLLs but I can't figure out what's different running under
> >mod_perl. Th
Larry Leszczynski wrote:
I'm having a problem on Windows 2000 where DBD::Oracle works fine from
perl on the command prompt but not from inside mod_perl. I think it is a
problem loading DLLs but I can't figure out what's different running under
mod_perl. The machine is running
Hi -
I'm having a problem on Windows 2000 where DBD::Oracle works fine from
perl on the command prompt but not from inside mod_perl. I think it is a
problem loading DLLs but I can't figure out what's different running under
mod_perl. The machine is running:
ActiveState perl
", $user, $password)
or die "Cannot connect: ".$DBI::errstr;
Thank you for your advice!
Atsushi
- Original Message -
From: "Geoffrey Young" <[EMAIL PROTECTED]>
To: "Atsushi Fujita" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thur
Atsushi Fujita wrote:
> Hi all,
>
> Few weeks ago, I posted a problem about DBD::Oracle as following.
[snip]
>
>
> # add by atsushi 2002/08/22
> $ENV{'ORACLE_HOME'} = '/u01/app/oracle/product/9.0.1';
> $ENV{'ORACLE_SID'} = &
Hi all,
Few weeks ago, I posted a problem about DBD::Oracle as following.
> I am trying to use DBD::Oracle1.12 on mod_perl2.
> But it doesn't work fine.
> It shows error as following in error_log at $dbh = DBI->connect.
>
> [error_log]
> DBI->connect(ynt0
#x27;NLS_LANG'}\n";
> print "DSN=$dsn$ENV{'ORACLE_SID'}\n";
>
> $dbh = DBI->connect("$dsn$ENV{'ORACLE_SID'}", $user, $password)
> or die "Cannot connect: ".$DBI::errstr;
>
> $sth = $dbh->prepare($sql)
> or die "
NV{'ORACLE_SID'}", $user, $password)
or die "Cannot connect: ".$DBI::errstr;
$sth = $dbh->prepare($sql)
or die "Cannot prepare: ".$dbh->errstr();
$rv = $sth->execute
or die "Cannot execute: ".$sth->errstr();
print "sth=$sth,rv=$rv\n
Atsushi Fujita wrote:
> Hi Stas,
>
>
>>Can you please try to convert the script into a mod_perl handler and
>>test again?
>
>
> OK, I just checked it.
> The result was everything fine using by mod_perl handler!
> There was no problem in my new code.
>
> ...But I want to use ModPerl::Registry,
Hi,
the problem connecting to an oracle DB through mod_perl is solved: the
solution was, to convert the script into a mod_perl handler as it was
suggested by Stas. I adopted the code posted by Atsushi Fujita and it
worked just perfect for me.
So, thank you all for your help.
Fredo
--
Dr. Fred
;
$rv = $sth->execute
or die "Cannot execute: ".$sth->errstr();
$r->print("sth=[$sth],rv=[$rv]\n");
while(@row = $sth->fetchrow_array){
$r->print("@row\n");
}
$sth->finish();
$dbh->disconnect();
$r->print("Finished!!\n");
Mike P. Mikhailov wrote:
> Hello Fredo Sartori,
>
> Thursday, August 15, 2002, 1:44:34 PM, you wrote:
>
> I mabe wrong, but what about to move code to setup ENV out from BEGIN
> block ? I wrote simple test below:
>
> # Test.pm
> package Test;
>
> use Apache::Constants qw ( :common );
>
> BE
..
FS> the log file of the Oracle listener on the DB box ahows:
FS> 15-AUG-02 09:25:46 *
FS>
(CONNECT_DATA=(SID=*)(SERVICE_NAME=sun1.)(CID=(PROGRAM=)(HOST=ollenhauer)(USER=www-adm)))
* (ADDRESS=(PROTOCOL=tcp)(HOST=172.22.250.27)(PORT=53048)) sh * * * 0
FS> ......
Atsushi Fujita wrote:
> Hi Lyle,
>
>
>>I does seem to be an ORACLE environment issue.
Can you please try to convert the script into a mod_perl handler and
test again? I doubt this is registry problem, but probably something
that about setting up the env for mod_perl in general.
What would he
h], attr=[$attr]\n";
for(keys %$attr){
print "attr{$_}=[${$attr}{$_}]\n";
}
for(keys %ENV){
print "ENV{$_}=[$ENV{$_}]\n";
}
# Call Oracle OCI logon func in Oracle.xs file
# and populate internal handle data.
DBD::Oracle::db::_login($dbh, $dbname, $user, $
fork_perl5.6.1normal/cgi-bin/test1.cgi line 42.
>
>
> This looks like a problem of %ENV.
> So, I inserted debug code in DBD.pm to output %ENV, and it was correct in
> DBD.pm under mod_perl2.
> But I didn't check deep C code, I gave up to check it...
>
perl5.6.1(non thread)
- DBI-1.30
- DBD-Oracle-1.12
- mod_perl1.99_04(DSO build)
- apache2.0.39(prefork)
- Oracle9.0.1.3 for Linux in same machine
And I attached my last mail.
Sorry for being long mail...
Thank you.
Atsushi
- Original Message -
From: "Atsushi Fujita"
Hello Mike,
of course: the error message of the listener is correct: theres is no
SID sent to the DB server. But, if the same script is run from the
command line, the SID is transmitted.
Fredo
Am Don, 2002-08-15 um 11.34 schrieb Mike P. Mikhailov:
> Hello Fredo Sartori,
>
> Hmm... It looks li
Hello Fredo Sartori,
Hmm... It looks like a TNS error.
TNS-12505 TNS:listener could not resolve SID given in connect descriptor
I think it has nothing to do with mod_perl :(
Thursday, August 15, 2002, 3:10:59 PM, you wrote:
FS> Hello Mike,
FS> the code works from the shell as a regular perl
Hello Mike,
the code works from the shell as a regular perl script. The service is
correctly resolved with tnsping.
Fredo
Am Don, 2002-08-15 um 10.05 schrieb Mike P. Mikhailov:
> Hello Fredo Sartori,
>
> You are connecting to Oracle with service specified in connect
> string. Does this service
OL=tcp)(HOST=172.22.250.27)(PORT=53048)) sh * * * 0
FS> ..
FS> The following versions are used:
FS> apache 2.0.39
FS> mod_perl: 1.99_04
FS> DBI: 1.30
FS> DBD-Oracle: 1.12
FS> .
FS> #sample script:
FS> #!/usr/local/bin/perl -w
FS&g
* * * 0
..
The following versions are used:
apache 2.0.39
mod_perl: 1.99_04
DBI: 1.30
DBD-Oracle: 1.12
.
#sample script:
#!/usr/local/bin/perl -w
BEGIN {
$ENV{ORACLE_HOME} = '/opt/oracle/app/product/8.1.6';
$ENV{ORACLE_SID} = 'SPD';
}
u
m: "Stas Bekman" <[EMAIL PROTECTED]>
To: "Atsushi Fujita" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, July 31, 2002 11:18 AM
Subject: Re: mod_perl2 & DBD::Oracle problem
> Atsushi Fujita wrote:
> > Hi all,
> >
> > I a
anese_japan.ja16euc
> DSN=dbi:Oracle:ynt0
>
> Internal Server Error
> The server encountered an internal error or misconfiguration and was unable to
> complete your request.
>
>
>
> And if I turned off the mod_perl, it works fine on normal CGI-script.
> This
p/oracle/product/9.0.1
ORACLE_SID=ynt0
NLS_LANG=japanese_japan.ja16euc
DSN=dbi:Oracle:ynt0
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to
complete your request.
And if I turned off the mod_perl, it works fine on normal CGI-scrip
t;
> On Mon, Mar 11, 2002 at 02:33:17PM -0500, Geoffrey Young wrote:
> > Brian Lavender wrote:
> > >
> > > I am trying to install Apache::Session and it is failing on
> > > the DBD::Oracle tests. It is asking for a default user. Do
> > > I need to con
er wrote:
> >
> > I am trying to install Apache::Session and it is failing on
> > the DBD::Oracle tests. It is asking for a default user. Do
> > I need to configure Oracle for a default user? Or do I need
> > to set some environment variable with a user id and password?
>
>
On Mon, 11 Mar 2002, Brian Lavender wrote:
> Date: Mon, 11 Mar 2002 11:24:35 -0800
> From: Brian Lavender <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Apache::Session problem with DBD::Oracle
>
> I am trying to install Apache::Session and it is failing on
> t
Brian Lavender wrote:
>
> I am trying to install Apache::Session and it is failing on
> the DBD::Oracle tests. It is asking for a default user. Do
> I need to configure Oracle for a default user? Or do I need
> to set some environment variable with a user id and password?
wel
I am trying to install Apache::Session and it is failing on
the DBD::Oracle tests. It is asking for a default user. Do
I need to configure Oracle for a default user? Or do I need
to set some environment variable with a user id and password?
brian
Here are the errors I am getting:
t/99oracle
Andrei A. Voropaev wrote:
> Hi!
>
> In the code for DBD::Oracle::db::ping method there are lines
>
> local $SIG{__DIE__};
> local $SIG{__WARN__};
>
> As I understand these lines don't do anything though I guess they are supposed
> to suppress wa
Hi!
In the code for DBD::Oracle::db::ping method there are lines
local $SIG{__DIE__};
local $SIG{__WARN__};
As I understand these lines don't do anything though I guess they are supposed
to suppress warning messages and possibly 'die' messages. Currently everytime
when
> PH> Another solution is to have the child process exit if the ping
> PH> fails. You get one failed request, but you clear out the messed
> PH> up processes quickly and replace them with new ones that can
> PH> connect safely.
>
> Yeah, good point. Although our poor little WAP ser
> "PH" == Perrin Harkins <[EMAIL PROTECTED]> writes:
PH> Are you loading the Oracle driver in the parent process (with
PH> startup.pl)? I think I remember this sometimes causing problems
PH> with re-connecting.
No, but we did hand load it in a module called from perl.conf with
Pe
> Apache::DBI's ping check worked fine, but when the dbh was ejected from
> the cache (and so went out of scope), something in the DESTROY stack
> was blocking, and holding the child up for 12m. I'm guesing the
> underlying DBD::Oracle code was trying to do a nice shutd
went out of scope), something in the DESTROY stack
was blocking, and holding the child up for 12m. I'm guesing the
underlying DBD::Oracle code was trying to do a nice shutdown on the
dbh, but obviously couldn't.
Quick hack:
Tweak Apache::DBI to keep the ejected dbh in scope, in a glo
At 01:26 PM 8/23/2001 -0700, Benjamin Trott wrote:
> > I haven't read the entire thread, so forgive me if I'm restating. But there
> > are reasons for sharing DB connections (and reasons not to). In the case of
> > MySQL and getting messages about active statement handles, that's because
> > you'r
From: Perrin Harkins <[EMAIL PROTECTED]>
> Database handles are never shared between processes. If you missed this,
> you should re-read the Apache::DBI docs.
Uh, oh. You're right, I spoke too quickly. And I did it more than once, sorry.
With separate processes, everything is new (mostly). In
>> Apache::DBI doesn't have a problem with transactions.
>
> Ah, OK. What about when a shared connection is rolled back in one process,
> will it effect other running processes with the same handle?
Database handles are never shared between processes. If you missed this,
you should re-read the A
From: Perrin Harkins <[EMAIL PROTECTED]>
> Apache::DBI doesn't have a problem with transactions.
Ah, OK. What about when a shared connection is rolled back in one process, will it
effect other running processes with the same handle?
---
Rodney Broom
Programmer: Desert.Net
>
>BT> By using the magic 6th arg ($connect_meth in the DBI::connect
>source) to
>BT> DBI::connect. In my DB wrapper I have a connect method that
>internally calls
>
>Duh... the source! What a concept ;-)
it's actually even documented (from DBI 1.18+ IIRC :)
The "dbi_connect_method" attribute c
On Thu, Aug 23, 2001 at 11:19:22AM -0700, Kyle Oppenheim wrote:
> 3. Apache::DBI intercepts the connect(), looks in it's hash and sees that it
> already has a connection. It pings the handle, fails, and deletes the entry
> from the hash. That's the last refcount on the dbh, so DESTROY gets call
> Nope, you've got it. If you don't have transactions (anything else?) to
worry about, I'd say to use
> Apache::DBI.
Apache::DBI doesn't have a problem with transactions. If you're doing
strange things like changing isolation levels on particular requests you can
get into trouble, but that's an
>>> PH> Don't open a connection during startup.
>>> PH> Open a connection in the child process instead.
>>
> BT > I will second this. I've done this (unintentionally) when using MySQL,
> and
> BT > you get a lot of weird errors about statement handles being active, etc.
>
> I haven't read the en
> "BT" == Benjamin Trott <[EMAIL PROTECTED]> writes:
>> that all clients also use? That is, how can I force Apache::DBI to
>> close that handle prior to the forking of children?
BT> By using the magic 6th arg ($connect_meth in the DBI::connect source) to
BT> DBI::connect. In my DB wrapper I
Rodney Broom <[EMAIL PROTECTED]> said something to this effect on 08/23/2001:
> From: Rasoul Hajikhani <[EMAIL PROTECTED]>
> > I am sorry but this topic is confusing me... Are you saying that
> > persistent DB connection objects are bad?
>
> It sounds like that, doesn't it?
This is only when one
From: Benjamin Trott <[EMAIL PROTECTED]>
> > PH> Don't open a connection during startup.
> > PH> Open a connection in the child process instead.
>
BT > I will second this. I've done this (unintentionally) when using MySQL, and
BT > you get a lot of weird errors about statement handles being act
Benjamin Trott wrote:
>
> > PH> Don't open a connection during startup. If you do, it will be shared when
> > PH> Apache forks, and sharing a database handle is bad for the same reasons
> > PH> sharig a file handle is. Open a connection in the child process instead.
>
> I will second this. I'v
> PH> Don't open a connection during startup. If you do, it will be shared when
> PH> Apache forks, and sharing a database handle is bad for the same reasons
> PH> sharig a file handle is. Open a connection in the child process instead.
I will second this. I've done this (unintentionally) when
che/DBI.pm line 119.
dbih_clearcom (h 0x82a3934, com 0x84ae49c):
FLAGS 0x211: COMSET Warn AutoCommit
TYPE 1
PARENT undef
KIDS 0 (0 active)
IMP_DATA undef in 'DBD::Oracle::dr'
5. Apache::DBI calls the real DBI->connect. This fails due to a &
[EMAIL PROTECTED] (Vivek Khera) wrote:
>> "PH" == Perrin Harkins <[EMAIL PROTECTED]> writes:
>PH> Don't open a connection during startup. If you do, it will be shared when
>PH> Apache forks, and sharing a database handle is bad for the same reasons
>PH> sharig a file handle is. Open a connec
> "PH" == Perrin Harkins <[EMAIL PROTECTED]> writes:
PH> Don't open a connection during startup. If you do, it will be shared when
PH> Apache forks, and sharing a database handle is bad for the same reasons
PH> sharig a file handle is. Open a connection in the child process instead.
Speaki
> On Wed, Aug 22, 2001 at 09:42:59AM -0400, Perrin Harkins wrote:
> > > > Are you using Apache::DBI? Are you opening a connection in
> the parent
> > > > process (in startup.pl or equivalent)?
> > > Yes, yes.
> >
> > Don't open a connection during startup. If you do, it will be
> shared when
> >
On Wed, Aug 22, 2001 at 09:42:59AM -0400, Perrin Harkins wrote:
> > > Are you using Apache::DBI? Are you opening a connection in the parent
> > > process (in startup.pl or equivalent)?
> > Yes, yes.
>
> Don't open a connection during startup. If you do, it will be shared when
> Apache forks, an
> > Are you using Apache::DBI? Are you opening a connection in the parent
> > process (in startup.pl or equivalent)?
> Yes, yes.
Don't open a connection during startup. If you do, it will be shared when
Apache forks, and sharing a database handle is bad for the same reasons
sharig a file handle
On Wed, Aug 22, 2001 at 09:07:59AM -0400, Perrin Harkins wrote:
> > (DBD: error possibly near <*> indicator at char 1 in '<*>select
> slogan_text
> > from
> > slogans') at /usr/local/www/lib/SQL.pm line 221.
> Are you using Apache::DBI? Are you opening a connection in the parent
> process (in st
> After some time of work (about hundred of requests), I get
>
> DBD::Oracle::db prepare failed: ORA-03113: end-of-file on communication
> channel
> (DBD: error possibly near <*> indicator at char 1 in '<*>select
slogan_text
> from
> slogans') at /usr
Hello!
I'm getting constant troubles with DBD::Oracle and mod_perl.
DBD::Oracle 1.08, DBI 1.19, mod_perl 1.26 on Apache 1.3.20,
SunOS netra 5.8 Generic_108528-09 sun4u sparc SUNW,UltraAX-i2
gcc 2.95.3 20010315 (release)
This is perl, v5.6.1 built for sun4-solaris
# perl -V:usemym
this
> makes any difference;
Dunno!
> as well, I am using perl 5.005.
Shouldn't think that would stop you, but I'm using 5.7.0.
> > > DBD::Oracle::db rollback failed: Error while trying to retrieve
text for
> > > error ORA-03113 (DBD ERROR: OCITransRollback) at
T
On Mon, Jun 11, 2001 at 04:15:15PM -0700, Eric Kolve wrote:
> I recently upgraded to DBI 1.18 + DBD::Oracle 1.07 and upon restarts
> with mod_perl, I get the following error:
>
> DBD::Oracle::db rollback failed: Error while trying to retrieve text for
> error ORA-0
Hi there,
On Tue, 12 Jun 2001, Mark Vandenbroeck wrote:
> There seems to be some confusion and even incorrectness in this trail. Let's get
> some things straight :
Thanks for setting me straight!
73,
Ged.
ifference;
Dunno!
> as well, I am using perl 5.005.
Shouldn't think that would stop you, but I'm using 5.7.0.
> > > DBD::Oracle::db rollback failed: Error while trying to retrieve text for
> > > error ORA-03113 (DBD ERROR: OCITransRollback) at
This is really two
recently upgraded to DBI 1.18 + DBD::Oracle 1.07 and upon restarts
> > with mod_perl, I get the following error:
> >
> > DBD::Oracle::db rollback failed: Error while trying to retrieve text for
> > error ORA-03113 (DBD ERROR: OCITransRollback) at
> > /usr/lib/perl5/s
Hi there,
On Mon, 11 Jun 2001, Eric Kolve wrote:
> I recently upgraded to DBI 1.18 + DBD::Oracle 1.07 and upon restarts
> with mod_perl, I get the following error:
>
> DBD::Oracle::db rollback failed: Error while trying to retrieve text for
> error ORA-03113 (DBD ERROR: OCITr
I recently upgraded to DBI 1.18 + DBD::Oracle 1.07 and upon restarts
with mod_perl, I get the following error:
DBD::Oracle::db rollback failed: Error while trying to retrieve text for
error ORA-03113 (DBD ERROR: OCITransRollback) at
/usr/lib/perl5/site_perl/5.005/Apache/DBI.pm line 153.
I am
001 05:20
> To: 'EXT-Sethi, Arun'
> Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
> Subject: RE: DBD - Oracle "Error connecting to Oracle"
>
>
>
> > -Original Message-
> > From: EXT-Sethi, Arun [mailto:[EMAIL P
Geoff / Daniel,
this is in ref. to your emails (as given below) in the "mod_perl" users group.
I am going through the same errors in my error_log ie
getting:
Use of inherited AUTOLOAD for non-method DBD::Oracle::ORA_OCI() is deprecated at
/oracle/product/9iAS/Apache/perl/lib/site_
> -Original Message-
> From: EXT-Sethi, Arun [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 27, 2001 10:07 PM
> To: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
> Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]';
> '[EMAIL
> -Original Message-
> From: Jay Strauss [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 06, 2001 10:07 AM
> To: Geoffrey Young; [EMAIL PROTECTED]
> Subject: Re: DBD-oracle works but not from Mod-perl
>
>
> Not finding libclntsh.so.1.0 isn't my problem
TED]>
To: "'Jay Strauss'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, March 06, 2001 8:49 AM
Subject: RE: DBD-oracle works but not from Mod-perl
>
>
> > -Original Message-
> > From: Jay Strauss [mailto:[EMAIL PROTECTED]]
> >
> -Original Message-
> From: Jay Strauss [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 06, 2001 9:03 AM
> To: [EMAIL PROTECTED]
> Subject: DBD-oracle works but not from Mod-perl
>
>
> Hi mod_perl,
>
> I have a problem, I've installed DBI & D
Hi mod_perl,
I have a problem, I've installed DBI & DBD-Oracle. I have read and searched
all over for an answer and have only found one message with the same problem
(but no reply). It all works fine from a regular perl script (i.e. I can
connect and query fine). But when I try to
d
x27;ve written up a basic scaling framework, and I've posted a
> particular development profiling tool that we wrote to capture, time, and
> explain all SQL select queries that occur on a particular page of a
mod_perl
> + DBD::Oracle application:
> -http://www.lifespree.com/modperl/ex
2:54 PM
To: Perrin Harkins
Cc: Ed Park; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [ANNOUNCE] new site: scaling mod_perl (+tool: mod_perl +
DBD::Oracle)
On Fri, 8 Dec 2000, Perrin Harkins wrote:
> > 1. Performance benchmarking code. In particular, I'm looking for tools
> that
On Fri, 8 Dec 2000, Perrin Harkins wrote:
> > 1. Performance benchmarking code. In particular, I'm looking for tools
> that
> > can read in an apache log, play it back realtime (by looking at the time
> > between requests in the apache log), and simulate slow & simultaneous
> > connections. I've
of a mod_perl
> + DBD::Oracle application:
> -http://www.lifespree.com/modperl/explain_dbitracelog.pl
The docs should at least mention the ora_explain tool from Alan
Burlison (a Sun performance guy) that's included in the DBD::Oracle
distribution.
It'll let you and and explain t
> 2. Caching techniques. I know that this is a topic that has been somewhat
> beaten to a pulp on this list, but it keeps coming up, and I don't know of
> any place where the current best thinking on the subject has been
> synthesized. I haven't used any caching techniques yet myself, but I
intend
On Fri, 8 Dec 2000, Ed Park wrote:
> The enterprise mod_perl architectures idea that I posted earlier has evolved
> into a slightly modified idea: a 'scaling mod_perl' site:
> http://www.lifespree.com/modperl.
Ed, this is all cool, but is it possible that we put this on one of the
public sites?
e, complicated mod_perl
architectures.
So far, I've written up a basic scaling framework, and I've posted a
particular development profiling tool that we wrote to capture, time, and
explain all SQL select queries that occur on a particular page of a mod_perl
+ DBD::Oracle application:
-
connecting to oracle
with DBD-Oracle-1.06/DBI-1.14 with Perl version v5.6.0 for Apache/1.3.12
(Unix) mod_perl/1.24 mod_ssl/2.6.6 OpenSSL/0.9.5a
I had a
problem connectingto DB using CGI scripts, but it was working fine manual
connections. So we had to add line “$ORACLE_HOME/lib “ in
, 2000 12:28 AM
Subject: problem connecting to oracle with DBD-Oracle-1.06/DBI-1.14
with
Perl version v5.6.0 for Apache/1.3.12 (Unix) mod_perl/1.24
mod_ssl/2.6.6
OpenSSL/0.9.5a
> I've got a system running the following:
>
> Perl version v5.6.0 for Apache/1.3.12 (Unix) mod_perl/1.24
m
redhat linux 6.2
- Original Message -
From: "Richard Routh/Tampa/IBM" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, October 27, 2000 12:47 AM
Subject: Re: problem connecting to oracle with DBD-Oracle-1.06/DBI-1.14 with
Perl version v5.6.0 for Apache/1.3.1
Oops correction to below: should read ORA-12154
ORA-12154 (DBD ERROR: OCIServerAttach)
- Original Message -
From: "HotMail: Bill" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, October 27, 2000 12:28 AM
Subject: problem connecting to oracle with DBD-Ora
]
In the middle of difficulty lies opportunity. - Albert Einstein
"HotMail: Bill" <[EMAIL PROTECTED]> on 10/26/2000 11:28:53 AM
To: <[EMAIL PROTECTED]>
cc:
Subject: problem connecting to oracle with DBD-Oracle-1.06/DBI-1.14 with
Perl version v5.6.0 for Apache/1.3.1
HotMail: Bill [mailto:[EMAIL PROTECTED]] wrote:
> I've got a system running the following:
>
> Perl version v5.6.0 for Apache/1.3.12 (Unix) mod_perl/1.24 mod_ssl/2.6.6
> OpenSSL/0.9.5a
>
> If I run the cgi scripts from command line they connect to the oracle
> database just fine.
>
> If I run the
HotMail: Bill wrote:
> If I run the cgi scripts from command line they connect to the oracle
> database just fine.
>
> If I run them under the webserver (apache::registry), the cannot connect to
> the database.
> ORA-12054 error.
>
> Has anyone seen this before or have an idea on how to track do
I've got a system running the following:
Perl version v5.6.0 for Apache/1.3.12 (Unix) mod_perl/1.24 mod_ssl/2.6.6
OpenSSL/0.9.5a
If I run the cgi scripts from command line they connect to the oracle
database just fine.
If I run them under the webserver (apache::registry), the cannot connect to
> -Original Message-
> From: Daniel Hutchison [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, October 22, 2000 2:16 PM
> To: [EMAIL PROTECTED]
> Subject: DBD-Oracle
>
>
> I just transplanted our website from a computer that had only Net8
> installed, to a compute
] Carp.pm: Use of uninitialized value at
/usr/local/lib/perl5/5.6.0/Carp.pm
line 119.
[Sun Oct 22 14:03:49 2000] Carp.pm: Use of inherited AUTOLOAD for non-method
DBD::Oracle::ORA_OCI() is
deprecated at
/usr/local
The 'surgery on Oracle' technique described in the README.java file in
the DBD::Oracle 1.06 distribution fixed all the problems I was having
with DBD::Oracle and mod_perl.
Whew.
--
Larry Mulcahy [EMAIL PROTECTED]
PGP public key a
ARGGGHHH.
I'm trying to get the above combination working.
DBD::Oracle was a very tough build. I am afflicted with the 'You must
install a Solaris patch to run this version of the Java runtime' bug.
Using the solution described at
http://x55.deja.com/[ST_rn=ps]/getdoc.xp?AN=61
1 - 100 of 127 matches
Mail list logo
