SQL q & a：操控索引卡
SQL 索引有時很麻煩，但只要您保持警戒並密切注意任何問題，就會發現它們更容易管理。
Paul S. Randal
意外 DBA
Q. 我在我的公司 「 非官方 DBA 」。. 我們越來越多，使用 SQL Server 有因為公司的 SQL Server 執行個體，並知道我們需要幫助實際 DBA。 雖然我們招募人員，我需要能夠了解什麼對某些情況下執行得較慢。 您是否有任何的一般建議，我應該開始尋找?
A. 這是一個很棒的問題。 它可以是令人沮喪，要求也不執行 SQL Server 執行個體，不知道要從何處開始尋找原因。 有各種無法提供給效能降低，因此我一定很容易問 SQL Server 本身的動作。
SQL Server 會追蹤兩組資訊：I/O 統計資料，並等候統計資料。 這些應該提供您的問題是出是個好主意。
大部份的 SQL Server 安裝這些天是我 I/O 繫結 (亦即其效能受到不了讀取和寫入資料)。 您降低可能較慢的 I/O 子系統，慢速網路連線到伺服器，會強制 SQL Server，以交換進出記憶體、 不佳的索引策略或一大堆其他動作的網頁伺服器上的記憶體不足，無法於 SAN。
您可以使用動態管理檢視 (DMV) sys.dm_io_virtual_file_stats 以查看哪些 SQL Server 知道 I/O 磁碟區、 停車格和延遲的所有 I/O 資料和記錄檔案。 您可能會發現 I/O 子系統本身並不作用區，但 I/O 可能仍是問題。 I/O 子系統可能不夠複製 I/O 負載。
這是拼圖的另一個組件會進來：等候統計資料。 每次執行執行緒必須等待可用的資源，以及執行緒必須等候的時間長度，會持續追蹤的 SQL Server。 您也能找出必須等候之後通知資源的可用性，但之前能夠在 CPU 上執行執行緒的時間長度。 透過彙總這些資料，很容易地查看造成等候的 SQL Server 的上方區域。 這可讓您要從何處開始尋找原因的指標。
這是這種方法的高階檢視。 如更深入討論，包括指令碼，您可以使用，請參閱我的部落，」等待統計資料。"它也有多個 1800 SQL Server 執行個體與含有解釋普遍等待類型的讀者問卷調查的結果。 基本要求是：不要浪費時間在環繞在 SQL Server 中直到您已經要求 SQL Server 它認為與問題相關的 poking。
遺漏索引分析
Q. 我剛剛發現遺漏索引 Dmv。 我告訴我有上百個遺漏一個 SQL Server 執行個體上的索引。 我應該只是建立全部都還是，這樣會產生會造成問題吗？
A. 不會立即建立所有的索引而不先進行一些分析。 從 SQL Server 2005 和較新版本的查詢處理器可以判斷當索引會使查詢 (或批次或預存程序) 的計劃。 它會同時編譯查詢計劃。
每次作業系統判定有遺漏索引，其備忘稿這件事。 它也會保持多少次，每個遺失的索引可能已過，連同查詢計劃中的專案改善已編譯查詢計劃時存在該索引的計數。
您可以存取此使用三個 Dmv (sys.dm_db_missing_index_groups、 sys.dm_db_missing_index_group_stats 和 sys.dm_db_missing_index_details) 的所有資訊。 另外還有 DMV，告訴您哪一個資料表的資料行遺漏索引 (sys.dm_db_missing_index_columns)。 前三個 Dmv 是較常見的。 來查詢它們一起，以便讓最簡單的方法，以取得該資料。 Bart 鄧肯被廣泛使用的指令碼，」您使用 SQL 的遺漏索引 Dmv?」 也可以說明。
這是寶貴的資訊，但您應該帶在身邊 salt 的粒狀資料單位。 首先，在遺漏索引 Dmv 沒有潛在的 bug。 它會告訴您實際上並不存在的索引會遺失。 將在 SQL Server 的下一個版本中修正這個錯誤。 您可以閱讀更多有關在自己的部落格文章，」遺失索引 Dmv bug 的可能成本您毋須.”
第二，判斷查詢處理器中的遺漏索引的機制只考量索引是否適合正在進行編譯的查詢。 它不會考慮必須維護該索引的插入/更新/刪除作業的可能效能影響。 這可能是大如果資料表有比例許多更多的變更非讀取。 它也不會考慮建立索引的大小。 這是只有您可以使需要犧牲的代價。
最後，它會尋找絕對的最佳索引，以協助正在進行編譯的查詢計劃。 比方說，可能有 30 的資料行和叢集的索引與查詢要求 25 資料表資料行的資料表。 遺漏索引判斷機制會建議建立非叢集索引來涵蓋 25 欄查詢。 在大多數情況下，不會有意義的。
若要查看彙總的遺漏索引輸出使用鄧肯的指令碼。 然後查看 top 10 或 20 的索引，並進行一些分析來判斷他們是否真的值得建立。 大部分的情況下，您會發現一些不值得建立，因此永遠都是值得執行這項分析。
我們只取得無法吗？
Q. 我就一一群 Dba 處理的各種應用程式開發小組是本公司。 沒有團隊之間的常數 animosity。 它不利於工作環境。 您有知不知道如何平滑小組間的關聯嗎吗？
A. 這是一個常見的問題，可以讓工作環境令人不悅 animosity、 都要存疑與 grudges。 沒有任何它可協助產能和公司有。 幸運的是，沒有解決方案。 其實很容易說明，但比較不容易將放入練習：
- 您必須教育彼此。 每個小組必須瞭解另一隊的推動和他們認為他們界限的責任。 您會很訝異有什麼每個小組認為應該執行另一隊。
- 每個小組必須瞭解其他小組要害。 您可以在不這匿名，使得一些事物個人。
- 每個小組則需要教育其他小組的工作其他小組如何影響他們。 比方說，假設開發團隊撰寫一些程式碼，只會測試以小型的資料集，然後牆上擲它回到實際執行環境-而失敗的 spectacularly。 如果程式開發小組預期 DBA 小組疑難排解並修正程式碼，，顯然是中斷的處理程序。
用來認可並了解問題是，在激勵兩面朝向解決方案，會再次時代工作環境和平並具有生產力的唯一方法。
Vexing 索引
Q. 我是 SharePoint 系統管理員，我知道相當多關於 SQL Server 也。 主控 SharePoint 資料庫 SQL Server 2008 有很多索引片段。 這會影響 SharePoint 效能。 我知道我無法變更索引，但是否有任何我一定辦除了常常需要重新建置吗？
A. 經常重新建立索引，就會將 SQL Server 上沈重的負載放在 I/O 與 CPU 資源、 產生的交易記錄和可能封鎖其他處理程序方面。 就連執行 sys.dm_db_index_physical_stats DMV 來決定片段的索引可以是資源水管。
許多索引變得過於分散在 SharePoint 環境中，因為 SharePoint 資料庫結構描述使用 GUID 叢集索引鍵。 我的妻子戴婉討論此主題在她的部落，」Guid 當做主索引鍵和/或叢集索引鍵.”
如果索引有什麼是本質上的隨機金鑰，索引插入隨機發生，且導致呼叫頁面分割的處理程序。 頁面分割原因必然分段 ； 這是昂貴的程序 (請參閱我的部落格張貼，」代價有多高的交易記錄檔的角度來看的頁面分割?”). 頁面分割時執行的動作] 頁面上會擺滿，但在該頁面上所需空間 (比方說，當發生插入時必須儲存在該頁面上的隨機金鑰值的索引)。 新的頁面配置，大約一半來自整頁的記錄會移到新頁面，如此會建立可用空間。 這是基本程序。
您無法變更在 SharePoint 資料庫中，索引時，可能會破壞支援合約。 然而，您可以變更其預設填滿因數。 當您建立或重建索引時，您可以指示 SQL Server，以保留在某段中以便隨機插入索引分頁可用空間。 這表示比較有可能索引頁已經不需要昂貴的頁面分割有在其上的空間，以讓新資料錄。 一般重建索引時，留下 20%的可用空間時，請設定為 80%容量的填滿因數為 80 表示要填滿頁面。
接著會變成問題狀態，「 什麼是最佳的填滿因數 」？不幸的是，還有不好的答案。 資料不會變更，並沒有任何線上交易處理 (OLTP) 插入活動的資料倉儲，最佳的填滿因數通常是 SQL Server 預設值為 100 (亦即沒有可用空間)。
OLTP 環境中，答案取決於發生磁碟分散的速度和您重建頻率移除片段。 它是以 70 (30%可用空間) 開頭，並且監視片段以查看您是否需要調整上移或下移，是個好主意或更多或更少經常執行索引維護。
.jpg)
Paul S. Randal 是管理 director 的 SQLskills.com，Microsoft 地區主管與 SQL 伺服器 MVP。 他投入 SQL Server 儲存引擎小組在 Microsoft 從 1999年 2007年。 他的 SQL Server 2005 撰寫 DBCC CHECKDB/修復，並在 SQL Server 2008 開發期間是負責核心儲存引擎。 Randal 是嚴重損壞修復、 高可用性和資料庫維護的專家，身為在世界各地研討會發表演說。 他在部落在 SQLskills.com/blogs/paul，而且您可以在 Twitter 上找到他在 twitter.com/PaulRandal。