SQL Server数据库表锁定原理以及如何解除锁定

12 事务的ACID原则13 锁是关系数据库很重要的一部分, 数据库必须有锁的机制来确保数据的完整和一致性 131 SQL Server中可以锁定的资源:132 锁的粒度:133 锁的升级: 锁的升级门限以及锁升级是由系统自动来确定的，不需要用户设置 134 锁的类型: (1) 共享锁: 共享锁用于所有的只读数据 *** 作 (2) 修改锁: 修改锁在修改 *** 作的初始化阶段用来锁定可能要被修改的资源，这样可以避免使用共享锁造成的死锁现象 (3) 独占锁: 独占锁是为修改数据而保留的。它所锁定的资源，其他事务不能读取也不能修改。独占锁不能和其他锁兼容。 (4) 架构锁 结构锁分为结构修改锁(Sch-M)和结构稳定锁(Sch-S)。执行表定义语言 *** 作时，SQL Server采用Sch-M锁，编译查询时，SQL Server采用Sch-S锁。 (5) 意向锁 意向锁说明SQL Server有在资源的低层获得共享锁或独占锁的意向。 (6) 批量修改锁 批量复制数据时使用批量修改锁 134 SQL Server锁类型 (1) HOLDLOCK: 在该表上保持共享锁，直到整个事务结束，而不是在语句执行完立即释放所添加的锁。 (2) NOLOCK：不添加共享锁和排它锁，当这个选项生效后，可能读到未提交读的数据或“脏数据”，这个选项仅仅应用于SELECT语句。 (3) PAGLOCK：指定添加页锁(否则通常可能添加表锁)。 (4) READCOMMITTED用与运行在提交读隔离级别的事务相同的锁语义执行扫描。默认情况下，SQL Server 2000 在此隔离级别上 *** 作。 (5) READPAST: 跳过已经加锁的数据行，这个选项将使事务读取数据时跳过那些已经被其他事务锁定的数据行，而不是阻塞直到其他事务释放锁， READPAST仅仅应用于READ COMMITTED隔离性级别下事务 *** 作中的SELECT语句 *** 作。 (6) READUNCOMMITTED：等同于NOLOCK。 (7) REPEATABLEREAD：设置事务为可重复读隔离性级别。 (8) ROWLOCK：使用行级锁，而不使用粒度更粗的页级锁和表级锁。

此文章主要是对Oracle数据库锁机制的详细研究 首先我们要介绍的是Oracle数据库锁的类型 同时也阐述 在实际应用中我们经常会遇到的与锁相关的异常情况 特别对经常遇到的由于等待锁而使事务被挂起的问题进行了定位及解决 并对死锁这一比较严重的现象 提出了相应的解决方法和具体的分析过程

数据库是一个多用户使用的共享资源 当多个用户并发地存取数据时 在数据库中就会产生多个事务同时存取同一数据的情况 若对并发 *** 作不加控制就可能会读取和存储不正确的数据 破坏数据库的一致性

加锁是实现数据库并发控制的一个非常重要的技术 当事务在对某个数据对象进行 *** 作前 先向系统发出请求 对其加锁 加锁后事务就对该数据对象有了一定的控制 在该事务释放锁之前 其他的事务不能对此数据对象进行更新 *** 作

在数据库中有两种基本的锁类型 排它锁（Exclusive Locks 即X锁）和共享锁（Share Locks 即S锁） 当数据对象被加上排它锁时 其他的事务不能对它读取和修改 加了共享锁的数据对象可以被其他事务读取 但不能修改 数据库利用这两种基本的锁类型来对Oracle数据库的事务进行并发控制

在实际应用中经常会遇到的与锁相关的异常情况 如由于等待锁事务被挂起 死锁等现象 如果不能及时地解决 将严重影响应用的正常执行 而目前对于该类问题的解决缺乏系统化研究和指导 本文在总结实际经验的基础上 提出了相应的解决方法和具体的分析过程

Oracle数据库的锁类型

根据保护的对象不同 Oracle数据库锁可以分为以下几大类 DML锁（data locks 数据锁） 用于保护数据的完整性 DDL锁（dictionary locks 字典锁） 用于保护数据库对象的结构 如表 索引等的结构定义 内部锁和闩（internal locks and latches） 保护数据库的内部结构

DML锁的目的在于保证并 况下的数据完整性 本文主要讨论DML锁 在Oracle数据库中 DML锁主要包括TM锁和TX锁 其中TM锁称为表级锁 TX锁称为事务锁或行级锁

当Oracle执行DML语句时 系统自动在所要 *** 作的表上申请TM类型的锁 当TM锁获得后 系统再自动申请TX类型的锁 并将实际锁定的数据行的锁标志位进行置位 这样在事务加锁前检查TX锁相容性时就不用再逐行检查锁标志 而只需检查TM锁模式的相容性即可 大大提高了系统的效率

TM锁包括了SS SX S X等多种模式 在Oracle数据库中用 － 来表示 不同的SQL *** 作产生不同类型的TM锁 如表 所示

在数据行上只有X锁（排他锁） 在 Oracle数据库中 当一个事务首次发起一个DML语句时就获得一个TX锁 该锁保持到事务被提交或回滚 当两个或多个会话在表的同一条记录上执行DML语句时 第一个会话在该条记录上加锁 其他的会话处于等待状态 当第一个会话提交后 TX锁被释放 其他会话才可以加锁

当Oracle数据库发生TX锁等待时 如果不及时处理常常会引起Oracle数据库挂起 或导致死锁的发生 产生ORA 的错误 这些现象都会对实际应用产生极大的危害 如长时间未响应 大量事务失败等

TX锁等待的分析

在介绍了有关地Oracle数据库锁的种类后 下面讨论如何有效地监控和解决锁等待现象 及在产生死锁时如何定位死锁的原因

监控锁的相关视图 数据字典是Oracle数据库的重要组成部分 用户可以通过查询数据字典视图来获得数据库的信息 和锁相关的数据字典视图如表 所示

TX锁等待的监控和解决在日常工作中 如果发现在执行某条SQL时数据库长时间没有响应 很可能是产生了TX锁等待的现象 为解决这个问题 首先应该找出持锁的事务 然后再进行相关的处理 如提交事务或强行中断事务

死锁的监控和解决在数据库中 当两个或多个会话请求同一个资源时会产生死锁的现象 死锁的常见类型是行级锁死锁和页级锁死锁 Oracle数据库中一般使用行级锁 下面主要讨论行级锁的死锁现象

当Oracle检测到死锁产生时 中断并回滚死锁相关语句的执行 报ORA 的错误并记录在Oracle数据库的日志文件alertSID log中 同时在user_dump_dest下产生了一个跟踪文件 详细描述死锁的相关信息

在日常工作中 如果发现在日志文件中记录了ora 的错误信息 则表明产生了死锁 这时需要找到对应的跟踪文件 根据跟踪文件的信息定位产生的原因

如果查询结果表明 死锁是由于bitmap索引引起的 将IND_T_PRODUCT_HIS_STATE索引改为normal索引后 即可解决死锁的问题

表 Oracle的TM锁类型

锁模式 锁描述 解释 SQL *** 作

none

NULL 空 Select

SS(Row S) 行级共享锁 其他对象只能查询这些数据行 Select for update Lock for update Lock row share

SX(Row X) 行级排它锁 在提交前不允许做DML *** 作 Insert Update Delete Lock row share

S(Share) 共享锁 Create index Lock share

SSX(S/Row X) 共享行级排它锁 Lock share row exclusive

lishixinzhi/Article/program/Oracle/201311/18509

分布式系统架构中，分布式事务问题是一个绕不过去的挑战。而微服务架构的流行，让分布式事问题日益突出！

下面我们以电商购物支付流程中，在各大参与者系统中可能会遇到分布式事务问题的场景进行详细的分析！

如上图所示，假设三大参与平台（电商平台、支付平台、银行）的系统都做了分布式系统架构拆分，按上数中的流程步骤进行分析：

1、电商平台中创建订单：预留库存、预扣减积分、锁定优惠券，此时电商平台内各服务间会有分布式事务问题，因为此时已经要跨多个内部服务修改数据；

2、支付平台中创建支付订单（选yhk支付）：查询账户、查询限制规则，符合条件的就创建支付订单并跳转银行，此时不会有分布式事务问题，因为还不会跨服务改数据；

3、银行平台中创建交易订单：查找账户、创建交易记录、判断账户余额并扣款、增加积分、通知支付平台，此时也会有分布式事务问题（如果是服务化架构的话）；

4、支付平台收到银行扣款结果：更改订单状态、给账户加款、给积分帐户增加积分、生成会计分录、通知电商平台等，此时也会有分布式事务问题；

5、电商平台收到支付平台的支付结果：更改订单状态、扣减库存、扣减积分、使用优惠券、增加消费积分等，系统内部各服务间调用也会遇到分布式事问题；

如上图，支付平台收到银行扣款结果后的内部处理流程：

1、支付平台的支付网关对银行通知结果进行校验，然后调用支付订单服务执行支付订单处理；

2、支付订单服务根据银行扣款结果更改支付订单状态；

3、调用资金账户服务给电商平台的商户账户加款（实际过程中可能还会有各种的成本计费；如果是余额支付，还可能是同时从用户账户扣款，给商户账户加款）；

4、调用积分服务给用户积分账户增加积分；

5、调用会计服务向会计（财务）系统写进交易原始凭证生成会计分录；

6、调用通知服务将支付处理结果通知电商平台；

如上图，把支付系统中的银行扣款成功回调处理流程提取出来，对应的分布式事务问题的代码场景：

/ 支付订单处理 /

@Transactional(rollbackFor = Exceptionclass)

public void completeOrder() {

orderDaoupdate();  // 订单服务本地更新订单状态

accountServiceupdate();  // 调用资金账户服务给资金帐户加款

pointServiceupdate();  // 调用积分服务给积分帐户增加积分

accountingServiceinsert();  // 调用会计服务向会计系统写入会计原始凭证

merchantNotifyServicenotify();  // 调用商户通知服务向商户发送支付结果通知

}

本地事务控制还可行吗？

以上分布式事务问题，需要多种分布式事务解决方案来进行处理。

订单处理：本地事务

资金账户加款、积分账户增加积分：TCC型事务（或两阶段提交型事务），实时性要求比较高，数据必须可靠。

会计记账：异步确保型事务（基于可靠消息的最终一致性，可以异步，但数据绝对不能丢，而且一定要记账成功）

商户通知：最大努力通知型事务（按规律进行通知，不保证数据一定能通知成功，但会提供可查询 *** 作接口进行核对）

是的，遵守两段封锁协议的并发事物的锁分为两个阶段：扩张阶段，对该事务所需要的数据全部加锁，该过程不允许解锁：收缩阶段：当该事务运行完成以后，对事物运行过程中所加的所，一一解开，该过程不想允许加锁

补充楼主：

其实我没什么经验，只不过是了解一些基础的东西罢了。

一楼的 一朵瘩红花 实际经验很丰富，你可以向她咨询一下。

你问的问题挺好得。三个概念紧密联系在一起。

这样说吧：并发的几个事务同时发生，不加锁控制的话数据就会乱套了，而加了锁后，又是并发访问会出现死锁，所以就会出现避免死锁的一些措施。

首先谈并发：理论指的是在一段时间同时对某件事进行 *** 作。 注意精度问题，修改数据库是在一段时间内 *** 作，不是在某个时刻，而日志则会从 时刻 开始记录你的 *** 作。

造成死锁的原因是为了防止 不同的用户同时间（不是时刻）都对某个数据修改，造成访问不一致的问题。

比如你读了数据库的一个数据然后把它修改了并存回去，是需要时间的（假如是student表中的有个grade属性，你改了一条记录的一个值）在这个过程当中，有人又访问了数据库并且恰恰访问的是存回去之前的数据，然后他要进行 *** 作，过了一段时间，此时你已经存回去了数据。会发现原来的数据被改动了。这时数据就乱套了。（专业术语叫读脏数据，其实还有很多其他类似这种导致前后数据不一致的问题）所以为了限定这种 *** 作，数据库设计了-----锁---来锁定这种 *** 作。就是你正在 *** 作某个数据的时候----通常之前会先锁定这个数据，这样别人就不能对此数据 *** 作了（严格来说就是只能读，不能改），必须等你 *** 作完才能对此数据修改等 *** 作，这就在一定程度上避免了前后 *** 作数据不一致的问题。

但是有了锁后，新问题出现了，就是死锁：

简单解释死锁：进程A等待进程B释放他的资源，B又等待A释放他的资源，这样就互相等待就形成死锁

官方解释死锁

死锁，根本原因在于对共享存储区的访问。在数据库中也一样，如果需要“修改”一条数据，首先数据库管理系统会在上面加锁，以保证在同一时间只有一个事务能进行修改 *** 作。锁有多种实现方式，比如意向锁，共享－排他锁，锁表，树形协议，时间戳协议等等。锁还有多种粒度，比如可以在表上加锁，也可以在记录上加锁。

在并发控制中，锁是非常重要的。

至于在Oracle还是别的数据库管理系统中，死锁产生的原因没有不同，不同的顶多是锁的实现或者死锁的恢复等罢了

再来说说事务：

事务简单来说就是 一系列的对数据库的 *** 作揉在一起，要么同时完成，要么就都不完成。

比如---你要取钱的过程就可以当成是一个小的事务： 插卡，输入取钱金额，取走钱，拿出来卡。此过程缺一不可。把所有这些过程细节封装起来就成为一个事务。

以oracle数据库为例：

一个事务（你可以认为是一系列业务的 *** 作）起始于dml语句（insert、update、delete）

即一条dml语句就做为一个事务的起始，然后根据业务需要，进行其他的dml *** 作都算是事务的一部分。

最后碰到commit。或者rollback，或者其他意外什么的都算作一个事务的结束。

整个过程就是一个事务。

事务的理论解释就是那四个什么特性：什么原子性、一致性、隔离性和持久性

简称ACID

剩下的：数据库是建立在 *** 作系统之上的一个层次。

你问的是数据库的存储机制？？工作机制？？还是什么的？？

数据库就是存数据的。数据库管理系统是 对存的数据进行高效率的管理

大的结构分物理数据跟逻辑数据。

物理数据就是数据在存储设备上的存储方式，什么物理联系，物理结构，物理记录等 术语。

逻辑数据就是程序员和用户看到的数据形式。什么逻辑联系，逻辑结构==同上

数据库管理类系统就是把这些逻辑跟物理相互转换。 好比你输入的叫逻辑数据存储在磁盘上叫物理数据。等等。

废话了一堆，也不知道回答对你的问题没~~

当多个用户同时更新同一数据的时候，由于更新可能导致数据的不一致性，使得程序的业务数据发生错误，这种情况可以称之为并发。在ADO NET中，并发的处理可以通过三种方式来控制：保守式并发控制、开发式并发控制以及最后更新生效方式。

— 保守式并发控制：数据从数据库取出之后，一直处于锁定的状态，其他用户不能获取该数据，直至数据更新完毕之后，用户才能取出该数据进行 *** 作。此种控制方式对于性能和资源占用得很多，由于只能同时有一个用户对数据享用 *** 作权，所以可能会在正常业务中，影响其他用户的处理进程。但此控制方式可以完全保证数据的完整性。该方式可以通过NET提供的事务机制来实现，前提是数据源需要支持事务。

— 开发式并发控制：数据在更新之前都是可以被其他用户使用的，只有在更新的时候，才锁定记录。但更新的时候，会比对与查询之初的数据是否吻合，如果不一致，则不运行修改。此种控制方式也可以完全保证数据的完整性，其优点是不会占用其他用户访问该数据的权限，其缺点是由于其他用户可能已经更新了这些数据，导致本次更新可能不会完成。对于此种控制方式，多以开发人员通过程序本身的业务逻辑来实现。

— 最后更新生效方式：此种方式同上，只有在数据更新的时候，其他用户才不可使用，但更新的时候不检查是否与开始数据一致，而直接对其更新。此种方式对于更新的并发性有很大的支持，但缺点是可能引发前后数据的不一致。此种方式适合可以满足此需求的业务场景使用。

注意：数据库的并发处理并不是一成不变的，不同的业务场景对数据库的并发要求是不一样的，可以根据具体情况具体分析

并发（concurrent）和并行（parallel）这两个概念，在数据库系统的资料中经常出现，然而有关它们的定义和区别却没有明确的说法。这里，我们根据这两个概念在资料中的使用，对它们的不同做一个说明。

并发是指多个任务的同时执行，任务与任务之间没有联系。由于数据库系统要同时为许多用户提供服务，每个用户都可以发出自己的访问请求，一个请求就是一个任务。在一个时间点，数据库系统可能要同时处理多个任务。因此，数据库系统一定要具备并发处理能力。

并行是指将一个任务划分为多个子任务，这些子任务同时执行。在所有子任务处理完成后，将它们的结果进行合并，就得到该任务的最终处理结果。在数据库系统中，如果要执行一个大的数据查询，为了提高速度、降低响应时间，用户可以通过系统配置或者在命令中，要求对该大数据量查询进行并行处理，将该查询划分成多个子查询。这些子查询同时执行，最后系统将所有子查询的处理结果进行合并，作为该查询处理的最终结果。现有的大型数据库系统都支持并行处理。

需要说明的是，并发和并行与数据库系统采用多进程还是多线程体系结构无关。对采用多进程结构的数据库系统，所有的任务、子任务通过进程来处理；而对采用多线程结构的数据库系统，这些工作是由线程来完成。

数据库系统的并发控制，涉及到任务的调度、数据的一致性及可靠性等，而数据库系统的并行处理，主要涉及任务的处理速度、系统性能等方面。

以上就是关于SQL Server数据库表锁定原理以及如何解除锁定全部的内容，包括:SQL Server数据库表锁定原理以及如何解除锁定、Oracle数据库锁的常用类型有哪些、微服务架构的分布式事务问题如何处理等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！