Exadata X7-2一體機IO導致日志無法歸檔問題處理
點擊上方“IT那活兒”公眾號，關注后了解更多內容，不管IT什么活兒，干就完了！！！
上午十一點，客戶發來erp核心數據庫后臺日志告警截圖，節點2數據庫所有的online log無法進行歸檔，客戶反饋時好時壞，而且出現這個問題的時候應用就不行了，這里可以肯定的是如果無法進行歸檔，日志就無法寫入，應用肯定會收到影響，跟客戶大概了解情況后，立馬登陸服務器進行診斷。
1. 首先登陸服務器后查看了在線日志狀態
這里發現節點2所有的在線redo無法進行歸檔，節點1部分在線redo無法歸檔。2. 查看磁盤組相關空間利用率信息
SQL> select free_mb,total_mb from v$asm_diskgroup ;
FREE_MB TOTAL_MB
---------- ----------
59352904 134535168
28793712 33623424
3. 查看數據庫當前等待事件
截圖查看此時等待事件，發現最明顯的就是log file sequential read，arch進程從redolog日志中讀取數據塊，下圖標記的信息正好對應節點2在線日志的SEQUENCE#。也就是說所有的未歸檔在線日志arch進程都在嘗試進行讀取并歸檔。4. 再次查看數據庫當前等待事件
經過一段時間后，再次查詢等待事件相關信息，如下截圖，log file sequential read等待事件仍然存在說明arch進程仍然在嘗試對在線日志進程歸檔處理，且log file switch (archiving needed)等待事件出現，等待事件后面出現了阻塞sid。5. 查看被阻塞回話在做什么
到這里我的思路很簡單，先查看下被阻塞的回話執行的SQL是什么，如下查詢，被阻塞session顯然是一個更新操作，且log file switch (archiving needed)對應的回話都是進行一些更新插入操作。UPDATE XXXXXX1 SET TIME_OUT = :B2 WHERE SESSION_ID = :B1
Plan hash value: 4160479998
----------------------------------------------------------------------------------------------------------
| Id | Operation | Name | E-Rows | Cost (%CPU)| E-Time | OMem | 1Mem | Used-Mem |
----------------------------------------------------------------------------------------------------------
| 0 | UPDATE STATEMENT | | | 3 (100)| | | | |
| 1 | UPDATE | XXXXXX1 | | | | | | |
|* 2 | INDEX UNIQUE SCAN| XXXXXX1_U1 | 1 | 2 (0)| 00:00:01 | 1025K| 1025K| |
----------------------------------------------------------------------------------------------------------
6. 這里我進一步查詢了2731這個回話具體在干什么以及是什么進程
這里查看到的信息是Oracle自己的進程通過OSUSER列。這里我通過主機層面直接查詢了spid進程，發現對應的2731回話是lgwr進程。[oracle@dm01dbadm02 ~]$ ps -ef |grep 288576
oracle 126003 67533 0 11:28 pts/2 00:00:00 grep 288576
oracle 288576 1 1 2021 ? 6-05:36:52 ora_lgwr_PROD2
7. 查看數據庫歸檔路徑
進一步查看歸檔路徑信息，主要是查看判斷是否有adg且是最大保護模式，這個數據庫是為了遷移X8一體機做了ADG但是已經停用，且log_archive_dest_state_2已經設置為defer，因此可以排除導致原因。7. 查看數據庫等待事件關系
從下圖基本上可以了解到的信息是arch進程一直在嘗試讀取在線日志，dbwr進程也在等待將臟塊寫入磁盤，dbwr將臟塊寫入磁盤肯定需要lgwr進程將log buffer寫入到在線日志中，lgwr進程出現了控制文件讀寫等待。從這里我得到的信息是控制文件好像是讀寫出現了問題，導致一些列問題的產生。SYS:(Wnnn) log file switch (archivingneeded)
-> SYS:(LGWR) enq: CF - contention[mode=5]
-> SYS:(CKPT) control file parallel write
8. 再次對故障事件排查
又對ash視圖進行了相關查詢，下面數據進行了整理，發現大量事務在等待2731這個回話，且通過如下查詢發現2731回話在進行控制文件讀寫，且伴隨著Log file parallel write以及enq:CF-contention。從上圖中的信息可以看到enq:CF-contention等待事件也是被controlfile file parallel write阻塞。所有的事件又都指向了控制文件。隨即讓客戶進行排查硬件層面問題，經過反饋硬件各方面監控都沒有報錯，而且上周剛剛對X7一體機進行了主機巡檢。9. 查看awr信息
對當前系統系統問題時間抓取了一個awr報告，top10事件如下，這里發現平均延遲和總等待都特別的高。10. 抓取hanganalyze
問題分析到這里已經沒有了頭緒，隨即抓了一個hanganalyze，相關信息截圖如下，滿屏信息都是log file switch (archiving needed)在等待2731這個回話。查看對應的2731回話發現回話在進行控制文件讀。這里的相關信息還是指向了控制文件。11. 再次排查主機硬件
協調客戶再次進行主機排查，去機房發現內存條壞了一個，這里是機房拍照信息，以為是內存調原因，因節點2問題已經影響業務，隨即將節點2關閉，讓業務在節點1上運行。但是節點1在運行一段時間后發生了同樣的問題，這里從剛開始的日志截圖就能發現端倪，節點1的部分在線日志也存在無法歸檔的現象，只不過是沒有那么明顯。12. 再次協調客戶進行一體機排查
最終一體機工程師在主機層面發現問題，一體機工程師發現磁盤IO達到瓶頸，磁盤IO平均相應在100ms以上，磁盤非常繁忙，達到瓶頸。Validate all the physical disks are in NORMAL state before modifying Exadata Smart Flash Cache.
The following command should return no rows:
# dcli –l root –g cell_group cellcli –e "list physicaldisk attributes name,status"|grep –v NORMAL
Drop the Flash Cache.
# dcli –l root –g cell_group cellcli -e drop flashcache
Set the flashCacheMode attribute to writeback.
# dcli –l root – g cell_group cellcli -e "alter cell flashCacheMode=writeback"
Re-create the Flash Cache.
# dcli –l root –g cell_group cellcli -e create flashcache all
Verify the flashCacheMode has been set to writeback.
# dcli –l root –g cell_group cellcli -e list cell detail | grep flashCacheMode
Validate the grid disk attributes cachingPolicy and cachedby.
# cellcli –e list griddisk attributes name,cachingpolicy,cachedby
cellclie -e list cell detail
13. 通過存儲工程師提供的關鍵信息在mos上進行搜索2812622.1
當前mos描述的信息和從數據庫查詢出來的一些狀態信息是吻合的。14. 修改flashcacha卡模式
15. 補充信息說明
一體機工程師給出的IO消耗原因具體到了以下對象，針對改對象排查是一個定時任務，在10點開始執行，在1分左右任務就會結束。如下查詢可以得出針對問題對象的更新變化操作都基本上在10點02的時候結束。以下是一體機工程師在存儲層面獲取到的信息，從信息可以看到，IO請求也基本上在10點開始，然后IO一直未釋放。后臺日志無法歸檔的問題出現在10:09左右，在這個時間點之前，數據庫中存在未應用在線日志，當這些日志信息被填滿，log buffer信息無法寫入到在線日志，所有的DML操作被掛起，對應的等待事件db file parallel write和log file switch completion也開始出現。
1. write-through mode和write-back模式比較
對于非極端閃存Exadata存儲服務器，默認情況下，智能閃存緩存配置為以直寫模式運行。在此模式下，寫入通過Exadata存儲服務器磁盤控制器上的緩存定向到磁盤。因此，寫I/O延遲通常不是性能問題。因此，直寫閃存為大多數應用程序提供了出色的性能。對于非常寫密集的應用程序，寫卷會淹沒磁盤控制器緩存，使其實際上毫無用處。寫回閃存緩存為寫密集型應用程序提供了解決方案。當智能閃存高速緩存在寫回模式下運行時，寫操作直接轉到閃存，只有當數據從高速緩存中老化時，數據才會寫入磁盤。因此，最常見的讀寫數據保存在智能閃存緩存中，而訪問較少的數據保存在磁盤上。請注意，對于寫操作沒有瓶頸的應用程序，回寫智能閃存緩存所啟用的額外寫吞吐量幾乎沒有或根本沒有好處。此外，在回寫模式下，數據的所有鏡像副本都寫入智能閃存緩存，與直寫模式相比，這顯著的地減小了緩存大小。由于每個緩存模式的特性不同，建議在默認情況下使用直寫模式，并且只有在將寫I/O視為性能瓶頸時才啟用寫回模式。確定寫瓶頸的最佳方法是在數據庫等待事件統計信息中查找空閑緩沖區等待。管理員還可以檢查Exadata存儲服務器指標是否存在高磁盤I/O延遲和大比例的寫入。2. write-through mode
In write-through mode, Exadata Smart Flash Cache works as follows:For write operations, CELLSRV writes data to disk and sends an acknowledgement to the database so it can continue without any interruption. Then, if the data is suitable for caching, it is written to Exadata Smart Flash Cache. Write performance is not improved or diminished using this method. However, if a subsequent read operation needs the same data, it is likely to benefit from the cache. When data is inserted into a full cache, a prioritized least recently used (LRU) algorithm determines which data to replace.For read operations, CELLSRV must first determine if the request should use the cache. This decision is based on various factors including the reason for the read, the CELL_FLASH_CACHE setting for the associated object, and the current load on the cell. If it is determined that the cache should be used, CELLSRV uses an in-memory hash table, to quickly determine if the data resides in Exadata Smart Flash Cache. If the requested data is cached, a cache lookup is used to satisfy the I/O request.For read operations that cannot be satisfied using Exadata Smart Flash Cache, a disk read is performed and the requested information is sent to the database. Then if the data is suitable for caching, it is written to Exadata Smart Flash Cache.3. write-back mode
Commencing with Exadata Storage Server release 11.2.3.2.0, Exadata Smart Flash Cache can operate in write-back mode. In this mode, write operations work as follows:- CELLSRV receives the write operation and uses intelligent caching algorithms to determine if the data is suitable for caching.
- If the data is suitable for caching, it is written to Exadata Smart Flash Cache only. If the cache is full, CELLSRV determines which data to replace using the same prioritized least recently used (LRU) algorithm as in write-though mode.
- After the data is written to flash, an acknowledgment is sent back to the database.
- Data is only written back to disk when it is aged out of the cache.
Note the following regarding write-back flash cache:Write-back flash cache is ideal for write-intensive applications that would otherwise saturate the disk controller write cache.The large flash capacity of Exadata Storage Server means that for many applications a high proportion of all I/O can be serviced by flash.An active data block can remain in write back flash cache for months or years. Also, Exadata Smart Flash Cache is persistent through power outages, shutdown operations, cell restarts, and so on.1. 生產問題無小事，發現問題需要及時進行排查做到問題閉環。2. 問題的定位需要全方面考慮，驗證。本次故障主要體現在Redo日志無法歸檔，log buffer無法刷新，所有的業務變更都被阻塞。3. 知識面需要擴展，不能僅僅停留在軟件層面，硬件層面問題排查也很關鍵，包括磁盤IO、網絡，交換機配置，存儲卡配置等。4. 業務層面批量業務也需要重點考慮，往往因為一次瞬時的操作導致系統夯實，本次定位到10點開始的一個定時任務，任務結束后，IO未能釋放為觸發問題主要原因。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/129489.html
