一、数据恢复一例
08年4月23日，一个值得“纪念”的日子。
晚上10点刚过抄起家当，准备回宿舍。由于要实施网上查询，一个同事H在本机导数据，本想到他机器上看看是否导完数据，但看到的桌面让我大吃一惊：
加Truncate参数，使用Oracle的Impdp在生产环境导数据！
立马打开查询窗口，查询相关的表，结果返回：no rows selected.数据已经全部清掉了。
一瞬间一下子就懵了：我Kao，搞什么鬼？怎么能把生产机的数据truncate掉？是不是脑子进水了？马上打电话给H，电话占线，Shit，再打，还是占线...... 急，先上洗手间，掏出手机，继续打，终于通了，第一句话：怎么在生产机上导数据？为什么动生产机的数据？
H给出的答复是由于刚才导网上查询数据时误操作把一张表的数据删掉了，没有把问题反馈上来，直接就想通过18：30左右的备份恢复该表，由于缺乏IMPDP的相关知识，以为导出文件有的表，在impdp的时候都必须制定，结果把其他十来各表都全部truncate。
出现问题没有反馈，掩盖问题试图自己解决，由于缺乏相关的知识，结果误操作导致更严重的后果。
由于有下班后的Expdp备份，本来是一张表的数据，而且该表数据在下班后不会变化，简单的通过impdp就可以恢复，结果用truncate选项把其他表统统清除掉，当时心里那个苦啊！
事已至此，没有办法，马上组织其他人手先通过备份恢复数据。
1.把大表和小表分开，大表先drop索引再导入，小表直接导入。
2.大表导入完毕后同步建立索引。
其他表都比较顺利，最后有两张表（大表A和中表B），死活导不进去。当时已经是凌晨0点10分左右。出现的现象是：
大表A导入了1.5个小时，没有任何反应，中表B导入时通过后台查询发现有其他进程lock该表，进程是ORACLE.EXE(DW01)。
再等了十分钟，还是如此，觉得不能这样坐以待毙，重启数据库，重写执行导入数据，还是如此。
大表A的导入没有任何异常情况，就是Hang着不动，这时候想到该表是复合分区表，如果改成普通表是否可以？通过rename原来的表，通过CTAS创建普通表，重新导入，It works！数据导入后，通过insert into as select导入到正式表，然后通过rename等操作把正式表恢复到正常的表名。
大表A导完后，发现中表B还是在等待ORACLE.EXEC(DW01)，本想着通过alter system kill session把相关的session kill掉，半个小时过去，没有kill掉，只是mark kill。这时候查询session时发现相关schema是XDB，把XDB用户account lock，再导入，还是如此。这时候已经凌晨一点，就剩下这张表，头都有点大了，再仔细分析session的信息，发现module是Data pump，不是Oracle的必须后台进程，同时想起几年前在windows平台可以用orakill杀掉windows线程，抱着试试的心态，用 orakill杀掉了ORACLE.EXE(DW01)的线程，然后用impdp尝试导入，God，It works！谢天谢地，总算，数据都恢复了，这时候是凌晨1：30.
索引都创建完毕后，再次一张一张表检查一次，确保数据和索引都存在。
最后执行dbms_stats.gather_table_stats过程对相关的表执行一遍信息，并设定定时任务对数据库进行备份。
大功告成，凌晨2：30，可以躺一下了......
环境:
Oracle10.2.0.3
Windows2003 64bit
Inter Xeon CPU 8X
相关的SQL脚本：
1.查询等待或给锁定的object脚本
SELECT /*+ rule */ lpad(‘ ‘,decode(l.xidusn ,0,3,0))||l.oracle_username User_name,
o.owner,o.object_name,o.object_type,s.sid,s.serial#
FROM v$locked_object l,dba_objects o,v$session s
WHERE l.object_id=o.object_id
AND l.session_id=s.sid
ORDER BY o.object_id,xidusn DESC
2.查询v$session，可获取MODULE等信息。
3.orakill的用法可通过orakill -help获取
c:>orakill -help
Usage: orakill sid thread
where sid = the Oracle instance to target
thread = the thread id of the thread to kill
The thread id should be retrieved from the spid column of a query such as:
select spid, osuser, s.program from
v$process p, v$session s where p.addr=s.paddr
在本例中用法为:
orakill prod 2203
晚上10点刚过抄起家当，准备回宿舍。由于要实施网上查询，一个同事H在本机导数据，本想到他机器上看看是否导完数据，但看到的桌面让我大吃一惊：
加Truncate参数，使用Oracle的Impdp在生产环境导数据！
立马打开查询窗口，查询相关的表，结果返回：no rows selected.数据已经全部清掉了。
一瞬间一下子就懵了：我Kao，搞什么鬼？怎么能把生产机的数据truncate掉？是不是脑子进水了？马上打电话给H，电话占线，Shit，再打，还是占线...... 急，先上洗手间，掏出手机，继续打，终于通了，第一句话：怎么在生产机上导数据？为什么动生产机的数据？
H给出的答复是由于刚才导网上查询数据时误操作把一张表的数据删掉了，没有把问题反馈上来，直接就想通过18：30左右的备份恢复该表，由于缺乏IMPDP的相关知识，以为导出文件有的表，在impdp的时候都必须制定，结果把其他十来各表都全部truncate。
出现问题没有反馈，掩盖问题试图自己解决，由于缺乏相关的知识，结果误操作导致更严重的后果。
由于有下班后的Expdp备份，本来是一张表的数据，而且该表数据在下班后不会变化，简单的通过impdp就可以恢复，结果用truncate选项把其他表统统清除掉，当时心里那个苦啊！
事已至此，没有办法，马上组织其他人手先通过备份恢复数据。
1.把大表和小表分开，大表先drop索引再导入，小表直接导入。
2.大表导入完毕后同步建立索引。
其他表都比较顺利，最后有两张表（大表A和中表B），死活导不进去。当时已经是凌晨0点10分左右。出现的现象是：
大表A导入了1.5个小时，没有任何反应，中表B导入时通过后台查询发现有其他进程lock该表，进程是ORACLE.EXE(DW01)。
再等了十分钟，还是如此，觉得不能这样坐以待毙，重启数据库，重写执行导入数据，还是如此。
大表A的导入没有任何异常情况，就是Hang着不动，这时候想到该表是复合分区表，如果改成普通表是否可以？通过rename原来的表，通过CTAS创建普通表，重新导入，It works！数据导入后，通过insert into as select导入到正式表，然后通过rename等操作把正式表恢复到正常的表名。
大表A导完后，发现中表B还是在等待ORACLE.EXEC(DW01)，本想着通过alter system kill session把相关的session kill掉，半个小时过去，没有kill掉，只是mark kill。这时候查询session时发现相关schema是XDB，把XDB用户account lock，再导入，还是如此。这时候已经凌晨一点，就剩下这张表，头都有点大了，再仔细分析session的信息，发现module是Data pump，不是Oracle的必须后台进程，同时想起几年前在windows平台可以用orakill杀掉windows线程，抱着试试的心态，用 orakill杀掉了ORACLE.EXE(DW01)的线程，然后用impdp尝试导入，God，It works！谢天谢地，总算，数据都恢复了，这时候是凌晨1：30.
索引都创建完毕后，再次一张一张表检查一次，确保数据和索引都存在。
最后执行dbms_stats.gather_table_stats过程对相关的表执行一遍信息，并设定定时任务对数据库进行备份。
大功告成，凌晨2：30，可以躺一下了......
环境:
Oracle10.2.0.3
Windows2003 64bit
Inter Xeon CPU 8X
相关的SQL脚本：
1.查询等待或给锁定的object脚本
SELECT /*+ rule */ lpad(‘ ‘,decode(l.xidusn ,0,3,0))||l.oracle_username User_name,
o.owner,o.object_name,o.object_type,s.sid,s.serial#
FROM v$locked_object l,dba_objects o,v$session s
WHERE l.object_id=o.object_id
AND l.session_id=s.sid
ORDER BY o.object_id,xidusn DESC
2.查询v$session，可获取MODULE等信息。
3.orakill的用法可通过orakill -help获取
c:>orakill -help
Usage: orakill sid thread
where sid = the Oracle instance to target
thread = the thread id of the thread to kill
The thread id should be retrieved from the spid column of a query such as:
select spid, osuser, s.program from
v$process p, v$session s where p.addr=s.paddr
在本例中用法为:
orakill prod 2203
二、临时表不能删除问题
今天创建了如下临时表
-- Create table
create global temporary table TEMPTABLE
(COL_A VARCHAR2(10),
COL_B VARCHAR2(10))
on commit preserve rows;
插入数据
insert into temptable(col_a,col_b)values('a','b');
insert into temptable(col_a,col_b)values('aa','ba');
然后
drop table temptable ;
提示
ORA-14452: 试图创建, 更改或删除正在使用的临时表中的索引
然后
truncate table temptable ;
drop table temptable ;
还是提示
ORA-14452: 试图创建, 更改或删除正在使用的临时表中的索引
使用sys登陆
SQL> Select object_id From all_objects Where object_name = 'TEMPTABLE';
OBJECT_ID
----------
30567
select * from v$lock where type='TO' and id2=1 and id1 = 30567;
ADDR KADDR SID TYPE ID1 ID2 LMODE REQUEST CTIME BLOCK
-------- -------- ---------- ---- ---------- ---------- ---------- ---------
682BDC58 682BDC68 12 TO 30567 1 3 0 2930 0
select sid,paddr,status from v$session where sid='12';
SID PADDR STATUS
---------- -------- --------
12 681E73BC INACTIVE
SQL> SELECT SPID FROM V$PROCESS WHERE ADDR='681E73BC';
SPID
------------
1720
在命令行
C:>orakill orcl 1720
Kill of thread id 1720 in instance orcl successfully signalled.
继续drop
DROP TABLE user.TEMPTABLE;
结果
DROP TABLE user.TEMPTABLE
ORA-14452: 试图创建, 更改或删除正在使用的临时表中的索引
-- Create table
create global temporary table TEMPTABLE
(COL_A VARCHAR2(10),
COL_B VARCHAR2(10))
on commit preserve rows;
插入数据
insert into temptable(col_a,col_b)values('a','b');
insert into temptable(col_a,col_b)values('aa','ba');
然后
drop table temptable ;
提示
ORA-14452: 试图创建, 更改或删除正在使用的临时表中的索引
然后
truncate table temptable ;
drop table temptable ;
还是提示
ORA-14452: 试图创建, 更改或删除正在使用的临时表中的索引
使用sys登陆
SQL> Select object_id From all_objects Where object_name = 'TEMPTABLE';
OBJECT_ID
----------
30567
select * from v$lock where type='TO' and id2=1 and id1 = 30567;
ADDR KADDR SID TYPE ID1 ID2 LMODE REQUEST CTIME BLOCK
-------- -------- ---------- ---- ---------- ---------- ---------- ---------
682BDC58 682BDC68 12 TO 30567 1 3 0 2930 0
select sid,paddr,status from v$session where sid='12';
SID PADDR STATUS
---------- -------- --------
12 681E73BC INACTIVE
SQL> SELECT SPID FROM V$PROCESS WHERE ADDR='681E73BC';
SPID
------------
1720
在命令行
C:>orakill orcl 1720
Kill of thread id 1720 in instance orcl successfully signalled.
继续drop
DROP TABLE user.TEMPTABLE;
结果
DROP TABLE user.TEMPTABLE
ORA-14452: 试图创建, 更改或删除正在使用的临时表中的索引
备注：会话临时表要在会话断开后临时表里面的数据才会被清除，如果会话不断开那么数据无法清除，会话状态为inactive，该会话虽然为inactive但没并有断开，所以临时表里面的数据删除不掉，oracle中的无效会在默认情况下是oracle在空闲的时候才会去清除的。
三、远程数据库无法释放dblink的连接(也是本地数据库的请求在远程数据库中长时间占用连接)
alter session close database link linkname;
假设现在客户端执行一个会话，执行完之后退出，但是在服务器端如果oracle没有空闲那么该会话进程还是存在的，因为在默认情况下oracle要在空闲的时候才会去清除无效的会话，那数据库什么时候有空呢，不知道所以可以在sqlnet.ora里面添加一个sqlnet.expire_time参数使无效会话在设定的时间内自动被清除，从而确保无效会话占用的连接被即时释放。
[@more@]
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/13879334/viewspace-1034912/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/13879334/viewspace-1034912/
扫一扫
4328
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
