SQL大数据量统计，远程无响应，在线等，急

[一只眼足矣看码]

服务器是通过3389端口远程连接，平时都没有什么问题，但是通过SQL处理亿级的统计数据时，大概十天半个月就出现一次无法远程连接，能ping通服务器，但是不能通过3389端口远程连接了，并且也不能通过程序访问数据库。重启以后又可以正常使用。
如果说是程序问题，在统计的时候就应该无响应，为什么统计每天都在执行，突然有一天不能用呢？
追究运营方的责任，他们给的答复是：服务器在未部署 SQL统计时无任何问题，发生这个原因是负载过高造成。

服务器是：24核CPU+26G内存

我是程序员，不是运营人员，现在也无任何解决办法。哎，希望哪位大神能解救我

[一只眼足矣看码]

引用 8 楼 luckyrandom 的回复:

你既然是程序员，那这责任也不应该在你身上呀 ××并非说事不关己，高高挂起。而是一个较大的应用，应该职责分明，别把自己当全能，当然老板(上司)倒是希望你全能，并负全责

开始说了，这是一个扯皮的事情，即使不是程序的原因，也要查明原因找到直接人

[七神之光]

重启

[唐诗三百首]

建议查看服务器的SQL日志,有详细的错误信息.

[Mr_Nice]

能ping通服务器，但是不能通过3389端口远程连接了，并且也不能通过程序访问数据库 这个明显是连接上的事情，跟数据量没啥关系。 重启能解决问题，建议监控看看tempdb 的相关变化。

[叶子]

只能看看错误日志了，看看是不是什么的负载到上限了。

[一只眼足矣看码]

引用 4 楼 maco_wang 的回复:

只能看看错误日志了，看看是不是什么的负载到上限了。

我看了SQL日志，与windows日志，都很正常

[一只眼足矣看码]

引用 3 楼 OrchidCat 的回复:

能ping通服务器，但是不能通过3389端口远程连接了，并且也不能通过程序访问数据库 这个明显是连接上的事情，跟数据量没啥关系。 重启能解决问题，建议监控看看tempdb 的相关变化。

可否说的详细点，怎么监控 tempdb 。感谢

[haitao]

估计是统计时把sql进程搞死活搞飞了

[Q315054403]

你既然是程序员，那这责任也不应该在你身上呀 ××并非说事不关己，高高挂起。而是一个较大的应用，应该职责分明，别把自己当全能，当然老板(上司)倒是希望你全能，并负全责

[Mr_Nice]

引用 6 楼 xiangjing163 的回复:

引用 3 楼 OrchidCat 的回复:能ping通服务器，但是不能通过3389端口远程连接了，并且也不能通过程序访问数据库 这个明显是连接上的事情，跟数据量没啥关系。 重启能解决问题，建议监控看看tempdb 的相关变化。 可否说的详细点，怎么监控 tempdb 。感谢

1、tempdb创建在单独的数据文件上 2、DMV sys.dm_db_file_space_usage 查看空间使用情况，及增长情况

[弘恩]

前两天写了一个普通的语句,也没有用到临时表; 结果,TEMPDB增长了60G. 可能真的和TEMPDB有关的.

[铁歌]

贴出SQL错误日志和WINDOWS日志看看，估计CPU被占满 处理不过来有些关系。。

[最爱午夜]

大数据统计时，会加重CPU，内存，以及io负载，当负载达到一定程度，比如：io请求队列高过200时，请求基本不响应了，就跟宕机了一样，但是机房却觉察不到任何情况，这个我以前遇到过，你看看是不是优化一下统计语句。

[KevinLiu]

看一下数据库的错误日志和WINDOWS日志，这种情况有可能是由于负载导致的，比如CPU100%无法处理SQL请求等等。

[KevinLiu]

另外出问题时你可以远程连接到数据库看吗？看看当时的负载情况。

[Barton]

这个在你大数据量处理的时候你要限制并发，最好加上maxdop 因为如果SQL很复杂，数据库会采用并发执行，因为一台服务器的thread数量默认是有限制的，如果此时thread数量正好全部用完，SQLServer是不能处理新的连接的。 建议检查sql的日志，查看有没有17883，17884类似的错误日志。