巧用閃回查詢來分析事務延遲的問題
前段時間有個開發的同事向我諮詢一個問題,
開發同事: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這個時間段提交的,而具體的時間戳已經不重要了,因為已經說明了問題。
可以基本斷定是在應用端存在一個大事務,遲遲未提交,導致資料的狀態一直沒有得到更新,確認了這點,應用端就很好去分析和處理了。
開發同事: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這個時間段提交的,而具體的時間戳已經不重要了,因為已經說明了問題。
可以基本斷定是在應用端存在一個大事務,遲遲未提交,導致資料的狀態一直沒有得到更新,確認了這點,應用端就很好去分析和處理了。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/23718752/viewspace-2122779/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 閃回版本查詢與閃回事務查詢
- Oracle閃回查詢,閃回版本查詢與閃回事務查詢的使用區別總結Oracle
- 閃回查詢之閃回版本查詢
- 閃回查詢之閃回表查詢
- Mybatis延遲查詢MyBatis
- Oracle 11G 閃回技術 閃回版本查詢和閃回事務查詢Oracle
- 【閃回特性之閃回查詢】使用閃回查詢(select as of)
- 閃回表、閃回查詢
- 分析伺服器延遲的問題伺服器
- 閃回查詢
- 閃回(關於閃回查詢)
- 閃回刪除、閃回查詢
- oracle的閃回查詢Oracle
- oracle的回閃查詢Oracle
- 基本閃回查詢和閃回表
- 閃回技術一:閃回查詢
- 【閃回特性之閃回事務查詢】Flashback Transaction Query
- oracle閃回查詢Oracle
- 閃回查詢(轉)
- 閃回查詢(1)
- oracle 閃回查詢Oracle
- DM7閃回與閃回查詢
- 回閃查詢查詢刪除的資料
- Flashback Query閃回查詢
- 閃回查詢(undo sql)SQL
- 閃回版本查詢操作
- 網路延遲對事務的影響
- [閃回特性之閃回版本查詢]Flashback Version Query
- Oracle 11G 閃回技術 使用Oracle閃回事務查詢Oracle
- DM8 閃回查詢
- 閃回版本查詢技術:
- C# Linq 延遲查詢的執行C#
- 歸檔放在閃回區帶來的問題
- 如何避免MYSQL主從延遲帶來的讀寫問題?MySql
- 事務已提交另外會話查詢不到的問題解析會話
- 【備份恢復】閃回技術之閃回版本查詢
- Oracle 11G 閃回技術 使用Oracle閃回查詢Oracle
- Oracle 11G 閃回技術 使用閃回版本查詢Oracle