查詢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 功能，也比較好用。