Dbd Error Ocisessionend During Global Destruction
Q&A Tutorials Poetry RecentThreads NewestNodes Donate What'sNew on Mar 29, 2005 at 16:34UTC ( #443177=perlquestion: print w/replies, xml ) Need Help?? guice has asked for the wisdom of the Perl Monks concerning the following question: Anybody have any problems with Parallel::ForkManager or maybe even DBI eating up resources? I currently run a script that forks upto 5 children using ForkManager with upto a total 140 children by the time it's done. When I run a big load (133), my CPU load slowly climbs from 5 to over 20 by the time it finishes. Once the whole script is done, it drops back down to ~5-7ish (not immediately, but 2x the speed it climbed). Any thoughts? I do everything by the book; Opening a DBI process per child, closing and unsetting the veriable for each close. -- philip We put the 'K' in kwality! Comment on Parallel::ForkManager eating up Resources? Replies are listed 'Best First'. Re: Parallel::ForkManager using up Resources? by cazz (Pilgrim) on Mar 29, 2005 at 16:49UTC Ouch. 140 children all with their own DB connections? And you create a new connection per child? Surely there is a better way. First off, you should probably cut down the number of children. Most database performance numbers fall off pretty quickly when you start adding a number of children doing anything more than reads. You should also look at using a pool of database handles. Why create and then close database connections over and over again if you don't have to? I sped up the performance of a data loading script by a few orders of magnitude by moving the dbh create/destroy outside of the main loop.[reply] Re^2: Parallel::ForkManager using up Resources? by guice (Scribe) on Mar 29, 2005 at 16:52UTC It's a max of 5 children at once. I tried to use a pool, but couldn't figure out a way to make sure none of the children used a wrong handle. Care to share how you got past this one? I tried an array with $cnt++ % 5, but no way t
Message ID: 4.3.2.7.2.20021113160734.00b391c8@malone.cisco.com Hi All, I did a trial and error by reducing the {LongReadLen} and the script is running without any problems. #$dbh_prod->{LongReadLen} = 100000000; $dbh_prod->{LongReadLen}=30000000; My 'select' reads the data from a long field, specifying {LongReadLen} to a higher value might have been causing the unable to allocate memory error. Thanks, -Jibo At 04:05 PM 11/13/2002 -0800, Steven Hajducko wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Also, > >Why use eval? I believe http://www.perlmonks.org/?node_id=443177 ( from my minor experience here.. ) that >eval is meant to do 2 things. > >a) execute code at runtime - > my $code_snip = "print 'hi\n'"; > eval $code_snip > > would print: > > hi > >b) trap errors that would otherwise kill the program. > >In your case, you're killing your script anyways http://www.nntp.perl.org/group/perl.dbi.users/2002/11/msg15001.html if the eval fails. >So why not just do... > >print $stmt2; >$csr2 = $dbh_prod->prepare($stmt2) or die >$dbh_prod->trace(6),"\n\nCould not prepare statement: >\n",$dbh_prod->errstr(); > >Like I said, my perl experience is small, so I'm not sure if maybe >the whole eval testing thing is taking up too much memory or what. > >Hope it helps, > >- -- >sh > > >- -----Original Message----- >From: Jibo John [mailto:jijohn@cisco.com] >Sent: Wednesday, November 13, 2002 3:31 PM >To: dbi-users@perl.org >Subject: DBI giving unable to allocate memory error > > >Folks, > >I am running into a problem here: > >My script is running on: > >Solaris SunOS 5.8 Generic_108528-15 sun4u sparc >SUNW,Ultra-Enterprise >Perl 5.6.1 >DBI 1.18 >DBD::Oracle 1.07 > > >It gives the following error while preparing a select query: >DBD::Oracle::db prepare failed: ORA-01062: unable to allocate memory >for >define buffer (DBD ERROR: OCIDefineByPos) at script.pl line 159. > >Here is the code snippet: >print $stmt2; >eval{ >$csr2 = $dbh_prod->prepare($stmt2); >}; >if($@){ > $dbh_prod->trace(6); > die "prepare failed : $DBI::errstr\n" >} >
Here is what the Oracle utility oerr returns for 1062 code: 01062, 00000, "unable to allocate memory http://www.nntp.perl.org/group/perl.dbi.users/2002/11/msg15000.html for define buffer" // *Cause: Exceeded the maximum buffer size for http://marc.info/?l=dbi-dev&m=95252168523130&w=2 current plaform // *Action: Use piecewise fetch with a smaller buffer size // *Action: Use a client application linked with V8 (or higher) libraries.60 Regards, Ellen Yu On Wed, 13 Nov 2002, Jibo John wrote: > Folks, > > I am running into a dbd error problem here: > > My script is running on: > > Solaris SunOS 5.8 Generic_108528-15 sun4u sparc SUNW,Ultra-Enterprise > Perl 5.6.1 > DBI 1.18 > DBD::Oracle 1.07 > > > It gives the following error while preparing a select query: > DBD::Oracle::db prepare failed: ORA-01062: unable to allocate memory for > define buffer (DBD ERROR: dbd error ocisessionend OCIDefineByPos) at script.pl line 159. > > Here is the code snippet: > print $stmt2; > eval{ > $csr2 = $dbh_prod->prepare($stmt2); > }; > if($@){ > $dbh_prod->trace(6); > die "prepare failed : $DBI::errstr\n" > } > > A 'select count(*)' of the same query $stmt2 runs without any issues. > > Here is the Oracle trace 6 output: > > DBI::db=HASH(0x208b10) trace level set to 6 in DBI 1.18-nothread > Note: perl is running without the recommended perl -w option > -> $DBI::errstr (&) FETCH from lasth=DBI::db=HASH(0x208b10) > prepare failed : ORA-01062: unable to allocate memory for define buffer > (DBD ERROR: OCIDefineByPos) > -> DESTROY for DBD::Oracle::db (DBI::db=HASH(0x208b10)~INNER) > Issuing rollback() for database handle being DESTROY'd without explicit > disconnect() during global destruction. > OCITransRollback(22d0e4,22d30c,0)=SUCCESS > OCISessionEnd(22d0e4,22d30c,239724,0)=SUCCESS > OCIServerDetach(22d150,22d30c,0)=SUCCESS > OCIHandleFree(239724,9)=SUCCESS > OCIHandleFree(22d150,8)=SUCCESS > OCIHandleFree(22d0e4,3)=SUCCESS > OCIHandleFree(22d30c,2)=SUCCESS > <- DESTROY= undef during global destruction. > > > Any help regarding this is highly appreciated. > > Thanks, > -Jibo > >
RAW] *** From dbi-users - To unsubscribe, see the end of this message. *** *** DBI Home Page - http://www.symbolstone.org/technology/perl/DBI/ *** Fundamentally I'm pretty sure this has to be an Oracle problem. It is odd that the error changes from 12545: $ oerr ora 12545 12545, 00000, "Connect failed because target host or object does not exist" // *Cause: The address specified is not valid, or the program being // connected to does not exist. // *Action: Ensure the ADDRESS parameters have been entered correctly; the // most likely incorrect parameter is the node name. Ensure that the // executable for the server exists (perhaps "oracle" is missing.) // If the protocol is TCP/IP, edit the TNSNAMES.ORA file to change the // host name to a numeric IP address and try again. which is understandable, to 12154: $ oerr ora 12154 12154, 00000, "TNS:could not resolve service name" // *Cause: The service name specified is not defined correctly in the // TNSNAMES.ORA file. // *Action: Make the following checks and correct the error: // - Verify that a TNSNAMES.ORA file exists and is in the proper // place and accessible. See the operating system specific manual // for details on the required name and location. // - Check to see that the service name exists in one of the // TNSNAMES.ORA files and add it if necessary. // - Make sure there are no syntax errors anywhere in the file. // Particularly look for unmatched parentheses or stray characters. // Any error in a TNSNAMES.ORA file makes it unusable. See // Chapter 4 in the SQL*Net V2 Administrator's Guide. If // possible, regenerate the configuration files using the Oracle // Network Manager. which is a little odd, and then gets 'stuck' with that error after Oracle's back up. I think you should try talking to Oracle about it. (Don't mention Perl, just talk about your "OCI application".) Tim. On Wed, Mar 08, 2000 at 03:27:44AM -0800, Chris Nokleberg wrote: > Hi -- > > I was searching for an answer to my problem in the archives and came across your > message (attached below) asking for reconnection problems after a "shutdown > abort". I believe this is happening to me. > > Configuration: > > apache 1.3.9 > modperl 1.21 > Oracle 8i (8.1.6) > (DBD compiled against 8.0.5 libs, still works) > DBD-Oracle-1.03 > DBI-1.13 > Solaris 2.7 (both client and server) > > The problem: > > 1) Everything runs fine, no other problems with Oracle, DBI, mod_perl. > 2) Log on to DB machine as internal, do a shutdown abort. > 3) httpds correct detect no database connection, take appropriate action. > 4) Startup oracle again. > 5) http