to ： tj_dns(愉快的登山者) 确实有多个线程在不断地同时访问一张表，但它们更新和修改的内容是不一样的，而其它的只是在用户只是在读取这张表的数据或将某些数据删除，在本人看来应该不会发生共享冲突，实在是搞不懂为什么随着时间的增长，性能会下降（下降的蛮快的，过了一个星期就有点受不了了） 不管怎么样都为问题的解决提供了一个参考的方法，先谢谢您了^_^，希望您能继续关注，呵呵
to ： weixy() 我也知道，可没办法呀（就目前而言），内存不会太小了吧，都1.2G了，而且要强调的是在系统开始运行时速度是很快的，只是在长时间持续运行后性能下降
to 楼上两位兄弟 对于Yang_(扬帆破浪)的意見我不是作了解释了吗？难道我的解释不成立，这一特性是微软数据库的一大改进呢，当除数据库以外的程序需要内存而系统自身已不能提供时，自动从数据库的内存池中释放部分不用的（里面有一G多呢，其中有好多暂时没用到的）供其它程序使用，因此看起来系统总是不够内存，呵呵。而且其它程序看起来运行得都很正常，使用的内存很稳定（至少看起来是这样的）。 不知道我说的有没有道理，希望大家能够多提意见，搞不懂呀！现在脑子里连问号都没有！！！！
to ： yinzhen(銀圳) win 2000的内存管理应该还可以，如果我的程序里有跑线程，那么内存出现问题的可能性就非常大了，因为有些程序在非线程里一点问题都没有，但在线程里就不一样了，这样的问题我也遇见过， 内存莫明其妙地变少，呵呵，如果使用了线程就要好好检查检查了，不过一旦出现这样的问题是很难找出来的喔
同意yang_(扬帆破浪),由于sql server长时间运行以后只给operation system and other applications只留下5M内存,由于操作系统速度上不去,在起上面的应用的速度也一定快不了. 建议:enterprise manager---right click your sql server--properties--memory---maximum的数值向下调整.
或者建立trace跟踪数据库的更新插入和查询请款
to lonwang() 您的建议很好，我本来就打算采用这些方法进行分析原因所在，可是对跟踪方法不太熟，只好先找找资料罗，有什么好方法可以介绍介绍 首先，我这的情况是： CPU的负载没问题（75%以下） 数据库容量没问题 硬盘容量没问题（85%以内） 高速缓存的命中率没问题（平均93%） 用户连接数据没问题（远没达到最大的255） 我还要进行监控的性能数据还有哪些，关于数据库方面的数据我不太清楚主要要看哪些，它们的数据在什么范围内正常及在什么范围内过载
checkpoint清除脏页 dbccdb
to ： weixy() dbccdb是什么呀！我以前没有专门从事数据库工作的，俺是写程序的，呵呵。还请多多指教！
to dreamyyuan(dreamyyuan) 在我这，存贮过程并不多游标的使用就更少了，且都是些定时作业，最频繁的作业也只是十分钟才运行一次，大部分一天只要运行一次，而在其它的程序运行中每秒钟就要对数据库进行大概二十次左右的操作（查、增、改，删等）。都是不间断运行，应该是这些频繁的操作导致的，可就是找不出什么原因
to qywjg(猎人) 如果是操作系统的问题，那别人是怎么解决的？要真的是这样，恐怕就没人用了！应该有解决的办法的，好多数据量比我这大得多的数据库都运行得很好啊！ 加内存绝对不是解决问题的根本办法，虽然能在一定程度下得到改善，目前的内存足够正常使用，只是不知道原因所在to zqllyh(找感觉) 您所说的LOCKS太少，我查了资料发现从SQL SERVER 7以后LOCKS的数量是由数据库动态分配的，从5000到一个非常非常大的数（上亿了吧），所以我认为应该不是这个问题，想听听您的看法与见解
to hillniu(晓峰) 呵呵，我前面说过的啦，读、写、改、删都有， 主要是应用程序对数据库的操作，存贮过程运用较少(用于定时处理主要是写、删操作)。数据表字段较多，一般都有十几个到二十几个（会不会太多了），本人认为该建索引的地方都已建了（几乎所有与条件相关的建了索引）。我这有一个特点就是应用程序几乎二十四小时不停地对数据库进行操作（晚上二点到早上八九点时较闲，也有每秒钟建立数次数据库操作连接),数据量并不大，因为每天都进行了备份，将要进行频繁操作的表记录进行清理。
Try setting your MAX Memory config in SQL Server to some amount less than the max and see if that helps. That will always leave some ram for the OS and other processes.一个MPV告诉我的我认为确实有道理，你检查一下SQLSERVER的WORKING SET 有多大。 还有，SQLSERVER的句炳数是不是一直在增加。
兄弟，1。2G内存再大也搁不住一个劲地使用啊！建议控制内存池的大小。真羡慕你，我的64M内存还在跑SQL server 2000呢！仔细查看一下吧
确实有多个线程在不断地同时访问一张表，但它们更新和修改的内容是不一样的，而其它的只是在用户只是在读取这张表的数据或将某些数据删除，在本人看来应该不会发生共享冲突，实在是搞不懂为什么随着时间的增长，性能会下降（下降的蛮快的，过了一个星期就有点受不了了）
不管怎么样都为问题的解决提供了一个参考的方法，先谢谢您了^_^，希望您能继续关注，呵呵
我也知道，可没办法呀（就目前而言），内存不会太小了吧，都1.2G了，而且要强调的是在系统开始运行时速度是很快的，只是在长时间持续运行后性能下降
我查过了命中率大概在93%呢，不算低了
应该不是这个原因，在SQL SERVER 7以上版本，默认的情况下数据库会占用几乎所有的内存，这是因为它的内存池一直在增加，直到整个系统的可用内存只有5MB左右才停止，并只在系统需要内存时才让出内存池中的内存而不管内存池中的内存在最近有没有被使用
1、就假设存在查询优化问题，那也不至于开始很快而到后面就逐渐慢下来吧
2、相关的索引都已建立了（呵呵，这个是我个人认为的^_^）,我会再检查检查
3、对3能说的具体些吗？谢谢了
我同意Yang_(扬帆破浪) 的说法，你没有试一下怎么知道不是这个原因呢？一开始快说明不是索引、查询优化等问题。
对于Yang_(扬帆破浪)的意見我不是作了解释了吗？难道我的解释不成立，这一特性是微软数据库的一大改进呢，当除数据库以外的程序需要内存而系统自身已不能提供时，自动从数据库的内存池中释放部分不用的（里面有一G多呢，其中有好多暂时没用到的）供其它程序使用，因此看起来系统总是不够内存，呵呵。而且其它程序看起来运行得都很正常，使用的内存很稳定（至少看起来是这样的）。
不知道我说的有没有道理，希望大家能够多提意见，搞不懂呀！现在脑子里连问号都没有！！！！
win 2000的内存管理应该还可以，如果我的程序里有跑线程，那么内存出现问题的可能性就非常大了，因为有些程序在非线程里一点问题都没有，但在线程里就不一样了，这样的问题我也遇见过， 内存莫明其妙地变少，呵呵，如果使用了线程就要好好检查检查了，不过一旦出现这样的问题是很难找出来的喔
建议:enterprise manager---right click your sql server--properties--memory---maximum的数值向下调整.
您的建议很好，我本来就打算采用这些方法进行分析原因所在，可是对跟踪方法不太熟，只好先找找资料罗，有什么好方法可以介绍介绍
首先，我这的情况是：
CPU的负载没问题（75%以下）
数据库容量没问题
硬盘容量没问题（85%以内）
高速缓存的命中率没问题（平均93%）
用户连接数据没问题（远没达到最大的255）
我还要进行监控的性能数据还有哪些，关于数据库方面的数据我不太清楚主要要看哪些，它们的数据在什么范围内正常及在什么范围内过载
dbccdb
dbccdb是什么呀！我以前没有专门从事数据库工作的，俺是写程序的，呵呵。还请多多指教！
dbcc checkdb('DBNAME') 命令
为什么不要设虚存呀！不明白
对于性能配置选项你认为要怎么样设置才好呢？我看不出设置有什么问题。应该在设置中注意什么问题？
是你的LOCKS太少了，重启还没多少用户用时当然快啦！你把LOCKS改大再重启服务，搞定了要谢谢我呀，这可是我碰得头破血流得到的经验。
谢谢你的建议，我试试去，如果真如你所说的，那可要好好谢谢你啦！
不会，数据库可是在几天的运行过程中性能缓慢下降
在我这，存贮过程并不多游标的使用就更少了，且都是些定时作业，最频繁的作业也只是十分钟才运行一次，大部分一天只要运行一次，而在其它的程序运行中每秒钟就要对数据库进行大概二十次左右的操作（查、增、改，删等）。都是不间断运行，应该是这些频繁的操作导致的，可就是找不出什么原因
如果是操作系统的问题，那别人是怎么解决的？要真的是这样，恐怕就没人用了！应该有解决的办法的，好多数据量比我这大得多的数据库都运行得很好啊！
加内存绝对不是解决问题的根本办法，虽然能在一定程度下得到改善，目前的内存足够正常使用，只是不知道原因所在to zqllyh(找感觉)
您所说的LOCKS太少，我查了资料发现从SQL SERVER 7以后LOCKS的数量是由数据库动态分配的，从5000到一个非常非常大的数（上亿了吧），所以我认为应该不是这个问题，想听听您的看法与见解
呵呵，我前面说过的啦，读、写、改、删都有， 主要是应用程序对数据库的操作，存贮过程运用较少(用于定时处理主要是写、删操作)。数据表字段较多，一般都有十几个到二十几个（会不会太多了），本人认为该建索引的地方都已建了（几乎所有与条件相关的建了索引）。我这有一个特点就是应用程序几乎二十四小时不停地对数据库进行操作（晚上二点到早上八九点时较闲，也有每秒钟建立数次数据库操作连接),数据量并不大，因为每天都进行了备份，将要进行频繁操作的表记录进行清理。
the max and see if that helps. That will always leave some ram for the OS
and other processes.一个MPV告诉我的我认为确实有道理，你检查一下SQLSERVER的WORKING SET 有多大。
还有，SQLSERVER的句炳数是不是一直在增加。