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.

Similar Messages

Result_cache does not work in 11g

-bash-3.00$ uname -a
SunOS tssoldb01 5.10 Generic sun4u sparc SUNW,Sun-Fire-V210
-bash-3.00$ sqlplus / as sysdba
SQL*Plus: Release 11.1.0.6.0 - Production on Fri Feb 29 11:37:14 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> show parameter result_cache_;
NAME TYPE VALUE
client_result_cache_lag big integer 3000
client_result_cache_size big integer 100M
result_cache_max_result integer 5
result_cache_max_size big integer 3M
result_cache_mode string MANUAL
result_cache_remote_expiration integer 0
SQL> select /*+ RESULT_CACHE */ object_name from dba_objects
2 where owner='SYSTEM' and object_type='PROCEDURE' ;
OBJECT_NAME
ORA$_SYS_REP_AUTH
SQL> select count(*) from v$result_cache_objects;
COUNT(*)
0
SQL>
Try the hint /*+ result_cache */ but the result cache view returns nothing. All parameters are set. Do not know why?

Oops, not query the sys views.
Thanks Chris, just read your message while post above.
Yeah, should not use dba_objects.
Message was edited by:
user498460
Message was edited by:
user498460

Sql Profile Error ORA-13786: missing SQL text of statement object "1"

Hi,
I am testing a Sql Profile sample executiion with the hint result_cache for faster execution of a query. I have created a tuning task but got no recommendations. But when i tried to create sql profile with the pkg dbms_sqltune.accept_sql_profile i am getting an error. The db version is 11.1.0.7. Given below is the sql and the output.
Please let me know if you have any suggestions.
-- Accept SQL Profiles
SET SERVEROUTPUT ON
DECLARE
l_sql_tune_task_id VARCHAR2(2000);
BEGIN
l_sql_tune_task_id := DBMS_SQLTUNE.accept_sql_profile (
task_name => 'Permissionstab_tuning_task',
name => 'Permissionstab_profile',
description => 'sql profile for Permissionstab_profile',
force_match => TRUE);
--profile_type => DBMS_SQLTUNE.PX_PROFILE);
DBMS_OUTPUT.put_line('l_sql_tune_task_id: ' || l_sql_tune_task_id);
END;
with profile_type commented out output
DECLARE
ERROR at line 1:
ORA-13786: missing SQL text of statement object "1" for tuning task "Permissionstab_tuning_task"
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 95
ORA-06512: at "SYS.DBMS_SQLTUNE_INTERNAL", line 11049
ORA-06512: at "SYS.PRVT_SQLPROF_INFRA", line 30
ORA-06512: at "SYS.DBMS_SQLTUNE", line 5836
ORA-06512: at line 4
including profile_type
profile_type => DBMS_SQLTUNE.PX_PROFILE);
ERROR at line 9:
ORA-06550: line 9, column 35:
PLS-00302: component 'PX_PROFILE' must be declared
ORA-06550: line 4, column 5:
PL/SQL: Statement ignored
Given below is the complete script and output
CONN / AS SYSDBA
GRANT CREATE ANY SQL PROFILE TO ariba;
GRANT DROP ANY SQL PROFILE TO ariba;
GRANT ALTER ANY SQL PROFILE TO ariba;
conn ariba/****;
EXEC DBMS_SQLTUNE.DROP_TUNING_TASK('Permissionstab_tuning_task');
-- Tuning task created for a manually specified statement.
DECLARE
l_sql VARCHAR2(4000);
l_sql_tune_task_id VARCHAR2(1000);
BEGIN
l_sql := 'SELECT /*+ result_cache */ rootId, pe_DefaultingSetBits, pe_Version, pe_Creator, pe_Active, pe_AdapterSource, pe_AdapterFlag, pe_PartitionN
umber, '||
'pe_PurgeState, pe_TimeCreated, pe_TimeUpdated, pe_CommonId, pe_ServerVersion, pe_UniqueName, pe_Name, mls_DefaultingSetBits, '||
'mls_PrimaryString, mls_MaxTranslationID, mls_Translations, mls_PrimaryStringLanguageID, mls_LocalizationKey, pe_Description, '||
'mls0_DefaultingSetBits, mls0_PrimaryString, mls0_MaxTranslationID, mls0_Translations, mls0_PrimaryStringLanguageID, '||
'mls0_LocalizationKey, pe_Created, pe_Modified '||
'FROM PermissionTab '||
'where pe_UniqueName = '||''''||'PurchasingAgent'||''''||' '||
'and ( pe_PurgeState = :1 ) AND pe_PartitionNumber = :2';
l_sql_tune_task_id := DBMS_SQLTUNE.create_tuning_task (
sql_text => l_sql,
user_name => 'ARIBA',
scope => DBMS_SQLTUNE.scope_comprehensive,
time_limit => 60,
task_name => 'Permissionstab_tuning_task',
description => 'Tuning task for an Permissionstab query.');
DBMS_OUTPUT.put_line('l_sql_tune_task_id: ' || l_sql_tune_task_id);
END;
EXEC DBMS_SQLTUNE.execute_tuning_task(task_name => 'Permissionstab_tuning_task');
SELECT task_name, status FROM dba_advisor_log WHERE owner = 'ARIBA';
SET LONG 10000;
SET PAGESIZE 1000
SET LINESIZE 200
SELECT DBMS_SQLTUNE.report_tuning_task('Permissionstab_tuning_task') AS recommendations FROM dual;
SET PAGESIZE 24
-- Accept SQL Profiles
SET SERVEROUTPUT ON
DECLARE
l_sql_tune_task_id VARCHAR2(2000);
BEGIN
l_sql_tune_task_id := DBMS_SQLTUNE.accept_sql_profile (
task_name => 'Permissionstab_tuning_task',
name => 'Permissionstab_profile',
description => 'sql profile for Permissionstab_profile',
force_match => TRUE,
profile_type => DBMS_SQLTUNE.PX_PROFILE);
DBMS_OUTPUT.put_line('l_sql_tune_task_id: ' || l_sql_tune_task_id);
END;
11:17:17 SYS@FLBUYPM 02-APR-13> @sql_profile_result_cache.sql
Connected.
Grant succeeded.
Grant succeeded.
Grant succeeded.
Connected.
PL/SQL procedure successfully completed.
PL/SQL procedure successfully completed.
PL/SQL procedure successfully completed.
TASK_NAME STATUS
Permissionstab_tuning_task COMPLETED
RECOMMENDATIONS
GENERAL INFORMATION SECTION
Tuning Task Name : Permissionstab_tuning_task
Tuning Task Owner : ARIBA
Workload Type : Single SQL Statement
Scope : COMPREHENSIVE
Time Limit(seconds): 60
Completion Status : COMPLETED
Started at : 04/02/2013 11:17:20
Completed at : 04/02/2013 11:17:20
Schema Name: ARIBA
SQL ID : 2y6yar7r71tj1
SQL Text : SELECT /*+ result_cache */ rootId, pe_DefaultingSetBits,
pe_Version, pe_Creator, pe_Active, pe_AdapterSource,
pe_AdapterFlag, pe_PartitionNumber, pe_PurgeState,
pe_TimeCreated, pe_TimeUpdated, pe_CommonId, pe_ServerVersion,
pe_UniqueName, pe_Name, mls_DefaultingSetBits,
mls_PrimaryString, mls_MaxTranslationID, mls_Translations,
mls_PrimaryStringLanguageID, mls_LocalizationKey,
pe_Description, mls0_DefaultingSetBits, mls0_PrimaryString,
mls0_MaxTranslationID, mls0_Translations,
mls0_PrimaryStringLanguageID, mls0_LocalizationKey, pe_Created,
pe_Modified FROM PermissionTab where pe_UniqueName =
'PurchasingAgent' and ( pe_PurgeState = :1 ) AND
pe_PartitionNumber = :2
ADDITIONAL INFORMATION SECTION
- At least one important bind value was missing for this sql statement. The
accuracy of the advisor's analysis may depend on all important bind values
being supplied.
EXPLAIN PLANS SECTION
1- Original
Plan hash value: 778402129
| Id | Operation | Name | Rows | Byte
s | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 29
8 | 1 (0)| 00:00:01 |
| 1 | RESULT CACHE | 9qsg9vxnpk5r13h9gb3wcgujg1 | |
| | |
|* 2 | TABLE ACCESS BY INDEX ROWID| PERMISSIONTAB | 1 | 29
8 | 1 (0)| 00:00:01 |
|* 3 | INDEX UNIQUE SCAN | ARIBAINDEX341 | 1 |
| 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - filter("PE_PURGESTATE"=TO_NUMBER(:1))
3 - access("PE_UNIQUENAME"='PurchasingAgent' AND "PE_PARTITIONNUMBER"=TO_NUMB
ER(:2))
Result Cache Information (identified by operation id):
1 - column-count=30; dependencies=(ARIBA.PERMISSIONTAB); attributes=(single-r
ow); parameters=(nls, :1, :2); name="SELECT /*+ result_cache */ rootId, pe_Defau
ltingSetBits, pe_Version, pe_Creator, pe_Active, pe_AdapterSource, pe_AdapterFla
g, pe"
DECLARE
ERROR at line 1:
ORA-13786: missing SQL text of statement object "1" for tuning task "Permissionstab_tuning_task"
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 95
ORA-06512: at "SYS.DBMS_SQLTUNE_INTERNAL", line 11049
ORA-06512: at "SYS.PRVT_SQLPROF_INFRA", line 30
ORA-06512: at "SYS.DBMS_SQLTUNE", line 5836
ORA-06512: at line 4
11:17:20 ARIBA@FLBUYPM 02-APR-13>
profile_type => DBMS_SQLTUNE.PX_PROFILE);
ERROR at line 9:
ORA-06550: line 9, column 35:
PLS-00302: component 'PX_PROFILE' must be declared
ORA-06550: line 4, column 5:
PL/SQL: Statement ignored
Edited by: 997562 on Apr 2, 2013 8:34 AM

Hi Experts,
i too getting this error while attaching the tuning task to the sql profiler, below are the details, appreciate any help on this.
SQL> SQL> VAR profile_name VARCHAR2(30);
SQL> BEGIN
   :profile_name := DBMS_SQLTUNE.ACCEPT_SQL_PROFILE(task_name => 'sql_tuning_task');
END;
/ 2    3    4
BEGIN
ERROR at line 1:
ORA-13786: missing SQL text of statement object "1" for tuning task "sql_tuning_task"
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 95
ORA-06512: at "SYS.DBMS_SQLTUNE_INTERNAL", line 16442
ORA-06512: at "SYS.PRVT_SQLPROF_INFRA", line 31
ORA-06512: at "SYS.DBMS_SQLTUNE", line 7544
ORA-06512: at line 2
SQL> select banner from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 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

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>

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.

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,

Is result_cache working in Oracle 11.1.0.6.0?

BANNER
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production
PL/SQL Release 11.1.0.6.0 - Production
CORE 11.1.0.6.0 Production
TNS for Solaris: Version 11.1.0.6.0 - Production
NLSRTL Version 11.1.0.6.0 - Production
SQL> SELECT dbms_result_cache.status() FROM dual;
DBMS_RESULT_CACHE.STATUS()
--------------------------------------------------------------------------------------------------------------------------------------------------------------------ENABLED
12:31:08 SQL> set autotrace on
select count(*) from objs;
12:31:27 SQL>
COUNT(*)
69918
Elapsed: 00:00:01.72
Execution Plan
Plan hash value: 386529197
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 289 (1)| 00:00:04 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | TABLE ACCESS FULL| OBJS | 80773 | 289 (1)| 00:00:04 |
Note
- dynamic sampling used for this statement
Statistics
282 recursive calls
0 db block gets
1140 consistent gets
1038 physical reads
0 redo size
524 bytes sent via SQL*Net to client
524 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
5 sorts (memory)
0 sorts (disk)
1 rows processed
12:31:49 SQL> select /*+ result_cache */ count(*) from objs;
COUNT(*)
69918
Elapsed: 00:00:00.03
Execution Plan
Plan hash value: 386529197
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 289 (1)| 00:00:04 |
| 1 | RESULT CACHE | cnsc9rw3p17364cbg4975pad6y | | | |
| 2 | SORT AGGREGATE | | 1 | | |
| 3 | TABLE ACCESS FULL| OBJS | 80773 | 289 (1)| 00:00:04 |
Result Cache Information (identified by operation id):
1 - column-count=1; dependencies=(CTSGKOD.OBJS); attributes=(single-row); name="select /*+ result_cache */ count(*) from objs"
Note
- dynamic sampling used for this statement
Statistics
4 recursive calls
0 db block gets
1110 consistent gets
0 physical reads
0 redo size
524 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)
1 rows processed
12:32:06 SQL>
i see result_cache in execution plan, but why do i see 1110 consistent gets? I expected 0 in consisent gets and physical reads and the query is not executed ...
Thank You

Aman,
lets say i run these statements
1) exec dbms_result_cache.flush
2) alter system flush shared_pool;
3)alter system flush buffer_cache;
Then i run the query without hint of result_cache
4) Select count(*) from objs; --> This query is not using result cache, it is running for first time, so physical reads & consistent gets
5) select count(*) from objs; --> again same query, this time only consistent gets
6) select /*+ result_cache */ count(*) from objs; -- Lets introduce result_cache now
Will the above query gets data from buffer cache or will it use result_cache and gets result from memory instead of running query? Or will this 6th statement run same as (5) and prepares ground for usage of result_cache and
any other queries later can benefit from result_cache?
Thanks again Aman

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

Dynamic %HINT ORACLE in select query

Hi Experts,
I am trying to implement given below code with dynamic % hint oracle
      SELECT vbeln posnr uepos
         FROM vbap INTO TABLE i_vbap
         FOR ALL ENTRIES IN i_vbak
          WHERE vbeln EQ i_vbak-vbeln
            %_hints oracle '&max_in_blocking_factor 500&&max_blocking_factor 500&'.
I want value 500 dynamic,
So far I have tried
%hint oracle lv_oracle_string.
%hint oracle (lv_oracle_string).
WHERE (lv_oracle_string).     "where conditon with %_hints oracle '&max_in_blocking_factor 500&&max_blocking_factor 500&'.
Any other ideas?
Thanks in Advance

Samuel,
Thank you so much, whatever you mentioned, I have tried ealier, but it was giving me dump because of incorrect spacing in my string.
Given below sloved my problem.
CONCATENATE '''&max_in_blocking_factor ' lv_oracle '&&max_blocking_factor ' lv_oracle '&'''
          INTO lv_oracle_string RESPECTING BLANKS.
          SELECT vbeln posnr uepos
             FROM vbap INTO TABLE i_vbap
             FOR ALL ENTRIES IN i_vbak
             WHERE vbeln EQ i_vbak-vbeln
             %_hints oracle lv_oracle_string.
Thanks you so much again. You Rock

Report Developer Control Of Applying Hints to Analytics Queries

There are numerous ways to apply hints to the queries generated by Analytics:
- Table level
- Join level
- Evaluate calculation
Each has its advantages and drawbacks.
- Table level: applies the hint to every query that references the table.
- Join level: applies the hint whenever the join is used in the query.
- Evaluate: allows the report developer to include a hint, but can't control where Analytics decides to apply the hint.
I propose another method for the report developer to apply hints, when needed, that uses join level hints. All the report developer
does is add the hint column to the Answer or add a filter based on the hint column to the Answer to apply the hint.
Setup
NOTE: I suggest you do consistency checks along the way, especially before starting work in the next Layer, to be sure that all setup errors are resolved early.
1) Start by defining a Logical SQL table in the Physical Layer using the following SQL: Select 1 Hint from dual
2) Alias this table for each hint to be defined for report developer usage. As an example, alias the hint table, creating
No Star and Parallel alias tables.
3) Join each alias to the physical layer fact tables, using a complex join, where the hint could be applied. In the Join definition screen, put the hint in the HINT field and enter 1=1 for
in the Expression section. Yes, we are creating a cartesian join between the hint and the other joining table. As the hint table always returns one and only one row, there
is no effect on the rows returned by the query. For No Star, you
put NO_STAR_TRANSFORMATION in the Hint field. For Parallel, you put PARALLEL(<physical table name>, default, default), where the physical table name
is the name of the actual database table, not the name of the alias table (Analytics will put the alias in the place of the database table name
when it generates the SQL). Additionally, for hints that have no parameters, you only need to join it
to the Fact tables in a query and not necessarily the dimensions. If you include fields from multiple fact tables, the hint will be applied
for each fact table. So, you may see the hint multiple times in the SQL (something like SELECT /*+ NO_STAR_TRANSFORMATION NO_STAR_TRANSFORMATION */ t00001.col1...)
4) Add the hint alias tables to the BMM Layer.
5) Rename the Hint field in each of the BMM hint tables to identify the hint being applied. For No Star, change the column name from Hint to No Star Hint. For Parallel,
change the column name from Hint to Parallel Hint.
6) Set the hint column as a key.
7) Join the BMM hint tables to the appropriate fact tables, using a complex join.
8) Define each hint table as a dimension.
9) Set the Logical Level in the Content tab in each of the sources of the joined tables to use the Detail of the hint dimension.
10) Create a folder in the Presentation Layer called Hints
11) Place each BMM hint field into the Presentation Layer Hints folder.
To apply a hint to your Answer, either add the Hint field to your Answer or create a filter where the Hint field is equal to/is in 1 (the number one). Check that the SQL generated
contains the hint, in Answers, go into Administration, Session Manager, and view the log for the user (the user log level will need to have been set to 7 to see the SQL generated).
Use of hints in more complex setups can be done by performing a setup of the hints that is parallel to the fact table setup. As an example, if you specify fragmentation content and a where
clause in your BMM for your fact tables, you would setup parallel physical layer hint tables and joins, BMM objects and joins, fragmentation content, and where clauses based on the
hint tables (only hint tables are referenced in the where clause).
As any database person knows, hints can either help or degrade the performance of queries. So, taking the SQL of the pre-hint Answer and figuring out which hints give the best
performance is suggested, prior to adding the hint fields/filters to the Answer.

Hi Oliver,
I would suggest you to have a look at the below WLST script which would give you the required report of the active threads and it would be send an email too.
Topic: Sending Email Alert for Threads Pool Health Using WLST
http://middlewaremagic.com/weblogic/?p=5433
Topic: Sending Email Alert for Hogger Threads Count Using WLST
http://middlewaremagic.com/weblogic/?p=5423
Also you can use the below script in case of the stuck threads, this script would send you an email with the thread dumps during the issue occurred.
Topic: Sending Email Alert For Stuck Threads With Thread Dumps
http://middlewaremagic.com/weblogic/?p=5582
Regards,
Ravish Mody

Query HINT help requested Pls.

A query thus:
SELECT equipment_id,
vsemml.stock_equipment_id,
game_ware_id
FROM v_stocked_equipment_inven_his vsdeih,
v_stock_equipment_mod_man_list vsemml
WHERE vsemml.stock_equipment_id = vsdeih.stock_equipment_id(+)
AND equipment_status_code IN
('ALL', 'AVA' )
AND ec_end_date IS NULL
AND eav_end_date IS NULL
GROUP BY equipment_id,
vsemml.stock_equipment_id,
game_ware_id
HAVING COUNT (model_attribute_value_id) =
(SELECT COUNT (*)
FROM stock_equipment JOIN stock_equipment_attrib_value
USING (stock_equipment_id)
WHERE stock_equipment_id =
vsemml.stock_equipment_id);
has result :
513 rows selected.
Elapsed: 00:04:59.17
Execution Plan
Plan hash value: 3816309895
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 240 | 21120 | | 38010 (7)| 00:07:37 |
|* 1 | FILTER | | | | | | |
| 2 | HASH GROUP BY | | 240 | 21120 | | 38010 (7)| 00:07:37 |
|* 3 | FILTER | | | | | | |
|* 4 | HASH JOIN OUTER | | 23915 | 2055K| | 38006 (7)| 00:07:37 |
|* 5 | HASH JOIN | | 42 | 630 | | 7 (15)| 00:00:01 |
| 6 | TABLE ACCESS FULL | MODEL | 31 | 279 | | 3 (0)| 00:00:01 |
| 7 | TABLE ACCESS FULL | STOCK_EQUIPMENT | 42 | 252 | | 3 (0)| 00:00:01 |
| 8 | VIEW | V_STOCKED_EQUIPMENT_INVEN_HIS | 23915 | 1704K| | 37998 (7)| 00:07:36 |
| 9 | HASH UNIQUE | | 23915 | 2989K| 6392K| 37998 (7)| 00:07:36 |
|* 10 | HASH JOIN RIGHT OUTER | | 23915 | 2989K| | 37307 (7)| 00:07:28 |
| 11 | TABLE ACCESS FULL | GAME_WARE | 325 | 1950 | | 3 (0)| 00:00:01 |
|* 12 | HASH JOIN RIGHT OUTER | | 23915 | 2849K| | 37303 (7)| 00:07:28 |
| 13 | TABLE ACCESS FULL | GAMESET | 825 | 8250 | | 5 (0)| 00:00:01 |
|* 14 | HASH JOIN | | 23915 | 2615K| | 37297 (7)| 00:07:28 |
| 15 | TABLE ACCESS FULL | EQUIPMENT_STATUS | 16 | 128 | | 3 (0)| 00:00:01 |
|* 16 | HASH JOIN | | 23915 | 2428K| | 37293 (7)| 00:07:28 |
| 17 | TABLE ACCESS FULL | STOCK_EQUIPMENT | 42 | 252 | | 3 (0)| 00:00:01 |
|* 18 | HASH JOIN | | 645K| 60M| | 37278 (7)| 00:07:28 |
| 19 | INDEX FULL SCAN | XPKSTOCK_EQUIPMENT_ATTRIB_VAL | 42 | 294 | | 1 (0)| 00:00:01 |
|* 20 | HASH JOIN | | 5288K| 458M| 9M| 37180 (7)| 00:07:27 |
| 21 | TABLE ACCESS FULL | EQUIPMENT_ATTRIBUTE_VALUE | 297K| 6672K| | 784 (3)| 00:00:10 |
|* 22 | HASH JOIN | | 7467K| 484M| 6328K| 5447 (5)| 00:01:06 |
| 23 | INDEX FAST FULL SCAN | PK_EQUIPMENT_CONFIGURATION | 380K| 1859K| | 398 (3)| 00:00:05 |
|* 24 | HASH JOIN | | 380K| 22M| 4528K| 3235 (2)| 00:00:39 |
|* 25 | HASH JOIN | | 140K| 2876K| | 563 (2)| 00:00:07 |
| 26 | MERGE JOIN | | 281 | 3372 | | 6 (17)| 00:00:01 |
| 27 | TABLE ACCESS BY INDEX ROWID| SITE_TYPE | 4 | 20 | | 2 (0)| 00:00:01 |
| 28 | INDEX FULL SCAN | PK_SITE_TYPE | 4 | | | 1 (0)| 00:00:01 |
|* 29 | SORT JOIN | | 281 | 1967 | | 4 (25)| 00:00:01 |
| 30 | VIEW | index$_join$_016 | 281 | 1967 | | 3 (0)| 00:00:01 |
|* 31 | HASH JOIN | | | | | | |
| 32 | INDEX FAST FULL SCAN | PK_SITE | 281 | 1967 | | 1 (0)| 00:00:01 |
| 33 | INDEX FAST FULL SCAN | XIF1SITE | 281 | 1967 | | 1 (0)| 00:00:01 |
| 34 | TABLE ACCESS FULL | LOCATION | 140K| 1232K| | 554 (2)| 00:00:07 |
| 35 | TABLE ACCESS FULL | EQUIPMENT_CONFIGURATION | 380K| 15M| | 1460 (2)| 00:00:18 |
| 36 | SORT AGGREGATE | | 1 | 6 | | | |
| 37 | NESTED LOOPS | | 1 | 6 | | 0 (0)| 00:00:01 |
|* 38 | INDEX UNIQUE SCAN | XPKSTOCK_EQUIPMENT | 1 | 3 | | 0 (0)| 00:00:01 |
|* 39 | INDEX RANGE SCAN | XIF1STOCK_EQUIPMENT_ATTRIB_VAL | 1 | 3 | | 0 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter(COUNT("MODEL_ATTRIBUTE_VALUE_ID")= (SELECT COUNT(*) FROM "STOCK_EQUIPMENT_ATTRIB_VALUE"
"STOCK_EQUIPMENT_ATTRIB_VALUE","STOCK_EQUIPMENT" "STOCK_EQUIPMENT" WHERE "STOCK_EQUIPMENT"."STOCK_EQUIPMENT_ID"=:B1 AND
"STOCK_EQUIPMENT"."STOCK_EQUIPMENT_ID"="STOCK_EQUIPMENT_ATTRIB_VALUE"."STOCK_EQUIPMENT_ID" AND
"STOCK_EQUIPMENT_ATTRIB_VALUE"."STOCK_EQUIPMENT_ID"=:B2))
3 - filter(("EQUIPMENT_STATUS_CODE"='ALL' OR "EQUIPMENT_STATUS_CODE"='AVA') AND "EC_END_DATE" IS NULL AND "EAV_END_DATE"
IS NULL)
4 - access("SE"."STOCK_EQUIPMENT_ID"="VSDEIH"."STOCK_EQUIPMENT_ID"(+))
5 - access("SE"."MODEL_ID"="M"."MODEL_ID")
10 - access("GS"."GAME_WARE_ID"="GW"."GAME_WARE_ID"(+))
12 - access("EC"."GAMESET_ID"="GS"."GAMESET_ID"(+))
14 - access("EC"."EQUIPMENT_STATUS_ID"="ES"."EQUIPMENT_STATUS_ID")
16 - access("EC"."MODEL_ID"="STOCK_EQUIPMENT"."MODEL_ID" AND
"STOCK_EQUIPMENT"."STOCK_EQUIPMENT_ID"="STOCK_EQUIPMENT_ATTRIB_VALUE"."STOCK_EQUIPMENT_ID")
18 - access("MODEL_ATTRIBUTE_VALUE_ID"="STOCK_EQUIPMENT_ATTRIB_VALUE"."MODEL_ATTRIBUTE_VALUE_ID")
20 - access("EC"."EQUIPMENT_ID"="EAV"."EQUIPMENT_ID")
filter("EAV"."START_DATE">="EC"."START_DATE" AND ("EAV"."END_DATE" IS NULL AND "EC"."END_DATE">="EAV"."START_DATE" OR
"EC"."END_DATE" IS NULL OR "EAV"."END_DATE"<="EC"."END_DATE") OR "EC"."START_DATE">="EAV"."START_DATE" AND ("EC"."END_DATE"
IS NULL AND "EAV"."END_DATE">="EC"."START_DATE" OR "EAV"."END_DATE" IS NULL OR "EC"."END_DATE"<="EAV"."END_DATE"))
22 - access("EC"."EQUIPMENT_ID"="EC"."EQUIPMENT_ID")
24 - access("EC"."LOCATION_ID"="L"."LOCATION_ID")
25 - access("L"."SITE_ID"="S"."SITE_ID")
29 - access("S"."SITE_TYPE_ID"="ST"."SITE_TYPE_ID")
filter("S"."SITE_TYPE_ID"="ST"."SITE_TYPE_ID")
31 - access(ROWID=ROWID)
38 - access("STOCK_EQUIPMENT"."STOCK_EQUIPMENT_ID"=:B1)
39 - access("STOCK_EQUIPMENT"."STOCK_EQUIPMENT_ID"="STOCK_EQUIPMENT_ATTRIB_VALUE"."STOCK_EQUIPMENT_ID")
filter("STOCK_EQUIPMENT_ATTRIB_VALUE"."STOCK_EQUIPMENT_ID"=:B1)
Query altered to:
=================
SELECT equipment_id,
vsemml.stock_equipment_id,
game_ware_id
FROM v_stocked_equipment_inven_his vsdeih,
v_stock_equipment_mod_man_list vsemml
WHERE vsemml.stock_equipment_id = vsdeih.stock_equipment_id(+)
AND equipment_status_code = 'ALL'
AND ec_end_date IS NULL
AND eav_end_date IS NULL
GROUP BY equipment_id,
vsemml.stock_equipment_id,
game_ware_id
HAVING COUNT (model_attribute_value_id) =
(SELECT COUNT (*)
FROM stock_equipment JOIN stock_equipment_attrib_value
USING (stock_equipment_id)
WHERE stock_equipment_id =
vsemml.stock_equipment_id)
union
SELECT equipment_id,
vsemml.stock_equipment_id,
game_ware_id
FROM v_stocked_equipment_inven_his vsdeih,
v_stock_equipment_mod_man_list vsemml
WHERE vsemml.stock_equipment_id = vsdeih.stock_equipment_id(+)
AND equipment_status_code = 'AVA'
AND ec_end_date IS NULL
AND eav_end_date IS NULL
GROUP BY equipment_id,
vsemml.stock_equipment_id,
game_ware_id
HAVING COUNT (model_attribute_value_id) =
(SELECT COUNT (*)
FROM stock_equipment JOIN stock_equipment_attrib_value
USING (stock_equipment_id)
WHERE stock_equipment_id =
vsemml.stock_equipment_id);
Results in:
513 rows selected.
Elapsed: 00:00:07.40
Execution Plan
Plan hash value: 3317078232
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 2 | 176 | | 6431 (51)| 00:01:18 |
| 1 | SORT UNIQUE | | 2 | 176 | | 6431 (51)| 00:01:18 |
| 2 | UNION-ALL | | | | | | |
|* 3 | FILTER | | | | | | |
| 4 | HASH GROUP BY | | 1 | 88 | | 3216 (2)| 00:00:39 |
|* 5 | HASH JOIN | | 95 | 8360 | | 3214 (2)| 00:00:39 |
|* 6 | HASH JOIN | | 42 | 630 | | 7 (15)| 00:00:01 |
| 7 | TABLE ACCESS FULL | MODEL | 31 | 279 | | 3 (0)| 00:00:01 |
| 8 | TABLE ACCESS FULL | STOCK_EQUIPMENT | 42 | 252 | | 3 (0)| 00:00:01 |
| 9 | VIEW | V_STOCKED_EQUIPMENT_INVEN_HIS | 95 | 6935 | | 3207 (2)| 00:00:39 |
| 10 | HASH UNIQUE | | 95 | 12160 | | 3207 (2)| 00:00:39 |
|* 11 | HASH JOIN RIGHT OUTER | | 95 | 12160 | | 3206 (2)| 00:00:39 |
| 12 | TABLE ACCESS FULL | GAME_WARE | 325 | 1950 | | 3 (0)| 00:00:01 |
|* 13 | HASH JOIN OUTER | | 95 | 11590 | | 3202 (2)| 00:00:39 |
|* 14 | HASH JOIN | | 95 | 10640 | | 3196 (2)| 00:00:39 |
| 15 | TABLE ACCESS FULL | SITE_TYPE | 4 | 20 | | 3 (0)| 00:00:01 |
|* 16 | HASH JOIN | | 95 | 10165 | | 3193 (2)| 00:00:39 |
| 17 | VIEW | index$_join$_021 | 281 | 1967 | | 3 (0)| 00:00:01 |
|* 18 | HASH JOIN | | | | | | |
| 19 | INDEX FAST FULL SCAN | PK_SITE | 281 | 1967 | | 1 (0)| 00:00:01 |
| 20 | INDEX FAST FULL SCAN | XIF1SITE | 281 | 1967 | | 1 (0)| 00:00:01 |
| 21 | NESTED LOOPS | | 95 | 9500 | | 3189 (2)| 00:00:39 |
|* 22 | HASH JOIN | | 96 | 8736 | 4440K| 3093 (2)| 00:00:38 |
|* 23 | HASH JOIN | | 56789 | 3771K| | 1679 (2)| 00:00:21 |
|* 24 | HASH JOIN | | 2894 | 178K| | 1273 (1)| 00:00:16 |
| 25 | INDEX FULL SCAN | XPKSTOCK_EQUIPMENT_ATTRIB_VAL | 42 | 294 | | 1 (0)| 00:00:01 |
|* 26 | HASH JOIN | | 2894 | 158K| | 1271 (1)| 00:00:16 |
| 27 | TABLE ACCESS FULL | STOCK_EQUIPMENT | 42 | 252 | | 3 (0)| 00:00:01 |
|* 28 | TABLE ACCESS BY INDEX ROWID| EQUIPMENT_CONFIGURATION | 1279 | 53718 | | 1265 (1)| 00:00:16 |
| 29 | NESTED LOOPS | | 1860 | 93000 | | 1268 (1)| 00:00:16 |
|* 30 | TABLE ACCESS FULL | EQUIPMENT_STATUS | 1 | 8 | | 3 (0)| 00:00:01 |
|* 31 | INDEX RANGE SCAN | XIF3EQUIPMENT_CONFIGURATION | 23796 | | | 48 (3)| 00:00:01 |
| 32 | INDEX FAST FULL SCAN | PK_EQUIPMENT_CONFIGURATION | 380K| 1859K| | 398 (3)| 00:00:05 |
|* 33 | TABLE ACCESS FULL | EQUIPMENT_ATTRIBUTE_VALUE | 242K| 5451K| | 785 (3)| 00:00:10 |
| 34 | TABLE ACCESS BY INDEX ROWID | LOCATION | 1 | 9 | | 1 (0)| 00:00:01 |
|* 35 | INDEX UNIQUE SCAN | PK_LOCATION | 1 | | | 0 (0)| 00:00:01 |
| 36 | TABLE ACCESS FULL | GAMESET | 825 | 8250 | | 5 (0)| 00:00:01 |
| 37 | SORT AGGREGATE | | 1 | 6 | | | |
| 38 | NESTED LOOPS | | 1 | 6 | | 0 (0)| 00:00:01 |
|* 39 | INDEX UNIQUE SCAN | XPKSTOCK_EQUIPMENT | 1 | 3 | | 0 (0)| 00:00:01 |
|* 40 | INDEX RANGE SCAN | XIF1STOCK_EQUIPMENT_ATTRIB_VAL | 1 | 3 | | 0 (0)| 00:00:01 |
|* 41 | FILTER | | | | | | |
| 42 | HASH GROUP BY | | 1 | 88 | | 3216 (2)| 00:00:39 |
|* 43 | HASH JOIN | | 95 | 8360 | | 3214 (2)| 00:00:39 |
|* 44 | HASH JOIN | | 42 | 630 | | 7 (15)| 00:00:01 |
| 45 | TABLE ACCESS FULL | MODEL | 31 | 279 | | 3 (0)| 00:00:01 |
| 46 | TABLE ACCESS FULL | STOCK_EQUIPMENT | 42 | 252 | | 3 (0)| 00:00:01 |
| 47 | VIEW | V_STOCKED_EQUIPMENT_INVEN_HIS | 95 | 6935 | | 3207 (2)| 00:00:39 |
| 48 | HASH UNIQUE | | 95 | 12160 | | 3207 (2)| 00:00:39 |
|* 49 | HASH JOIN RIGHT OUTER | | 95 | 12160 | | 3206 (2)| 00:00:39 |
| 50 | TABLE ACCESS FULL | GAME_WARE | 325 | 1950 | | 3 (0)| 00:00:01 |
|* 51 | HASH JOIN OUTER | | 95 | 11590 | | 3202 (2)| 00:00:39 |
|* 52 | HASH JOIN | | 95 | 10640 | | 3196 (2)| 00:00:39 |
| 53 | TABLE ACCESS FULL | SITE_TYPE | 4 | 20 | | 3 (0)| 00:00:01 |
|* 54 | HASH JOIN | | 95 | 10165 | | 3193 (2)| 00:00:39 |
| 55 | VIEW | index$_join$_044 | 281 | 1967 | | 3 (0)| 00:00:01 |
|* 56 | HASH JOIN | | | | | | |
| 57 | INDEX FAST FULL SCAN | PK_SITE | 281 | 1967 | | 1 (0)| 00:00:01 |
| 58 | INDEX FAST FULL SCAN | XIF1SITE | 281 | 1967 | | 1 (0)| 00:00:01 |
| 59 | NESTED LOOPS | | 95 | 9500 | | 3189 (2)| 00:00:39 |
|* 60 | HASH JOIN | | 96 | 8736 | 4440K| 3093 (2)| 00:00:38 |
|* 61 | HASH JOIN | | 56789 | 3771K| | 1679 (2)| 00:00:21 |
|* 62 | HASH JOIN | | 2894 | 178K| | 1273 (1)| 00:00:16 |
| 63 | INDEX FULL SCAN | XPKSTOCK_EQUIPMENT_ATTRIB_VAL | 42 | 294 | | 1 (0)| 00:00:01 |
|* 64 | HASH JOIN | | 2894 | 158K| | 1271 (1)| 00:00:16 |
| 65 | TABLE ACCESS FULL | STOCK_EQUIPMENT | 42 | 252 | | 3 (0)| 00:00:01 |
|* 66 | TABLE ACCESS BY INDEX ROWID| EQUIPMENT_CONFIGURATION | 1279 | 53718 | | 1265 (1)| 00:00:16 |
| 67 | NESTED LOOPS | | 1860 | 93000 | | 1268 (1)| 00:00:16 |
|* 68 | TABLE ACCESS FULL | EQUIPMENT_STATUS | 1 | 8 | | 3 (0)| 00:00:01 |
|* 69 | INDEX RANGE SCAN | XIF3EQUIPMENT_CONFIGURATION | 23796 | | | 48 (3)| 00:00:01 |
| 70 | INDEX FAST FULL SCAN | PK_EQUIPMENT_CONFIGURATION | 380K| 1859K| | 398 (3)| 00:00:05 |
|* 71 | TABLE ACCESS FULL | EQUIPMENT_ATTRIBUTE_VALUE | 242K| 5451K| | 785 (3)| 00:00:10 |
| 72 | TABLE ACCESS BY INDEX ROWID | LOCATION | 1 | 9 | | 1 (0)| 00:00:01 |
|* 73 | INDEX UNIQUE SCAN | PK_LOCATION | 1 | | | 0 (0)| 00:00:01 |
| 74 | TABLE ACCESS FULL | GAMESET | 825 | 8250 | | 5 (0)| 00:00:01 |
| 75 | SORT AGGREGATE | | 1 | 6 | | | |
| 76 | NESTED LOOPS | | 1 | 6 | | 0 (0)| 00:00:01 |
|* 77 | INDEX UNIQUE SCAN | XPKSTOCK_EQUIPMENT | 1 | 3 | | 0 (0)| 00:00:01 |
|* 78 | INDEX RANGE SCAN | XIF1STOCK_EQUIPMENT_ATTRIB_VAL | 1 | 3 | | 0 (0)| 00:00:01 |
Predicate Information (identified by operation id):
3 - filter(COUNT("MODEL_ATTRIBUTE_VALUE_ID")= (SELECT COUNT(*) FROM "STOCK_EQUIPMENT_ATTRIB_VALUE"
"STOCK_EQUIPMENT_ATTRIB_VALUE","STOCK_EQUIPMENT" "STOCK_EQUIPMENT" WHERE "STOCK_EQUIPMENT"."STOCK_EQUIPMENT_ID"=:B1 AND
"STOCK_EQUIPMENT"."STOCK_EQUIPMENT_ID"="STOCK_EQUIPMENT_ATTRIB_VALUE"."STOCK_EQUIPMENT_ID" AND
"STOCK_EQUIPMENT_ATTRIB_VALUE"."STOCK_EQUIPMENT_ID"=:B2))
5 - access("SE"."STOCK_EQUIPMENT_ID"="VSDEIH"."STOCK_EQUIPMENT_ID")
6 - access("SE"."MODEL_ID"="M"."MODEL_ID")
11 - access("GS"."GAME_WARE_ID"="GW"."GAME_WARE_ID"(+))
13 - access("EC"."GAMESET_ID"="GS"."GAMESET_ID"(+))
14 - access("S"."SITE_TYPE_ID"="ST"."SITE_TYPE_ID")
16 - access("L"."SITE_ID"="S"."SITE_ID")
18 - access(ROWID=ROWID)
22 - access("MODEL_ATTRIBUTE_VALUE_ID"="STOCK_EQUIPMENT_ATTRIB_VALUE"."MODEL_ATTRIBUTE_VALUE_ID" AND
"EC"."EQUIPMENT_ID"="EAV"."EQUIPMENT_ID")
filter("EAV"."START_DATE">="EC"."START_DATE" AND ("EAV"."END_DATE" IS NULL AND "EC"."END_DATE">="EAV"."START_DATE" OR
"EC"."END_DATE" IS NULL OR "EAV"."END_DATE"<="EC"."END_DATE") OR "EC"."START_DATE">="EAV"."START_DATE" AND ("EC"."END_DATE"
IS NULL AND "EAV"."END_DATE">="EC"."START_DATE" OR "EAV"."END_DATE" IS NULL OR "EC"."END_DATE"<="EAV"."END_DATE"))
23 - access("EC"."EQUIPMENT_ID"="EC"."EQUIPMENT_ID")
24 - access("STOCK_EQUIPMENT"."STOCK_EQUIPMENT_ID"="STOCK_EQUIPMENT_ATTRIB_VALUE"."STOCK_EQUIPMENT_ID")
26 - access("EC"."MODEL_ID"="STOCK_EQUIPMENT"."MODEL_ID")
28 - filter("EC"."END_DATE" IS NULL)
30 - filter("ES"."EQUIPMENT_STATUS_CODE"='ALL')
31 - access("EC"."EQUIPMENT_STATUS_ID"="ES"."EQUIPMENT_STATUS_ID")
33 - filter("EAV"."END_DATE" IS NULL)
35 - access("EC"."LOCATION_ID"="L"."LOCATION_ID")
39 - access("STOCK_EQUIPMENT"."STOCK_EQUIPMENT_ID"=:B1)
40 - access("STOCK_EQUIPMENT"."STOCK_EQUIPMENT_ID"="STOCK_EQUIPMENT_ATTRIB_VALUE"."STOCK_EQUIPMENT_ID")
filter("STOCK_EQUIPMENT_ATTRIB_VALUE"."STOCK_EQUIPMENT_ID"=:B1)
41 - filter(COUNT("MODEL_ATTRIBUTE_VALUE_ID")= (SELECT COUNT(*) FROM "STOCK_EQUIPMENT_ATTRIB_VALUE"
"STOCK_EQUIPMENT_ATTRIB_VALUE","STOCK_EQUIPMENT" "STOCK_EQUIPMENT" WHERE "STOCK_EQUIPMENT"."STOCK_EQUIPMENT_ID"=:B1 AND
"STOCK_EQUIPMENT"."STOCK_EQUIPMENT_ID"="STOCK_EQUIPMENT_ATTRIB_VALUE"."STOCK_EQUIPMENT_ID" AND
"STOCK_EQUIPMENT_ATTRIB_VALUE"."STOCK_EQUIPMENT_ID"=:B2))
43 - access("SE"."STOCK_EQUIPMENT_ID"="VSDEIH"."STOCK_EQUIPMENT_ID")
44 - access("SE"."MODEL_ID"="M"."MODEL_ID")
49 - access("GS"."GAME_WARE_ID"="GW"."GAME_WARE_ID"(+))
51 - access("EC"."GAMESET_ID"="GS"."GAMESET_ID"(+))
52 - access("S"."SITE_TYPE_ID"="ST"."SITE_TYPE_ID")
54 - access("L"."SITE_ID"="S"."SITE_ID")
56 - access(ROWID=ROWID)
60 - access("MODEL_ATTRIBUTE_VALUE_ID"="STOCK_EQUIPMENT_ATTRIB_VALUE"."MODEL_ATTRIBUTE_VALUE_ID" AND
"EC"."EQUIPMENT_ID"="EAV"."EQUIPMENT_ID")
filter("EAV"."START_DATE">="EC"."START_DATE" AND ("EAV"."END_DATE" IS NULL AND "EC"."END_DATE">="EAV"."START_DATE" OR
"EC"."END_DATE" IS NULL OR "EAV"."END_DATE"<="EC"."END_DATE") OR "EC"."START_DATE">="EAV"."START_DATE" AND ("EC"."END_DATE"
IS NULL AND "EAV"."END_DATE">="EC"."START_DATE" OR "EAV"."END_DATE" IS NULL OR "EC"."END_DATE"<="EAV"."END_DATE"))
61 - access("EC"."EQUIPMENT_ID"="EC"."EQUIPMENT_ID")
62 - access("STOCK_EQUIPMENT"."STOCK_EQUIPMENT_ID"="STOCK_EQUIPMENT_ATTRIB_VALUE"."STOCK_EQUIPMENT_ID")
64 - access("EC"."MODEL_ID"="STOCK_EQUIPMENT"."MODEL_ID")
66 - filter("EC"."END_DATE" IS NULL)
68 - filter("ES"."EQUIPMENT_STATUS_CODE"='AVA')
69 - access("EC"."EQUIPMENT_STATUS_ID"="ES"."EQUIPMENT_STATUS_ID")
71 - filter("EAV"."END_DATE" IS NULL)
73 - access("EC"."LOCATION_ID"="L"."LOCATION_ID")
77 - access("STOCK_EQUIPMENT"."STOCK_EQUIPMENT_ID"=:B1)
78 - access("STOCK_EQUIPMENT"."STOCK_EQUIPMENT_ID"="STOCK_EQUIPMENT_ATTRIB_VALUE"."STOCK_EQUIPMENT_ID")
filter("STOCK_EQUIPMENT_ATTRIB_VALUE"."STOCK_EQUIPMENT_ID"=:B1)
5 minutes reduced to 7 seconds.!!
THE QUESTION.
Which (and where) query hint do I use to get the FIRST query to use the execution plan "method" of the second -
IE: To still perform well when a IN-LIST is used instead of EQUALS.
Technical:
Oracle 10.2.0.2 EE on Solaris 8, 64 bit.
Please help.
Thank you.
Below is the code of the referenced views for clarity.
CREATE OR REPLACE FORCE VIEW etrak.v_stocked_equipment_inven_his (stock_equipment_id,
equipment_id,
model_id,
gameset_id,
gameset_is_active,
game_ware_id,
game_ware_is_active,
equipment_status_code,
ec_start_date,
ec_end_date,
eav_start_date,
eav_end_date,
model_attribute_value_id,
site_id,
is_store
AS
SELECT DISTINCT stock_equipment_id, equipment_id, model_id, gameset_id,
gameset_is_active, game_ware_id, game_ware_is_active,
equipment_status_code, ec_start_date, ec_end_date,
eav_start_date, eav_end_date, model_attribute_value_id,
site_id, is_store
FROM (SELECT stock_equipment_id, equipment_id, model_id,
gameset_id, gameset_is_active, game_ware_id,
game_ware_is_active, equipment_status_code,
ec_start_date, ec_end_date, eav_start_date,
eav_end_date, model_attribute_value_id, site_id,
is_store
FROM (SELECT DISTINCT equipment_id, model_id,
gameset_id, gameset_is_active,
game_ware_id, game_ware_is_active,
equipment_status_code,
model_attribute_value_id,
ec_start_date, ec_end_date,
eav_start_date, eav_end_date,
site_id, is_store
FROM (SELECT ec.equipment_id,
ec.model_id,
gs.gameset_id,
gs.active_flag
AS gameset_is_active,
gw.game_ware_id,
gw.active_flag
AS game_ware_is_active,
es.equipment_status_code,
ec.start_date
AS ec_start_date,
ec.end_date
AS ec_end_date,
l.site_id, st.is_store
FROM equipment_configuration ec,
equipment_status es,
LOCATION l,
site s,
site_type st,
gameset gs,
game_ware gw
WHERE ec.equipment_status_id =
es.equipment_status_id
AND ec.gameset_id = gs.gameset_id(+)
AND gs.game_ware_id = gw.game_ware_id(+)
AND ec.location_id =
l.location_id
AND l.site_id = s.site_id
AND s.site_type_id =
st.site_type_id)
JOIN
(SELECT ec.equipment_id,
model_attribute_value_id,
eav.start_date
AS eav_start_date,
eav.end_date
AS eav_end_date
FROM equipment_configuration ec,
equipment_attribute_value eav
WHERE ec.equipment_id =
eav.equipment_id)
USING (equipment_id)
WHERE ( eav_start_date >=
ec_start_date
AND ( ( eav_end_date IS NULL
AND ec_end_date >=
eav_start_date
OR ec_end_date IS NULL
OR eav_end_date <=
ec_end_date
OR ( ec_start_date >=
eav_start_date
AND ( ( ec_end_date IS NULL
AND eav_end_date >=
ec_start_date
OR eav_end_date IS NULL
OR ec_end_date <=
eav_end_date
JOIN
(SELECT stock_equipment_id, model_id,
model_attribute_value_id
FROM stock_equipment JOIN stock_equipment_attrib_value
USING (stock_equipment_id)
) USING (model_id,
model_attribute_value_id)
CREATE OR REPLACE FORCE VIEW etrak.v_stock_equipment_mod_man_list (stock_equipment_id,
stock_equipment_code,
model_id,
model_name,
model_type_id,
model_type_code,
model_type_name,
man_id,
man_name
AS
SELECT se.stock_equipment_id, se.stock_equipment_code, m.model_id,
m.model_name, mt.model_type_id, mt.model_type_code,
mt.model_type_name, ma.man_id, ma.man_name
FROM stock_equipment se, model m, model_type mt, manufacturer ma
WHERE se.model_id = m.model_id
AND m.model_type_id = mt.model_type_id
AND m.man_id = ma.man_id;

What also makes it difficult to read is the lack of formatting tags ([code][/code] or [pre][/pre]) so that we can actually read the code and execution plans.
I'm not going to trawl through formatting all that myself just to try and see what the differences are between query 1 and query 2.
Also bear in mind that when query 2 ran, the data may have been cached and so there is less physical I/O required.
You don't really want to use any hints to cause re-use of execution plans from 1 query to a different query (like I said, I don't know how different they are). What you want to do is determine what poor SQL coding is making the first query slow and fix it.

What is the difference between the following 2 hints?

What is the difference between the following 2 hints?
USE_NL
USE_NL_WITH_INDEX

http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/sql_elements006.htm#SQLRF50701
Oracle Documentation starts @ http://tahiti.oracle.com

Index, Hints, etc

All,
I was wondering whether you could please help out on the following points:
(a) In the query below, what might be the suitable (and why?) indexes to be built?
=======================================
SELECT CONTRACT_PAY_GROUPS.CPG_AMOUNT_CY_AP,
CONTRACT_PAY_GROUPS.CPG_AMOUNT_EU_AP,
CONTRACT_PAY_GROUPS.CPG_TOTAL_ELIGIBLE_AREA
FROM CONTRACT JOIN CONTRACT_PAY_GROUPS ON CONTRACT.AC_SEQ = CONTRACT_PAY_GROUPS.CPG_CON_SEQ
WHERE CONTRACT.AC_START_YEAR = 2005
AND CONTRACT.AC_APPLICANT_NUMBER = '50614'
AND CONTRACT_PAY_GROUPS.CPG_SCHEME = 'Ε'
AND CONTRACT.AC_STATUS <> 2
=======================================
(b) Can the query below be (re-)written in any better way, in terms of performance (that is, which ---type of--- indexes and/or hints might be important to be created)?
=======================================
SELECT LYALLPLOTS.CP_END_YEAR
FROM (SELECT TYPLOTS.CP_PE_PLOT_ID FROM (SELECT CP_PE_PLOT_ID,
CP_PE_PT_SEQ,
AC_APPLICANT_NUMBER,
AC_START_YEAR,
AC_END_YEAR,
AC_STATUS,
AC_TYPE
FROM CONTRACT JOIN CONTRACT_PLOT ON CONTRACT.AC_SEQ = CONTRACT_PLOT.CP_CON_SEQ
JOIN APPLICATIONS ON CONTRACT.AC_APPL_SEQ = APPLICATIONS.APPL_SEQ
WHERE APPLICATIONS.APPL_YEAR = 2005
AND CP_PE_PT_SEQ IS NOT NULL ) TYPLOTS JOIN
(SELECT PT_SEQ, PT_PLOT_ID, PT_FROM_APPL_NUM, PT_TO_APPL_NUM FROM PLOTS_TRANSFER) TRPLOTS
ON TYPLOTS.CP_PE_PT_SEQ = TRPLOTS.PT_SEQ) TYTRANSFERS
JOIN (SELECT CP_PE_PLOT_ID, AC_APPLICANT_NUMBER, CONTRACT_PLOT.CP_END_YEAR FROM CONTRACT_PLOT JOIN CONTRACT
ON CONTRACT_PLOT.CP_CON_SEQ = CONTRACT.AC_SEQ
WHERE CONTRACT.AC_START_YEAR = 2004) LYALLPLOTS ON TYTRANSFERS.CP_PE_PLOT_ID = LYALLPLOTS.CP_PE_PLOT_ID
WHERE TYTRANSFERS.CP_PE_PLOT_ID = '5101-53/16--143'
GROUP BY LYALLPLOTS.CP_END_YEAR;
=======================================
(c) In general, could you please provide any insight on which types of indexes and/or hints (UNNEST, HASH_AJ, etc) might be needed in the case we are joining tables?
Any clue/support will be greatly appreciated. Thank you,
-Pericles Antoniades.

I'll echo sven's advice about not using hints unless you need to. I'm not telling you not to use hints. I am telling you to explore other solutions first, for the reasons sven mentioned.
An indexing strategy can be tricky to come up with. There are guidelines to follow (which follow), but also exceptions to those guidelines. Your own observations may differ from I'm going to describe. Also, I only glanced at your posting and possibly missed something. I'm going to describe btree indexes. Bitmap indexes work a bit differently.
Generally, indexes help do two things: get back small amounts of data quickly, and enforce uniqueness. Small amounts of data is sometimes considered to be between 15-20% of the rows in a table in 9i/10g; more than this and you might be better off with direct table access. Indexed lookups work well with nested loops joins (this is where the execution plan becomes useful) or direct table access, while other join methods (usually hash joins) may be more efficient when joining most of the rows from two tables.
What columns should you index? That's a matter of some debate. You can search OTN for other ideas. The best candidates for indexing are columns used in your WHERE clauses and/or those that make up a unique key. In your example
ON CONTRACT.AC_SEQ = CONTRACT_PAY_GROUPS.CPG_CON_SEQ WHERE CONTRACT.AC_START_YEAR = 2005 AND CONTRACT.AC_APPLICANT_NUMBER = '50614' AND CONTRACT_PAY_GROUPS.CPG_SCHEME = 'Ε' AND CONTRACT.AC_STATUS <> 2
I personally get the best results by listing the indexes in the order of most to last restrictive, but that's a matter of some debate.
I would consider putting indexes on contract.ac_seq, contract.ac_start_year contract.ac_applicant_number, and contrct.ac_status (composite), as well as contract_pay_groups.cpg_scheme and cpg_con_seq (composite). Then I would check to see if they were being used from an execution plan, ultimately using timings and run statistics from SQL*PLUS AUTOTRACE to decide if they were helping.

Kichat: How do I get iChat 3 working ? Upgrade hints, FAQ

Disclaimer: Apple does not necessarily endorse any suggestions, solutions, or third-party software products that may be mentioned in the topic below. Apple encourages you to first seek a solution at Apple Support. The following links are provided as is, with no guarantee of the effectiveness or reliability of the information. Apple does not guarantee that these links will be maintained or functional at any given time. Use the information below at your own discretion.
How do I get iChat 3 working ? Upgrade hints:FAQ
Trouble Shooting Revisited
Ok We will start with loading Tiger and iChat version 3.0
From Panther
There are or were serveral Add-ons and applications avaiblable to Panther users of iChat that are not compatible with iChat 3.
These following need to be deleted.
iCAR - An Add-on that posts an Auto response Away message (produces a 1 fps result in a Video chat)
Virex for Panther - An Anti Virus app avialable to @mac account users (Produces the 1 fsp problem)
iChatUSBCam for Panther/iChat2.x - A Add-on utility for using iSight or USB cam with iChat2.x (Incompatible with Tiger/iChat 3)
iProfile - An Add-on for producing a profile on the AIM server that ichat 2.x could not do (not proven to be a problem but now not needed).
A clean install of Tiger (not Archive and Install) produces the best results.
But any install should also check these Tiger settings.
First, UPGRADE to 10.4.3 as this gets past many Connection issues that became apparent with the basic Tiger (10.4) and iChat 3.0 It updates iChat to version 3.1
Check Settings
Don't be complacent that you have not set anything different.
There are several new things in Tiger that may trip you up.
These are worth looking at:
Mac Firewall. Now includes the ability to Block all UDP traffic in the Advanced button (System Preferences > Sharing >Firewall tab then the Advanced Button).
Also can now open UDP protocol for ports where as the Panther one only did TCP (Check any old Panther settings you Added to the presets).
The ports should be:
TCP -5190
UDP -5060, 5190, 5678, 16384-16403
There are more ports for Bonjour 5297, 5298, 5353 UDP and 5298 TCP and Jabber, 5220, 5222, 5223 on TCP)
(Table View see 7th Sept)
QuickTime. This has a change in the name of the Connection Speed tab to Streaming (System Preferences > QuickTime) Check this is set to be equal to your connection speed (the download one if this is faster). See Apple Doc 301641 Dated 9th November 2005.
Date & Time. Not conclusively involved but worth eliminating. Set a Network Server and the correct Time Zone.
Apple Remote Desktop. If this is active in System Preferences > Sharing > Services tab it causes problems for iChat.
Next, test the actual speed you are getting from your ISP.
http://www.dslreports.com/stest
There is a table here of the speeds you need:
http://docs.info.apple.com/article.html?artnum=301050
The one you get linked to in the Help menu is wrong.
Other Known Problems
There are several other applications that iChat 3 does not seem to like.
folding@home This is a application that uses spare processor time to help find protein chains for a University.
PostgreSQL This is a data base application that can be reset to allow more processor time for iChat. See here http://www.murraywilliams.com/blog/archives/000046.html
Lotus Notes Some people have reported problems with this.
Make sure any Add-on Video cards or input PCI cards have up to date Firmware
IF you are still having problems I would do Routine Maintenance Tasks as laid out here.
Lastly, some routers/modems are SIP aware and give different results in iChat 3 compared to iChat 2.
This is due to the Operating System changing (like a new computer connecting to the modem) rather than iChat.
See My web pages: page4 at the SIP Text in a Box section.
Also for the above try some housekeeping particularly if you do not keep your Computer on 24/7 Gulliver, "kmosx3: Mac OS X 10.3/10.4: System maintenance"
Ralph
Do you want to provide feedback on this User Contributed Tip or contribute your own? If you have achieved Level 2 status, visit the User Tips Library Contributions forum for more information.

i think apple needs to keep up with the jones here, so far i read at LOGIC PRO FORUMS many saying cubase and pro tools left logic in the dust, 1 year ago already, sad, but true
in anycase, trye starting one app before the other to see which combination works., other wise i think more apps will fall out of sync with old logic pro

Hint /*+result_cache*/?

Similar Messages

Maybe you are looking for

Hint /+result_cache/?