SQL Azure - 一个会话锁定整个数据库以进行更新和插入

Sam*_*les 10 sql sql-server azure-sql-database

SQL Azure问题.

我的问题在我们的(asp.net)网站上显示为以下异常:

超时已过期.操作完成之前经过的超时时间或服务器没有响应.该语句已终止.

它还导致更新和插入语句永远不会在SMSS中完成.查询时不存在任何X或IX锁:sys.dm_tran_locks查询时没有事务sys.dm_tran_active_transactionssys.dm_tran_database_transactions.

问题出现在数据库中的每个表中,但同一实例上的其他数据库不会导致问题.问题的持续时间可以是2分钟到2小时,并且不会在一天中的任何特定时间发生.

数据库未满.

有一次这个问题没有自行解决,但我能够通过查询sys.dm_exec_connections找到运行时间最长的会话,然后杀死它来解决问题.奇怪的是,连接是15分钟,但锁定问题已经存在超过3个小时.

还有什么我可以检查的吗?

编辑

按照保罗的回答如下.在他回答之前,我实际上已经找到了问题.我会在下面发布我用来解决这个问题的步骤,以防他们帮助其他人.

当存在"超时期限"时,运行以下查询.

select *  from sys.dm_exec_requests
Run Code Online (Sandbox Code Playgroud)

请求统计

我们可以看到,所有WAIT请求都在等待会话1021,即复制请求!该TM Request指示DTC事务,我们不使用分布式事务.您还可以看到wait_type SE_REPL_COMMIT_ACK再次暗示复制.

select * from  sys.dm_tran_locks
Run Code Online (Sandbox Code Playgroud)

在此输入图像描述

再次等待1021会话

SELECT * FROM sys.dm_db_wait_stats ORDER BY wait_time_ms desc
Run Code Online (Sandbox Code Playgroud)

在此输入图像描述

是的,SE_REPL_CATCHUP_THROTTLE总等待时间为8094034毫秒,即134.9分钟!

有关此问题的详细信息,请参阅以下论坛. http://social.technet.microsoft.com/Forums/en-US/ssdsgetstarted/thread/c3003a28-8beb-4860-85b2-03cf6d0312a8

我在与微软的沟通中得到了以下答案(我们已经在欧盟数据中心的15个数据库中看到了这个问题):

问题:在过去三周内,即自我的问题开始以来,这些软限制限制是否有变化?

答:不,没有.

问题:我们有什么方法可以阻止或警告我们接近极限?

答:不会.问题可能不是由您的应用程序引起的,但可能是由依赖相同物理硬件的其他租户引起的.换句话说,您的应用程序可以承受很小的负载并仍然遇到问题.换句话说,您自己的流量可能是导致此问题的原因,但也可能是由依赖于相同物理硬件的其他租户造成的.事先没有办法知道这个问题很快就会发生 - 它可以在没有任何警告的情况下随时发生.SQL Azure操作团队不会监视此类错误,因此他们不会自动尝试为您解决问题.因此,如果你碰到它,你有两个选择:

  1. 创建数据库的副本并使用它,并希望将数据库放置在负载较小的另一台服务器上.

  2. 联系Windows Azure支持并告知有关问题的信息,并让他们为您执行选项1

Pau*_* DB 9

您可能遇到了SE_REPL*问题,这些问题目前正在困扰很多使用Sql Azure的人(包括我的公司).

当您遇到超时时,请尝试检查等待类型的等待请求:

  • SE_REPL_SLOW_SECONDARY_THROTTLE
  • SE_REPL_COMMIT_ACK

运行以下命令检查当前连接上的等待类型:

SELECT TOP 10 r.session_id, r.plan_handle,
r.sql_handle, r.request_id,
r.start_time, r.status,
r.command, r.database_id,
r.user_id, r.wait_type,
r.wait_time, r.last_wait_type,
r.wait_resource, r.total_elapsed_time,
r.cpu_time, r.transaction_isolation_level,
r.row_count
FROM sys.dm_exec_requests r
Run Code Online (Sandbox Code Playgroud)

您还可以通过运行以下方法检查此类的历史记录:

SELECT * FROM sys.dm_db_wait_stats
ORDER BY wait_time_ms desc
Run Code Online (Sandbox Code Playgroud)

如果您看到很多SE_REPL*等待类型并且这些类型在您的连接上保持设置任何时间长度,那么基本上您已经搞砸了.微软已经意识到了这个问题,但是我现在已经有了一个星期的支持票,他们现在仍在努力工作.

当Sql Azure复制从属落后时,SE_REPL*等待.基本上整个db在复制赶上时挂起查询:/

因此,实质上使Sql Azure高度可用的方面导致数据库变得随机不可用.如果没有杀死我们,我会嘲笑讽刺.

有关详细信息,请查看此主题:http: //social.technet.microsoft.com/Forums/en-US/ssdsgetstarted/thread/c3003a28-8beb-4860-85b2-03cf6d0312a8