Server 2005性能排错

拙劣游标使用

SQL Server 2005之前的SQL Server 版本仅支持在每个连接上有单个活动的操作。一个查询正在执行或有了结果等待发送到客户端时将被认为是活动的。在一些情形中，客户端应用程序也许需要从结果中读取并向SQL Server提交其他基于刚刚从结果集中读取的行的查询。这在默认的结果集中是不能实现的，因为还有其他等待的结果。一般的解决方法是改变连接属性是用服务器端游标。

当使用服务器端游标，数据库客户端软件(OLE DB提供者或ODBC驱动)显然会封装客户端请求在特殊的扩展存储过程中，例如sp_cursoropen，sp_cursorfetch等等。这提到了API游标（而不是TSQL游标）。当用户执行查询，查询文本通过sp_cursoropen被发送到服务器，请求读取从sp_cursorfetch指示服务器进发送某些数量的行。通过控制获取行的数量，可以为ODBC驱动或OLE DB提供者缓存行。这阻止发生服务器等待客户端都区所有发送的行的情形。因此，服务器可以在这个连接上接受新的请求。

一次性打开游标并获取1行（或少量行）的应用程序能被网络延时的网络瓶颈影响，特别是在广域网（WAN）。在有快速网络并有不同用户连接时，处理很多游标请求的开销变得更重要。因为开销来自于游标位置的变化来适应在结果集上的位置改变，预请求的处理开销，类似的处理，服务器处理1个请求返回100行必处理100不同请求相同的100行但是每次1行更有效率。

检测

你可以使用下列方法为拙劣游标使用排错。

系统监视器(Perfmon)

通过考虑SQL Server:Cursor Manager By Type – Cursor Requests/Sec计数器，你可以通过这个性能计数器知道有多少游标在系统中使用。系统还有很高的CPU利用率，因为小量的读取通常会有每秒数百个游标请求。这里没有特殊的计数器告诉你关于获取的缓存大小。

DMVs

接下来的查询可以用于测定使用API游标（不是TSQL游标）连接获取一行使用的缓存大小。它对于大的获取缓存更有效，例如100行。

select 

cur.* 

from 

sys.dm_exec_connections con

cross apply sys.dm_exec_cursors(con.session_id) as cur

where

cur.fetch_buffer_size = 1 

and cur.properties LIKE 'API%' 
-- API cursor (TSQL cursors always have fetch buffer of 1)

SQL 跟踪

使用包括RPC：Completed事件类的跟踪用于搜索sp_cursorfetch语句。第4个参数的值是通过获取返回的行数。请求返回的最大行数是被指定为与RPC:Starting事件类关联的参数。

解决

◆确定游标是完成操作的最佳方法或是否基于集合这种更有效的操作是可行的。

◆当连接到SQL Server 2005，考虑使用多活动结果集(MARS)

◆参考你使用的API文档决定如何指定游标的获取缓存大小：

ODBC - SQL_ATTR_ROW_ARRAY_SIZE

OLE DB – IRowset::GetNextRows or IRowsetLocate::GetRowsAt

内存瓶颈

这部分给出了低缓存的条件和对不同内存错误诊断方法，可能的原因和排错方法。

背景

引用不同的内存资源通过使用简单的术语内存。但是却有一些内存资源类型，对于理解和区分特殊的内存资源这是很重要的。

虚拟地址空间和物理内存

在Microsoft Windows®，每个进程都有自己的虚拟地址空间(VAS)。进程可用所有虚拟地址有VAS的大小决定。VAS的大小依赖于架构（32位或64位）和操作系统。在排错的上下文中，理解虚拟地址空间使用内存资源，了解应用程序可以超出VAS即使在64位平台只要物理地址可能一直可用，这些很重要。

更多有关于虚拟地址空间，请查看SQL Server联机丛书中“Process Address Space”和MSDN中的Virtual Address Space。

Windows地址扩展和SQL Server

Windows地址扩展(AWE)是允许32位应用程序跨越32位地址限制操作内存的API。AWE机制技术上不需要64位平台。然而它出现了。内存页通过AWE机制涉及在64位平台上的锁定页。

在32位和64位平台上，内存通过AWE机制分配不能分页出界。这可以有益于应用程序（这是在64位平台上使用AWE机制的原因）。这也影响了系统和其他应用程序可用RAM总数，这可能是有害的影响。因为这个原因为了使用AWE，Lock Pages in Memory权利必须分配该运行SQL Server的账号。

从排错的角度来看，要点是SQL Server缓存池使用AWE映射内存；然而，只有数据库（hash过的）页面可以利用AWE分配内存。通过AWE机制内存分配将不会在任务管理器或在Process: Private Bytes性能计数器中看到。你需要使用SQL Server特殊的计数器或动态管理视图来获取这些信息。

更多关于AWE映射内存的信息，请在SQL Server联机丛书中查看“Managing memory for large databases” 和 “Memory Architecture”以及MSDN中的Large Memory Support

下列表汇总了不同SQL Server 2005支持的最大内存（注意特殊的SQL Server版本或Windows可以有不同支持内存的限制）

表1