非常非常抱歉，今天上午的故障又一次給大家帶來麻煩了，再次懇請大家的諒解。
在昨天升級阿里雲 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 高的確是索引碎片引起的。