事务与并发控制

最新推荐文章于 2022-09-02 11:08:58 发布
最新推荐文章于 2022-09-02 11:08:58 发布
阅读量918 收藏 1
点赞数
分类专栏： PostgreSQL
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/u011354817/article/details/105971820
版权

文章目录

事务

概念

事务是数据库系统执行过程中最小的逻辑单位。
在PostgreSQL中，显示地指定BEGIN…END/COMMIT/ROLLBACK包括的语句块为一个事务，未指定的单条语句也称为一个事务。

例如：

SELECT
    now(),
    now();

              now              |              now
-------------------------------+-------------------------------
 2020-02-29 07:21:55.100997+00 | 2020-02-29 07:21:55.100997+00
(1 row)

BEGIN；


SELECT
    now();

              now
-------------------------------
 2020-02-29 07:15:06.975875+00
(1 row)


SELECT
    now();

              now
-------------------------------
 2020-02-29 07:15:06.975875+00
(1 row)


COMMIT;

事务有四个重要的特性（通常称为ACID）：

  • 原子性（Atomicity）：事务必须是原子工作单元，对于其数据修改，要么全都执行，要么全都不执行。

  • 一致性（Consistency）：事务在完成时，必须使所有的数据都保持一致状态。

  • 隔离性（Isolation）：由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。事务查看数据时数据所处的状态，要么是另一个并发事务修改它之前的状态，要么是修改它之后的状态。事务不会查看中间状态的数据。

  • 持久性（Durability）：事务完成之后，它对于系统的影响是永久性的。即使出现系统故障也将一直保持。

其中，一致性由主键、外键这类约束保证，持久性由WAL日志和数据库管理系统的恢复子系统保证，原子性、隔离性由事务管理器和MVCC来控制。

并发引发的现象

数据库中数据的并发操作经常发生，而对数据的并发操作可能会带来脏读、幻读、不可重复读等现象。

创建测试数据，并举例说明。

CREATE TABLE t_test (
    id		int,
    name	text
);


INSERT INTO t_test (
    id,
    name
)
VALUES
    (
        1,
        'a'
    );

脏读

一个事务读取了另一个并行未提交事务写入的数据。

由于PostgreSQL内部将Read Uncommitted设计为和Read Committed一样，因此在PostgreSQL中，无法产生脏读。所以下面的例子是假想的。

事务1事务2
BEGIN TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;BEGIN;
UPDATE t_test SET name = ‘b’ WHERE id = 1;
SELECT * FROM t_test;
看到 (1, a)
ROLLBACK

不可重复读

一个事务重新读取之前读取过的数据，发现该数据已经被另一个事务（在初始读之后提交）修改。

事务1事务2
BEGIN TRANSACTION ISOLATION LEVEL READ COMMITTED;
SELECT * FROM t_test WHERE id = 1;
看到 (1, a)
BEGIN;
UPDATE t_test SET name = ‘b’ WHERE id = 1;
COMMIT;
SELECT * FROM t_test WHERE id = 1;
看到 (1, b)

使用可重复读隔离级别，可以避免不可重复读：

事务1事务2
BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ;
SELECT * FROM t_test WHERE id = 1;
看到 (1, a)
BEGIN;
UPDATE t_test SET name = ‘b’ WHERE id = 1;
COMMIT;
SELECT * FROM t_test WHERE id = 1;
仍然看到 (1, a)

幻读

一个事务重新执行一个返回符合一个搜索条件的行集合的查询， 发现满足条件的行集合因为另一个最近提交的事务而发生了改变。

事务1事务2
BEGIN TRANSACTION ISOLATION LEVEL READ COMMITTED;
SELECT * FROM t_test WHERE id < 3;
看到 (1, a)
BEGIN;
INSERT INTO t_test (id, name) VALUES (2, ‘b’);
COMMIT;
SELECT * FROM t_test WHERE id < 3;
(1, a)
(2, b)

不可重复读和幻读很相似，它们之间的区别主要在于不可重复读主要受到其他事务对数据的UPDATE操作影响，而幻读主要受到其他事务的INSERT和DELETE操作影响。

在PostgreSQL中，使用可重复读隔离级别，也可以避免幻读：

事务1事务2
BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ;
SELECT * FROM t_test WHERE id < 3;
看到 (1, a)
BEGIN;
INSERT INTO t_test (id, name) VALUES (2, ‘b’);
COMMIT;
SELECT * FROM t_test WHERE id < 3;
仍然看到 (1, a)

事务隔离级别

SQL标准允许更严格的行为：四种隔离级别只定义了哪种现象不能发生，但是没有定义哪种现象必须发生。

隔离级别脏读不可重复读幻读序列化异常
读未提交可能，但不在PG中可能可能可能
读已提交不可能可能可能可能
可重复读不可能不可能可能，但不在PG中可能
可序列化不可能不可能不可能不可能

  • Read Uncommitted（读未提交）：在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。在多用户数据库中，脏读是非常危险的，在并发情况下，查询结果非常不可控。即使不考虑结果的严谨性只追求性能，它的性能也并不比其他事务隔离级别好多少，可以说脏读没有任何好处。所以读未提交这一事务隔离级别很少用于实际应用。

  • Read Committed（读已提交）：PostgreSQL的默认隔离级别。当一个事务运行使用这个隔离级别时，一个查询（没有FOR UPDATE/SHARE子句）只能看到查询开始之前已经被提交的数据， 而无法看到未提交的数据或在查询执行期间其它事务提交的数据。实际上，SELECT查询看到的是一个在查询开始运行的瞬间该数据库的一个快照。不过SELECT可以看见在它自身事务中之前执行的更新的效果，即使它们还没有被提交。还要注意的是，即使在同一个事务里两个相邻的SELECT命令可能会看到不同的数据， 因为其它事务可能会在第一个SELECT开始和第二个SELECT开始之间提交。

  • Repeatable Read（可重复读）：可重复读隔离级别只看到在事务开始之前被提交的数据，它从来看不到未提交的数据或者并行事务在本事务执行期间提交的修改。在PostgreSQL中，这个隔离级别阻止了除序列化异常之外的所有现象，这是比SQL标准对此隔离级别所要求的更强的保证。如上面所提到的，这是SQL标准特别允许的。

  • Serializable（可序列化）：可序列化隔离级别提供了最严格的事务隔离。这个级别为所有已提交事务模拟序列事务执行，就好像事务被按照序列一个接着另一个被执行，而不是并行地被执行。但是，使用这个级别的应用必须准备好因为序列化失败而重试事务。事实上，这个隔离级别完全像可重复读一样地工作，除了它会监视一些条件，这些条件可能导致一个可序列化事务的并发集合的执行产生的行为与这些事务所有可能的序列化（一次一个）执行不一致。这种监控不会引入超出可重复读之外的阻塞，但是监控会产生一些负荷，并且对那些可能导致序列化异常的条件的检测将触发一次序列化失败。

并发控制

基于锁的并发控制

PostgreSQL为锁定一个表提供了8种类型的锁。一个锁可以轻如ACCESS SHARE锁或者重如ACCESS EXCLUSIVE锁。

锁模式解释
Access Share只与Access Exclusive锁模式冲突。
SELECT将会在它查询的表上获取Access Share锁，一般地，任何一个对表上的只读查询操作都将获取这种类型锁。
Row Share与Exclusive和Access Exclusive锁模式冲突。
SELECT FOR UPDATE和SELECT FOR SHARE命令将获得这种类型锁。
Row Exclusive与Share，Share Row Exclusive，Exclusive，Access Exclusive模式冲突。
UPDATE/DELETE/INSERT命令会在目标表上获得这种类型的锁，一般地，更改表数据的命令都将在这张表上获得Row Exclusive锁。
Share Update ExclusiveShare Update Exclusive，Share，Share Row Exclusive，Exclusive，Access exclusive模式冲突，这种模式保护一张表不被并发的模式更改和VACUUM。
VACUUM(without FULL)，ANALYZE和CREATE INDEX CONCURRENTLY命令会获得这种类型锁。
Share与Row Exclusive，Share Update Exclusive，Share Row Exclusive，Exclusive，Access exclusive锁模式冲突，这种模式保护一张表数据不被并发的更改。
CREATE INDEX命令会获得这种锁模式。
Share Row Exclusive与Row Exclusive，Share Update Exclusive，Shared，Shared Row Exclusive，Exclusive，Access Exclusive锁模式冲突。
任何PostgreSQL命令都不会自动请求这个锁模式。
Exclusive与ROW Share, Row Exclusive, Share Update Exclusive, Share , Share Row Exclusive, Exclusive, Access Exclusive模式冲突，这种锁模式仅能与Access Share模式并发，换句话说，只有读操作可以和持有Exclusive锁的事务并行。
任何PostgreSQL命令都不会在用户表上自动请求这个锁模式。
Access Exclusive与所有模式锁冲突（Access Share，Row Share，Row Exclusive，Share Update Exclusive，Share, Share Row Exclusive，Exclusive，Access Exclusive）。
这种模式保证了当前只有一个人访问这张表。ALTER TABLE，DROP TABLE，TRUNCATE，REINDEX，CLUSTER，VACUUM FULL命令会获得这种类型锁，在LOCK TABLE命令中，如果没有申明其它模式，它也是默认模式。

表级锁的冲突矩阵

请求的锁模式当前的锁模式
Access ShareRow ShareRow ExclusiveShare Update ExclusiveShareShare Row ExclusiveExclusiveAccess Exclusive
Access ShareX
Row ShareXX
Row ExclusiveXXXX
Share Update ExclusiveXXXXX
ShareXXXXXX
Share Row ExclusiveXXXXXX
ExclusiveXXXXXXX
Access ExclusiveXXXXXXXX

表中“X”表示这两种表冲突，也就是不同的进程不能同时持有这两种锁。

最普通的是共享锁Share和排他锁Exclusive，它们分别是读、写锁的意思。加了Share锁，即读锁，表的内容就不能变化了，可以为多个事务加上此锁，只要任意一个事务不释放这个读锁，则其他事务就不能修改这个表。加上了Exclusive，相当于加了写锁，这时别的进程不能写也不能读这条数据。

后来数据库又加上了多版本的功能。修改一条语句的同时，允许了读数据，为了处理这种情况，又增加了两种锁Access Share和Access Excusive，锁中的关键字Access是与多版本读相关的。有了多版本的功能后，如果修改一行数据，实际并没有改原先那行数据，而是复制了一个新行，修改都在新行上，事务不提交，其他人是看不到修改的这条数据的。由于旧行数据没有变化，在修改过程中，读数据的人仍然可以读到旧的数据。

表级锁加锁对象是表，这使得加锁范围太大，导致并发并不高，于是人们提出了行级锁的概念，但行级锁与表级锁之间会产生冲突，这时需要一种机制来描述行级锁与表级锁之间的关系。方法就是当我们要修改表中的某一行数据时，需要先在表上加一种锁，如Row Share和Row Exclusive（对应MySQL中的共享意向锁和排他意向锁），表示即将在表的部分行上加共享锁或排他锁。

表级锁对应的操作

锁类型对应的数据库操作
Access ShareSELECT
Row ShareSELECT FOR UPDATE，SELECT FOR SHARE
Row ExclusiveUPDATE，DELETE，INSERT
Share Update ExclusiveVACUUM (without FULL)，ANALYZE，CREATE INDEX CONCURRENTLY
ShareCREATE INDEX (without CONCURRENTLY)
Share Row Exclusive任何PostgreSQL命令都不会自动请求这个锁模式
Exclusive任何PostgreSQL命令都不会在用户表上自动请求这个锁模式
Access ExclusiveALTER TABLE，DROP TABLE，TRUNCATE，REINDEX，CLUSTER，VACUUM FULL

锁的查看

视图pg_locks提供了数据库服务器上活动进程中保持的锁的信息。

名称类型引用描述
locktypetext可锁对象的类型： relation, extend, page, tuple, transactionid, virtualxid, object, userlock, or advisory
databaseoidpg_database.oid锁目标存在的数据库的OID，如果目标是一个共享对象则为0，如果目标是一个事务ID则为空
relationoidpg_class.oid作为锁目标的关系的OID，如果目标不是一个关系或者只是关系的一部分则此列为空
pageinteger作为锁目标的页在关系中的页号，如果目标不是一个关系页或元组则此列为空
tuplesmallint作为锁目标的元组在页中的元组号，如果目标不是一个元组则此列为空
virtualxidtext作为锁目标的事务虚拟ID，如果目标不是一个虚拟事务ID则此列为空
transactionidxid作为锁目标的事务ID，如果目标不是一个事务ID则此列为空ID
classidoidpg_class.oid包含锁目标的系统目录的OID，如果目标不是一个普通数据库对象则此列为空
objidoid任意OID列锁目标在它的系统目录中的OID，如果目标不是一个普通数据库对象则为空
objsubidsmallint锁的目标列号（classid和objid指表本身），如果目标是某种其他普通数据库对象则此列为0，如果目标不是一个普通数据库对象则此列为空
virtualtransactiontext保持这个锁或者正在等待这个锁的事务的虚拟ID
pidinteger保持这个锁或者正在等待这个锁的服务器进程的PID，如果此锁被一个预备事务所持有则此列为空
modetext此进程已持有或者希望持有的锁模式
grantedboolean如果锁已授予则为真，如果锁被等待则为假
fastpathboolean如果锁通过快速路径获得则为真，通过主锁表获得则为假
单个读
事务1事务2
SELECT pg_backend_pid();
10572
BEGIN;
SELECT * FROM t_test;
查看锁【注1】
查看表【注2】

【注1】

SELECT
    locktype, database, relation, virtualxid, transactionid, virtualtransaction, pid, mode, granted
FROM
    pg_locks
WHERE
    pid = 10572;
    
  locktype  | database | relation | virtualxid | transactionid | virtualtransaction |  pid  |      mode       | granted
------------+----------+----------+------------+---------------+--------------------+-------+-----------------+---------
 relation   |    13269 |    16398 |            |               | 5/7                | 10572 | AccessShareLock | t
 virtualxid |          |          | 5/7        |               | 5/7                | 10572 | ExclusiveLock   | t
(2 rows)

【注2】

SELECT relname FROM pg_class WHERE oid = 16398;

 relname
---------
 t_test
(1 row)
同时读写
事务1事务2事务3
SELECT pg_backend_pid();SELECT pg_backend_pid();
43544366
BEGIN;BEGIN;
UPDATE t_test SET name = ‘c’ WHERE id = 1;
SELECT * FROM t_test WHERE id = 1;
看到 (1, a)
查看锁【注3】

【注3】

SELECT
    locktype, relation, transactionid, pid, mode, granted
FROM
    pg_locks
WHERE
    pid IN (4354, 4366) 
    AND (relation > 5000 OR relation IS NULL) 
ORDER BY pid;

   locktype    | relation | transactionid | pid  |       mode       | granted
---------------+----------+---------------+------+------------------+---------
 relation      |    16398 |               | 4354 | RowExclusiveLock | t
 virtualxid    |          |               | 4354 | ExclusiveLock    | t
 transactionid |          |          1706 | 4354 | ExclusiveLock    | t
 relation      |    16398 |               | 4366 | AccessShareLock  | t
 virtualxid    |          |               | 4366 | ExclusiveLock    | t
(5 rows)
同时写
事务1事务2事务3
SELECT pg_backend_pid();SELECT pg_backend_pid();
96029617
BEGIN;BEGIN;
UPDATE t_test SET name = ‘c’ WHERE id = 1;
UPDATE t_test SET name = ‘d’ WHERE id = 1;
等待事务1
查看锁【注4】

【注4】

SELECT ctid, * FROM t_test;

 ctid  | id | name
-------+----+------
 (0,6) |  1 | a
 (0,8) |  2 | b
(2 rows)


SELECT
    locktype, database, relation, page, tuple, virtualxid, transactionid, virtualtransaction, pid, mode, granted, fastpath
FROM
    pg_locks
WHERE
    pid IN (9602, 9617)
    AND (relation > 5000 OR relation IS NULL)
ORDER BY pid;

   locktype    | database | relation | page | tuple | virtualxid | transactionid | virtualtransaction | pid  |       mode       | granted | fastpath
---------------+----------+----------+------+-------+------------+---------------+--------------------+------+------------------+---------+----------
 relation      |    13269 |    16398 |      |       |            |               | 2/32               | 9602 | RowExclusiveLock | t       | t
 virtualxid    |          |          |      |       | 2/32       |               | 2/32               | 9602 | ExclusiveLock    | t       | t
 transactionid |          |          |      |       |            |          1709 | 2/32               | 9602 | ExclusiveLock    | t       | f
 virtualxid    |          |          |      |       | 3/16       |               | 3/16               | 9617 | ExclusiveLock    | t       | t
 transactionid |          |          |      |       |            |          1709 | 3/16               | 9617 | ShareLock        | f       | f
 tuple         |    13269 |    16398 |    0 |     6 |            |               | 3/16               | 9617 | ExclusiveLock    | t       | f
 transactionid |          |          |      |       |            |          1710 | 3/16               | 9617 | ExclusiveLock    | t       | f
 relation      |    13269 |    16398 |      |       |            |               | 3/16               | 9617 | RowExclusiveLock | t       | t
(8 rows)


SELECT 
    pid, wait_event_type, wait_event, state, backend_xid, backend_xmin, query
FROM
    pg_stat_activity
WHERE
    pid IN (9602, 9617);
    
 pid  | wait_event_type |  wait_event   |        state        | backend_xid | backend_xmin |                   query                
------+-----------------+---------------+---------------------+-------------+--------------+--------------------------------------------
 9602 |                 |               | idle in transaction |        1709 |              | UPDATE t_test SET name = 'c' WHERE id = 1;
 9617 | Lock            | transactionid | active              |        1710 |         1709 | UPDATE t_test SET name = 'd' WHERE id = 1;
(2 rows)

同时日志里记录如下：

2020-05-09 00:40:46.178 CST,"postgres","postgres",9617,"127.0.0.1:40056",5eb58b0d.2591,1,"",2020-05-09 00:38:37 CST,3/16,1710,LOG,00000,"process 9617 still waiting for ShareLock on transaction 1709 after 1000.090 ms","Process holding the lock: 9602. Wait queue: 9617.",,,,"while updating tuple (0,6) in relation ""t_test""",,,"ProcSleep, proc.c:1425","psql"

如果事务1结束，则事务2获得锁，在日志里记录如下：

2020-05-09 00:52:28.462 CST,"postgres","postgres",9617,"127.0.0.1:40056",5eb58b0d.2591,2,"",2020-05-09 00:38:37 CST,3/16,1710,LOG,00000,"process 9617 acquired ShareLock on transaction 1709 after 703283.665 ms",,,,,"while updating tuple (0,6) in relation ""t_test""",,,"ProcSleep, proc.c:1432","psql"
观察死锁

死锁是指两个（或多个）事务相互持有对方期待的锁，例如，如果事务1在表A上获得一个排他锁，同时试图获取一个在表B上的排他锁， 而事务2已经持有表B的排他锁，同时却正在请求表A上的一个排他锁，那么两个事务就都不能进行下去。

PostgreSQL能够自动检测到死锁情况并且会通过中断其中一个事务从而允许其它事务完成来解决这个问题。

事务1事务2
BEGIN;BEGIN;
SELECT * FROM t_test WHERE id = 1 FOR UPDATE;
SELECT * FROM t_test WHERE id = 2 FOR UPDATE;
SELECT * FROM t_test WHERE id = 2 FOR UPDATE;
等待事务2SELECT * FROM t_test WHERE id = 1 FOR UPDATE;
等待事务2等待事务1
1秒（deadlock_timeout）以后死锁解除

一旦检测到死锁，将会报错如下：

ERROR:  deadlock detected
DETAIL:  Process 9617 waits for ShareLock on transaction 1711; blocked by process 9602.
Process 9602 waits for ShareLock on transaction 1712; blocked by process 9617.
HINT:  See server log for query details.
CONTEXT:  while locking tuple (0,6) in relation "t_test"

日志：

2020-05-09 01:02:35.541 CST,"postgres","postgres",9602,"127.0.0.1:40043",5eb58b04.2582,1,"",2020-05-09 00:38:28 CST,2/33,1711,LOG,00000,"process 9602 still waiting for ShareLock on transaction 1712 after 1000.097 ms","Process holding the lock: 9617. Wait queue: 9602.",,,,"while locking tuple (0,8) in relation ""t_test""",,,"ProcSleep, proc.c:1425","psql"
2020-05-09 01:03:22.892 CST,"postgres","postgres",9617,"127.0.0.1:40056",5eb58b0d.2591,3,"",2020-05-09 00:38:37 CST,3/17,1712,LOG,00000,"process 9617 detected deadlock while waiting for ShareLock on transaction 1711 after 1000.063 ms","Process holding the lock: 9602. Wait queue: .",,,,"while locking tuple (0,6) in relation ""t_test""",,,"ProcSleep, proc.c:1416","psql"
2020-05-09 01:03:22.893 CST,"postgres","postgres",9617,"127.0.0.1:40056",5eb58b0d.2591,4,"",2020-05-09 00:38:37 CST,3/17,1712,ERROR,40P01,"deadlock detected","Process 9617 waits for ShareLock on transaction 1711; blocked by process 9602.
Process 9602 waits for ShareLock on transaction 1712; blocked by process 9617.
Process 9617: SELECT * FROM t_test WHERE id = 1 FOR UPDATE;
Process 9602: SELECT * FROM t_test WHERE id = 2 FOR UPDATE;","See server log for query details.",,,"while locking tuple (0,6) in relation ""t_test""",,,"DeadLockReport, deadlock.c:1135","psql"
2020-05-09 01:03:22.893 CST,"postgres","postgres",9602,"127.0.0.1:40043",5eb58b04.2582,2,"",2020-05-09 00:38:28 CST,2/33,1711,LOG,00000,"process 9602 acquired ShareLock on transaction 1712 after 48351.896 ms",,,,,"while locking tuple (0,8) in relation ""t_test""",,,"ProcSleep, proc.c:1432","psql"
Loong Tu
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
postgresql表中间加列_PostgreSQL死锁案例分析__在最近的生产环境巡检中，发现一个死锁错误。从日志中看，触发死锁的是对表的相同行操作，最终分析和业务操作有关，不过其中涉及到Postg...
weixin_39732249的博客
12-22 259
### **作者介绍**#### 陈雁飞，开源PostgreSQL爱好者，一直从事PostgreSQL数据库运维工作### **问题现象**#### 在最近的生产环境巡检中，发现一个死锁错误。从日志中看，触发死锁的是对表的相同行操作，最终分析和业务操作有关，不过其中涉及到Postgres数据库的外键更新加锁处理逻辑，下面对这个问题展开详细分析。#### 数据库日志中记录的死锁日志信息如下```20...
postgres死锁处理
不再疯要傻
12-23 5757
psotgres 锁     1、因为事物产生的锁 操作： session A postgres=# drop table test2; DROP TABLE postgres=# create table test2(id int, info text); CREATE TABLE postgres=# insert into test2 values (1,'test');
PostgreSQL 解决锁表、死锁问题
qq_25775675的博客
02-17 6094
1.-- 查询ACTIVITY的状态等信息 select T.PID, T.STATE, T.QUERY, T.WAIT_EVENT_TYPE, T.WAIT_EVENT, T.QUERY_START from PG_STAT_ACTIVITY T where T.DATNAME = '数据库用户名'; 上面查询结果中：pid就是ACTIVITY的唯一标识，st...
数据库表死锁解决方案
yangyi1018的博客
04-11 1270
系统单元测试时，增删改的操作会突然无法进行，导致需要重启服务器，然后在测试再无法执行......  死循环，郁闷.... 我们可以再PL/SQL下解决这类的问题 查询一下： select object_name,s.sid,s.serial# From v$locked_object o,v$session s ,dba_objects c Where o.session_id=s.sid An
Python 随录———持续更新Updating
D_Music的博客
05-07 331
Python随录——持续更新一、class与class（）的区别如果声明和定义类的时候带不带括号只是继承与不继承的关系，但在应用类对象的时候会是什么样子呢？class Obj: def __init__(self): print "Obj __init__" if __name__ ="__main__": ob1=Obj print "*"*10 ...
实验15事务与并发控制.pdf
10-05
实验15的主题聚焦于“事务与并发控制”，这是数据库管理系统中的核心概念，特别是对于确保数据一致性和完整性至关重要。事务是数据库操作的基本单元，它代表了一系列的数据库操作，这些操作要么全部执行，要么全部不...
实验17事务与并发控制.pdf
10-05
【事务与并发控制】是数据库管理系统中的核心概念，主要涉及数据的一致性和完整性。本实验旨在让学生深入理解数据库事务的基本概念、四大特性以及如何在SQL Server中进行事务管理。 1. **事务的概念**：事务是...
数据库实验报告：事务与并发控制.docx
10-03
数据库实验报告：事务与并发控制.docx
实验15事务与并发控制.doc
09-25
实验15事务与并发控制.doc
数据库课程设计-客户信息管理系统实验报告事务与并发控制.docx
最新发布
03-12
【数据库课程设计-客户信息管理系统实验报告事务与并发控制】 本次实验主要围绕客户信息管理系统，涉及的核心知识点包括事务处理和并发控制，这是数据库系统中确保数据一致性和完整性的重要机制。 1. **事务处理**...
一次生产死锁问题的处理
勿在浮沙筑高台
09-02 404
存储制品库maven包，有两张表meta_maven存储groupId、artifactId、version信息，meta_maven_file存储GAV下的具体文件jar、pom、sha1、meta_maven.xml。场景1: deploy上传snapshot的maven包，用新的meta_maven.xml替换之前的，之前的删除。场景2: 下载GAV包，检查是否有漏洞：开始更新组件状态为扫描中，从黑鸭子获取扫描结果（超长时间等待），更新组件的扫描结果，有漏洞禁止下载。
MySQL与PostgreSQL的 SELECT FOR UPDATE
热门推荐
04-07 1万+
MySQL的行级锁 MySQL 版本: 1 2 3 4 5 6 7 8 9 mysql> select version(); +------------+ | version() | +------------+ | 5.6.17-log | +------------+ 1 row in set (0.00 sec) mysql> 创建
PostgreSQL 锁等待跟踪
工作点滴
05-05 3207
摘要PostgreSQL 在打印LONG SQL时，锁等待的时间也会算在内，并且目前在日志中没有将锁等待的时间单独打印出来。 shared_preload_libraries='auto_explain' auto_explain.log_min_duration='1s' auto_explai... PostgreSQL 在打印LONG SQL时，锁等待的时间也会算在内，并且目前在日
Cause: org.postgresql.util.PSQLException: ERROR: deadlock detected 检测到死锁异常排查处理
weixin_40903055的博客
03-23 6304
报错内容如下： org.springframework.dao.DeadlockLoserDataAccessException: ### Error querying database. Cause: org.postgresql.util.PSQLException: ERROR: deadlock detected 详细：Process 7372 waits for ShareLock on transaction 46061491; blocked by process 4624. Pro
pgsql批量死锁
fay的博客
11-02 2325
jdbc批量更新时死锁. java.sql.BatchUpdateException: Batch entry 910 UPDATESQL语句 was aborted：ERROR：deadlock detected 详细： Process 157988 waites for ShareLock on transaction 7944777; blocked by process 157400. Process 157400 waites for ShareLock on transaction 794477
MySQL和PostgreSQL中的死锁
allway2的博客
01-27 1908
并发控制是与数据库一起使用的概念，可确保并发执行数据库事务而不会破坏数据完整性。 关于此概念及其实现方法有很多理论和不同方法，但是我们将简要介绍PostgreSQL和MySQL（使用InnoDB时）处理它的方式，以及在高并发系统中可能出现的常见问题：僵局。 这些引擎通过使用称为MVCC（多版本并发控制）的方法来实现并发控制。在此方法中，当更新项目时，更改不会覆盖原始数据，而是将创建该项目的新版本（包含更改）。因此，我们将存储该项目的多个版本。 该模型的主要优点之一是为查询（读取）数据而获取的锁与为写入
postgresql 锁_PostgreSQL中的锁：3.其他锁
cullen2012的博客
09-09 1219
postgresql 锁object-level locks (specifically, relation-level locks), as well as 对象级别的锁 (特别是关系级别的锁)，以及row-level locks with their connection to object-level locks and also explored wait queues, which ar...
PostgreSQL DBA(78) - Locks(When Postgres blocks 7 tips for dealing with locks)
08-14 544
本节介绍了APP在涉及locks时需要注意的地方. 测试数据: [local]:5432 pg12@testdb=# ...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值