Oracle Fractional Date Constraints Meaning

Question

I have a MY_VIEW_A which is a union of MY_VIEW_B and MY_MATERIALIZED_VIEW_C.

MY_VIEW_B has a constraint of MY_DATE > (SYSDATE - 1) + 1 / 24.

MY_MATERIALIZED_VIEW_C is updated by a job whose interval is TRUNC(SYSDATE+1) + 1/24. Note this might be invalid...the issue I am working on is that the job stopped running. Perhaps due to a 10G 11G migration.

I am wonder what the 1/24 means in these situations. From looking around, I believe it is indicating 1 hour. So then I think the following might be what is going on.

1. MY_VIEW_B only retrieves entities that have a MY_DATE that is in the last 23 hours.
2. MY_MATERIALIZE_VIEW_C is updated every 25 hours.

However, this seems to be a problematic scenario. As an entity made 24 hours ago might not be in either view.

Am I not understanding something? Or is the setup indeed faulty?

Answer 1

1/24 does indeed convert to 1 hour in this context. Personally, I prefer using interval notation rather than adding and removing fractional days.

SYSDATE - interval '23' hour

seems much more readable to me.

Your materialized view is updated every 24 hours. It will be updated every day at 1am.

TRUNC(SYSDATE+1) + 1/24

returns tomorrow at 1am. trunc(sysdate) is midnight today, trunc(sysdate+1) is midnight tomorrow, and trunc(sysdate+1) + 1/24 is tomorrow at 1am.

If you are querying the view between midnight and whenever the materialized view finishes refreshing (presumably some time after 1am), there may be rows that are more than 23 hours old that are not yet reflected in the materialized view. Depending on the architecture (and the reason that entries apparently exist in two different objects), I'd be more concerned about duplicate rows. At 8am, for example, the materialized view will have data that is only 7 hours old (presumably), which could also be returned from my_view_b (I assume that when you say "constraint" you really mean that there is a predicate on my_view_b like WHERE MY_DATE > (SYSDATE - 1) + 1 / 24).

Taking a step back, though, the approach seems dubious to me. Having detail level data in a materialized view and in a separate table that is accessed via a view and then going to the expense of doing a UNION to remove duplicates seems highly dubious to me. Materialized views will often improve performance if you are using them to pre-aggregate data or at least to pre-compute something that is costly to compute at runtime. That doesn't appear to be what you're using them for, though, so I'm rather dubious that this is doing anything other than causing you to use more disk space, put more pressure on the buffer cache, and suffer worse performance.