oracle 12c automatic big table cache - home: … · oracle 12c automatic big table cache markus...

CAMPUS INNENSTADT

INSTITUT FÜR NOTFALLMEDIZIN UND MEDIZINMANAGEMENT

ORACLE 12c AUTOMATIC BIG TABLE CACHE

Markus Geis

18.11.2015

INSTITUT FÜR NOTFALLMEDIZIN

UND MEDIZINMANAGEMENT

KLINIKUM DER UNIVERSITÄT MÜNCHEN®

AGENDA

• INM (Institute for Emergency Medicine and Management in

Medicine)

• automatic big table cache

• Technology

• Configuration

• First impressions

• Conclusions

18.11.2015 2

automatic big table cache – Markus Geis




INM

3

Institute for Emergency Medicine and Management in Medicine

Part of the Munich University Hospital (LMU)

Quality Management in Emergency Medicine and

Prehospital Medicine

Interdisciplinary research institute

DWH: 2 MIO prehospital missions/ per year

Processing of medical and GEO-Data

www.inm-online.de


18.11.2015

http://www.inm-online.de/






INITIAL SITUATION

4

Operating a 12c 3 nodes cluster (12.1.0.2 EE)

-> 3 DB‘s, ca. 3TB / 1.200 DB-User

Netapp Metro Cluster

Shared Disk Spaces connected via NFS (no ASM)

Options:

Partitioning

Spatial (routing and geo-analysis)


18.11.2015




INITIAL SITUATION

5


Oracle-HTTP / Apache

Tomcat-Application-Server

• JSP

Weblogic-Server

• ADF

• Java

• MAP-Builder

Windows 7 & XP

RAC-Cluster

12.1.0.2

18.11.2015




AUTOMATIC BIG TABLE CACHE

6

Part of the Oracle „inMemory“ Initiative

available starting with Version 12.1.0.2

Feature (Poor Man’s In-Memory Caching)

available in all editions:

SI (EE): sequential queries (PX)

RAC / (EE): parallel-query only


18.11.2015





7

Performance of the DB determined by CACHE

access to DB-Data should be realised via CACHE (DB-Blocks)

disk access should be avoided

data volumes are growing

important / unimportant Data


18.11.2015





8

classic technology for processing big tables

(Full Table Scans)

direct path read

_small_table_threshold

COMPRESSED

PARTIONING


18.11.2015





9

direct path read

reads big tables accessed via a FULL-TABLE-SCAN directly,

baypassing the BUFFER-Caches, from the Data-Files to the

PGA of the users

BUFFER-Cache is not flooded

Disadvantage: SELECT always accesses the disk


18.11.2015

DISK

PGA

DB-BLOCK-BUFFER





10

_small_table_threshold :

defines a table as „SMALL“

HIDDEN

a table is considered SMALL when the size < 2% of the

buffer-cache

data are provided by the DB-BLOCK-BUFFER (full-table-

scan)

important Info for the „automatic big table cache“


18.11.2015





11

_small_table_threshold (number of blocks)

SELECT a.ksppinm,b.ksppstvl ,c.ksppstvl,a.ksppdesc

FROMx$ksppi a ,x$ksppcv b ,x$ksppsv c

WHEREa.indx = b.indx AND a.indx = c.indx

AND a.ksppinm LIKE '/_%' escape '/'

and a.ksppinm like '_small%'

ORDER BY 1

gv$sgainfo (Buffer Cache Size 26306674688 bytes ca.26GB)

76.943*DB-Block (8K)/DB-Buffer-CACHE ca. 2%

Size of SMALL-Table in the INM-environment: ca. 600 MB


18.11.2015

PARAM SESSIONVAL INSTANCEVAL DESCR

_small_table_threshold 76943 76943 lower threshold level of table size for direct

reads





12

current/normal CACHE-behaviour of DB-BLOCK-BUFFER:

LRU (last recently used)-> Algorithm

LRU-List handles CACHE (DB-BUFFER)

COLD- / HOT-AREA

blocks are inserted in the middle of the LRU-List


18.11.2015





13

current CACHE-behaviour of DB-BLOCK-BUFFER :

depending on usage blocks move to COLD or HOT area

when space is needed blocks are removed from CACHE

Problem: important blocks/objects can drop out of CACHE

(queries get slow / disk reads)


18.11.2015





14

KEEP-mechanism

certain tables can be pinned to memory

technology or small tables

no possibility to access „Partitions“

Workload is not taken into consideration / the admin defines the

technology


18.11.2015





15

Automatic big table cache: „ABTC“

this technology should prevent often used objects from dropping

out of the CACHE

„workload“ should determine behaviour of the CACHE

a certain amount of the DB-Block-Buffer is reserved for this

technology (up to 90%)


18.11.2015





16

How is the workload calculated?

Algorithm determines based of access frequency if and how an

object (e.g. table) will get loaded into CACHE and stays there or

not

Oracle calls this “temperature”

the higher the “temperature” the higher the probability of an

object to stay in the CACHE

Only big tables are taken into consideration;

no small tables -> _small_table_threshold


18.11.2015





17

Librarians get the reqested boook for each query

Librarians use their experience to compile a pool of probably

needed books: „ABTC“


18.11.2015





18

two setting for the activation:

ALTER SYSTEM SET db_big_table_cache_percent_target=55;

ALTER SYSTEM SET compatible='12.1.0.2.0'

RAC-Cluster: „parallel query“ on

(automatic / adaptive)

ALTER SYSTEM SET PARALLEL_DEGREE_POLICY=AUTO;

single instance : also sequential queries

15.09.2015






19

Those objects can be loaded into „ABTC“:

15.09.2015


OBJECTS OBJECT-TYPE (v$bt_scan_obj)

Table TABLE PARTITION

Table-Partition TABLE SUBPARTITION

Index INDEX

Index-Partition INDEX SUBPARTITION




AUTOMATIC BIG TABLE CACHE - TECHNOLOGY

20

Two SYS-Views for the administration of the “ABTC”:

Single-Instance

V$BT_SCAN_CACHE -> CACHE-Infos

V$BT_SCAN_OBJ_TEMPS -> Objects in “ABTC”

RAC:

gV$BT_SCAN_CACHE

gV$BT_SCAN_OBJ_TEMPS

15.09.2015






21

Example: Space requirements and infos on „ABTC“

SELECT bt_cache_alloc, bt_cache_target, object_count, memory_buf_alloc

FROM v$bt_scan_cache;

SELECT * from gV$BT_SCAN_CACHE

15.09.2015

BT_CACHE_ALLOC BT_CACHE_TARGET OBJECT_COUNT MEMORY_BUF_ALLOC

.400005755 40 3 50685

INST_ID BT_CACHE_ALLOC BT_CACHE_TARGET OBJECT_COUNT MEMORY_BUF_ALLOC

2 0,550005216490914 55 204 1706599

1 0,550000710281341 55 2563 1659568

3 0,550000788577281 55 234 1732373






22

Objects in „ABTC“:

SELECT distinct obj.object_name,ts.name ts_name,subobject_name,object_type,

temperature,policy, (cached_in_mem*8192)/1024/1024 cached_mb, dataobj# , btt.inst_id

FROM gv$tablespace ts,gv$bt_scan_obj_temps btt,dba_objects obj

WHERE ts.ts# = btt.ts#

AND obj.object_id = DATAOBJ#

order by temperature desc, dataobj# ;

OBJECT_NAME TS_NAME SUBOBJECT_NAME OBJECT_TYPE TEMPERATURE POLICY CACHED_MB DATAOBJ# ID

ILS_EINSATZMITTEL ARLIS_DATA RDB_303 TABLE PARTITION 405000 MEM_ONLY 64,4140625 1251086 2

ARLIS_DATA ARLIS_DATA ED_2012_RDB_303 TABLE

SUBPARTITION 9813 MEM_ONLY 44,7109375 1029063 3

ARLIS_DATA_FA_EDAT ARLIS_INDEX ED_2008_RDB_302 INDEX



18.11.2015





23 15.09.2015


in the RAC the objects / object fragments are distributed over the

nodes

each node administers its own CACHE

https://apex.oracle.com/pls/apex/GERMAN_COMMUNITIES.SHOW_RESOURCE_BY_FNAME?P_TIPP_ID=3841&P_FILE_NAME=snap1.png





24 15.09.2015


no „cache-fusion“ technology as in regular RAC operation

no blocks/data are being transmitted over the interconnect

when processes are distributed over more knots only the results are

generated over the PX on the remote knot and transmitted to the

querying knot

if: PARALLEL_FORCE_LOCAL=TRUE (interconnect / PX stay on one

instance) / intentional decision in INM

objects can be multiple allocated on the instances





25 15.09.2015






AND obj.object_id = DATAOBJ#

and subobject_name='ED_2013_RDB_501'

order by obj.object_name,btt.inst_id

OBJECT_NAME SUBOBJECT_NAME OBJECT_TYPE TEMPERATURE POLICY CACHED_MB DATAOBJ# INST_ID

ARLIS_DATA ED_2013_RDB_501 TABLE

SUBPARTITION

2000 MEM_ONLY 130,3203125 1058127 1


SUBPARTITION

1000 MEM_ONLY 130,3203125 1058127 2


SUBPARTITION

60250 MEM_ONLY 130,3203125 1058127 3





26

Ways of „ABTC“ (POLICY)

MEM_ONLY Object stays completely in CACHE

MEM_PART Parts of the object stay in CACHE

DISK Object is read entirely from DISK

OBJECT_NAME TS_NAME TEMPERATURE POLICY CACHED_MB

ARLIS_DATA_FIRMA_P_O_IDX ARLIS_INDEX 2000 DISK 0

ARLIS_DATA_FIRMA_P_O_IDX1 ARLIS_INDEX 2000 MEM_PART 1,2578125

DM_TG_RDS_BODEN ARLIS_DATA 26563 MEM_ONLY 888,8046875


18.11.2015





27 15.09.2015


SQL> select object_count from V$BT_SCAN_CACHE;

OBJECT_COUNT

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

0

SQL> set autotrace on

SQL> select count(*) from scott.t1;

COUNT(*)

--------

2000000

Execution Plan

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

Plan hash value: 227768458

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

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

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

|0 | SELECT STATEMENT | | 1 | 211 (6) | 00:00:01 |

|1 | SORT AGGREGATE | | 1 | | |

|2 | INDEX FAST FULL SCAN | SYS_C0011355 | 2565K | 211 (6) | 00:00:01 |

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

Statistiken

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

947 recursive calls

0 db block gets

11489 consistent gets

4191 physical reads





select object_count from V$BT_SCAN_CACHE;

OBJECT_COUNT

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

1

select ts#,dataobj#,policy from V$BT_SCAN_OBJ_TEMPS;

TS# DATAOBJ# POLICY

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

196612 96464 MEM_ONLY

select owner,object_name,object_type

from dba_objects

where data_object_id=96464;

OWNER OBJECT_NAME OBJECT_TYPE

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

SCOTT T1 TABLE

15.09.2015


28





select count(*) from scott.t1;

Execution Plan

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


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

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

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

| 0 | SELECT STATEMENT | | 1 | 211 (6)| 00:00:01 |

| 1 | SORT AGGREGATE | | 1 | | |

| 2 | INDEX FAST FULL SCAN| SYS_C0011355 | 2565K| 211 (6)| 00:00:01 |

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

Statistiken

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


0 physical reads

15.09.2015


29





select /*+ full(t1) */ count(*) from scott.t1;

COUNT(*)

--------

2000000

Elapsed: 00:00:00.03

Execution Plan

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


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

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

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

|0 | SELECT STATEMENT | | 1 | 596 (33)| 00:00:01 |

|1 | SORT AGGREGATE | | 1 | | |

|2 | TABLE ACCESS FULL| T1 | 2565K | 596 (33) | 00:00:01 |

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

Statistiken

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


0 physical reads

15.09.2015


30





Measurements INM:

Problem: test environment (each new test after some days of

normal operations)

55% „ABTC“ with ca. 26 GB DB-BLOCK-BUFFERS

regularly single selects on table „distanz_matrix“ with ca. 1,6

billion rows, to generate load on machine and cache (12c with

ABTC)

restart of the statements after one day

Table with partitions and SUB-partitions

SIZE: 22,6 GB / 30,5 million rows

15.09.2015


31





Select-INM:

Test: 29.10.2015:





AND obj.object_id = DATAOBJ# order by temperature desc, dataobj# ;

15.09.2015


32

OBJECT_NAME TS_NAME SUBOBJECT_NAME OBJECT_TYPE TEMPERATURE POLICY CACHED_MB DATAOBJ# INST_ID







ILS_EINSATZMITTEL ARLIS_DATA RDB_303 TABLE

PARTITION 17010 MEM_ONLY 69,3203125 1251086 2

ILS_EINSATZMITTEL ARLIS_DATA RDB_314 TABLE

PARTITION 16010 MEM_ONLY 400,984375 1251097 2





Measurements INM:

select /*+ full(t1) */ distinct to_char(einsatz_datum,'dd.mm.yyyy') TAG, count(*)

from oracle.arlis_data t1

where einsatz_datum >=to_date('01.01.2013','dd.mm.yyyy')

and einsatz_datum < to_date('01.01.2014','dd.mm.yyyy')

and firma=308

group by to_char(einsatz_datum,'dd.mm.yyyy')

TAG COUNT(*)

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

23.10.2013 157

22.10.2013 140

09.05.2013 97

…

365 Zeilen ausgewählt.

Abgelaufen: 00:00:05.17

15.09.2015


34





Measurements INM:

Ausführungsplan

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


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

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

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

| 0 | SELECT STATEMENT | | 365 | 4380 | 1260 (4)| 00:00:01 | | |

| 1 | HASH GROUP BY | | 365 | 4380 | 1260 (4)| 00:00:01 | | |

| 2 | PARTITION RANGE SINGLE| | 62513 | 732K| 1249 (3)| 00:00:01 | 16 | 16 |

| 3 | PARTITION LIST SINGLE| | 62513 | 732K| 1249 (3)| 00:00:01 | KEY | KEY |

| 4 | TABLE ACCESS FULL | ARLIS_DATA | 62513 | 732K| 1249 (3)| 00:00:01 | 401 | 401 |

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

Statistiken

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


362 physical reads

15.09.2015


35





Measurements INM:

Using partitioning combined with “ABTC”

Partition considerably reduces amount of data

“ABTC” keeps the partition in CACHE thanks to the calculated

workflow

15.09.2015


36





Measurements INM / development over time:

select count(*), firma, kfzart

from oracle.arlis_data

group by firma, kfzart

15.09.2015


37

Statement 12.1.0.2 / SI / ohne ABTC 11gCluster 12c Cluster + parallel /ABTC

2 00:00:20.64 00:05:39.64 00:00:13.67

00:00:18.31 (days later)

00:00:26.97 (days later)




AUTOMATIC BIG TABLE CACHE – FIRST EXPERIENCES

38

simple configuration / no change to DB structure or applications

especially well suited for partitioned tables

simulated calculations with repeated SQL-queries on the same

table partitions

workload determies CACHE content

it takes some time for the „workload“ to adjust itself correctly

significat performance boost in our environment

e.g. procedure before „ABTC“ 45 minutes / now 12 minutes

productive for ca. 3 months


18.11.2015




THANK YOU FOR YOUR ATTENTION

CONTACT DATA:

Markus Geis

Klinikum der Universität München

INM - Institut für Notfallmedizin

und Medizinmanagement

Phone: +49 / 89 / 4400-57101

E-Mail: [email protected]

Internet: www.inm-online.de

39 18.11.2015




16.11.2015 41

oracle 12c automatic big table cache - home: … · oracle 12c automatic big table cache markus...

Documents