Corrupt Numeric Data

Question

Hi,
when I issue a very simple statement:
select *
from table_name
where numeric_value > 0
I get row which have a numeric_value equal to 0.
We tried to rebuild the indices and the to update the statistics, but does not help.
Looks like an internal corruption of the data, does anyone have a guess, what it could be?
Is there a way to see the physical representation of the data on disk? Maybe the corruption can be find out looking on that.
Thanks for you effort
Bernhard Slominski

Answer 1

Bernhard:
Your result intrigued me, so I did a little research. There is an article on Metalink (Note 1007641.6) that outlines Oracle's internal representation of numbers. The gist of it goes like this.
A number is (almost) always stored as a minimum of 2 bytes. The first byte gives the sign and an exponent, the remaining bytes give the value in a base 100 notation.
The high order bit in the first byte is the sign, it will be set for a positive number. The remaining 7 bits give the exponent in excess 64 notation. The second thru whatever bytes allow you to calculate the number. To avoid storing null bytes 1 is always added to each of the remaining bytes.
Negative numbers require a little more manipulation, but to calculate a positive number from the internal representation:
SQL> select dump(150) from dual;
DUMP(150)
Typ=2 Len=3: 194,2,51
1. Convert 1st byte to binary.  If the bit 8 is 1 then it is positive
   194 Binary is 11000010 so it is positive.
2. Convert the remaining 7 bits to decimal
   1000010 Decimal is 66
3. Subtract 64 from this to get the exponent
     66 - 64 = 2
4. For each remaining byte, subtract 1 from the number and
   multiply by 100 to the power of (exponent - 1).  If there are decimal points, just keep
   going, using negative exponents for the decimals.
   (2 - 1) * (100 ^ 1) = 1 * 100 = 100
   (51 - 1) * (100 ^ 0) = 50 * 1 =  50
5. Add the results together to get the number
   100 + 50 = 150The dump result you get (193,1) actually does seem to resolve to 0 using this formula.
193 binary is 11000001 so it is positive.
Drop the sign bit and 1000001 decimal is 65
65 - 64 = 1 and
(1 - 1) * (100 ^ 0) = 0
Putting my dump result (128) through the same steps gives a really interesting result.
128 binary is 10000000
So zero seems to be a special case. Even though you really do have a zero stored in your table (I would bet that if you did some arithmetic with that column you would prove it), Oracle is comparing internal representations for the query and obviously
1100000100000001 is greater than 10000000
HTH
John