Re: SQLPlus version tracking

From: Yong Huang <yong321_at_yahoo.com>
Date: Fri, 20 Jan 2012 10:42:14 -0800 (PST)
Message-ID: <1327084934.88170.YahooMailClassic_at_web181217.mail.ne1.yahoo.com>

It looks like only 11g client (including Java thin client) can populate the underlined field of client_version of v$session_connect_info. The problem with this column is caused by the sys_op_version function so we should avoid that.

Here's a my test:

Server: 11.2.0.1.0
My laptop client: 11.2.0.2.0
A Linux box client: 11.2.0.3.0

Before the Linux box client connects, my latop connecting to the server shows:

SQL> select ksuseclvsn, count(*) from x$ksusecon group by ksuseclvsn;

KSUSECLVSN COUNT(*)
---------- ----------

 186647040         60
 186646784        120
         0       1483
 185599744        111

where ksuseclvsn is the column that maps to client_version after going through sys_op_version, and x$ksusecon is the base table for v$session_connect_info.

After my Linux client connects to the database, my laptop shows:

KSUSECLVSN COUNT(*)
---------- ----------

 186647040         60
 186646784        116
 186647296          3
         0       1483
 185599744        111

So I have 4 less for 186646784 and 3 new for 186647296. After multiple tests, I get these cryptic numbers, and shown in hex:

186647040 B200200
186647296 B200300
185599744 B100700
186646784 B200100
186647296 B200300

Take the last for an example. I guess "B" is version 11, "2" is the release, "003" is the minor release, and "00" is the patch level (correct me if I get the terms wrong). I think what just happened is that some unused slot (but probably previously used by a 11.2.0.1 client) is used by my 11.2.0.3.0 client, taking 3 rows (the banner has 3 rows).

The bug with client_version is tracked by multiple bugs, such as 12737014, 8996729. As soon as sys_op_version is fixed, the problem should be fixed. For now, we just need to read x$ksusecon.ksuseclvsn directly and interpret the numbers by ourselves.

Yong Huang

--
http://www.freelists.org/webpage/oracle-l

Received on Fri Jan 20 2012 - 12:42:14 CST