我的新 Oracle DBA 說話有道理嗎
當我們為我們的 MSSQL 機器設置 FC LUN 時，我們很少需要向它們提供超過 8 個不同類型的不同 LUN（Quorum、MSDTC、TempDB、Data、Logs、Backup 和其他一些）。
我們有一個新的 Oracle DBA，他給了我一份他想要用於他的第一台新伺服器的 LUN 列表 - 其中有 38 個！這是一個非常基本的數據庫盒，只有一個數據庫。它們都是相當小的 (100GB) LUN，它們顯然使用 ASM 以 LVM 類型的方式連接在一起。
最好的方法是做到這一點，我真的不是Oracle專家，但對我來說似乎過於復雜，你對這件事有什麼想法和經驗？
我是 Oracle DBA。您的新 DBA 表現得像許多 Oracle DBA 並且過度工程化。
- 沒有 oracle 不需要 38 個 LUN。我已經將數據文件分佈在大量的 lun 上，但這些文件位於非常活躍且非常大的系統上。LUN 不需要映射到新的 RAID 組，對吧？因此，將文件放在單獨的 lun 上並不需要分散任何東西（我不是這方面的專家）。
- 所有這種文件條帶化將為 DBA 做更多的工作。這增加了他對球隊的重要性。許多 Oracle DBA 總是試圖讓自己看起來更重要，並且總是過度設計事物。
- 將數據分離到不同的 RAID 組/lun 不是特定於 Oracle 的。它基於使用情況。為了正確分散文件，您的 DBA 需要了解應用程序以了解正在訪問的內容（順便說一句，將索引與數據分開不會提高性能，因為訪問是串列的……）。他知道申請嗎？他是否查看了數據庫以查看正在訪問哪些對象？需要散播什麼？什麼是批量寫入和讀取，需要隔離。
這聽起來像是一個中小型數據庫。什麼是活動水平？他大概不知道。
通常在較小的數據庫上，您不需要在文件系統級別做太多工作來提高性能。95% 是 SQL，開發人員是否在循環中執行了太多的 sql 語句。
編輯（多年後！）：
自從發布此文章以來，我一直在與 SAN 工程師交談，並在一定程度上提高了我對 SAN 和 LUN 的了解。首先，LUN 是“合乎邏輯的”。它不需要映射到單獨的 RAID 組、磁碟等……這是由 SAN 工程師設置的，對 DBA 不可見。大多數人都意識到，在 SAN 中分離 IO 的工作還有很多。
我正在開發一個非常大的系統，該系統具有非常高的活動水平。我們有數百個 LUN、RAID 組等……我們將文件分佈在各處。我們與 SAN 工程師一起配置 LUN，以確保它們分佈到 SAN 的不同部分。我們真的無法了解 LUN 如何從作業系統級別映射。新的文件系統並不意味著我們將數據映射到 SAN 上的新位置。
至於關於條帶ASM的HP文件。這在使用 SAN 時完全沒有意義。條帶化、鏡像、RAID 等……都是在表面下完成的。您不會在應用程序或數據庫級別看到它。將 Oracle ASM 配置為“條帶化”在 SAN 中毫無意義，因為您將只在可能使用 RAID 5 配置的邏輯卷上進行條帶化（由於控製成本，絕大多數情況下。SAN 是數百萬美元的投資）。您只會看到文件系統。這些不一定映射到 SAN 中的不同磁碟或不同位置。
IBM 顯然有一個新功能，可以讓 SAN 根據活動決定在哪裡寫入磁碟。我的觀點是優化 SAN 的人是專家。你需要和他們一起工作。DBA 或應用程序開發人員將無法查看是否有任何東西正在展開。
據我所知，大多數商店都沒有非常好的 SAN 工程師。它往往是初級人員的工作。大多數優秀的人往往是顧問。所以很多時候你只是使用製造商的預設設置。重申一下，添加更多 LUN 可能不會分散任何數據，除非您有 SAN 工程師在表面下為您配置它。最重要的是，您可以擁有 1 個 LUN 並為您展開。除非你有一個好的 SAN 工程師，否則所有這些東西都是沒有意義的。對我來說很明顯，所討論的 DBA 對 SAN 的了解還不夠，甚至不知道他什麼都不知道。
99.9% 的時間標準配置都很好。除非您有特定的 IO 瓶頸，否則這是不必要的。如果這樣做，那麼您需要與 SA 和 SAN 工程師一起確定問題所在。很多時候它與 SAN 的佈局無關。同樣，DBA 和開發人員無法查看底層發生的事情，更不用說了解這一點的知識了。SAN 非常複雜。