Oracle 11g Server Result Cache Result_cache_mode

Source: Internet
Author: User
Tags sorts

For the result set that is often checked, a small number of records are returned, the server side is cacheable, the result set is stored in the shared pool, the binding variable is assumed, and the value of the bound variable is the same.

Sql> Show Parameter Result_cache
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
Client_result_cache_lag Big Integer 3000
Client_result_cache_size Big Integer 0
Result_cache_max_result Integer 5
Result_cache_max_size Big Integer 33440K
Result_cache_mode stringManual
Result_cache_remote_expiration integer 0
--result_cache_max_result Specifies that no matter what single result set can use the size of result_cache_max_size (in percent), it defaults to 5, agreeing to a value from 1 to 100, The result set exceeding this limit is invalidated by two colors.
--result_cache_max_size Specifies the size of the shared pool memory used as the result cache, assuming that it is set to 0, indicating that this feature is disabled.

--Theresult_cache_mode hypothesis is set to MANUAL (which is also the default), only the ability to use the result cache when specifying hint Result_cache; When force, all does not include hint No_ Result_cache query Statements will use the result cache, the second time the query takes effect, and when auto, the same SQL is executed at 11g for the third time, the cache does not work.

< Span style= "FONT-FAMILY:SIMSUN; line-height:22px ">--result_cache_remote_expiration The lifetime of the cached remote object (in minutes), usually feels 0, which means that the caching of query results based on remote objects is forbidden.

-- Result_cache_max_result and result_cache_max_size is a system-level setting, result_cache_mode and result_cache_remote_ Expiration can be changed at the session level.

sql> alter system set Result_cache_mode=force

Sql> SELECT COUNT (1)
2 from Gg_distribution W
3 WHERE w.data_area like ' 03 ' | | ‘%‘
4 and W.create_date > to_date (' 2013-01-01 ', ' yyyy-gg-dd ');
Time used: 00:00:22.48
Run a plan
----------------------------------------------------------
Plan Hash value:3923546474
-------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU) | Time | Pstart| Pstop |
-------------------------------------------------------------------------------------------------------------
| 0 |                 SELECT STATEMENT |     |    1 |   14 | 106K (1) |       00:24:46 |       | |
|  1 |                 SORT AGGREGATE |     |    1 |            14 |          |       |       | |
|   2 |                 PARTITION RANGE All |  |    2173k|   29m| 106K (1) |     00:24:46 |     1 | 2 |
|    3 |                 PARTITION LIST iterator|  |    2173k|   29m| 106K (1) |   00:24:46 |   KEY | KEY |
|* 4 | TABLE ACCESS Full |  gg_distribution |    2173k|   29m| 106K (1) |     00:24:46 |    1 | 48 |
-------------------------------------------------------------------------------------------------------------
predicate information (identified by Operation ID):
---------------------------------------------------
4-filter ("W". " Create_date ">to_date (' 2013-01-01 00:00:00 ', ' syyyy-gg-dd hh24:mi:ss ') and
"W". " Data_area "like ' 3% ')
Statistical information
----------------------------------------------------------
0 Recursive calls
0 db Block gets
280123 consistent gets
263679 Physical Reads
0 Redo Size
339 Bytes sent via sql*net to client
337 Bytes received via sql*net from client
2 sql*net roundtrips To/from Client
0 Sorts (memory)
0 Sorts (disk)
1 rows processed

Sql>/
Time used: 00:00:00.11
Run a plan
----------------------------------------------------------
Plan Hash value:3923546474
--------------------------------------------------------------------------------------------------------------- ----------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU) | Time | Pstart| Pstop |
--------------------------------------------------------------------------------------------------------------- ----------
| 0 |                            SELECT STATEMENT |     |    1 |   14 | 106K (1) |       00:24:46 |       | |
|  1 | RESULT CACHE |       0MR1089P1WXV3919RAQYVTWTSV |       |            |       |  |       | |
|   2 |                            SORT AGGREGATE |     |    1 |            14 |       |  |       | |
|    3 |                            PARTITION RANGE All |  |    2173k|   29m| 106K (1) |     00:24:46 |     1 | 2 |
|     4 |                            PARTITION LIST iterator|  |    2173k|   29m| 106K (1) |   00:24:46 |   KEY | KEY |
|* 5 | TABLE ACCESS Full |  gg_distribution |    2173k|   29m| 106K (1) |     00:24:46 |    1 | 48 |
--------------------------------------------------------------------------------------------------------------- ----------
predicate information (identified by Operation ID):
---------------------------------------------------
5-filter ("W". " Create_date ">to_date (' 2013-01-01 00:00:00 ', ' syyyy-gg-dd hh24:mi:ss ') and" W "." Data_area "
Like ' 3% ')
Result Cache Information (identified by Operation ID):
-----------------------------------------------------
1-column-count=1; Dependencies= (lcam_test. Gg_distribution); Attributes= (Single-row); Parameters= (NLS); Name= "Select COUNT (1)
From Gg_distribution W
WHERE w.data_area like ' 03 ' | | ‘%‘
and W.create_date > To_date (' 2013-01-01 ', ' yyyy-'
Statistical information
----------------------------------------------------------
1 Recursive calls
0 db Block gets
0 consistent gets
0 physical Reads
0 Redo Size
339 Bytes sent via sql*net to client
337 Bytes received via sql*net from client
2 sql*net roundtrips To/from Client
0 Sorts (memory)
0 Sorts (disk)
1 rows processed

0MR1089P1WXV3919RAQYVTWTSV finds its cached information.

< Span style= "FONT-FAMILY:SIMSUN; line-height:22px "> sql> Select S.status,
           s.creation_timestamp,
           s.build_time,
       -& nbsp  s.row_count,
           s.scan_count
      from V$result_cache _objects s
     where cache_id = ' 0MR1089P1WXV3919RAQYVTWTSV ';
STATUS    creation_times build_time  row_count scan_count
--------------------------------------- --------------
Published 20月-June -14            700          1 &N Bsp      

Limit of result cache:

cannot be cached when a query statement uses nondeterministic functions, serial numbers, and temporal tables.

Query statements can result in inconsistent data.

Query statements referencing to the data dictionary view cannot be cached.

Ability to manage caches using Dbms_result_cache.

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.