RE: Hunting down (possible) memory leak in DBD::Oracle ** EXTERNAL **

Thanks for the reply, Howard, I am using the exact same database - a test database that has copies of the production data put into it once a day - besides that it doesn't change much (if at all) during the day. The SQL I am using doesn't leave out a "bad guy" - I thought of that and actually

Re: Hunting down (possible) memory leak in DBD::Oracle

Hmm this type of DBD::Oracle debugging will be tricky. Could be almost anything. You are jumping versions in a big way but that still should be ok A few questions 1) What is the ORA-NN in question 2) Set trace to 15 to see if that give you more details 3) What are the type of

RE: Hunting down (possible) memory leak in DBD::Oracle

John, Thanks so much for your reply! I have put off this work for a few years and now the pressure is on - the original box and OS are so old that the DBA and System Engineer and the Operations manager have all ganged up on me. I suppose I could try and work around by downgrading both the perl

RE: Hunting down (possible) memory leak in DBD::Oracle ** EXTERNAL **

Good question - I have asked DBA and am waiting for a reply. -Original Message- From: Howard, Chris [mailto:howa...@prpa.org] Sent: Monday, December 18, 2017 11:36 AM To: Fennell, Brian ; dbi-users@perl.org Subject: RE: Hunting down (possible) memory leak in

RE: Hunting down (possible) memory leak in DBD::Oracle ** EXTERNAL **

Ok . . . I am already benefiting from the support from this list : - ) I noticed that I was actually ordering my query BY rownum (which doesn't make much sense . . . and perhaps oracle's optimizer recognized this and ignored the pseudo column.) Just to be sure, I change the query and then

RE: Hunting down (possible) memory leak in DBD::Oracle

Pluta, Looks like it is worth a try - when I looked at the project before it looked like it was for installing a "per user" perl. Does it work for root / all users on a box as well? Brian