RESULT_CACHE hint

I am trying to figure out why the explain plan (and performance) for the same query is different between our staging environment and our production environment when using the RESULT_CACHE hint. It's significantly worse in production. Platform and database version is the same. There are differences in the init settings between the two environments, specifically the following:
In Stage:
optimizer_mode = first_rows_100
result_cache_mode=manual
result_cache_max_result=5
result_cache_max_size=7872K
cursor_sharing=similar
In Prod:
optimizer_mode =
result_cache_mode=
result_cache_max_result=
result_cache_max_size=
cursor_sharing=exact
When I run the query in Stage, the explain plan looks like this:
Execution Plan
Plan hash value: 3058471186
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 263 | 8 (13)| 00:00:01 |
|* 1 | FILTER | | | | | |
| 2 | HASH GROUP BY | | 1 | 263 | 8 (13)| 00:00:01 |
| 3 | NESTED LOOPS | | 1 | 263 | 7 (0)| 00:00:01 |
|* 4 | TABLE ACCESS BY INDEX ROWID| C11_HOLDINGS | 1 | 195 | 4 (0)| 00:00:01 |
|* 5 | INDEX RANGE SCAN | HOLDING_CALC2_IDX | 1 | | 3 (0)| 00:00:01 |
|* 6 | TABLE ACCESS BY INDEX ROWID| C11_HOLDINGS | 1 | 68 | 3 (0)| 00:00:01 |
|* 7 | INDEX RANGE SCAN | HOLDING_CALC_IDX | 1 | | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter("STATEMENT_DATE"=MAX("STATEMENT_DATE"))
4 - filter(UPPER("SYMBOL")=UPPER(NVL(NULL,"SYMBOL")) AND "SECURITY_TYPE"<>'NO REVIEW
REQUIRED' AND ("STATEMENT_DATE">=INTERNAL_FUNCTION("STATEMENT_DATE")-.0000115740740740740740
7407407407407407407407 OR "STATEMENT_DATE"=NULL) AND "ACTIVE_FLAG"='Y' AND
"STATEMENT_DATE"<=SYSDATE@!-3)
5 - access("BROKERAGE_ACCOUNT_ID"=14873 AND "USER_ID"=39356 AND "CLIENT_ID"=609)
6 - filter("B"."ACTIVE_FLAG"='Y' AND "B"."STATEMENT_DATE"<=SYSDATE@!-3 AND
"A"."SYMBOL"="B"."SYMBOL")
7 - access("B"."BROKERAGE_ACCOUNT_ID"=14873 AND "B"."USER_ID"=39356 AND
"B"."CLIENT_ID"=609 AND "A"."SECURITY_TYPE"="B"."SECURITY_TYPE")
filter("B"."SECURITY_TYPE"<>'NO REVIEW REQUIRED')
Statistics
0 recursive calls
0 db block gets
1356 consistent gets
0 physical reads
0 redo size
1904 bytes sent via SQL*Net to client
360 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
3 rows processed
When I run it in Prod:
Execution Plan
Plan hash value: 1021161140
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 252 | 239 (1)| 00:00:03 |
| 1 | NESTED LOOPS | | | | | |
| 2 | NESTED LOOPS | | 1 | 252 | 239 (1)| 00:00:03 |
| 3 | VIEW | VW_SQ_1 | 1 | 88 | 236 (1)| 00:00:03 |
|* 4 | FILTER | | | | | |
| 5 | HASH GROUP BY | | 1 | 83 | 236 (1)| 00:00:03 |
|* 6 | TABLE ACCESS BY INDEX ROWID| C11_HOLDINGS | 256 | 21248 | 235 (0)| 00:00:03 |
|* 7 | INDEX RANGE SCAN | HOLDING_CALC2_IDX | 512 | | 5 (0)| 00:00:01 |
|* 8 | INDEX RANGE SCAN | HOLDINGS_SYMB_IDX | 1 | | 2 (0)| 00:00:01 |
|* 9 | TABLE ACCESS BY INDEX ROWID | C11_HOLDINGS | 1 | 164 | 3 (0)| 00:00:01 |
Predicate Information (identified by operation id):
4 - filter("B"."BROKERAGE_ACCOUNT_ID"=14873 AND "B"."USER_ID"=39356 AND
"B"."CLIENT_ID"=609 AND MAX("STATEMENT_DATE")<=SYSDATE@!-3)
6 - filter("B"."ACTIVE_FLAG"='Y' AND "B"."STATEMENT_DATE"<=SYSDATE@!-3 AND
"B"."SECURITY_TYPE"<>'NO REVIEW REQUIRED')
7 - access("B"."BROKERAGE_ACCOUNT_ID"=14873 AND "B"."USER_ID"=39356 AND
"B"."CLIENT_ID"=609)
8 - access("A"."SYMBOL"="ITEM_5")
filter(UPPER("SYMBOL")=UPPER(NVL(NULL,"SYMBOL")))
9 - filter("BROKERAGE_ACCOUNT_ID"=14873 AND "USER_ID"=39356 AND "CLIENT_ID"=609 AND
"ACTIVE_FLAG"='Y' AND "SECURITY_TYPE"<>'NO REVIEW REQUIRED' AND
("STATEMENT_DATE">=INTERNAL_FUNCTION("STATEMENT_DATE")-.00001157407407407407407407407407407407
407407 OR "STATEMENT_DATE"=NULL) AND "STATEMENT_DATE"<=SYSDATE@!-3 AND
"STATEMENT_DATE"="MAX(STATEMENT_DATE)" AND "A"."SECURITY_TYPE"="ITEM_4")
Statistics
0 recursive calls
0 db block gets
18051 consistent gets
0 physical reads
0 redo size
1872 bytes sent via SQL*Net to client
360 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
3 rows processed
The queries and the data in both environments are identical. Any ideas, suggestions would be appreciated.
Thanks

Interestingly, the explain plans are identical to what they were with the result_cache hint.

Similar Messages

  • What's wrong with the following result_cache hint?

    Dear all,
    I try to use result_cache hint in the following sql aggregate function statement, but the explain plan doesn't show any difference between non-result_cached and with result_cached:
    SQL> set autot on explain stat
    SQL> select account_mgr_id,count(*) from customers group by account_mgr_id;
    ACCOUNT_MGR_ID      COUNT(*)
            147            76
            149            74
            148            58
            145           111
    Execution Plan
    Plan hash value: 1577413243
    | Id  | Operation        | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT   |            |     4 |    16 |     6     (17)| 00:00:01 |
    |   1 |  HASH GROUP BY        |            |     4 |    16 |     6     (17)| 00:00:01 |
    |   2 |   TABLE ACCESS FULL| CUSTOMERS |   319 |  1276 |     5      (0)| 00:00:01 |
    Statistics
           0  recursive calls
           0  db block gets
          16  consistent gets
           0  physical reads
           0  redo size
         689  bytes sent via SQL*Net to client
         524  bytes received via SQL*Net from client
           2  SQL*Net roundtrips to/from client
           0  sorts (memory)
           0  sorts (disk)
           4  rows processed
    SQL> select /*+ result_cache */ account_mgr_id,count(*) from customers group by account_mgr_id;
    ACCOUNT_MGR_ID      COUNT(*)
            147            76
            149            74
            148            58
            145           111
    Execution Plan
    Plan hash value: 1577413243
    | Id  | Operation         | Name                | Rows  | Bytes | Cost (%CPU)| Time      |
    |   0 | SELECT STATEMENT    |                     |     4 |    16 |     6  (17)| 00:00:01 |
    |   1 |  RESULT CACHE         | 3s3bugtq0p5bm71mhmqvvw0x7y |      |      |           |       |
    |   2 |   HASH GROUP BY     |                     |     4 |    16 |     6  (17)| 00:00:01 |
    |   3 |    TABLE ACCESS FULL| CUSTOMERS            |   319 |  1276 |     5   (0)| 00:00:01 |
    Result Cache Information (identified by operation id):
       1 - column-count=2; dependencies=(OE.CUSTOMERS); name="select /*+ result_cache */ account_mgr_id,
    count(*) from customers group by account_mgr_id"
    Statistics
           1  recursive calls
           0  db block gets
          16  consistent gets
           0  physical reads
           0  redo size
         689  bytes sent via SQL*Net to client
         524  bytes received via SQL*Net from client
           2  SQL*Net roundtrips to/from client
           0  sorts (memory)
           0  sorts (disk)
           4  rows processedAnything wrong with the hint?
    Best regards,
    Val

    Two executions required to benefit from result cache (two executions of the statement with the result cache hint).
    First to populate, Second to benefit.
    Can offer good benefits particularly with poor code - e.g. functions in SQL, row-by-row function calls, etc.
    Optimal solution may be to refactor to more efficient approach.
    But result cache can deliver significant short term tactical gain.
    Not a no-brainer though.
    There were scalability issues with a single latch protecting the result cache - I believe this has changed in 11gR2.
    There are also issues with concurrent executions were the result needs to be recalculated and takes x time to regenerate that result.
    See http://uhesse.wordpress.com/2009/11/27/result-cache-another-brilliant-11g-new-feature/#comment-216
    SQL> drop table t1;
    Table dropped.
    SQL>
    SQL> create table t1
      2  as
      3  select rownum col1
      4  from   dual
      5  connect by rownum <= 100000;
    Table created.
    SQL> set autotrace traceonly explain statistics
    SQL> select col1
      2  from   t1
      3  where  col1 >= 99997;
    Execution Plan
    Plan hash value: 3617692013
    | Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |      |    10 |   130 |    58   (9)| 00:00:01 |
    |*  1 |  TABLE ACCESS FULL| T1   |    10 |   130 |    58   (9)| 00:00:01 |
    Predicate Information (identified by operation id):
       1 - filter("COL1">=99997)
    Note
       - dynamic sampling used for this statement (level=4)
    Statistics
             10  recursive calls
              0  db block gets
            220  consistent gets
            153  physical reads
              0  redo size
            379  bytes sent via SQL*Net to client
            334  bytes received via SQL*Net from client
              2  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              4  rows processed
    SQL> select col1
      2  from   t1
      3  where  col1 >= 99997;
    Execution Plan
    Plan hash value: 3617692013
    | Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |      |    10 |   130 |    58   (9)| 00:00:01 |
    |*  1 |  TABLE ACCESS FULL| T1   |    10 |   130 |    58   (9)| 00:00:01 |
    Predicate Information (identified by operation id):
       1 - filter("COL1">=99997)
    Note
       - dynamic sampling used for this statement (level=4)
    Statistics
              0  recursive calls
              0  db block gets
            158  consistent gets
              0  physical reads
              0  redo size
            379  bytes sent via SQL*Net to client
            334  bytes received via SQL*Net from client
              2  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              4  rows processed
    SQL>
    SQL>
    SQL> select /*+ result_cache */ col1
      2  from   t1
      3  where  col1 >= 99997;
    Execution Plan
    Plan hash value: 3617692013
    | Id  | Operation          | Name                       | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT   |                            |    10 |   130 |    58   (9)| 00:00:01 |
    |   1 |  RESULT CACHE      | 4p777jcbdgjm25xy3502ypdb5r |       |       |            |          |
    |*  2 |   TABLE ACCESS FULL| T1                         |    10 |   130 |    58   (9)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - filter("COL1">=99997)
    Result Cache Information (identified by operation id):
       1 - column-count=1; dependencies=(RIMS.T1); name="select /*+ result_cache */ col1
    from   t1
    where  col1 >= 99997"
    Note
       - dynamic sampling used for this statement (level=4)
    Statistics
              4  recursive calls
              0  db block gets
            216  consistent gets
              0  physical reads
              0  redo size
            379  bytes sent via SQL*Net to client
            334  bytes received via SQL*Net from client
              2  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              4  rows processed
    SQL>
    SQL>
    SQL> select /*+ result_cache */ col1
      2  from   t1
      3  where  col1 >= 99997;
    Execution Plan
    Plan hash value: 3617692013
    | Id  | Operation          | Name                       | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT   |                            |    10 |   130 |    58   (9)| 00:00:01 |
    |   1 |  RESULT CACHE      | 4p777jcbdgjm25xy3502ypdb5r |       |       |            |          |
    |*  2 |   TABLE ACCESS FULL| T1                         |    10 |   130 |    58   (9)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - filter("COL1">=99997)
    Result Cache Information (identified by operation id):
       1 - column-count=1; dependencies=(RIMS.T1); name="select /*+ result_cache */ col1
    from   t1
    where  col1 >= 99997"
    Note
       - dynamic sampling used for this statement (level=4)
    Statistics
              0  recursive calls
              0  db block gets
              0  consistent gets
              0  physical reads
              0  redo size
            379  bytes sent via SQL*Net to client
            334  bytes received via SQL*Net from client
              2  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              4  rows processed
    SQL>

  • Hint /*+result_cache*/?

    Hi guys,
    11g introduce a new feature for sql query call 'result cache', I'm curious to know, does this mechanism work if i DON'T add a /*+result_cache*/ HINT to my select statement?  anyone have any clues?
    Many thanks.

    Morven,
    If result cache feature is enabled at server, then in SQL is supported by RESULT_CACHE hint only. For MANUAL result_cache_mode, the hint is a necessary practise. If u omit this in query, query will run conventionally.
    Also u can test by changing the RESULT_CACHE_MODE to FORCE.

  • Result Cache hint in Oracle 11 g

    I have a problem with the RESULT_CACHE hint , this has been used in the various function in our database e.g
    Function xyz (input IN table1.col1%type)
    RETURN BOLEAN
    RESULT_CACHE
    AS
    DATE_VALUE DATE;
    BEGIN
    SELECT x INTO DATE_VALE FROM TABLE2 WHERE COLUMN3=INPUT;
    IF DATE_VALUE <SYSDATE
    RETURN TRUE;
    ELSE
    RETURN FALSE;
    END IF;
    EXCEPTION WHEN NO_DATA_FOUND
    THEN
    RETURN FALSE;
    END;
    Now the value of DATE_VALUE is fetched in stored in cache, based on the input . but the value of DATE_value is changed after some db operations .
    Oracle will return the same value even after the value has been changed for the same input (assume that the true/false is changed after the date_value is changed. )
    So clearly in this function RESULT_CACHE has not been used correctly.
    what could be the solution for this , Result_cache has been used in 20+ function and code change is not possible at this time.
    can we use DBMS_RESULT_CACHE.BYPASS(TRUE) ;
    is it at instance level , or session level. we will be running oracle job using the procedure which uses this function ,so before each job do we need to run this pkg.(DBMS_RESULT_CACHE.BYPASS(TRUE)) ?
    we do not want to use FLUSH as we will have to do it every time before the job runs .
    or any other solution .
    DATABASE Details are :
    Oracle 11g Enterprise edition 11.1.0.7.0- 64 bit
    HPUX version 11.1.0.7.0

    Su**** wrote:
    Yes Tubby you are correct,
    removing the result_cache from function is the permanent solution here,
    But I want to know if anyone have encountered the same problem and use the BYPASS ,FLUSH etc to get a temporary solution . Thanks much.Your application has a bug. It has a bug because your developers didn't have time, or didn't care to read the documentation and understand what they were doing.
    Why would you not want to fix that bug, choosing a workaround that may or may not work, and may or may not have undesired side effects on other portions of your application when the obvious solution is to remove the RESULT_CACHE from the function declaration where it was erroneously placed to begin with?
    Worst case scenario, you remove that and the application works slower ... but correctly. I don't see how that's problematic.
    Cheers,

  • Reg: result_cache in parallel -

    Hi Experts,
    I have few concern(s) regarding the Result Cache (introduced in 11gR2) and the /*+ RESULT_CACHE */ hint.
    Refering to -
    Doc 12.1 - Tuning the Result Cache
    Murali Vallath - Using Oracle Database 11g Release 2 Result Cache in an Oracle RAC Environment
    Adrian Billington -- query result cache in oracle 11g
    Concerns -
    (1) Suppose I have a master ETL job which has 5 sub-jobs. These sub-jobs are executed in parallel i.e. started all at once from ETL.
    Each of these sub-job executes an extraction query and pulls data from database.
    In each of these sub-job queries, there's a subquery which is common. I am thinking to provide /*+ RESULT_CACHE */ to this common subquery.
    But my actual concern - since all the extraction queries (i.e. sub-jobs) are started in parallel, will the Result Cache thing come into picture?
    (2) For how long the data is retained in the cache?
    A wild guess - till the point we execute the DBMS_RESULT_CACHE.FLUSH procedure ?
    (3) Any caveats?
    (Trying to fix few costly time-consuming queries, and suddenly this option came to my mind. Took the opportunity to look at this cool feature, at the same time understanding the caveats, if any)
    Please advise me on this.
    -- Ranit
    (on Oracle 11.2.0.3.0)

    Hi.
    2.1) 50Mb can store approximately 50Mb of data. The amount of stuff you can sore depends a number of factors, including:
    - How many queries or function calls are being cached.
    - With respect to the query cache, how wide are the rows. We are talking size of data in the columns.
    - How many rows are being returned.
    So you might have a few larger result sets, or many small ones.
    2.2) Well, it can't. The RESULT_CACHE_MAX_RESULT parameter determines the maximum size of a result set that will be considered for caching. By default it is set to 5, which means 5% of the size. So let's say you have a result cache of 100Mb. By default, a result set in excess of 5Mb will not be considered for caching. This stops you wiping out useful information in the cache by trying to cache one big result set.
    The reality is, if you start to use this feature you will have to monitor the cache performance and be selective about what you cache and what you don't. The default sizing parameters are not going to be suitable for everyone. You need to alter them based on your monitoring. Nobody in a forum will be able to tell you figures to set. If it were that easy, Oracle would do it for you.
    Regarding your "alternative solution", I don't really want to comment on that specifically because I don't know enough about the system. Typically, it would not be something I would do, but maybe it is the right thing for you to do in your case. Impossible for me to know. Things to consider in preference to your alternative solution.
    - Scalar subquery caching: If the subqueries are scalar subqueries (pulling back a single column/object in a single row), it will already be taking advantage of scalar subquery caching, so your alternative solutions may actually give worse performance. There is no sharing between SQL statements or sessions.
    ORACLE-BASE - Efficient Function Calls From SQL
    - Use a WITH clause to replace the subqueries and use the materialize hint. This way, the subquery is automatically materialized into temp segments, so multiple references to it within a single statement query the result from the temp segments, rather than the full subquery. There is no sharing between SQL statements or sessions.
    ORACLE-BASE - WITH Clause : Subquery Factoring
    The reality is, there is not going to be a "best" solution that works for all cases. What you need to do is try several approaches and pick the one that works best for your circumstances. The next time you run into a similar issue, you can't assume what you did last time is the right solution this time...
    Regardless of which option you pick, you need to read the docs and feel comfortable with the tech before you launch down the path. No matter how good a feature is, if you use it badly you will make that feature look bad. 
    Cheers
    Tim...

  • Apex using result_cache has an invalid status for wwv_flow_language query

    In the v_$result_cache_objects view of SYS I noticed that Apex is using the result_cache feature of 11g.
    Some of the Apex queries will have the status 'PUBLISHED', but others have the status 'INVALID'
    Why does the "SELECT /*+ result_cache */ NLS_LANGUAGE, NLS_TERRITORY, NLS_SORT, NLS_WINDOWS_CHARSET FROM WWV_FLOW_LANGUAGES WHERE LANG_ID_UPPE..." query has a INVALID status?
    It already happens when I start APEX (http://localhost:7778/pls/apex).
    As I understand the result_cache method it will invalidate the cache after an update is done on the depending table.
    Does it make sense that those Apex queries has a result_cache hint when it will be invalidated soon after?

    Hi,
    just had a look at our own development box and for me this query doesn't show the status INVALID. It would also not make a lot of sense because this table is only populated during installation.
    When you shutdown your database and start it up again and then access APEX with http://localhost:7778/pls/apex to see the query in invalid status?
    Regards
    Patrick
    My Blog: http://www.inside-oracle-apex.com
    APEX 4.0 Plug-Ins: http://apex.oracle.com/plugins
    Twitter: http://www.twitter.com/patrickwolf

  • SQL strange behavior after 11g upgrade

    Hi all,
    After upgrading from 10.2.0.3 to 11.2.0.1 (64-bit RedHat), one of my SQLs behaves very strangely.
    These are the facts:
    - This is upgrade evaluation phase in 'lab' environment
    - First run (after db restart) returns results very quickly (acceptable 0.4 secs)
    - Every consecutive run is very slow (3-4 minutes)
    - Explain Plan did NOT change between runs;
    - Number of 'consistent gets' changed drastically (from few thousands to few millions) ...which would usually lead to inefficient data access plan (index), but again, the explain plan did not change!
    - If I flush shared_pool, next run is quick again, and the story repeats ... flushing shared_poll is possible in test system only, it's out of question for prod system of course
    - All above happens in 'lab' environment, i.e. no multi-user load yet ... practically 'one-session' system
    - I have tried both AMM and ASSM memory management(s) and same problem happens regardless (my old 10g database uses ASSM and I am trying to implement ASM in new 11g db)
    - On same server, the SQL in question performs correctly if I run it in 10g environment;
    - I have updated my 11g Oracle software/db with the latest CPU;
    In addition, I have played with 'result cache' in 11g, and putting 'result_cache' hint in my sql resolved the issue. But that will open a lot of new questions for implementation in real app environment ... so at this moment, I don't want to evaluate result cache ...if I don't have to
    I am thinking to try this on another server and eliminate eventual issue with some kind of faulty memory on existing server ... after that - to open ticket with Oracle ...
    Any similar experience out there? Any thoughts?
    Thanks a lot ...

    Welcome to the forums !
    How to post a tuning request
    HOW TO: Post a SQL statement tuning request - template posting
    When your query takes too long ...
    HTH
    Srini

  • Using the Client Result Cache

    Hello everyone,
    I have a question regarding the use of the client result cache but first of all here are the informations about my database:
    SQL> SELECT * FROM v$version;
    BANNER
    Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
    PL/SQL Release 11.2.0.1.0 - Production
    CORE    11.2.0.1.0    Production
    TNS for Linux: Version 11.2.0.1.0 - Production
    NLSRTL Version 11.2.0.1.0 - Production
    I have installed the Oracle Client Tools on my clientmachine. It has a tnsnames.ora like this:
    ORCL =
      (DESCRIPTION =
        (ADDRESS_LIST =
          (ADDRESS = (PROTOCOL = TCP)(HOST = FEA11-119SRV)(PORT = 1521))
        (CONNECT_DATA =
          (SERVICE_NAME = orcl.local)
    The Client Result Cache is configured in the sqlnet.ora.
    ADR_BASE = /u01/app/oracle
    OCI_RESULT_CACHE_MAX_SIZE= 2048000
    OCI_RESULT_CACHE_MAX_RSET_SIZE = 1024000
    NAMES.DIRECTORY_PATH = (EZCONNECT, TNSNAMES, HOSTNAME)
    The Databaseserver is configured like that:
    SQL> col name format a30
    SQL> col value format a30
    SQL> SELECT name, value
      2  FROM   v$system_parameter
      3  WHERE  name LIKE '%result_cache%';
    NAME                   VALUE
    result_cache_mode           MANUAL
    result_cache_max_size           0
    result_cache_max_result        5
    result_cache_remote_expiration 0
    client_result_cache_size       1073741824
    client_result_cache_lag        3000
    After configuring client an server I try the followign SQL-Statement on the clientmachine:
    sqlplus oracle/password@orcl
    set autotrace traceonly explain
    SELECT /*+ result_cache */ *
    FROM testtable;
    SQL
    The execution plan show two operations: "SELECT STATEMENT" and "TABLE ACCESS FULL" but no the "RESULT CACHE" operation.
    Did I miss something?
    Any help would be appreciated
    Florian W.

    result_cache_max_size           0
    That means the result cache is disabled. You need to set it to a non-zero value. That is the maximum ammount of memory, in bytes, the database will allocate on the shared pool to dedicate it to the result cache for all requests.
    By the way, OCI_RESULT_CACHE_MAX_SIZE is optional. By default the sessions will have the maximum size they can occupy on the cache determined by CLIENT_RESULT_CACHE parameter, the client (OCI) side parameters override that.
    result_cache_mode           MANUAL
    Another thing to consider is RESULT_CACHE_MODE in MANUAL, that will cause only the statements with the RESULT_CACHE hint on it to be cached on the result cache. You can also set result cache to mode FORCE on specific tables with alter table command.
    Regards

  • Query executes faster 2nd time

    Hi,
    So, the result% parameters are as follows, on a specific instance:
    AME                                                                                   TYPE VALUE
    result_cache_mode                                                                         2 MANUAL
    result_cache_max_size                                                                     6 20971520
    result_cache_max_result                                                                   3 5
    result_cache_remote_expiration                                                            3 0
    Executed in 0,156 secondsWell, if i run first time a large query, which takes much time (WITHOUT result_cache hint), this executes in 10 minutes. Then, some of my collegue said me second time i run the query i obtain the results faster than the first time, but i told him caching is not enabled, so why we got faster the results? The query execution plan is the same.
    So, are any buffers, or something, from which the database retrieves the results when executing again that query? Or any explanation why it executes faster on subsequent invocations?
    Thanks

    Roger22 wrote:
    So even if the result caching is not used, the data can be retrieved from the buffers.? okA fundamental concept for all databases and all modern file systems. A read-write memory cache that sits between the s/w and spinning rust.
    Also the basic reason why measuring performance for comparison using elapsed time is flawed - as the very SAME query with the SAME execution plan on the SAME data can show DIFFERENT elapsed times. Amount of I/O is constant, but the type of I/O (logical/fast versus physical/slow) is not.

  • Oracle Performance tunning genral question

    Hi,
    Below is the list of Areas of Oracle db for which tunning activities are done. You are invited to comment to it weather this is complete list or need some addition or deletion. As I'm learning PT for Oracle now a days, therefore I want to expand my knowledge by sharing what I'm learning and what I need to learn.
    So comment with Open hearts on it. Espically from experts and Gurus.
    Here is the List
    1-Planning for Performance, include Storage consideration( Weather it is SAN, NAS, DAS), Network planning and host OS planning with proper configuration for running Oracle.
    2-Database desining (Not under-Normalized and not Over-Normalized with proper usage of Indexes, views and Stored Procedures)
    3- Instance tunning (Memory structure + B.g Processes)
    4- Session tunning.
    5- Segment Space tunning.
    6- SQL tunning.
    This is what uptill what I've learned. If it needs addition kindly tell me what are these. Please also provide me links(good and precise one) for PT tutorials on web.Also note that I'm discussing this w.r.t Single instance non-rac db.
    Looking for Good sugessions
    Regards,
    Abbasi

    Hello,
    This is the oracle course contents:
    Contents
    Preface
    1 Introduction
    Course Objectives 1-2
    Organization 1-3
    Agenda 1-4
    What Is Not Included 1-6
    Who Tunes? 1-7
    What Does the DBA Tune? 1-8
    How to Tune 1-10
    Tuning Methodology 1-11
    Effective Tuning Goals 1-13
    General Tuning Session 1-15
    Summary 1-17
    2 Basic Tuning Tools
    Objectives 2-2
    Performance Tuning Diagnostics 2-3
    Performance Tuning Tools 2-4
    Tuning Objectives 2-5
    Top Wait Events 2-6
    DB Time 2-7
    CPU and Wait Time Tuning Dimensions 2-8
    Time Model: Overview 2-9
    Time Model Statistics Hierarchy 2-10
    Time Model Example 2-12
    Dynamic Performance Views 2-13
    Dynamic Performance Views: Usage Examples 2-14
    Dynamic Performance Views: Considerations 2-15
    Statistic Levels 2-16
    Statistics and Wait Events 2-18
    System Statistic Classes 2-19
    Displaying Statistics 2-20
    Displaying SGA Statistics 2-22
    Wait Events 2-23
    Using the V$EVENT_NAME View 2-24
    Wait Classes 2-25
    Displaying Wait Event Statistics 2-26
    Oracle Internal & Oracle Academy Use Only
    iv
    Commonly Observed Wait Events 2-28
    Using the V$SESSION_WAIT View 2-29
    Precision of System Statistics 2-31
    Using Features of the Packs 2-32
    Accessing the Database Home Page 2-34
    Enterprise Manager Performance Pages 2-35
    Viewing the Alert Log 2-37
    Using Alert Log Information as an Aid in Tuning 2-38
    User Trace Files 2-40
    Background Processes Trace Files 2-41
    Summary 2-42
    Practice 2 Overview: Using Basic Tools 2-43
    3 Using Automatic Workload Repository
    Objectives 3-2
    Automatic Workload Repository: Overview 3-3
    Automatic Workload Repository Data 3-4
    Workload Repository 3-5
    Database Control and AWR 3-6
    AWR Snapshot Purging Policy 3-7
    AWR Snapshot Settings 3-8
    Manual AWR Snapshots 3-9
    Managing Snapshots with PL/SQL 3-10
    Generating AWR Reports in EM 3-11
    Generating AWR Reports in SQL*Plus 3-12
    Reading the AWR Report 3-13
    Snapshots and Periods Comparisons 3-14
    Compare Periods: Benefits 3-15
    Compare Periods: Results 3-16
    Compare Periods: Report 3-17
    Compare Periods: Load Profile 3-18
    Compare Periods: Top Events 3-19
    Summary 3-20
    Practice 3 Overview: Using AWR-Based Tools 3-21
    4 Defining Problems
    Objectives 4-2
    Defining the Problem 4-3
    Limit the Scope 4-4
    Setting the Priority 4-5
    Top Wait Events 4-6
    Oracle Internal & Oracle Academy Use Only
    v
    Setting the Priority: Example 4-7
    Top SQL Reports 4-8
    Common Tuning Problems 4-9
    Tuning Life Cycle Phases 4-11
    Tuning During the Life Cycle 4-12
    Application Design and Development 4-13
    Testing: Database Configuration 4-14
    Deployment 4-15
    Production 4-16
    Migration, Upgrade, and Environment Changes 4-17
    ADDM Tuning Session 4-18
    Performance Versus Business Requirements 4-19
    Performance Tuning Resources 4-20
    Filing a Performance Service Request 4-21
    RDA Report 4-22
    Monitoring and Tuning Tool: Overview 4-23
    Summary 4-25
    Practice 4 Overview: Identifying the Problem 4-26
    5 Using Metrics and Alerts
    Objectives 5-2
    Metrics, Alerts, and Baselines 5-3
    Limitation of Base Statistics 5-4
    Typical Delta Tools 5-5
    Oracle Database 11g Solution: Metrics 5-6
    Benefits of Metrics 5-7
    Viewing Metric History Information 5-8
    Using EM to View Metric Details 5-9
    Statistic Histograms 5-10
    Histogram Views 5-11
    Server-Generated Alerts 5-12
    Database Control Usage Model 5-13
    Setting Thresholds 5-14
    Creating and Testing an Alert 5-15
    Metric and Alert Views 5-16
    View User-Defined SQL Metrics 5-17
    Create User-Defined SQL Metrics 5-18
    View User-Defined Host Metrics 5-19
    Create User-Defined Host Metrics 5-20
    Summary 5-21
    Practice Overview 5: Working with Metrics 5-22
    Oracle Internal & Oracle Academy Use Only
    vi
    6 Baselines
    Objectives 6-2
    Comparative Performance Analysis with AWR Baselines 6-3
    Automatic Workload Repository Baselines 6-4
    Moving Window Baseline 6-5
    Baselines in Performance Page Settings 6-6
    Baseline Templates 6-7
    AWR Baselines 6-8
    Creating AWR Baselines 6-9
    Single AWR Baseline 6-10
    Creating a Repeating Baseline Template 6-11
    Managing Baselines with PL/SQL 6-12
    Generating a Baseline Template for a Single Time Period 6-13
    Creating a Repeating Baseline Template 6-14
    Baseline Views 6-15
    Performance Monitoring and Baselines 6-17
    Defining Alert Thresholds Using a Static Baseline 6-19
    Using EM to Quickly Configure Adaptive Thresholds 6-20
    Changing Adaptive Threshold Settings 6-22
    Summary 6-23
    Practice 6: Overview Using AWR Baselines 6-24
    7 Using AWR-Based Tools
    Objectives 7-2
    Automatic Maintenance Tasks 7-3
    Maintenance Windows 7-4
    Default Maintenance Plan 7-5
    Automated Maintenance Task Priorities 7-6
    Tuning Automatic Maintenance Tasks 7-7
    ADDM Performance Monitoring 7-8
    ADDM and Database Time 7-9
    DBTime-Graph and ADDM Methodology 7-10
    Top Performance Issues Detected 7-12
    Database Control and ADDM Findings 7-13
    ADDM Analysis Results 7-14
    ADDM Recommendations 7-15
    Database Control and ADDM Task 7-16
    Changing ADDM Attributes 7-17
    Retrieving ADDM Reports by Using SQL 7-18
    Active Session History: Overview 7-19
    Active Session History: Mechanics 7-20
    Oracle Internal & Oracle Academy Use Only
    vii
    ASH Sampling: Example 7-21
    Accessing ASH Data 7-22
    Dump ASH to File 7-23
    Analyzing the ASH Data 7-24
    Generating ASH Reports 7-25
    ASH Report Script 7-26
    ASH Report: General Section 7-27
    ASH Report Structure 7-28
    ASH Report: Activity Over Time 7-29
    Summary 7-30
    Practice 7 Overview: Using AWR-Based Tools 7-31
    8 Monitoring an Application
    Objectives 8-2
    What Is a Service? 8-3
    Service Attributes 8-4
    Service Types 8-5
    Creating Services 8-6
    Managing Services in a Single-Instance Environment 8-7
    Everything Switches to Services 8-8
    Using Services with Client Applications 8-9
    Using Services with the Resource Manager 8-10
    Services and Resource Manager with EM 8-11
    Services and the Resource Manager: Example 8-12
    Using Services with the Scheduler 8-13
    Services and the Scheduler with EM 8-14
    Services and the Scheduler: Example 8-16
    Using Services with Parallel Operations 8-17
    Using Services with Metric Thresholds 8-18
    Changing Service Thresholds by Using EM 8-19
    Services and Metric Thresholds: Example 8-20
    Service Aggregation and Tracing 8-21
    Top Services Performance Page 8-22
    Service Aggregation Configuration 8-23
    Service Aggregation: Example 8-24
    Client Identifier Aggregation and Tracing 8-25
    trcsess Utility 8-26
    Service Performance Views 8-27
    Summary 8-29
    Practice 8 Overview: Using Services 8-30
    Oracle Internal & Oracle Academy Use Only
    viii
    9 Identifying Problem SQL Statements
    Objectives 9-2
    SQL Statement Processing Phases 9-3
    Parse Phase 9-4
    SQL Storage 9-5
    Cursor Usage and Parsing 9-6
    SQL Statement Processing Phases: Bind 9-8
    SQL Statement Processing Phases: Execute and Fetch 9-9
    Processing a DML Statement 9-10
    COMMIT Processing 9-12
    Role of the Oracle Optimizer 9-13
    Identifying Bad SQL 9-15
    TOP SQL Reports 9-16
    What Is an Execution Plan? 9-17
    Methods for Viewing Execution Plans 9-18
    Uses of Execution Plans 9-19
    DBMS_XPLAN Package: Overview 9-20
    EXPLAIN PLAN Command 9-22
    EXPLAIN PLAN Command: Example 9-23
    EXPLAIN PLAN Command: Output 9-24
    Reading an Execution Plan 9-25
    Using the V$SQL_PLAN View 9-26
    V$SQL_PLAN Columns 9-27
    Querying V$SQL_PLAN 9-28
    V$SQL_PLAN_STATISTICS View 9-29
    Querying the AWR 9-30
    SQL*Plus AUTOTRACE 9-32
    Using SQL*Plus AUTOTRACE 9-33
    SQL*Plus AUTOTRACE: Statistics 9-34
    SQL Trace Facility 9-35
    How to Use the SQL Trace Facility 9-37
    Initialization Parameters 9-38
    Enabling SQL Trace 9-40
    Disabling SQL Trace 9-41
    Formatting Your Trace Files 9-42
    TKPROF Command Options 9-43
    Output of the TKPROF Command 9-45
    TKPROF Output with No Index: Example 9-50
    TKPROF Output with Index: Example 9-51
    Generate an Optimizer Trace 9-52
    Oracle Internal & Oracle Academy Use Only
    ix
    Summary 9-53
    Practice Overview 9: Using Execution Plan Utilities 9-54
    10 Influencing the Optimizer
    Objectives 10-2
    Functions of the Query Optimizer 10-3
    Selectivity 10-5
    Cardinality and Cost 10-6
    Changing Optimizer Behavior 10-7
    Using Hints 10-8
    Optimizer Statistics 10-9
    Extended Statistics 10-10
    Controlling the Behavior of the Optimizer with Parameters 10-11
    Enabling Query Optimizer Features 10-13
    Influencing the Optimizer Approach 10-14
    Optimizing SQL Statements 10-15
    Access Paths 10-16
    Choosing an Access Path 10-17
    Full Table Scans 10-18
    Row ID Scans 10-20
    Index Operations 10-21
    B*Tree Index Operations 10-22
    Bitmap Indexes 10-23
    Bitmap Index Access 10-24
    Combining Bitmaps 10-25
    Bitmap Operations 10-26
    Join Operations 10-27
    Join Methods 10-28
    Nested Loop Joins 10-29
    Hash Joins 10-31
    Sort-Merge Joins 10-32
    Join Performance 10-34
    How the Query Optimizer Chooses Execution Plans for Joins 10-35
    Sort Operations 10-37
    Tuning Sort Performance 10-38
    Reducing the Cost 10-39
    Index Maintenance 10-40
    Dropping Indexes 10-42
    Creating Indexes 10-43
    SQL Access Advisor 10-44
    Table Maintenance for Performance 10-45
    Oracle Internal & Oracle Academy Use Only
    x
    Table Reorganization Methods 10-46
    Summary 10-47
    Practice 10 Overview: Influencing the Optimizer 10-48
    11 Using SQL Performance Analyzer
    Objectives 11-2
    Real Application Testing: Overview 11-3
    Real Application Testing: Use Cases 11-4
    SQL Performance Analyzer: Process 11-5
    Capturing the SQL Workload 11-7
    Creating a SQL Performance Analyzer Task 11-8
    SQL Performance Analyzer: Tasks 11-9
    Optimizer Upgrade Simulation 11-10
    SQL Performance Analyzer Task Page 11-11
    Comparison Report 11-12
    Comparison Report SQL Detail 11-13
    Tuning Regressing Statements 11-14
    Preventing Regressions 11-16
    Parameter Change Analysis 11-17
    Guided Workflow Analysis 11-18
    SQL Performance Analyzer: PL/SQL Example 11-19
    SQL Performance Analyzer: Data Dictionary Views 11-21
    Summary 11-22
    Practice 11: Overview 11-23
    12 SQL Performance Management
    Objectives 12-2
    Maintaining SQL Performance 12-3
    Maintaining Optimizer Statistics 12-4
    Automated Maintenance Tasks 12-5
    Statistic Gathering Options 12-6
    Setting Statistic Preferences 12-7
    Restore Statistics 12-9
    Deferred Statistics Publishing: Overview 12-10
    Deferred Statistics Publishing: Example 12-12
    Automatic SQL Tuning: Overview 12-13
    SQL Statement Profiling 12-14
    Plan Tuning Flow and SQL Profile Creation 12-15
    SQL Tuning Loop 12-16
    Using SQL Profiles 12-17
    SQL Tuning Advisor: Overview 12-18
    Oracle Internal & Oracle Academy Use Only
    xi
    Using the SQL Tuning Advisor 12-19
    SQL Tuning Advisor Options 12-20
    SQL Tuning Advisor Recommendations 12-21
    Using the SQL Tuning Advisor: Example 12-22
    Using the SQL Access Advisor 12-23
    View Recommendations 12-25
    View Recommendation Details 12-26
    SQL Plan Management: Overview 12-27
    SQL Plan Baseline: Architecture 12-28
    Loading SQL Plan Baselines 12-30
    Evolving SQL Plan Baselines 12-31
    Important Baseline SQL Plan Attributes 12-32
    SQL Plan Selection 12-34
    Possible SQL Plan Manageability Scenarios 12-36
    SQL Performance Analyzer and SQL Plan Baseline Scenario 12-37
    Loading a SQL Plan Baseline Automatically 12-38
    Purging SQL Management Base Policy 12-39
    Enterprise Manager and SQL Plan Baselines 12-40
    Summary 12-41
    Practice 12: Overview Using SQL Plan Management 12-42
    13 Using Database Replay
    Objectives 13-2
    Using Database Replay 13-3
    The Big Picture 13-4
    System Architecture: Capture 13-5
    System Architecture: Processing the Workload 13-7
    System Architecture: Replay 13-8
    Capture Considerations 13-9
    Replay Considerations: Preparation 13-10
    Replay Considerations 13-11
    Replay Options 13-12
    Replay Analysis 13-13
    Database Replay Workflow in Enterprise Manager 13-15
    Capturing Workload with Enterprise Manager 13-16
    Capture Wizard: Plan Environment 13-17
    Capture Wizard: Options 13-18
    Capture Wizard: Parameters 13-19
    Viewing Capture Progress 13-20
    Viewing Capture Report 13-21
    Export Capture AWR Data 13-22
    Oracle Internal & Oracle Academy Use Only
    xii
    Viewing Workload Capture History 13-23
    Processing Captured Workload 13-24
    Using the Preprocess Captured Workload Wizard 13-25
    Using the Replay Workload Wizard 13-26
    Replay Workload: Prerequisites 13-27
    Replay Workload: Choose Initial Options 13-28
    Replay Workload: Customize Options 13-29
    Replay Workload: Prepare Replay Clients 13-30
    Replay Workload: Client Connections 13-31
    Replay Workload: Replay Started 13-32
    Viewing Workload Replay Progress 13-33
    Viewing Workload Replay Statistics 13-34
    Packages and Procedures 13-36
    Data Dictionary Views: Database Replay 13-37
    Database Replay: PL/SQL Example 13-38
    Calibrating Replay Clients 13-40
    Summary 13-41
    Practice 13: Overview 13-42
    14 Tuning the Shared Pool
    Objectives 14-2
    Shared Pool Architecture 14-3
    Shared Pool Operation 14-4
    The Library Cache 14-5
    Latch and Mutex 14-7
    Latch and Mutex: Views and Statistics 14-9
    Diagnostic Tools for Tuning the Shared Pool 14-11
    AWR/Statspack Indicators 14-13
    Load Profile 14-14
    Instance Efficiencies 14-15
    Top Waits 14-16
    Time Model 14-17
    Library Cache Activity 14-19
    Avoid Hard Parses 14-20
    Are Cursors Being Shared? 14-21
    Sharing Cursors 14-23
    Adaptive Cursor Sharing: Example 14-25
    Adaptive Cursor Sharing Views 14-27
    Interacting with Adaptive Cursor Sharing 14-28
    Avoiding Soft Parses 14-29
    Sizing the Shared Pool 14-30
    Oracle Internal & Oracle Academy Use Only
    xiii
    Shared Pool Advisory 14-31
    Shared Pool Advisor 14-33
    Avoiding Fragmentation 14-34
    Large Memory Requirements 14-35
    Tuning the Shared Pool Reserved Space 14-37
    Keeping Large Objects 14-39
    Data Dictionary Cache 14-41
    Dictionary Cache Misses 14-42
    SQL Query Result Cache: Overview 14-43
    Managing the SQL Query Result Cache 14-44
    Using the RESULT_CACHE Hint 14-46
    Using the DBMS_RESULT_CACHE Package 14-47
    Viewing SQL Result Cache Dictionary Information 14-48
    SQL Query Result Cache: Considerations 14-49
    UGA and Oracle Shared Server 14-50
    Large Pool 14-51
    Tuning the Large Pool 14-52
    Summary 14-53
    Practice Overview 14: Tuning the Shared Pool 14-54
    15 Tuning the Buffer Cache
    Objectives 15-2
    Oracle Database Architecture 15-3
    Buffer Cache: Highlights 15-4
    Database Buffers 15-5
    Buffer Hash Table for Lookups 15-6
    Working Sets 15-7
    Tuning Goals and Techniques 15-9
    Symptoms 15-11
    Cache Buffer Chains Latch Contention 15-12
    Finding Hot Segments 15-13
    Buffer Busy Waits 15-14
    Calculating the Buffer Cache Hit Ratio 15-15
    Buffer Cache Hit Ratio Is Not Everything 15-16
    Interpreting Buffer Cache Hit Ratio 15-17
    Read Waits 15-19
    Free Buffer Waits 15-21
    Solutions 15-22
    Sizing the Buffer Cache 15-23
    Buffer Cache Size Parameters 15-24
    Dynamic Buffer Cache Advisory Parameter 15-25
    Oracle Internal & Oracle Academy Use Only
    xiv
    Buffer Cache Advisory View 15-26
    Using the V$DB_CACHE_ADVICE View 15-27
    Using the Buffer Cache Advisory with EM 15-28
    Caching Tables 15-29
    Multiple Buffer Pools 15-30
    Enabling Multiple Buffer Pools 15-32
    Calculating the Hit Ratio for Multiple Pools 15-33
    Multiple Block Sizes 15-35
    Multiple Database Writers 15-36
    Multiple I/O Slaves 15-37
    Use Multiple Writers or I/O Slaves 15-38
    Private Pool for I/O Intensive Operations 15-39
    Automatically Tuned Multiblock Reads 15-40
    Flushing the Buffer Cache (for Testing Only) 15-41
    Summary 15-42
    Practice 15: Overview Tuning the Buffer Cache 15-43
    16 Tuning PGA and Temporary Space
    Objectives 16-2
    SQL Memory Usage 16-3
    Performance Impact 16-4
    Automatic PGA Memory 16-5
    SQL Memory Manager 16-6
    Configuring Automatic PGA Memory 16-8
    Setting PGA_AGGREGATE_TARGET Initially 16-9
    Monitoring SQL Memory Usage 16-10
    Monitoring SQL Memory Usage: Examples 16-12
    Tuning SQL Memory Usage 16-13
    PGA Target Advice Statistics 16-14
    PGA Target Advice Histograms 16-15
    Automatic PGA and Enterprise Manager 16-16
    Automatic PGA and AWR Reports 16-17
    Temporary Tablespace Management: Overview 16-18
    Temporary Tablespace: Best Practice 16-19
    Configuring Temporary Tablespace 16-20
    Temporary Tablespace Group: Overview 16-22
    Temporary Tablespace Group: Benefits 16-23
    Creating Temporary Tablespace Groups 16-24
    Maintaining Temporary Tablespace Groups 16-25
    View Tablespace Groups 16-26
    Monitoring Temporary Tablespace 16-27
    Oracle Internal & Oracle Academy Use Only
    xv
    Temporary Tablespace Shrink 16-28
    Tablespace Option for Creating Temporary Table 16-29
    Summary 16-30
    Practice Overview 16: Tuning PGA Memory 16-31
    17 Automatic Memory Management
    Objectives 17-2
    Oracle Database Architecture 17-3
    Dynamic SGA 17-4
    Granule 17-5
    Memory Advisories 17-6
    Manually Adding Granules to Components 17-7
    Increasing the Size of an SGA Component 17-8
    Automatic Shared Memory Management: Overview 17-9
    SGA Sizing Parameters: Overview 17-10
    Dynamic SGA Transfer Modes 17-11
    Memory Broker Architecture 17-12
    Manually Resizing Dynamic SGA Parameters 17-13
    Behavior of Auto-Tuned SGA Parameters 17-14
    Behavior of Manually Tuned SGA Parameters 17-15
    Using the V$PARAMETER View 17-16
    Resizing SGA_TARGET 17-17
    Disabling Automatic Shared Memory Management 17-18
    Configuring ASMM 17-19
    SGA Advisor 17-20
    Monitoring ASMM 17-21
    Automatic Memory Management: Overview 17-22
    Oracle Database Memory Parameters 17-24
    Automatic Memory Parameter Dependency 17-25
    Enabling Automatic Memory Management 17-26
    Monitoring Automatic Memory Management 17-27
    DBCA and Automatic Memory Management 17-29
    Summary 17-30
    Practice 17: Overview Using Automatic Memory Tuning 17-31
    Oracle Internal & Oracle Academy Use Only
    xvi
    18 Tuning Segment Space Usage
    Objectives 18-2
    Space Management 18-3
    Extent Management 18-4
    Locally Managed Extents 18-5
    Large Extents: Considerations 18-6
    How Table Data Is Stored 18-8
    Anatomy of a Database Block 18-9
    Minimize Block Visits 18-10
    The DB_BLOCK_SIZE Parameter 18-11
    Small Block Size: Considerations 18-12
    Large Block Size: Considerations 18-13
    Block Allocation 18-14
    Free Lists 18-15
    Block Space Management 18-16
    Block Space Management with Free Lists 18-17
    Automatic Segment Space Management 18-19
    Automatic Segment Space Management at Work 18-20
    Block Space Management with ASSM 18-22
    Creating an Automatic Segment Space Management Segment 18-23
    Migration and Chaining 18-24
    Guidelines for PCTFREE and PCTUSED 18-26
    Detecting Migration and Chaining 18-27
    Selecting Migrated Rows 18-28
    Eliminating Migrated Rows 18-29
    Shrinking Segments: Overview 18-31
    Shrinking Segments: Considerations 18-32
    Shrinking Segments by Using SQL 18-33
    Segment Shrink: Basic Execution 18-34
    Segment Shrink: Execution Considerations 18-35
    Using EM to Shrink Segments 18-36
    Table Compression: Overview 18-37
    Table Compression Concepts 18-38
    Using Table Compression 18-39
    Summary 18-40
    19 Tuning I/O
    Objectives 19-2
    I/O Architecture 19-3
    File System Characteristics 19-4
    I/O Modes 19-5
    Oracle Internal & Oracle Academy Use Only
    xvii
    Direct I/O 19-6
    Bandwidth Versus Size 19-7
    Important I/O Metrics for Oracle Databases 19-8
    I/O Calibration and Enterprise Manager 19-10
    I/O Calibration and the PL/SQL Interface 19-11
    I/O Statistics: Overview 19-13
    I/O Statistics and Enterprise Manager 19-14
    Stripe and Mirror Everything 19-16
    Using RAID 19-17
    RAID Cost Versus Benefits 19-18
    Should I Use RAID 1 or RAID 5? 19-20
    Diagnostics 19-21
    Database I/O Tuning 19-22
    What Is Automatic Storage Management? 19-23
    Tuning ASM 19-24
    How Many Disk Groups per Database 19-25
    Which RAID Configuration for Best Availability? 19-26
    ASM Mirroring Guidelines 19-27
    ASM Striping Granularity 19-28
    What Type of Striping Works Best? 19-29
    ASM Striping Only 19-30
    Hardware RAID Striped LUNs 19-31
    ASM Guidelines 19-32
    ASM Instance Initialization Parameters 19-33
    Dynamic Performance Views 19-34
    Monitoring Long-Running Operations by Using V$ASM_OPERATION 19-36
    ASM Instance Performance Diagnostics 19-37
    ASM Performance Page 19-38
    Database Instance Parameter Changes 19-39
    ASM Scalability 19-40
    Summary 19-41
    20 Performance Tuning Summary
    Objectives 20-2
    Necessary Initialization Parameters with Little Performance Impact 20-3
    Important Initialization Parameters with Performance Impact 20-4
    Sizing Memory Initially 20-6
    Database High Availability: Best Practices 20-7
    Undo Tablespace: Best Practices 20-8
    Temporary Tablespace: Best Practices 20-9
    General Tablespace: Best Practices 20-11
    Internal Fragmentation Considerations 20-12
    Oracle Internal & Oracle Academy Use Only
    xviii
    Block Size: Advantages and Disadvantages 20-13
    Automatic Checkpoint Tuning 20-14
    Sizing the Redo Log Buffer 20-15
    Sizing Redo Log Files 20-16
    Increasing the Performance of Archiving 20-17
    Automatic Statistics Gathering 20-19
    Automatic Statistics Collection: Considerations 20-20
    Commonly Observed Wait Events 20-21
    Additional Statistics 20-22
    Top 10 Mistakes Found in Customer Systems 20-23
    Summary 20-25
    Appendix A: Practices and Solutions
    Appendix B: Using Statspack
    Index

  • Result cache not working?

    Hi,
    BANNER
    Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
    PL/SQL Release 11.2.0.3.0 - Production
    CORE 11.2.0.3.0 Production
    TNS for Linux: Version 11.2.0.3.0 - Production
    NLSRTL Version 11.2.0.3.0 - Production
    SQL> show parameter result;
    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 10M
    result_cache_mode string MANUAL
    result_cache_remote_expiration integer 0
    The above are the initialization parameters set and the DB version.
    Now i have created a table as
    create table objects as select * from dba_objects;
    then issued the following query.
    select /* result_cache */ object_Type,count(*) from objects group by object_type;
    it appears that the results of the above query is not cached in the result cache. using
    set autotrace traceonly explain confirms that there is no result cache or the CACHE_ID in the explain plan. also the v$result_cache_statistics confirm the same.
    But after this when i issued the following statement.
    alter session set result_cache_mode=force;
    the same below sql statement again
    select /* result_cache */ object_Type,count(*) from objects group by object_type;
    it appears that now the result cache is being used.
    My question is despite using the result_cache hint and trying the above statement when the result_cache_mode=auto/manual. The result cache is not being used or the results of the SQL statements are not being cached at all despite using the result_cache hint and the table being not used at all. and if i use the result_cache_mode=force then the result cache is being used.
    Can any one please explain this behavior. Cursor_sharing is set to EXACT. and i am issuing the same SQL statement without any changes at all.
    Thanks,

    There is a syntax problem with your queries:
    select /* result_cache */.... is just a comment, not a hint. For creating a hint, you need "+": select /*+ result_cache */....

  • Using the client result cache without the query result cache

    I have constructed a client in C# using ODP.NET to connect to an Oracle database and want to perform client result caching for some of my queries.
    This is done using a result_cache hint in the query.
    select /*+ result_cache */ * from table
    As far as I can tell query result caching on the server is done using the same hint, so I was wondering if there was any way to differentiate between the two? I want the query results to be cached on the client, but not on the server.
    The only way I have found to do this is to disable all caching on the server, but I don't want to do this as I want to use the server cache for PL/SQL function results.
    Thanks.

    e3a934c9-c4c2-4c80-b032-d61d415efd4f wrote:
    I have constructed a client in C# using ODP.NET to connect to an Oracle database and want to perform client result caching for some of my queries.
    This is done using a result_cache hint in the query.
    select /*+ result_cache */ * from table 
    As far as I can tell query result caching on the server is done using the same hint, so I was wondering if there was any way to differentiate between the two? I want the query results to be cached on the client, but not on the server.
    The only way I have found to do this is to disable all caching on the server, but I don't want to do this as I want to use the server cache for PL/SQL function results.
    Thanks.
    You haven't provided ANY information about how you configured the result cache. Different parameters are used for configuring the client versus the server result cache so you need to post what, if anything, you configured.
    Post the code you executed when you set the 'client_result_cache_lag' and 'client_result_cache_size' parameters so we can see what values you used. Also post the results of querying those parameters after you set them that show that they really are set.
    You also need to post your app code that shows that you are using the OCI statements are used when you want to use client side result cacheing.
    See the OCI dev guide
    http://docs.oracle.com/cd/B28359_01/appdev.111/b28395/oci10new.htm#sthref1491
    Statement Caching in OCI
    Statement caching refers to the feature that provides and manages a cache of statements for each session. In the server, it means that cursors are ready to be used without the need to parse the statement again. Statement caching can be used with connection pooling and with session pooling, and will improve performance and scalability. It can be used without session pooling as well. The OCI calls that implement statement caching are:
      OCIStmtPrepare2()
      OCIStmtRelease()

  • 11g Client result set caching in OCI

    I'm trying out this feature in the 11.1.0.6 release. My understanding of this feature is that when enabled with the appropriate server-side init.ora parameters, a 11g OCI client connecting to the instance will cache SQL results locally in some fixed amount of RAM on the client. The idea is that network roundtrips would simply disappear in this situation.
    I'm not sure if it's working--or how to tell if it is. I have a 11g instance running and put the 11g client incl. sqlplus on a separate box, setting up TNS connectivity from client to server. Pretty standard stuff. I can connect fine and run the same query over and over, but I see incrementing execution counts on the database side and network traffic between the client and server so I'm guessing that the client-side caching isn't happening. There doesn't seem to be a ton of clear documentation on this feature so I wanted to see if anyone else has kicked it around.
    Bob

    I am also facing the same issue (enabling client result set caching). I am using Oracle Database 11g Release 11.2.0.2.0.
    I have made the below configuration changes
    1. Enabled the client result set cache by setting the server side parameter 'client_result_cache_size' to 10485760 (10 MB)
    2. Restarted the oracle instance after setting the above parameter
    3. Added a table annotation by executing the statement ALTER TABLE emp RESULT_CACHE (MODE FORCE). I verified that the annotation is applied by query the user table later.
    4. Enabled statement caching on the client side i.e. on the JDBC driver.
    5. Used prepared statements to execute the query so that statement caching kicks in. From the driver logs I verified that execution of subsequent queries after the first one used the same statement handle.
    After executing the select prepared statement query for three times I checked the CLIENT_RESULT_CACHE_STATS$ view. But this view didn't result in any rows.
    As part of troubleshooting I even tried adding the /*+ RESULT_CACHE */ hint to the query but the view didn't gave any result.
    Also on enabling sql trace I could see from tkprof that every execution of the query increased the number of rows fetched on the server which indicates that the client result set caching in OCI isn't working.
    Are there any steps which I have missed?
    Thanks in advance.

  • Multi-Left Join Query Tuning

    I am tuning a SELECT query with 36 Left Joins in addition to normal Inner Joins and a View.
    I have used the RESULT_CACHE hint with some success.
    I have tried the LEADING hint and USE_MERGE with no success.
    Is there an Undocumented HINT and that may assist me?
    Thanks
    BRAD

    Hi, Brad,
    Welcome to the forum!
    970109 wrote:
    I am tuning a SELECT query with 36 Left Joins in addition to normal Inner Joins and a View.Why does the query need so many outer joins? Could there be a bad table design behind this problem? Post a simplified version ot the problem (with maybe 3 tables that need to be outer-joined). Post CREATE TABLE and INSERT statements for a little sample data (relevant columns only), the results you want from that sample data, and an explanation of how you get those results from that data.
    See the forum FAQ {message:id=9360002}
    For all tuning problems, see {message:id=9360003}

  • Query result cache with functions

    Hi all,
    one of my colleagues has found a little bit weird behavior of a query result cache. He has set result_cache_mode = 'FORCE' (but it can be reproduced with a result_cache hint too) and suddenly functions called from the query get executed twice (for the first time) .
    An easy example:
    alter session set result_cache_mode = 'FORCE';
    create sequence test_seq;
    create or replace function test_f(i number)
    return number
    is                  
    begin
      dbms_output.put_line('TEST_F executed');
      --autonomous transaction or package variable can be used too
      return test_seq.nextval;
    end;
    prompt First call
    select test_f(1) from dual;
    prompt Second call
    select test_f(1) from dual;
    drop sequence test_seq;
    drop function test_f;
    First call
    TEST_F(1)
             2
    TEST_F executed
    TEST_F executed
    Second call
    TEST_F(1)
             1
    As you can see - for the first time the function is executed twice and return the value from the second execution. When I execute the query again it returns the value from the first execution... but it doesn't matter, problem is in the double execution. Our developers used to send emails via select (it's easier for them):
    select send_mail(...) from dual;
    ... and now the customers complains that they get emails twice
    And now the question - is there any way, hot to get rid of this behavior (without changing the parameter back or rewriting code)? I thought that the result cache is automatically disabled for non-deterministic functions...or is this an expected behavior?
    Thanks,
    Ivan

    Interesting.. you are right:
    SELECT /*+ RESULT_CACHE */ 'dog' FROM DUAL;
    And at the second execution:
    | Id  | Operation        | Name                       | Rows  | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT |                            |     1 |     2   (0)| 00:00:01 |
    |   1 |  RESULT CACHE    | cc5k01xyqz3ypf9t0j28r5gtd1 |       |            |          |
    |   2 |   FAST DUAL      |                            |     1 |     2   (0)| 00:00:01 |
    Hmmm..

Maybe you are looking for