最近在工作中同事们经常遇到锁表、误删表和程序覆盖的情况，现总结下遇到这三种情况的解决方案：
1.暴力删除锁表
当表被某些语句占用无法停止，或者出现事物阻塞的情况下，需要手动删除锁（万不得已的情况下用）：
--首先查询锁（需要管理员权限）
SELECT OBJECT_NAME AS 对象名称,
S.SID,
S.SERIAL#,
P.SPID AS 系统进程号,
S.MACHINE
FROM V$LOCKED_OBJECT L, DBA_OBJECTS O, V$SESSION S, V$PROCESS P
WHERE L.OBJECT_ID = O.OBJECT_ID
AND L.SESSION_ID = S.SID
AND S.PADDR = P.ADDR
AND OBJECT_NAME = 'T1';--表名要大写
若出现结果：
则T1表是锁定的。
强制删除锁的语句是（需要管理员权限）：
alter system kill session 'SID,SERIAL#';
在这里也就是：alter system kill session '133,37';
执行完后，再运行上述查询sql，发现锁已经不存在了。
2.找回误删表
假如T1表被我删了：DROP TABLE T1;
那么找回的语句是：FLASHBACK TABLE t1 TO BEFORE DROP;
因为“drop talbe 表名” 这句话并没有完全删除表，通过语句：
SELECT t.object_name,t.type ,t.original_name FROM user_recyclebin t;
可以查询到刚刚被删的表：
T1表是从这里被找回的。如果是这样删表的话：
DROP TALBE T1 PURGE;
那就悲剧了，上述语句失效！具体可以参考这篇文章：http://www.cnblogs.com/HondaHsu/archive/2012/09/28/2707487.html
3.找回覆盖程序
需要管理员权限
法一：
根据时间点查询程序信息：
SELECT * FROM source$
AS OF TIMESTAMP TO_TIMESTAMP('2015-7-22 09:25:32', 'YYYY-MM-DD HH24:MI:SS')
where source like '%CREATE_ODS_INDEXES%'
根据类型查找出程序代码：
--包头
SELECT *
FROM DBA_SOURCE AS OF TIMESTAMP TO_TIMESTAMP('2015-7-22 09:25:32', 'YYYY-MM-DD HH24:MI:SS')
WHERE NAME LIKE UPPER('%CREATE_ODS_INDEXES%')
AND OWNER = 'SCOTT'
AND TYPE = 'PACKAGE'
ORDER BY LINE;
结果：
--包体
SELECT *
FROM DBA_SOURCE AS OF TIMESTAMP TO_TIMESTAMP('2015-7-22 09:25:32', 'YYYY-MM-DD HH24:MI:SS')
WHERE NAME LIKE UPPER('%CREATE_ODS_INDEXES%')
AND OWNER = 'SCOTT'
AND TYPE = 'PACKAGE BODY'
ORDER BY LINE;
结果：
具体参考：http://blog.sina.com.cn/s/blog_6d6e54f701012mp5.html
法二：
根据时间点查询程序信息：
SELECT OBJ#
FROM OBJ$ AS OF TIMESTAMP TO_TIMESTAMP('2015-7-22 09:25:32', 'YYYY-MM-DD HH24:MI:SS')
WHERE NAME = UPPER('CREATE_ODS_INDEXES');
结果：
找回包头和包体：
--查询出来的为包头
SELECT SOURCE FROM SOURCE$ AS OF TIMESTAMP TO_TIMESTAMP('2015-7-22 09:25:32', 'YYYY-MM-DD HH24:MI:SS') WHERE OBJ# = 76005;
--查询出来的为包体
SELECT SOURCE FROM SOURCE$ AS OF TIMESTAMP TO_TIMESTAMP('2015-7-22 09:25:32', 'YYYY-MM-DD HH24:MI:SS') WHERE OBJ# = 76006;
具体参考：http://blog.itpub.net/35489/viewspace-761921/
其实这两种方法本质上是一样的，具体就看个人喜好了。