Изначально будут раскрыты базовые причины, которые заставили появиться такой части механизма СУБД, как кэш результатов, и почему в ряде СУБД он есть или отсутствует. Будут рассмотрены различные варианты кэширования результатов как sql-запросов, так и результатов хранимой в БД бизнес-логики. Произведено сравнение способов кэширования (программируемые вручную кэши, стандартный функционал) и даны рекомендации, когда и в каких случаях данные способы оптимальны, а порой опасны. Для каждой из рекомендаций будут продемонстрированы как положительные так и отрицательные кейсы из опыта production-эксплуатации реальных систем, где используются разные варианты кэшей

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

2. 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

3. Agenda
• Retailer case
• Finance case
• Limitations and caveats
• Loyalty case
• Conclusion

4. Database caches
• Buffer cache – cache for data pages/data blocks
• Statement cache – cache of queries plan
• Result cache – rows from queries
• OS cache

5. Retailer case
DWH report
Oracle 11
20 Tb
300 users
20 min
350 distinct SKU
5000 rows
Select sku_id,
Shop_id,
sku_detail(sku_id),
…..
from dim_sales
where ….
Order by shop_id……..
Create or replace
function
sku_detail(sku_id
number) return
number is
Select 1
If Select 2
Else Select 3
…
…
…
Select 30
End;
400 lines of
SQL+PL/SQL
0.2 second per SKU
5000 * 0.2 = 1000 seconds

6. Retailer case Hand-made cache
DWH
report
Oracle 11
20 Tb
300 users
4 min
350 distinct SKU
5000 rows
Select sku_id,
Shop_id,
sku_detail(sku_id),
…..
from dim_sales
where ….
Order by shop_id……..
Create or replace function
sku_full(sku_id number)
return number is
Select 1
If Select 2
Else Select 3
…
…
…
Select 30
End;
400 lines of SQL+PL/SQL
0.2 second per SKU
350* 0.2 = 70 seconds
CREATE 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(sku
number) RETURN number IS
BEGIN
IF NOT cache.EXISTS(sku) THEN
cache(sku) := sku_full(sku);
END IF;
RETURN cache(sku);
END sku_detail;

7. Hand-made cache Memory
12X

8. Hand-made cache
Pros:
- 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

9. Hand-made cache Not Oracle
No cache

10. Hand-made cache Not Oracle
With propopulated cache

11. Case 2 Recommendation engine
Oracle
main
Oracle
DG
Application
server
Application
server
Load
balancer
Client
browser
4000
users
10000
requests
per
second
In-
memory
cluster

12. Case 2 Recommendation engine
Recommendation rules
1. 10 best recommendations by text match
2. Multilanguage capabilities
3. Should be taken from 12 previous recognized documents of the client
4. If there is no documents – from all clients of the same industry
5. If no in same industry – from clients similar by margin and e.t.c
max
100
rows
2-3 columns
max 100 users

13. Case 2 Recommendation engine
1 week before the Release
1. Recommendations work slow – 5 minutes for 1 document
2. Code freeze

14. 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

15. 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

16. Oracle Result Cache Way 1
ID of result
First execution Second execution

17. Oracle Result Cache Table annotations
No query changes
but RC works

18. Oracle Result Cache Table annotations
No annotation on JOBS table – no result cache

19. Oracle Result Cache Table annotations
2 annotations –result cache works

20. Oracle Result Cache Dependency Tracking
No in dependency list

21. Oracle Result Cache Dependency Tracking

22. Oracle Result Cache Inline Views

23. Oracle Result Cache Inline Views

24. Oracle Result Cache Simple Views

25. Oracle Result Cache Invalidation

26. Oracle Result Cache Invalidation
Cache is ignored for current session
Good for others sessions

27. Oracle Result Cache Invalidation
Invalidated after commit for others sessions!

28. 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.

29. 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

30. 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.

31. Case 2 Recommendation engine
• Active user count: 400
• Database active session count: 1200 = 400* 3
• Row count: 500
• Columns count: 5-8
X5 more!

32. Monitoring features
View Name Description
V$RESULT_CACHE_STATISTICS Lists cache settings and memory usage statistics
V$RESULT_CACHE_MEMORY Lists all the memory blocks and corresponding
statistics
V$RESULT_CACHE_OBJECTS Lists all the objects(cached results and
dependencies) along with their attributes
V$RESULT_CACHE_DEPENDENCY Lists the dependency details between the cached
results and dependencies
V$SQLAREA Lists SQL statements issued inside Oracle database

33. Management features
Procedure Name Description
BYPASS Instruction to ignore result cache: for current
session or for all DB
FLUSH Clean cache
MEMORY_REPORT Memory detail report
STATUS Checks the status
INVALIDATE Invalidates the specified result-set object
Package: DBMS_RESULT_CACHE

34. 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!!!

35. Case 2 Recommendation engine Investigations
Strange queries for 40 small tables each minute:
ETL

36. Case 2 Recommendation engine Investigations
Result cache annotation
Still 20 minutes per document 

37. 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!!!

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

39. Result cache latches

40. Result cache latches Type 1
When sets
First row of dataset is placed in Result Cache
When release
Last 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.

41. Result cache latches Type 2
When sets
First row of dataset is requested from Result Cache
When release
Last row of dataset is read from Result Cache
Who waits
Sessions with same SQL which requested the latch
How much
It depends 

42. Result cache latches
Latches 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.

43. Result cache statistics
NAME VALUE
Block Size (Bytes) 1024
Block Count Maximum 4096
Block Count Current 4096
Result Size Maximum
(Blocks) 204
Create Count Success 500
Create Count Failure 0
Find Count 20000
Invalidation Count 10000
Delete Count Invalid 155
Delete Count Valid 14000
Hash Chain Length 1
Find Copy Count 1770
Latch (Share) 0
They are equal – the cache is full!!!
Proper results are deleted

44. Memory estimate
Result Cache Size = row width (bytes)* expected row count
NAME VALUE
Block Size (Bytes) 1024
Block Count Maximum 4096
Block Count Current 4096
Memory allocated by blocks!!!
Result Cache Size = block size (if fits in 1024) * expected row count

45. Administration
23 undocumented parameters
6 documented parameters

46. Administration
Parameter 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!!!

47. Case 2 Recommendation engine
NAME VALUE
Block Size (Bytes) 1024
Block Count Maximum 4096
Block Count Current 4096
Result Size Maximum
(Blocks) 204
Create Count Success 500
Create Count Failure 0
Find Count 20000
Invalidation Count 10000
Delete Count Invalid 155
Delete Count Valid 14000
Hash Chain Length 1
Find Copy Count 1770
Latch (Share) 0
A lot of updates on source tables

48. Case 2 Recommendation engine

49. Final statistics for result cache
40 seconds per document!!!
NAME VALUE
Block Size (Bytes) 1024
Block Count Maximum 4096
Block Count Current 4096
Result Size Maximum
(Blocks) 204
Create Count Success 500
Create Count Failure 0
Find Count 20000
Invalidation Count 10000
Delete Count Invalid 155
Delete Count Valid 14000
Hash Chain Length 1
Find Copy Count 1770
Latch (Share) 0
NAME VALUE
Block Size (Bytes) 1024
Block Count Maximum 8192
Block Count Current 6000
Result Size Maximum
(Blocks) 204
Create Count Success 1000
Create Count Failure 0
Find Count 20000
Invalidation Count 30
Delete Count Invalid 155
Delete Count Valid 0
Hash Chain Length 1
Find Copy Count 1770
Latch (Share) 0

50. Case 2 Recommendation engine Auto-expiring
SHELFLIFE = read-consistent result life time in seconds
SNAPSHOT = NON-read-consistent result life time in seconds

51. 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

52. Result cache inside Oracle
Where in Oracle
Jobs related stuff
SELECT /*+ NO_STATEMENT_QUEUING RESULT_CACHE (SYSOBJ=TRUE) */
OBJ#,SCHEDULE_LMT,PRIO,JOB_WEIGHT FROM "SYS"."SCHEDULER$_PROGRAM" WHERE bla-bla-bla
APEX
SELECT /*+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%‘

53. Result cache inside Oracle
Dynamic sampling
SELECT /* 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 statistic
SELECT /* 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

54. Oracle internals for result cache
1
2
3

55. 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

56. We are not alone

57. 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_OBJECTS
Patch 14665745: DBMS_RESULT_CACHE.MEMORY_REPORT LOCKS OUT WRITERS TO THE RESULT CACHE

58. We are not alone
Result_cache_max_size /*+ result_cache*/ removed or
dbms_result_cache.add_to_black_list or
/*+ no_result_cache*/

59. 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);

60. Client side result cache
DB
Client cache is ON
Client driver
2. 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

61. Client side result cache Invalidation Case 1
DB
Client 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

62. Client side result cache Invalidation Case 1
DB
Client 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

63. 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

64. Client side result cache

65. Client side result cache

66. Client side result cache
NAME VALUE
Block Size (Bytes) 256
Block Count Maximum 256
Block Count Current 3
Create Count Success 1
Create Count Failure 0
Find Count 9
Invalidation Count 0
Delete Count Invalid 0
Delete Count Valid 0
= 10

67. Client side Result cache pros&cons
Pros:
- 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

68. 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

69. 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

70. 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

71. Conclusion
1. 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

72. Q&A

73. Alexander Tokarev
Database expert
DataArt
Alexander.Tokarev@dataart.com
THANK YOU.
WE ARE HIRING!