Same query in 9i & 11g returning different counts

Question

Recently our DB was upgraded from 9i to 11g. We observed some weird results like same query returning more records in 11g than in 9i. I later found out that was because of Null values. I used below commands to achieve same results.
1)     ALTER session set optimizer_features_enable='9.2.0'; -
2)     SELECT /*+ optimizer_features_enable=('9.2.0' )*/ *
FROM TABLE_NAME
WHERE
ORDER BY COL1 DESC , COL2 ASC,COL3 ASC;
Do we have any documentation/material/link which explains this behavior? Any documentation on data type difference between 9i & 11g? Similar issue i observed in connect by prior.I had to select level in order to get the same records but in 9i without selecting level also we were getting desired result.
Thanks

Answer 1

Hi,
MSINHA wrote:
Recently our DB was upgraded from 9i to 11g. We observed some weird results like same query returning more records in 11g than in 9i. I later found out that was because of Null values. I used below commands to achieve same results.
1)     ALTER session set optimizer_features_enable='9.2.0'; -
2)     SELECT /*+ optimizer_features_enable=('9.2.0' )*/ *
FROM TABLE_NAME
WHERE
ORDER BY COL1 DESC , COL2 ASC,COL3 ASC;If you're getting any results other than an error message, then I don't believe you're running the query above. You need include some condition in the WHERE clause, or leave out the WHERE clause altogether.
Do you have row-level security in either database?
As Blushadow said, post a complete test script that people can use to re-create the problem and test their ideas. Include CREATE TABLE and INSERT statements for some sample data, and the complete query that you're using. If you are using dbms_rls row-level security, include the function and the code to enable it.
There's no version 9h or 9j, so it's kind of silly to say you're using 9i. The same goes for 10g. Why not give the actual version numbers, such as 9.2.0.6.0 and 10.2.0.3.0?
See the forum FAQ {message:id=9360002}