查看sqlserver负载，sql server怎么看数据

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

相关问答

Q1: 怎样查出SQLServer的性能瓶颈

硬件性能瓶颈 内存 内存对SQL Server性能的影响胜过任何其他硬件。因此，对SQL Server系统的内存使用情况进行定期监视以确保内存的可用百分比高于20%是很有必要的。如果用户遭遇性能问题，同时可用内存百分比低于20%，那么此问题一定是内存分配不足导致的。这要求技术人员密切关注显示平均页面预期寿命的性能计数器，并确保平均页面预期寿命总是高于300秒（5分钟）。一旦放生少于此标准的情况，就说明要么是糟糕的索引设计导致了磁盘输入/输出（I/O）的增加，要么就是对内存的利用效率很低，或者是实际的内存不足。技术人员需要监视SQL Server系统上的分页率，并确保它们常规为1000页每秒。检查PerfMon object MSSQL Buffer Manager（性能监视对象MSSQL缓冲管理器）和Memory Performance Counters（内存性能计数器）。 同样，还要监视计数器，即PerfMon object SQL Server Memory Manager Counters中的Memory Grants Pending。此计数器显示的是每秒钟等待工作负载分配的进程总数。一般来讲，小型OLTP事务不需要大内存分配。对一个OLTP事务来说，任何大于零的内存分配都说明SQL Server系统存在内存不足。 解决内存瓶颈的途径之一是找出内存高耗进程，这可以确认诸如内存泄漏之类潜在的应用程序问题。你还可以通过检查查询优化性能以消耗更少的内存。另外一种方法就是给SQL Server增加更多的物理内存来扩展升级SQL Server环境。扩展升级通常是解决任何与内存相关的性能瓶颈的济世良方。 磁盘I/O使用 对比其他的硬件资源，存储输入/输出通常是SQL Server中最慢的系统资源。因此，监视存储系统以确定存储是否成为一个影响性能的瓶颈是十分重要的。如果是，那么下个步骤就是要调查是否能够优化存储系统的设计和配置以获得扩展性和高性能。检查Average Disk Sec/Read（秒均磁盘读取）和Average Disk Sec/Write （秒均磁盘写入）的PerfMon磁盘计数器。确保OLTP系统和更高决策支持系统的一个读或写的时间在理想情况下少于12毫秒。 与内存一样，解决磁盘I/O性能瓶颈最简单的方法就是扩展升级SQL Server环境，即用更快的磁盘替换现有磁盘，可以更好地应对I/O负载和分配I/O负载到多个轴上。同时还要定期整理磁盘数据。 CPU CPU性能瓶颈的发生有诸多原因。它们包括非理想的查询计划，应用程序或是数据库的设计缺陷，糟糕的SQL Server配置或是硬件资源的不足。技术人员可以对Processor Queue Length（处理器队列长度）的PerfMon operation system CPU（PerfMon操作系统CPU）和处理器计数器进行检查以验证正在等待CPU周期的线程数在八个以内。如果这一数字大于12，那就意味着CPU产生了性能问题。 在确认了某个CPU瓶颈之后，便可以使用sys.dm_os_wait_stats动态管理视图（DMV）来确认对CPU来说排前十的性能最差的查询，如下所示。 SELECT TOP 10 (a.total_worker_time / a.execution_count) AS [Avg_CPU_Time] ,Convert(VARCHAR, Last_Execution_Time) AS [Last_Execution_Time] ,Total_Physical_Reads ,SUBSTRING(b.TEXT, a.statement_start_offset / 2, ( CASE WHEN a.statement_end_offset = - 1 THEN len(convert(NVARCHAR(max), b.TEXT)) * 2 ELSE a.statement_end_offset END - a.statement_start_offset ) / 2) AS [Query_Text] ,dbname = Upper(db_name(b.dbid)) ,b.objectid AS 'Object_ID', B.* FROM sys.dm_exec_query_stats a CROSS APPLY sys.dm_exec_sql_text(a.sql_handle) AS b ORDER BY [Avg_CPU_Time] DESC 接着，你可以对这些查询和底层索引进行调优以解决CPU瓶颈。同时，对你的SQL Server进行配置以使用所有可用的CPU机器。你还可以通过添加额外的CPU或用更快的CPU升级一个新的服务器来扩展你的SQL Server系统。 数据库设计问题 高度规范化的数据库 糟糕的数据库设计会导致数据库性能不足。例如，高度规范化的数据库是与复杂关系连接相关联的。这就造成了长时间执行查询对诸如CPU，内存，和磁盘I/O之类系统资源的浪费。显然，一个高度规范化的数据库会让SQL Server和数据库性能显著降低。编写高效查询的一般规则就是如果一个操作需要五个或者更多的表连接，就要对数据库进行重新设计。 重复和未使用的索引 索引是解决很多性能问题的杀手锏，但是在频繁更新的表上拥有过多的索引会招致额外开销，因为SQL Server在执行插入/更新/删除操作期间会执行额外的工作以保持索引处于最新状态。这就意味着在更新基于索引数量和复杂度的表中数据的时候，SQL Server数据库引擎需要更多的时间。同时，索引维护也会增加CPU和I/O使用，这会在一个密集写入的系统中对性能造成损害。因为任何重复和冗余的索引对系统资源来说毫无意义，所以需要将它们移除。

Q2: 如何查sqlserver transactions per second

当您怀疑计算机硬件是影响SQL Server运行性能的主要原因时，可以通过SQL Server Performance Monitor监视相应硬件的负载，以证实您的猜测并找出系统瓶颈。下文将介绍一些常用的分析对象及其参数。

Windows资源监控中，如果% Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。

Processor%Privileged Time该参数值一直很高，且如果在 Physical Disk 计数器中，只有%Disk time 比较大，其他值都比较适中，硬盘可能会是瓶颈。若几个值都比较大，那么硬盘不是瓶颈。若数值持续超过80%，则可能是内存泄露。如果 Physical Disk 计数器的值很高时该计数器的值（Processor%Privileged Time）也一直很高，则考虑使用速度更快或效率更高的磁盘子系统。

Disk sec/Transfer 一般来说，该数值小于15ms为最好，介于15-30ms之间为良好，30-60ms之间为可以接受，超过60ms则需要考虑更换硬盘或是硬盘的RAID方式了.

Average Transaciton Response Time（事务平均响应时间）随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势

Transactions per Second（每秒通过事务数/TPS）当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈

Hits per Second（每秒点击次数）通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。

Throughput（吞吐率）可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。

Connections（连接数）当连接数到达稳定状态而事务响应时间迅速增大时，添加连接可以使性能得到极大提高（事务响应时间将降低）

Time to First Buffer Breakdown（Over Time）（第一次缓冲时间细分（随时间变化））可以使用该图确定场景或会话步骤运行期间服务器或网络出现问题的时间。

Q3: sql server 布置在多cpu的服务器上，却只占用一个cpu的情况

实际上确实是多个CPU在运行。你只要改变一下查看方式就可以看到了：

打开任务管理器，点击“查看”－－cpu记录－－选择“每个CPU一张图表”就可以了。

如果还不行，说明CPU任务配置不对，要设置一下CPU.

如果出现两个核心负载有明显差异的情况，最主要的原因是没有安装双核心驱动、微软的系统补丁、修改注册表，如果对这些操作不熟悉，可以从网上下载一个“双核心补丁智能安装包”，然后按照提示进行安装即可。

另外，如果是SqlServer2000的话，需要打SP4补丁。否则也可能会出现两个核心中只有一个核心工作，另一个核心不工作情况。

Q4: 如何测试sqlserver性能

对于DBA来讲，我们都会做新服务器的性能测试。我会从TPC的基准测试入手，使用HammerDB做整体性能评估（前身是HammerOra），跟厂商数据对比。再使用DiskSpd针对性的测试磁盘IO性能指标（前身是SQLIO），再到SQLIOSIM测试存储的完整性，再到ostress并发压力测试，对于数据库服务器迁移，我们还会收集和回放Profiler Trace，并收集期间关键性能计数器做对比。

下面我着重谈谈使用HammerDB的TPC-C来做SQL Server基准测试。

自己写负载测试代码很困难

为了模拟数据库的负载，你想要有多个应用程序用户和混合数据读写的语句。你不想总是对单一行更新相同的值，或者只是重复插入假的值。

自己动手使用Powershell、C#等语言写负载测试脚本也不是不可能，只是太消耗时间，你需要创建或者恢复数据库，并做对应的测试。

免费而简单的压测SQL Server：使用HammerDB模拟OLTP数据库负载

HammerDB是一个免费、开源的工具，允许你针对SQL Server、Oracle、MySQL和PostgreSQL等运行TPC-C和TPC-H基准测试。你可以使用HammerDB来针对一个数据库生成脚本并导入测试。HammerDB也允许你配置一个测试运行的长度，定义暖机阶段，对于每个运行的虚拟用户的数量。

首先，HammerDB有一个自动化队列，让你将多个运行在不同级别的虚拟用户整合到一个队列--你可以以此获得在什么级别下虚拟用户性能平稳的结果曲线。你也可以用它来模拟用于示范或研究目的的不同负载。

用于SQL Server上的HammerDB的优缺点

HammerDB是一个免费工具，它也极易访问和快速的启动基准测试和模拟负载的方法。它的自动程序特性也是的运行工作负载相当自动。

主要缺点是它有一个学习曲线。用户界面不是很直观，需要花费时间去习惯。再你使用这个工具一段时间之后，将会更加容易。

HammerDB也不是运行每一个基准测试。它不运行TPC-E基准，例如，SQL Server更热衷于当前更具发展的OLTP基准TPC-E。如果你用HammerDB运行一个TPC-C基准，你应该理解它不能直接与供应商提供的TPC-C基准结果相比较。但是，它是免费的、快速的、易用的。

基准测试使用案例

基准测试负载不能精确模拟你的应用程序的特点。每个负载是唯一的，在不同的系统有不同的瓶颈。对于很多使用案例，使用预定义的基准测试仍然是非常有效的,包括以下性能的比较：

多个环境（例如：旧的物理服务器，新的虚拟环境）

使用各种因素的不同及时点（例如：使用共享存储和共享主机资源的虚拟机的性能）

在配置改变前后的点

当然，对一个数据库服务器运行基准测试可以影响其他SQL Server数据库或者相同主机上其他虚拟机的性能，在生产环境你确保有完善的测试计划。

对于自学和研究来说，有预配置的负载非常棒。

开始使用基准测试

你可以从阅读HammerDB官方文档的“SQL Server OLTP Load Testing Guide”开始。

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

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

希望我的回答对你有帮助

关于查看sqlserver负载和sql server怎么看数据的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。