sqlserver负载

❶ sql server 的最大负载能力是多大能支持多大的数据库

主要考虑到数据均衡的
SQLServer支持多CPU并发,CPU越多,效率越好,一般来说,百万级也有用SQLSERVER的,
但如果超过百万级,达到千万或更多,就应该考虑用ORACLE了..

❷ 什么是sqlserver的集群

由二台或更多物理上独立的服务器共同组成的“虚拟”服务器称之为集群服务器。一项称做MicroSoft集群服务(MSCS)的微软服务可对集群服务器进行管理。一个SQL Server集群是由二台或更多运行SQL Server的服务器（节点）组成的虚拟服务器。如果集群中的一个节点发生故障，集群中的另一个节点就承担这个故障节点的责任。
认为一个SQL Server集群能够给集群中的两个节点带来负载平衡，这是一种常见的误解。虽然这似乎很有用，但却是不正确的。这也意味着集束SQL Server不能真正提高性能。集束SQL Server只能提供故障转移功能。故障转移就是当系统中的一台机器发生故障失去其功能时，另一台机器将接手运行它的SQL Server实例。这种功能失效可能是由于硬件故障、服务故障、人工故障或各种其它原因。
为何要集束SQL Server环境？
在实用性方面，集群SQL Server环境令人满意。在进行故障转移时，将数据库实例由一台服务器转移到另一台服务器的时间非常短暂，一般只需要3至7秒钟。虽然需要重建连接，但对数据库的终端用户而言，故障转移处理通常是透明的。低廉的故障转移成本还可帮助你对集群中的节点进行维护，而不会造成服务器完全无法访问。
SQL Server集群类型
一共有两种类型的SQL Server集群：主动/被动集群和主动/主动集群。下面分别对它们进行说明（说明以两个节点的SQL Server集群为基础）。
主动/被动集群
在这种类型的集群中，一次只有一个节点控制SQL Server资源。另一个节点一直处于备用模式，等待故障发生。进行故障转移时，备用的节点即取得SQL Server资源的控制权。
优点：由于服务器上只有一个实例在运行，所以在进行故障转移时，不需要另外的服务器来接管两个SQL Server实例，性能也不会因此降低。
缺点：由于虚拟服务器上只有一个SQL Server实例在运行，另一台服务器总是处理备用模式与空闲状态。这意味着你并没有充分利用你购买的硬件。
主动/主动集群
在这种类型的集群中，集群中的每个节点运行一个独立且主动的SQL Server实例。发生节点故障时，另一个节点能够控制发生故障节点的SQL Server实例。然后这个正常的节点将运行两个SQL Server实例——它自己的实例和发生故障的实例。
优点：通过这种配置，你能够充分利用你的硬件。在这样的系统中，两个服务器都在运行，而不是只有一台服务器运行，而另一台处于等待故障发生的备用模式，因此你能够充分利用你购买的机器。
缺点：如果进行故障转移，一台服务器运行两个SQL Server实例，性能就会受到不利影响。然而，性能降低总比虚拟服务器完全失灵要强得多。这种配置的另一故障在于它要求购买的许可要比主动/被动集群多一些。因为集群在运行两个主动SQL Server实例，这要求你购买两个单独的服务器许可。在某些情况下，这也可能对你形成阻碍。
集群考虑
在高实用性方面，集群SQL Server环境有一定的优势。然而，高实用性也确实伴随某种折衷。
首先，建立一个集群SQL Server环境非常昂贵。这是因为集群中的节点必须遵照集群节点的兼容性列表。而且，还需要建立一个复杂的网络，机器的配置必须几乎相同，同时需要实现数据库文件磁盘子系统共享。存储区网络(SAN)是建立这种子系统的不错选择，但SAN并非必要，而且十分昂贵。另外，如果你正在运行一个主动/主动集群，你需要为集群中运行SQL Server实例的每台机器的处理器购买一个许可。
因为当地集群主要局限于同一地理区域，自然灾难可能会使集群完全失灵。在那种情况下，你需要转移到灾难恢复站点进行继续操作。你也可以建立地理分散的SQL Server集群，但这样的系统更加复杂与昂贵。

❸ 怎样查出SQLServer的性能瓶颈

SQLServer性能监控

这套性能优化的清单将至少准科学的帮助你找出你的SQLServer任何明显的性能问题。说是这样说，SQLServer的性能调优仍然是很困难的。我试图用这套清单去找出“容易”的sqlserver性能问题，困难的留待稍后。我这样做是因为很容易将容易和困难的的性能调优问题搞混。通过列出一个“容易”的性能调优范围，就很容易的将这些问题解决，一旦解决了这些容易的问题，那么你就能集中去解决更困难的问题。

使用这个SQLServer性能调优清单的一个好处是，它将不仅仅告诉你目前最容易解决的性能问题是什么，而且还帮助你正确的去解决。在某种程度上，你可以选择不同的顺序进行。换句话说，你可以故意做出特殊的决定而不是按照清单通常的顺序进行。某种意义上说你是对的，不是所有的性能调优建议都适合所有的情形。另外，你的决定是基于你的资源限制，例如没有足够的钱去买满足负荷的硬件。如果真是那样的话，你就别无选择了。还有，你的决定可能基于一些政治原因，那是你不得不作出的改变。不管怎样，你需要知道你能做什么，使用这个性能调优清单找出你能改变的范围并做出相应的改变提升你的SQLServer的性能。

一般来说，你将在你的每一个SQL服务器上执行这个清单。如果遇到清单中的一些问题，这会花掉你一些时间。我建议你从目前性能问题最多的的服务器开始，然后当你有时间的时候按照自己的思路去解决其他服务器。

一旦你完成了，可仍然有很多事情要去做。记住，这些只是一些容易的。一旦你完成了这些容易的，接下来你需要花时间去解决更困难问题。这个是另一篇文章要解决的问题了。

怎样进行你的SQLServer性能调优呢?

为了使其变得容易，我把它们分成了以下几个部分：
？ 使用性能监视器找出硬件瓶颈
？ SQLServer硬件性能监控列表
？ 操作系统性能监控列表
？ SQLServer2000配置性能监控列表
？ 数据库配置设置性能监控列表
？ 索引性能监控列表
？ 应用程序和T-SQL性能监控列表
？ SQLServer数据库作业性能监控列表
？ 使用Profiler找出低效的查询
？ 怎样最好的实现SQLServer性能监控
管理你的SQLServe性能的最好方法是首先回顾上面每一部分的内容，把它们打印出来。然后完成每一部分的内容，写下你收集到的结果。你也可以按照你喜欢的顺序进行。上面的步骤仅仅列出了我执行的顺序，因为那样通常能达到一个比较好的效果。

性能监控列表
计数器名称 均值 最小值 最大值
Memory: Pages/sec
Memory: Available Bytes
Physical Disk: % Disk time
Physical Disk: Avg. Disk Queue Length
Processor: % Processor Time
System: Processor Queue Length
SQL Server Buffer: Buffer Cache Hit Ratio
SQL Server General: User Connections

在上表输入你的结果.

使用性能监视器找出SQLServer硬件瓶颈

开始SQLServer性能调优的最佳地方就是从性能监视器（系统监视器）开始。通过一个24小时的周期对一些关键的计数器进行监控，你将对你SQLServer服务器的硬件瓶颈了如指掌。

一般来说，使用性能监视器去创建一个一些关键的计数器的24小时周期的监控日志。当你决定创建这个日志的时候，你需要选择一个典型的24小时的周期，例如，选择一个典型的比较忙的日期，而不是周日或节假日。

一旦你将这些捕获的数据形成日志后，在性能监视器的图形界面下会显示计数器的推荐值。你在上表中记下均值、最小值、峰值。做完这些后，用你的结果跟下面的分析比较。通过你的结果和下面的建议值进行比较，你将能快速的找到你的SQLServe正在经历的潜在的硬件瓶颈。

关键性能计数器说明

下面是不同关键性能计数器的一个讨论，它们的建议值和为了帮助解决硬件瓶颈问题的一些选项。注意我已经限制了性能监视器需要监视的一些关键计数器。我这么做是因为在本文我们的目的是为了容易的找到显而易见的性能问题，许多其他的性能监视器计数器你能在本网站其他地方找到。

Memory: Pages/sec

这个计数器记录的是每秒钟内存和磁盘之间交换的页面数。交换更多的页面、超过你服务器承受的更多的I/O，将轮流降低你SQLserver的性能。你的目的就是尽量将页面减少到最小，而不是消除它。

如果你的服务器上SQLServer是最主要的应用程序，那么这个值的理想范围是0～20之间。可能很多时候你看到的值都会超过20。这个值一般要保持在每秒的平均页数在20以下。

如果这个值平均总是超过20，其中最大的一个可能是内存瓶颈问题，需要增加内存。通常来说，更多的内存意味着需要执行的页面更少。
在大多数情况下，服务器决定SQLServer使用的适当内存的大小，页面将平均小于20。给SQLServer适当的内存意味着服务器的缓存命中率（Buffer Hit Cache Ratio 这个稍后会讲到）达到99％或者更高。如果在一个24小时的周期里你的sqlserver的缓存命中率达到99％或者更高，但是在这个期间你的页面数总是超过20，这意味着你或许运行了其他的程序。如果是这样的情况，建议你移除这些程序，使SQLServer是你的服务器的最主要的程序。

如果你的sqlserver服务器没有运行其他程序，并且在一个24小时的周期里页面数总是超过20，这说明你应该修改你对SQLServer的内存设置了。将其设置为“动态配置SQLServer的内存”，并且最大内存设置得高一些。为了达到最优，SQLServer将尽可能的获得多的内存以完成自己的工作，而不是去和其他的程序争夺内存。

Memory: Available Bytes

另一个检查SQLServer是否有足够的物理内存的方法是检查Memory Object: Available Bytes计数器。 这个值至少大于5M，否则需要添加更多的物理内存。在一个专门的SQLServer服务器上，SQLServer试图维持4-10M的自由物理内存，其余的物理内存被操作系统和SQLServer使用。当可用的物理内存接近5M或者更低时，SQLServer最可能因为缺少内存而遇到性能瓶颈。遇此情况，你需要增加物理内存以减少服务器的负荷，或者给SQLServer配置一个合适的内存。

Physical Disk: % Disk Time

这个计数器度量磁盘阵列繁忙程度（不是逻辑分区或磁盘阵列上独立的磁盘）。它提供一个对磁盘阵列繁忙程度相对较好的度量。原则上计数器% Disk Time的值应该小于55%。如果持续超过55%（在你24小时的监控周期里大约超过10分钟），说明你的SQLServer有I/O瓶颈。如果你只是偶尔看到，也不必太担心。但是，如果经常发生的话（也就是说，一个小时出现好几次），就应该着手寻找增加服务器I/O性能或者减少服务器负荷的解决之道了。一般是为磁盘阵列增加磁盘，或者更好更快的磁盘，或者给控制器卡增加缓存，或者使用不同版本的RAID，或者更换更快的控制器。

在NT4.0上使用该计数器之前，确认在NT命令提示符下输入diskperf -y，重启服务器，以便手动打开。在NT4.0下第一次必须将该计数器打开，Windows2000默认是打开的。

Physical Disk: Avg. Disk Queue Length

除了观察物理磁盘的% Disk Time计数器外，还可以用Avg. Disk Queue Length计数器。磁盘阵列中的各个磁盘的该值如果超过2（在你24小时的监控周期里大约超过10分钟），那么你的磁盘阵列存在I/O瓶颈问题。象计数器% Disk Time一样，如果只是偶尔看到，也不必太担心。但是，如果经常发生的话，就应该着手寻找增加服务器I/O性能的解决之道了。如前所述。

你需要计算这个值，因为性能监视器不知道你的磁盘阵列中有多少物理磁盘。例如，如果你有一个6个物理磁盘组成的磁盘阵列，它的Avg.
Disk Queue Length值为10，那么实际每个磁盘的值为1.66（10/6＝1.66），它们都在建议值2以内。

在NT4.0上使用该计数器之前，确认在NT命令提示符下输入diskperf -y，重启服务器，以便手动打开。在NT4.0下第一次必须将该计数器打开，Windows2000默认是打开的。

一起使用这两个计数器将帮助你找出I/O瓶颈。例如，如果% Disk Time的值超过55%，Avg. Disk Queue Length计数器值超过2，服务器则存在I/O瓶颈。

Processor: % Processor Time

处理器对象： % Processor Time计数器对每一个CPU可用，并针对每一个CPU进行检测。同样对于所有的CPU也可用。这是一个观察CPU利用率的关键计数器。如果% Total Processor Time计数器的值持续超过80%（在你24小时的监控周期里大约超过10分钟），说明CPU存在瓶颈问题。如果只是偶尔发生，并且你认为对你的服务器影响不大，那没问题。如果经常发生，你应该减少服务器的负载，更换更高频率的CPU，或者增加CPU的数量或者增加CPU的2级缓存（L2 cache）。

System: Processor Queue Length

根据% Processor Time计数器，你可以监控Processor Queue Length计数器。每个CPU的该值如果持续超过2（在你24小时的监控周期里大约超过10分钟），那么你的CPU存在瓶颈问题。例如，如果你的服务器有4个CPU，Processor Queue Length计数器的值总共不应超过8。

如果Processor Queue Length计数器的值有规律的超过建议的最大值，但是CPU利用率相对不是很高，那么考虑减少SQLServer的"max worker threads"的配置值。Processor Queue Length计数器的值高的可能原因是有太多的工作线程等待处理。通过减少"maximum worker threads"的值，强迫线程池踢掉某些线程，从而使线程池得到最大的利用。

一起使用计数器Processor Queue Length和计数器% Total Process Time，你可以找到CPU瓶颈，如果都显示超过它们的建议值，可以确信存在CPU瓶颈问题。

SQL Server Buffer: Buffer Cache Hit Ratio

SQL Server Buffer中的计数器Buffer Cache Hit Ratio用来指出SQLServer从缓存中而不是磁盘中获得数据的频率。在一个OLTP程序中，该比率应该超过90%，理想值是超过99%。如果你的buffer cache hit ratio低于90%，你需要立即增加内存。如果该比率在90%和99%之间，你应该认真考虑购买更多的内存了。如果接近99%，你的SQLServer性能是比较快的了。某些情况下，如果你的数据库非常大，你不可能达到99%，即使你在服务器上配置了最大的内存。你所能做的就是尽可能的添加内存。

在OLAP程序中，由于其本身的工作原理，该比率大大减少。不管怎样，更多的内存总是能提高SQLServer的性能。

SQL Server General: User Connections

既然sqlserver的使用人数会影响它的性能，你就需要专注于sqlserver的General Statistics Object: User Connections计数器。它显示sqlserver目前连接的数量，而不是用户数。
如果该计数器超过255，那么你需要将sqlserver的"Maximum Worker Threads" 的配置值设置得比缺省值255高。如果连接的数量超过可用的线程数，那么sqlserver将共享线程，这样会影响性能。"Maximum Worker Threads"需要设置得比你服务器曾经达到的最大连接数更高。

❹ iis 负载均衡 如何保存session状态

一、Inproc模式
Inproc是缺省的设置,这种模式和以前的ASP的会话状态的方法是类似的,会话的状态会被保存在ASP.NET进程中，它的优点是显而易见的：性能。进程内的数据访问自然会比夸进程的访问快。然而，这种方法Session的状态依赖于ASP.NET进程，当IIS进程崩溃或者正常重起启时，保存在进程中的状态将丢失。

二、StateServer模式
为了克服Inproc模式的缺点，ASP.NET提供了两种进程外保持会话状态的方法。

ASP.NET首先提供了提供了一个Windows服务：ASPState,这个服务启动后，ASP.NET应用程序可以将mode属性设置为 “SateServer”,来使用这个Windows服务提供的状态管理方法。

除了在web.config文件中设置mode属性为StateServer外，还必须设置运行StateServer服务器的IP地址和端口号，具体配置方法如下：

2.1 如果在IIS所在的机器运行StateServer则IP地址就是127.0.0.1,端口号通常是42424.配置如下：

mode=”StateServer”

stateConnectionString=”tcpip=127.0.0.1:42424″

2.2 找一台服务器作为Session服务器

如IP为：172.18.1.188，启动其Windows中的ASP.NET State Service（默认的端口号为42424），把启动类型改为自动；

2.3 修改Session服务器注册表中的项：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services \aspnet_state\Parameters中的AllowRemoteConnection 键的值为1，其中的Port键控制ASP.NET State Service的监听端口；修改后需要重启ASP.NET State Service才生效；

2.4 每台服务器的web.config 的stateConnectionString都指向这台服务器

使用这种模式,会话状态的存储将不依赖IIS进程的失败或者重启,会话的状态将存储在StateServer进程的内存空间中。

三、SQlServer模式
另一种会话状态模式是SQLServer模式。这种模式是将会话的状态保存在SQL Server数据库中的。使用这种模式前，必须至少有一台SQL Server服务器，并在服务器中建立需要的表和存储过程。.NET SDK提供了两个脚本来简化这个工作：InstallSqlState.sql和UnInstallSqlState.sql。这两个文件存放在下面路径中：

c:\windows\Microsoft.NET\Framework

要配置SQL Server 服务器，可以在命令行中运行SQL Server提供的命令行工具osql.exe

osql -s [server name] -u [user] -p [password]

例如：

osql -s (local) -u as -p “”-i InstallSqlState.sql

做好必要的数据库准备工作后，将web.config文件中的sessionstate元素的mode属性改为”sqlserver”,并指定 SQL连接字符串。具体如下：

mode=”SQLServer”

sqlConnectionString=”data source=127.0.0.1;userid=sa;password=;Trusted_Connection=yes”

使用SQLServer模式处了可以使Session的状态不依赖于IIS服务器之外，还可以利用SQL Server的集群，使状态存储不依赖于单个的SQL Server,这样就可以为应用程序提供极大的可靠性。

❺ sqlserver数据库压力测试用什么工具比较好，是直接对数据库进行压力测试的

loadrunner，负载测试用的很多。

❻ MSSQLSERVER2012支持负载均衡吗

不支持，但是可以从业务方面去减轻，比如分开一些只读数据到一个服务器，另外一个服务器用于OLTP的数据。

❼ SQLSERVER怎么搭建服务器集群实现负载均衡

很多组织机构慢慢的在不同的服务器和地点部署SQL Server数据库——为各种应用和目的——开始考虑通过SQL Server集群的方式来合并。

将SQL Server实例和数据库合并到一个中心的地点可以减低成本，尤其是维护和软硬件许可证。此外，在合并之后，可以减低所需机器的数量，这些机器就可以用于备用。

当寻找一个备用，比如高可用性的环境，企业常常决定部署Microsoft的集群架构。我常常被问到小的集群(由较少的节点组成)SQL Server实例和作为中心解决方案的大的集群哪一种更好。在我们比较了这两个集群架构之后，我让你们自己做决定。

什么是Microsoft集群服务器

MSCS是一个Windows Server企业版中的内建功能。这个软件支持两个或者更多服务器节点连接起来形成一个“集群”，来获得更高的可用性和对数据和应用更简便的管理。MSCS可以自动的检查到服务器或者应用的失效，并从中恢复。你也可以使用它来(手动)移动服务器之间的负载来平衡利用率以及无需停机时间来调度计划中的维护任务。

这种集群设计使用软件“心跳”来检测应用或者服务器的失效。在服务器失效的事件中，它会自动将资源(比如磁盘和IP地址)的所有权从失效的服务器转移到活动的服务器。注意还有方法可以保持心跳连接的更高的可用性，比如站点全面失效的情况下。

MSCS不要求在客户计算机上安装任何特殊软件，因此用户在灾难恢复的经历依赖于客户-服务器应用中客户一方的本质。客户的重新连接常常是透明的，因为MSCS在相同的IP地址上重启应用、文件共享等等。进一步，为了灾难恢复，集群的节点可以处于分离的、遥远的地点。

在集群服务器上的SQL Server

SQL Server 2000可以配置为最多4个节点的集群，而SQL Server 2005可以配置为最多8个节点的集群。当一个SQL Server实例被配置为集群之后，它的磁盘资源、IP地址和服务就形成了集群组来实现灾难恢复。

SQL Server 2000允许在一个集群上安装16个实例。根据在线帮助，“SQL Server 2005在一个服务器或者处理器上可以支持最多50个SQL Server实例，”但是，“只能使用25个硬盘驱动器符，因此如果你需要更多的实例，那么需要预先规划。”

注意SQL Server实例的灾难恢复阶段是指SQL Server服务开始所需要的时间，这可能从几秒钟到几分钟。如果你需要更高的可用性，考虑使用其他的方法，比如log shipping和数据库镜像。

单个的大的SQL Server集群还是小的集群

下面是大的、由更多的节点组成的集群的优点：

◆更高的可用新(更多的节点来灾难恢复)。

◆更多的负载均衡选择(更多的节点)。

◆更低廉的维护成本。

◆增长的敏捷性。多达4个或者8个节点，依赖于SQL版本。

◆增强的管理性和简化环境(需要管理的少了)。

◆更少的停机时间(灾难恢复更多的选择)。

◆灾难恢复性能不受集群中的节点数目影响。

下面是单个大的集群的缺点：

◆集群节点数目有限(如果需要第9个节点怎么办)。

◆在集群中SQL实例数目有限。

◆没有对失效的防护——如果磁盘阵列失效了，就不会发生灾难恢复。

◆使用灾难恢复集群，无法在数据库级别或者数据库对象级别，比如表，创建灾难恢复集群。

虚拟化和集群

虚拟机也可以参与到集群中，虚拟和物理机器可以集群在一起，不会发生问题。SQL Server实例可以在虚拟机上，但是性能可能会受用影响，这依赖于实例所消耗的资源。在虚拟机上安装SQL Server实例之前，你需要进行压力测试来验证它是否可以承受必要的负载。

在这种灵活的架构中，如果虚拟机和物理机器集群在一起，你可以在虚拟机和物理机器之间对SQL Server进行负载均衡。比如，使用虚拟机上的SQL Server实例开发应用。然后在你需要对开发实例进行压力测试的时候，将它灾难恢复到集群中更强的物理机器上。

集群服务器可以用于SQL Server的高可用性、灾难恢复、可扩展性和负载均衡。单个更大的、由更多的节点组成的集群往往比小的、只有少数节点的集群更好。大个集群允许更灵活环境，为了负载均衡和维护，实例可以从一个节点移动到另外的节点。

❽ 如何实现mssql数据库负载均衡

SQL Server 负载均衡集群
一个应用系统随着业务量的提高,以及访问量和数据流量的快速增长，各个核心部分的处理性能和计算强度也相应增大，使得单一设备根本无法承担。在此情况下，如果扔掉现有设备去做大量的硬件升级，必将造成现有资源的浪费，而且下一次业务量的提升，又将导致再一次硬件升级的高额成本投入。于是，负载均衡机制应运而生。 对于应用系统的负载均衡的硬件和软件比比皆是，因为应用服务器上的程序基本上认为是不变化的，而且一般的各个应用服务器上的程序是不交互的。因此应用服务器的负载均衡非常好做，只需要能够进行分流的软件或者硬件把多个客户端的连接分配到多个应用服务器上去即可。
因为数据库内的数据是频繁变化的，为了数据的一致性以及锁资源的分配协调等，所以像应用服务器那样只有分流是不够的，各个节点需要频繁的交互。这也是数据库集群软件难做的原因，当然也是卖的贵的原因了。

Oracle Real Application Clusters
对于数据库负载均衡，大家最为耳熟能详的就是Oracle RAC了。RAC是双机并行服务器(8i及以前版本称作Oracle Parallel Server，OPS)，用来在集群环境下实现多机共享数据库，以保证应用的高可用性，同时可以自动实现并行处理及均分负载，还能实现数据库在故障时的排错和无断点恢复。它可以自动进行负载平衡、故障修复和规划停机时间，以支持高可用性应用程序。若并行服务器中某节点失效，透明的应用程序容错能够把用户自动转接到另一节点上继续运行，应用程序在用户没有察觉的情况下继续执行。这使周期性和非周期性发生故障的系统增大了连续可用性。进程的失效可以完全透明地转移到另一节点上去，通过适当地配置，可以指定所有查询都在客户端进行缓存，这样它们便可以在转移后的节点上重新设置。
Moebius for SQL Server
截至到SQL Server 2008，微软还是没有推出负载均衡组件，只能靠第三方软件来实现，好在这个软件是几个从微软出来的人写的，也算是个小小的巧合。说他们是微软出来的并不是说他们的技术多厉害，而是他们利用SQL Server的一些内部接口把集群做的非常透明， 无论是应用程序的调用还是开发/管理人员的使用都和面对一个数据库一样。
他们的实现原理是这样的：和SQL Server镜像一样，每个数据库节点都有自己的数据，也就是无共享磁盘架构。他们称之为“中间件”的程序宿主在数据库的内部，每个节点数据库上写入数据导致数据变化时，SQL Server会激活“中间件”，“中间件”把变化的数据同步到其他的节点上。其他节点发生变化也是一样。因为“中间件”宿主在数据库内， 所以它能够把每个同步的Session和SQL Server的Session绑定到一起，也就是使用户的执行和数据的同步成为一个原子操作，从而保证数据在每时每刻都是一致的。因此查询可以随便到每个机器上去查，从而做到了真正的负载均衡。
这是一种叫"数据库路由器"的技术,这种技术的特点是灵活性好,但效率比RAC要低，毕竟RAC是在引擎里实现的不管怎么样有比没有强!

❾ SQL SERVER 2008 服务器CPU满负荷，求检查方法

至强E5-2640 为六核心 十二线程的 看的出你得服务器上有两个处理器，此类处理器还是带的动500人同时访问，没必要换。你的内存使用量太高了，建议关闭不必要后台。如果你要找出是数据库的造成问题 那么你得把数据库代码发出来 不然是无法为你找的 你给的只是CPU和内存在任务管理器里使用率，服务器长时间不关机 也是导致运行缓慢的原因之间，windows系统开时间长了系统占用资源很大临时文件很多，建议使用linux或unix系统关闭不必要的端口服务 数据库建议使用oracle或者my sql数据库。
希望我的回答对你有帮助