浅谈优化SQLServer数据库服务器内存设置的策略

浅谈优化SQLSe。笔者经过仔细摸索，发现系统对硬、软件的需求较高，为充分发挥设计效能，达到最佳运作效果，需要对计算机硬、软件系统进行较为完备的性能测试和最佳设置，特别是内存设置的好坏对系统的运行速度具有决定性的作用。下面，笔者就怎么优化SQLServer数据库服务器的内存设置提出一些认识和看法。

一、有关内存的基本概念

　　1?物理内存和虚拟内存
　　视窗系统NT使用两类内存：物理内存和虚拟内存。
　　物理内存：作为RAM芯片安装在计算机内部的存储器。
　　虚拟内存：用于模拟RAM芯片功能的磁盘(硬盘)空间，其实质是通过将内存中当前没有使用的部分内容临时存储到磁盘上，使系统能使用到比机器物理内存更多的内存。
　　2?分页和分页文件
　　视窗系统NT系统通过使用磁盘空间使得对内存的需求得到部分缓解，从而使用到比物理内存更多内存的技术就称为“交换”或分页，也就是通常所说的虚拟内存技术。通常视窗系统 NT 4.0系统安装时将在引导驱动器上设置一个大小为16MB的交换(分页)文件(pagefile.sys)。

二、优化视窗系统 NT 4.0系统内存设置

　　在大多数情况下，为了充分发挥视窗系统 NT 4.0系统效能，内存的作用比起处理器的处理能力更具有影响力，特别是在客户／服务器模式环境下更是如此，因为通常在这种环境下并不十分强调处理器的能力，相反却十分注重是否采用足够的内存来满足各个客户的应用需要。此外，为了获得容错功能和保护应用程式，确保应用程式高速运行、充分发挥设计功能都需要有足够多的内存，特别是工业绘图设计和各种工程应用程式更需要占用大量的内存来进行复杂的计算。
　　物理内存(RAM)方便快速的好处显而易见，但由于其价格昂贵，也就不可能做到多多益善了，因此通过合理优化内存设置、扩充虚拟内存提高计算机运算速度也就成了一项非常重要的应用技术手段。
　　1?确保视窗系统 NT系统基本内存需求
　　视窗系统 NT 4.0系统至小应设置12MB内存，16MB内存基本够用，正常情况下确保NT系统有32MB内存就能了，因为并不是所有的16MB基本内存在所有时候都被同时使用。如果添加一些服务和应用程式，则对内存的需求就会急剧增大。如：
　　(1)添加网络服务需要4MB内存空间；
　　(2)容错功能和系统保护功能需要8MB内存(如磁盘映像和分条功能)；
　　(3)进行图像图象处理需要增加16MB内存空间；
　　(4)安装VC、VB研发系统需要增加16MB内存空间；
　　另外，如在视窗系统 NT上构建大型数据库如SYBASE、Microsoft SQL Server等，对内存的需求就更多了。
　　2?优化内存性能
　　为了使视窗系统NT不至于过分占用较多的内存或浪费处理器的时间用于换页，能采用以下方法优化内存性能。
　　(1)减少显示颜色的数量；
　　(2)降低显示分辨率；
　　(3)尽可能不使用或使用位宽度较小的墙纸；
　　(4)关闭不必的服务程式或驱动程式，尽量不要在服务器上使用其他应用程式。
　　停用服务或驱动程式的操作步骤如下：
　　①确定需要停用的服务或驱动程式的名称；
　　②从“控制面板”中双击“服务”或“设备”图标；
　　③在列表中选择想要停用的服务或设备驱动程式的名称，单击“停止”按钮，这时出现确认操作对话框；
　　④选择“是”确认操作，然后关闭对话框完成设置。
　　3?优化虚拟内存
　　在对视窗系统 NT虚拟内存进行设置时需要合理确定各个驱动器分页文件的“起始大小”和“最大值”两个参数，他们用于指定分页文件的起始空间和最大空间。下面对这两个参数作一些解释：
　　起始大小：指初始创建该分页文件时的文件大小，单位为MB，根据缺省设置，这个值被设置为系统中的物理内存的大小。
　　最大值：指出该分页文件的最大尺寸，单位为MB。
　　(1)分页文件的设置原则：
　　①分页文件起始大小应保留缺省设置，一般情况下请不要改动；
　　②分页文件最佳的最大尺寸为系统物理内存尺寸的2.5倍至4倍。需要说明的是：如果系统工作时不必大量内存，请选择靠近下限的值，即用系统物理内存的2.5倍作为这个尺寸的起始值；如果系统工作时需要大量内存，请选择靠近上限的值。
　　(2)视窗系统 NT虚拟内存设置步骤：
　　①从“控制面板”中双击“系统”图标；
　　②在“系统特性”对话框中单击“性能”标签；
　　③在虚拟内存对话框中单击“更改”按钮，这时出现“虚拟内存”对话框，上端的驱动器框逐一列出了 视窗系统 NT所有页面文件的大小；
　　④在驱动器列表中，选择需要设置分页文件的驱动器盘符，在“驱动器页面文件大小”对话框中列出了 “起始大小”和“最大值”两个参数栏，填入按照上面的原则确定的数值；
　　⑤单击“设置”确认以上操作，然后依次单击“确定”按钮退出各个对话框，完成设置。
　　(3)Win95／98虚拟内存设置。
　　Win95／98虚拟内存设置方法、步骤和原则和视窗系统 NT 4.0的设置大致相同，请参照上面视窗系统 NT的设置。
　　4?注意事项
　　(1)合理确定分页文件的最大值，根据系统需求随时进行调整，使用过多虚拟内存将导致整个系统处理性能的下降。设置虚拟内存最大值的目的是使用户不必在视窗系统NT的交换文件上消耗过多的磁盘空间，通常情况下如果超过了系统需要的最佳值后，生成交换文件的磁盘空间就被浪费了。
　　(2)尽可能设立专用硬盘设置内存交换区，或将交换空间放到主硬盘的另一个分区，同时应将主硬盘的交换文件大小降至16MB，这样主硬盘(分区)仅用来放置操作系统和应用程式，就能减少交换次数，防止频繁交换耗费大量 CPU时间。
　　(3)虚拟内存技术的确改善了视窗系统 NT系统的性能，但也受到机器硬盘空间大小、硬盘速度、处理器 (CPU)速度的影响，从最佳角度出发，要提高计算机的性能就必须减少交换操作的次数，不过没有一个视窗系统NT计算机不发生交换，这就需求计算机要有足够的物理内存，以保持最少的交换操作。

三、优化Microsoft SQL Server数据库内存设置

　　内存是影响Microsoft SQL Server系统性能的一个重要因素，SQL Server数据库安装时将为具有32MB物理内存的机器缺省设置16MB可用内存，16MB物理内存的机器缺省设置4MB可用内存。应在Microsoft SQL Server数据库安装后进行内存选项(Memory)设置，最大设置值为2GB。
　　为了确定SQL Server系统最适宜的内存需求，能从总的物理内存中减去视窗系统 NT4.0需要的内存及其他一些内存需求后综合确定，最佳的情况是给SQL Server分配尽可能多的内存，而不产生页面调度。
　　1?根据物理内存合理规划SQL Server可用内存
　　在大多数的生产环境中，服务器配备的物理内存是64MB～128MB，偶尔也有256MB的，只要设置恰当是完万能满足SQL Server的内存需求的。下表是笔者关于SQL Server内存分配的建议规划，供参考。


物理内存 分配给SQL Server 设置值(单位：2KB)
8MB 4MB 2048
16MB 8MB 4096
32MB 16～18MB 8192～9216
48MB 28～34MB 14336～17408
64MB 40～46MB 20480～23552
128MB 100～108MB 51200～55296
256MB 216～226MB 110592～115712
512MB 464～472MB 237568～241664

　　以下是SQL Server内存选项(Memory)设置方法
　　(1)从Microsoft SQL Server程式集中启动SQL Enterprise Manager；
　　(2)从Server Manager窗口中选择“Server”菜单选项；
　　(3)在“Server”菜单中选择“Configurations”选项；
　　(4)在“Server Configuration”对话框中选择”Configuration”标签，Configuration窗口显示设置选项列表；
　　(5)选中“Memory”项目，在“Current”栏填入新值；
　　(6)停止并重新启动SQLServer服务，使设置生效。
　　2?合理扩充虚拟内存、增大SQL Server可用内存
　　当SQL Server系统确实需要扩大可用内存时，应在磁盘空间充足的情况下扩充供虚拟内存，并相应增大 SQL Server可用内存。具体做法是，系统管理员首先扩充服务器的虚拟内存，然后再参考上表增大SQL Server可用内存，关键是要根据系统的负载情况综合决定是否扩充内存、优化设置。
　　3?使用tempinRAM
　　SQL Server使用tempdb临时数据库作为一些查询连接操作时排序或创建临时表的工作空间。将tempdb创建在RAM中能使系统操作性能有较大提高，而且因为tempdb在每次重启动服务器时都重建，这样即使有非正常的关闭也是较为安全的，例如停电故障。要将tempdb创建在RAM中，能使用sp_configure进行设置，具体用法请参阅有关资料。
　　由于tempdbinRAM使用的内存是由系统从内存体独立分配的，和SQL Server的内存选项设置的可用内存池是分开的，使用tempdbin RAM将减少整个系统的可用内存，应根据SQL Server和服务器运行情况进行设置，否则就可能适得其反，影响系统性能。另外，适当增加tempdb数据库空间，即使不使用tempdbin RAM，也能提高数据库的运行速度。
　　4?注意事项
　　(1)建议在生产环境中SQL Server不要设置小于32MB内存，而且数据库服务器上尽量不要运行其他应用程式；
　　(2)扩充供虚拟内存、增大SQL Server可用内存，应考虑物理内存使用状况和磁盘空间许可情况；
　　(3)在可能的情况下，要为系统留有部分额外的内存，这样在服务器上打开一个服务或添加一个进程且不改动SQL Server内存设置时，不致于使NT服务器的运行速度受到影响(变得非常慢)，一般认为最小为2MB最大为20MB。
四、巧用内存设置，解决统计服务器问题

　　一单位的统计服务器投入使用后，运行速度较慢，经排查原因，发现SQLServer中的内存选项(Memory)仅为安装缺省值??16MB(而服务器有128MB的物理内存)，在将内存值调整为100MB时却误将其改成了 1000MB，使得SQL Server服务不能启动，统计数据库打不开，也就不能再次进入SQL Enterprise Manager修改内存设置了。由于近期未备份业务数据，不到万不得已不能重装SQLServer数据库，就试图用命令行参数命令来重新启动SQL Server服务，但均不能奏效，陷入了困境。我们经过仔细分析提出：既然SQL Server可用内存设置值远远大于物理内存，造成SQLServer服务不能启动，何不扩充虚拟内存呢?经设法将机器虚拟内存扩充至1000MB并重新启动，SQL Server数据库成功启动，问题迎刃而解。

五、结束语

　　目前，大多数单位投入使用的Microsoft SQL Server数据库服务器的物理内存一般都在64MB以上，如农业银行省、市分行的统计服务器配备128MB物理内存，只要按照上面提出的方法合理规划、优化NT和SQL Server的内存设置，使设置尽可能达到最优，应用系统就一定能够充分发挥设计功能、满足业务需求。□ rver数据库服务器内存设置的策略

客户端：  
  sql:='Select   top   n   from   tablename   where   id>'+curmaxid;  
  Datas:=ClientDm.ATest.MSearch(Sql);  
          if   Not   VarisNULL(dATAS)   THEN  
          BEGIN  
              CdsTypes.Close;  
              CdsTypes.Data:=NULL;  
              CdsTypes.Data:=DATAS;  
              DATAS:=Null;  
          END;  
   
  用语句来控制的查询，，分页等。这样服务器始终保持最小的内存使用状态！！！说的有点模糊，，见晾  

SQLServer2000里自动重建索引

SQLServer2000里自动重建索引

--王成辉翻译整理，转贴请注明出自微软BI开拓者www.windbi.com

6 p) W) }. ?# ^

--原帖地址

在所有的OLTP环境里，实质上所有的索引都将随着时间产生碎片。几乎所有的UPDATE、INSERT、DELETE活动都将引起索引比最初创建时变得更无组织。页拆分更多，大量的页上只有很少的数据，因此满足每个SELECT需要更多的I/O。数据和索引的碎片越多，应用程序就会更慢，数据花费的空间就更多。对此你能做什么呢？你可以定期的重建索引。 

0 ^& g; ]) {9 @% `$ q, i6 @

那么什么可以立即使用呢？

) ~$ c# E* u* h* Z

基本上你可以使用数据库维护向导来执行索引重建，创建维护计划来完成。如果你原意接受它固有的缺陷，这也可以使用。首先，用维护向导来配置和完成索引重建是不慎重的。它将重建每一个索引，不管它是否需要重建。如果你有一个有很多大表和大量索引的大数据库，这会出问题，因为不加区别的重建整个数据库的索引会花费很长的时间，会使你的维护窗口不可用。问题在于，要么全部重建，要么全部不重建，你根本不能以任何方式分批处理数据库的表。

 

0 u8 u M5 x7 g' K. m+ _0 |* v

 

; _- ~" c! x- |. M2 B; r

那么有什么别的能做吗？你可以写一个脚本来重建选择的表的索引。这样你能对数据库分批处理以减少在重建索引时你维护窗口执行的时间。你需要将这个时间减小到最少，因为重建索引会对表执行排它锁，在重建索引期间禁止用户访问。所以你可以每周的每个工作日的晚上重建五分之一表的索引，所有的索引至少一周做一次。然而，这也是不慎重的――你将重建所有表的索引而不论数据和索引是否是有碎片。

这里推荐选择性的重建索引。你需要检查表的索引和数据的碎片，保留数据，据此操作，重建索引要用确定的且区别对待的方式。仅仅通过这样系统的方法，你可以仅重建那些实际需要重建的表的数据和索引。而且也只有这种方式能最小化索引重建的时间。在整个索引重建期间，如果你不想影响你的用户的话，减少索引重建的时间是至关重要的。

8 r- \, S. Y2 K3 H& D) r

那么我们怎样可以解决呢？

. T) w& N3 K0 T8 J- q6 Y6 J5 G! J1 `

可以使用命令

0 G1 I( E# ?+ K& a- L1 q( m1 p

DBCC SHOWCONTIG()

- T" @% G7 |, H, F

SQLServer2000比以前版本有一个大的改进就是这个简单而又至关重要的命令。DBCC SHOWCONTIG是SQLServer提供来检查索引碎片情况的工具。在以前的版本里（7.0和更早的版本），这个命令只输出文本，如果手工处理这个命令很好，然而，要实现自动化目的，它会带来严重的问题。那意味着你要循环执行每一个表并将结果输出到文本文件，然后为了读和解释原文的输出结果以便获得你寻找的信息，需要进行烦人的结构化处理。

2 |, T+ B, k. m6 \

SQLServer2000对DBCC SHOWCONTIG()命令引进了一个关键子句，名为WITH TABLERESULTS。这意味着你能运行这个命令然后将捕获的数据直接输出到表里，而不是还需要使用XP_CMDSHELL来操作的文本文件里。

' I# u, _8 i+ }6 Y* V- \# ]* C1 r

在SQLServer2000里，这意味着你能结构化的循环处理表，通过在它们上面运行DBCC SHOWCONTIG命令以将捕获碎片信息插入表中。然后你能循环使用这个结果，根据碎片的情况，选择性的进行碎片整理。可以用下面的存储过程实现：

CREATE PROCEDURE sp_defragment_indexes @maxfrag DECIMAL

AS --王成辉翻译整理，转贴请注明出处

! \& Y& R# |% S* `- C$ f1 }2 E4 q

--声明变量

, N& q3 z0 i3 A) o1 A/ L1 T

SET NOCOUNT ON

6 S. S$ e! M" }. ~) `

DECLARE @tablename VARCHAR (128)

: g1 x3 [- U& r+ i

DECLARE @execstr VARCHAR (255)

5 d4 P8 z: A. V, t

DECLARE @objectid INT

8 P2 Z; p6 G3 w3 \# V) y

DECLARE @objectowner VARCHAR(255)

DECLARE @indexid INT

! E8 l8 N: T% v) S* Q/ b

DECLARE @frag DECIMAL

0 o3 c" }6 e% @6 e: m

DECLARE @indexname CHAR(255)

( g! ^% t8 v5 C: B$ B+ y+ M

DECLARE @dbname sysname

! w8 f. X9 @7 ^2 L% T4 k, b8 K/ P8 x

DECLARE @tableid INT

0 u( P: u! `$ Y6 M; W

DECLARE @tableidchar VARCHAR(255)

--检查是否在用户数据库里运行

; v) j( J: ^2 c

SELECT @dbname = db_name()

% E5 L8 q! [; g, g: Q

IF @dbname IN ('master', 'msdb', 'model', 'tempdb')

BEGIN

- e( q& j; S( d

PRINT 'This procedure should not be run in system databases.'

4 K! E. ~5 s. D9 C5 e( D. l

RETURN

END

, B! {2 K# ^4 J0 ~& ?! D

--第1阶段:检测碎片

% ?% t( Q v; m# S' Z0 A* I/ w

--声明游标

DECLARE tables CURSOR FOR

/ u v1 J7 J x8 @& a2 W# @

SELECT convert(varchar,so.id)

1 k: M& S3 j* Y4 ]& q

FROM sysobjects so

) B0 J0 v0 U( y) _, o6 r

JOIN sysindexes si

; x/ S! l& H g, H V l5 X

ON so.id = si.id

WHERE so.type ='U'

AND si.indid < 2

2 u5 Y9 F* Q( }# v; H

AND si.rows > 0

/ h ?1 |& n' L( q; Q8 M8 z; e) e: a

-- 创建一个临时表来存储碎片信息

CREATE TABLE #fraglist (

ObjectName CHAR (255),

ObjectId INT,

! r. ?! X' [6 b9 s6 @( J6 p

IndexName CHAR (255),

# _4 V4 r; {' C9 R9 U" i1 i0 S

IndexId INT,

2 X' t: g* e" P7 V6 a- c/ {; g

Lvl INT,

! Y' S( @6 z. e. P

CountPages INT,

( B/ w8 @' W$ T9 k0 E

CountRows INT,

8 c8 h$ [' b7 \: Q4 V

MinRecSize INT,

MaxRecSize INT,

AvgRecSize INT,

ForRecCount INT,

. o ~( ]% G6 C3 _! G

Extents INT,

ExtentSwitches INT,

AvgFreeBytes INT,

' {! F; `. g/ {7 d

AvgPageDensity INT,

; R6 _7 |0 E- e4 e

ScanDensity DECIMAL,

BestCount INT,

ActualCount INT,

LogicalFrag DECIMAL,

) Z+ b( ~; j! S5 c& S& ? l1 b2 R

ExtentFrag DECIMAL)

! r/ q& N' a9 R4 @2 n( |, a

--打开游标

OPEN tables

5 {& \! T0 A: z) y- N, G$ { F

-- 对数据库的所有表循环执行dbcc showcontig命令

FETCH NEXT

, q$ d' Q3 [1 M

FROM tables

; I7 d! `) A0 z+ S' ^8 u$ p7 p

INTO @tableidchar

J8 A4 {% V" B

WHILE @@FETCH_STATUS = 0

BEGIN

0 x1 W: v0 N* }$ D4 `

--对表的所有索引进行统计

; U6 f/ W9 t/ Y' Q6 O5 n! y( p

INSERT INTO #fraglist

EXEC ('DBCC SHOWCONTIG (' + @tableidchar + ') WITH FAST, TABLERESULTS, ALL_INDEXES, NO_INFOMSGS')

4 T3 A$ s: y" j0 T/ c

FETCH NEXT

; f3 Q7 N! @+ B, W9 Q

FROM tables

INTO @tableidchar

END

) U. s" X) f) V( A% s% s, q5 v1 F, y, t

-- 关闭释放游标

' p) Z8 [( ]" C( ]! Y

CLOSE tables

) L; X- |- k/ Y0 w9 ?( T7 z2 T

DEALLOCATE tables

- g8 R9 T' y( M* P |$ E

-- 为了检查，报告统计结果

SELECT * FROM #fraglist

0 F! _% O2 D' n( \$ ~. ^- j

--第2阶段: (整理碎片) 为每一个要整理碎片的索引声明游标

4 B( F1 H# W' }6 e* D

DECLARE indexes CURSOR FOR

SELECT ObjectName, ObjectOwner = user_name(so.uid), ObjectId, IndexName, ScanDensity

- w) P$ a7 u" a" x) H6 r$ q

FROM #fraglist f

' ~9 D# z( O- i

JOIN sysobjects so ON f.ObjectId=so.id

# r2 b* t+ I* _! I [8 v8 r

WHERE ScanDensity <= @maxfrag

/ D( e5 E- Y, O1 F' @5 \

AND INDEXPROPERTY (ObjectId, IndexName, 'IndexDepth') > 0

-- 输出开始时间

! u- ?) @3 H; k2 o4 F, w8 A \

SELECT 'Started defragmenting indexes at ' + CONVERT(VARCHAR,GETDATE())

, }3 k+ h$ k( M

--打开游标

OPEN indexes

& {/ t) H1 I" W: \

--循环所有的索引

x3 Z; q6 ]/ n1 Z# u

FETCH NEXT

FROM indexes

INTO @tablename, @objectowner, @objectid, @indexname, @frag

7 r" W7 I6 [) c8 O5 X6 l/ Y

WHILE @@FETCH_STATUS = 0

BEGIN

$ S# y6 a/ m# W& }* C5 ]& f6 I

SET QUOTED_IDENTIFIER ON

2 F0 m9 n" T3 e7 ]4 }: _# K

SELECT @execstr = 'DBCC DBREINDEX (' + '''' +RTRIM(@objectowner) + '.' + RTRIM(@tablename) + '''' +

?8 d/ H6 y5 r' g

', ' + RTRIM(@indexname) + ') WITH NO_INFOMSGS'

' n4 A2 l+ B3 M2 l" r

SELECT 'Now executing: '

SELECT(@execstr)

5 E) ^$ S2 H5 A! _3 ]7 X9 x! K

EXEC (@execstr)

SET QUOTED_IDENTIFIER OFF

* r0 n3 S( \5 j

FETCH NEXT

: j& t& ^. ?" v

FROM indexes

INTO @tablename, @objectowner, @objectid, @indexname, @frag

END

-- 关闭释放游标

CLOSE indexes

DEALLOCATE indexes

6 J2 }. A+ u/ f- [) p) w0 }1 a

-- 报告结束时间

SELECT 'Finished defragmenting indexes at ' + CONVERT(VARCHAR,GETDATE())

-- 删除临时表

" I$ @2 q# w& ~( |

DROP TABLE #fraglist

- @" p3 `8 a, h3 `

GO

/ I7 L. {5 J( O. |* N

使用

这个存储过程应该创建在master数据库里，以便你能在服务器上的任何用户数据库里使用。

在用户数据库里通过传递一个参数（MAXFRAG）来运行。该参数是一个百分比值。意思是任何索引的碎片扫描密度小于这个值。例如，如果你想要整理那些扫描密度小于95％的索引的碎片：

2 o3 e$ J( b" x/ u/ l

USE pubs

GO

7 U* ~7 w; J* ~3 ]6 p" v+ |6 I- J

EXEC sp_deframent_indexes 95.00

! K6 E0 v/ ?! e4 G" G! t9 |

局限

这个过程依赖于的标准是扫描密度，但扫描密度对于那些跨越多个文件的索引来说不是一个有效的标准。如果你的索引确实跨越多个文件，你需要用另一个标准（如Logical Frag）来更改这个存储过程。然而，这类更改超过本文的范围；如果你的索引跨越多个文件，你需要做更多的工作。 

怎样做，做什么？

0 Q7 N/ R V% ~! n2 q( y6 `) h4 @' b

这个存储过程有两个独特的部分。

第1阶段

在这部分里，存储过程通过在数据库里的每个表上运行下面的命令来检查索引碎片：

DBCC SHOWCONTIG (‘tablename') WITH FAST, TABLERESULTS, ALL_INDEXES, NO_INFOMSGS

0 S4 T+ X" u4 S

命令的结果存储在预先创建的临时表#fraglist里。这里就会用到DBCC SHOWCONTIG 语句的WITH TABLERESULTS的好处，仅这一点，真正的节省了太多的以前版本得到同样结果所花费的麻烦和精力。

$ q8 C& `' o! l, c; }

你应该注意该存储过程工作的数据库的表的拥有者是不是dbo，通常是。我发现我最初的版本不起作用，当时一个软件经销商给我们提供的新系统的数据库里就出现了拥有者不是dbo的表。当我在这个新系统上第一次运行我的碎片整理过程时，这个程序的缺点就暴露无遗了，最后彻底失败。这个问题实际上出现在碎片整理阶段（阶段2），因为表在这里要引用表名，而在阶段1，DBCC SHOWCONTIG命令引用的时表的ID即object_id。

第2阶段

这儿使用了另一个游标来循环处理表#fraglist里的记录，这些记录是那些扫描密度低于传给存储过程参数的那个阈值的表：

4 }6 e7 `5 k+ L

DBCC DBREINDEX()

执行的结果以输出文件的形式显示在表#fraglist的内容之后，以便你能查看表和索引的碎片，正如屏幕上所显示的那样，也可以通过查看DBCC DBREINDEX()执行的结果列表来查看采取的动作。利用这些你也能推导出每个索引重建的时间。 

( @9 p* A4 w1 ~8 |! R0 n) F: g

输出结果是什么意思？

; e1 v9 I4 n$ G

输出示例：

! F. R/ G" }/ e: }; U2 Q4 ~1 N

 

6 ~$ @3 N. z, R! W' n0 x

上面是在Excel里打开的存储过程输出文本文件的一个截屏。为了简洁一些列已经删掉了。你需要用文本文件向导来打开它，选择固定列宽，打开导入从第三行起。

0 o( ]) y5 c' e F

这里，你能够检查你选择检查的数据库里的表的扫描密度。

0 r( Q8 ^# S! {0 x+ c

在接下来的输出文件里（DBCC SHOWCONTIG输出结果的后面），你会发现正被重建索引的每个表或索引的细节，这部分的开始和结束部分都有重建索引的开始和结束时间。如下面例子显示的那样：

9 Z# w' T* w( m5 q3 M S4 @, }5 G

为什么不使用DBCC INDEXDEFRAG()去减少阻塞？

9 `& M- r; q. P( ~

答案是如果你想要或者需要的话就使用它。如果你需要7×24小时的在线操作，那么DBCC DBREINDEX()的排他表锁不适合你的业务，你可以使用它来代替DBCC DBREINDEX()。然而，你需要适当改变一下语法，因为它们是不相同的（谢谢，微软！）。如果你不知道它们的区别，这里有一个简单的摘要：当运行DBCC DBREINDEX()的时候，必须对表有排他锁，因为它是一个完全的，彻头彻尾的索引重建操作。而DBCC INDEXDEFRAG()就不那么完全了，在线的操作试图改善你索引的环境而不至于引起阻塞和中断OLTP（希望如此）。我必须承认我从来不用DBCC INDEXDEFRAG()，因为很幸运的是我的系统不需要严格的7×24在线且要求不阻塞，所以我不敢担保是否有效率。我已经理解它不是和DBCC DBREINDEX一样有效率。然而它的确比什么都没有强，所以如果你的数据库运行一个全球的WEB站点并且从来不能停止，这在今天这也很普遍，那么你需要使用它来代替以改变这个存储过程。 

添加到调度任务里

对于有相当经验的DBA来说这是一个相关的微不足道的任务，所以我在这里不会提供它的代码。作为一个独立的任务或在你存在的维护作业里的一个步骤都行。你要确保作业的步骤或作业里的输出结果是一个文本文件以便你能保存和查看所有重要的输出文件。 

6 W3 T+ X' ?4 K$ P0 ~2 I7 }

结论

希望这篇文章和代码能帮助你完成一个对数据库服务器维护来说更好的更精确的方法。现在的维护窗口开销很大，所以在影响用户和执行时间上保持最小的同时也提供了有效率和良好的数据库服务器维护。用调度作业实现这个过程，小心的监控它的输出结果。

http://topic.csdn.net/t/20050115/10/3727581.html

--执行这个语句  
  exec   sp_configure   'min   memory   per   query',1024

1。   你的内存设置的太小了！企业管理器--右键SQL实例--内存--选择"动态地配置SQL   Server内存--将最小值设置为0--最大值设置大一点  
  2。   要不就是你的内存容量不够了！需要加内存容量

MSSQLSERVER_8651

 详细信息

" f% I4 c" X# A4 F& S2 l0 A

! D) R H3 o+ I" \( c* T, p( X

3 d7 V+ E$ s1 Q0 V& ~- W* M y f" K/ m/ d8 [% A) a8 y! p9 a$ D7 Y2 n! W/ x" y# X3 v! G& e/ A7 z7 T0 w" w" \- k* N2 Y$ f* P/ m: @0 d9 c# N# E: E' e: B, J1 z" a" J1 Q- g5 w: r' ] x9 e0 y8 d P5 J/ l9 K2 ]& |$ s' W1 ~- [" e6 s+ s0 m* B$ J1 N( z* R; y* [$ m6 T, E. U! z/ c' o6 Q' i( Q* v9 N& i) X9 u7 i1 W9 h. V% c: h f

, e g9 m7 H: K& K. H 产品名称	; A- y% ]1 c9 n# L0 A SQL Server
产品版本	10.0
$ e; { ~6 R7 K5 l% Q* @* {! e1 j3 b o 产品内部版本号	10.00.0000.00
事件 ID	0 Y; O9 ?- e4 b4 T3 `$ Y 8651
事件源	MSSQLSERVER
# ]$ i$ f1 e2 A; l- ~ 组件	1 L! m' `2 w \ M SQLEngine
0 Z8 o( `6 g& p; q8 O/ @/ z+ N 符号名称	$ n* E% k0 `2 Z u MEMGRANT_ERR
消息正文	/ ]( ^% m. e F9 Q, A4 a 未能执行所请求的操作，因为可用内存少于最小查询内存。请减小“每次查询占用的最小内存”服务器配置选项的配置值。

* x* J( k, |: _1 D4 h

 解释

其他进程正在占用服务器内存（在服务器中施加内存压力）。

0 J- I9 P/ ] Q* Q* Q4 j( S

 用户操作

; y- P9 v3 e+ H+ c4 l

减小“每次查询占用的最小内存”服务器配置选项的配置值，或者减少服务器的查询负载。

下面的列表概述了有助于解决内存错误的一般步骤：

; i* J/ @4 E; I+ C5 C) ]& X

* o# P, l+ v6 G a
1. 验证其他应用程序或服务是否占用此服务器上的内存。重新配置不太重要的应用程序或服务，使其占用更少的内存。
   9 h4 r5 V9 x, J" ?9 B- `
2. 开始收集 SQL Server: Buffer Manager、SQL Server: Memory Manager 的性能监视器计数器。
   , W) q8 @! F# @* g: ?
3. 检查下面的 SQL Server 内存配置参数：
   0 q* ?1 F( R7 a% J# o* u
   1 ]9 `& x1 A* s- X. Y5 w
   • max server memory
     
   • min server memory
     5 V9 I$ L; O8 K* o' S9 b
   • awe enabled
     ; T( W% Z: p( r6 k; |: u! i* k! e5 J8 H
   • min memory per query
     
   注意不正常的设置。根据需要将其更正。SQL Server 联机丛书中的“设置服务器配置选项”中列出了默认设置。
   
4. 如果正在使用地址窗口化扩展插件 (AWE)，请验证是否启用了 Windows 安全设置“锁定内存页”。
   
5. 检查工作负荷（例如，并发会话数，当前执行的查询）。
   

. i3 u' ?, b" b) K6 y' P" ?4 z

以下操作可以使更多内存可供 SQL Server 使用：

• 如果除 SQL Server 外的应用程序正在占用资源，请尝试停止运行这些应用程序，或者考虑在单独的服务器上运行它们。这样做将消除外部内存压力。
  
• 如果已配置 max server memory，请增大其设置。
  

) e: s4 K( |, y4 \# H' [

运行以下 DBCC 命令以释放几个 SQL Server 内存缓存。

- }& x! F! a8 v& H3 ]

# _) S& N/ b' w. }! l
• DBCC FREESYSTEMCACHE
  
• DBCC FREESESSIONCACHE
  , W1 I( b. I3 S3 ]. R+ m' a, i2 N( h1 E
• DBCC FREEPROCCACHE
  

如果问题仍存在，则您将需要进一步调查，可能需要减小工作负荷。