分类目录归档：Oracle性能优化

oracle性能优化

数据文件自扩展引起—enq: HW – contention

发表于 2018 年 4 月 2 日由惜分飞

客户反馈数据库比较慢,严重影响业务运行,让我们进行分析
enq: HW – contention等待明显
登录上去查看发现大量的enq: HW – contention等相关等待.

确认相关对象

SQL> select p3 from v$session_wait where event = 'enq: HW - contention';

   P3 
----------
34083635

SQL> select dbms_utility.data_block_address_block(34083635) RDBA_FILE,
  2  dbms_utility.data_block_address_file(34083635) RDBA_BLOCK from dual;  

 RDBA_FILE RDBA_BLOCK
---------- ----------
    529203          8


SQL>  select owner, segment_type, segment_name,tablespace_name   
  2      from dba_extents   
  3      where file_id = 8   
  4     and 529203 between block_id and block_id + blocks - 1;  

   OWNER   SEGMENT_TYPE        SEGMENT_NAME 	    TABLESPACE_NAME
---------- ------------------- -------------------  -------------------
XXXX       INDEX               T_TRADEITEM_85        USERS

确认对应sql

分析表空间使用情况

增加数据文件

再次查询表空间使用情况

查询等待事件

通过这里的分析,由于USERS表空间的空闲表空间已经被完全使用,后续使用需要扩展,因而引起了enq: HW – contention等待,以及由于该等待引起了其他相关等待,当users表空间进行扩展之后,立马恢复正常.实际的例子证明,在实际生产中特别是高并发生产库中,数据文件自扩展会严重影响数据库性能.

发表在 Oracle性能优化 | 标签为 enq: HW - contention | 2 条评论

_optimizer_null_aware_antijoin和not in效率

发表于 2017 年 6 月 4 日由惜分飞

准备两个测试表

SQL> conn chf/oracle
Connected.
SQL> select * from v$version;

BANNER
----------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
PL/SQL Release 11.2.0.4.0 - Production
CORE    11.2.0.4.0      Production
TNS for Linux: Version 11.2.0.4.0 - Production
NLSRTL Version 11.2.0.4.0 - Production

SQL> create table t_xifenfei
  2  as select * from dba_objects;

Table created.

SQL> select count(*) from t_xifenfei;

  COUNT(*)
----------
     86259

SQL> create table t_xifenfei1
  2  as select * from dba_objects;

Table created.

SQL> select count(*) from t_xifenfei1;

  COUNT(*)
----------
     86260

--删除部分记录，用来做not in的内部表
SQL> delete from t_xifenfei where object_id>86200;

918 rows deleted.

SQL> commit;

Commit complete.

查询_optimizer_null_aware_antijoin隐含参数默认值

SQL> conn / as sysdba
Connected.
SQL> col name for a52
SQL> col value for a24
SQL> col description for a50
set linesize 150
select a.ksppinm name,b.ksppstvl value,a.ksppdesc description
  from x$ksppi a,x$ksppcv b
 where a.inst_id = USERENV ('Instance')
   and b.inst_id = USERENV ('Instance')
   and a.indx = b.indx
   and upper(a.ksppinm) LIKE upper('%&param%')
order by name
SQL> SQL>   2    3    4    5    6    7    8  /
Enter value for param: _optimizer_null_aware_antijoin
old   6:    and upper(a.ksppinm) LIKE upper('%&param%')
new   6:    and upper(a.ksppinm) LIKE upper('%_optimizer_null_aware_antijoin%')

NAME                                                 VALUE                    DESCRIPTION
---------------------------------------------------- ------------------------ -----------------------------
_optimizer_null_aware_antijoin                       TRUE                     null-aware antijoin parameter

_optimizer_null_aware_antijoin从11.1.0.6开始引进,默认为true

_optimizer_null_aware_antijoin为true,执行not in

SQL> conn chf/oracle 
Connected.
SQL> set autot trace
SQL> set timing on
SQL> set lines 150
SQL> set pages 1000
SQL>  select count(*) from t_xifenfei1 where object_id not in(select object_id from t_xifenfei);

Elapsed: 00:00:00.09

Execution Plan
----------------------------------------------------------
Plan hash value: 4048525918

----------------------------------------------------------------------------------------
| Id  | Operation                | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT         |             |     1 |    10 |   688   (1)| 00:00:09 |
|   1 |  SORT AGGREGATE          |             |     1 |    10 |            |          |
|*  2 |   HASH JOIN RIGHT ANTI NA|             |  1137 | 11370 |   688   (1)| 00:00:09 |
|   3 |    TABLE ACCESS FULL     | T_XIFENFEI  | 85341 |   416K|   344   (1)| 00:00:05 |
|   4 |    TABLE ACCESS FULL     | T_XIFENFEI1 | 86260 |   421K|   344   (1)| 00:00:05 |
----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("OBJECT_ID"="OBJECT_ID")


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
       2472  consistent gets
          0  physical reads
          0  redo size
        527  bytes sent via SQL*Net to client
        520  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

_optimizer_null_aware_antijoin为false,执行not in

SQL> alter session set "_optimizer_null_aware_antijoin"=false;

Session altered.

Elapsed: 00:00:00.00
SQL> select count(*) from t_xifenfei1 where object_id not in(select object_id from t_xifenfei);

Elapsed: 00:02:29.64

Execution Plan
----------------------------------------------------------
Plan hash value: 2503880249

-----------------------------------------------------------------------------------
| Id  | Operation           | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |             |     1 |     5 |    25M  (1)| 86:20:57 |
|   1 |  SORT AGGREGATE     |             |     1 |     5 |            |          |
|*  2 |   FILTER            |             |       |       |            |          |
|   3 |    TABLE ACCESS FULL| T_XIFENFEI1 | 86260 |   421K|   344   (1)| 00:00:05 |
|*  4 |    TABLE ACCESS FULL| T_XIFENFEI  |     1 |     5 |   344   (1)| 00:00:05 |
-----------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter( NOT EXISTS (SELECT 0 FROM "T_XIFENFEI" "T_XIFENFEI" WHERE
              LNNVL("OBJECT_ID"<>:B1)))
   4 - filter(LNNVL("OBJECT_ID"<>:B1))


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
   52982891  consistent gets
          0  physical reads
          0  redo size
        527  bytes sent via SQL*Net to client
        520  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

这里很明显,当 _optimizer_null_aware_antijoin为false的时候not in效率非常低(当in里面记录多，使用FILTER效率肯定低下).

_optimizer_null_aware_antijoin为false,执行not exists

SQL> alter session set "_optimizer_null_aware_antijoin"=false;

Session altered.

SQL>select count(*) from t_xifenfei1 b where not exists 
 2  (select 1 from t_xifenfei a where a.object_id=b.object_id);

Elapsed: 00:00:00.07

Execution Plan
----------------------------------------------------------
Plan hash value: 2976307246

-------------------------------------------------------------------------------------
| Id  | Operation             | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |             |     1 |    10 |   688   (1)| 00:00:09 |
|   1 |  SORT AGGREGATE       |             |     1 |    10 |            |          |
|*  2 |   HASH JOIN RIGHT ANTI|             |  1137 | 11370 |   688   (1)| 00:00:09 |
|   3 |    TABLE ACCESS FULL  | T_XIFENFEI  | 85341 |   416K|   344   (1)| 00:00:05 |
|   4 |    TABLE ACCESS FULL  | T_XIFENFEI1 | 86260 |   421K|   344   (1)| 00:00:05 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("A"."OBJECT_ID"="B"."OBJECT_ID")


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       2472  consistent gets
          0  physical reads
          0  redo size
        527  bytes sent via SQL*Net to client
        520  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

对于11g的版本可以通过_optimizer_null_aware_antijoin参数开启NULL-aware Anti join特性来提高not in的效率,对于11g以下版本可以通过not exists来提高效率

发表在 Oracle性能优化 | 标签为 not in, _optimizer_null_aware_antijoin | 评论关闭

12.1中出现大量Result Cache: RC Latch处理

发表于 2016 年 5 月 29 日由惜分飞

昨天有个朋友找到我说他们的12.1的库在业务高峰期非常慢，希望我们给予优化支持,经过awr分析，定位到问题为latch free问题,具体定位为:Result Cache: RC Latch.
优化之前awr部分信息
awr整体负载情况，证明当前这个库已经比较忙，业务反馈很慢
awr1

addr信息和top wait信息，确定是latch free问题比较突出
awr2

latch信息统计和ash信息，找出来突出的latch,定位为Result Cache: RC Latch引起该问题
awr4

补充大量异常sql

类似sql语句

SELECT /* DS_SVC */ /*+ dynamic_sampling(0) no_sql_tune no_monitoring optimizer_features_enable(default) no_parallel */
 SUM(C1) FROM (SELECT /*+ qb_name("innerQuery") INDEX_FFS( "ACCOUNT" "ACC_USER_ID") */ 
1 AS C1 FROM "ACCOUNT" SAMPLE BLOCK(39.3701, 8) SEED(1) "ACCOUNT" WHERE ( "ACCOUNT".USER_ID IS NOT NULL)) innerQuery

查询mos发现
The cause of this issue is automatic dynamic statistics which is enabled by default in 12c automatically decides whether dynamic statistics are useful and which statistics level to use for all SQL statements. It collects dynamic statistics when the optimizer deems it necessary.
When Automatic Dynamic Sampling is used for the SQL statements, it can decide, based upon these statistics, that a better response time could be achieved by using the result cache for those queries. This can cause heavy usage of the result cache leading to the contention on latch free for “Result Cache: RC Latch”.
也就是说,12c在自动采样有改进，而且默认使用result cache特性，从而引起该问题，即使你设置了 RESULT_CACHE_MODE = MANUAL，依旧会有大量动态采样引起 Result Cache: RC Latch，彻底解决给问题就是通过隐含参数禁止Automatic Dynamic Statistics使用result cache

alter system set "_optimizer_ads_use_result_cache" = FALSE;

设置该参数之后效果
这里看，通过上述处理后，系统db time 大量减少，业务反馈已经运行正常
hawr1

latch free和Result Cache: RC Latch已经基本上消失
hawr2

当然这个异常是由于动态采样导致,可以通过收集数据库统计信息，设置动态采样级别，也可以从一定程度上缓解该情况.
参考mos
Very Long Parse Time for Queries in InMemory Database (Doc ID 2102106.1)
High “Latch Free” Waits with Contention on ‘Result Cache: RC Latch’ when RESULT_CACHE_MODE = MANUAL on Oracle 12c (Doc ID 2002089.1)

发表在 Oracle性能优化 | 标签为 Result Cache: RC Latch, _optimizer_ads_use_result_cache | 评论关闭

17813235971

QQ 咨询

分类目录归档：Oracle性能优化

数据文件自扩展引起—enq: HW – contention

_optimizer_null_aware_antijoin和not in效率

12.1中出现大量Result Cache: RC Latch处理

文章分类

最近发表

分类目录归档：Oracle性能优化

数据文件自扩展引起—enq: HW – contention

_optimizer_null_aware_antijoin和not in效率

12.1中出现大量Result Cache: RC Latch处理

标签云

文章分类

最近发表