【故障公告】再次出現數據庫 CPU 居高不下的問題以及找到了最可能的緣由

很是很是抱歉，今天上午的故障又一次給你們帶來麻煩了，再次懇請你們的諒解。

在昨天升級阿里雲 RDS SQL Server 實例的配置後（詳見昨天的博文），萬萬沒有想到，今天上午更高配置的阿里雲 RDS 實例依然出現了 CPU 居高不下的問題。

在數據庫 CPU 高的狀況下，有時對訪問速度影響不大，有時巨慢無邊，在今天上午的故障期間，咱們經過2次主備切換才恢復了正常。

下午，咱們咱們調整了服務器的部署，用了更多服務器進行混合部署（docker-compose與docker swarm），狀況有了明顯改善。

可是，15:15 開始數據庫 CPU 又飈了上去，但訪問速度沒有受到明顯影響，一致堅持到 16:50 左右，在扛不住的時候，咱們再次經過主備切換恢復了正常。

此次恢復正常後，咱們才忽然想到，數據庫天天一大早會跑一個整理索引碎片的任務，是否是升級後這個任務不能正常執行了？打開 SSMS 一看，果真是。

昨天由於升級 SQL Server 後重建備庫，整理索引碎片任務失敗了。

Date		9/5/2019 06:30:00
Log		Job History (Reorganize Index)

Step ID		1
Server		SD39184A
Job Name	Reorganize Index
Step Name	Reorganize Index
Duration	00:00:00
Sql Severity	14
Sql Message ID	927

Message
Executed as user: xxx. Database 'xxx' cannot be opened. It is in the middle of a restore. [SQLSTATE 42000] (Error 927).  The step failed.

今天不知什麼緣由整理索引碎片的任務也失敗了。

Date		9/6/2019 06:30:00
Log		Job History (Reorganize Index)

Step ID		1
Server		SD39184A
Job Name	Reorganize Index
Step Name	Reorganize Index
Duration	00:00:00
Sql Severity	14
Sql Message ID	954

Message
Executed as user: xxx. The database "xxx" cannot be opened. It is acting as a mirror database. [SQLSTATE 42000] (Error 954).  The step failed.

CPU 高的問題極可能就是索引碎片沒有被及時整理引發的，是否真的是這個緣由，要等下週的訪問高峯才能獲得驗證。

對於升級後整理索引碎片任務失敗的問題，咱們向阿里雲提交工單後，阿里雲建議咱們先關閉 mirror database 。

alter database 庫名 set partner off

目前咱們沒有采用這個建議，還在考慮更好的解決方法。

【更新】

7:40 很是奇怪，今天凌晨負載極低的時候，阿里雲 RDS 實例居然也出現了 CPU 居高不下的問題，並且 CPU 近 100% 。

主備切換後才恢復正常。

8:30 手動完成了索引碎片的整理。

9月10日更新：經後來的驗證，CPU 高的確是索引碎片引發的。