非常非常抱歉，今天上午的故障又一次給大家帶來麻煩了，再次懇請大家的諒解。

在昨天升級阿里雲 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

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