前段时间我们进行数据库的升级测试，测试的规模和投入的力量都是很大的。从9i到10g，本以为会非常顺利（ORACLE产品都自家兄弟，并且都是比较可靠的RELEASE 2 ）,但是确实发现了一个重大的问题。
在一个通过统计查询显示趋势图的页面，原本显示的很正常的图形在接入10g数据库后显示的乱七八糟。-:(
后来终于查明：
鉴于对现有应用影响最小的原则：将该排序方法在数据库服务器端停止。 即修改了ORACLE10g的隐含参数：_gby_hash_aggregation_enabled=false，输出的趋势图终于没有问题了。
良好的测试，尤其是优良的测试用例，真的可以让我们自己的应用在上线前避免很多错误，甚至上线后发现问题我们仍然可以比较快速的定位问题。没有什么不可能，错误可以无处不在，并且往往是那些没有被测试或者认真测试过的地方 -:)
在一个通过统计查询显示趋势图的页面，原本显示的很正常的图形在接入10g数据库后显示的乱七八糟。-:(
后来终于查明：
starting with 10g, Oracle uses the new HASH GROUP BY mechanism which will not guarantee the result in any order unless ORDER BY clause is specified.
In a nutshell, in Oracle 9i, GROUP BY clause gives result in sort order, this behavior has changed from 10g onwards.
The general and Oracle recommendation is, to add the ORDER BY clause in order to have 100% guaranteed order by result.
In a nutshell, in Oracle 9i, GROUP BY clause gives result in sort order, this behavior has changed from 10g onwards.
The general and Oracle recommendation is, to add the ORDER BY clause in order to have 100% guaranteed order by result.
鉴于对现有应用影响最小的原则：将该排序方法在数据库服务器端停止。 即修改了ORACLE10g的隐含参数：_gby_hash_aggregation_enabled=false，输出的趋势图终于没有问题了。
良好的测试，尤其是优良的测试用例，真的可以让我们自己的应用在上线前避免很多错误，甚至上线后发现问题我们仍然可以比较快速的定位问题。没有什么不可能，错误可以无处不在，并且往往是那些没有被测试或者认真测试过的地方 -:)
