奇怪的数据，select出来明明是0.0140625，但通过round(vv,6)出来的却没有四舍五入。按理应该得到：0.014063，实际却得到：0.014062。违背了四舍五入的原则。
案例：
drop table tt ;
create table tt as
select a, v, exp(sum(ln(1 + v)) over(order by rownum)) - 1 x
from (select a, lag(a, 1, a) over(order by r desc) / a - 1 v
from (select 1.2980 a, 2 r
from dual
union all
select 1.2800 a, 1 r from dual))
SQL> select a, v, round(v,6) round_v, x, round(x,6) round_x from tt a;
A V ROUND_V x ROUND_x
---------- ---------- ---------- ---------- ----------
1.298 0 0 0 0
1.28 0.0140625 0.014063 0.0140625 0.014062
仔细观察以上结果，可发现字段v和字段x是“相同”的，都是0.0140625,。但是对这两个字段同样的round 6却出现了不同的结果。v对应的round_v是0.014063，即四舍五入了。而x对应的round_x是0.014062，没有四舍五入。
进一步dump后发现，其实内部的数据存储是不一样的：
v的dump结果：
Typ=2 Len=5: 192,2,41,63,51
x的dump结果：
Typ=2 Len=20: 192,2,41,63,50,100,100,100,100,100,100,100,100,100,100,100,100,100
同样的数据，存储的差异却很大。
现在，再来深入挖掘一下，对x的dump结果进行翻译：
有192得到指数位：192-193=-1
然后再得到各个数字位：
(2 - 1) * 100^ (-1 - 0) +
(41 - 1) * 100^( -1 - 1) +
(63 - 1) * 100^( -1 - 2) +
(50 - 1) * 100^( -1 - 3) +
(100 - 1) * 100^( -1 - 4)
=0.0140624999
现在，知道为什么了。
因为Oracle内部的存储是0.0140624999，也就是说，小数点后第七位是4，而不是5，因此四舍五入的时候没有“入”。v的翻译结果就是0.0140625，因此“入”了。
不知道这是显示的问题还是Oracle处理的一个bug，出现这个问题的因素有两个：
1、exp ln函数的使用。如果直接使用加减乘除是可以得到正确的结果的。
2、只有x.xxxxx49999这种情况才会导致数据差异。由此导致的问题还是比较明显的。