Key Concepts SQL Optimization: Transaction

: Original Key Concepts SQL Optimization: Transaction

 

sql optimization and business relationship?

On the surface, let sql run faster, it seems that the concept of a transaction and no contact, but the relational database of the most important is the relationship between two concepts, matters.

Relationship, in correspondence to sql, is achieved through the primary and foreign key join, of course, is not the primary foreign key, can still association table.

Affairs, is provided by the database, especially in the case of high concurrency, consistent data protection mechanism.

But in fact, when a session is to modify the data, and another session have to read the data, the transaction will automatically play.

Under normal circumstances, it seems that this transaction and far away from us, it seems to be carried out without a trace of the concept, but we can through some system attempts to check the details about the transaction information to deepen understanding of the issues.

 

1, implicit transaction

Implicit transaction is carried out without explicit commit or rollback, the transaction is consistent presence.

Since the default sql server implicit transaction is closed, so in the following experiment to open the implicit transaction.


   
   
  1. /*==================================================================
  2. 当以create,drop,
  3. fetch,open,
  4. revoke,grand,
  5. alter table,select,insert,delete,update,truncate table
  6. 语句首先执行的时候,SQL Server会话自动打开一个新的事务,
  7. 如果在会话中激活了隐式事务模式,那么这个事务会一直保持打开状态,
  8. 直到rollback或commit语句这个事务才结束,如果忘记提交事务,
  9. 那么在相应的隔离级别下,事务占用的锁可能不会释放,因此尽量不要用隐式事务。
  10. ====================================================================*/
  11. --会话1
  12. set implicit_transactions on
  13. update t
  14. set v = 'ext12'
  15. set implicit_transactions off
  16. select @@TRANCOUNT --输出:1,说明事务没有释放
  17. --占用的X独占锁不会释放,会阻塞其他会话

   
   
  1. --会话2,被会话1阻塞住了,不会返回任何记录
  2. select *
  3. from t

In session 1 to submit the Executive commit the transaction, the session will be immediately returned 2 records.

Now the order of execution of two sessions of the exchange about:


   
   
  1. --会话1
  2. set implicit_transactions on --打开了隐式事务
  3. select *
  4. from t
  5. set implicit_transactions off
  6. select @@TRANCOUNT --输入:1,说明这个会话中的事务也没有提交

   
   
  1. --会话2,会话2没有被会话1阻塞,
  2. --之所以这样是因为会话的默认隔离级别是read committed,
  3. --会话1中的事务虽然没有提交,但是select语句在这种隔离级别下,
  4. --运行完就会释放占用的S共享锁,所以不会阻塞写操作
  5. update t
  6. set v = 'ext'

 

2, showing the oldest active transaction database


   
   
  1. /*==============================================================
  2. 如果事务在数据库中始终打开,有可能会阻塞其他进程的操作,
  3. 为什么是有可能而不是一定呢,
  4. 原因就是:在默认隔离级别下的select语句查询到数据后就会立即释放共享锁。
  5. 另外,日志备份也只会截断不活动事务的那部分日志,所以活动的事务
  6. 会导致日志数据越来越多。
  7. 为了找到没有提交的事务,可以用下面的命令显示某个数据库最早的活动事务.
  8. 不过有个例外,就是下面的命令不会返回:不占用锁资源的未提交事务
  9. ================================================================*/
  10. begin tran --开始显示事务
  11. select *
  12. from t --运行后立即释放共享锁
  13. select @@TRANCOUNT --输入:1,说明没有提交事务
  14. dbcc opentran( 'wc') --显示数据库最早的活动事务,
  15. --但是这儿显示"没有处于打开状态的活动事务"

 

3, through the session to query transaction information


   
   
  1. --由于上面未提交事务中的select语句在默认的隔离级别下执行后自动释放了共享锁,
  2. --所以dbcc opentran命令并没有返回这个活动事务,
  3. --不过下面的视图解决了这个问题,可以找到所有活动事务。
  4. --找到活动事务
  5. select session_id, --session_id与transaction_id的对应关系
  6. transaction_id,
  7. is_user_transaction,
  8. is_local
  9. from sys.dm_tran_session_transactions --会话中的事务,识别所有打开的事务
  10. where is_user_transaction = 1
  11. --找到活动事务对应的执行语句
  12. select c.session_id, --session_id与connection_id的对应关系
  13. c.connection_id,
  14. c.most_recent_sql_handle,
  15. s.text
  16. from sys.dm_exec_connections c --执行连接,最近执行的查询信息
  17. cross apply sys.dm_exec_sql_text(c.most_recent_sql_handle) s
  18. where c.session_id = 361
  19. --活动事务的具体信息
  20. select t.transaction_id,
  21. t.name, --这里显示user_transaction
  22. t.transaction_begin_time,
  23. case t.transaction_type --事务类型
  24. when 1 then '读/写事务'
  25. when 2 then '只读事务'
  26. when 3 then '系统事务'
  27. when 4 then '分布式事务'
  28. end 'transaction type',
  29. case t.transaction_state
  30. when 0 then '事务尚未完全初始化'
  31. when 1 then '事务已初始化但尚未启动'
  32. when 2 then '事务处于活动状态'
  33. when 3 then '事务已结束。该状态用于只读事务'
  34. when 4 then '已对分布式事务启动提交进程'
  35. when 5 then '事务处于准备就绪状态且等待解析'
  36. when 6 then '事务已提交'
  37. when 7 then '事务正在被回滚'
  38. when 8 then '事务已回滚'
  39. end 'transaction state'
  40. from sys.dm_tran_active_transactions t --活动的事务
  41. where transaction_id = 150764485
Published 416 original articles · won praise 135 · views 940 000 +

Guess you like

Origin www.cnblogs.com/lonelyxmas/p/12019937.html