最近在工作中同事们经常遇到锁表、误删表和程序覆盖的情况,现总结下遇到这三种情况的解决方案:
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/
其实这两种方法本质上是一样的,具体就看个人喜好了。