oracle数据库锁表怎么解决？首先你要知道表锁住了是不是正常锁？因为任何DML语句都会对表加锁。你要先查一下是那个会话那个sql锁住了表，有可能这是正常业务需求，不建议随便KILLsession，如果这个锁表是正常业务你把sessionkill掉了会影响业务的。建议先查原因再做决定。(1)锁表查询的代码有以下的形式：selectcount(*)fromv$locked_objectselect*fromv$locked_object(2)查看哪个表被锁selectb.owner，b.object_name，a.session_id，a.locked_modefromv$locked_objecta，dba_objectsbwhereb.object_id=a.object_id(3)查看是哪个session引起的selectb.username，b.sid，b.serial#，logon_timefromv$locked_objecta，v$sessionbwherea.session_id=b.sidorderbyb.logon_time(4)查看是哪个sql引起的selectb.username，b.sid，b.serial#，c.*fromv$locked_objecta，v$sessionb，v$sqlcwherea.session_id=b.sidandb.SQL_ID=c.sql_idandc.sql_id=""orderbyb.logon_time(5)杀掉对应进程执行命令：altersystemkillsession"1025，41"其中1025为sid，41为serial#.
锁只会对DML语句产生影响，普通的查询是不会受到影响的，不过如果你的查询后面添加了forupdate，就会被影响了
oracle数据库能查到哪个人删了表吗，会不会记录电脑ip或者其它什么？多用户操作的影响主要是回锁定记录，oracle数据库提供行级锁，也就是说用户操作数据时，oracle为记录行加锁，当然如果用户一次性操作的数据过多，oracle的锁资源过大，或者锁定数据长时间没有释放（例如几百万条记录更新移植没有提交）。oracle的资源不够，回升级为表锁。至于性能，仍然跟锁定的资源大小有关系。多用户操作的解决方法：一次更新量不要太大，记得及时提交结果，养成sql语句后面立即commit或者rollback的习惯。（我们以前有个非常搞笑的同时，数据处理报错先在前台页面弹窗提示，等操作人员点了确认才提交或者回滚，结果操作人员一看见弹窗就打电话咨询去了，事务几个小时都没提交）多人操作表是有加锁的也就是表是共享的行是独占的你正在操作的行别人只能查不能一起做修改的操作你commit或rollback之后就会释放锁别人就可以操作了.oracle并发可以解决这个问题，只要在增、删、改时记得及时commit或rollback就行了.2.两个用户同时对一个表进行增加操作，是不是要等一个增加完之后另一个才可以执行增加操作啊？一个用户加数据，如果加完数据立即做事务处理，另一个用户就不用太久等待，甚至可能没有感觉，再如果一个用户加数据加锁后不做事务处理，那另一个用户就会一直等待，直到第一个用户commit后才可以执行第二个用户的操作.１oracle的数据模式是：用户建在表空间上，表建在用户上２一个用户的表就象自己的私有财产一样，没有自己或管理员授权别的用户是不能查询或修改的；３对于不同用户下的同名表，都是独立的数据对象，如user1.table1和user2.table1是相互独立的，用户分别操作自己的表是不影响其他用户的；４对于同一用户下的同一个表，所有有权限的用户对其进行数据操作时，是会相互影响的，如对user1.table1来说，user1修改了它的一行，user２又对该表的该行进行了修改，那么该表的该行的实际内容是在user１修改后基础上user2修改的结果（注意，所有修改以最后成功提交修改请求的用户的内容为准），多个用户对同一个用户下的同一个表的同时修改和锁定会造成锁等待
查看oracle是否锁表？查看哪个表被锁
selectb.owner，b.object_name，a.session_id，a.locked_mode
fromv$locked_objecta，dba_objectsb
whereb.object_id=a.object_id
查看是哪个session引起的
selectb.username，b.sid，b.serial#，logon_time
fromv$locked_objecta，v$sessionb
wherea.session_id=b.sidorderbyb.logon_time