logfileswitch(checkpointincomplete)的問題定位
|
|
|
|
今天測試環境下應用慢，發現數據庫出了問題，直接上AWR報告。
由於是虛擬機，所以不用貼cpu的個數，可以發現負載高。
查看等待時間，發現日志切換在等待。
Top 10 Foreground Events by Total Wait Time
Event |
Waits |
Total Wait Time (sec) |
Wait Avg(ms) |
% DB time |
Wait Class |
log file switch (checkpoint incomplete)
350
11.3K
32229
26.2
Configuration
db file sequential read
569,141
8433.8
15
19.6
User I/O
read by other session
1,228,260
6279.9
5
14.6
User I/O
buffer busy waits
452,194
6138
14
14.3
Concurrency
DB CPU
3121.5
7.3
enq: TX - row lock contention
300
1934.5
6448
4.5
Application
direct path read
45,561
1647.4
36
3.8
User I/O
db file scattered read
89,177
1617.5
18
3.8
User I/O
db file parallel read
29,761
1079.4
36
2.5
User I/O
log file sync
9,864
720.7
73
1.7
Commit
半小時切換了23次，redo日志我看了一下，一個為512M。
Statistic |
Total |
per Hour |
log switches (derived)
23
46.78
最直接的方法是看下數據塊改動的情況，再去查SQL，一眼看去就是物化視圖MV_CONTRACT_INFO導致，70,211,408是改動數據庫的數量，換算成數據量是70211408*8/1024/1024=535.6G，不過這個是最大的redo，其實真實的比這個小，即使小，也非常可觀。很明顯，是有人在刷新物化視圖，通知開發不要在上班時間內刷新物化視圖。
