SQL Server是否等同于Oracle RAC的功能？[关闭]

11

我做了一些谷歌搜索，比几年前还没有找到这个问题的答案，所以我想问一下。Oracle的RAC功能可为读写事务提供负载平衡，并且可在不停机的情况下实现横向扩展和高可用性（至少据我所知-我们将部署第一个使用RAC的数据库，因此，看看效果如何）。

是否提供任何提供等效功能的SQL Server功能集（或您可以在其上安装的第三方组件）？我们一直使用Windows群集，在该群集中，故障转移事件会导致大约20-30秒的SQL停机时间-始终可以忍受，但并不理想。现在，借助SQL 2012中的AlwaysOn，SQL Server将其缩短到大约15秒，并增加了只读-辅助数据库的概念，但是它们仍然要求通过单个连接点阻塞写事务（由于许多事务都需要处理，因此大大改进了）只是阅读，但仍然不是真正的负载平衡），并且在节点故障或需要打补丁的情况下，仍然存在停机时间。

我想这只是出于好奇-我觉得这是SQL Server落后于Oracle的唯一领域（至少在我个人使用的功能中）。我想看看是否有任何选择可以弥补这一差距，并在我们等待添加Microsoft的等效功能时（也许在SQL 2014/2015中）改善我们自己的SQL Server部署？

— SqlRyan
source

1

我不确定SQL Server是否真的落后于Oracle。好吧，是的，它具有SQL Server所没有的功能，但是请确保在运行了该线程几个月后重新访问该线程，并让我们知道它是否全都是玫瑰。:-)我也没有经验，但是那些并不总是有好的话要说的同事。

— 亚伦·伯特兰

2

另外，我希望您不要对SQL Server的未来版本中的功能有任何准确的猜测。那些知道在计划阶段是否具有此类功能的人无法告诉您；那些谁也不告诉你。:-)

— 亚伦·伯特兰

1

@AaronBertrand：公平地说，我真的不希望有任何功能推测，因为我意识到这根本不准确。尽管AlwaysOn是一项改进（在某些情况下），但我寄予更高的希望，那就是它将更加紧密地复制RAC的功能并缩小差距。在我看来，MSSQL在许多方面都比Oracle更好，但是在我看来，这是Oracle负责的领域。

— SqlRyan 2012年

1

再次@rwmnau，我建议您对RAC表示赞赏，直到您实施它并使用了几个月。：-）你可能是对的; 它可能就是它所承诺的一切，并且非常适合您。但是您可能会被盒子上闪闪发光的光芒迷住了。:-)

— 亚伦·伯特兰

2

@AaronBertrand：哈，要点。我已经听到了许多批评，例如它对网络延迟太敏感，并且可以快速驱逐节点等，因此，我肯定会保持完全的判断力，直到我们将其推出并亲自使用为止。SQL Server尽管具有许多HA选项，但似乎并没有进入“多个可写前端”空间。也许我正要发现原因:)

— SqlRyan 2012年

8

没有，没有什么SQL Server可以给你一点相同的开箱。

当前，唯一允许在多个节点上同时写入的SQL Server技术是对等复制。请注意，我并不是说“写向外扩展”，因为它的工作方式使得整个系统仅具有单个节点的写容量。该页面的介绍性段落措辞谨慎，包括“横向扩展”一词，而没有说“写横向扩展”。是的，要进行营销演讲。

根据我的阅读，Oracle RAC在这方面是相同的。从功能上讲，此配置中SQL Server唯一缺少的是负载平衡解决方案，这既有优势（您可以按照自己的方式实现），也有劣势（Microsoft不在包装中或不受支持）。与竞争产品进行比较。

相反，Oracle RAC的不给你同样的事情与SQL Server 开箱无论是。例如，由于实时网络延迟，建议在彼此之间100公里之内的节点上实施RAC，而对等复制没有这种限制。（我并不是说一种解决方案比另一种更好：我只是指出它们是不同的。企业应该选择最适合其特定需求的解决方案。）

— 乔恩·西格尔
source

1

达到100公里的主要原因是因为Oracle仍然跨节点遵守ACID要求-它们需要通过高速互连相互通信，并且光速成为问题。类似配置中的SQL Server会传播更改，并且如果两个节点在一定时间段内更新同一行-不是ACID-不是单个数据库，则可能会出现行级冲突。一组RAC实例是一个数据库，这是唯一的区别。

— 菲尔（Philᵀᴹ）2012年

@Phil：是的，这就是我的观点-他们是不同的。

— 乔恩·塞格尔

6

我是同时支持SQL 2000-2012，Oracle 11g和Oracle 11g RAC的DBA。

IMO，SQL 2012中的Always On可用性组非常接近RAC的可用性和可伸缩性，而成本和复杂性却低得多。您可以通过查询镜像来扩展读取，但是您希望将所有DML定向到主服务器（无法更新SQL Server镜像）。如果主SQL Server崩溃，则故障转移几乎是瞬时的。如果由于崩溃节点上未提交的事务由尚存的节点回滚而导致节点崩溃，RAC也会经历类似的暂停。

与RAC相比，SQL 2012 AAAG的最大优势是无共享架构。RAC共享存储。如果失败，则整个群集都将关闭。那是RAC中一个巨大的SPOF，每个人似乎都忘记了。如果要保护自己免受侵害，则需要设置备用服务器。如果您希望将其用作RAC，则成本会进一步增加。

— 卡盘
source

1

关于RAC SPOF的要点。

— StanleyJohns

5

您问题的直接答案是不，SQL Server没有等效的功能。SQL Server的某些方面为您提供了所需的故障容忍度（甚至可以追溯到使用DB镜像和镜像感知应用程序时的SQL Server 2005），但是Oracle RAC并没有1：1。

— 埃里克·希金斯
source

1

AlwaysOn的更好比较是Oracle的Data Guard功能。主动-被动群集。（是的，您可以从备用数据库中读取数据，但是它是只读的，因此仍然只有一个节点处于活动状态”）

Oracle RAC是完全不同的动物，是一个双活群集。我没有看到微软是否愿意实施任何举措。

— 塔加尔
source

-2

带有AlwaysOn的SQL Server 2012/2014添加了许多使您接近Oracle RAC的功能-并在某些情况下对其进行了改进。（回想一下，使用RAC，您需要使用Oracle应用服务器，weblogic和JDBC-并在单个数据中心中运行，并且该应用只能连接到一个RAC群集-共享存储意味着RAC无法在云中运行）。

使用AlwaysOn，您将获得只读辅助副本（4 in 12、8 in 14）和自动故障转移支持。尽管有一些挑战性的挑战-AlwaysOn不支持负载平衡-除非编写脚本，否则它将始终在列表上绘制第一个服务器。故障转移还会影响应用程序-它不是透明的，因此可能必须重新启动应用程序。

全面披露-我在一家开发可扩展AlwaysOn的软件的公司工作。我们的数据库负载平衡软件前端SQL Server-代表应用执行读/写拆分，执行跨数据中心的基于响应时间的负载平衡，并在故障转移期间对入站的写/事务进行排队，以使应用看不到错误。了解Microsoft，Dell，Quicken Loans和其他企业如何使用ScaleArc软件来扩展SQL Server AlwaysOn并获得无需更改应用程序即可获得的类似于RAC的功能。

— 蜜雪儿
source