1、案例概述
某客户有一台Exadata X9M-2，据客户反馈：“晚上20:30分，开始expdp备份，20:32分卡住。同时，在20:30分也发起了RMAN备份，RMAN备份在21:44也卡住。之后，杀掉进程，并重启恢复正常。” 现在，客户希望分析故障原因。为什么备份进程会卡住？
2、故障分析
1、分析数据库等待事件
(1).8点至9点的等待事件
节点1的等待事件
节点2的等待事件
从8点至9点的等待事件可以看出：
该时间段，集群间的gc等待非常严重。 gc cr failure 和 gc cr block congested表示集群间的数据块传输出现拥堵和丢失。
2、集群间gc等待的可能原因
集群间的数据块传输出现gc cr block congested和gc cr failure，主要有如下几种原因：
（1）、SQL语句执行计划异常，造成全表扫描，当该SQL需要访问大量数据块。而其他节点已经缓存了这些数据块时，此时就需要从其他节点传输大量的数据块到本节点。如果访问的这张表非常大，则有可能会造成LMS进程过载，表现为gc cr block congested。
（2）、集群间进行通信的心跳网络异常。
（3）、负责管理硬件中断的某个CPU核繁忙，使用率高达100%，导致硬件中断处理不及时。
（4）、主机的内存耗尽，出现swap in和swap out。
3、分析OSW日志
(1).meminfo
zzz <08/27/2025 18:56:49> Count:0
MemTotal: 395132216 kB
MemFree: 3709616 kB
MemAvailable: 1188432 kB
Buffers: 28 kB
Cached: 12032904 kB
SwapCached: 76884 kB
Active: 149039012 kB
Inactive: 8446232 kB
Active(anon): 148829848 kB
Inactive(anon): 6495604 kB
Active(file): 209164 kB
Inactive(file): 1950628 kB
Unevictable: 865868 kB
Mlocked: 865868 kB
SwapTotal: 16777212 kB
SwapFree: 0 kB
Dirty: 640 kB
Writeback: 0 kB
AnonPages: 146241600 kB
Mapped: 5442532 kB
Shmem: 9730172 kB
Slab: 3591088 kB
SReclaimable: 1064636 kB
SUnreclaim: 2526452 kB
KernelStack: 101984 kB
PageTables: 2265464 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 103715480 kB
Committed_AS: 62561552 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB
CmaTotal: 0 kB
CmaFree: 0 kB
HugePages_Total: 108035
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 11926592 kB
DirectMap2M: 221290496 kB
DirectMap1G: 168820736 kB
在故障时间之前，可用内存仅剩1.1GB，而且SwapFree为0。这是非常严重的性能问题，表明该主机的内存资源严重不足。
(2).vmstat
--time-- procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
19:59:19 7 0 16777212 3377912 28 13556812 0 0 122640 645 39767 45936 8 3 89 0 0
19:59:24 5 0 16777212 5065428 28 11885800 0 0 117720 352 41140 45688 9 3 88 0 0
19:59:29 7 0 16777212 4500544 28 12469792 0 0 114825 302 40306 47953 8 2 90 0 0
19:59:34 7 0 16777212 3977232 28 12977664 0 0 101005 281 38346 46682 7 1 92 0 0
19:59:39 4 0 16777212 4042680 28 12953268 0 0 100337 397 38301 45395 7 2 91 0 0
19:59:44 5 0 16777212 4103020 28 12975440 0 0 109073 615 39058 48136 6 3 91 0 0
19:59:49 6 0 16777212 5111100 28 12005216 0 0 104481 385 38432 45932 7 3 90 0 0
19:59:54 6 0 16777212 4414392 28 12557440 0 0 105422 294 41266 48463 7 3 90 0 0
19:59:59 16 0 16777212 3282876 28 12606792 0 0 141326 3906 167337 182032 40 10 50 0 0
20:00:04 23 0 16777212 4195028 28 11443252 0 0 91555 1036 123428 132536 26 9 65 0 0
20:00:09 19 0 16777212 3177524 28 12047492 0 0 107209 603 112189 113794 28 5 67 0 0
20:00:14 24 0 16777212 3407900 28 11591308 0 0 98224 634 85612 90788 27 4 69 0 0
20:00:19 30 0 16777212 3152248 28 11793660 0 0 82126 510 81212 90838 26 9 66 0 0
20:00:24 27 0 16777212 3149988 28 11397332 0 0 59440 938 86161 95558 23 19 58 0 0
20:00:29 16 0 16777212 3158172 28 11290288 0 0 57571 993 89098 85191 25 18 56 0 0
20:00:35 20 0 16777212 3152940 28 11267920 0 0 86931 703 84660 93726 26 12 61 0 0
20:00:40 20 0 16777212 3169776 28 11323156 0 0 77527 762 69641 73964 25 11 64 0 0
20:00:45 20 0 16777212 3215660 28 11461924 0 0 78945 451 68760 66184 28 8 64 0 0
20:00:50 24 0 16777212 3150244 28 11646244 0 0 79808 698 69045 68526 26 10 64 0 0
20:00:55 29 0 16777212 3158272 28 11552816 0 0 94865 607 67114 65634 27 6 67 0 0
20:01:00 28 0 16777212 3154828 28 11353896 0 0 59493 959 104948 101294 26 20 54 0 0
20:01:05 28 0 16777212 3151248 28 11084344 0 0 51926 605 67429 62298 17 24 59 0 0
20:01:10 94 0 16777212 3154124 28 10896292 0 0 42644 824 93561 54325 10 64 25 0 0
20:01:15 120 1 16777212 3150484 28 10881924 108 98 145133 1005 107026 49930 4 94 1 0 0
20:01:26 83 0 16777212 3157968 28 10929332 10 8 84330 866 92014 54354 9 84 6 0 0
20:01:40 155 2 16777212 3150832 28 10893992 7 2 117506 678 97307 52599 5 92 3 0 0
20:02:03 84 0 16777212 3150308 28 10876720 24 18 138650 720 113378 52820 5 93 2 0 0
20:02:31 86 1 16777212 3150380 28 10885948 15 14 103451 940 110829 51847 7 91 3 0 0
20:03:30 174 3 16777212 3150472 28 10815028 5 5 279750 1530 173396 89584 2 95 3 0 0
20:04:52 99 0 16777212 3150820 28 10892648 59 57 99820 2948 115961 69472 11 83 6 0 0
20:05:10 80 0 16777212 3152352 28 11099356 178 226 109439 18518 128141 116141 26 57 13 3 0
20:07:14 106 2 16777212 3152600 28 10877852 547 406 77940 3996 141946 95841 9 86 5 0 0
20:07:21 241 3 16777212 3151664 28 10886656 53 62 123005 1257 112425 66700 4 93 3 0 0
20:07:56 125 2 16777212 3150524 28 10894696 5 8 114052 2020 116798 72652 9 88 3 0 0
20:08:10 78 0 16777212 3150976 28 10908088 16 10 108087 1496 89820 45140 8 90 2 0 0
20:08:26 143 0 16777212 3150024 28 10907968 0 1 118848 2264 101932 54539 8 88 3 0 0
20:08:33 121 0 16777212 3151968 28 10808352 4 2 327491 1695 207159 107591 3 94 3 0 0
20:09:09 19 0 16765992 65409536 28 12068968 866 288 191655 3685 147535 157768 41 17 41 1 0
20:09:25 31 0 3156048 106541552 28 12654188 158 0 115700 6723 130034 162272 37 6 57 0 0
20:09:30 22 0 3155336 105431536 28 13194964 53 0 104170 7696 107475 132445 39 4 57 0 0
20:09:35 18 0 3155332 105313648 28 13693660 1 0 99094 1718 73415 74990 28 2 70 0 0
20:09:40 16 0 3155252 104969616 28 14204728 88 0 101406 1661 67826 71145 28 2 70 0 0
在故障时间段， 19：59分以前，CPU的队列进程数也才个位数，此时只是系统中的剩余内存非常低，此时还没有表现出系统卡顿的现象。但从20：00分开始，CPU的队列进程数增长，已经开始出现SWAP交换情况，此时的系统已经表现出卡顿。（正常时，该日志每5秒有一条输出，系统出现卡顿时，需要几十秒才有一条日志输出。） 这是因为开始expdp备份工作。（本来操作系统已经达到性能奔溃的临界点，此时又多了一个消耗大量内存的备份任务，系统需要进行SWAP操作，释放内存，最终造成整个系统卡住。）
4、与客户电话沟通了下，得知：该Exadata上运行了很多套数据库，所有数据库的SGA+PGA都已经接近物理内存大小，每个数据库中的连接会话也大约好几千。这也就解释了为什么在发起备份这前，SWAPFREE都已经为0了。一句话就是：内存资源不够用了。
3、建议：
增加物理内存，或者调整数据库的内存使用量。