stopher Jones [mailto:christopher.jo...@oracle.com]
Sent: Monday, January 15, 2018 6:56 PM
To: dbi-users@perl.org
Subject: Re: Hunting down (possible) memory leak in DBD::Oracle
On 16/1/18 9:17 am, Fennell, Brian wrote:
> $ egrep -B1 -A20 -i 'invalid write'
> /copy/sandbox/feeds/data/se
On 16/1/18 9:17 am, Fennell, Brian wrote:
$ egrep -B1 -A20 -i 'invalid write'
/copy/sandbox/feeds/data/search4_1/valgrind-log.txt | head -22
==19402==
==19402== Invalid write of size 4
==19402==at 0xBD747E6: __intel_ssse3_rep_memcpy (in
I got this case running with valgrind -
Valgrind reported -
8 invalid writes, 8 invalid writes, 2239 accesses to uninitialized values.
All invalid writes have a stack trace leading back to
XS_DBD__Oracle__st_fetchrow_array (Oracle.xsi:662) and ora_st_fetch
(oci8.c:4032)
Details follow:
export
John,
Thanks for your incites. I tried what you said.
I read up on NVARCHAR2 v VARCHAR2 - interesting. I also see that Oracle has a
way (more than one way) to specify if a VARCHAR2 should contain bytes or
characters - further while a VARCHAR2(11 byte) and a VARCHAR2(11 char) are
different
On 2017-12-19 20:55:30 +, Fennell, Brian wrote:
> And, also with the log level set to 15 here are the LAST 200 lines
[...]
> -> fetchrow_array for DBD::Oracle::st
> (AAA::DBI::Connection::st=HASH(0x3abd310)~0x39f75f0) thr#24d4010
> dbd_st_fetch 6 fields...
> dbd_st_fetched
And, also with the log level set to 15 here are the LAST 200 lines
3abd340 (field=0): '1127646'
field #2 with rc=0(OK)
3abd340 (field=1): '1268251'
field #3 with rc=0(OK)
3abd340 (field=2): 'a...'
field #4 with rc=0(OK)
With the log level set to 15 here are the first 200 lines of log
AAA::DBI::Connection::db=HASH(0x3abce00) trace level set to 0x0/15 (DBI @
0x0/0) in DBI 1.637-ithread (pid 12594)
-> STORE for DBD::Oracle::db
(AAA::DBI::Connection::db=HASH(0x3abce00)~INNER 'RowCacheSize' 2097152)
John,
Thanks for the ideas to change the cache params - I will try that!
Here is the SQL and the field types:
SELECT
d.ROW_NUMBER,
d.f1,
d.f2,
d.f3,
d.f4,
d.f5
FROM
(
SELECT /*+ FULL(A) PARALLEL(A 6) */
rownum ROW_NUMBER,
A.field1 f1 ,
com>
Sent: December 18, 2017 11:25 AM
To: John Scoles; dbi-users@perl.org
Subject: 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 Sys
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
2, 3, 4, 5
) d
WHERE
d.row_number < 202
AND d.row_number >= 100
-Original Message-
From: Howard, Chris [mailto:howa...@prpa.org]
Sent: Monday, December 18, 2017 9:21 AM
To: Fennell, Brian <fenne...@radial.com>; dbi-users@perl.org
Subject: RE: Hunting dow
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
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
umber >= 100
-Original Message-
From: Howard, Chris [mailto:howa...@prpa.org]
Sent: Monday, December 18, 2017 9:21 AM
To: Fennell, Brian <fenne...@radial.com>; dbi-users@perl.org
Subject: RE: Hunting down (possible) memory leak in DBD::Oracle ** EXTERNAL **
Same database... do
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
15 matches
Mail list logo
