- 識別硬體和軟體故障、調整逾時並防止鏡像中的誤報。
- 修復降低效能的模式：N+1、WHERE 函數和缺失索引。
- 避免 SQL 錯誤（語法、順序、別名）和不良的設計實踐（PK、規範化）。
- 實作 KEDB 以快速透明地解決重複發生的事件。
我們的目標是讓您帶著清晰的行動指南離開：了解這些問題出現的原因、如何檢測它們以及應該採取哪些措施。您將找到關於SQL Server（鏡像）硬體和軟體錯誤、效能瓶頸模式、常見查詢編寫錯誤、經典建模/開發陷阱以及如何使用結構良好的鍵控錯誤資料庫 (KEDB) 來記錄和解決重複事件的 ITIL/ITSM 方法的詳細指南。
硬體錯誤：跡象、原因和反應時間
物理故障通常會很快顯現出來，因為其他系統元件會向資料庫引擎發出警報。發生這種情況時，伺服器會立即收到硬體錯誤報告，但有時會因網路或 I/O 計時器而導致通知延遲。
常見原因包括連接中斷或電纜損壞、網路卡故障、路由器或防火牆變更、終端重新配置、儲存交易日誌的磁碟機遺失，或進程/作業系統錯誤。這些問題如果影響到日誌磁碟或網絡，可能會導致從連接斷開到資料庫複製或鏡像嚴重中斷等各種問題。
請注意，某些網路元件和特定 I/O 子系統會應用自身的內部逾時機制。這些超時機制獨立於資料庫，可能會延遲故障偵測，從而延長實際故障發生到引擎感知到故障之間的時間間隔。
為了更了解「線路」上發生的情況，可以詢問網路團隊在諸如DNS 中斷、網路線斷開、防火牆連接埠阻塞、監聽該連接埠的應用程式崩潰、伺服器名稱變更或重新啟動等常見事件發生期間，連接埠接收到的訊息有哪些。這份症狀清單有助於在服務突然停止時加快診斷速度。
軟體錯誤和超時：何時修復以及如何避免誤報
軟體故障不會自行發出警報：如果沒有監控機制，伺服器可能會無限期地處於空閒狀態。因此，在資料庫鏡像等場景中，會定期「ping」實例，如果在約定的時間內沒有收到訊號，則認為發生了問題。
導致這些等待時間的條件包括網路錯誤（TCP 逾時、封包損壞、遺失或順序錯誤）、作業系統/伺服器/資料庫無回應、Windows 級過期以及資源不足：磁碟或 CPU 飽和、交易日誌 100%、記憶體或執行緒不足。
如果遇到這種情況，您可以選擇增加逾時時間、降低負載或升級硬體來應對需求。逾時時間設定過短會導致誤報；設定過長則會延遲對實際故障的回應。
SQL Server鏡像中的ping/逾時機制
為了保持每個連線的活躍狀態，每個實例都會以固定的時間間隔發送 ping 套件。如果在逾時時間視窗（加上發送時間）內收到 ping 包，則認為通訊處於活動狀態，並將計時器重設。如果在該時間間隔內沒有收到 ping 包，則認為逾時已過，連線將關閉，並根據角色和運行模式處理該事件。
即使另一台伺服器運作正常，逾時也會被視為故障。如果配置的逾時值對於環境的正常延遲來說太短，則會出現「虛假」錯誤。因此，建議超時時間不要低於 10 秒。
在高效能模式下，超時時間始終為10 秒；這通常足以避免誤報。在高安全模式下，預設值也為 10 秒，但可以配置；如果網路速度較慢，請在此模式下將其調整為 10 秒或更長。
如果需要更改此設置，請記住，此修改僅適用於高安全性等級會話。您可以根據您的版本和策略，透過引擎管理介面或使用 T-SQL 檢視和修改此設定。
出現錯誤時伺服器如何回應
如果發生任何類型的錯誤，實例會根據其角色（主實例/見證實例/輔助實例）、運作模式和連線狀態採取相應的措施。如果某個夥伴實例遺失，其行為會因目前是否處於高效能模式或高安全模式（且有見證實例）而有所不同，因此記錄每個會話的運作模式至關重要，以便預測停機時間和切換情況。
SQL 中的效能殺手模式（以及如何修復它們）
有四種非常常見的「錯誤做法」會不必要地增加延遲。這些錯誤很容易發現，避免它們可以從一開始就節省 CPU、I/O 和資料庫存取資源。
循環內的查詢：每次迭代都執行查詢（經典的 N+1 循環）會增加呼叫次數和延遲。使用 UNION 或 IN一次檢索所有數據，或使用批次查詢。使用已載入到記憶體中的資料結構來處理程式碼中的邏輯。
載入過多資料——檢索你不會使用的列和行——就像用大錘砸核桃一樣。應該篩選資料庫，只選擇必要的數據，在適當的時候使用分頁，除非有明確的理由，否則避免使用 SELECT *。
WHERE 子句中的函數：對列套用 LOWER()、DATE() 或其他函數通常會阻止索引的使用。最好在不轉換列的情況下進行比較：先預處理資料或轉換字面值。例如，使用日期/時間列按日期範圍進行篩選，而無需將其包裝在函數中。
缺少索引：如果用於篩選或連接的列沒有索引，就相當於要求執行全表掃描。定期檢查應用程式的篩選/連接操作，並建立相應的索引（必要時建立複合索引）。平衡：索引過多會增加寫入效能。
編寫 SQL 時的典型錯誤：語法、順序和歧義
大多數初學者（甚至一些經驗豐富的使用者）犯的錯誤都與文法和SQL 注入有關。資料庫無法理解你的請求，因此會報錯。使用具有文字高亮功能的編輯器會有所幫助，但了解常見的陷阱可以加快處理速度。
拼字錯誤：FROM、WHERE 子句或表格/列名拼字錯誤很常見。錯誤訊息通常會指出解析器出錯的地方。使用具有高亮顯示和自動補全功能的編輯器；如果某個關鍵字沒有高亮顯示，則需要注意。
括號和引號：缺少括號或引號會造成難以察覺的問題。請記住運算子優先權（AND/OR），並用括號將文字分組。在文字字面量中，請轉義內部引號或交替使用單引號和雙引號，以避免字串斷裂（例如，O'Reilly）。
SELECT 語句順序無效：正確的順序是SELECT → FROM → WHERE → GROUP BY → HAVING → ORDER BY。更改 ORDER BY 或 HAVING 的順序會導致錯誤。請記住這個順序，或是準備一份速查表。
省略表別名：在自連接或兩個表存在同名列時，會收到「列名不明確」的錯誤。請使用簡短、清晰的別名，並使用 `alias.column` 引用列。這樣做還能提高 SQL 程式碼的可讀性。
區分大小寫或特殊名稱：如果您堅持使用區分大小寫或區分空格的名稱，則需要根據搜尋引擎的不同，使用雙引號將其括起來。最好避免使用這些名稱；否則，引用時請保持一致。
資料庫開發中常見的錯誤
除了編寫查詢語句之外，還有一些設計決策會對中長期產生影響。以下列舉了五個常見的開發錯誤，以及如何採取正確的措施來保護程式碼的完整性和可維護性。
過度使用預存程序：它們固然有用，但有了現代 ORM 和存取層，您不再需要將所有邏輯都放在其中。儲存過程需要維護和版本控製成本；僅在必要時建立用於資料存取的預存程序，而不是用於應用程式業務邏輯。
避免使用主鍵：將唯一性委託給視圖、預存程序或應用程式會增加複雜性和錯誤率。在所有表中定義真正的主鍵，並在適當的地方使用唯一鍵；這將防止事後去重和脆弱的查詢。
硬刪除而非軟刪除：實體刪除資料會使稽核和復原變得複雜，尤其是在發生「糟糕，我搞砸了」的情況時。對於許多用例，可以新增一個活動/非活動（軟刪除）標誌，並將其從查詢中排除。物理刪除僅用於受控清理。
已知錯誤資料庫 (KEDB)：它是什麼以及為什麼它對你來說是個好主意
在實際營運中，並非所有問題都能立即解決。由於資源有限、系統複雜或需要保障業務連續性等原因，臨時解決方案（權宜之計）在所難免。 KEDB 是一個儲存庫，用於記錄所有已知錯誤、錯誤原因（如有）以及相應的臨時或永久解決方案。
它是 ITIL 框架的一部分，並與問題管理和知識管理相輔相成。當重複出現類似事件時，團隊會查閱知識庫資料庫 (KEDB)，套用已驗證的解決方案，從而減少停機時間，而無需從頭開始。
使用者獲益：更快的故障解決速度、更少的故障中斷和更可預測的結果。 IT 部門獲益：提高效率（無需重複造輪子）、即使人員流動也能保留知識，以及用於持續改進的數據。利害關係人獲益：提高透明度、基於充分資訊的產能/風險決策和成本節約。
如何逐步實作有效的KEDB
1）明確範圍和目標：確定包含哪些故障（軟體、硬體、網路或特定領域），如何對故障進行分類，以及要實現的目標（例如，縮短平均修復時間、提高滿意度等）。優先考慮關鍵系統和服務，並使範圍與業務目標和服務等級協定 (SLA) 保持一致。
指導性問題：它是否涵蓋所有內容，還是我們應該從影響最大的問題開始？我們的主要目標是縮短解決問題的時間，還是也希望發現預防的模式？
2) 收集並記錄：與事件/問題管理團隊合作，收集尚未記錄的重複出現錯誤和有效的臨時解決方案。使用包含以下欄位的簡單範本：描述、根本原因（如果已知）、臨時/永久解決方案、影響、日期和備註。
提示：使用清晰的語言，採取可操作的步驟，進行有用的分類，連結相關事件，並在有新進展時更新條目。
3) 選擇工具：您需要強大的搜尋、分類/標籤功能、項目間連結、可擴充性、報告功能，以及與 ITSM 平台整合的能力。優先考慮使用者友善的介面以鼓勵使用者採用；考慮使用 AI 驅動的搜尋和可自訂的工作流程。
4）培訓團隊：教導他們如何有效率地記錄文件、有效率地搜尋資訊並保持文件品質。培訓內容包括結合真實案例的實踐練習、快速指南、影片、導師指導以及定期複習課程。鼓勵回饋以改進流程。
5) 維護和改進：明確職責、關鍵績效指標 (KPI) 和審核週期（關鍵問題每月審核一次，其他問題每季審核一次）。建立新條目的同儕審查機制，每次問題出現後持續更新文檔，並建立使用者和支援團隊的回饋管道。
6）推廣使用：進行內部宣傳活動，表彰貢獻最大的員工，並促進各部門（網路、軟體、硬體）之間的協作。將 KEDB 融入服務文化，使其成為使用者尋找資訊的首選平台。
KEDB 與知識庫（KDB）：主要區別
KEDB 專注於已知故障及其解決方案（暫時或永久），與問題和事件管理緊密相關。它通常與 ITSM 集成，其主要受眾是負責解決事件的技術團隊。
KEDB 的內容遠不止於此：它涵蓋了最佳實踐、流程、配置資料、幫助文章等等。其維護工作也更為廣泛，除了技術文章之外，還需要修訂流程和最佳實務。簡而言之：KEDB 是「當此操作失敗時，執行其他操作」這一概念的專門子集。
如您所見，資料庫的穩定性和效能不僅取決於編寫良好的 SQL 語句、進行智慧建模以及組織運作知識，還取決於對物理和邏輯故障（及其檢測時間）的理解。如果您能修正這四種效能模式，避免常見的語法錯誤，採用強主鍵和合理的標準化設計，並建立即時資料庫管理系統 (KEDB)，即使出現故障，您也能擁有一個速度更快、更可預測且更易於操作的平台。
