需要修改的是那個“另外數據交換程序”，它不能把本次的SYSDATE記錄下來作為下次抽取的起點，應該去V$TRANSACTION里面找最小的START_TIME, 找不到才用SYSDATE。

TOM"Oracle 9i 10g編程藝術":

7.3.1 一種會失敗的常用數據倉庫技術

我看到，許多人都喜歡用這樣一種常用的數據倉庫技術：

(1) 他們使用一個觸發器維護源表中的一個 LAST_UPDATED 列，這與上一章的 6.2.3 節中討論的

方法很相似。

(2) 最初要填充數據倉庫表時，他們要記住當前的時間，為此會選擇源系統上的 SYSDATE。例

如，假設現在剛好是上午 9:00。 ------------------ 此處就是引起漏洞的原因，需要修改

(3) 然后他們從事務系統中拉(pull)出所有行，這是一個完整的 SELECT * FROM TABLE 查詢，

可以得到最初填充的數據倉庫。

(4) 要刷新這個數據倉庫，他們要再次記住現在的時間。例如，假設已經過去了 1 個小時，現

在源系統上的時間就是 10:00.他們會記住這一點。然后拉出自上午 9:00 (也就是第一次拉出

數據之前的那個時刻)以來修改過的所有記錄，并把這些修改合并到數據倉庫中。

注意 這種技術可能會在兩次連續的刷新中將相同的記錄 “拉出”兩次。由于時鐘的粒度所致，這是不可

避免的。MERGE 操作不會受此影響(即更新數據倉庫中現有的記錄，或插入一個新記錄)。

他 們相信，現在數據倉庫中有了自第一次執行拉出操作以來所修改的所有記錄。他們確實可能有所

有記錄，但是也有可能不是這樣。對于其他采用鎖定系統的數據庫來 說，這種技術確實能很好地工作， 在

這些數據庫中讀會被寫阻塞，反之寫也會被讀阻塞。但是在默認支持非阻塞讀的系統中，這個邏輯是有問

題的。

要看這個例子有什么問題，只需假設上午 9:00 至少有一個打開的未提交事務。例如，假設在上午

8:59:30 時，這個事務已經更新了表中我們想復制的一行。在上午 9:00， 開始拉數據時，會讀取這個表中

的數據，但是我們看不到對這一行做的修改；只能看到它的最后一個已提交的版本。如果在查詢中到達這

一行時它已經鎖定，我們就 會繞過這個鎖。如果在到達它之前事務已經提交，我們還是會繞過它讀取查詢

開始時的數據，因為讀一致性只允許我們讀取語句開始時數據庫中已經提交的數據。在 上午 9:00 第一次

拉數據期間我們讀不到這一行的新版本，在上午 10:00 刷新期間也讀不到這個修改過的行。為什么呢？上

午 10:00 的刷新只會拉出自那天早上上午 9:00 以后修改的記錄，但是這個記錄是在上午 8:59:30 時修改的 ，

我們永遠也拉不到這個已修改的記錄。

在許多其他的數據庫中，其中讀會被寫阻塞，可以完成已提交但不一致的讀，那么這個刷新過程就能

很好地工作。如果上午 9:00(第一次拉數據時)我們到達這一行，它已經上鎖，我們就會阻塞，等待這一

行可用，然后讀取已提交的版本。如果這一行未鎖定，那么只需讀取就行，因為它們都是已提交的。

那么，這是否意味著前面的邏輯就根本不能用呢？也不是，這只是說明我們需要用稍微不同的方式來

得到 “現在”的時間。應該查詢 V$TRANSACTION，找出最早的當前時間是什么，以及這個視圖中 START_TIME

列記錄的時間。我們需要拉出自最老事務開始時間(如果沒有活動事務，則取當前的 SYSDATE 值)以來經

過修改的所有記錄：

select nvl( min(to_date(start_time,'mm/dd/rr hh24:mi:ss')),sysdate)

from v$transaction;

在這個例子中，這就是上午 8:59:30，即修改這一行的事務開始的那個時間。我們在上午 10:00 刷新

數據時，會拉出自那個時間以來發生的所有修改，把這些修改合并到數據倉庫中，這就能得到需要的所有

東西。

總結

以上是生活随笔為你收集整理的oracle时间戳效率问题,时间戳问题 - Oracle开发 - ITPUB论坛－中国专业的IT技术社区...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。