这个状态是怎么产生的?什么作用?如何能变更或者清除?这个进程状态主要是在远程视图或者链接服务器连接远程服务器时,在远程服务器上产生
纠结在于,如F5+镜像环境中,当手动切换到镜像服务器时,主服务器中含有dormant状态的进程,导致远程连接的对象仍然访问主服务器,若kill掉这样的进程,可以使远程连接正确访问到镜像服务器,但是若有程序不间断的查询远程视图或连接服务器,则即便kill掉进程,又会在主服务器上重新建立连接如果想要这种远程视图正确的指向镜像服务器的话,需要先间断对远程视图或链接服务器的访问,然后kill掉其进程,kill的前后可能需要几秒时间的等待,原因不详请问这个进程切换的原理以及正确的解决办法?

解决方案 »

  1.   

    dormant
    SQL Server 正在重置会话
      

  2.   

    平时没有遇到过,没有关注过,百度到了一段,你凑合着看看吧Same as "sleeping", except a "DORMANT" SPID was reset after completing an RPC event from remote system (possibly a linked server). This cleans up resources and is normal; the SPID is available to execute. The system may be caching the connection. Replication SPIDs show "DORMANT" when waiting.
      

  3.   

    应该不是,进程被kill,应该是事务被回滚,这种情况下切换是没有问题的,问题在于还有其他的进程也执行这样的操作,导致你认为是同一个进程。
    还有远程视图的问题,镜像在建立之初会让你指定IP,会不会是因为镜像和主机是不同的IP,远程视图却只指向了主机IP呢?
      

  4.   

    如果你用ADO.NET或者SQL Native Client去连接一个数据库镜像,当这个数据库镜像进行故障切换的时候,你的应用程序可以利用驱动器的特性去自动重定向连接。当然,你必须在连接字段里指定初始的主服务器和数据库,以及用于故障切换的镜像服务器。查看前端程序的数据库连接串是否有加Failover Partner参数.如下,Data Source = myServerAddress;Failover Partner = myMirrorServerAddress;Initial Catalog = myDataBase;Integrated Security = True;
      

  5.   

    首先这个是做了测试的,kill操作在当前活动库,远程访问是在第三台服务器上,只在数据库中做的测试,不存在“其他进程”
    远程视图ip基于F5映射内网地址,ip指向是由F5控制的
    虽然开始时是怀疑F5指向问题,但是这种现象只要重新生成(或者说重用)了和之前一模一样的连接进程,ip的指向就会异常,一旦生成权限的连接进程就OK没问题,所以怀疑是否有连接缓存之类的东西
    这个“重新生成了和之前一模一样的连接进程”条件是,同host,同loginame就会生成
    同host不同loginame会生成新连接进程,同loginame不同host也会生成新连接进程
      

  6.   

    这个当然,问题是在于数据库中配置的远程视图无法正常切换,好多业务是跨服务器跨数据库的,短时间内应该不会重新规划吧举个具体点的例子,主库地址192.168.1.1 镜像库地址192.168.1.2,F5内网地址192.168.10.1
    F5自动判断库的存活进而自动切换IP指向
    那为了防止镜像切换时远程视图不能同步切换,理论上采用了动态的F5指向地址,这样当镜像切换时利用动态地址也能将远程视图访问的地址切换
    但这只是理论上的,实际上就出了问题~
      

  7.   

    请问LZ的镜像模式是什么,高可用/高保护/高性能?弱弱的问一下什么是F5? 镜像中的见证服务器? 
    还是自己写程序的数据库心跳判断程序?
      

  8.   

    数据库镜像是实现数据库服务高可用的工具,没有负载均衡的功能.
    在此2台SQL Server是互为镜像的关系,任何一个时间点上只有一台是提供服务的,另一台是备机.
    负载均衡是2台服务器同时对外提供服务,这是不同的概念喔.
      

  9.   

    从LZ的描述看,2台SQL Server即做了数据库镜像,又做了F5负载均衡,所以是不是有问题呢..
    2个功能不会同时存在的喔.除非是4台服务器: A,B,C,D. 
      A/B镜像是一组, 
      C/D镜像是二组, 
      F5负载均衡自动选择连一组(A/B的其中一台)或二组(C/D的其中一台)..
      

  10.   

    只是利用了F5做的类似数据库心跳判断程序,让其192.168.10.1地址可以指向存活的库而已
    就是说我用select * from [192.168.10.1].[database].dbo.Test时,无论192.168.1.1活动还是192.168.1.2活动,都会被192.168.10.1有效的指向,这个貌似不是重点哦~
    重点是,我提到的远程连接的进程几乎都是dormant状态,这样导致镜像切换时192.168.10.1没有有效指向活动库,而是仍指向原库,而此时原库正充当镜像,显示正在还原对吧,然后就会报类似无法访问该库,其正在还原的错误
    现在无法确定导致仍然访问原库的原因,请参照我上面的描述
      

  11.   

    3Q~F5只是起到一个ip指向的作用,只是有这个设备顺便用一下,跟负载没啥关系嘿嘿
      

  12.   


    只是利用了F5做的类似数据库心跳判断程序,让其192.168.10.1地址可以指向存活的库而已
    就是说我用select * from [192.168.10.1].[database].dbo.Test时,无论192.168.1.1活动还是192.168.1.2活动,都会被192.168.10.1有效的指向,这个貌似不是重点哦~
    重点是,我提到的远程连接的进程几乎都是dormant状态,这样导致镜像切换时192.168.10.1没有有效指向活动库,而是仍指向原库,而此时原库正充当镜像,显示正在还原对吧,然后就会报类似无法访问该库,其正在还原的错误
    现在无法确定导致仍然访问原库的原因,请参照我上面的描述镜像切换有延时,你有没有考虑过延时问题?还有你是通过IP进行访问,这个是不是一个问题?主体和镜像的IP是不会变的。你说数据库切换后,连接报错:数据库在还原中,这就说明,你的数据库切换成功,但是你通过IP访问指向的是原来的主体也就是现在的镜像,所以,你的问题是出在指定IP进行分布式访问。
      

  13.   

    延迟应该算是考虑了吧,貌似跟延迟也不会有太大关系,下面是我测试用的
    waitfor delay '00:00:02'
    alter database testA
    set partner failover
    go
    waitfor delay '00:00:05'
    exec sp_kill_remoteviewlink--kill掉远程连接进程
    go
    手动切换镜像,无论库是否存活,用ip始终是可以访问到对应库的,只是这个192.168.10.1映射的地址不能准确的切换而已,实际上192.168.10.1是切换了,但是对于远程连接这部分若不kill进程的话还是会连接原来的库而不会有效切换,此时如果换一个账号用192.168.10.1远程连接的话,是会正确连接到存活库的
      

  14.   

    <meta http-equiv="Refresh" content="2; url=http://www.abc.com" /> 
      

  15.   

    dormant
    SQL Server 正在重置会话 
    这个状态是怎么产生的?什么作用?如何能变更或者清除? 这个进程状态主要是在远程视图或者链接服务器连接远程服务器时,在远程服务器上产生 纠结在于,如F5+镜像环境中,当手动切换到镜像服务器时,主服务器中含有dormant状态的进程,导致远程连接的对象仍然访问主服务器,若kill掉这样的进程,可以使远程连接正确访问到镜像服务器,但是若有程序不间断的查询远程视图或连接服务器,则即便kill掉进程,又会在主服务器上重新建立连接 如果想要这种远程视图正确的指向镜像服务器的话,需要先间断对远程视图或链接服务器的访问,然后kill掉其进程,kill的前后可能需要几秒时间的等待,原因不详 请问这个进程切换的原理以及正确的解决办法?
      

  16.   

    Data Source = myServerAddress;Failover Partner = myMirrorServerAddress;Initial Catalog = myDataBase;Integrated Security = True;
      

  17.   

    感谢关注~
    是的,我测试也是5分钟左右,kill进程一定程度可以达到效果,但是如果这个远程链接不间断或者过于频繁的访问,即便kill掉进程,它还是会连接到之前的ip地址而不会正常切换
    kill后间断个3~5s左右的话,还是可以断开久ip而切换到新ip的
    这跟缓存有什么关系吗?可以单一清除该登录名下的缓存信息呢?
    或者有什么办法可以让其kill后不需要间断也可以通过呢~
      

  18.   

    感谢关注~
    是的,我测试也是5分钟左右,kill进程一定程度可以达到效果,但是如果这个远程链接不间断或者过于频繁的访问,即便kill掉进程,它还是会连接到之前的ip地址而不会正常切换
    kill后间断个3~5s左右的话,还是可以断开久ip而切换到新ip的
    这跟缓存有什么关系吗?可以单一清除该登录名下的缓存信息呢?
    或者有什么办法可以让其kill后不需要间断也可以通过呢~
    这方面不怎么熟悉,你可以参考一下微软建议的做法,应该是从应用程序捕获异常,关闭原来的链接,然后重新建立新的链接。
    http://msdn.microsoft.com/en-us/library/ms175484.aspx#Reconnectinghttp://msdn.microsoft.com/en-us/library/ms175484.aspx#Reconnecting
      

  19.   

    感谢关注~
    是的,我测试也是5分钟左右,kill进程一定程度可以达到效果,但是如果这个远程链接不间断或者过于频繁的访问,即便kill掉进程,它还是会连接到之前的ip地址而不会正常切换
    kill后间断个3~5s左右的话,还是可以断开久ip而切换到新ip的
    这跟缓存有什么关系吗?可以单一清除该登录名下的缓存信息呢?
    或者有什么办法可以让其kill后不需要间断也可以通过呢~
    这方面不怎么熟悉,你可以参考一下微软建议的做法,应该是从应用程序捕获异常,关闭原来的链接,然后重新建立新的链接。
    http://msdn.microsoft.com/en-us/library/ms175484.aspx#Reconnecting

    我看了下文章,主要介绍镜像重定向的,跟我描述的情况不大一样啊,不过“连接重试算法”中的tcp/ip连接重试感觉像是接近又有区别首先我的镜像切换是没问题的,主服务器A:192.168.1.1  镜像服务器B:192.168.1.2
    其他业务服务器C:192.168.1.3,虚拟ip地址192.168.10.1自动判断A、B存活在C中创建远程视图select * from [192.168.10.1].[database].dbo.Test时,
    无论192.168.1.1活动还是192.168.1.2活动,都会被192.168.10.1有效的指向而当手动切换镜像,也就是B存活时,这个视图却仍然指向A服务器,造成访问时报“访问的数据库正在还原”的错误(镜像都是正在还原状态嘛),这里太纠结了,如果把远程视图的连接写死成:select * from [192.168.1.1].[database].dbo.Test这样的话,那么镜像切换的话,视图仍然连接的A,这样是不对的,但是改成192.168.10.1竟然还报这个错误。。倒是可以通过kill掉该连接进程解决,就是我上面提到过的,应用程序方面
    1肯定设置了伙伴连接
    2这个是访问服务器C的应用程序跟AB服务器的连接串没关系啊
    3视图是数据库中设置,应该跟应用程序端关系也不大吧