首先再次明确下,数据库因为要同时保证数据的并发性和一致性,所以操作有锁等待是正常的. 只有那些长时间没有提交或回滚的事物,阻塞了其他业务正常操作,才是需要去定位处理的. 1.单实例环境 2.RAC环境 1. 单实例环境 实验环境:Oracle 10.2.0.5 单实例 会话1模拟业务操作: SQL> select sid from v$mystat where rownum=1; SID ---------- 144 SQL> show user USER is "JINGYU&qu…

Oracle数据库的锁类型 博客分类: oracle   Oracle数据库的锁类型 根据保护的对象不同,Oracle数据库锁可以分为以下几大类:DML锁(data   locks,数据锁),用于保护数据的完整性:DDL锁(dictionary   locks,字典锁),用于保护数据库对象的结构,如表.索引等的结构定义:内部锁和闩(internal   locks   and   latches),保护数据库的内部结构. DML锁的目的在于保证并发情况下的数据完整性,本文主要讨论DML锁.在Or…

锁表处理及查询 查看Oracle数据库被锁住的表,删除锁表的进程 1.查看被锁住的表 SELECT dob.object_name table_name,    lo.locked_mode, lo.session_id, vss.serial#, vss.action action, vss.osuser osuser, vss.logon_time, vss.process ap_pid, vps.spid db_pid FROM v$locked_object lo, dba_object…

数据的锁定分为两种方法,第一种叫做悲观锁,第二种叫做乐观锁.什么叫悲观锁呢,悲观锁顾名思义,就是对数据的冲突采取一种悲观的态度,也就是说假设数据肯定会冲突,所以在数据开始读取的时候就把数据锁定住.而乐观锁就是认为数据一般情况下不会造成冲突,所以在数据进行提交更新的时候,才会正式对数据的冲突与否进行检测,如果发现冲突了,则让用户返回错误的信息,让用户决定如何去做. 先从悲观锁开始说.在SqlServer等其余很多数据库中,数据的锁定通常采用页级锁的方式,也就是说对一张表内的数据是一种串行化的更新插…

一.查询哪些表被锁以及查看锁表得会话及操作系统进程ID 其中locked_mode为锁的级别,spid为数据库所在操作系统的进程id select c.sid, c.serial#, c.username, c.osuser, b.owner, b.object_name, a.locked_mode, p.spid from v$locked_object a, dba_objects b, v$session c, v$process p where a.object_id = b.obje…

所谓的锁等待:就是一个事务a对一个数据表进行ddl或是dml操作时,系统就会对该表加上表级的排它锁,此时其他的事务对该表进行操作的时候会等待a提交或是回滚后,才可以继续b的操作 所谓的死锁:当两个或多个用户相互等待锁定的数据时就会发生死锁,这时这些用户被卡在不能继续处理业务,oracle可以自动检测死锁并解决他们,通过回滚一个死锁中的语句,释放锁定的数据,回滚的话会遇到ora-00060 deadlock detected while waiting for resource 模拟锁等待: 两个…

前阵子有一个网友在群里问了一个关于Oracle数据库的TX锁问题,问题原文如下: 请教一个问题: 两个会话执行不同的delete语句,结果都是删除同一个行.先执行的会话里where条件不加索引走全表扫描,表很大,执行很慢:后执行的用where条件直接用rowid进行delete. Oracle的什么机制使第二个会话执行后一直是等待第一个会话结束的呢. 那么我们先动手实验一下,来看看这个问题吧,首先,我们需要一个数据量较大的表(数据量大,全表扫描时间长,方便构造实验效果), 这里实验测试的表为IN…

ORACLE体系结构包括:实例(Instance),数据库文件,用户进程(User process),服务器进程以及其他文件. 1.ORACLE实例(instance)     1).要访问数据库必须先启动实例,实例启动时先分配内存区,然后再启动后台进程,后他进程执行数据库的输入,输出以及监控其他进程.      在数据库启动的过程中 一下五个进程必须启动:         1.SMON(系统监控进程) 2.PMON(进程监控) 3.DBWR(数据库写进程) 4.LGWR(日志写进程) 5.CK…

问题背景: 有时会考虑一件事情,如果在Oracle环境下出现了锁阻塞的情况,如何定位到SQL源头(通过session.lock.transaction等视图仅能定位到会话)?或许有人会想有没有可能通过AWR相关的数据库性能历史视图找到有用的信息呢?答案是否定的,因为AWR仓库中的历史性能数据都是收集的有性能问题的会话.语句.活动,而最初加锁的那个update语句执行速度非常快,往往根本达不到AWR收集的阀值,不被Oracle注意到.而Oracle注意到的都是被“它”给阻塞的那些会话. 是不是没方…

在写 Oracle session相关数据字典(一)  这篇文章时,提到使用v$session视图的树形查询可以得到Oracle锁树,这样就便于我们找出阻塞会话的源头,但是仅仅可以在单机环境中使用.今天把单机和RAC的阻塞树都整理了一下,话不多说,直接开干,奥利给. (一)单机的阻塞会话树 单机的不再测试,直接搬以前的记录.EM里面的Blocking session里面看到下图,以折叠图的形式展现,最上面的代表正在阻塞其它session的会话,研究了一下,可以使用v$session来得到类似的效…