巧用閃回查詢來分析事務延遲的問題

   前段時間有個開發的同事向我諮詢一個問題，
    開發同事：Oracle會存在一個使用者插入資料，已經提交了；但是另外一個使用者還查詢不到嗎？都是同一張表
    jeanron:   不會的。
    開發同事: 我們現在一個使用者寫入，程式日誌是說已經寫入；可是讀取的使用者還讀取不到，線上延遲5分鐘可能的問題在哪兒？或者你幫忙監控一下？
    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這個時間段提交的，而具體的時間戳已經不重要了，因為已經說明了問題。
    可以基本斷定是在應用端存在一個大事務，遲遲未提交，導致資料的狀態一直沒有得到更新，確認了這點，應用端就很好去分析和處理了。