73
100500 способов кэширования в Oracle Database или как достичь максимальной скорости обработки запросов минимальной ценой Токарев Александр DataArt

Oracle result cache highload 2017

Embed Size (px)

Citation preview

Page 1: Oracle result cache highload 2017

100500 способовкэширования в Oracle Database или как достичьмаксимальной скоростиобработки запросовминимальной ценой

Токарев Александр

DataArt

Page 2: Oracle result cache highload 2017

Agenda• Database caches

• Result cache

• Result cache in DBMSs different from Oracle

• Hand-made Oracle result cache implementation

• Embedded Oracle result cache implementation

• Performance tests

• Limitations and caveats

• Cases

• Conclusion

Page 3: Oracle result cache highload 2017

Agenda• Retailer case

• Finance case

• Limitations and caveats

• Loyalty case

• Conclusion

Page 4: Oracle result cache highload 2017

Database caches

• Buffer cache – cache for data pages/data blocks

• Statement cache – cache of queries plan

• Result cache – rows from queries

• OS cache

Page 5: Oracle result cache highload 2017

Retailer case

DWH report

Oracle 1120 Tb300 users

20 min350 distinct SKU5000 rows

Select sku_id,Shop_id,sku_detail(sku_id),…..

from dim_saleswhere ….Order by shop_id……..

Create or replace function sku_detail(sku_idnumber) return number isSelect 1If Select 2Else Select 3………Select 30End;

400 lines of SQL+PL/SQL

0.2 second per SKU

5000 * 0.2 = 1000 seconds

Page 6: Oracle result cache highload 2017

Retailer case Hand-made cache

DWHreport

Oracle 1120 Tb300 users

4 min350 distinct SKU5000 rows

Select sku_id,Shop_id,sku_detail(sku_id),…..

from dim_saleswhere ….Order by shop_id……..

Create or replace function

sku_full(sku_id number)

return number isSelect 1If Select 2Else Select 3………Select 30End;

400 lines of SQL+PL/SQL

0.2 second per SKU

350* 0.2 = 70 secondsCREATE PACKAGE BODY cache_sku AS

TYPE sku_cache_aat IS TABLE OF number INDEX BY PLS_INTEGER;

cache sku_cache_aat;

end cache_sku;

cache

FUNCTION sku_detail(skunumber) RETURN number ISBEGINIF NOT cache.EXISTS(sku) THEN

cache(sku) := sku_full(sku);END IF;RETURN cache(sku);

END sku_detail;

Page 7: Oracle result cache highload 2017

Hand-made cache Memory

12X

Page 8: Oracle result cache highload 2017

Hand-made cachePros:- Very fast- Easy to implement- No configuration efforts- No intra-process sync logic burden

Cons:- Cache consumes expensive memory from DB- Memory is allocated per-session basis- PL/SQL or other DB stored logic is required- Vendor specific- No automatic invalidation

Page 9: Oracle result cache highload 2017

Hand-made cache Not OracleNo cache

Page 10: Oracle result cache highload 2017

Hand-made cache Not OracleWith propopulated cache

Page 11: Oracle result cache highload 2017

Case 2 Recommendation engine

Oracle main

OracleDG

Application server

Application server

Load balancer

Client browser

4000users10000 requests per second

In-memory cluster

Page 12: Oracle result cache highload 2017

Case 2 Recommendation engine

Recommendation rules

1. 10 best recommendations by text match 2. Multilanguage capabilities3. Should be taken from 12 previous recognized documents of the client4. If there is no documents – from all clients of the same industry5. If no in same industry – from clients similar by margin and e.t.c

max 100 rows

2-3 columns

max 100 users

Page 13: Oracle result cache highload 2017

Case 2 Recommendation engine

1 week before the Release

1. Recommendations work slow – 5 minutes for 1 document

2. Code freeze

Page 14: Oracle result cache highload 2017

Case 2 Recommendation engine

Solution

1. Use database to cache queries

2. Use Oracle Database Result Cache

Why

1. SQL to get recommendation works 0.5 sec, no options for query tuning – Oracle full text search engine + it is really heavy SQL

2. Same parameters appear at least 5-10 times – cache will be used

3. Data to get recommendations is refreshed 1 hour basis

4. PL/SQL is prohibited

Page 15: Oracle result cache highload 2017

Oracle Result Cache

Oracle result cache

1. Memory area to share query result sets

2. Read consistent – auto invalidation during DML

3. Automatic dependency tracking

4. Minimal changes in the application

5. There is an option how not to change application

6. Could cache PL/SQL logic as well

Page 16: Oracle result cache highload 2017

Oracle Result Cache Way 1

ID of result

First execution Second execution

Page 17: Oracle result cache highload 2017

Oracle Result Cache Table annotations

No query changes but RC works

Page 18: Oracle result cache highload 2017

Oracle Result Cache Table annotations

No annotation on JOBS table – no result cache

Page 19: Oracle result cache highload 2017

Oracle Result Cache Table annotations

2 annotations –result cache works

Page 20: Oracle result cache highload 2017

Oracle Result Cache Dependency TrackingNo in dependency list

Page 21: Oracle result cache highload 2017

Oracle Result Cache Dependency Tracking

Page 22: Oracle result cache highload 2017

Oracle Result Cache Inline Views

Page 23: Oracle result cache highload 2017

Oracle Result Cache Inline Views

Page 24: Oracle result cache highload 2017

Oracle Result Cache Simple Views

Page 25: Oracle result cache highload 2017

Oracle Result Cache Invalidation

Page 26: Oracle result cache highload 2017

Oracle Result Cache Invalidation

Cache is ignored for current session

Good for others sessions

Page 27: Oracle result cache highload 2017

Oracle Result Cache Invalidation

Invalidated after commit for others sessions!

Page 28: Oracle result cache highload 2017

Oracle Result Cache Invalidation

Unexpected cache invalidation

1. SELECT FOR UPDATE statement even there were no changes at all

2. an unindexed foreign key + delete/update/insert a record from parent table

3. Update/delete statements in main table with no records affected + an update to any table where rows were affected.

P.S. Result Cache doesn’t track partitions even if a result cache query works with only 1 partition. Table level tracking always.

Page 29: Oracle result cache highload 2017

Case 2 Recommendation engine

Final solution

1. Do not use annotations – not all queries should be cached

2. Use /*+ result_cache*/ for long-running query

3. Performance is tested. Document recognition –30 seconds.

Time for production

Page 30: Oracle result cache highload 2017

Case 2 Recommendation engine Early morning

Level 3 support

Production incident

Severity 1

Users can’t provide document recognition. Recognition takes 20 minutes

at least. Sessions hangs.

Regards, L2 support team.

Page 31: Oracle result cache highload 2017

Case 2 Recommendation engine

• Active user count: 400

• Database active session count: 1200 = 400* 3

• Row count: 500

• Columns count: 5-8

X5 more!

Page 32: Oracle result cache highload 2017

Monitoring features

View Name DescriptionV$RESULT_CACHE_STATISTICS Lists cache settings and memory usage statisticsV$RESULT_CACHE_MEMORY Lists all the memory blocks and corresponding

statisticsV$RESULT_CACHE_OBJECTS Lists all the objects(cached results and

dependencies) along with their attributesV$RESULT_CACHE_DEPENDENCY Lists the dependency details between the cached

results and dependenciesV$SQLAREA Lists SQL statements issued inside Oracle database

Page 33: Oracle result cache highload 2017

Management features

Procedure Name DescriptionBYPASS Instruction to ignore result cache: for current

session or for all DBFLUSH Clean cacheMEMORY_REPORT Memory detail report

STATUS Checks the status

INVALIDATE Invalidates the specified result-set object

Package: DBMS_RESULT_CACHE

Page 34: Oracle result cache highload 2017

V$RESULT_CACHE_MEMORY

V$RESULT_CACHE_OBJECTS

V$RESULT_CACHE_STATISTICS

DBMS_RESULT_CACHE.MEMORY_REPORT

Locks Result cache prior 12.2 – use very careful!!!

Page 35: Oracle result cache highload 2017

Case 2 Recommendation engine Investigations

Strange queries for 40 small tables each minute:

ETL

Page 36: Oracle result cache highload 2017

Case 2 Recommendation engine Investigations

Result cache annotation

Still 20 minutes per document

Page 37: Oracle result cache highload 2017

Case 2 Recommendation engine

We have received very positive feedback about Oracle Adaptive Statistic feature from customer with respect to adaptive plans. It has proved to be very able at improving system performance for a huge range of workloads. (c) Oracle

20000 queries

10 minutes per document!!!

Via bug? WTF!!!

Page 38: Oracle result cache highload 2017

Result cache latches

Latches are Oracle-internal low-level locks that protect the memory structures of the system global area (SGA) against simultaneous accesses.

Page 39: Oracle result cache highload 2017

Result cache latches

Page 40: Oracle result cache highload 2017

Result cache latches Type 1When setsFirst row of dataset is placed in Result Cache

When releaseLast row of dataset is placed in Result Cache

Who waits

Sessions with same SQL which requested the latch

How much

_RESULT_CACHE_TIMEOUT – 10 seconds. Next - result cache bypassed.

Page 41: Oracle result cache highload 2017

Result cache latches Type 2When setsFirst row of dataset is requested from Result Cache

When releaseLast row of dataset is read from Result Cache

Who waits

Sessions with same SQL which requested the latch

How much

It depends

Page 42: Oracle result cache highload 2017

Result cache latchesLatches not only makes SQL to wait but consumes CPU.

There is no options to get rid of result cache latches – slow for concurrent environment..

Be ready to convince DBA latches wait time saves DB time.

Page 43: Oracle result cache highload 2017

Result cache statistics

NAME VALUEBlock Size (Bytes) 1024Block Count Maximum 4096Block Count Current 4096Result Size Maximum (Blocks) 204Create Count Success 500

Create Count Failure 0Find Count 20000Invalidation Count 10000Delete Count Invalid 155Delete Count Valid 14000Hash Chain Length 1Find Copy Count 1770Latch (Share) 0

They are equal – the cache is full!!!

Proper results are deleted

Page 44: Oracle result cache highload 2017

Memory estimate

Result Cache Size = row width (bytes)* expected row count

NAME VALUEBlock Size (Bytes) 1024Block Count Maximum 4096Block Count Current 4096

Memory allocated by blocks!!!

Result Cache Size = block size (if fits in 1024) * expected row count

Page 45: Oracle result cache highload 2017

Administration23 undocumented parameters6 documented parameters

Page 46: Oracle result cache highload 2017

AdministrationParameter Purpose

RESULT_CACHE_MAX_SIZE memory allocated to the server result cache in bytes. default – 0 bytes

RESULT_CACHE_MAX_RESULT maximum amount of server result cache memory (in percent) that can be used for a single result. The default value is 5%.

RESULT_CACHE_MODE Default is MANUAL which means that the cache should be requested explicitly via the RESULT_CACHE hint

_RESULT_CACHE_TIMEOUT (undocumented)

Maximum time a session request for a latch. Default 10 sec.

6 minutes per document!!!

Page 47: Oracle result cache highload 2017

Case 2 Recommendation engineNAME VALUEBlock Size (Bytes) 1024Block Count Maximum 4096Block Count Current 4096Result Size Maximum (Blocks) 204Create Count Success 500

Create Count Failure 0Find Count 20000Invalidation Count 10000Delete Count Invalid 155Delete Count Valid 14000Hash Chain Length 1Find Copy Count 1770Latch (Share) 0

A lot of updates on source tables

Page 48: Oracle result cache highload 2017

Case 2 Recommendation engine

Page 49: Oracle result cache highload 2017

Final statistics for result cache

40 seconds per document!!!

NAME VALUEBlock Size (Bytes) 1024Block Count Maximum 4096Block Count Current 4096Result Size Maximum (Blocks) 204Create Count Success 500

Create Count Failure 0Find Count 20000Invalidation Count 10000Delete Count Invalid 155Delete Count Valid 14000Hash Chain Length 1Find Copy Count 1770Latch (Share) 0

NAME VALUEBlock Size (Bytes) 1024Block Count Maximum 8192Block Count Current 6000Result Size Maximum (Blocks) 204Create Count Success 1000

Create Count Failure 0Find Count 20000Invalidation Count 30Delete Count Invalid 155Delete Count Valid 0Hash Chain Length 1Find Copy Count 1770Latch (Share) 0

Page 50: Oracle result cache highload 2017

Case 2 Recommendation engine Auto-expiring

SHELFLIFE = read-consistent result life time in seconds

SNAPSHOT = NON-read-consistent result life time in seconds

Page 51: Oracle result cache highload 2017

Restrictions• Dictionary tables/views (sys. schema)

• Temporary and external tables

• Sequences (nextval and curval columns)

• Non-deterministic SQL functions:

current_date, current_time, local_timestamp, sys_guid…

• Non-deterministic PL/SQL function: dbms_random, hand-written, …

• Pipelined functions (returning rowsets)

• Only IN parameter with simple data types: no CLOB, BLOB, records, objects, collections, ref cursors

• The same for return result

Page 52: Oracle result cache highload 2017

Result cache inside OracleWhere in Oracle

Jobs related stuffSELECT /*+ NO_STATEMENT_QUEUING RESULT_CACHE (SYSOBJ=TRUE) */

OBJ#,SCHEDULE_LMT,PRIO,JOB_WEIGHT FROM "SYS"."SCHEDULER$_PROGRAM" WHERE bla-bla-bla

APEXSELECT /*+result_cache*/ NAME, VALUE FROM WWV_FLOW_PLATFORM_PREFS

WHERE NAME IN ( 'QOS_MAX_WORKSPACE_REQUESTS', 'QOS_MAX_SESSION_REQUESTS', bla-bla-bla

select *

from v$sqlarea

where upper(sql_fulltext) like

'%RESULT_CACHE%‘

Page 53: Oracle result cache highload 2017

Result cache inside OracleDynamic samplingSELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS RESULT_CACHE(SNAPSHOT=3600)

opt_param('parallel_execution_enabled', 'false') NO_PARALLEL(SAMPLESUB)

NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),:"SYS_B_0"),

NVL(SUM(C2),:"SYS_B_1") FROM (bla-bla-bla

Adaptive statisticSELECT /* DS_SVC */ /*+ dynamic_sampling(0) no_sql_tune no_monitoring

optimizer_features_enable(default) no_parallel RESULT_CACHE(SNAPSHOT=3600) */

NVL(SUM(C1),0) FROM (SELECT /*+ qb_name("innerQuery") NO_INDEX_FFS bla-bla-bla

Page 54: Oracle result cache highload 2017

Oracle internals for result cache

1

2

3

Page 55: Oracle result cache highload 2017

Database result cache pros&cons

Pros:- Minimal or no intervention at all into application code- No DB stored logic required- Read consistency - Fast in certain scenarios

Cons:- Cache consumes expensive memory from database- Should be properly set up- Sometimes could lead even to performance degradation- Vendor specific

Page 56: Oracle result cache highload 2017

We are not alone

Page 57: Oracle result cache highload 2017

1. Не расчитан размер кэша Troubleshooting Latch Free (Result Cache: RC Latch) Issues When The Result Cache is Full (Doc ID 2143739.1)

2. Блокировки Patch 14665745: DBMS_RESULT_CACHE.MEMORY_REPORT LOCKS OUT WRITERS TO THE RESULT CACHE

Bug 19846066 : LATCH FREE IN RESULT CACHE WHEN QUERYING V$RESULT_CACHE_OBJECTSPatch 14665745: DBMS_RESULT_CACHE.MEMORY_REPORT LOCKS OUT WRITERS TO THE RESULT CACHE

Page 58: Oracle result cache highload 2017

We are not alone

Result_cache_max_size /*+ result_cache*/ removed ordbms_result_cache.add_to_black_list or/*+ no_result_cache*/

Page 59: Oracle result cache highload 2017

We are not alone: Lessons learned

Best approach to roll out updates:

1. Adjust result cache memory

2. Disable cache before bulk loading

dbms_result_cache.bypass;

data ingestion scripts;

Issue dbms_result_cache.bypass(false);

Page 60: Oracle result cache highload 2017

Client side result cache

DBClient cache is ON

Client driver2. Configuration message

Connection thread 1

Connection thread 2

Result cache

3. SQL

Statistics messages

1. connect

1. connect 3. Cached SQL 1

4. Results

4. Results

5. Cached SQL 1

6. Results

CACHE SIZE

Page 61: Oracle result cache highload 2017

Client side result cache Invalidation Case 1

DBClient cache is ON

Client driver

Connection thread 1

Result cache

1. non-cached SQL

2. Invalid resultset list

2. Results

t last cached SQL 1 < Invalidation lag

Invalidation rules = Invalidation rules for Server Side Result Cache

Invalidation

Page 62: Oracle result cache highload 2017

Client side result cache Invalidation Case 1

DBClient cache is ON

Client driver

Result cache

1. Get invalid result set list

2. Invalid result set list

Current time = t Invalidation message + Invalidation lag

Invalidation rules = Invalidation rules for Server Side Result Cache

Invalidation

Page 63: Oracle result cache highload 2017

Client side result cache Configuration

Parameter Purpose

CLIENT_RESULT_CACHE_LAG maximum time in milliseconds that client result cache can lag behind changes in the database that affect its result sets. Default 3000 milliseconds

CLIENT_RESULT_CACHE_SIZE the maximum size of the client result set cache for each client process. Default 0 – not active, min - 32KB, max – 2G

Page 64: Oracle result cache highload 2017

Client side result cache

Page 65: Oracle result cache highload 2017

Client side result cache

Page 66: Oracle result cache highload 2017

Client side result cache

NAME VALUEBlock Size (Bytes) 256Block Count Maximum 256

Block Count Current 3

Create Count Success 1

Create Count Failure 0Find Count 9Invalidation Count 0Delete Count Invalid 0Delete Count Valid 0

= 10

Page 67: Oracle result cache highload 2017

Client side Result cache pros&consPros:

- Cheap client memory

- JDBC and .NET drivers

- Minimal or no intervention at all into application code

- Significant CPU, I/O, network roundtrip reduction

- No extra caching layer/API is required

- No latches

Cons:

- Eventual read consistency with delay

- Oracle OCI client should be installed

- Vendor specific

- 2 Gb per client limitation

- Not enough information about production

Page 68: Oracle result cache highload 2017

Hand-made cache bad scenario• Cache invalidation in case of data changes is a must

• Database stored logic isn’t in favor

• There is strong database developers team

• PL/SQL business logic is already in place

• There are limitations which don’t permit others caching techniques

Hand-made cache good scenario

Page 69: Oracle result cache highload 2017

Server side Result cache bad scenario• SQL populates a large number of distinct result sets

• SQL statement takes more than _RESULT_CACHE_TIMEOUT

• Cached results are requested very often from many sessions

Result cache good scenario• Queries have a limited number of possible result sets

• Result sets are relatively small (200-300 rows)

• SQL statements are relatively expensive

• Queries run against relatively static tables

• There is a strong DBA

Page 70: Oracle result cache highload 2017

Client side Result cache bad scenario• Instant cache invalidation in case of data changes is a must

• Thin drivers are required

• There is fine middle-tier developers team

• Middle tier uses a lot of SQL without any caching layer

• There are DB server hardware limitations

Hand-made cache good scenario

Page 71: Oracle result cache highload 2017

Conclusion1. Estimate memory size properly:

volume (Mb) = (

number of result rows * block size+

avg number of apex usage +

avg number adaptive statistic usage

)/1024

2. Add auto-cleaning capabilities with (snapshot + shelflife) options

3. Bypass the cache during bulk data changes

4. Adjust _result_cache_timeout to expected queries duration

5. Never use FORCE mode for all database

6. Check does FORCE used as expected in table annotations

7. Decide about adaptive statistics: _optimizer_ads_use_result_cache = false

Page 72: Oracle result cache highload 2017

Q&A

Page 73: Oracle result cache highload 2017

Alexander Tokarev

Database expert

DataArt

[email protected]

THANK YOU.WE ARE HIRING!