MS SQL Server和Oracle，在可伸缩性方面哪个更好？
例如，如果数据大小达到500 TB等。

解决方案

oracle的人会告诉你oracle更好，sql server peopele会告诉你sql server更好。
我说它们的缩放比例几乎相同。用你所知道的更好。我们那里有数据库，在oracle和sql server上都具有该大小

这也取决于应用程序意味着什么。如果它仅使用很少更新的插入，那么我认为MSSQL将具有更高的可伸缩性和更好的性能。但是，如果其中有很多更新，那么Oracle会更好地扩大规模

问题15是Oracle还是MSSQL可扩展/性能更好。不管我们运行的是Oracle，MSSQL，Informix还是其他任何工具，数据模型都是最重要的要素。数据模型结构，什么样的应用程序，如何访问db等，开发人员足够了解的大型系统目标平台等是我们应该首先问自己的问题。

Oracle和SQL Server都是共享磁盘数据库，因此对于表扫描大量数据的查询，它们受到磁盘带宽的限制。 Teradata，Netezza或者DB / 2 Parallel Edition之类的产品是"无共享"架构，其中数据库在各个节点上存储水平分区。这种类型的体系结构可提供最佳的并行查询性能，因为每个节点上的本地磁盘都不会受到SAN上中央瓶颈的限制。

共享磁盘系统(例如Oracle Real Application Clusters或者Clustered SQL Server安装仍然需要共享的SAN，SAN的流传输带宽受到限制。在VLDB上，这会严重限制可能实现的表扫描性能。大多数数据仓库查询对大块数据运行表或者范围扫描，如果查询将占行的百分之几以上，则单表扫描通常是最佳的查询计划。

节点上的多个本地直接连接磁盘阵列可提供更多磁盘带宽。

话虽如此，我知道一个Oracle DW商店(一家欧洲主要电信公司)拥有一个基于oracle的数据仓库，每天可加载600 GB，因此共享磁盘体系结构似乎并没有施加不可克服的限制。

MS-SQL和Oracle之间存在一些差异。由于以下原因，恕我直言，Oracle比SQL Server具有更好的VLDB支持：

• Oracle对位图索引具有本机支持，位图索引是适用于高速数据仓库查询的索引结构。它们实质上是用CPU进行I / O权衡的，因为它们是游程长度编码的，并且使用的空间相对较小。另一方面，Microsoft声称Index Intersection并没有明显慢。
• Oracle具有比SQL Server更好的表分区功能。 IIRC SQL Server 2005中的表分区只能在单个列上完成。
• 尽管可以在一些相当大的系统上运行SQL Server，但是Oracle可以在比SQL Server更大的硬件上运行。
• Oracle对物化视图和查询重写提供了更成熟的支持，以优化关系查询。 SQL2005确实具有一些查询重写功能，但是文档记录不多，我还没有看到它在生产系统中使用过。但是，Microsoft建议我们使用Analysis Services，它实际上支持不共享的配置。

除非我们拥有真正的圣经数据量，并且在Oracle和无共享架构(例如Teradata)之间进行选择，否则我们可能看不到Oracle与SQL Server之间的实际区别。特别是自从引入SQL2005以来，SQL Server中的分区功能就被认为足够好，并且已经有许多成功地实现了多TB系统的示例。

我曾经在Oracle上担任DBA(尽管已有数年之久了)，现在我广泛使用MSSQL，尽管不是正式的DBA。我的建议是，在大多数情况下，这两种情况都将满足所有要求，并且性能问题将比产品的基本特征更多地取决于数据库的设计和部署，而这两种情况都是绝对的。可靠(MSSQL是MS在许多人看来是最好的产品，因此，不要让MS的通常感知蒙蔽了我们)。

我个人将倾向于使用MSSQL，除非系统将变得非常庞大且真正处于企业级别(大量用户，9的正常运行时间为多个)，仅仅是因为以我的经验，Oracle倾向于比MSSQL要求更高级别的DBA知识和维护。以获得最大的收益。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。 Oracle在初始部署和为其租用DBA方面的成本也往往更高。 OTOH如果我们正在研究企业系统，那么Oracle将拥有优势，尤其是因为如果我们负担得起，他们的支持将是无与伦比的。

我非常怀疑我们是否将获得针对该特定问题的客观答案，直到遇到在两个平台上都实现了相同数据库(模式，数据等)的任何人。

但是考虑到我们可以找到两个数据库的数以百万计的用户的事实，我敢说这两个都可以很好地扩展(我已经看到了一个300 TB的Sql 2005 Snappy快速实现，似乎响应很快) )

我必须同意那些说deisgn更重要的人的观点。

我已经处理了许多不同口味的超快和超慢数据库(绝对最糟糕的是Oracle数据库，但这不是Oracle的错)。数据库的设计以及如何决定对其进行索引，分区和查询的方式与可伸缩性的关系要远远大于产品是来自MSSQL Server还是来自Oracle。

我认为我们可能更容易找到更多具有terrabyte数据库经验的Oracle dbas(运行大型数据库就像了解SQL的特定风格一样是一项专业)，但这可能取决于本地区域。

当我们达到OBSCENE数据库大小时(超过1TB的容量确实足够大，而500TB的容量却无法承受)，那么操作支持必须在要求列表中占上风。有了这么多的数据，我们就不会为一分钱的捏合系统规格所困扰。

我们将如何备份该大小的系统？升级操作系统并修补数据库？可伸缩性和可靠性是否值得关注？

我具有Oracle和MS SQL的经验，对于真正的大型系统(用户，数据或者重要性)，Oracle更好地设计用于运营支持和数据管理。

每个人都试图备份和还原拆分为多个实例上的多个数据库的1TB + SQL Server数据库，而每个数据库都在各处散布事务日志文件，并尝试使其保持同步吗？祝你好运。

使用Oracle，我们拥有一个数据库(因此我不同意"无共享"的方法更好)，其中包含一组REDO日志(1)和一组归档日志(2)，并且我们只需添加额外的硬件节点即可，而无需更改(即重新分区)应用程序和数据。

(1)当然，重做日志是镜像的。
(2)存档日志当然存储在多个位置。

当我们谈论500TB时，这是(a)大而(b)专业的。
我将去咨询公司，聘请适当的专家，以研究现有技能，与现有技术栈的集成，预期用途，备份/恢复/灾难恢复要求...。

简而言之，基于stackoverflow的观点，这不是我要去的项目。无意冒犯，但有太多因素需要考虑，其中很多是商业机密。