Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

CHAPTER 7 ■ CONCURRENCY AND MULTI-VERSIONING 243
3. They then pull all of the rows from the transactional system—a full SELECT * FROM ➥
TABLE—to get the data warehouse initially populated.
4. To refresh the data warehouse, they remember what time it is right now again. For
example, suppose an hour has gone by and it is now 10:00 am on the source system.
They will remember that fact. They then pull all changed records since 9:00 am—the
moment before they started the first pull—and merge them in.
■Note This technique may “pull” the same record twice in two consecutive refreshes. This is unavoidable
due to the granularity of the clock. A MERGE operation will not be affected by this (i.e., update existing record
in the data warehouse or insert a new record).
They believe that they now have all of the records in the data warehouse that were modified
since they did the initial pull. They may actually have all of the records, but just as likely
they may not. This technique does work on some other databases—ones that employ a locking
system whereby reads are blocked by writes and vice versa. But in a system where you have
non-blocking reads, the logic is flawed.
To see the flaw in this example, all we need to do is assume that at 9:00 am there was at
least one open, uncommitted transaction. At 8:59:30 am, it had updated a row in the table we
were to copy. At 9:00 am, when we started pulling the data, reading the data in this table, we
would not see the modifications to that row; we would see the last committed version of it. If it
was locked when we got to it in our query, we would read around the lock. If it was committed
by the time we got to it, we would still read around it since read consistency permits us to read
only data that was committed in the database when our statement began. We would not read
that new version of the row during the 9:00 am initial pull, but nor would we read the modified
row during the 10:00 am refresh. The reason? The 10:00 am refresh would only pull records
modified since 9:00 am that morning—but this record was modified at 8:59:30 am. We would
never pull this changed record.
In many other databases where reads are blocked by writes and a committed but inconsistent
read is implemented, this refresh process would work perfectly. If at 9:00 am—when
we did the initial pull of data—we hit that row and it was locked, we would have blocked and
waited for it, and read the committed version. If it were not locked, we would just read whatever
was there, committed.
So, does this mean the preceding logic just cannot be used? No, it means that we need
to get the “right now” time a little differently. We need to query V$TRANSACTION and find out
which is the earliest of the current time and the time recorded in the START_TIME column of
this view. We will need to pull all records changed since the start time of the oldest transaction
(or the current SYSDATE value if there are no active transactions):
select nvl( min(to_date(start_time,'mm/dd/rr hh24:mi:ss')),sysdate)
from v$transaction;
In this example, that would be 8:59:30 am—when the transaction that modified the
row started. When we go to refresh the data at 10:00 am, we pull all of the changes that had
occurred since that time, and when we merge these into the data warehouse, we’ll have