作為BI登陸，但是數據庫是一個很大的WTF，怎麼辦？
也許是重複的，但我相信我的情況有點不同。從我在 SQL Server Central 上的這篇文章中得到的答案之一也很方便，但情況並不完全相同：繼承數據庫時要做的 9 件事
幾週前開始了一份新工作。我應該擔任 BI 分析師和 SQL 開發人員。但是在第一次分配任務時，通常會發現一切都需要很長時間才能執行。第一天問指導我的人，我的主管可以說，他告訴我他們知道數據庫一團糟。當被問及我是否可以看一看，看看可以做什麼，得到了肯定的回答。
所以我開始深入研究，使用了幾個非常方便的腳本，例如：
- 來自 Adam Machanic 的sp_whoisactive
- 來自@BrentOzar的 sp_blitz
- sp_BlitzIndex也來自@Brent Ozar
- 來自 Jason Strate的 sp_IndexAnalysis
- 2n 編輯Ola Hallengren維護腳本
- …和其他一些人來了解正在發生的事情…
正如他們告訴我的那樣，我發現的是一團糟。例如，blitzindex 過程返回近 2000 行，其中包含大量重複索引、包含表中所有列的 NC 索引、大量堆表、非常寬的索引等等。至於備份，幾個星期以來都沒有完成，被問及它，IT 人員只是每晚將數據庫複製到不同的伺服器。幾個數據庫超過 100Gb，其他幾個也接近這個大小。每個表的統計數據每天都會更新。有些報告需要一個多小時才能完成，而不是那麼大的表（只有幾百萬行）。等等。
作為測試，我花了幾天時間調整幾個大表以及使用它們的不同過程和查詢。使用分析器準備基線。然後進行一些更改並再次執行測試查詢。正如預期的那樣，現在需要大約 8 分鐘的報告在大約一分鐘內執行，而其他幾個查詢現在也只需要不到一半的時間。所有這些更改都在測試伺服器上完成，我們仍然有一個報告伺服器和一個生產伺服器。
考慮到我應該是一名 BI 和 sql 開發人員，在辦公室擁有有限的新權限，而不是 DBA。為了應對這種情況，您建議我採取哪些其他措施？有一個指定的 DBA，但似乎只是一個執行一些 dba 任務的 sql 開發人員。有 DBA，但他在大約半年前離開了，他們告訴我。我應該忘記這些問題嗎？或者作為一個大量使用數據庫的人，我必須指出問題並提出解決方案？有人遇到過同樣的情況嗎？
編輯
感謝大家的評論和回答。自從我發布問題以來已經一個月了。所以現在我可以指出更準確的問題。
我相信索引是主要問題之一，但刪除索引是完全禁止的，至少目前是這樣。即使存在具有多個相同索引的關鍵情況，例如在其中一個主表上，大約有 3000 萬行並且還在增長，也有 3 個 NC 索引，索引 7 列，包括所有列。我可以在非常嚴格的監督下創建索引，但僅此而已。
有幾個禁用的索引，它們會影響 CRUD 操作的性能嗎？
“優步觀點”綜合症。在另一個視圖中的另一個視圖中有很多視圖。關於這一點的一些建議？
很多 sp 在 SMSS 上執行速度很快，但是從 SSRS 呼叫時需要幾分鐘才能執行。閱讀它發現這似乎是一個與參數嗅探及其在儲存過程中的使用有關的問題。一項建議是在 sp 上使用變數。我已經對其中幾個進行了嘗試，並取得了成功。也有人推薦使用
WITH RECOMPILE. 但據我了解，這可能會適得其反，因為每次都需要在重新編譯時創建新的執行計劃。與往常一樣，我猜它“取決於”，必須測試並看看它在哪裡有用，在哪裡沒有幫助。還有什麼建議嗎？備份、日誌等暫時不在我的掌控之中。所以我必須以性能和優化問題為中心。
第二次編輯
還有很多重複的 sp、udf 表和其他一些對象。我猜想在某個模式的某個時間點創建的位置，通常是 dbo。但是，過了一會兒，創建了一個新模式來容納一些對象，但 dbo 上的舊對像沒有被刪除。所以現在在修改東西時，我在數據庫上遇到了很多重複的（有時是三次重複的）對象。
有沒有一種簡單的方法（可能檢查依賴關係？）來檢查哪些對象仍在使用中，以便我可以報告應該刪除哪些對象？
當被問及我是否可以看一看，看看可以做什麼，得到了肯定的回答。
這是非常令人鼓舞的：你處於一個很好的位置來推進你的職業生涯並學習一些東西！
你提到的有些事情是問題，有些不是。我將簡要回答他們並提出一些更廣泛的建議。
- 過程返回近 2000 行，其中包含大量重複索引。如果它們真的是重複的——類型、順序等——額外的東西可以毫無損失地丟棄，而不必擔心。DBMS 只能使用一個，它不關心哪個。
Insert每當索引再見時，性能都會提高。- NC 索引包括表中的所有列。普通的。這些被稱為“覆蓋索引”。它們類似於物化視圖。
- 很多堆表。壞的。每張桌子都需要一把鑰匙。有時你會被告知，“它沒有鑰匙”。如果為 true，則可以將整行定義為主鍵，除了添加額外的列（不在鍵中）作為計數。“添加”一行變成了將計數加 1 的問題。
- 非常寬的索引可能有幫助，也可能沒有幫助，參見。覆蓋索引，上面。
- 數據庫超過 100Gb。正常情況下，數據庫會隨著數據而增長。
- 每個表的統計數據每天都會更新。好的。
- 有些報告需要一個多小時才能完成。每一個問題都是一個機會。
我的建議是通過閱讀四本書來完成你的家庭作業，並從一些戲劇性的事情開始，通過修復執行時間最長的程序（或者你老闆認為最大的問題）。
當您提出更改建議時，您希望能夠在您正在處理的領域中自信而權威地發言：關係理論和數據庫設計，以及 SQL Server。
對於理論，我推薦 CJ Date 的An Introduction to Database Systems、SQL and Relational Theory和Database Design and Relational Theory，按順序排列。當你被問及為什麼應該以某種方式完成某事時，這將為你提供所需的資訊和智力參考點。對於 SQL Server，我可以推薦Itzik Ben-Gan的 Inside Microsoft SQL Server 2008：T-SQL Querying。
不幸的是，閱讀書籍是容易的部分。困難的部分是將它們應用到數據庫中。您可能會發現很難獲得與表一起使用的所有查詢的列表。不僅很難知道需要哪些索引，還意味著將一張表分成兩張需要進行艱苦的測試，以確保沒有任何問題（以及潛在的應用程序更改）。想要規範化數據庫的人幾乎沒有朋友，因為任何更改，即使是正確和必要的更改，都可能給其他人帶來工作和乾擾。
我會看看你的壞孩子，長期執行的報告或很多時候似乎是錯誤的報告。檢查查詢計劃並根據 BCNF 考慮表。如果幸運的話，答案可能是添加一個索引，或者可能刪除一些。如果沒有，你手上就有一個設計問題，這必然會涉及到其他人。
祝你好運。你有你的工作為你完成。好消息是你有一個地方可以學習一些東西，並且可以更聰明地工作而不是更努力地工作。如果你堅持下去，那麼有一天，你將不會減少 30% 或 50%，而是 99% 或更多的查詢時間。發生這種情況時，您將看到鏡子中的新 DBA，所以要小心您的願望。:-)