最近接手一个搜索新闻的爬虫程序，
window2008, Sqlserver2000 SP4, 系统内存8G
SQLServer内存配置 最小:1024M,最大5816M总共搜索大概300个网站，通过数据库管理在什么时候搜索哪个网站
利用SQLSERVERAGENT来启动搜索程序
每天24小时执行，对数据库的操作非常频繁
现在Sqlserver的数据文件大概5G, 日志文件13G问题1
大概每隔1天左右，就会发生 错误:17803,可用内存不够!
然后SQLSERVERAGENT就停止了，搜索程序不能继续启动
有没有什么解决办法？问题2
有一个管理界面，有时候打开画面的时候出现下面的错误
8642 查询处理器未能为执行并行查询启动必要的线程资源。
发生这个错误的原因是什么，应该怎样避免？问题3
以前曾经压缩过一次日志文件，现在再次想压缩的时候，只能减少几百兆
有没有什么办法尽量让日志文件减小，日志文件太大了会不会影响内存？
window2008, Sqlserver2000 SP4, 系统内存8G
SQLServer内存配置 最小:1024M,最大5816M总共搜索大概300个网站，通过数据库管理在什么时候搜索哪个网站
利用SQLSERVERAGENT来启动搜索程序
每天24小时执行，对数据库的操作非常频繁
现在Sqlserver的数据文件大概5G, 日志文件13G问题1
大概每隔1天左右，就会发生 错误:17803,可用内存不够!
然后SQLSERVERAGENT就停止了，搜索程序不能继续启动
有没有什么解决办法？问题2
有一个管理界面，有时候打开画面的时候出现下面的错误
8642 查询处理器未能为执行并行查询启动必要的线程资源。
发生这个错误的原因是什么，应该怎样避免？问题3
以前曾经压缩过一次日志文件，现在再次想压缩的时候，只能减少几百兆
有没有什么办法尽量让日志文件减小，日志文件太大了会不会影响内存？
定期监视 Microsoft® SQL Server™ 实例，确认内存的使用在正常范围内，并且没有进程（包括 SQL Server）缺少内存或消耗太多的内存。
若要监视内存不足情况，可从下列对象计数器开始：
Memory:Available Bytes
Memory:Pages/sec
Available Bytes 计数器表示当前进程可使用的内存字节数。Pages/sec 计数器表示由于缺页处理而从磁盘取回的页数，或由于缺页处理而写入磁盘以释放工作集空间的页数。
偏低的 Available Bytes 计数器值表示计算机从总体上短缺内存或一个应用程序没有释放内存。高比率的 Pages/sec 计数器值可能表示换页过度。监视 Memory:Page Faults/sec 计数器以保证磁盘活动不是由换页造成的。
换页率偏低（以及由此产生的换页错误）是正常的，即使计算机有大量的可用内存。Microsoft Windows NT® 虚拟内存管理器 (VMM) 在调整 SQL Server 和其它进程的工作集大小时，会盗用这些进程的页，从而导致换页错误。若要确定是 SQL Server 而非其它进程导致过度换页，请监视 Process:Page Faults/sec 计数器。
有关解决过多换页的更多信息，请参见 Windows NT 4.0 或 Microsoft Windows® 2000 文档。
隔离 SQL Server 所用的内存
默认情况下，SQL Server 会依据可获得的系统资源动态改变它的内存需求。如果 SQL Server 需要更多的内存，它会要求操作系统确定是否有空闲的物理内存可用，并使用可用的内存。若 SQL Server 不再需要当前分配给它的内存，它就将内存释放给操作系统。不过，可以用 min server memory、max server memory 和 set working set size 服务器配置选项替代动态使用内存的选项。有关更多信息，请参见服务器内存选项。
若要监视 SQL Server 正在使用的内存量，请检查下列性能计数器：
Process:Working Set
SQL Server:Buffer Manager:Buffer Cache Hit Ratio
SQL Server:Buffer Manager: Total Pages
SQL Server:Memory Manager:Total Server Memory (KB)
Working Set 计数器表示的是一个进程所占用的内存数量。若这一数值持续低于 SQL Server 配置使用的内存数量(由"最小服务器内存"和"最大服务器内存"服务器选项设置)，则表示 SQL Server 所配置的内存比它所需要的多。否则，用"设置工作集大小"服务器选项修改工作集大小。有关更多信息，请参见 set working set size 选项。
Buffer Cache Hit Ratio 计数器值依应用程序而定，但比率最好为 90% 或更高。增加内存直到这一数值持续高于 90%，表示 90% 以上的数据请求可以从数据缓冲区中获得所需数据。
若 Total Server Memory (KB) 计数器值与计算机的物理内存大小相比一直很高，可能表示需要更多的内存。
大概每隔1天左右，就会发生 错误:17803,可用内存不够!
然后SQLSERVERAGENT就停止了，搜索程序不能继续启动
有没有什么解决办法？是否启用了AWE扩展内存？有个要注意的问题是Page in memory是否设置，这个选现你可以google一下问题2
有一个管理界面，有时候打开画面的时候出现下面的错误
8642 查询处理器未能为执行并行查询启动必要的线程资源。
发生这个错误的原因是什么，应该怎样避免？
这个推荐你看一下 SQL 2005技术内幕存储引擎问题3
以前曾经压缩过一次日志文件，现在再次想压缩的时候，只能减少几百兆
有没有什么办法尽量让日志文件减小，日志文件太大了会不会影响内存？backup log dbname with truncate_only;
go
dbcc shrinkdatabase(dbname);
go
SQLServer内存占用是最大占用机制的
也就是系统空闲的内存越大，就可能占越多
但当系统空闲内存较少时，SQLServer会释放相对占用的内存
先把你的SqlServer内存占用最大值调的相对小一些看看
当出现这种情况时，分页进程将显著增加并且会对性能产生负面影响。Windows 2000 和 Windows Server 2003 内存管理器使用 PAE 向程序提供更多的物理内存。这会降低对交换页面文件内存的需要，从而提高了性能。程序本身并不知道实际的内存大小。所有的内存管理和 PAE 内存分配都由内存管理器处理，与运行的程序无关。不过这是32位windows特性，如果改用64位windows的话，由于可管理内存增大，系统自动内存要求支持大于2gb应用程序。
解决方案
1、修改启动文件，添加/pae和/3gb开关，步骤为：
右击我的电脑 --> 属性 --> 高级 --> 启动和恢复 --> 设置 --> 手工编辑启动文件，加入开关，
以下是一个 Boot.ini 文件的示例，其中已添加了 PAE 和3gb开关：
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Windows Server 2003, Enterprise" /fastdetect /PAE /3gb
启用awe有用吗？
32位操作系统有个很大的缺陷，应用程序无法访问大于4G的进程地址空间，因为32位的指针无法保存大于4G的地址空间
如果大于4G，则需要使用地址窗口化扩展插件(AWE)，具体操作如下：
1，启动物理地址扩展
(1)找到C:\boot.ini,并删除其只读属性.
(2)编辑boot.ini，在ARC路径中添加/PAE参数.例如：
在windows Server 2003 Enterprise Edition 中，编辑后的ARC路径如下：
muti(0)disk(0)partition(1)windows="windows Server 2003 Enterprise,Edition"/fastdetect/PAE
保存后将其恢复为只读模式，然后重新启动计算机。如果计算机上的可用物理内存超过16G，应确保boot.ini文件中没有/3gb参数---如何启动AWE选项
sp_configure'show advanced options',1
reconfigure
go
sp_configue 'awe enabled',1
reconfigure
go
---手动配置内存选项
sp_configure'show advanced options',1
go
reconfigure
go
sp_configure 'min server memory' --服务器最小内存
sp_configure 'max server memory' --服务器最大内存
sp_configure 'index create memory'--创建索引占用的内存
sp_configure 'min memory per query'--每次查询占用的最小内存
经常看见有人问，MSSQL占用了太多的内存，而且还不断的增长；或者说已经设置了使用内存，可是它没有用到那么多，这是怎么一回事儿呢？
首先，我们来看看MSSQL是怎样使用内存的。
最大的开销一般是用于数据缓存，如果内存足够，它会把用过的数据和觉得你会用到的数据统统扔到内存中，直到内存不足的时候，才把命中率低的数据给清掉。所以一般我们在看statistics io的时候，看到的physics read都是0。
其次就是查询的开销，一般地说，hash join是会带来比较大的内存开销的，而merge join和nested loop的开销比较小，还有排序和中间表、游标也是会有比较大的开销的。
所以用于关联和排序的列上一般需要有索引。
再其次就是对执行计划、系统数据的存储，这些都是比较小的。
我们先来看数据缓存对性能的影响，如果系统中没有其它应用程序来争夺内存，数据缓存一般是越多越好，甚至有些时候我们会强行把一些数据pin在高速缓存中。但是如果有其它应用程序，虽然在需要的时候MSSQL会释放内存，但是线程切换、IO等待这些工作也是需要时间的，所以就会造成性能的降低。这样我们就必须设置MSSQL的最大内存使用。可以在SQL Server 属性（内存选项卡）中找到配置最大使用内存的地方，或者也可以使用sp_configure来完成。如果没有其它应用程序，那么就不要限制MSSQL对内存的使用。
然后来看查询的开销，这个开销显然是越低越好，因为我们不能从中得到好处，相反，使用了越多的内存多半意味着查询速度的降低。所以我们一般要避免中间表和游标的使用，在经常作关联和排序的列上建立索引。
dbcc memorystatus
把当时的memory的详细信息输出来看看.执行:
DBCC FREEPROCCACHE
从过程高速缓存中删除所有元素。DBCC DROPCLEANBUFFERS
从缓冲池中删除所有清除缓冲区。
Stolen 664
Free 317504
Procedures 8339
Inram 0
Dirty 561
Kept 0
I/O 0
Latched 25
Other 192499Buffer Counts Buffers
Commited 519592
Target 519592
Hashed 193085
InternalReservation 151
ExternalReservation 0
Min Free 256
Visible 455760Procedure Cache Value
TotalProcs 1975
TotalPages 8339
InUsePages 4052Dynamic Memory Manager Buffers
Stolen 9003
OS Reserved 928
OS Committed 906
OS In Use 898
General 1249
QueryPlan 8320
Optimizer 0
Utilities 29
Connection 111Global Memory Objects Buffer
Resource 920
Locks 71
XDES 24
SQLCache 196
Replication 2
LockBytes 2
ServerGlobal 20Query Memory Objects Value
Grants 0
Waiting 0
Available (Buffers) 338327
Maximum (Buffers) 338327Optimization Queue Value
Optimizing 0
Waiting 0
Available 32
Maximum 32
Target 519592这个说明内存已经很紧张了吧， Garnett_Kg?
Stolen 664
Free 317504
Procedures 8339
Inram 0
Dirty 561
Kept 0
I/O 0
Latched 25
Other 192499
根据dbcc memorystatus结果，内存方面此时应该是没问题的。楼主最好看看你的搜索程序有没问题。
SQL的缓存性能调整一下，
查看一下死锁的问题，是否第一次搜索尚未完成，接着又进行第二次搜索了，写SQL语句的时候习惯用SELECT * FROM （WITH LOCK /NOLOCK）
http://support.microsoft.com/default.aspx?scid=kb;en-us;289290
BUG: SELECT INTO with Fixed Memory May Cause Errors 802 and 17803
http://support.microsoft.com/default.aspx?scid=kb;en-us;197299
FIX: SQLTrace May Cause Error 17803 on a Server
http://support.microsoft.com/default.aspx?scid=kb;en-us;162033
FIX: When you use Transact-SQL cursor variables to perform operations that have large iterations, memory leaks may occur in SQL Server 2000
http://support.microsoft.com/default.aspx?scid=kb;en-us;837957 自己搜索一下，很有可能是BUG.你的sql打到SP4了吗
监视内存的使用
定期监视 Microsoft® SQL Server™ 实例，确认内存的使用在正常范围内，并且没有进程（包括 SQL Server）缺少内存或消耗太多的内存。
若要监视内存不足情况，可从下列对象计数器开始：
Memory:Available Bytes
Memory:Pages/sec
Available Bytes 计数器表示当前进程可使用的内存字节数。Pages/sec 计数器表示由于缺页处理而从磁盘取回的页数，或由于缺页处理而写入磁盘以释放工作集空间的页数。
偏低的 Available Bytes 计数器值表示计算机从总体上短缺内存或一个应用程序没有释放内存。高比率的 Pages/sec 计数器值可能表示换页过度。监视 Memory:Page Faults/sec 计数器以保证磁盘活动不是由换页造成的。
换页率偏低（以及由此产生的换页错误）是正常的，即使计算机有大量的可用内存。Microsoft Windows NT® 虚拟内存管理器 (VMM) 在调整 SQL Server 和其它进程的工作集大小时，会盗用这些进程的页，从而导致换页错误。若要确定是 SQL Server 而非其它进程导致过度换页，请监视 Process:Page Faults/sec 计数器。
有关解决过多换页的更多信息，请参见 Windows NT 4.0 或 Microsoft Windows® 2000 文档。
隔离 SQL Server 所用的内存
默认情况下，SQL Server 会依据可获得的系统资源动态改变它的内存需求。如果 SQL Server 需要更多的内存，它会要求操作系统确定是否有空闲的物理内存可用，并使用可用的内存。若 SQL Server 不再需要当前分配给它的内存，它就将内存释放给操作系统。不过，可以用 min server memory、max server memory 和 set working set size 服务器配置选项替代动态使用内存的选项。有关更多信息，请参见服务器内存选项。
若要监视 SQL Server 正在使用的内存量，请检查下列性能计数器：
Process:Working Set
SQL Server:Buffer Manager:Buffer Cache Hit Ratio
SQL Server:Buffer Manager: Total Pages
SQL Server:Memory Manager:Total Server Memory (KB)
Working Set 计数器表示的是一个进程所占用的内存数量。若这一数值持续低于 SQL Server 配置使用的内存数量(由"最小服务器内存"和"最大服务器内存"服务器选项设置)，则表示 SQL Server 所配置的内存比它所需要的多。否则，用"设置工作集大小"服务器选项修改工作集大小。有关更多信息，请参见 set working set size 选项。
Buffer Cache Hit Ratio 计数器值依应用程序而定，但比率最好为 90% 或更高。增加内存直到这一数值持续高于 90%，表示 90% 以上的数据请求可以从数据缓冲区中获得所需数据。
若 Total Server Memory (KB) 计数器值与计算机的物理内存大小相比一直很高，可能表示需要更多的内存。
上面给出的内存信息是正常运行的时候的信息，下次贴出处问题的时候的信息
SQLAgent调用存储过程，存储过程里面再调用asp.net程序，asp.net里面执行搜索出现错误的时候，好像SQLAgent停止运行，执行sql语句的话，还是能从库里面查出信息
从过程高速缓存中删除所有元素。DBCC DROPCLEANBUFFERS
从缓冲池中删除所有清除缓冲区。
最大内存5G多一些，应该不会和系统争用
打了SP4
Stolen 2622
Free 1641
Procedures 109286
Inram 0
Dirty 2240
Kept 0
I/O 0
Latched 25
Other 403778Buffer Counts Buffers
Commited 519592
Target 519592
Hashed 406043
InternalReservation 140
ExternalReservation 0
Min Free 256
Visible 455760
Procedure Cache Value
TotalProcs 22481
TotalPages 109286
InUsePages 53083Dynamic Memory Manager Buffers
Stolen 111908
OS Reserved 920
OS Committed 898
OS In Use 896
General 3227
QueryPlan 109256
Optimizer 0
Utilities 11
Connection 108Global Memory Objects Buffer
Resource 922
Locks 163
XDES 24
SQLCache 2166
Replication 2
LockBytes 2
ServerGlobal 20Query Memory Objects Value
Grants 0
Waiting 0
Available (Buffers) 300042
Maximum (Buffers) 300042Optimization Queue Value
Optimizing 0
Waiting 0
Available 32
Maximum 32
搜索程序的启动是通过sqlagent来启动的，调用存储过程
大概每隔1天左右，就会发生 错误:17803,可用内存不够!
然后SQLSERVERAGENT就停止了，搜索程序不能继续启动
有没有什么解决办法？
--用批處理文件，設定每天半夜重新啟動sql。這樣的話就可以釋放sql暫用的內存。
问题3
以前曾经压缩过一次日志文件，现在再次想压缩的时候，只能减少几百兆
有没有什么办法尽量让日志文件减小，日志文件太大了会不会影响内存？
--每天夜裡自動清除log。語句為：
--use 數據庫名
DUMP TRANSACTION 數據庫名 WITH NO_LOG --
BACKUP LOG 數據庫名 WITH NO_LOG--
DBCC SHRINKDATABASE(數據庫名)--壓縮數據庫把這個寫到sql JOB中即可
楼主可以看看 http://msdn.microsoft.com/zh-cn/library/aa337448.aspx 可能有帮助
从dbcc memorystatus的输出看出，Buffer pool始终没有超过4GB。
而max server memory的设置是>4GB的。对于运行在WOW模式下的
SQL Server ，VAS大小是4GB。如果要使用超过4GB的内存，
你要开启AWE。显然你没有开启AWE开启AWE，重启服务
sp_configue 'awe enabled',1
reconfigure
go要确保启动SQL Server的帐户有“Lock Pages in Memory”权利，
正确配置AWE后，Errorlog里会有相应的信息。2.确认你的SQL Server sp4已经更新了最新的累积补丁包
http://support.microsoft.com/kb/916287/en-us3.个人感觉是SQL Server没能及时响应自身内部的内存压力，最终导致的问题。
服务器负载突然加大可能是个原因。另外32bit SQL Server和64bit的 Windows 2008
这样的组合可能也是一个重要的原因，这样的组合最好不要在生产系统中部署。
建议要么将SQL Server升级到2005/2008 要么将windows降至2003。而且如果操作系统是
64bit，SQL Server最好也用64bit的。而SQL Server 2000只有IA64版本，没有X64版本。
兼容性问题极少罕见，除非是古老的一些SQL写法
看看是哪些存储过程在重编译，引起stored procedure变大的。Troubleshooting stored procedure recompilation
http://support.microsoft.com/?scid=kb%3Ben-us%3B243586&x=3&y=17