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未能释放为触发问题主要原因。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/129489.html
