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:43:09 +0100
Message-ID: <4D518EBD.8020805_at_gmail.com>
On 08.02.2011 19:37, Maxim Demenko wrote:
> 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
Date: Tue, 08 Feb 2011 19:43:09 +0100
Message-ID: <4D518EBD.8020805_at_gmail.com>
On 08.02.2011 19:37, Maxim Demenko wrote:
> 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
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 Received on Tue Feb 08 2011 - 12:43:09 CST