SQL Server和Oracle，哪一個在可伸縮性方面更好？

Question

MS SQL Server和Oracle，哪一個在可伸縮性方面更好？
例如，如果數據大小達到500 TB等

Answer 1

oracle人會告訴你oracle比較好，sql server peopele會告訴你sql server比較好。 我說他們的規模幾乎相同。使用你所知道的更好。你有那裏的數據庫，這是在oracle以及SQL服務器上的大小

Answer 2

它也將取決於你的應用程序的意思。如果它只使用插入而只有很少的更新，那麼我認爲MSSQL在性能方面更具可擴展性和更好性。但是如果有更新的話，那麼Oracle會更好地擴展

Answer 3

問題＃15 Oracle或MSSQL是否會擴展/更好地運行。無論您是在運行Oracle，MSSQL，Informix還是其他任何軟件，數據模型都是第一個make-it或break-it項目。數據模型結構，應用程序的類型，訪問數據庫的方式等等，您的開發人員所熟悉的平臺適用於大型系統等，這是您應該問自己的第一個問題。

Answer 4

Oracle和SQL Server都是共享磁盤數據庫，因此它們受限於表掃描大量數據的查詢的磁盤帶寬。諸如Teradata,Netezza或DB/2 Parallel Edition的產品是'shared nothing'架構，其中數據庫在各個節點上存儲水平分區。這種體系結構提供了最佳的並行查詢性能，因爲每個節點上的本地磁盤不會受限於SAN上的中央瓶頸。

共享磁盤系統（如Oracle Real Application Clusters或Clustered SQL Server安裝仍然需要一個共享的SAN，這受限帶寬用於流。在一個VLDB這可以嚴重地限制了表掃描性能這是可能實現的。大多數數據倉庫查詢運行表或範圍掃描跨越大塊數據，如果查詢的命中率超過百分之幾，則單個表掃描通常是最佳查詢計劃

節點上的多個本地直接連接磁盤陣列可提供更多磁盤帶寬

說到我知道Oracle DW店（專業歐洲電信公司），該公司擁有基於Oracle的數據倉庫，每天加載600 GB的數據，因此共享磁盤體系結構似乎不會帶來無法克服的限制。

在MS-SQL和Oracle之間有一些差異。 IMHO Oracle有更好VLDB支持比的原因如下SQL服務器：

• Oracle有用於bitmap indexes，其適合於高速數據倉庫查詢索引結構的本地支持。他們基本上是爲CPU進行I/O折衷，因爲它們是運行長度編碼的並且使用相對較少的空間。另一方面，微軟聲稱Index Intersection沒有明顯的慢。

• Oracle比SQL Server擁有更好的表分區功能。 IIRC SQL Server 2005中的表分區只能在單個列上完成。

• Oracle可以在somewhatlargerhardware比SQL Server運行，但一個可以運行在一些quiterespectablylarge系統SQL服務器。

• Oracle對Materialized views和Query rewrite提供了更成熟的支持來優化關係查詢。 SQL2005確實具有一些查詢重寫功能，但它的記錄很差，我沒有看到它在生產系統中使用。但是，Microsoft會建議您使用Analysis Services，它確實支持無共享配置。

除非你有真正的聖經的數據量和Oracle和無共享架構，如Teradata的，你可能會看到Oracle和SQL Server之間幾乎沒有實際差別之間進行選擇。特別是自SQL2005推出以來，SQL Server中的分區設施被認爲已經足夠好了，並且已經成功實現了個multi-terabyte系統的plenty。

Answer 5

我已經在甲骨文公司擔任DBA（雖然有些年以前），現在我廣泛使用MSSQL，雖然不是一個正式的DBA。我的建議是，在絕大多數情況下，兩者都會滿足你可以投入的所有內容，並且性能問題將更多地依賴於數據庫設計和部署，而不是產品的基本特徵，在兩種情況下都是完全和完全的堅實（MSSQL是MS在許多人的觀點中所做出的最好的產品，所以不要讓通常的MS認知會讓你失望）。

自己，我會傾向MSSQL，除非你的系統將是非常大的，真正的企業級（用戶的龐大的數字，多9的正常運行時間等），只是因爲在我的經驗甲骨文往往需要DBA知識更高水平和維護比MSSQL更好地利用它。對於初始部署和爲其僱用DBA的成本，Oracle也往往更昂貴。 OTOH如果你正在尋找一個企業系統，那麼Oracle會有優勢，尤其是如果你能負擔得起，他們的支持是首屈一指的。

Answer 6

我很懷疑，你會得到一個客觀的回答這個特定問題，直到你遇到的人已經實現兩個平臺上相同的數據庫（架構，數據等）。

但是，考慮到你可以找到數以百萬計的兩個數據庫的快樂用戶，我敢說沒有太多的延伸說任何一個都可以縮放（我已經看到了Sql 2005的快速實現300 TB這似乎相當敏感）

Answer 7

我不得不同意那些說deisgn更重要的人。

我和許多不同口味的超高速和超慢的數據庫工作（絕對最差是一個Oracle數據庫，但它不是甲骨文的故障）。數據庫的設計以及如何決定指數，並對其進行分區和查詢它有更多的做的可擴展性比產品是來自MSSQL Server或Oracle。

我想你可以更容易地找到更多具有Terrabyte數據庫經驗的Oracle數據庫（運行大型數據庫就像知道特定的SQL風格一樣是一項專業），但這可能取決於您的本地區域。

Answer 8

當你到淫穢的數據庫大小（其中超過1TB真是夠大的，和500TB的海量該死的），則操作支援必須在需求列表上得很高。有了這麼多的數據，你就不會吝嗇一分錢捏系統規格。

你打算如何備份系統的大小？升級操作系統並修補數據庫？關注可擴展性和可靠性？

我有Oracle和MS SQL的經驗，併爲真正的真正的大系統（用戶數據或重要性），那麼甲骨文是運營支持和數據管理更好的設計。

每一個試圖備份和在多個數據庫上的事務日誌文件的多個實例恢復1TB + SQL Server數據庫拆分被每個數據庫到處吐出來，並試圖保持它的所有同步？祝你好運。

對於Oracle，您有一個數據庫（所以我不同意「無共享」方法更好），一組REDO日誌（1）和一組存檔日誌（2），您可以添加額外的硬件節點不改變（即重新分區）您的應用程序和數據。

（1）重做日誌是，當然，鏡像。 （2）歸檔日誌當然存儲在多個位置。

Answer 9

當你談論500TB，即（一）大和（b）專業。 我會去諮詢公司與適當的專家來看看現有的技能，與現有技術堆棧，預期使用情況，備份/恢復/災難恢復需求的集成....

總之，它不是根據來自stackoverflow的意見，我將會進入一些項目。沒有任何意圖，但有太多因素需要考慮，其中很多因素都是商業機密。

Answer 10

甲骨文像高品質的手動膠片相機，它需要最好攝影師採取而MS SQL最佳畫面等的自動數碼相機。在過去，當然，所有專業攝影師都會使用膠捲相機，現在想想有多少專業攝影師使用自動數碼相機。