( Sorry a repeat of blog posting ... )

I get grumpy when I see negative serial#'s in v
$session_connect_info ... this is almost enough to make a groundhog
run for cover. Looking for sessions not using AES256 encryption ...
running 11.1.0.7.5 ( patchset update about to go to 11.1.0.7.6 ).

This query shows rows from v$session_connect_info that have serial#'s
less than zero.

select * from ( select sid, serial#, authentication_type,
network_service_banner from v$session_connect_info where
instr(network_service_banner,'AES256') > 0 ) where serial# < 1

SID,SERIAL#,AUTHENTICATION_TYPE,NETWORK_SERVICE_BA NNER
5088,-21485,DATABASE,Oracle Advanced Security: AES256 encryption
service adapter for Linux: Version 11.1.0.7.0 - Product
5301,-29006,DATABASE,Oracle Advanced Security: AES256 encryption
service adapter for Linux: Version 11.1.0.7.0 - Product
5382,-26393,DATABASE,Oracle Advanced Security: AES256 encryption
service adapter for Linux: Version 11.1.0.7.0 - Product

When I check these sessions against v$session the serial# looks ok
( not negative ).

select saddr, sid, serial#, username, osuser, type from v$session
where
sid in ( select sid from
( select sid, serial#, authentication_type, network_service_banner
from v$session_connect_info where
instr(network_service_banner,'AES256') > 0 ) where serial# < 1 )

SADDR,SID,SERIAL#,USERNAME,OSUSER,TYPE
00000002D7C49DD0,5382,39143,I1236,whse,USER
00000002D792E920,5088,44051,I0952,sales,USER
00000002D7B6EC08,5301,36530,I5304,sales,USER

*** I guess I have to volley this over to Oracle Support I did not
find anything relevant yet in my searches.

On Feb 8, 8:37*am, John Hurley <hurleyjo... (AT) yahoo (DOT) com> wrote:
I do not remember ever seeing negative serial# in any of the v$session
views. Interesting and probably a bug. I request you go ahead and
enter a SR with support. Maybe by version 12.2 or 13.1 there will be
a fix.

HTH -- Mark D Powell --

On 08.02.2011 14:37, John Hurley wrote:
I think, you are not quit fair about your version - according to
Bug 183704, you should have running 7.0.13.0 (or anything below 7.0.17)
on HP OpenVMS VAX. On the other side, i may be wrong, as the bug was
asked to be ported to Novell NetWare (literally: "Bug 209306: PLEASE
PORT BUG 183704 TO NETWARE") - so, may be they ported it on demand into
11.1.

;-)))

Seriously, i can't remember seeing negative serial#'s as well, but it is
obviously some kind of integer overflow, so you could try to kill either
the os process or try to play with adding something like
byte/short/integer/word maxvalue for your platform - as supposed in the
first mentioned note

Best regards

Maxim

On 08.02.2011 19:37, Maxim Demenko wrote:
Sorry, was too deep in metalink docs, so, my post before (the serious
part) not directly addressed your question, but, i think, the rest still
applies - some otherflow bug, probably best addressed by MOS.

Best regards

Maxim

Maxin:

# Sorry, was too deep in metalink docs, so, my post before (the
serious part) not directly addressed your question, but, i think, the
rest still applies - some otherflow bug, probably best addressed by
MOS.

Yeah thanks I had found the one you looked at ... like I said it's not
in v$session but in session_connect_info ... not causing me any grief
right now just confused me.

I will have to ante up and create an SR that they probably will not be
able to duplicate ... c'est la vie.