Compare 2 numbers with different precision

Question

Hi all,
Using DB 10.2.0.5, I've encountered a strange behaviour today while trying to compare ORA_ROWSCN with a previous SCN sored in a column.
SELECT
  h.id HID,
  h.ora_rowscn HSCN,
  o.id OID,
  o.scn OSCN,
  h.ora_rowscn-o.scn DIFF
FROM
  har@REMOTE h LEFT JOIN other o ON (h.id=o.id)
WHERE
  h.ORA_ROWSCN > o.scn
ORDER BY 5 desc ;
       HID       HSCN        OID       OSCN       DIFF
...{snip}...
      4213 5093868663       4213 5092916724     951939
1157 rowsWhile casting o.scn to a number gives me another resultset (this one is correct):
SELECT
  h.id HID,
  h.ora_rowscn HSCN,
  o.id OID,
  o.scn OSCN,
  h.ora_rowscn-o.scn DIFF
FROM
  har@REMOTE h LEFT JOIN other o ON (h.id=o.id)
WHERE
  h.ORA_ROWSCN > to_number(o.scn)
ORDER BY 5 desc ;
       HID       HSCN        OID       OSCN       DIFF
...{snip}...
     70949 5093865558      70949 5093847070      18488
2114 rowsI got the same result if I use NVL(o.scn,0) rather than TO_NUMBER(o.scn).
I can't find out why this happens. Obviously, the ">" condition doesn't match when the difference is too small.
AFAIK, ora_rowscn is a NUMBER while my "scn" column is a NUMBER(12) (which should be sufficient to store my DB or remote DB's SCN).
Does anyone has an explanation?
Thanks!

Answer 1

Thank you, I've marked both of your message Helpful.
@Solomon, maybe you are right, I'll get a try with Materialized Views.
About my comparison problem, I think I haven't targeted the right spot. Maybe it is an index+ora_rowscn problem. Here is my execution plan:
SQL>  SELECT h.id hid, h.ora_rowscn hscn, o.id oid, o.scn oscn, h.ora_rowscn-o.scn diff
FROM har@REMOTE h, other o
WHERE
   h.id=o.id(+) AND
   h.ORA_ROWSCN > o.scn
ORDER BY 5 desc ;
| Id  | Operation                | Name             | Rows  | Bytes | Cost (%CPU)| Time     | Inst   |IN-OUT|
|   0 | SELECT STATEMENT         |                  |   683 | 17075 |    94   (4)| 00:00:02 |        |      |
|   1 |  SORT ORDER BY           |                  |   683 | 17075 |    94   (4)| 00:00:02 |        |      |
|*  2 |   HASH JOIN              |                  |   683 | 17075 |    93   (3)| 00:00:02 |        |      |
|   3 |    REMOTE                | HAR              | 13658 |   173K|    46   (0)| 00:00:01 | REMOTE | R->S |
|   4 |    VIEW                  | index$_join$_002 | 14024 |   164K|    46   (3)| 00:00:01 |        |      |
|*  5 |     HASH JOIN            |                  |       |       |            |          |        |      |
|*  6 |      INDEX RANGE SCAN    | IDX_OTHER_SCN    | 14024 |   164K|     3  (34)| 00:00:01 |        |      |
|   7 |      INDEX FAST FULL SCAN| SYS_C006381      | 14024 |   164K|    54   (0)| 00:00:01 |        |      |
Predicate Information (identified by operation id):
   2 - access("H"."ID"="O"."ID")
       filter("O"."SCN"<"H"."ORA_ROWSCN")
   5 - access(ROWID=ROWID)
   6 - access("O"."SCN"<"H"."ORA_ROWSCN")
Remote SQL Information (identified by operation id):
   3 - SELECT "ID","ORA_ROWSCN" FROM "HAR" "H" (accessing 'REMOTE' )Where SYS_C006381 is an index on OTHER.ID and IDX_OTHER_SCN is an index on OTHER.SCN column.
As soon as I drop the latter index, I get the correct resultset:
SQL> drop index IDX_OTHER_SCN ;
| Id  | Operation           | Name     | Rows  | Bytes | Cost (%CPU)| Time     | Inst   |IN-OUT|
|   0 | SELECT STATEMENT    |          |   683 | 17075 |   117   (3)| 00:00:02 |        |      |
|   1 |  SORT ORDER BY      |          |   683 | 17075 |   117   (3)| 00:00:02 |        |      |
|*  2 |   HASH JOIN         |          |   683 | 17075 |   116   (2)| 00:00:02 |        |      |
|   3 |    REMOTE           | HAR      | 13658 |   173K|    46   (0)| 00:00:01 | REMOTE | R->S |
|   4 |    TABLE ACCESS FULL| OTHER    | 14024 |   164K|    69   (2)| 00:00:01 |        |      |
Predicate Information (identified by operation id):
   2 - access("H"."ID"="O"."ID")
       filter("O"."SCN"<"H"."ORA_ROWSCN")
Remote SQL Information (identified by operation id):
   3 - SELECT "ID","ORA_ROWSCN" FROM "HAR" "H" (accessing 'REMOTE' )Well, I can't figure out what's wrong, but the solution is here. Maybe a limitation of ORA_ROWSCN pseudocolumn...