Oracle SGA benefits of using indexes

Goo day people,
We have been having performance issues and then the SGA was not sized coprrectely.
The size of the SGA was 720mb so we then pushed it to 4 gig which I blv is enough.
We then did a run of the tuning advisory on the top sql queries that were top one,
the advisor then pointed on that we need to use indexes on those queries .
We then advised the developers that they need to use indexes as it will improve
performance .. This morning the ADDM pointed out that we need to up the sga
to 5 Gig and I dont see this a solution to the problem.
I need to find a note on what benefits does using indexes have on the SGA and the overall perfomance
so that I can show the business that increasing the SGA wont solve the problem.
See screen shot below
erformance Finding Details:
     Database Time (minutes)          33.8
     Period Start Time          10-Aug-2010 10:00:11 o'clock SAST
     Period Duration (minutes)          60.2
     Task Owner          SYS
     Task Name          ADDM:1511773678_1_28498
     Average Active Sessions          0.6
     Finding          The SGA was inadequately sized, causing additional I/O or hard parses.
     Impact (minutes)          14.4
     Impact (%)          [64] [86] 42.8
Recommendations
Show All Details | Hide All Details
Details     Category     Benefit (%) [Sorted in descending order]
[Select to hide information] Hide
     DB Configuration     [64] [86] 42.8
Action     Increase the size of the SGA by setting the parameter "sga_target" to 5120 M.
Thanks
Sibusiso
Edited by: 787473 on 10-Aug-2010 02:35

We have been having performance issues and then the SGA was not sized coprrectely.
The size of the SGA was 720mb so we then pushed it to 4 gig which I blv is enough.
We then did a run of the tuning advisory on the top sql queries that were top one,
the advisor then pointed on that we need to use indexes on those queries .
We then advised the developers that they need to use indexes as it will improve
performance .. Yes. As those queries must be missing indexes that would prove to be beneficial. So need to take it query by query and created the required indexes.
This morning the ADDM pointed out that we need to up the sga
to 5 Gig and I dont see this a solution to the problem.
I need to find a note on what benefits does using indexes have on the SGA and the overall perfomance
so that I can show the business that increasing the SGA wont solve the problem.
See screen shot below
erformance Finding Details:
     Database Time (minutes)          33.8
     Period Start Time          10-Aug-2010 10:00:11 o'clock SAST
     Period Duration (minutes)          60.2
     Task Owner          SYS
     Task Name          ADDM:1511773678_1_28498
     Average Active Sessions          0.6
     Finding          The SGA was inadequately sized, causing additional I/O or hard parses.
     Impact (minutes)          14.4
     Impact (%)          [64] [86] 42.8
Recommendations
Show All Details | Hide All Details
Details     Category     Benefit (%) [Sorted in descending order]
[Select to hide information] Hide
     DB Configuration     [64] [86] 42.8
Action     Increase the size of the SGA by setting the parameter "sga_target" to 5120 M.One of the biggest impact of indexes (if they fit in the scenario) is in reducing the IO (by avoiding full table scans). Reduced IO means faster system. Absence of indexes would mean that you read lots of data into the memory [buffer cache] and data would flush out quickly too (to make space for the new data), resulting in more IO. So having indexes in place means you only read as much amount of data as required and frequently accessed data stays in the memory.
Kinda incomplete answer...Lets wait for other experts' comments :)
Edited by: amardeep.sidhu on Aug 10, 2010 3:23 PM

Similar Messages

How oracle decide whetehr to use index or full scan (statistics)

Hi Guys,
Let say i have a index on a column.
The table and index statistics has been gathered. (without histograms).
Let say i perform a select * from table where a=5;
Oracle will perform a full scan.
But from which statistics it will be able to know indeed most of the column = 5? (histograms not used)
After analyzing, we get the below:
Table Statistics :
(NUM_ROWS)
(BLOCKS)
(EMPTY_BLOCKS)
(AVG_SPACE)
(CHAIN_COUNT)
(AVG_ROW_LEN)
Index Statistics :
(BLEVEL)
(LEAF_BLOCKS)
(DISTINCT_KEYS)
(AVG_LEAF_BLOCKS_PER_KEY)
(AVG_DATA_BLOCKS_PER_KEY)
(CLUSTERING_FACTOR)
thanks
Index Column (A)
======
1
1
2
2
5
5
5
5
5
5

I have prepared some explanation and have not noticed that the topic has been marked as answered.
This my sentence is not completely true.
A column "without histograms" means that the column has only one bucket. More correct: even without histograms there are data in dba_tab_histograms which we can consider as one bucket for whole column. In fact these data are retrieved from hist_head$, not from histgrm$ as usual buckets.
Technically there is no any buckets without gathered histograms.
Let's create a table with skewed data distribution.
SQL> create table t as
2 select least(rownum,3) as val, '*' as pad
3    from dual
4 connect by level <= 1000000;
Table created
SQL> create index idx on t(val);
Index created
SQL> select val, count(*)
2    from t
3   group by val;
       VAL   COUNT(*)
         1          1
         2          1
         3     999998So, we have table with very skewed data distribution.
Let's gather statistics without histograms.
SQL> exec dbms_stats.gather_table_stats( user, 'T', estimate_percent => 100, method_opt => 'for all columns size 1', cascade => true);
PL/SQL procedure successfully completed
SQL> select blocks, num_rows from dba_tab_statistics
2   where table_name = 'T';
    BLOCKS   NUM_ROWS
      3106    1000000
SQL> select blevel, leaf_blocks, clustering_factor
2    from dba_ind_statistics t
3   where table_name = 'T'
4     and index_name = 'IDX';
    BLEVEL LEAF_BLOCKS CLUSTERING_FACTOR
         2        4017              3107
SQL> select column_name,
2         num_distinct,
3         density,
4         num_nulls,
5         low_value,
6         high_value
7    from dba_tab_col_statistics
8   where table_name = 'T'
9     and column_name = 'VAL';
COLUMN_NAME NUM_DISTINCT    DENSITY NUM_NULLS      LOW_VALUE      HIGH_VALUE
VAL                     3 0,33333333          0           C102            C104So, Oracle suggests that values between 1 and 3 (raw C102 and C104) are distributed uniform and the density of the distribution is 0.33.
Let's try to explain plan
SQL> explain plan for
2 select --+ no_cpu_costing
3         *
4    from t
5   where val = 1
6 ;
Explained
SQL> @plan
| Id | Operation         | Name | Rows | Cost |
|   0 | SELECT STATEMENT |      |   333K|   300 |
|* 1 | TABLE ACCESS FULL| T    |   333K|   300 |
Predicate Information (identified by operation id):
   1 - filter("VAL"=1)
Note
   - cpu costing is off (consider enabling it)Below is an excerpt from trace 10053
BASE STATISTICAL INFORMATION
Table Stats::
Table: T Alias: T
    #Rows: 1000000 #Blks: 3106 AvgRowLen: 5.00
Index Stats::
Index: IDX Col#: 1
    LVLS: 2 #LB: 4017 #DK: 3 LB/K: 1339.00 DB/K: 1035.00 CLUF: 3107.00
SINGLE TABLE ACCESS PATH
BEGIN Single Table Cardinality Estimation
Column (#1): VAL(NUMBER)
    AvgLen: 3.00 NDV: 3 Nulls: 0 Density: 0.33333 Min: 1 Max: 3
Table: T Alias: T
    Card: Original: 1000000 Rounded: 333333 Computed: 333333.33 Non Adjusted: 333333.33
END   Single Table Cardinality Estimation
Access Path: TableScan
    Cost: 300.00 Resp: 300.00 Degree: 0
      Cost_io: 300.00 Cost_cpu: 0
      Resp_io: 300.00 Resp_cpu: 0
Access Path: index (AllEqRange)
    Index: IDX
    resc_io: 2377.00 resc_cpu: 0
    ix_sel: 0.33333 ix_sel_with_filters: 0.33333
    Cost: 2377.00 Resp: 2377.00 Degree: 1
Best:: AccessPath: TableScan
         Cost: 300.00 Degree: 1 Resp: 300.00 Card: 333333.33 Bytes: 0Cost of FTS here is 300 and cost of Index Range Scan here is 2377.
I have disabled cpu costing, so selectivity does not affect the cost of FTS.
cost of Index Range Scan is calculated as
blevel + (leaf_blocks * selectivity + clustering_factor * selecivity) = 2 + (4017*0.33333 + 3107*0.33333) = 2377.
Oracle considers that it has to read 2 root/branch blocks of the index, 1339 leaf blocks of the index and 1036 blocks of the table.
Pay attention that selectivity is the major component of the cost of the Index Range Scan.
Let's try to gather histograms:
SQL> exec dbms_stats.gather_table_stats( user, 'T', estimate_percent => 100, method_opt => 'for columns val size 3', cascade => true);
PL/SQL procedure successfully completedIf you look at dba_tab_histograms you will see following
SQL> select endpoint_value,
2         endpoint_number
3    from dba_tab_histograms
4   where table_name = 'T'
5     and column_name = 'VAL'
6 ;
ENDPOINT_VALUE ENDPOINT_NUMBER
             1               1
             2               2
             3         1000000ENDPOINT_VALUE is the column value (in number for any type of data) and ENDPOINT_NUMBER is cumulative number of rows.
Number of rows for any ENDPOINT_VALUE = ENDPOINT_NUMBER for this ENDPOINT_VALUE - ENDPOINT_NUMBER for the previous ENDPOINT_VALUE.
explain plan and 10053 trace of the same query:
| Id | Operation                   | Name | Rows | Cost |
|   0 | SELECT STATEMENT            |      |     1 |     4 |
|   1 | TABLE ACCESS BY INDEX ROWID| T    |     1 |     4 |
|* 2 |   INDEX RANGE SCAN          | IDX |     1 |     3 |
Predicate Information (identified by operation id):
   2 - access("VAL"=1)
Note
   - cpu costing is off (consider enabling it)
BASE STATISTICAL INFORMATION
Table Stats::
Table: T Alias: T
    #Rows: 1000000 #Blks: 3106 AvgRowLen: 5.00
Index Stats::
Index: IDX Col#: 1
    LVLS: 2 #LB: 4017 #DK: 3 LB/K: 1339.00 DB/K: 1035.00 CLUF: 3107.00
SINGLE TABLE ACCESS PATH
BEGIN Single Table Cardinality Estimation
Column (#1): VAL(NUMBER)
    AvgLen: 3.00 NDV: 3 Nulls: 0 Density: 5.0000e-07 Min: 1 Max: 3
    Histogram: Freq #Bkts: 3 UncompBkts: 1000000 EndPtVals: 3
Table: T Alias: T
    Card: Original: 1000000 Rounded: 1 Computed: 1.00 Non Adjusted: 1.00
END   Single Table Cardinality Estimation
Access Path: TableScan
    Cost: 300.00 Resp: 300.00 Degree: 0
      Cost_io: 300.00 Cost_cpu: 0
      Resp_io: 300.00 Resp_cpu: 0
Access Path: index (AllEqRange)
    Index: IDX
    resc_io: 4.00 resc_cpu: 0
    ix_sel: 1.0000e-06 ix_sel_with_filters: 1.0000e-06
    Cost: 4.00 Resp: 4.00 Degree: 1
Best:: AccessPath: IndexRange Index: IDX
         Cost: 4.00 Degree: 1 Resp: 4.00 Card: 1.00 Bytes: 0Pay attention on selectivity, ix_sel: 1.0000e-06
Cost of the FTS is still the same = 300,
but cost of the Index Range Scan is 4 now: 2 root/branch blocks + 1 leaf block + 1 table block.
Thus, conclusion: histograms allows to calculate selectivity more accurate. The aim is to have more efficient execution plans.
Alexander Anokhin
http://alexanderanokhin.wordpress.com/

Query Uses Index in 8i but not in 9i

I have simple query which runs good in Oracle 8i. It uses index ,if i use = or in clause.
Same query is not using Index in Oracle 9i,(We made the the optimizer as choose) . If i remove in clause and make it = ,it is using index
select * from DWFE_ELE_CAT_ACC_HISTORY
where udc_acct_num in (Select z.LAH_CURR_LDC_ACCT_NUM
from DWFE_LDC_ACCT_HISTORY B,DWFE_LDC_ACCT_HISTORY z
Where B.LAH_CURR_LDC_ACCT_NUM ='0382900397'
and B.cpa_prem_num = Z.cpa_prem_num );

Plan for Oracle 8i
Execution Plan
0 SELECT STATEMENT Optimizer=RULE
1 0 NESTED LOOPS
2 1 VIEW OF 'VW_NSO_1'
3 2 REMOTE* RSSCP_DB
LINK
4 1 TABLE ACCESS (BY INDEX ROWID) OF 'CAT_TRANS_HISTORY'
5 4 INDEX (RANGE SCAN) OF 'IDX3_CAT_TRANS_HISTORY' (NON-UN
IQUE)
3 SERIAL_FROM_REMOTE SELECT /*+ */ DISTINCT "A1"."LAH_CURR_LDC_AC
CT_NUM" FROM "RSSC"."LDC_ACCT_HISTOR
Statistics
0 recursive calls
0 db block gets
8 consistent gets
0 physical reads
0 redo size
7827 bytes sent via SQL*Net to client
316 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
6 rows processed
Plan for Oracle 9i
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=12018 Card=67728 Byt
es=9752832)
1 0 HASH JOIN (Cost=12018 Card=67728 Bytes=9752832)
2 1 VIEW OF 'VW_NSO_1' (Cost=707 Card=17041 Bytes=238574)
3 2 REMOTE* RSSCP_DB
LINK
4 1 TABLE ACCESS (FULL) OF 'CAT_TRANS_HISTORY' (Cost=6204 Ca
rd=1905290 Bytes=247687700)
3 SERIAL_FROM_REMOTE SELECT /*+ */ "A1"."LAH_CURR_LDC_ACCT_NUM" F
ROM "RSSC"."LDC_ACCT_HISTORY" "A2","
Statistics
42 recursive calls
1 db block gets
41038 consistent gets
41010 physical reads
380 redo size
7833 bytes sent via SQL*Net to client
253 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
6 rows processed

Can Oracle be forced to use the spatial index for sdo_filter in combination with an or clause? Difference between Enterprise and SE?

We’re seeing the following issue: sql - Can Oracle be forced to use the spatial index for sdo_filter in combination with an or clause? - Stack Overflow (posted by a colleague of mine) and are curious to know if this behaviour is due to a difference between standard and enterprise, or could we doing something else wrong in our DB config.?
We have also reproduced the issue on the following stacks:
Oracle SE One 11.2.0.3 (with Spatial enabled)
Redhat Linux 2.6.32-358.6.2.el6.x86_64 #1 SMP Thu May 16 20:59:36 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
11.2.0.3.0 Standard Edition and 11.2.0.4.0 Standard Edition (both with Spatial enabled)
Microsoft Windows Server 2003R2 Standard x64 Edition
However, the SQL works fine if we try it on Oracle 11.2.0.3.0 *Enterprise* Edition.
Any help or advice would be much appreciated.
Kindest Regards,
Kevin

In my experience sdo_filter ALWAYS uses the spatial index, so that's not the problem. Since you did not provide the explain plans, we can't say for sure but I think yhu is right: Standard Edition can't use the bitmap operations, and thus it'll take longer to combine the results of the two queries (because the optimizer will surely split this OR up in two parts, then combine them).
BTW: when asking questions about queries here, it would be nice if you posted the queries here as well, so that we do not have to check another website in order to see what you are doing. Plus it will probably get you more answers, because not everyone can be bothered to click on that link. It would also have been nice if you had posted your own answer on the other post here as well, because my recommendation would have been to use union all - but since you already found that out for yourself my recommendation would have been a little late.

How to use indexes correctly in oracle

Hi guys
on one table i have indexes on 3 columns in the following order
a
b
c
When i m writing a select statement in my where clause what should be the order? like
where
a='some value' and
b='some value' and
c='some value';
or in reverse order like this
c='some value' and
b='some value' and
a='some value';
please let me know.
Thanks

If you have an index on a,b,c the difference in performance can be on the index order.
If column "a" has only 2 unique values then the sub values of the index only has 50% of the remaining values, the cost optimizer on Oracle will probably skip the index as an index scan of 50% is slower than a full table scan.
If a has 100 unique values then the remaining search is only on 1% of the values so is likely to be used.
As with any optimisation try using
explain plan for selec x,y,z from a_table
from where
a='some value' and
b='some value' and
c='some value'
If the index is not being used firstly try
analyze table estimate statistics
sample 10 percent
for all indexes
for all indexed columns;
and failing than try different orders in acceptance environment.

Benefits for using Oracle RAC in SUNCLUSTER

Hi SC expert,
What is the technical benefits of using Oracle RAC in Suncluster, Both are cluster can take care of HA and Load balancing. which are the features are not in Oracle RAC. I am able to configure and check the functionality of Oracle RAC with SC. But I want some technical highlights to project SC have specific benefits over OracleRAC.
Any suggestion and recommentation are welcome.
regards
karthikeyan.N

Hi,
goto http://www.sun.com/cluster and search for "White Paper, Sun Cluster 3.2 Software: Making Oracle Database 10G R2 RAC Even More Unbreakable"
It has all the technical details that you are looking for.
Regards
Hartmut

How to know whether query is using Indexes in oracle?

Please let me know necessary steps to check whether query using indexes.

Try the below and check the explain plan.. See below explain plan using index marked as "RED" font
SET AUTOTRACE TRACEONLY EXPLAIN
SELECT * FROM emp WHERE empno = 7839;
Execution Plan
Plan hash value: 2949544139
| Id | Operation                   | Name   | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |        |     1 |    38 |     1   (0)| 00:00:01 |
|   1 | TABLE ACCESS BY INDEX ROWID| EMP    |     1 |    38 |     1   (0)| 00:00:01 |
|* 2 |   INDEX UNIQUE SCAN         | PK_EMP |     1 |       |     0   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("EMPNO"=7839)

Oracle evolution suggestion : NULL and Index

Hello,
As you know in most of case NULL values are not indexed and then not searchable using index.
Then when you do where MyField is null, you have the risk of doing a full table scan
However most of people don't know that, and then doesn't care of this possible issue and of possible solution (bitmap or including a not null column)
SQL Server, MySQL and probably some others DB don't have the same behavior as they indexes NULL
I know this caveat can be used to have partial indexing by nulling non interesting values and then can't be removed
Then I would suggest to enhance the create index command to allow to index also null with something like that
Create index MyIndex on MyTable(MyColumn including nulls )
As you make this change, perhaps it would be geat to change the behavior documented bellow as it looks more as an old heritage too by adding keyword like "allow null duplicate" and "constraint on null duplicate"
Ascending unique indexes allow multiple NULL values. However, in descending unique indexes, multiple NULL values are treated as duplicate values and therefore are not permitted.
Laurent

Hello,
Thanks, for the links it cover mains solutions to index null values, there's also the usage of bitmap index.
All of them are not very intuitive for an non expert.
But the purpose of my message was mainly to higlight this complexity for a quite basic stuff, as I think that the default solution should be to index nulls and eventually allow to do not index them.
As I said this is the behavior on sql server and mysql. That why i suggest to enhance index behavior to allow to index nulls easily and not by using stange tips like indexing a blank space or a not null column.
This solutions are from my viewpoint workaround, helpfull workaround but still workaround, Oracle database team have the power to change this root cause without breaking ascending compatibility, here is the sense of my message, just hopping they can hear me...
Laurent

Using index and NULL

Hi,
I have the following issue (10.2.0.4)
I have index on NO0_SESSION_ID and TBNAME
how can I force using index ?
Thanks for your help
UPDATE BXAT.no5
   SET TBNAME = :p0,
       REPLICATION_METHOD = :p1,
       STATUS = :p2,
       STARTING_TIME = :p3,
       ENDING_TIME = :p4,
       REC_INSERTED = :p5,
       REC_UPDATED = :p6,
       REC_UNCHANGED = :p7,
       REC_IN_ERROR = :p8,
       REC_CONFLICTS = :p9,
       TOTAL_REC = :p10,
       REC_CONF_UPDATED = :p11,
       REC_CONF_UNCHANGED = :p12,
       MASTER_TABLE = :p13,
       MASTER_SQ0_NRID = :p14,
       NO0_SESSION_ID = :p15,
       REC_PURGED = :p16,
       SQ0_NRID = :p17
WHERE     (NO0_SESSION_ID = :wp18 OR :wp18 IS NULL)
       AND (TBNAME = :wp19 OR :wp19 IS NULL)
| Id | Operation          | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | UPDATE STATEMENT   |      | 1723 | 96488 | 1361   (1)| 00:00:17 |
|   1 | UPDATE            | NO5 |       |       |            |          |
|* 2 |   TABLE ACCESS FULL| NO5 | 1723 | 96488 | 1361   (1)| 00:00:17 |
Predicate Information (identified by operation id):
   2 - filter((:WP19 IS NULL OR "TBNAME"=:WP19) AND (:WP18 IS NULL OR
              "NO0_SESSION_ID"=TO_NUMBER(:WP18)))

user12045475 wrote:
Hi,
I have the following issue (10.2.0.4)
I have index on NO0_SESSION_ID and TBNAME
how can I force using index ?
Thanks for your help
UPDATE BXAT.no5
SET TBNAME = :p0,
REPLICATION_METHOD = :p1,
STATUS = :p2,
STARTING_TIME = :p3,
ENDING_TIME = :p4,
REC_INSERTED = :p5,
REC_UPDATED = :p6,
REC_UNCHANGED = :p7,
REC_IN_ERROR = :p8,
REC_CONFLICTS = :p9,
TOTAL_REC = :p10,
REC_CONF_UPDATED = :p11,
REC_CONF_UNCHANGED = :p12,
MASTER_TABLE = :p13,
MASTER_SQ0_NRID = :p14,
NO0_SESSION_ID = :p15,
REC_PURGED = :p16,
SQ0_NRID = :p17
WHERE     (NO0_SESSION_ID = :wp18 OR :wp18 IS NULL)
AND (TBNAME = :wp19 OR :wp19 IS NULL)
| Id | Operation          | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | UPDATE STATEMENT   |      | 1723 | 96488 | 1361   (1)| 00:00:17 |
|   1 | UPDATE            | NO5 |       |       |            |          |
|* 2 |   TABLE ACCESS FULL| NO5 | 1723 | 96488 | 1361   (1)| 00:00:17 |
Predicate Information (identified by operation id):
2 - filter((:WP19 IS NULL OR "TBNAME"=:WP19) AND (:WP18 IS NULL OR
"NO0_SESSION_ID"=TO_NUMBER(:WP18)))
It has already been pointed out that the FTS is probably due to the OR whatever IS NULL predicates.
A hack that might/might not work - assuming indexes on the columns exist - is to use the syntax
--'' is an empty string, interpreted by Oracle as null
+column+ > ''A better way is to create a function-based index using NVL() or COALECSE on the affected column.

Not Using Index on File Server When Accessing User Files Directly on Server

It appears to me that on a server with an indexed network share (Desktop Experience and Search Indexing roles/features installed), if you access the share directly on the server using its drive path, you can search the folders using the index, which
is much faster and supports finding words inside of the files in seconds). However, if you access the same shared folder via its network path from the server itself, the server ignores the index. I have this experience/problem across all shared folders on
the Windows 2012 R2 Server. Details and my most specific goal follows.
In addition to a laptop, I frequently work directly on a Windows Server 2012 R2 computer. We have Redirected Folders set up on DFS (for failover redundancy) so that my Documents folder is in:
\\network\redirections\user\documents. This all works fine on Windows 7 and 8 client computers connected to the network via Offline Files.
The problem is on the server itself. The server has Desktop Experience enabled and Windows Search is installed. If I navigate manually through the DFS root folder to my documents folder, I can search and it properly uses the index. This proves the location
is properly indexed. However, if I access the folders through the official "Documents" folder from the Folder Redirection (a network share pointing to the same server computer I'm working on), it performs an un-indexed search (slow and ignores file
contents, but does find files eventually if the search term is in their filename). Is there a way to force the server to use the indexed search on the Redirected Folders (my Documents folder in particular) when working on that server when logged in locally
on that server?
I suspect a workaround would be to go into the Registry and manually change the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders to point to the local DFS folder instead of the network share name, but at least one problem
with this is then if I save files with links to other files (e.g., a linked Excel table in a PowerPoint, a mail merge to Access database in Word, etc.) on the server computer, those links will point to d:\DFSroot\... (a physical drive on the computer) instead
of \\network\redirections\user\... (a universally accessible network path) and so none of the other computers will be able to find the linked files, defeating one of the
major benefits of using Redirected Folders.
I can't believe that I need to choose between indexed searching and proper path names in saved files. Surely there is a way to use an indexed search on the server itself?
If you need any more info to help me troubleshoot, please let me know.
Thanks for any help,
Colin

Hi Colin,
It seems that we can not use indexed search on DFS shares. Windows Search works well when users directly access the server. That is, the server is not made available through Distributed File System (DFS).
For more detailed information, you could refer to the links below:
Windows Search Service, Clustered File Services, DFS, Win7 Libraries
https://social.technet.microsoft.com/Forums/windowsserver/en-US/31ac4c16-948b-4ca4-b18f-3a339cdfd5b9/windows-search-service-clustered-file-services-dfs-win7-libraries?forum=winserverfiles
Windows Browse and Organize Features
https://technet.microsoft.com/en-us/library/dd744693(WS.10).aspx
Best Regards,
Mandy
Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact [email protected]

Query result caching on oracle 9 and 10 vs indexing

I am trying to improve performance on oracle 9i and 10g.
We use some queries that take up to 30 minutes to execute.
I heard that there are some products to cache query results.
Would this have any advantage over using indexes or materialized views?
Does anyone know any products that I can use to cache the results of this queries on disk?
Personally I think that by using the query result caching I would reduce the cpu time needed to process the query.
Is this true?

Your message post pushes all the wrong buttons starting with the fact that 9i and 10g are marketing labels not version numbers.
You don't tune queries by spending money and throwing resources at them. You tune them by identifying the problem queries, running explain plans, visualizing their output using DBMS_XPLAN, and addressing the root cause.
If you want help post full version numbers, the SQL statements, and the DBMS_XPLAN outputs.

Query not using indexes

select *
          from hrm_career x
          WHERE x.begin_date = ( SELECT MAX(begin_date)
                         FROM hrm_career y
                         WHERE y.employee_id = x.employee_id AND
                              begin_date <= SYSDATE AND
                              primary_job = 'Y') AND
               x.primary_job = 'Y'
I have the above query which is not using the index created on the BEGIN_DT column
I tried to force using still not using
but when i apply a value say
select *
          from hrm_career x
          WHERE x.begin_date ='10-20-2007'
It is using index and resulting in very fast response
Can some throw some ideas on it...
Where should i look into here ..

SQL> set autotrace traceonly
SQL> select *
2 from hrm_career x
3 WHERE x.begin_date = ( SELECT MAX(begin_date)
4 FROM hrm_career y
5 WHERE y.employee_id = x.employee_id AND
6 begin_date <= SYSDATE AND
7 primary_job = 'Y') AND
8 x.primary_job = 'Y';
13454 rows selected.
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=1417 Card=152 Bytes=
35568)
1 0 FILTER
2 1 SORT (GROUP BY) (Cost=1417 Card=152 Bytes=35568)
3 2 HASH JOIN (Cost=254 Card=47127 Bytes=11027718)
4 3 INDEX (FAST FULL SCAN) OF 'HRM_CAREER_PK' (UNIQUE) (
Cost=12 Card=25026 Bytes=500520)
5 3 TABLE ACCESS (FULL) OF 'HRM_CAREER' (Cost=81 Card=25
335 Bytes=5421690)
Statistics
3671 recursive calls
9 db block gets
1758 consistent gets
2130 physical reads
0 redo size
2217762 bytes sent via SQL*Net to client
10359 bytes received via SQL*Net from client
898 SQL*Net roundtrips to/from client
128 sorts (memory)
1 sorts (disk)
13454 rows processed
TKPROF
TKPROF: Release 9.2.0.6.0 - Production on Wed Dec 12 18:40:56 2007
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Trace file: qnhg_ora_500.trc
Sort options: default
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
ALTER SESSION SET EVENTS '10046 trace name context forever, level 8'
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 1 0.00 0.00 0 0 0 0
Misses in library cache during parse: 0
Misses in library cache during execute: 1
Optimizer goal: CHOOSE
Parsing user id: 30 (ADMIN)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 1 0.00 0.00
SQL*Net message from client 1 34.45 34.45
select condition
from
cdef$ where rowid=:1
call count cpu elapsed disk query current rows
Parse 4 0.00 0.00 0 0 0 0
Execute 4 0.00 0.00 0 0 0 0
Fetch 4 0.00 0.00 0 8 0 4
total 12 0.00 0.00 0 8 0 4
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: SYS (recursive depth: 1)
Rows Row Source Operation
1 TABLE ACCESS BY USER ROWID CDEF$
select *
from hrm_career x
WHERE x.begin_date = ( SELECT MAX(begin_date)
FROM hrm_career y
WHERE y.employee_id = x.employee_id AND
begin_date <= SYSDATE AND
primary_job = 'Y') AND
x.primary_job = 'Y'
call count cpu elapsed disk query current rows
Parse 1 0.00 0.07 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 898 0.00 2.39 2038 946 9 13454
total 900 0.00 2.46 2038 946 9 13454
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 30 (ADMIN)
Rows Row Source Operation
13454 FILTER
25335 SORT GROUP BY
67496 HASH JOIN
25333 INDEX FAST FULL SCAN HRM_CAREER_PK (object id 25292)
25336 TABLE ACCESS FULL HRM_CAREER
Rows Execution Plan
0 SELECT STATEMENT GOAL: CHOOSE
13454 FILTER
25335 SORT (GROUP BY)
67496 HASH JOIN
25333 INDEX GOAL: ANALYZED (FAST FULL SCAN) OF 'HRM_CAREER_PK'
(UNIQUE)
25336 TABLE ACCESS GOAL: ANALYZED (FULL) OF 'HRM_CAREER'
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 898 0.00 0.00
SQL*Net more data to client 877 0.00 0.05
db file sequential read 1 0.01 0.01
db file scattered read 60 0.00 0.14
direct path write 9 0.00 0.00
direct path read 125 0.05 0.13
SQL*Net message from client 898 0.02 1.47
DELETE FROM PLAN_TABLE
WHERE
STATEMENT_ID=:1
call count cpu elapsed disk query current rows
Parse 2 0.00 0.00 0 0 0 0
Execute 2 0.00 0.00 0 6 6 6
Fetch 0 0.00 0.00 0 0 0 0
total 4 0.00 0.00 0 6 6 6
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 30 (ADMIN)
Rows Row Source Operation
0 DELETE
0 TABLE ACCESS FULL PLAN_TABLE
Rows Execution Plan
0 DELETE STATEMENT GOAL: CHOOSE
0 DELETE OF 'PLAN_TABLE'
0 TABLE ACCESS (FULL) OF 'PLAN_TABLE'
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 2 0.00 0.00
SQL*Net message from client 2 14.77 14.79
select o.owner#,o.name,o.namespace,o.remoteowner,o.linkname,o.subname,
o.dataobj#,o.flags
from
obj$ o where o.obj#=:1
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 3 0 1
total 3 0.00 0.00 0 3 0 1
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: SYS (recursive depth: 1)
EXPLAIN PLAN SET STATEMENT_ID='PLUS74964' FOR select *
from hrm_career x
WHERE x.begin_date = ( SELECT MAX(begin_date)
FROM hrm_career y
WHERE y.employee_id = x.employee_id AND
begin_date <= SYSDATE AND
primary_job = 'Y') AND
x.primary_job = 'Y'
call count cpu elapsed disk query current rows
Parse 1 0.00 0.01 0 4 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 2 0.00 0.01 0 4 0 0
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 30 (ADMIN)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 1 0.00 0.00
SQL*Net message from client 1 0.00 0.00
insert into plan_table (statement_id, timestamp, operation, options,
object_node, object_owner, object_name, object_instance, object_type,
search_columns, id, parent_id, position, other,optimizer, cost, cardinality,
bytes, other_tag, partition_start, partition_stop, partition_id,
distribution, cpu_cost, io_cost, temp_space, access_predicates,
filter_predicates )
values
(:1,SYSDATE,:2,:3,:4,:5,:6,:7,:8,:9,:10,:11,:12,:13,:14,:15,:16,:17,:18,:19,
:20,:21,:22,:23,:24,:25,:26,:27)
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 6 0.00 0.00 0 3 6 6
Fetch 0 0.00 0.00 0 0 0 0
total 7 0.00 0.00 0 3 6 6
Misses in library cache during parse: 1
Misses in library cache during execute: 2
Optimizer goal: CHOOSE
Parsing user id: 30 (ADMIN) (recursive depth: 1)
Rows Execution Plan
0 INSERT STATEMENT GOAL: CHOOSE
select o.name, u.name
from
sys.obj$ o, sys.user$ u where obj# = :1 and owner# = user#
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 0 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 1 0.00 0.00 0 0 0 0
Misses in library cache during parse: 1
Parsing user id: SYS (recursive depth: 1)
SELECT ID ID_PLUS_EXP,PARENT_ID PARENT_ID_PLUS_EXP,LPAD(' ',2*(LEVEL-1))
||OPERATION||DECODE(OTHER_TAG,NULL,'','*')||DECODE(OPTIONS,NULL,'','
('||OPTIONS||')')||DECODE(OBJECT_NAME,NULL,'',' OF '''||OBJECT_NAME||'''')
||DECODE(OBJECT_TYPE,NULL,'',' ('||OBJECT_TYPE||')')||DECODE(ID,0,
DECODE(OPTIMIZER,NULL,'',' Optimizer='||OPTIMIZER))||DECODE(COST,NULL,'','
(Cost='||COST||DECODE(CARDINALITY,NULL,'',' Card='||CARDINALITY)
||DECODE(BYTES,NULL,'',' Bytes='||BYTES)||')') PLAN_PLUS_EXP,OBJECT_NODE
OBJECT_NODE_PLUS_EXP
FROM
PLAN_TABLE START WITH ID=0 AND STATEMENT_ID=:1 CONNECT BY PRIOR ID=PARENT_ID
AND STATEMENT_ID=:1 ORDER BY ID,POSITION
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.00 0.00 0 22 0 6
total 4 0.00 0.00 0 22 0 6
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 30 (ADMIN)
Rows Row Source Operation
6 SORT ORDER BY
6 CONNECT BY WITH FILTERING
1 NESTED LOOPS
1 TABLE ACCESS FULL PLAN_TABLE
1 TABLE ACCESS BY USER ROWID PLAN_TABLE
5 NESTED LOOPS
6 BUFFER SORT
6 CONNECT BY PUMP
5 TABLE ACCESS FULL PLAN_TABLE
Rows Execution Plan
0 SELECT STATEMENT GOAL: CHOOSE
6 SORT (ORDER BY)
6 CONNECT BY (WITH FILTERING)
1 NESTED LOOPS
1 TABLE ACCESS (FULL) OF 'PLAN_TABLE'
1 TABLE ACCESS (BY USER ROWID) OF 'PLAN_TABLE'
5 NESTED LOOPS
6 BUFFER (SORT)
6 CONNECT BY PUMP
5 TABLE ACCESS (FULL) OF 'PLAN_TABLE'
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 2 0.00 0.00
SQL*Net message from client 2 0.09 0.09
SELECT ID ID_PLUS_EXP,OTHER_TAG OTHER_TAG_PLUS_EXP,OTHER OTHER_PLUS_EXP
FROM
PLAN_TABLE WHERE STATEMENT_ID=:1 AND OTHER_TAG IS NOT NULL ORDER BY ID
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 3 0 0
total 3 0.00 0.00 0 3 0 0
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 30 (ADMIN)
Rows Row Source Operation
0 SORT ORDER BY
0 TABLE ACCESS FULL PLAN_TABLE
Rows Execution Plan
0 SELECT STATEMENT GOAL: CHOOSE
0 SORT (ORDER BY)
0 TABLE ACCESS (FULL) OF 'PLAN_TABLE'
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 2 0.00 0.00
SQL*Net message from client 2 0.00 0.00
ALTER SESSION SET EVENTS '10046 trace name context off'
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 2 0.00 0.00 0 0 0 0
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 30 (ADMIN)
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 7 0.00 0.09 0 4 0 0
Execute 8 0.00 0.00 0 6 6 6
Fetch 901 0.00 2.39 2038 971 9 13460
total 916 0.00 2.49 2038 981 15 13466
Misses in library cache during parse: 6
Misses in library cache during execute: 1
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 906 0.00 0.00
SQL*Net message from client 906 34.45 50.82
SQL*Net more data to client 877 0.00 0.05
db file sequential read 1 0.01 0.01
db file scattered read 60 0.00 0.14
direct path write 9 0.00 0.00
direct path read 125 0.05 0.13
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 7 0.00 0.00 0 0 0 0
Execute 11 0.00 0.00 0 3 6 6
Fetch 5 0.00 0.00 0 11 0 5
total 23 0.00 0.00 0 14 6 11
Misses in library cache during parse: 4
Misses in library cache during execute: 2
9 user SQL statements in session.
6 internal SQL statements in session.
15 SQL statements in session.
5 statements EXPLAINed in this session.
Trace file: qnhg_ora_500.trc
Trace file compatibility: 9.02.00
Sort options: default
3 sessions in tracefile.
12 user SQL statements in trace file.
8 internal SQL statements in trace file.
15 SQL statements in trace file.
11 unique SQL statements in trace file.
5 SQL statements EXPLAINed using schema:
ADMIN.prof$plan_table
Default table was used.
Table was created.
Table was dropped.
3945 lines in trace file.
Message was edited by:
Maran Viswarayar

Creating a script for a PRIMARY KEY USING INDEX SORT doesn't work

Probably a bug.
h1. Environment
Application: Oracle SQL Developer Data Modeler
Version: 3.0.0.655
h1. Test Case:
1. Create a new table TRANSACTIONS with some columns.
2. Mark one of numeric columns as the primary key - PK_TRANSACTIONS.
3. Go to Physical Models and create new Oracle Database 11g.
4. Go to Physical Models -> Oracle Database 11g -> Tables -> TRANSACTIONS -> Primary Keys -> PK_TRANSACTIONS -> Properties:
a) on General tab set Using Index to BY INDEX NAME
b) on Using Index tab choose a tablespace
c) on Using Index tab set Index Sort to SORTED.
5. Export the schema to DDL script. For the primary key you will get something like this:
ALTER TABLE TRANSACTION
ADD CONSTRAINT PK_TRANSACTION PRIMARY KEY ( TRAN_ID ) DEFERRABLE
USING INDEX
PCTFREE 10
MAXTRANS 255
TABLESPACE TBSPC_INDX
LOGGING
STORAGE (
INITIAL 65536
NEXT 1048576
PCTINCREASE 0
MINEXTENTS 1
MAXEXTENTS 2147483645
FREELISTS 1
FREELIST GROUPS 1
BUFFER_POOL DEFAULT
) SORTED
h1. Reason of failure
The script will fail because SORTED is not allowed here. It should be SORT.
Additionally, the default behaviour for Data Modeler is to set Index Sort to NO but default setting for Oracle database 11g is SORT. Shouldn't Data Modeler use SORT as the default value?
Edited by: user7420841 on 2011-05-07 03:15

Hi,
Thanks for reporting this problem. As you say, it should be SORT rather than SORTED. I have logged a bug on this.
I also agree that, for consistency with the database default, it would be better to have SORT as the default in Data Modeler.
David

CBO calculates un acceptable cost while using index.

Hi,
I was wondering to see the execution plan for both the case using index/without index.
We are using oracle 10G(10.2.0.3.0) with RAC in production at O/S:- sun solaris 10.
Java based application is running in this database. One of the sql query is taking long time to fetch the records. I analyzed the sql plan and noticed the FTS. I created indexes to the column(s) which is refering in where clauses. I noticed a strage behavior. Execution plan shows that the CBO is using right path but its not acceptable as application is time outs while return the rows.
first execution plan with/without index (not using the index).
PLAN_TABLE_OUTPUT
Plan hash value: 419342726
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 196 | 3332 | 67845 (3)| 00:13:35 |
|* 1 | TABLE ACCESS FULL | CWDBENUMDESCRIPTIONS | 1 | 35 | 3 (0)| 00:00:01 |
| 2 | SORT GROUP BY | | 196 | 3332 | 67845 (3)| 00:13:35 |
|* 3 | TABLE ACCESS FULL| CWORDERINSTANCE | 51466 | 854K| 67837 (3)| 00:13:35 |
Predicate Information (identified by operation id):
1 - filter("ERR"."CODE"=:B1)
3 - filter("OI"."ERROR_CODE" IS NOT NULL AND "OI"."DIVISION"='OR9' AND
"OI"."ACTIVE"=TO_NUMBER(:1) AND "OI"."ORDER_STATE"<>'O_NR_NS' AND
"OI"."ORDER_STATE"<>'C_C_QR' AND "OI"."ORDER_STATE"<>'O_NR_NS_D')
SQl query was modified to force the index to use /*+ index(oi oi_div) */ the execution is as below:-
PLAN_TABLE_OUTPUT
Plan hash value: 1157277132
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 196 | 3332 | 394K (1)| 01:18:52 |
|* 1 | TABLE ACCESS FULL | CWDBENUMDESCRIPTIONS | 1 | 35 | 3 (0)| 00:00:01 |
| 2 | SORT GROUP BY | | 196 | 3332 | 394K (1)| 01:18:52 |
|* 3 | TABLE ACCESS BY INDEX ROWID| CWORDERINSTANCE | 51466 | 854K| 394K (1)| 01:18:52 |
|* 4 | INDEX RANGE SCAN | OI_DIV | 3025K| | 14226 (1)| 00:02:51 |
Predicate Information (identified by operation id):
1 - filter("ERR"."CODE"=:B1)
3 - filter("OI"."ERROR_CODE" IS NOT NULL AND "OI"."ACTIVE"=TO_NUMBER(:1) AND
"OI"."ORDER_STATE"<>'O_NR_NS' AND "OI"."ORDER_STATE"<>'C_C_QR' AND
"OI"."ORDER_STATE"<>'O_NR_NS_D')
My questions are here:-
1). why FTS is less costly comparing index scan where there are 15000000 rows in the table.
2). while forcing index to use cost increase drastically (the statistics is latest one analyzed on 6th of feb 2009)
3). what should i suppose to change to get the performance benefit.
Thanks,
Pradeep

user587112 wrote:
select null, oi.division, oi.METADATATYPE, oi.ERROR_CODE,
       ( select err.DESCRIPTION
FROM   CWDBENUMDESCRIPTIONS err
WHERE oi.ERROR_CODE = err.CODE
count(*)
from CWORDERINSTANCE oi
where
     oi.ERROR_CODE is not null
      and oi.division in ('BK9')
     and oi.order_state not in ('O_NR_NS_D', 'C_C_QR', 'O_NR_NS')
      and oi.metadatatype = :1
     and oi.duedate>=:2
     and oi.active = :3
group by oi.division, oi.metadatatype, oi.error_code
order by oi.division, oi.metadatatype, oi.error_code
In this query, if we use as it is how its being displayed, it runs like a rocket, but if we change division in ('OR9') instead of 'BK9' it does not use index and leads to time out the application.
Number of records   division
1964690                             ---------------- why this field is null ?
3090666              OR9
3468                 BA9
1242                 EL9
2702                 IN9
258                  EU9
196198               DT9
1268                 PA9
8                    BK9
2332                 BH9
1405009              TP9
According to the stats in your original execution plan, it looks like you have a histogram on this column, and the index you want to use is on just the division column.
Oracle estimate for 'OR9' is 3M rowids from the index, resulting in 50,000+ rows from the table - that's a lot of work - it's not surprising that the optimizer chose a tablescan for 'OR9' - but chose to use the index for 'BK9' which has only 8 rows.
How often do you want to run this query ? And how accurate does the answer have to be ?
If you want this query to run faster even when it's processing a huge number of rows, one option would be to create a materialized view over the data that could supply the result set much more efficiently (possibly getting your front-end code to call a materialized view refresh before running the query).
The only other altenative is probably to create an index that covers all the columns in the query so that you don't have to visit the table - and if you order them correctly you won't have to do a sort group by. I think this index should do the trick: (division, metadatatype, error_code,active, duedate,orderstate). You could also compress this index on at least the first column, but possibly on far more columns, to minimise the size,
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge."
Stephen Hawking
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.

Oracle.security.jazn.JAZNRuntimeException: Invalid index

Hi all,
I'm getting this exception very often:
oracle.security.jazn.JAZNRuntimeException: Invalid index
     at oracle.security.jazn.oc4j.JAZNFilter.doFilter(JAZNFilter.java:480)
     at com.evermind[Oracle Containers for J2EE 11g (11.1.1.0.0) ].server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:583)
     at com.evermind[Oracle Containers for J2EE 11g (11.1.1.0.0) ].server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:334)
     at com.evermind[Oracle Containers for J2EE 11g (11.1.1.0.0) ].server.http.HttpRequestHandler.doDispatchRequest(HttpRequestHandler.java:942)
     at com.evermind[Oracle Containers for J2EE 11g (11.1.1.0.0) ].server.http.HttpRequestHandler.doProcessRequest(HttpRequestHandler.java:843)
     at com.evermind[Oracle Containers for J2EE 11g (11.1.1.0.0) ].server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:658)
     at com.evermind[Oracle Containers for J2EE 11g (11.1.1.0.0) ].server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:626)
     at com.evermind[Oracle Containers for J2EE 11g (11.1.1.0.0) ].server.http.HttpRequestHandler.serveOneRequest(HttpRequestHandler.java:417)
     at com.evermind[Oracle Containers for J2EE 11g (11.1.1.0.0) ].server.http.HttpRequestHandler.run(HttpRequestHandler.java:189)
     at com.evermind[Oracle Containers for J2EE 11g (11.1.1.0.0) ].server.http.HttpRequestHandler.run(HttpRequestHandler.java:163)
     at oracle.oc4j.network.ServerSocketReadHandler$ClientRunnable.run(ServerSocketReadHandler.java:275)
     at oracle.oc4j.network.ServerSocketAcceptHandler.procClientSocket(ServerSocketAcceptHandler.java:237)
     at oracle.oc4j.network.ServerSocketAcceptHandler.access$800(ServerSocketAcceptHandler.java:29)
     at oracle.oc4j.network.ServerSocketAcceptHandler$AcceptHandlerHorse.run(ServerSocketAcceptHandler.java:877)
     at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
     at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.IllegalStateException: Invalid index
     at org.apache.myfaces.trinidad.bean.util.StateUtils.restoreKey(StateUtils.java:68)
     at org.apache.myfaces.trinidad.bean.util.StateUtils.restoreState(StateUtils.java:142)
     at org.apache.myfaces.trinidad.bean.util.FlaggedPropertyMap.restoreState(FlaggedPropertyMap.java:194)
     at org.apache.myfaces.trinidad.bean.FacesBeanImpl.restoreState(FacesBeanImpl.java:342)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.restoreState(UIXComponentBase.java:898)
     at org.apache.myfaces.trinidad.component.TreeState.restoreState(TreeState.java:57)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState(UIXComponentBase.java:872)
     at org.apache.myfaces.trinidad.component.TreeState.restoreState(TreeState.java:96)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState(UIXComponentBase.java:872)
     at org.apache.myfaces.trinidad.component.TreeState.restoreState(TreeState.java:96)
     at org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState(UIXComponentBase.java:872)
     at org.apache.myfaces.trinidad.component.TreeState.restoreState(TreeState.java:96)...{code}
Usualy when I click on refresh button on browser and in many other cases that I can't recognize as some rule...
Thanks in advance,
s o v i e t

Hi Frank!
This error occur for me when I have "pending" PPR and I start a new one (e.g. fast clicking same button twice). Also, it may happen when I have pending lazy fetching of some table or graph and I hit some action button, or when I refresh a page using browser refresh button (while PPR is still not finished).
And I notice that it doesn't occur when I don't use ADF Controller.
I have not found cause nor workaround, expect to keep users patient until the PPR is finished (blocking attribute is not working in TP4, and your very nice glasspane trick is not appropriate for each and every button click).
Regards,
PaKo

Oracle SGA benefits of using indexes

Similar Messages

Maybe you are looking for