约2秒左右)才返回结果。

初步判断，可能pl/sql developer的操作过程中涉及到一些系统表的查询，可能数据字典和系统固定对象的统计信息没有收集，导致有些内部视图的访问太慢。

于是收集数据字典和系统固定对象的统计信息

14:02:25 SQL> exec dbms_stats.gather_dictionary_stats;

PL/SQL 过程已成功完成。

已用时间:  00: 02: 34.50

15:23:01 SQL> exec dbms_stats.gather_fixed_objects_stats

PL/SQL 过程已成功完成。

已用时间:  00: 03: 56.13

完成之后，清空共享池：alter system flush shared_pool;

验证之前慢的操作，仍然还是慢，于是做了一个sql trace，根据跟踪文件，发现以下类似的sql在编写sql语句期间被自动执行了：

原来是进行了动态采样，这些采样语句的IO都比较高，所以会这么卡。

SELECT /* DS_SVC */ /*+ dynamic_sampling(0) no_sql_tune no_monitoring

optimizer_features_enable(default) no_parallel result_cache(snapshot=3600)

*/ C1, C2, C3

FROM

(SELECT /*+ qb_name("innerQuery") NO_INDEX_FFS( "O2")  */ 4294967295 AS C1,

COUNT(*) AS C2, SUM(CASE WHEN ("O2"."TYPE#"=88) THEN 1 ELSE 0 END) AS C3

FROM SYS."OBJ$" SAMPLE BLOCK(44.1745, 8) SEED(1)  "O2" WHERE ("O2"."TYPE#"=

88)) innerQuery

call     count       cpu    elapsed       disk      query    current        rows

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

Parse       12      0.00       0.00          0          0          0           0

Execute     12      0.00       0.00          0          0          0           0

Fetch       12      0.14       0.08          0       9564          0          12

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

total       36      0.14       0.08          0       9564          0          12

Misses in library cache during parse: 1

Optimizer mode: ALL_ROWS

Parsing user id: 310     (recursive depth: 2)

Rows     Row Source Operation

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

1  VIEW  (cr=797 pr=0 pw=0 time=5509 us cost=219 size=31 card=1)

1   SORT AGGREGATE (cr=797 pr=0 pw=0 time=5506 us)

0    TABLE ACCESS SAMPLE OBJ$ (cr=797 pr=0 pw=0 time=5497 us cost=219 size=16 card=1)

********************************************************************************

SELECT /* DS_SVC */ /*+ dynamic_sampling(0) no_sql_tune no_monitoring

optimizer_features_enable(default) no_parallel result_cache(snapshot=3600)

*/ C1, C2, C3

FROM

(SELECT /*+ qb_name("innerQuery") NO_INDEX_FFS( "DO")  */ 4294967295 AS C1,

COUNT(*) AS C2, SUM(CASE WHEN ("DO"."TYPE#"=92) THEN 1 ELSE 0 END) AS C3

FROM SYS."OBJ$" SAMPLE BLOCK(44.1745, 8) SEED(1)  "DO" WHERE ("DO"."TYPE#"=

92)) innerQuery

call     count       cpu    elapsed       disk      query    current        rows

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

Parse        8      0.00       0.00          0          0          0           0

Execute      8      0.00       0.00          0          0          0           0

Fetch        8      0.04       0.04          0       6376          0           8

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

total       24      0.04       0.04          0       6376          0           8

Misses in library cache during parse: 1

Optimizer mode: ALL_ROWS

Parsing user id: 310     (recursive depth: 2)

Rows     Row Source Operation

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

1  VIEW  (cr=797 pr=0 pw=0 time=5716 us cost=219 size=31 card=1)

1   SORT AGGREGATE (cr=797 pr=0 pw=0 time=5711 us)

0    TABLE ACCESS SAMPLE OBJ$ (cr=797 pr=0 pw=0 time=5704 us cost=219 size=16 card=1)

查了一下动态采样的参数，其值居然是3，修改参数值为0，关闭动态采样：

alter system set optimizer_dynamic_sampling=0 scope=both;

执行后大部分操作有一定的性能改善，但没有完全解决，于是又重启了数据库，再进行相应的操作，就不再卡了。

原文：http://blog.itpub.net/117319/viewspace-2084246/