The document discusses Oracle Database result caching. It provides an overview of database caches including the result cache. It then describes a hand-made result cache implementation for a retailer case study and how it improved performance from 20 minutes to 4 minutes for a report. It also discusses using the Oracle Database result cache explicitly with hints and annotations, how to monitor and manage it using views and packages, limitations, and best practices.

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

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. Hot news from trenches!!!

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

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

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

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

8. Hand-made cache Memory
12X

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

10. Hand-made cache Not Oracle
No cache

11. Hand-made cache Not Oracle
With propopulated cache

12. Case 2 Recommendation engine
Oracle
main
Oracle
DG
Application
server
Application
server
Load
balancer
Client
browser
400 users
1000
requests
per
second
Hazelcast

13. 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. Parameter length – 100 letter.
max 10 users

14. Case 2 Recommendation engine
1. Recommendations work slow – 5 minutes for 1 document
2. To risky to change JAVA

15. 1. Do not use any cache to not care about expiration
2. Use purchased Oracle options of customer
3. Use “in-Memory for beggars” - KEEP pool for full text search

16. 1. Table with recommendations was too big
2. New DR$ tables in case of frequent index setting changes
3. KEEP pool warming is complicated (iot, lob, small table threshold, etc.)
4. DBA was reluctant to extra pool management, warming stored
procedure, additional permissions
5. Performance gain was not enough – 90 seconds per document

17. 1. Table with recommendations was too big
2. New DR$ tables in case of frequent index setting changes
3. KEEP pool warming is complicated (iot, lob, small table threshold, etc.)
4. DBA was reluctant to extra pool management, warming stored
procedure, additional permissions
5. Performance gain was not enough – 90 seconds per document

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

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

20. Result Cache Way 1
ID of result
First execution Second execution

21. Result Cache Table annotations
No query changes
but RC works

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

23. Result Cache Table annotations
2 annotations –result cache works

24. Result Cache Dependency Tracking
No in dependency list

25. Result Cache Dependency Tracking

26. Result Cache Inline Views

27. Result Cache Inline Views

28. Result Cache Simple Views

29. Result Cache Invalidation

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

31. Result Cache Invalidation
Invalidated after commit for others sessions!

32. 1. SELECT FOR UPDATE + COMMIT statements even there were no
changes at all:
- no DML statement were issued
- DML updated 0 rows
2. Update/delete statements in a table under result cache with no
records affected + an update to any table where rows were affected +
COMMIT.
SQL Result Cache Unexpected Invalidation
WTF!!!

33. SQL Result Cache Unexpected Invalidation
3. An unindexed foreign key + delete/update/insert a record from
parent table
4. Changes in an arbitrary partition even if a RC query deals with a
different single partition data. Table level tracking only.

34. Unexpected PL/SQL Invalidation Quiz
How it is possible for equal calls?

35. Unexpected PL/SQL Invalidation Quiz
No exception handler
Explicit exception
in case of error!

36. Unexpected PL/SQL Invalidation Quiz

37. Unexpected PL/SQL Invalidation
No-invalidation style – always return value!!!

38. Unexpected PL/SQL Invalidation

39. Unexpected PL/SQL Invalidation

40. 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
Performance is tested. Document recognition – 30 seconds.
Time for production

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

42. Case 2 Recommendation engine
• Active user count: 40
• Row count: 300
• Columns count: 5-8
• Parameter length: 300
• Database active session count: 120 = 40 * 3
X5 more!

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

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

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

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

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

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

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

50. Result cache latches

51. 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. Result cache bypassed after timeout.

52. 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 

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

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

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

56. Administration Patching

57. Administration Patching

58. Administration
23 undocumented parameters
6 documented parameters

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

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

61. Case 2 Recommendation engine
1. Materialize recommendations
2. Refresh on hourly basis

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

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

64. Auto-expiring Snapshot Internals
No dependencies for
RC_TAB

65. Auto-expiring Snapshot Internals

66. Auto-expiring Snapshot Internals

67. Auto-expiring Snapshot Internals
No records for RC_TAB
It happens in 5 minutes usually!

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

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

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

71. Oracle internals for result cache
1
2
3

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

73. We are not alone

74. 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
3. Не проверено исчезновение ошибки после накатов патчей

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

76. Black lists

77. Black lists

78. Black lists
There is no record with type = Result! But Dependency still in place !

79. Black lists

80. Black lists
1. Alive during runtime
2. Valid only for 12.2 Oracle

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

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

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

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

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

86. Client side result cache

87. Client side result cache

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

89. 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
- Overrides server result cache

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

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

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

93. Conclusion
1. Estimate memory size properly:
volume (Mb) = (
number of result rows * block size+
avg number of apex/scheduler usage +
avg number adaptive statistic usage
)
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

94. Q&A