SQLの最適化とビジネス関係？
表面には、より高速なSQL実行させ、それがトランザクションの概念と非接触と思われるが、最も重要なのリレーショナルデータベースは二つの概念、問題との関係です。
リレーションシップは、SQLに対応して、関連テーブルはまだ、もちろん、主外部キーではなく、プライマリおよび外部キーによって可能に参加達成されます。
業務は、特に高い並行性、一貫性のあるデータ保護機構の場合には、データベースによって提供されます。
セッションがデータを変更することで、別のセッションがデータを読み取るために持っている場合しかし、実際には、トランザクションが自動的に再生されます。
通常の状況下では、遠く離れて私たちからこの取引とは、コンセプトの跡形もなく行われているように見えるようですが、私たちは問題の理解深めるための取引情報についての詳細を確認するためにいくつかのシステムの試行を介しすることができます。
1、暗黙的なトランザクション
暗黙的なトランザクションを明示的にコミットまたはロールバックせずに行われ、トランザクションが一貫性の存在です。
デフォルトのSQL Serverの暗黙的なトランザクションが閉じているので、その次の実験で暗黙的なトランザクションを開きます。
-
/*==================================================================
-
当以create,drop,
-
fetch,open,
-
revoke,grand,
-
alter table,select,insert,delete,update,truncate table
-
语句首先执行的时候，SQL Server会话自动打开一个新的事务，
-
如果在会话中激活了隐式事务模式，那么这个事务会一直保持打开状态，
-
直到rollback或commit语句这个事务才结束，如果忘记提交事务,
-
那么在相应的隔离级别下，事务占用的锁可能不会释放，因此尽量不要用隐式事务。
-
====================================================================*/
-
-
--会话1
-
set implicit_transactions
on
-
-
update t
-
set v =
'ext12'
-
-
set implicit_transactions
off
-
-
select @@TRANCOUNT
--输出：1，说明事务没有释放
-
--占用的X独占锁不会释放，会阻塞其他会话
-
--会话2,被会话1阻塞住了，不会返回任何记录
-
select *
-
from t
エグゼクティブは、トランザクションをコミット提出するセッション1では、セッションはすぐに2つのレコードが返されます。
今程度の交換の二つのセッションの実行順序：
-
--会话1
-
set implicit_transactions
on
--打开了隐式事务
-
-
select *
-
from t
-
-
set implicit_transactions
off
-
-
select @@TRANCOUNT
--输入：1，说明这个会话中的事务也没有提交
-
--会话2，会话2没有被会话1阻塞，
-
--之所以这样是因为会话的默认隔离级别是read committed，
-
--会话1中的事务虽然没有提交，但是select语句在这种隔离级别下，
-
--运行完就会释放占用的S共享锁，所以不会阻塞写操作
-
update t
-
set v =
'ext'
2、最も古いアクティブなトランザクションデータベースを示します
-
/*==============================================================
-
如果事务在数据库中始终打开，有可能会阻塞其他进程的操作,
-
为什么是有可能而不是一定呢，
-
原因就是：在默认隔离级别下的select语句查询到数据后就会立即释放共享锁。
-
另外，日志备份也只会截断不活动事务的那部分日志，所以活动的事务
-
会导致日志数据越来越多。
-
-
为了找到没有提交的事务，可以用下面的命令显示某个数据库最早的活动事务.
-
-
不过有个例外，就是下面的命令不会返回：不占用锁资源的未提交事务
-
================================================================*/
-
-
begin tran
--开始显示事务
-
-
select *
-
from t
--运行后立即释放共享锁
-
-
select @@TRANCOUNT
--输入：1，说明没有提交事务
-
-
dbcc opentran(
'wc')
--显示数据库最早的活动事务，
-
--但是这儿显示"没有处于打开状态的活动事务"
3、クエリのトランザクション情報へのセッションを介して
-
--由于上面未提交事务中的select语句在默认的隔离级别下执行后自动释放了共享锁，
-
--所以dbcc opentran命令并没有返回这个活动事务，
-
--不过下面的视图解决了这个问题，可以找到所有活动事务。
-
-
-
--找到活动事务
-
select session_id,
--session_id与transaction_id的对应关系
-
transaction_id,
-
is_user_transaction,
-
is_local
-
from sys.dm_tran_session_transactions
--会话中的事务，识别所有打开的事务
-
where is_user_transaction =
1
-
-
-
--找到活动事务对应的执行语句
-
select c.session_id,
--session_id与connection_id的对应关系
-
c.connection_id,
-
c.most_recent_sql_handle,
-
s.text
-
from sys.dm_exec_connections c
--执行连接，最近执行的查询信息
-
cross
apply sys.dm_exec_sql_text(c.most_recent_sql_handle) s
-
where c.session_id =
361
-
-
-
--活动事务的具体信息
-
select t.transaction_id,
-
t.name,
--这里显示user_transaction
-
t.transaction_begin_time,
-
-
case t.transaction_type
--事务类型
-
when
1
then
'读/写事务'
-
when
2
then
'只读事务'
-
when
3
then
'系统事务'
-
when
4
then
'分布式事务'
-
end
'transaction type',
-
-
case t.transaction_state
-
when
0
then
'事务尚未完全初始化'
-
when
1
then
'事务已初始化但尚未启动'
-
when
2
then
'事务处于活动状态'
-
when
3
then
'事务已结束。该状态用于只读事务'
-
when
4
then
'已对分布式事务启动提交进程'
-
when
5
then
'事务处于准备就绪状态且等待解析'
-
when
6
then
'事务已提交'
-
when
7
then
'事务正在被回滚'
-
when
8
then
'事务已回滚'
-
end
'transaction state'
-
from sys.dm_tran_active_transactions t
--活动的事务
-
where transaction_id =
150764485
