一個(gè)生產(chǎn)庫， 使用量不算特別大， 內(nèi)存 64GB， 數(shù)據(jù)庫 60 GB左右。IO 也非常不錯(cuò)，雖然是虛擬機(jī)，但性能很好。

版本： SQL Server2014 企業(yè)版。?

搭建了 Alwayson ， 同步模式、自動(dòng)故障轉(zhuǎn)移。

奇怪的是， 用擴(kuò)展事件捕獲到的慢SQL特別多（但占用CPU很低）， 用戶實(shí)際使用也比較慢， 連純插入語句都很慢， 一天產(chǎn)生幾萬數(shù)據(jù)量的表插入居然要幾秒（無更新和刪除，少量查詢）， 令人難以置信。看監(jiān)控， CPU、IO 等非常占用很低， 5% 都不到， 唯一能查到的是有兩個(gè)表的更新操作很頻繁， 平均每秒 幾十次， 但也沒占什么CPU。而且這個(gè)一時(shí)也改不了程序。

后來查了等待，發(fā)現(xiàn)可能有與 Alwayson 相關(guān)的等待：

msdn

select * from sys.dm_os_wait_stats s where s.max_wait_time_ms>1000 or s.signal_wait_time_ms>1000 or s.waiting_tasks_count>1000 or s.wait_time_ms>1000 order by s.wait_time_ms desc

清空的SQL：

DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR);

將 Alwayson 其改為 異步、手動(dòng)轉(zhuǎn)移 就好了。

可惜的是 異步 不能自動(dòng)轉(zhuǎn)移， 但也沒辦法了。

慢得有些奇葩， 其它有些庫是同步模式也沒慢成這樣， 先記著吧。

今天在再看這個(gè)服務(wù)器時(shí)， 發(fā)現(xiàn) xp_readerrorlog 要幾十秒才能讀完。

也許是那個(gè)死鎖標(biāo)記導(dǎo)致的吧， 錯(cuò)誤日志文件估計(jì)都有個(gè)幾百M(fèi)B了。

DBCC TRACEON (3605,1204,1222,-1)
里面其實(shí)不是什么死鎖， 都是一些 alwayson 相關(guān)的內(nèi)容。

算了， 先用：

exec msdb.dbo.sp_cycle_errorlog 把最大的錯(cuò)誤日志滾到最后吧。

慢跟這個(gè)應(yīng)該是有一定關(guān)系的了。

總結(jié)

以上是生活随笔為你收集整理的Alwayson 同步模式的坑的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。