Re: I get grumpy when I see negative serial#''s in v$session_connect_info ...
From: Maxim Demenko <mdemenko_at_gmail.com>
Date: Tue, 08 Feb 2011 19:37:35 +0100
Message-ID: <4D518D6F.1050000_at_gmail.com>
On 08.02.2011 14:37, John Hurley wrote:
> ( 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_BANNER
> 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.
Date: Tue, 08 Feb 2011 19:37:35 +0100
Message-ID: <4D518D6F.1050000_at_gmail.com>
On 08.02.2011 14:37, John Hurley wrote:
> ( 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_BANNER
> 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.
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 Received on Tue Feb 08 2011 - 12:37:35 CST