sql2000中,打开企业管理器->管理->当前活动->进程信息。
看到好多状态为sleeping,命令为AWAITING COMMAND的进程,请问这些进程占用数据库的连接吗?

解决方案 »

  1.   

    这些是数据库系统服务进程 占有相应的资源(内存/文件句柄/CPU Qom等)大致类似CHECKPOINT LGWR DBWR PMON SMON
      

  2.   

    那如果程序调用数据库时报数据库连接池超时和这些有关吗? 
    -----------------------
    java前端好像容易报这样的错误 这样的错误应该首先从程序上去找原因
      

  3.   

    to rouqu ,这些进程绝大部分是状态为sleeping,命令为AWAITING COMMAND,而且其中有很多都不是数据库系统服务进程,是其他应用程序的,这样会否对程序与数据库的链接产生影响?另外,是否每个连接都有一个相关进程?
      

  4.   

    而且其中有很多都不是数据库系统服务进程
    -----------------
    不会吧 这些都是SQL Server内部进程 你都可以看到每个进程所针对的数据库对象 sleeping表示该进程处暂时休眠状态 awaiting command表示该进程当前未有命令可执行 正等待(命令输入)这样会否对程序与数据库的链接产生影响?
    -----------------
    两者没有什么联系吧是否每个连接都有一个相关进程?
    -----------------
    SQL服务起来之后 会有connection context内存区域 有相应的进程来维护 但不可能一连接一进程
      

  5.   

    SQL Server 2000 is very efficient in the way it stores the context and state information for each connection, typically using less than 24 KB for each connection.
    ----------------------
    每个连接少于24KB SQL理论最大接受32,767并发连接 
      

  6.   

    2000中有命令能查看data buffer内存区域的使用情况吗?索引分布?聚集索引页碎片情况...
      

  7.   

    看到好多状态为sleeping,命令为AWAITING   COMMAND的进程,请问这些进程占用数据库的连接吗? 
    -----------------------------------------
    这些大多数是系统进程,不算是数据库的连接。那如果程序调用数据库时报数据库连接池超时和这些有关吗?   
    -----------------------------------------
    多半没有关系。这通常是应用程序或者连接数据库的驱动程序(包括配置)方面的问题。关于连接池:
    连接池其实属于数据库系统外面,因为建立数据库连接很耗费资源,并且数据库连接是有限的,
    所以才出现了连接池的概念,以实现有效利用现有连接的目的。
    MSSQL内部并没有维护一个专门的连接池。
    连接池是在框架或者应用服务器里面的,比如.NET框架里面,或者WEBLOGIC服务器里面。
      

  8.   

    恩 也有必要说明一下 SQL所占据内存POOL中的connection context并不是连接池(connection pool)