标签: locking

据我了解，使用 Read Committed Snapshot，读者不会阻止作者，而作者不会阻止读者。唯一可能发生的阻塞是编写器阻塞编写器。默认情况下，我们的数据库设置为 Read Committed Snapshot。但是，我们有很多用户使用 WITH (NOLOCK) 发出查询（出于不良习惯）。如果我理解正确，使用 WITH (NOLOCK) 的查询会更改隔离级别。当在查询中使用它时，读取器现在是否可以阻止尝试更新正在读取的数据的进程？

据我所知，无论使用哪种隔离级别，SQL Server 在事务期间都会持有 X 锁。U锁呢？如果一个事务在 UPDATE 语句中读取了 100 条记录（U 锁）但只更新了 10 条记录，那么在更新完成后，如果 tran 仍然打开，我们会得到 90-U 和 10-X 吗？

回应以下大卫的回答：不，这些情况不相关（感谢您的回答！）。我无法发布代码，因为我手头没有电脑，但我将尝试简要描述这种情况。我有一堆。我更新了，更新了10条记录。问：我们会在 ... 点有任何 U 锁，还是在获得 X 锁后释放它们？谢谢！

Begin tran;

Update t
Set b = 10
Where a = 1;
...

作为处理发票的一部分，我们的第 3 方 ERP 创建、查询，然后在其中一个 ERP 数据库表上删除视图。

我们对此有不同的担忧，但我真的很好奇：CREATE 或 DROP 语句中的任何一个都需要对数据库或视图中涉及的表使用模式修改锁吗？

如果没有，进程中是否还有其他需要我们关注的锁类型？

我有一个包含 3 个模式和大约 1200 个表的 postgres 数据库。当我尝试使用命令仅获取其中的 pg_dump 模式时，pg_dump -h localhost -p 5432 -U postgres -d my_test_db -s有时会出现错误

错误：共享内存不足
提示：您可能需要增加 max_locks_per_transaction

这种情况也是随机发生的，当我重新运行相同的查询时，它运行良好。有什么方法可以克服这个问题

当我sys.sysprocesses在 SQL 2008R2 中签入时，存在许多阻塞会话。其中大部分是插入、更新和删除语句，具有与锁相关的等待类型。

这会导致超时问题吗？谁能确认这是否会导致超时/性能问题？

我想弄清楚PostgreSQL在一段时间内等待锁所花费的时间（在这段时间内，PostgreSQL服务了很多请求）。

我知道的

PostgreSQL 系统表pg_locks显示一些信息。喜欢：

SELECT * FROM 
    pg_locks         pl   LEFT JOIN 
    pg_stat_activity psa
ON pl.pid = psa.pid;

但是我仍然无法弄清楚它在锁上花费了多长时间。

为什么我问这个问题

我发现当我增加 PostgreSQL 的并发性时（例如，增加每个收集的并行工作线程数、最大并行工作线程数或其他一些配置），我的 100 秒多线程 TPC-C-like 工作负载变得更慢（即，更低的吞吐量）。所以我想弄清楚这是否是因为争用过多。

类似的答案

对于 SQL Server：如何在没有分析器的情况下查看查询花费了多长时间等待锁定？

我试图理解为什么 SQL Server (2014) 在死锁场景中放置独占键锁。我已将整个死锁图粘贴在下面。

我很困惑，因为死锁发生在两个 SELECT 语句之间，两者都作为单个 READ COMMITTED 语句运行，而不是在事务内运行（因此同一事务中的其他地方没有发生更新等）。

我相信发生死锁是因为每个进程都在索引上创建一系列键锁，并且由于获取它们的顺序，所以发生了死锁。但是，如果进程仅创建共享锁，则不应出现死锁（根据我的理解）！

所以根本问题是 - 为什么这些 SELECT 语句会获取独占键锁？

我希望这只是我对锁定的误解。任何建议将不胜感激。

    <deadlock>
  <victim-list>
    <victimProcess id="processd7f647848" />
  </victim-list>
  <process-list>
    <process id="processd7f647848" taskpriority="0" logused="25948" waitresource="KEY: 32:72057594051428352 (e2d15ad895e9)" waittime="5014" ownerId="394724294049" transactionname="user_transaction" lasttranstarted="2022-04-06T09:46:18.770" XDES="0x67bf873350" lockMode="S" schedulerid="15" kpid="26196" status="suspended" spid="306" sbid="0" ecid="0" priority="0" trancount="1" lastbatchstarted="2022-04-06T09:46:18.783" lastbatchcompleted="2022-04-06T09:46:18.783" lastattention="1900-01-01T00:00:00.783" clientapp=".Net SqlClient Data Provider" hostname="myhost" hostpid="1500" loginname="myuser" isolationlevel="read committed (2)" xactid="394724294049" currentdb="32" lockTimeout="4294967295" clientoption1="673185824" clientoption2="128056">
      <executionStack>
        <frame procname="MyDatabase.Main.GetMessages" line="154" stmtstart="11934" stmtend="12156" sqlhandle="0x03002000ebd98264d1bfae0066ae000001000000000000000000000000000000000000000000000000000000">
SELECT ID, Message FROM [dbo].[Messages] WHERE MessageType = @Type …

我知道这是一个笼统的问题，但我必须澄清一些基本问题。
我知道当对 SQL Server 数据库表进行写入时，对该表的读取将不得不等待。
我的问题是：我正在使用的 SQL 数据库服务器暴露于多次写入和少量读取。一些 SSRS 报告也在同一台服务器上运行。

1. 适应这种情况的理想或推荐方法是什么？

我知道最好从同一数据库的重复实例执行报告。但是对于一些报表，是否值得设置一个重复的实例进行报表？

有时我会抱怨某些报告运行缓慢。

2. 它可以是写发生时的读等待吗？

DELETE我的生产 SQL 服务器中的查询导致死锁。我知道 DELETE 导致了这种情况，因为我检查了扩展事件并检查了死锁 XML 并发现此 DELETE 正在阻塞，这最终导致死锁。

所以DELETE是发生在两个表格，TB1和TB2。tb1 的主键在 tb2 中可用作外键，并CASCADE DELETE在 tb2 外键中使用。

我什Allow Page Locks至FALSE在 tb1 和 tb2 中创建了聚集索引，但仍然没有运气。

我想READ COMMITTED SNAPSHOT在我的数据库中尝试之前尝试所有其他选项。

任何帮助将不胜感激。

附加信息：

使用READ COMMITTED SNAPSHOT也是一个挑战，因为它涉及风险。

• 我的数据库大小很大（~1.6 TB），RAM 为 128 GB。
• 使用 SQL Server 2016

这是 XDL

<deadlock>
 <victim-list>
  <victimProcess id="process257a65d6ca8" />
 </victim-list>
 <process-list>
  <process id="process257a65d6ca8" taskpriority="0" logused="6024" waitresource="KEY: 6:72057794784329728 (bb7a6e52eae1)" waittime="4485" ownerId="45816472292" transactionname="user_transaction" lasttranstarted="2019-01-08T11:30:06.837" XDES="0x24883ec2a70" lockMode="RangeS-U" schedulerid="26" kpid="39320" status="suspended" spid="217" sbid="2" …

假设连接 1 中的事务尝试修改记录 A，然后提交。因为提交仅将缓冲区中的日志记录刷新到磁盘，检查点的工作是将所有脏页刷新到磁盘 (mdf)。并且有一个连接 B 在连接 1 提交后尝试读取记录 A。（因为 A 已经提交，这里没有锁定的东西）

所以我的问题是：

Q1-如果连接B在检查点之前读取记录A，是否意味着它将读取旧值？

Q2-如果连接B在检查点后读取记录A，是否意味着它将读取新值？

Q3-有时连接 B 获得新值，有时获得旧值，这不是很奇怪，解决这个问题的方法是 A 需要手动触发检查点吗？