步四:在另一个会话中去Truncate表
SQL> truncate table jj_2;
表被截断。
----等待第一个会话中的执行完毕----
步五:把执行结果输送到文件中
SQL> spool off;
查看aa.txt 发现 循环次数 锁状态
--------------- -------------
1--205 显示为9 无
206--375 显示为6 传说中的6-X锁
376--结束 一直为9 6 锁已经释放
*****以上结果我是在10G中做的实验,同样的我又在9i中试了试,发现略有不同*****
结果如下:
1--93 显示为9
94--126 显示为6
127--217 显示为2
218--249 显示为3
250--266 显示为6
267--结束 一直为9
小结:在10G中只加了6锁,而9i中是236混杂出现,看来10G的截断操作比9i要简单明了,从算法上进步了不少哟~~ !^_^!
另附： drop table 在10G中 为 6锁，9i中是6 3 混合
create table 在10G中 为 3锁，
create index 在10G中 为 4锁，表共享锁，根据兼容矩阵表示，4号锁和4号锁是相兼容的，但是我同时开两个会话创建索引，还是有等待，发现是library cache lock在等待。因为创建索引时，会在表上加独占的library cache lock。
create index on line 在10G中 为 2，4 锁 其中2锁时间较长。2锁只和6锁不兼容，其他都兼容。其中4锁时间较短，只占41次循环。证明连机创建索引对DML操作影响不大,处
了41次 4锁之外,大部分时间是可以执行DML的.
其他执行速度比较快的操作,查看锁步骤类似,可以用上例一样的方式实验...TX锁相关事务,放到后面回滚段相关章节再发... |