标签: locking

正如标题所说，在回滚事务时，我是否对整个数据库具有读/写访问权限？

或者仅对事务未写入的表进行读/写访问？什么是锁定行为？

如果我有读访问权限，当我读取事务回滚写入的表时会发生什么（查询失败还是等待）？

抱歉，我曾尝试在线阅读（ROLLBACK TRANSACTION (Transact-SQL)），但似乎没有触及这种深度。

考虑一个简单的查询，就像一条select语句一样简单：

select * from Teachers where Name like N'%John%'

一旦我开始这个查询，它就完成了。因此，我没有机会看到sp_who2这个查询对数据库对象应用了什么类型的锁。

我可以用事务语句来扩充这个查询：

begin transaction

select * from Teachers where Name like N'%John%'

-- Here, I won't commit transaction, thus holding the lock

但坦率地说，这似乎不是自然锁定检测的正确方法，因为我已经使用事务语句操纵了默认行为。

我们是否有一个工具，比如Display Estimated Execution Plan向我们展示有关锁定给定查询的一些信息？如果不是，我们如何找出给定查询可以在数据库上应用哪种类型的锁，因为它们执行得太快而无法检测到。

据我了解，从 Teradata 中的表中选择时，该表默认处于锁定状态。我想做一个简单的select * from table不锁定表。意思是，我想做一个选择并允许其他用户从同一个表中进行选择，而不必等待我的选择结束。

我知道我可以使用LOCKING修饰符降级选择锁，如下所示：

locking table my_table for access select * from my_table

但这将允许我的操作不等待锁定。据我了解，它仍然会锁定表，因此其他操作将不得不等待锁定。

由于频繁的新记录和更新记录导致索引和存储碎片，我面临性能下降和存储使用量增加的问题。

VACUUM 没有多大帮助。

不幸的是，CLUSTER 不是一个选项，因为它会导致停机并且 pg_repack 不适用于 AWS RDS。

我正在寻找 CLUSTER 的 hacky 替代品。在我的本地测试中似乎可以正常工作的一个是：

begin;

create temp table tmp_target as select * from target;

delete from target;
insert into target select * from tmp_target order by field1 asc, field2 desc;

drop table tmp_target;

commit;

ctid看起来的顺序是正确的：

select ctid, field1, field2 from target order by ctid;

问题是：这看起来好吗？是否会锁定target表以SELECT查找导致应用程序停机的查询？有没有办法列出事务中涉及的锁？

与集群命令锁定只读查询相关的副本

在 MSSQL 中，当使用语句获取锁时，锁定模式由引擎决定，而不是由程序员决定。有没有办法强制引擎使用指定的锁定模式（即行锁定）？

我一直在研究死锁，它是不同的原因。我找到了一个关于这个问题的例子，但我无法完全理解死锁的原因，因为涉及两个不同的表，到目前为止我读到的是只涉及一个表！

首先，我在连接 1 中运行此查询：

Begin Tran

 Update  Purchasing.PurchaseOrderHeader
 Set Freight = Freight * 0.9
 Where PurchaseOrderID = 1255;

我再次在连接 2 中运行此查询：

update Purchasing.PurchaseOrderDetail
Set OrderQty = 4
Where ProductID = 448 and
      PurchaseOrderID = 1255

回到连接 1 我运行这个查询（这会导致死锁）：

Begin Transaction

             Update Purchasing.PurchaseOrderDetail
             Set OrderQty = 2
             where ProductID = 448 and
                   PurchaseOrderID = 1255

可以看到，事务中涉及到两张表，那么到底是什么导致了死锁呢？？提前致谢

死锁图：

<deadlock>
  <victim-list>
    <victimProcess id="process21881f1bc28" />
  </victim-list>
  <process-list>
    <process id="process21881f1bc28" taskpriority="0" logused="0" waitresource="KEY: 7:72057594049003520 (44e4a8141ab4)" waittime="375" ownerId="313642186" transactionname="user_transaction" lasttranstarted="2018-12-09T10:00:39.007" XDES="0x217706d6408" lockMode="RangeS-U" schedulerid="2" kpid="6776" status="suspended" spid="59" sbid="0" ecid="0" priority="0" trancount="2" lastbatchstarted="2018-12-09T10:00:39.013" lastbatchcompleted="2018-12-09T10:00:39.007" lastattention="1900-01-01T00:00:00.007" clientapp=".Net SqlClient Data Provider" hostname="x" hostpid="4724" loginname="x" isolationlevel="read uncommitted (1)" xactid="313642186" currentdb="7" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128056">
      <executionStack>
        <frame procname="adhoc" line="1" stmtstart="44308" stmtend="72024" sqlhandle="0x02000000fb261007e17c6dabc0917779a6823e14abd04fef0000000000000000000000000000000000000000">
unknown    </frame>
        <frame procname="unknown" line="1" sqlhandle="0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000">
unknown    </frame>
      </executionStack>
      <inputbuf>
(@param0 int,@param1 int,@param2 int,@param3 real,@param4 int,@param5 int,@param6 int,@param7 nvarchar(21),@param8 int,@param9 nvarchar(7),@param10 datetime,@param11 datetime,@param12 nvarchar(14),@param13 int,@param14 int,@param15 …

这与调试挂起的会话/锁定有关

每隔一段时间（大约一个月 1-2 次）我们就会锁定我们的数据库，因为有一个查询没有完成，并且请求的锁阻塞了所有其他查询。这是我们业务的核心所在，因此会导致停机。

有问题的查询是几个候选之一，所有这些都只是UPDATE在 1 行上运行的simple s。迄今为止我拥有的最好的线索（我对其他途径持开放态度）来自 RDS 性能见解，我看到虽然所有其他查询都锁定在“元组”上，但总是有 1 个查询锁定在“ClientRead”上。根据我的研究，这似乎是 Postgres 等待客户端库向它发送绑定参数或类似的。所以我的理论是，有一个查询有时会随机地以这种状态结束，这会阻止它之后的所有其他查询。这是一个合理的评价吗？

如果是这种情况，我该如何进行调查和解决？我们使用sequelize 5.9.4(node-js)。我们最近确实升级了它，大约 1-2 个月前，所以我想知道这个版本中是否可能存在一个错误，这可能会在处理查询时导致 sequelize 方面的错误，这可能吗？它也可能是一个错误node-postgres，这在我的搜索https://github.com/brianc/node-postgres/issues/1952 中出现。

下次发生时，我将尝试使用 RDS 性能洞察的屏幕截图进行更新，其保留时间比预期的要短。

我很好奇：假设 SQL Server（或任何其他数据库管理系统）在一个表上接收大量读取流量，因此在任何时间点，至少请求（并且可能授予）一个读取锁。现在假设出现了一个写锁定请求。

写锁是否曾经发出过？还是只要没有授予写锁就总是授予读锁，这样就永远不会授予写锁？锁定请求是否按到达的顺序提供？还是通过更复杂的优先级方案在某个更难确定的时间点发出写锁？

如何使用来自两个不同数据库的锁。当一个会话获取锁时，没有什么可以阻止不同的会话从不同的数据库获取相同的锁。

第一节：

USE db_one;
EXEC @lock_result = sp_getapplock @Resource = 'my_resource',
                                  @LockMode = 'Exclusive',
                                  @LockTimeout = 30000;

第二场：

USE db_two;
EXEC @lock_result = sp_getapplock @Resource = 'my_resource',
                                  @LockMode = 'Exclusive',
                                  @LockTimeout = 30000;

第二个会话立即获取锁，而不是等待锁。现在两个会话似乎同时拥有相同的锁。