前段時間有個開發的同事向我諮詢乙個問題，
開發同事：oracle會存在乙個使用者插入資料，已經提交了；但是另外乙個使用者還查詢不到嗎？都是同一張表
jeanron: 不會的。
jeanron: 是oracle嗎，mysql還可能有這種情況
開發同事: oracle,mysql是什麼情況下會這樣？
jeanron: mysql，主庫寫，從庫查，可能會有這種延遲
後續和他們確認了下，是oracle環境，而且都是在主庫端查詢，而且是同乙個表。這種情況聽起來著實有點意思，當然我們知道多版本查詢是oracle的乙個亮點，也是作為mvcc的乙個必備特徵。如果這個都不能保證，資料就會亂套了。
但是目前資料庫中的資料根據開發同學的反饋確實有這種情況，這一點就讓很有意思了。當然他們說感覺延遲，我希望能夠讓他們也幫忙具體定位一下，比如提供一條資料記錄，他們從前端的日誌中發現有延遲的這種情況，我在資料庫端就容易來定位問題了。
沒過多久，開發同學就提供了乙個語句，他們使用rowid定位到了那條記錄，這個對我來說就方便多了。
語句類似下面的樣子：
select count(*)from heart where rowid='aaasdnaahaamgirabn'
他們反饋根據資料的情況，說這條記錄是在2016-07-14 16:40:00 這個時間點插入的，但是有很大的延遲，一直查不到資料。
這個時候使用oracle的閃回查詢就是乙個很好的實踐。首先確保根據rowid能夠定位到資料。
select count(*)from heart where rowid='aaasdnaahaamgirabn' 1
然後延遲5秒鐘看看是否能夠看到資料，結果奇怪的是沒有找到匹配的資料
select count(*)from heart as of timestamp to_timestamp('2016-07-14 16:40:05','yyyy-mm-dd hh24:mi:ss') where rowid='aaasdnaahaamgirabn' 0
然後我逐步放大實踐延遲，一直放大到延遲6分鐘，還是沒有找到匹配的資料。
select count(*)from heart as of timestamp to_timestamp('2016-07-14 16:46:00','yyyy-mm-dd hh24:mi:ss') where rowid='aaasdnaahaamgirabn' 0
繼續放大延遲間隔，終於看到了匹配的記錄。
select count(*)from heart as of timestamp to_timestamp('2016-07-14 16:47:00','yyyy-mm-dd hh24:mi:ss') where rowid='aaasdnaahaamgirabn' 1
從這個簡單的測試來看，這個資料是在2016-07-14 16:40:00插入的，可以從表裡的資料看出，表裡有乙個欄位會做標示，但是資料在乙個事務內一直未提交，所以其他的使用者查詢的時候會始終查到的是未提交狀態的資料，而資料是在16:46:00~16:47:00這個時間段提交的，而具體的時間戳已經不重要了，因為已經說明了問題。
可以基本斷定是在應用端存在乙個大事務，遲遲未提交，導致資料的狀態一直沒有得到更新，確認了這點，應用端就很好去分析和處理了。
MySQL回閃查詢 閃回查詢（undo sql）
select versions xid,versions operation,versions starttime,versions endtime,versions startscn,versions endscn from site daily report versions between t...
閃回事務查詢 閃回事務查詢案例
閃回事務查詢 1閃回事務查詢是閃回版本查詢的乙個擴充 2閃回事務查詢可以審計某個事務或者撤銷乙個已經提交的事務 閃回事務查詢案例 測試資料 create table sct4 id number 4 name varchar2 20 insert into sct4 values 1,lili co...
Oracle閃回查詢
閃回查詢 查詢在特定時間點存在的所有資料。使用閃回查詢功能，可以執行截止到特定時間的查詢。使用select語句的as of子句，可以指定要檢視其對應資料的時間戳。這在分析資料差異時非常有用。注 timestamp和scn是as of子句的有效選項。update employees set salar...