查询dba_segmetns 异常慢，在11g 某个库里。

Encountering Slow Performance Reading *_SEGMENTS or *_TS_QUOTAS (文档 ID 1491748.1) 转到底部转到底部

In this Document
Symptoms
Changes
Cause
Solution
References

APPLIES TO:
Oracle Database - Standard Edition - Version 10.2.0.5 to 12.1.0.1 [Release 10.2 to 12.1]
Oracle Database - Personal Edition - Version 10.2.0.5 to 12.1.0.1 [Release 10.2 to 12.1]
Oracle Database - Enterprise Edition - Version 10.2.0.5 to 12.1.0.1 [Release 10.2 to 12.1]
Oracle Database Cloud Schema Service - Version N/A and later
Oracle Database Exadata Cloud Machine - Version N/A and later
Information in this document applies to any platform.
View affected include: DBA_SEGMENTS, USER_SEGMENTS, DBA_TS_QUOTAS, USER_TS_QUOTAS
SYMPTOMS
Queries on DBA_SEGMENTS or USER_SEGMENTS involving the columns BYTES, BLOCKS, or EXTENTS are very slow.
Queries on DBA_TS_QUOTAS or USER_TS_QUOTES on columns BYTES or BLOCKS are also slow.
You have tablespaces using LOCAL extent management and MANUAL segment space management.
If you perform the following query, you will find that a large number of segments (probably in the 1000s or more) are listed as SLOW_SEGS:
select tablespace_name
, count(*) as seg_cnt
, sum(DECODE(bitand(segment_flags,131072),0,1)) as slow_segs
from sys.sys_dba_segs
where bitand(segment_flags,1)=1
and segment_type not in ('ROLLBACK', 'DEFERRED ROLLBACK', 'TYPE2 UNDO')
group by tablespace_name
having sum(DECODE(bitand(segment_flags,131072),0,1)) > 0;

TABLESPACE_NAME SEG_CNT SLOW_SEGS
------------------------------ ---------- ----------
SYSTEM 2968 2388
SYSAUX 2053 1444
DATA 10322 8021
USERS 755 510

CHANGES
This may be seen after upgrading to Oracle Database 11.2 and may get worse over time.

CAUSE
This is caused by the issue described in Document 12940620.8. There is a problem caching segment sizing information that is resulting in queries to these views having to compute sizing information for every segment on the fly in tablespaces with LOCAL extent management and MANUAL segment space management.

SOLUTION
Applying Patch 12940620 will prevent the problem from getting worse. After applying the patch, you can run the following PL/SQL block as sysdba which corrects sizing information on the segments:

begin
for t in (
select distinct tablespace_name
from sys.sys_dba_segs
where bitand(segment_flags,131073) = 1
and segment_type not in ('ROLLBACK', 'DEFERRED ROLLBACK', 'TYPE2 UNDO')
and tablespace_name != 'SYSTEM'
)
loop
dbms_space_admin.tablespace_fix_segment_extblks(t.tablespace_name);
end loop;
end;
/

WARNING: This procedure may take some time to complete and there is a potential of it disrupting other activities on the database while it is running. You may wish to run it out of peak hours or during a deployment window.
This procedure can also be run without applying the patch as a workaround, but the problem will return over time as database activity causes segments to grow.

###

表现为单独查询可以接受。

SELECT owner,SEGMENT_NAME,(BYTES) / 1024 / 1024
MB FROM DBA_SEGMENTS

一旦加入排序，就异常慢

SELECT owner,SEGMENT_NAME, SUM(BYTES) / 1024 / 1024
MB FROM DBA_SEGMENTS GROUP BY owner,SEGMENT_NAME
ORDER BY 3 DESC

--查看等待事件为

enq-tx-content  ,执行时间（sysdate - sql exec start (from v$session)）超过 10个小时。

参考文档https://www.cnblogs.com/feiyun8616/p/6138333.html 查看 锁的源头为

-> 30 7wurkmg0thn0d enq: TX - row lock contention -> 1596 d0wra06b4q1su gc current multi block request （1596是阻塞源头 ）

->阻塞源头： session  1596  USER DBBAT 等待事件为  gc current multi block request ，执行开始时间为  2019/10/22 7:41:52 ，持续时间为为10小时还没有结束

-》执行语句为：

INSERT INTO CST_DEP_STTN ( ***）

CRMBAT 1596 16529 ACTIVE opcrm pcrmapp01 sqlplus@pcrmapp01 (TNS V1-V3) SQL*Plus 2019/10/22 7:41:52 0000000FF9230770 3922867 0000001018E8C2D0 85 2 2147483644 0000001017D740E0 DEDICATED 85 CRMBAT 31838 55775 USER 000000105486F1B0 2521499418 d0wra06b4q1su 0 2019/10/22 7:41:52 16777217 0000001035B9B790 380981399 5rfk8u8bban4r 0 2019/10/22 7:41:52 16777216 91686 1 3669949024 0 732610847 200533 18 381503 0 59 37823 NO NONE NONE NO DISABLED ENABLED ENABLED 0 UNKNOWN UNKNOWN 11616 158 gc current multi block request file# 21 0000000000000015 block# 52993 000000000000CF01 id# 33554440 0000000002000008 3871361733 11 Cluster 0 37793 WAITING 37793271808 -1 0 crmo DISABLED FALSE FALSE FIRST EXEC 100 0000001018E8C2D0 77

-》被堵赛进程；seesion 2118   DBA等待事件为  enq: TX - contention name ，对象为usn<<16 | slot 45878 （undo数据库块），执行开始时间为  2019/10/22 8:27:26. 持续时间为10小时还没有结束

->执行语句为:

SELECT *
FROM (SELECT owner,SEGMENT_NAME, SUM(BYTES) / 1024 / 1024 MB
FROM DBA_SEGMENTS
GROUP BY owner,SEGMENT_NAME
ORDER BY 3 DESC)
WHERE ROWNUM < 15

DBMGR 2118 22623 ACTIVE oracle11g yumserver sqlplus@yumserver (TNS V1-V3) SQL*Plus 2019/10/22 8:27:26 0000001011322BF8 3923185 0000001000EC4680 87 3 2147483644 0000001019413248 DEDICATED 0 SYS 25589 35954 USER 00000010356FCA48 2695323532 54017vkhafrwc 0 2019/10/22 8:27:26 16777280 00000010477BC398 3933222116 dyk4dprp70d74 1 2019/10/22 8:27:26 17368993 4964 16 4964 16 3669949024 0 732737580 -1 23 1053699 0 59 35089 NO NONE NONE NO DISABLED ENABLED ENABLED 0 VALID 1 1596 VALID 1 1596 904 778 enq: TX - contention name|mode 1415053316 0000000054580004 usn<<16 | slot 458783 000000000007001F sequence 200458 0000000000030F0A 1893977003 0 Other 0 35086 WAITING 35085915534 -1 0 SYS$USERS DISABLED FALSE FALSE FIRST EXEC 100 0000001000EC4680 121

查询dba_segments 有锁的原因，是因为一张表发生大量的数据变动，为了防止数据不一致，dba_segments 会从undo 获取数据，这样造成锁，

而undo 因为该表的dml 没有提交，所以导致查询也被锁住了。

建议找应用看看最近为何insert 这们慢。

另外Pl/SQL developer sessions 里集成了sql monitor 功能，也比较好用。