Re: SQLPlus version tracking
- From: Yong Huang <yong321@xxxxxxxxx>
- To: William.Blanchard@xxxxxxxxxxxxx
- Date: Fri, 20 Jan 2012 10:42:14 -0800 (PST)
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
--
//www.freelists.org/webpage/oracle-l
Other related posts:
