04:23:28 檢查點(diǎn)完成: 期間為 17 秒.
04:23:28 Checkpoint loguniq 280608, logpos 0x580c8, timestamp: 1692770041作者: mwao 時(shí)間: 2006-03-16 10:57
我也碰到過這個(gè)問題,經(jīng)判斷是連接用戶數(shù)太多,CPU反映不過來,不夠用原因.如果CPU<=2個(gè),沒什么辦法,如>2個(gè),配置更改一下,綁定CPU就行.作者: wantfly 時(shí)間: 2006-03-24 14:58
TO mwao:
這個(gè)情況我認(rèn)為應(yīng)該是不可能的,因?yàn)闀r(shí)間段是在半夜.不是在白天.
白天用戶多時(shí)也沒有這種錯(cuò)誤呀,我們半夜基本上沒有用戶在用的.作者: mydb 時(shí)間: 2006-09-10 00:12
可能是客戶端設(shè)置的問題.
客戶斷和服務(wù)器的連接參數(shù)不匹配(可能是客戶端,也可能是數(shù)據(jù)庫的通訊參數(shù)被修改),數(shù)據(jù)庫再收到這些來自客戶端的連接請(qǐng)求后,被丟掉,并記錄錯(cuò)誤信息作者: IFMXDBA 時(shí)間: 2006-09-11 22:29 標(biāo)題: 回復(fù) 4樓 mydb 的帖子 another possibility, there was a long check point around 8 minutes. During the checkpoint, the engine is in critical seciton which is flushing logical/phyiscal log buffers to the physical files. Check if your system have a big job is progressing at that time. You can also try to adjust the LRU_MIN_DIRTY, LRU_MAX_DIRTY and CKPTINTRVL for checkpoint duration. Also, you might need check your SAN or disk array log to verify if there is any potential problems.