oracle执行drop慢,drop表空间缓慢 - Oracle专题深入讨论 - ITPUB论坛－中国专业的IT技术社区...

最新推荐文章于 2021-10-29 09:37:34 发布
最新推荐文章于 2021-10-29 09:37:34 发布
阅读量606 收藏
点赞数
文章标签： oracle执行drop慢

不好意思。最近几天都比较忙，现在继续研究。

我试过单独对tab$的索引重新收集统计信息，还是不行，对tab$才能解决问题。

有问题的语句如下：

select u.name, o.name

from

obj$ o,user$ u, tab$ t,   (select obj# objnum# from tab$    where ts#=:1 and

bitand(property,64+512+8192)=0 and          bitand(flags,536870912)

=0 union all    select distinct t.obj# objnum# from tabpart$ tp,tab$ t

where tp.ts#=:1 and          t.obj#=tp.bo# and          bitand(t.property,

64+512+8192)=0 and          bitand(t.flags,536870912)=0 union all    select

distinct t.obj# objnum# from tabcompart$ tcp,tabsubpart$ tsp,tab$ t

where tsp.ts#=:1 and          tsp.pobj#=tcp.obj# and t.obj#=tcp.bo# and

bitand(t.property,64+512+8192)=0 and          bitand(t.flags,536870912)

=0 union all    select t.obj# objnum# from ind$ i,tab$ t    where i.ts#=:1

and i.type#=4 and          t.obj#=i.bo# and bitand(t.property,8192)=0 union

all    select distinct t.obj# objnum# from indpart$ ip,ind$ i,tab$ t

where ip.ts#=:1 and i.type#=4 and          i.obj#=ip.bo# and

t.obj#=i.bo# and bitand(t.property,8192)=0 union all    select distinct

t.obj# objnum#    from indcompart$ icp,indsubpart$ isp,ind$ i,tab$ t

where isp.ts#=:1 and i.type#=4 and          isp.pobj#=icp.obj# and i.obj#=

icp.bo# and          t.obj#=i.bo# and bitand(t.property,8192)=0  ) tin

where tin.objnum# = o.obj# and o.owner# = u.user# and t.obj#=o.obj#  order

by bitand(t.property,4294967296) desc, tin.objnum# desc

在我数据库sql_id为7jrp85khm4tka，根据这个sql_id抓取了该sql执行时候的绑定变量，如下：

SYS@proc> select hash_value,sql_id,NAME,POSITION,DATATYPE_STRING,LAST_CAPTURED,value_string FROM v$sql_bind_capture where sql_id='7jrp85khm4tka';

HASH_VALUE SQL_ID         NAME                                                                POSITION DATATYPE_STRING                LAST_CAPT VALUE_STRING

---------- ------------- ------------------------------------------------------------ ---------- ------------------------------ --------- --------------------------------------------------

2704434762 7jrp85khm4tka :1                                                                       1 NUMBER                         11-DEC-16 9

2704434762 7jrp85khm4tka :1                                                                       2 NUMBER                         11-DEC-16 9

2704434762 7jrp85khm4tka :1                                                                       3 NUMBER                         11-DEC-16 9

2704434762 7jrp85khm4tka :1                                                                       4 NUMBER                         11-DEC-16 9

2704434762 7jrp85khm4tka :1                                                                       5 NUMBER                         11-DEC-16 9

2704434762 7jrp85khm4tka :1                                                                       6 NUMBER                         11-DEC-16 9

发现绑定变量的值都是9，不知道有没有问题。

另外，附上执行计划。

select * from table(dbms_xplan.display_cursor('7jrp85khm4tka'));

PLAN_TABLE_OUTPUT

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

SQL_ID        7jrp85khm4tka, child number 0

-------------------------------------

select u.name, o.name from obj$ o,user$ u, tab$ t,   (select obj#

objnum# from tab$    where ts#=:1 and

bitand(property,64+512+8192)=0 and            bitand(flags,536870912)=0

union all    select distinct t.obj# objnum# from tabpart$ tp,tab$ t

where tp.ts#=:1 and             t.obj#=tp.bo# and

bitand(t.property,64+512+8192)=0 and

bitand(t.flags,536870912)=0 union all         select distinct t.obj# objnum#

from tabcompart$ tcp,tabsubpart$ tsp,tab$ t    where tsp.ts#=:1 and

tsp.pobj#=tcp.obj# and t.obj#=tcp.bo# and

bitand(t.property,64+512+8192)=0 and

bitand(t.flags,536870912)=0 union all         select t.obj# objnum# from

ind$ i,tab$ t         where i.ts#=:1 and i.type#=4 and           t.obj#=i.bo#

and bitand(t.property,8192)=0 union all    select distinct t.obj#

objnum# from indpart$ ip,ind$ i,tab$ t          where ip.ts#=:1 and i.type#=4

and             i.obj#=ip.bo# and                t.obj#=i.bo# and

bitand(t.property,8192)=0 union all    select distinct t.obj# o

Plan hash value: 3413565305

--------------------------------------------------------------------------------------------------------------------

| Id  | Operation                               | Name                           | Rows  | Bytes | Cost (%CPU)| Time           |

--------------------------------------------------------------------------------------------------------------------

|   0 | SELECT STATEMENT                       |                           |           |           |   194 (100)|           |

|   1 |  SORT ORDER BY                               |                           |        32 |  2176 |   194   (4)| 00:00:03 |

|*  2 |   HASH JOIN                               |                           |        32 |  2176 |   193   (3)| 00:00:03 |

|   3 |    NESTED LOOPS                        |                           |        32 |  1632 |   190   (3)| 00:00:03 |

|   4 |     NESTED LOOPS                       |                           |   945 | 35910 |   158   (4)| 00:00:02 |

|   5 |      INDEX FAST FULL SCAN               | I_OBJ2                    | 86965 |  2802K|   153   (0)| 00:00:02 |

|   6 |      VIEW                               |                           |         1 |         5 |         0   (0)|           |

|   7 |       UNION-ALL PARTITION               |                           |           |           |                |           |

|*  8 |        TABLE ACCESS CLUSTER               | TAB$                           |         1 |        22 |         2   (0)| 00:00:01 |

|*  9 |         INDEX UNIQUE SCAN               | I_OBJ#                    |         1 |           |         1   (0)| 00:00:01 |

|  10 |        SORT UNIQUE                       |                           |         1 |        27 |         4  (25)| 00:00:01 |

|  11 |         NESTED LOOPS                       |                           |         1 |        27 |         3   (0)| 00:00:01 |

|* 12 |          TABLE ACCESS BY INDEX ROWID   | TABPART$                   |         1 |         8 |         2   (0)| 00:00:01 |

|* 13 |           INDEX RANGE SCAN               | I_TABPART_BOPART$           |         2 |           |         1   (0)| 00:00:01 |

|* 14 |          TABLE ACCESS CLUSTER               | TAB$                           |         1 |        19 |         1   (0)| 00:00:01 |

|* 15 |           INDEX UNIQUE SCAN               | I_OBJ#                    |         1 |           |         0   (0)|           |

|  16 |        SORT UNIQUE                       |                           |         1 |        34 |         6  (17)| 00:00:01 |

|* 17 |         HASH JOIN                       |                           |        29 |   986 |         5   (0)| 00:00:01 |

|  18 |          NESTED LOOPS                       |                           |         1 |        27 |         3   (0)| 00:00:01 |

|* 19 |           TABLE ACCESS FULL               | TABCOMPART$                   |         1 |         8 |         2   (0)| 00:00:01 |

|* 20 |           TABLE ACCESS CLUSTER               | TAB$                           |         1 |        19 |         1   (0)| 00:00:01 |

|* 21 |            INDEX UNIQUE SCAN               | I_OBJ#                    |         1 |           |         0   (0)|           |

|* 22 |          TABLE ACCESS FULL               | TABSUBPART$                   |        32 |   224 |         2   (0)| 00:00:01 |

|  23 |        NESTED LOOPS                       |                           |         1 |        24 |         3   (0)| 00:00:01 |

|* 24 |         TABLE ACCESS CLUSTER               | TAB$                           |         1 |        13 |         2   (0)| 00:00:01 |

|* 25 |          INDEX UNIQUE SCAN               | I_OBJ#                    |         1 |           |         1   (0)| 00:00:01 |

|* 26 |         TABLE ACCESS CLUSTER               | IND$                           |         1 |        11 |         1   (0)| 00:00:01 |

|  27 |        SORT UNIQUE                       |                           |         1 |        34 |         6  (17)| 00:00:01 |

|  28 |         NESTED LOOPS                       |                           |         1 |        34 |         5   (0)| 00:00:01 |

|  29 |          NESTED LOOPS                       |                           |         3 |        34 |         5   (0)| 00:00:01 |

|  30 |           NESTED LOOPS                       |                           |         1 |        26 |         3   (0)| 00:00:01 |

|* 31 |            TABLE ACCESS CLUSTER        | TAB$                           |         1 |        13 |         2   (0)| 00:00:01 |

|* 32 |             INDEX UNIQUE SCAN               | I_OBJ#                    |         1 |           |         1   (0)| 00:00:01 |

|* 33 |            TABLE ACCESS CLUSTER        | IND$                           |         1 |        13 |         1   (0)| 00:00:01 |

|* 34 |           INDEX RANGE SCAN               | I_INDPART_BOPART$           |         3 |           |         1   (0)| 00:00:01 |

|* 35 |          TABLE ACCESS BY INDEX ROWID   | INDPART$                   |         2 |        16 |         2   (0)| 00:00:01 |

|  36 |        SORT UNIQUE                       |                           |         1 |        78 |         4  (25)| 00:00:01 |

|  37 |         NESTED LOOPS                       |                           |         1 |        78 |         3   (0)| 00:00:01 |

|  38 |          NESTED LOOPS                       |                           |         1 |        78 |         3   (0)| 00:00:01 |

|  39 |           MERGE JOIN CARTESIAN               |                           |         1 |        65 |         3   (0)| 00:00:01 |

|  40 |            NESTED LOOPS                |                           |         1 |        52 |         2   (0)| 00:00:01 |

|  41 |             NESTED LOOPS               |                           |         1 |        52 |         2   (0)| 00:00:01 |

|  42 |              TABLE ACCESS FULL               | INDCOMPART$                   |         1 |        26 |         2   (0)| 00:00:01 |

|* 43 |              INDEX RANGE SCAN               | I_INDSUBPART_POBJSUBPART$ |         1 |           |         0   (0)|           |

|* 44 |             TABLE ACCESS BY INDEX ROWID| INDSUBPART$                   |         1 |        26 |         0   (0)|           |

|  45 |            BUFFER SORT                       |                           |         1 |        13 |         3   (0)| 00:00:01 |

|* 46 |             TABLE ACCESS CLUSTER       | TAB$                           |         1 |        13 |         1   (0)| 00:00:01 |

|* 47 |              INDEX UNIQUE SCAN               | I_OBJ#                    |         1 |           |         0   (0)|           |

|* 48 |           INDEX UNIQUE SCAN               | I_IND1                    |         1 |           |         0   (0)|           |

|* 49 |          TABLE ACCESS BY INDEX ROWID   | IND$                           |         1 |        13 |         0   (0)|           |

|  50 |     TABLE ACCESS CLUSTER               | TAB$                           |         1 |        13 |         1   (0)| 00:00:01 |

|* 51 |      INDEX UNIQUE SCAN                       | I_OBJ#                    |         1 |           |         0   (0)|           |

|  52 |    TABLE ACCESS FULL                       | USER$                           |        92 |  1564 |         3   (0)| 00:00:01 |

--------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - access("O"."OWNER#"="U"."USER#")

8 - filter(("TS#"=:1 AND BITAND("PROPERTY",8768)=0 AND BITAND("FLAGS",536870912)=0))

9 - access("OBJ#"="O"."OBJ#")

12 - filter("TP"."TS#"=:1)

13 - access("TP"."BO#"="O"."OBJ#")

14 - filter((BITAND("T"."PROPERTY",8768)=0 AND BITAND("T"."FLAGS",536870912)=0))

15 - access("T"."OBJ#"="TP"."BO#")

filter("T"."OBJ#"="O"."OBJ#")

17 - access("TSP"."POBJ#"="TCP"."OBJ#")

19 - filter("TCP"."BO#"="O"."OBJ#")

20 - filter((BITAND("T"."PROPERTY",8768)=0 AND BITAND("T"."FLAGS",536870912)=0))

21 - access("T"."OBJ#"="TCP"."BO#")

filter("T"."OBJ#"="O"."OBJ#")

22 - filter("TSP"."TS#"=:1)

24 - filter(BITAND("T"."PROPERTY",8192)=0)

25 - access("T"."OBJ#"="O"."OBJ#")

26 - filter(("I"."BO#"="O"."OBJ#" AND "I"."TYPE#"=4 AND "I"."TS#"=:1 AND "T"."OBJ#"="I"."BO#"))

31 - filter(BITAND("T"."PROPERTY",8192)=0)

32 - access("T"."OBJ#"="O"."OBJ#")

33 - filter(("I"."BO#"="O"."OBJ#" AND "I"."TYPE#"=4 AND "T"."OBJ#"="I"."BO#"))

34 - access("I"."OBJ#"="IP"."BO#")

35 - filter("IP"."TS#"=:1)

43 - access("ISP"."POBJ#"="ICP"."OBJ#")

44 - filter("ISP"."TS#"=:1)

46 - filter(BITAND("T"."PROPERTY",8192)=0)

47 - access("T"."OBJ#"="O"."OBJ#")

48 - access("I"."OBJ#"="ICP"."BO#")

49 - filter(("I"."BO#"="O"."OBJ#" AND "I"."TYPE#"=4 AND "T"."OBJ#"="I"."BO#"))

51 - access("T"."OBJ#"="O"."OBJ#")

UI似
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Oracle drop table
wcacer的博客
10-20 7347
1 drop table时，相关约束被删除 如图，经过drop table操作后已找不到相关的constraint 2 drop table时，对相关对象的影响 如图，index是在tb1上建立的，view和synonym也是基于tb1建立的 （注意这里因为tb1是从recylebin里flashback回来的，因此index的命名由系统自动命名为这种形式） ...
oracle执行drop慢,在线急等：drop table 非常慢 - Oracle数据库管理 - Oracle数据库数据恢复、性能优化来问问AskMaclean - ParnassusData诗檀...
weixin_39792475的博客
04-03 943
aixoracle 10.2.0.4drop一张表大概需要5s左右生成10046trace文件的问题sqlPARSING IN CURSOR #6 len=577 dep=1 uid=0 oct=3 lid=0 tim=39332565415208 hv=3360872067 ad='aaf1cad8'select u2.name, o2.name from ind$ i, obj$ o1, ob...
oracle执行drop慢,Oracle性能优化:drop table与db cache
weixin_34521244的博客
04-03 1442
【IT168 技术文档】我们都知道drop table, truncate table时都会先做一次checkpoint，将被删除对象的脏块写入磁盘。客户有一套系统，Oracle 9.2.0.8，需要做数据迁移，由于种种原因，采用的是逻辑迁移的方式。由于库比较大，超过了1.5T，而停机时间又有限，因此在正式迁移之前需要做大量的测试，测试的目的，一方面是看迁移流程上是否存在问题，另一方面是看迁移的时...
Oracle删除表空间很慢,Oracle表删除大量数据(千万)后查询变慢问题
weixin_32571965的博客
04-05 946
Oracle分析表是Oracle数据库管理的重要部分，下面就为您详细介绍Oracle分析表方面的知识，希望对您学习Oracle分析表方面能有所帮助。1、分析SQL:analyze table tablename compute statistics等同于 analyze table tablename compute statistics for table for all indexes for...
oracle删除表不等待,急, drop tablespace 一直等待 。。。
weixin_39788572的博客
04-03 621
上个星期直接DROP也是一样的,而且删除这个表空间里的表对象的时候也非常的慢select * from v$session_wait;1 7 3400 latch free address 1.38350580556225E19 C00000001448E428 number 66 ...
【重庆思庄oracle数据库分享】-执行DROP USER ... CASCADE操作删除很慢
duanweifang的博客
10-29 956
在删除用户及其对象时使用命令： drop user XXX cascade; 操作执行很慢，要删除很久 原因是：如果目标用户有太多表等对象的话，执行可能会非常慢。 作为临时处理方法可以先删除目标用户Schema中的所有对象，然后删除用户。 1.通过如下SQL列出目标用户所有对象的删除语句脚本（drop.sql） SQL> set pages 0 SQL> spool drop.sql SQL> select 'drop ’ || object_type || ’ ’ || owner ||
oracle+drop慢,处理链里Drop Index非常慢,请问是什么原因造成的?
weixin_42508903的博客
04-13 371
各位大侠好:在生产系统下的处理链里,相关CUBE的删除索引这个步骤非常慢.一般10分钟,有时候会达到1个半小时.CUBE的维度有16个(包含T P U) 请求也很多 922 个　基本ＣＵＢＥ摘取部分ＬＯＧ2010.01.30 01:20:40 DROP INDEX "ＣＵＢＥ－ＮＡＭＥ"2010.01.30 01:21:07 SQL-END: 2010.01.30 01:21:07 00:00:2...
oracle drop column 多个,3000W记录，alter table drop column很慢
weixin_42314192的博客
04-05 492
最初由 yzm2008 发布[B]Alter table T set unused(COLUMN)和 drop column有什么区别吗？ [/B]SET UNUSED ClauseSpecify SET UNUSED to mark one or more columns as unused. Specifying this clause does not actually remove the...
oracle-产品介绍.ppt
最新发布
11-21
对于用户来说，Oracle还拥有丰富的社区资源，如Itpub这样的专业论坛，以及Oracle官方文档和在线资源，为用户提供技术支持和学习资料。 总之，Oracle作为业界领先的关系型数据库管理系统，凭借其强大的功能、持续的...
Oracle 12c新特性--ASMFD（ASM Filter Driver）特性_ITPUB博客.mhtml
08-19
Oracle 12c新特性--ASMFD（ASM Filter Driver）特性
Oracle表删除大量数据(千万)后查询变慢问题(原因分析)
10-12
Oracle表删除大量数据(千万)后查询变慢问题(原因分析)
处理Oracle数据库中一张有效的Drop大表
03-03
本文中通过详细步骤来讲解Oracle数据库中有效的Drop表。
Oracle数据库创建表空间和用户.doc
04-22
在Oracle数据库管理中，创建表空间和用户是基础但至关重要的操作，这直接影响到数据库的性能、安全性和数据管理效率。以下将详细解析如何在Oracle数据库中创建表空间和用户，以及这一过程中涉及的关键概念和步骤。 ...
2008-2009中国IT应用技术蓝皮书(网络版).part2.rar
01-15
2008-2009中国IT应用技术蓝皮书(网络版) PDF格式 文件超过20M了 没办法，只能压成2个包 这个是part2 上传的时候没看到作者的版权声明 现在不知道怎么从这里撤下来 推荐大家到www.itpub.net上去下载（她论坛...
Oracle 18C新特性之PDB snapshot Carousel--PDB快照轮播_ITPUB博客.mhtml
08-19
Oracle 18C新特性之PDB snapshot Carousel--PDB快照轮播_ITPUB博客.mhtml
drop 很慢 物化视图_物化视图定义不当引发Oracle性能问题
weixin_39596720的博客
12-19 229
最近在实施一个大型BI项目，其中KPI指标数据是按月存放的，但用户要求每天进行一次计算，并替换前一天的计算结果，直到月末不再更新为止。项目初期Oracle数据库一直性能稳定，但最近两周性能突然大幅下降。经检查，服务器的CPU和内存都很正常，但磁盘IO奇高。优化SQL相关表索引无效，收缩数据文件也无效，最后发现会话中有很多耗时的Oracle(JXX)进程，执行：select * from dba_j...
drop 很慢 物化视图_【ORACLE】导致物化视图快速刷新变慢的原因和解决
weixin_39661405的博客
12-19 1109
ORACLE物化视图(MATERIALIZED VIEW)有自动提交刷新和手动刷新两种刷新方式，每种刷新方式下有增量刷新(FAST)、全量刷新(COMPLETE)、系统自动判断(FORCE)三种刷新方法。一般而言，增量刷新理论上是比全量刷新要快一些的，但是我发现某些情况下增量刷新将导致基表提交后延迟严重，下面将做一些测试。测试环境操作系统：Red Hat Enterprise Linux Serv...
ORACLE11.2.0.3数据库alter table drop column慢原因分析
weixin_38169722的博客
12-04 604
中午某生产库数据库发布补丁，开发人员反应有语句阻塞，无法执行下面语句 alter table pyramid.pd_loanProduct drop column customerType; 这是一个只有4行的小表 我建个测试表尝试了一下，果然很慢 create table pyramid.test_alter2(id number,name varchar2(10)) ...
Oracle drop 临时表空间时长时间没反应
贤时间
04-30 1081
修改Oracle 默认临时表空间时，要drop一个临时表空间，长时间没反应，应该是有会话占用这个临时表空间，需要手动 alter session kill 掉。 用如下命令查询： select srt.tablespace, srt.segfile#, srt.segblk#, srt.blocks, a.sid, a.serial#, a.sql_id, a.username, a.osus.
Oracle诊断事件深入解析：10053事件详解
"Oracle诊断事件及深入解析10053事件的PDF文档，来源于ITPub网站，由wanghai和liyongdong发表，vongates整理。文档主要讨论了Oracle中的诊断事件，特别是10053事件的解析，以及如何利用诊断事件进行问题排查和性能...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值