none
应用报数据库登录失败或超时 RRS feed

  • 问题

  • 近日,公司ERP应用不时会出现超时会数据库登录失败问题,影响用户体验ERP应用。初步检查服务器性能并未发现什么问题,服务器Ping是没有超时发现。错误如下:

    SQL Server日志:SQLServer 错误:  4060,无法打开登录所请求的数据库 "DBNAME"。登录失败

    ERP应用报错:The timeout period elapsed prior to completion of the operation or the server is not responding. 或账号**登录失败。

     

    应用配置和不配置连接池都会出现类似情况。不知有没人遇到类似问题,有没一套完整的排查措施。谢谢

    2011年8月9日 10:07

全部回复

  • SqlCommand.CommandTimeout
    获取或设置在终止执行命令的尝试并生成错误之前的等待时间。
    等待命令执行的时间(以秒为单位)。默认为 30 秒。

    SqlConnection.ConnectionTimeout
    获取在尝试建立连接时终止尝试并生成错误之前所等待的时间。
    等待连接打开的时间(以秒为单位)。默认值为 15 秒。

    估计是设置的问题,详见:

    http://blog.joycode.com/ghj/archives/2004/06/15/24612.joy

    2011年8月9日 10:49
    版主
  • 这个已经确认没有问题,SqlCommand.CommandTimeout为60S,SqlConnection.ConnectionTimeout
    为30S
    • 已建议为答案 Winds Gao 2011年8月16日 5:06
    • 取消建议作为答案 Winds Gao 2011年8月16日 8:02
    2011年8月9日 11:00
  • 你确认这两个错误是联系在一起的?

    SQL Server日志:SQLServer 错误:  4060,无法打开登录所请求的数据库 "DBNAME"。登录失败

    ERP应用报错:The timeout period elapsed prior to completion of the operation or the server is not responding. 或账号**登录失败。

     

    第一个是你的登录失败,

    第二个是操作超时

     

    如果是前者,请看看你的ERP用的登录用户的default database 设置的是什么?这个对应的“DBNAME”的数据库是否在错误时刻可用?


    If you think my suggestion is useful, please rate it as helpful.
    If it has helped you to resolve the problem, please Mark it as Answer.
    http://twitter.com/7Kn1ghts

    2011年8月9日 11:10
  • Those two errors sound related, ensure user's default db is online as said above.
    2011年8月9日 13:17
  • 默认账号原来是master,昨天下午我改成了主库。数据库是Online的。登录异常或超时可能集中在某一分钟,很短暂
    2011年8月10日 1:22
  • Did login fail after you changing default db? Did user have proper permission in default db at that time? Any other error in sql server log around that time?
    2011年8月10日 2:20
  • 之前之后均有出现,昨晚在重新启用连接池后,情况稍有好转,但服务平台依然不时会报有服务超时错误。数据库账号不存在任何问题,均有所需库的DB_OWNER权限。
    2011年8月10日 7:52
  • What's max number of connections in the pool? How many connections used? User may unable to get connection if reached limit, has to wait for free connection thus cause app timeout. 

    2011年8月10日 14:41
  • 数据库最大连接数的设置问题?

    2011年8月12日 5:13
  • 有2台APPServer,每台最大连接数设置上限300,现在数据库总连接数300-600不等,单个服务器连接数未发现突破300.这种问题时不时出现一下,过几分钟又好了,寻求帮助

    2011年8月12日 9:45
  • 默认设置,没更改过数据库设置,近期才出现这个问题
    2011年8月12日 9:46
  • If you have sql2k5 or up, can use following query to find out if user reaches sql when get time out. If never reach sql server, should check networking:

    SELECT

    dateadd(SS,-14400,xml_data.value('(/Record/ConnectivityTraceRecord/RecordTime)[1]', 'datetime')) AS 'TimeStampOfEvent',

    xml_data.value('(/Record/ConnectivityTraceRecord/RecordType)[1]', 'varchar(30)') AS 'RecordType',

    xml_data as RingBufferRecord

    FROM

    ( SELECT CAST(record AS XML) as xml_data  FROM sys.dm_os_ring_buffers

    WHERE ring_buffer_type = 'RING_BUFFER_CONNECTIVITY' ) as XEventData

    order by TimeStampOfEvent Desc

    2011年8月12日 13:08
  • Ring Buffer Connectivity 2008 才有的

     

    楼主跑一个profiler把,把每个连接login都看看,我怀疑你的error可能和sp_reset_connection 有关系


    If you think my suggestion is useful, please rate it as helpful.
    If it has helped you to resolve the problem, please Mark it as Answer.
    http://twitter.com/7Kn1ghts

    2011年8月12日 15:48
  • Ring Buffer Connectivity 2008 才有的

     

    楼主跑一个profiler把,把每个连接login都看看,我怀疑你的error可能和sp_reset_connection 有关系


    If you think my suggestion is useful, please rate it as helpful.
    If it has helped you to resolve the problem, please Mark it as Answer.
    http://twitter.com/7Kn1ghts


    具体怎么说
    2011年8月15日 3:15
  • Set network monitor between sql server and client machine, it'll tell what's going on. 
    2011年8月15日 3:42
  • 我提供一个解决方案:

    1. 在server 上加profiler, 跟踪一下操作,看用户是否已经登陆, 如果登陆执行的是什么操作导致的超时.

    2.把超时sql 抓出来,看看为什么超时.

    3.如果还有问题再过来发帖.

    2011年8月15日 7:41
  • What if logon time out? Profiler has no way to catch that.
    2011年8月15日 13:27
  • also, logon time out is another situation we should think about it independent.

    maybe:

    1. network is busy.

    2. server is busy.

    3. database connection is full.

    4. user access permmission.

    .....

    2011年8月16日 0:48
  • 我提供一个解决方案:

    1. 在server 上加profiler, 跟踪一下操作,看用户是否已经登陆, 如果登陆执行的是什么操作导致的超时.

    2.把超时sql 抓出来,看看为什么超时.

    3.如果还有问题再过来发帖.


    这里登陆超时,从程序日志反映的是无法创建连接,还没连接到数据库,也就无语句可言
    2011年8月16日 3:03
  • That's why need network monitor as I said above.
    2011年8月16日 3:06
  • Set network monitor between sql server and client machine, it'll tell what's going on. 


    connect reset/s  平均83 最大400

    Network IO wait  平均等待时间3ms,最大320ms

    处理器队列  平均0.38 最大41

    用户连接数  平均300 最大500

    这些参数应该没什么异常吧

    2011年8月16日 3:07
  • You should look for any error or packet dropping in network monitor.
    2011年8月16日 3:11
  • 我再提一个方案:

    1. 把客户端到服务器的那个request 在客户端跟踪出来,然后单独执行.

    2. 在客户端和服务器之间跟踪这个process, 看这个process 都做了什么,在什么地方出的问题.

    根据具体情况再做分析.

     

    2011年8月16日 3:33
  • How? Profiler on client?
    2011年8月16日 3:43
  • Any way if possible.
    2011年8月16日 3:44
  • Did you do your homework?
    2011年8月16日 3:47
  • 我觉得有程序在手里,要说跟踪出来几个操作应该说没啥问题.

    虽然说不能去客户现场,但是我们从代码的角度 完全可以获得相应的内容.

    如果是程序开发人员 这种事情因该没啥问题.

    项目上线之后为客户解决 几个问题 我想大家都有经验吧?

    2011年8月16日 5:10
  • 我觉得有程序在手里,要说跟踪出来几个操作应该说没啥问题.

    虽然说不能去客户现场,但是我们从代码的角度 完全可以获得相应的内容.

    如果是程序开发人员 这种事情因该没啥问题.

    项目上线之后为客户解决 几个问题 我想大家都有经验吧?

    我们现在的问题不是说某个操作超时,而是在某个时刻,所有ERP应用都会失去连接,(当时忘了看管理工具是否可以连接),过几分钟后又恢复正常了。

    虽然说程序设计问题可能是一个点,但没办法确认哪个点出问题,程序?网络?服务器?还是数据库。

    2011年8月16日 5:43
  • 我觉得问题应该还是出在服务器, 应该在服务器上设置监控器,把那个时间点的负载框定下来, 然后用loadrunner 等工具压一下,

    按照当时的负载进行模拟,然后再用debug 工具跟踪下.

    2011年8月16日 6:37
  • 我觉得问题应该还是出在服务器, 应该在服务器上设置监控器,把那个时间点的负载框定下来, 然后用loadrunner 等工具压一下,

    按照当时的负载进行模拟,然后再用debug 工具跟踪下.


    这个是生产数据库服务器,不能压啊,7*24应用,不好测。。。
    2011年8月16日 10:30
  • 有一种方式可以考虑, 就是搭建一个测试服务器, 根据生产环节进行比例配置.

    然后在测试服务器上查看.

    2011年8月17日 1:10
  • http://www.sqlskills.com/BLOGS/PAUL/post/Do-yourself-a-favor-Trust-No-One.aspx

    最新情况,半个月没出问题,昨天故障重现,跟踪到大量CXPACKET  和LATCH_EX 等待类型,等待资源ACCESS_METHODS_DATASET_PARENT (00000004E78523C8)这类的并行阻塞。在故障时段有时甚至在本地都无法新建数据库连接,但原有的连接能够继续执行SQL。感觉数据库资源已无法承载新的连接,连接数飚导900多。

    事后分析性能监视器报告,发现Network IO Waits比故障前高出很多,处理器等待队列和事务失败数已超出平常。但暂时没确定事件源头,不知各位有没类似经验,指点一下,谢谢。
    对于如何去解决这种并发问题,有没兄弟可以给出一些建议。

    2011年8月26日 3:35
  • How many processors does the server have? What's maxdop setting in sql? Too many parallel processes may use up all workers in sql, that prevents sql to accept new connections.
    2011年8月26日 3:45
  • How many processors does the server have? What's maxdop setting in sql? Too many parallel processes may use up all workers in sql, that prevents sql to accept new connections.

    48 processors ,maxdop 默认设置,无限制。这里补充下,刚仔细查看日志,发现故障时段本地登陆不上时,系统日志记录的是密码不正确,但当时密码应该是正确的。
    2011年8月26日 3:53
  • Are they NUMA processors? If so, set maxdop to n-1 (n is number of processors in each NUMA). If not, try set maxdop to 7.
    2011年8月26日 4:04
  • Are they NUMA processors? If so, set maxdop to n-1 (n is number of processors in each NUMA). If not, try set maxdop to 7.

    4个NUMA,每个12个处理器,那设置为11?请问这个依据是?有没风险,谢谢。
    2011年8月26日 4:39
  • 跟numa什么的没关系,别看那个cxpacket。关键还是latch_ex,应该是某些页过热。

    要是有2008的xe就方便了,定期看看sys.dm_exec_query_stats,和上一次sys.dm_exec_query_stats里的数据比较一下,看哪些sql执行频率高,占用资源多。


    想不想时已是想,不如不想都不想。
    2011年8月26日 5:13
    版主
  • 头痛医头不好使,最好还是监测整体系统状况。
    想不想时已是想,不如不想都不想。
    2011年8月26日 5:15
    版主
  • 跟numa什么的没关系,别看那个cxpacket。关键还是latch_ex,应该是某些页过热。

    要是有2008的xe就方便了,定期看看sys.dm_exec_query_stats,和上一次sys.dm_exec_query_stats里的数据比较一下,看哪些sql执行频率高,占用资源多。


    想不想时已是想,不如不想都不想。

    XE是指?能否详细介绍下怎么定位到过热的页,谢谢
    2011年8月26日 5:19
  • Are they NUMA processors? If so, set maxdop to n-1 (n is number of processors in each NUMA). If not, try set maxdop to 7.

    4个NUMA,每个12个处理器,那设置为11?请问这个依据是?有没风险,谢谢。

    http://support.microsoft.com/kb/329204
    2011年8月26日 20:21