Skip to Main Content
  • Questions
  • Is it possible to get duplicates using ORA_ROWSCN in the filter?

Breadcrumb

Question and Answer

Chris Saxon

Thanks for the question, Daniel.

Asked: June 20, 2019 - 12:05 pm UTC

Last updated: July 29, 2019 - 9:44 am UTC

Version: Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit

Viewed 1000+ times

You Asked

Hello Tom,

I just wanted to ask you if the problem that we are facing could even be related to Oracle, as we can't find a reason and we don't have access to the sources to check how the source objects are created.

Is it even possible that a select like this one is returning duplicates, when these duplicates are actually the same record but with the actual and the previous values of a particular updated field?

I mean that if you look for that record by ID, you only find the updated one (obviously), but when throwing the query we get both values, the new and the old values. I have been reading about the ora_rowscn and the flashback queries, and it makes me think that is could be related, but I don't understand how or if it is even possible without using the AS OF clause.

SELECT t1.SOME_FIELDS
      ,to_number(t1.ORA_ROWSCN) ORAROWSCN
      ,t1.MORE_FIELDS
FROM TABLE t1
WHERE (
 t1.START_DATE < TO_DATE($PARAMETER1, 'YYYYMMDD')
 OR 
        t1.START_DATE > TO_DATE($PARAMETER2, 'YYYYMMDD')
      )
      AND 
      (
        t1.END_DATE < TO_DATE($PARAMETER1, 'YYYYMMDD')
        OR 
        t1.END_DATE > TO_DATE($PARAMETER2, 'YYYYMMDD')
      )
      AND t1.ORA_ROWSCN >= 1
ORDER BY t1.ID


If you think that it could be related to Oracle I'll be glad to paste more code or whatever you ask, but I really don't know where to start right now. Otherwise, excuse me.

NOTE 1: We discarted the possibility of that record being updated during the extraction
NOTE 2: We don't know the purpose of using the ORA_ROWSCN in the filter, the query was created time ago and undocumented :(

Thanks!

and Chris said...

I'm not aware of a situation where this could happen. To help us diagnose, we really need a test case:

- create table
- data in the form of insert into statements
- the query you run

Sharing the execution plan for the query (including access/filter predicates) may also help.

PS - is the query really checking that ora_rowscn is one or more every time? Or is that just an example?

Rating

  (3 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

Andre Santos, June 20, 2019 - 3:29 pm UTC

Was the table created with the ROWDEPENDENCIES clause?

Working on it

Daniel Navarro, June 20, 2019 - 3:29 pm UTC

Hello Chris,

Thanks for your quick response, I'm trying to run some tests over the source tables right now, but I couldn't reproduce the scenario yet. We have very limited acces to the source system.

We have some legacy code from a previous provider, and yes, the query checks the ora_rowscn like that.

This is only happening when we are reading directly from the operational database, as we usually extracted the data from the daily copy of that database but due to some problems with the copy we started reading directly from the operational. I understand that if the database is copied, the information related to the "past" of the record is lost. In the copy this never happened
Chris Saxon
June 20, 2019 - 3:36 pm UTC

the query checks the ora_rowscn like that.

If it's always checking for >= 1, you should be able to remove it. The SCN will be at least one, so this is in effect an "always true" condition.

Daniel Navarro, July 26, 2019 - 8:00 am UTC

Hello Chris,

We performed some tests and couldn't reproduce the error, but as you said, the behaviour doesn't make much sense. We removed the pseudocolumn from the queries and will be running into production soon, so if we get duplicates again and can't find the reason I'll try to get all the info for a test case.

Thanks.
Chris Saxon
July 29, 2019 - 9:44 am UTC

Cheers for the update; let us know how you get on.

More to Explore

SQL

The Oracle documentation contains a complete SQL reference.