Table scan even with index

i have table called ABC with 300 Million records
i have non clustered index on YearMonth,used_Date
when i run below query / see execution plan its doing Table Scan
can any one help me why is this it should be Index scan right?
Select YearMonth,Min(Used_Date) Min_Used_DateAD,max(Used_Date) Max_Used_Date from [ABC]
group by YearMonth
hi

8> The table scan is is being used because there is no where clause in the query. Since you're including all of the rows in the table, a scan is the most efficient method.
Yeah, but since the index is covering, the index should be scanned, not the table. (Unless there is something weird like they are the only two columns in the table, or the third column is a tinyint so that the data rows are smaller than the index rows.)
Erland Sommarskog, SQL Server MVP, [email protected]

Similar Messages

Full table scan issue with optional params

Hi
I have following problem when writing PL/SQL queries for optional search conditions in the SQL statements
for ex: if there's a select querty with 3 contions as follows
select .......
from
table1 t1 join...
teble2 t2 join
where
( :param1 = -1 or t1.col1 = :param1)
and
( :param2 = -1 or t2.col1 = :param2)
this is mainly to support optional search conditions such as param1 and param2 where when any of those params are option it is passed as -1 so that condition of where clause becomes true and has no filtering.
However once we use this way even the contion columns are indexed those are not used but full scan happens.
if we write dynamic SQL (i.e removing condition check section totally from where clause dynamically based on the value of the param) then the query performs as usual. other option is to duplicate the same query in if ... then.. else block for different values of param1 and param2 .. in that case we would end up with huge SP..
so what's the solution for this kind of scenario... do we have to end up with dynamic SQL (string concatanation to build the query at runtime with required conditions)
Please help me on this. Normally what is the usual approach for such selection query since most search pages have this option to ommit several selection criterias if necessary... so it should be very common problem
Thanks
-Rasika

Hello
Have a look at this link to asktom It shows how to specify a dynamic where clause AND use bind variables in the resulting SQL statement.
HTH
David

Sql statement takes long to execute even with index

Hi
I have the following sql statement.
Its explain plan states its "TABLE ACCESS FULL".
But upon creation of index for table PWRKF2MV, using
IDX(pafidt,ppdept,prodno,ppname) and IDX2(pmfaci,prodno), it uses both indexes
but time taken to execute is still the same as when there is no indexes.
Why is that so? Appreciate any help. Thank you.
Pls take note that the PWRKF2MV is a materialized view and MITBALC0 is a synonym.
SQL statement: -
select a.ppdept dept, rtrim(b.mbsttx) prod, to_char(to_date(a.pafidt,'YYYYMMDD'),'Y')||to_char(to_date(a.pafidt,'YYYYMMDD'),'WW') as yrweek, sum(pmoqty) moqty
from pwrkf2mv a, mitbalc0 b
where a.pafidt between :p_startdate and :p_enddate
and a.ppdept = nvl(:p_dept,a.ppdept)
and a.prodno = nvl(:p_prodno,a.prodno)
and a.ppname like '%'||:p_proddesc||'%'
and rtrim(a.prefno) is not null
and rtrim(b.mbsttx) is not null
and a.pmfaci = b.mbwhlo
and a.prodno = b.mbitno
group by a.ppdept, b.mbsttx, to_char(to_date(a.pafidt,'YYYYMMDD'),'Y')||to_char(to_date(a.pafidt,'YYYYMMDD'),'WW')
order by a.ppdept, yrweek, b.mbsttx;
Siti

Hi Siti,
Is your table goes through frequent update and delete statements? if YES=>
Free blocks created during this operation may dgrade the performance during full
Tbale scan.
If you are using Oracle 10g, you can shrink the segments. But first enable the row movement
sql> alter table emp enable row movement;
http://www.oracle.com/technology/oramag/oracle/05-may/o35tuning.html
JAI HIND
Darshan

Index not being used even with hint

For this query, I'm getting a full table scan even when specifying a hint:
SELECT /*+ index_ffs (d ix_dunsno_dnb_store_data ) */7 as s_no, 'Number of DNB Records' as name, count(distinct( dnb_duns_number)) as value
FROM dnb_store_data d
However, this query uses an index fast full scan, even without the hint:
select count(distinct(dnb_duns_number)) as value from dnb_store_data
Anyone have any ideas??? I'm on oracle 10.2.0.4

SQL> create table myt1 as select * from dba_objects;
Table created.
SQL> create index myt1$objname on myt1(object_name);
Index created.
SQL> explain plan for select /*+ FULL(myt1) */ count(distinct object_name) from myt1;
Explained.
SQL> SET LINESIZE 130
SQL> SET PAGESIZE 0
SQL> SELECT * FROM table(DBMS_XPLAN.DISPLAY);
Plan hash value: 1763129885
| Id | Operation          | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |      |     1 |    66 |    49   (0)| 00:00:01 |
|   1 | SORT GROUP BY     |      |     1 |    66 |            |          |
|   2 |   TABLE ACCESS FULL| MYT1 | 11020 |   710K|    49   (0)| 00:00:01 |
Note
   - dynamic sampling used for this statement
13 rows selected.
SQL> explain plan for select /*+ INDEX_FFS( MYT1$OBJNAME myt1) */ count(distinct object_name) from myt1;
Explained.
SQL> SELECT * FROM table(DBMS_XPLAN.DISPLAY);
Plan hash value: 2781289525
| Id | Operation             | Name         | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT      |              |     1 |    66 |    18   (0)| 00:00:01 |
|   1 | SORT GROUP BY        |              |     1 |    66 |            |          |
|   2 |   INDEX FAST FULL SCAN| MYT1$OBJNAME | 11020 |   710K|    18   (0)| 00:00:01 |
Note
   - dynamic sampling used for this statement
13 rows selected.
SQL> explain plan for select /*+ INDEX_FFS( MYT1$OBJNAME myt1) */ 7 as ttt, count(distinct object_name) from myt1;
Explained.
SQL> SELECT * FROM table(DBMS_XPLAN.DISPLAY);
Plan hash value: 1763129885
| Id | Operation          | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |      |     1 |    66 |    49   (0)| 00:00:01 |
|   1 | SORT GROUP BY     |      |     1 |    66 |            |          |
|   2 |   TABLE ACCESS FULL| MYT1 | 11020 |   710K|    49   (0)| 00:00:01 |
Note
   - dynamic sampling used for this statement
13 rows selected.
SQL> explain plan for select 7 as ttt, ct from ( select count(distinct object_name) ct from myt1);
Explained.
SQL> SELECT * FROM table(DBMS_XPLAN.DISPLAY);
Plan hash value: 4000407046
| Id | Operation              | Name         | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT       |              |     1 |    13 |    18   (0)| 00:00:01 |
|   1 | VIEW                  |              |     1 |    13 |    18   (0)| 00:00:01 |
|   2 |   SORT GROUP BY        |              |     1 |    66 |            |          |
|   3 |    INDEX FAST FULL SCAN| MYT1$OBJNAME | 11020 |   710K|    18   (0)| 00:00:01 |
Note
   - dynamic sampling used for this statement
14 rows selected.So, problem is with '7 as ttt'.

How to avoid full Table scan when using Rule based optimizer (Oracle817)

1. We have a Oracle 8.1.7 DB, and the optimizer_mode is set to "RULE"
2. There are three indexes on table cm_contract_supply, which is a large table having 28732830 Rows, and average row length 149 Bytes
COLUMN_NAME INDEX_NAME
PROGRESS_RECID XAK11CM_CONTRACT_SUPPLY
COMPANY_CODE XIE1CM_CONTRACT_SUPPLY
CONTRACT_NUMBER XIE1CM_CONTRACT_SUPPLY
COUNTRY_CODE XIE1CM_CONTRACT_SUPPLY
SUPPLY_TYPE_CODE XIE1CM_CONTRACT_SUPPLY
VERSION_NUMBER XIE1CM_CONTRACT_SUPPLY
CAMPAIGN_CODE XIF1290CM_CONTRACT_SUPPLY
COMPANY_CODE XIF1290CM_CONTRACT_SUPPLY
COUNTRY_CODE XIF1290CM_CONTRACT_SUPPLY
SUPPLIER_BP_ID XIF801CONTRACT_SUPPLY
COMMISSION_LETTER_CODE XIF803CONTRACT_SUPPLY
COMPANY_CODE XIF803CONTRACT_SUPPLY
COUNTRY_CODE XIF803CONTRACT_SUPPLY
COMPANY_CODE XPKCM_CONTRACT_SUPPLY
CONTRACT_NUMBER XPKCM_CONTRACT_SUPPLY
COUNTRY_CODE XPKCM_CONTRACT_SUPPLY
SUPPLY_SEQUENCE_NUMBER XPKCM_CONTRACT_SUPPLY
VERSION_NUMBER XPKCM_CONTRACT_SUPPLY
3. We are querying the table for a particular contract_number and version_number. We want to avoid full table scan.
SELECT /*+ INDEX(XAK11CM_CONTRACT_SUPPLY) */
rowid, pms.cm_contract_supply.*
FROM pms.cm_contract_supply
WHERE
contract_number = '0000000000131710'
AND version_number = 3;
However despite of giving hint, query results are fetched after full table scan.
Execution Plan
0 SELECT STATEMENT Optimizer=RULE (Cost=1182 Card=1 Bytes=742)
1 0 TABLE ACCESS (FULL) OF 'CM_CONTRACT_SUPPLY' (Cost=1182 Card=1 Bytes=742)
4. I have tried giving
SELECT /*+ FIRST_ROWS + INDEX(XAK11CM_CONTRACT_SUPPLY) */
rowid, pms.cm_contract_supply.*
FROM pms.cm_contract_supply
WHERE
contract_number = '0000000000131710'
AND version_number = 3;
and
SELECT /*+ CHOOSE + INDEX(XAK11CM_CONTRACT_SUPPLY) */
rowid, pms.cm_contract_supply.*
FROM pms.cm_contract_supply
WHERE
contract_number = '0000000000131710'
AND version_number = 3;
But it does not work.
Is there some way without changing optimizer mode and without creating an additional index, we can use the index instead of full table scan?

David,
Here is my test on a Oracle 10g database.
SQL> create table mytable as select * from all_tables;
Table created.
SQL> set autot traceonly
SQL> alter session set optimizer_mode = choose;
Session altered.
SQL> select count(*) from mytable;
Execution Plan
   0      SELECT STATEMENT Optimizer=CHOOSE
   1    0   SORT (AGGREGATE)
   2    1     TABLE ACCESS (FULL) OF 'MYTABLE' (TABLE)
Statistics
          1 recursive calls
          0 db block gets
         29 consistent gets
          0 physical reads
          0 redo size
        223 bytes sent via SQL*Net to client
        276 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          1 rows processed
SQL> analyze table mytable compute statistics;
Table analyzed.
SQL> select count(*) from mytable
2 ;
Execution Plan
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=11 Card=1)
   1    0   SORT (AGGREGATE)
   2    1     TABLE ACCESS (FULL) OF 'MYTABLE' (TABLE) (Cost=11 Card=1
          788)
Statistics
          1 recursive calls
          0 db block gets
         29 consistent gets
          0 physical reads
          0 redo size
        222 bytes sent via SQL*Net to client
        276 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          1 rows processed
SQL> disconnect
Disconnected from Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - 64bit Production
With the Partitioning, Oracle Label Security, OLAP and Data Mining options

Query occasionally causes table scans (db file sequential read)

Dear all,
we periodically issue a query on a huge table via an oracle job.
Whenever I invoke the query manually, the response time is good. When I start the periodic job, initially the response times are good as well. After some days, however, the query suddenly takes almost forever.
My vague guess is that for some reason the query suddenly changes the execution plan from using the primary key index to a full table scan (or huge index range scan). Maybe because of some problems with the primary key index (fragmentation? Other?).
- Could it be the case that the execution plan for a query changes (automatically) like this? For what reasons?
- Do you have any hints where to look for further information for analysis? (logs, special event types, ...)?
- Of course, the query was designed having involved indexes in mind. Also, I studied the execution plan and did not find hints for problematic table/range scans.
- It is not a lock contention problem
- When the query "takes forever", there is a "db file sequential read" event in v$session_event for the query with an ever increasing wait time. That's why I guess a (unreasonable) table scan is happening.
Some charachteristics of the table in question:
- ~ 30 Mio rows
- There are only insertions to the table, as well as updates on a single, indexed field. No deletes.
- There is an integer primary key field with an B-tree index.
Charachteristics of the query:
The main structure of the query is very simple and as follows: I select a range of about 100 rows via primary key "id", like:
Select * from TheTable where id>11222300 and id <= 11222400
There are several joins with rather small tables, which make the overall query more complicated.
However, the few (100) rows of the huge table in question should always be fetched using the primary key index, shouldn't it?
Please let me know if some relevant information about the problem is missing.
Thanks!
Best regards,
Nang.

user2560749 wrote:
Dear all,
we periodically issue a query on a huge table via an oracle job.
Whenever I invoke the query manually, the response time is good. When I start the periodic job, initially the response times are good as well. After some days, however, the query suddenly takes almost forever.
My vague guess is that for some reason the query suddenly changes the execution plan from using the primary key index to a full table scan (or huge index range scan). Maybe because of some problems with the primary key index (fragmentation? Other?).
- Could it be the case that the execution plan for a query changes (automatically) like this? For what reasons?Yes possible, One reason is stats of the table has been changed i.e somebody issued dbms_stats. If you are worried about execution plan getting changed then two option 1) Lock the stats 2) Use hint in the query.
- Do you have any hints where to look for further information for analysis? (logs, special event types, ...)?Have a Ora-10053 trace enabled whenever query plan changes and analysis it.
- Of course, the query was designed having involved indexes in mind. Also, I studied the execution plan and did not find hints for problematic table/range scans.
- It is not a lock contention problem
- When the query "takes forever", there is a "db file sequential read" event in v$session_event for the query with an ever increasing wait time. That's why I guess a (unreasonable) table scan is happening.
If it db file sequential read then i see two things 1) It is doing index range scan(Not table full scan) or 2) It is scanning undo tablespaces.
Some charachteristics of the table in question:
- ~ 30 Mio rows
- There are only insertions to the table, as well as updates on a single, indexed field. No deletes.
- There is an integer primary key field with an B-tree index.
Charachteristics of the query:
The main structure of the query is very simple and as follows: I select a range of about 100 rows via primary key "id", like:
Select * from TheTable where id>11222300 and id <= 11222400
There are several joins with rather small tables, which make the overall query more complicated.
However, the few (100) rows of the huge table in question should always be fetched using the primary key index, shouldn't it?
Yes theoreitically it should practically we can only say by looking at run time explain plan(through 10053,10046 trace).
Please let me know if some relevant information about the problem is missing.
Thanks!
Best regards,
Nang.I am still not sure in which direction you are looking for solution.
Is your query performing bad once in a fortnight and next day it is all same again.
I suggest to
1) Check if the data is scanning undo tablespace. I see you mentioned there is lot of inserts, could be that Oracle would be scanning undo tablespace because of delayed clean out.
2) Check if that particular day the number of records are high compared to other day.
Or once it starts performing bad then for next couple of days there is no change in response time.
1) Check if explain plan has been changed?
And what action you take to bring back the response time to normal?
Regards
Anurag

Full table scan

Hello,
I am working on Oracle 9i and IBM AIX O/S .I am working on two database ..one is production and other one is development.
we are having one select statement which we are running on both database .. On development database this sql stetement is using indexes and give result fast but in production enviornment it is using full table scan for all table and taking time to execute.
The number of rows returning in both envoronment are also al most same ..
I checked that almost all parameters in both databases are same and we use to collect stats on both databses .So stats are also current ..
What all parameters is need to check and what easle i can do to make query using indexes ...?
Any idea...

oradba11 wrote:
Is this true that if we are fetching more then 15% of rows of a table ...oracle will prefer full table scan instead of index read..? Depend index,table stats,selectivity of predicate(so type of query,effective table ,index selectivity and clustering factor)
is this can be a reason for this ..?
any idea ..?Are both databases running in same host?
In both databases did you collected system stats?
In both databases optimizer related parameters are same?
You said,you collected statistics both table ok,but collection methods are same?(mean have you collected histograms both table or for one only).
Also investigate index structure and columns.(post here both table and index structure)
If CBO choose FULL TABLE SCAN(FTS) over INDEX RANGE SCAN(IS) it mean CBO can not use this index or cost of index scan actually expensive than FTS,in this case CBO choose FTS.In additionally depend your query predicate and literal values oracle can choose FTS or IS(depend predicate literals/condition and if here histograms are available).
And finally here is main matter is properties of index,you have to check clustering factor and leaf blocks of your index,due to cost of IS directly related of them.

Query optimization - Query is taking long time even there is no table scan in execution plan

Hi All,
The below query execution is taking very long time even there are all required indexes present.
Also in execution plan there is no table scan. I did a lot of research but i am unable to find a solution.
Please help, this is required very urgently. Thanks in advance. :)
WITH cte
AS (
SELECT Acc_ex1_3
FROM Acc_ex1
INNER JOIN Acc_ex5 ON (
Acc_ex1.Acc_ex1_Id = Acc_ex5.Acc_ex5_Id
AND Acc_ex1.OwnerID = Acc_ex5.OwnerID
WHERE (
cast(Acc_ex5.Acc_ex5_92 AS DATETIME) >= '12/31/2010 18:30:00'
AND cast(Acc_ex5.Acc_ex5_92 AS DATETIME) < '01/31/2014 18:30:00'
SELECT DISTINCT R.ReportsTo AS directReportingUserId
,UC.UserName AS EmpName
,UC.EmployeeCode AS EmpCode
,UEx1.Use_ex1_1 AS PortfolioCode
SELECT TOP 1 TerritoryName
FROM UserTerritoryLevelView
WHERE displayOrder = 6
AND UserId = R.ReportsTo
) AS BranchName
,GroupsNotContacted AS groupLastContact
,GroupCount AS groupTotal
FROM ReportingMembers R
INNER JOIN TeamMembers T ON (
T.OwnerID = R.OwnerID
AND T.MemberID = R.ReportsTo
AND T.ReportsTo = 1
INNER JOIN UserContact UC ON (
UC.CompanyID = R.OwnerID
AND UC.UserID = R.ReportsTo
INNER JOIN Use_ex1 UEx1 ON (
UEx1.OwnerId = R.OwnerID
AND UEx1.Use_ex1_Id = R.ReportsTo
INNER JOIN (
SELECT Accounts.AssignedTo
,count(DISTINCT Acc_ex1_3) AS GroupCount
FROM Accounts
INNER JOIN Acc_ex1 ON (
Accounts.AccountID = Acc_ex1.Acc_ex1_Id
AND Acc_ex1.Acc_ex1_3 > '0'
AND Accounts.OwnerID = 109
GROUP BY Accounts.AssignedTo
) TotalGroups ON (TotalGroups.AssignedTo = R.ReportsTo)
INNER JOIN (
SELECT Accounts.AssignedTo
,count(DISTINCT Acc_ex1_3) AS GroupsNotContacted
FROM Accounts
INNER JOIN Acc_ex1 ON (
Accounts.AccountID = Acc_ex1.Acc_ex1_Id
AND Acc_ex1.OwnerID = Accounts.OwnerID
AND Acc_ex1.Acc_ex1_3 > '0'
INNER JOIN Acc_ex5 ON (
Accounts.AccountID = Acc_ex5.Acc_ex5_Id
AND Acc_ex5.OwnerID = Accounts.OwnerID
WHERE Accounts.OwnerID = 109
AND Acc_ex1.Acc_ex1_3 NOT IN (
SELECT Acc_ex1_3
FROM cte
GROUP BY Accounts.AssignedTo
) TotalGroupsNotContacted ON (TotalGroupsNotContacted.AssignedTo = R.ReportsTo)
WHERE R.OwnerID = 109
Please mark it as an answer/helpful if you find it as useful. Thanks, Satya Prakash Jugran

Hi All,
Thanks for the replies.
I have optimized that query to make it run in few seconds.
Here is my final query.
select ReportsTo as directReportingUserId,
UserName AS EmpName,
EmployeeCode AS EmpCode,
Use_ex1_1 AS PortfolioCode,
BranchName,
GroupInfo.groupTotal,
GroupInfo.groupLastContact,
case when exists
(select 1 from ReportingMembers RM
where RM.ReportsTo = UserInfo.ReportsTo
and RM.MemberID <> UserInfo.ReportsTo
) then 0 else UserInfo.ReportsTo end as memberid1,
(select code from Regions where ownerid=109 and name=UserInfo.BranchName) as BranchCode,
ROW_NUMBER() OVER (ORDER BY directReportingUserId) AS ROWNUMBER
FROM
(select distinct R.ReportsTo, UC.UserName, UC.EmployeeCode,UEx1.Use_ex1_1,
(select top 1 TerritoryName
from UserTerritoryLevelView
where displayOrder = 6
and UserId = R.ReportsTo) as BranchName,
Case when R.ReportsTo = Accounts.AssignedTo then Accounts.AssignedTo else 0 end as memberid1
from ReportingMembers R
INNER JOIN TeamMembers T ON (T.OwnerID = R.OwnerID AND T.MemberID = R.ReportsTo AND T.ReportsTo = 1)
inner join UserContact UC on (UC.CompanyID = R.OwnerID and UC.UserID = R.ReportsTo )
inner join Use_ex1 UEx1 on (UEx1.OwnerId = R.OwnerID and UEx1.Use_ex1_Id = R.ReportsTo)
inner join Accounts on (Accounts.OwnerID = 109 and Accounts.AssignedTo = R.ReportsTo)
union
select distinct R.ReportsTo, UC.UserName, UC.EmployeeCode,UEx1.Use_ex1_1,
(select top 1 TerritoryName
from UserTerritoryLevelView
where displayOrder = 6
and UserId = R.ReportsTo) as BranchName,
Case when R.ReportsTo = Accounts.AssignedTo then Accounts.AssignedTo else 0 end as memberid1
from ReportingMembers R
--INNER JOIN TeamMembers T ON (T.OwnerID = R.OwnerID AND T.MemberID = R.ReportsTo)
inner join UserContact UC on (UC.CompanyID = R.OwnerID and UC.UserID = R.ReportsTo)
inner join Use_ex1 UEx1 on (UEx1.OwnerId = R.OwnerID and UEx1.Use_ex1_Id = R.ReportsTo)
inner join Accounts on (Accounts.OwnerID = 109 and Accounts.AssignedTo = R.ReportsTo)
where R.MemberID = 1
) UserInfo
inner join
select directReportingUserId, sum(Groups) as groupTotal, SUM(GroupsNotContacted) as groupLastContact
from
select distinct R.ReportsTo as directReportingUserId, Acc_ex1_3 as GroupName, 1 as Groups,
case when Acc_ex5.Acc_ex5_92 between GETDATE()-365*10 and GETDATE() then 1 else 0 end as GroupsNotContacted
FROM ReportingMembers R
INNER JOIN TeamMembers T
ON (T.OwnerID = R.OwnerID AND T.MemberID = R.ReportsTo AND T.ReportsTo = 1)
inner join Accounts on (Accounts.OwnerID = 109 and Accounts.AssignedTo = R.ReportsTo)
inner join Acc_ex1 on (Acc_ex1.OwnerID = 109 and Acc_ex1.Acc_ex1_Id = Accounts.AccountID and Acc_ex1.Acc_ex1_3 > '0')
inner join Acc_ex5 on (Acc_ex5.OwnerID = 109 and Acc_ex5.Acc_ex5_Id = Accounts.AccountID )
--where TerritoryID in ( select ChildRegionID RegionID from RegionWithSubRegions where OwnerID =109 and RegionID = 729)
union
select distinct R.ReportsTo as directReportingUserId, Acc_ex1_3 as GroupName, 1 as Groups,
case when Acc_ex5.Acc_ex5_92 between GETDATE()-365*10 and GETDATE() then 1 else 0 end as GroupsNotContacted
FROM ReportingMembers R
INNER JOIN TeamMembers T
ON (T.OwnerID = R.OwnerID AND T.MemberID = R.ReportsTo)
inner join Accounts on (Accounts.OwnerID = 109 and Accounts.AssignedTo = R.ReportsTo)
inner join Acc_ex1 on (Acc_ex1.OwnerID = 109 and Acc_ex1.Acc_ex1_Id = Accounts.AccountID and Acc_ex1.Acc_ex1_3 > '0')
inner join Acc_ex5 on (Acc_ex5.OwnerID = 109 and Acc_ex5.Acc_ex5_Id = Accounts.AccountID )
--where TerritoryID in ( select ChildRegionID RegionID from RegionWithSubRegions where OwnerID =109 and RegionID = 729)
where R.MemberID = 1
) GroupWiseInfo
group by directReportingUserId
) GroupInfo
on UserInfo.ReportsTo = GroupInfo.directReportingUserId
Please mark it as an answer/helpful if you find it as useful. Thanks, Satya Prakash Jugran

Function based indexes doing full table scan

Guys,
I am testing function based indexes and whatever I do
it is doing a full table scan.
1)I have set the following init parameters as
QUERY_REWRITE_ENABLED=TRUE
QUERY_REWRITE_INTEGRITY=TRUSTED
2)CREATE INDEX i3 ON emp(UPPER(ename));
3) ANALYZE TABLE emp COMPUTE STATISTICS
ANALYZE INDEX I3 COMPUTE STATISTICS
4) DELETE plan_table;
5) EXPLAIN PLAN SET statement_id='Test1' FOR
SELECT ename FROM emp WHERE UPPER(ename) = 'KING';
6) SELECT LPAD(' ',2*level-2)||operation||' '||options||' '||object_name
query_plan
FROM plan_table
WHERE statement_id='Test1'
CONNECT BY prior id = parent_id
START WITH id = 0 order by id
7) And the query plan shows as
SELECT STATEMENT
TABLE ACCESS FULL EMP
I am using 9.0.1.4 !!!
Any help is appreciated !!!
Regards,
A.Kishore

One of the many new features in Oracle 8i is the Function-Based Index (we will refrain from using FBI, but only just). This allows the DBA to create indexes on functions or expressions; these functions can be user generated pl/sql functions, standard SQL functions (non-aggregate only) or even a C callout.
A classic problem the DBA faces in SQL Tuning is how to tune those queries that use function calls in the where clause, and result in indexes created on these columns not to be used.
Example
Standard B-Tree index on SURNAME with cost based optimizer
create index non_fbi on sale_contacts (surname);
analyze index non_fbi compute statistics;
analyze table sale_contacts compute statistics;
SELECT count(*) FROM sale_contacts
WHERE UPPER(surname) = 'ELLISON';
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=1 Bytes=17)
1 0 SORT (AGGREGATE)
2 1 TABLE ACCESS (FULL) OF 'SALES_CONTACTS' (Cost=3 Card=16 Bytes=272)
Now we use a function based index
create index fbi on sale_contacts (UPPER(surname));
analyze index fbi compute statistics;
analyze table sale_contacts compute statistics;
SELECT count(*) FROM sale_contacts WHERE UPPER(surname) = 'ELLISON';
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=17)
1 0 SORT (AGGREGATE)
2 1 INDEX (RANGE SCAN) OF 'FBI' (NON-UNIQUE) (Cost=2 Card=381 Bytes=6477)
The function-based index has forced the optimizer to use index range scans (retuning zero or more rowids) on the surname column rather than doing a full table scan (non-index lookup). Optimal performance does vary depending on table size, uniqueness and selectivity of columns, use of fast full table scans etc. Therefore try both methods to gain optimal performance in your database.
It is important to remember that the function-based B*Tree index does not store the expression results in the index but uses an "expression tree". The optimizer performs expression matching by parsing the expression used in the SQL statement and comparing the results against the expression-tree values in the function-based index. This comparison IS case sensitive (ignores spaces) and therefore your function-based index expressions should match expressions used in the SQL statement where clauses.
Init.ora Parameters
The following parameter must be set in your parameter file: QUERY_REWRITE_INTEGRITY = TRUSTED
QUERY_REWRITE_ENABLED = TRUE
COMPATIBLE = 8.1.0.0.0 (or higher)
Grants
Grants To create function-based indexes the user must be granted CREATE INDEX and QUERY REWRITE, or alternatively be granted CREATE ANY INDEX and GLOBAL QUERY REWRITE. The index owner must have EXECUTE access on the function used for the index. If execute access is revoked then the function-based index will be "disabled" (see dba_indexes).
Disabled Indexes
If your function-based index has a status of "disabled" the DBA can do one of the following:
a) drop and create the index (take note of its current settings)
b) alter index enable, function-based indexes only, also use disable keyword as required
c) alter index unusable.
Queries on a DISABLED index fail if the optimizer chooses to use the index.Here is an example ORA error:
ERROR at line 1: ORA-30554: function-based index MYUSER.FBI is disabled.
All DML operations on a DISABLED index also fail unless the index is also marked UNUSABLE and the initialization parameter SKIP_UNUSABLE_INDEXES is set to true.
Some more Examples
CREATE INDEX expression_ndx
ON mytable ((mycola + mycolc) * mycolb);
SELECT mycolc FROM mytable
WHERE (mycola + mycolc) * mycolb <= 256;
..or a composite index..
CREATE INDEX example_ndx
ON myexample (mycola, UPPER(mycolb), mycolc);
SELECT mycolc FROM myexample
WHERE mycola = 55 AND UPPER(mycolb) = 'JONES';
Restriction & Rule Summary
The following restrictions apply to function based indexes. You may not index:
a) LOB columns
b) REF
c) Nested table column
d) Objects types with any of the above data types.
Function-based indexes must always follow these rules:
a) Cost Based optimizer only, must generate statistics after the index is created
b) Can not store NULL values (function can not return NULL under any circumstance)
c) If a user defined pl/sql routine is used for the function-based index, and is invalidated, the index will become "disabled"
d) Functions must be deterministic (always return the same value for a known input)
e) The index owner must have "execute" access on function used in the function-based index. Revocation of the privilege will render the index "disabled"
f) May have a B-Tree and Bitmap index type only
g) Can not use expressions that are based on aggregate functions, ie. SUM, AVG etc.
h) To alter a function-based index as enabled, the function used must be valid, deterministic and the signature of the function matches the signature of the function when it was created.
Joel P�rez

Help with table scan

I have a problem with full table scans that make very slow the performance of a report.
The test case is below. It looks that when the column is called from the table, the index is in use. If I use the same select from the view, then I get a table scan.
I would appreciate any idea on how to optimize it.
Thanks a lot for the help.
mj
<pre>
create table test1 (id1 number , id2 number, id3 number, col1 varchar(10),col2 varchar(50), col3 varchar(100));
create table test2 (id4 number , id5 number, id6 number, col4 varchar(10),col5 varchar(50), col6 varchar(100));
ALTER TABLE test1 ADD CONSTRAINT PK_test1 PRIMARY KEY(ID1) USING INDEX REVERSE;
create index index1 on test1(ID2);
create index index2 on test1(ID3,col2 );
ALTER TABLE test2 ADD CONSTRAINT PK_test2 PRIMARY KEY(ID4) USING INDEX REVERSE;
create or replace view test_view as select t1.*,
case (select t2.id4 from test2 t2 where t1.id2 = t2.id5 and t2.id6 = -1)
when t1.id2 then t1.id3
else t1.id2
end as main_id
from test1 t1 ;
create or replace view test_view2 as select * from test_view; --(requred by security levels)
select * from test1 where id2 =1000;
select * from test_view where id2 = 1000;
select * from test_view2 where id2 = 1000;
SQL> select * from test_view where id2 = 1000;
Elapsed: 00:00:00.00
Execution Plan
Plan hash value: 1970977999
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 125 | 1 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL | TEST2 | 1 | 39 | 2 (0)| 00:00:01 |
| 2 | TABLE ACCESS BY INDEX ROWID| TEST1 | 1 | 125 | 1 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | INDEX1 | 1 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter("T2"."ID5"=:B1 AND "T2"."ID6"=(-1))
3 - access("T1"."ID2"=1000)
SQL> select * from test_view where main_id = 1000;
Elapsed: 00:00:00.03
Execution Plan
Plan hash value: 3806368241
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 125 | 4 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL | TEST2 | 1 | 39 | 2 (0)| 00:00:01 |
|* 2 | FILTER | | | | | |
| 3 | TABLE ACCESS FULL| TEST1 | 1 | 125 | 2 (0)| 00:00:01 |
|* 4 | TABLE ACCESS FULL| TEST2 | 1 | 39 | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter("T2"."ID5"=:B1 AND "T2"."ID6"=(-1))
2 - filter(CASE WHEN "T1"."ID2"= (SELECT /*+ */ "T2"."ID4" FROM
MJ42."TEST2" "T2" WHERE "T2"."ID5"=:B1 AND "T2"."ID6"=(-1)) THEN
"T1"."ID3" ELSE "T1"."ID2" END =1000)
4 - filter("T2"."ID5"=:B1 AND "T2"."ID6"=(-1))
SQL>
</pre>

If you think about what the two queries are doing, it is easy to see why the first uses an index and the second does not.
Your first query:
SELECT * FROM test_view WHERE id2 = 1000explicitly uses an indexed column from test1 in the predicate. Oracle can use the index to identify the correct row from test1. Having found that single row in test1, it uses the FULL SCAN test2 to resolve the case statement.
Your second query:
SELECT * FROM test_view WHERE main_id = 1000uses the result of the case statement as the predicate. Oracle has no way of determing what row from test1 to use initially, so it must full scan both tables.
John

Preventing Discoverer using Full Table Scans with Decode in a View

Hi Forum,
Hope you are can help, it involves a performance issues when creating a Report / Query in Discoverer.
I have a Discoverer Report that currently takes less than 5 seconds to run. After I add a condition to bring back Batch Status that = Posted we cancelled the query after reaching 20 minutes as this is way too long. If I remove the condition the query time goes back to less than 5 seconds. Changing the condition to Batch Status that = Unposted returns the query in seconds.
Ive been doing some digging and have found the database view that is linked to the Journal Batches folder in Discoverer. See at end of post.
I think the problem is with the column using DECODE. When querying the column in TOAD the value of P is returned. But in discoverer the condition is done on the value Posted. Im not too sure how DECODE works, but think this could be the causing some sort of issue with Full Table Scans.
Any idea how do we get around this?
SELECT
JOURNAL_BATCH1.JE_BATCH_ID,
JOURNAL_BATCH1.NAME,
JOURNAL_BATCH1.SET_OF_BOOKS_ID,
GL_SET_OF_BOOKS.NAME,
DECODE( JOURNAL_BATCH1.STATUS,
'+', 'Unable to validate or create CTA',
'+*', 'Was unable to validate or create CTA',
'-','Invalid or inactive rounding differences account in journal entry',
'-*', 'Modified invalid or inactive rounding differences account in journal entry',
'<', 'Showing sequence assignment failure',
'<*', 'Was showing sequence assignment failure',
'>', 'Showing cutoff rule violation',
'>*', 'Was showing cutoff rule violation',
'A', 'Journal batch failed funds reservation',
'A*', 'Journal batch previously failed funds reservation',
'AU', 'Showing batch with unopened period',
'B', 'Showing batch control total violation',
'B*', 'Was showing batch control total violation',
'BF', 'Showing batch with frozen or inactive budget',
'BU', 'Showing batch with unopened budget year',
'C', 'Showing unopened reporting period',
'C*', 'Was showing unopened reporting period',
'D', 'Selected for posting to an unopened period',
'D*', 'Was selected for posting to an unopened period',
'E', 'Showing no journal entries for this batch',
'E*', 'Was showing no journal entries for this batch',
'EU', 'Showing batch with unopened encumbrance year',
'F', 'Showing unopened reporting encumbrance year',
'F*', 'Was showing unopened reporting encumbrance year',
'G', 'Showing journal entry with invalid or inactive suspense account',
'G*', 'Was showing journal entry with invalid or inactive suspense account',
'H', 'Showing encumbrance journal entry with invalid or inactive reserve account',
'H*', 'Was showing encumbrance journal entry with invalid or inactive reserve account',
'I', 'In the process of being posted',
'J', 'Showing journal control total violation',
'J*', 'Was showing journal control total violation',
'K', 'Showing unbalanced intercompany journal entry',
'K*', 'Was showing unbalanced intercompany journal entry',
'L', 'Showing unbalanced journal entry by account category',
'L*', 'Was showing unbalanced journal entry by account category',
'M', 'Showing multiple problems preventing posting of batch',
'M*', 'Was showing multiple problems preventing posting of batch',
'N', 'Journal produced error during intercompany balance processing',
'N*', 'Journal produced error during intercompany balance processing',
'O', 'Unable to convert amounts into reporting currency',
'O*', 'Was unable to convert amounts into reporting currency',
'P', 'Posted',
'Q', 'Showing untaxed journal entry',
'Q*', 'Was showing untaxed journal entry',
'R', 'Showing unbalanced encumbrance entry without reserve account',
'R*', 'Was showing unbalanced encumbrance entry without reserve account',
'S', 'Already selected for posting',
'T', 'Showing invalid period and conversion information for this batch',
'T*', 'Was showing invalid period and conversion information for this batch',
'U', 'Unposted',
'V', 'Journal batch is unapproved',
'V*', 'Journal batch was unapproved',
'W', 'Showing an encumbrance journal entry with no encumbrance type',
'W*', 'Was showing an encumbrance journal entry with no encumbrance type',
'X', 'Showing an unbalanced journal entry but suspense not allowed',
'X*', 'Was showing an unbalanced journal entry but suspense not allowed',
'Z', 'Showing invalid journal entry lines or no journal entry lines',
'Z*', 'Was showing invalid journal entry lines or no journal entry lines', NULL ),
DECODE( JOURNAL_BATCH1.ACTUAL_FLAG, 'A', 'Actual', 'B', 'Budget', 'E', 'Encumbrance', NULL ),
JOURNAL_BATCH1.DEFAULT_PERIOD_NAME,
JOURNAL_BATCH1.POSTED_DATE,
JOURNAL_BATCH1.DATE_CREATED,
JOURNAL_BATCH1.DESCRIPTION,
DECODE( JOURNAL_BATCH1.AVERAGE_JOURNAL_FLAG, 'N', 'Standard', 'Y', 'Average', NULL ),
DECODE( JOURNAL_BATCH1.BUDGETARY_CONTROL_STATUS, 'F', 'Failed', 'I', 'In Process', 'N', 'N/A', 'P', 'Passed', 'R', 'Required', NULL ),
DECODE( JOURNAL_BATCH1.APPROVAL_STATUS_CODE, 'A', 'Approved', 'I', 'In Process', 'J', 'Rejected', 'R', 'Required', 'V','Validation Failed','Z', 'N/A',NULL ),
JOURNAL_BATCH1.CONTROL_TOTAL,
JOURNAL_BATCH1.RUNNING_TOTAL_DR,
JOURNAL_BATCH1.RUNNING_TOTAL_CR,
JOURNAL_BATCH1.RUNNING_TOTAL_ACCOUNTED_DR,
JOURNAL_BATCH1.RUNNING_TOTAL_ACCOUNTED_CR,
JOURNAL_BATCH1.PARENT_JE_BATCH_ID,
JOURNAL_BATCH2.NAME
FROM
GL_JE_BATCHES JOURNAL_BATCH1,
GL_JE_BATCHES JOURNAL_BATCH2,
GL_SETS_OF_BOOKS
GL_SET_OF_BOOKS
WHERE
JOURNAL_BATCH1.PARENT_JE_BATCH_ID = JOURNAL_BATCH2.JE_BATCH_ID (+) AND
JOURNAL_BATCH1.SET_OF_BOOKS_ID = GL_SET_OF_BOOKS.SET_OF_BOOKS_ID AND
GL_SECURITY_PKG.VALIDATE_ACCESS( JOURNAL_BATCH1.SET_OF_BOOKS_ID ) = 'TRUE' WITH READ ONLY
Thanks,
Lance

Discoverer created it's own SQL.
Please see below the SQL Inspector Plan:
Before Condition
SELECT STATEMENT
SORT GROUP BY
VIEW SYS
SORT GROUP BY
NESTED LOOPS OUTER
NESTED LOOPS OUTER
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS OUTER
NESTED LOOPS OUTER
NESTED LOOPS
NESTED LOOPS OUTER
NESTED LOOPS OUTER
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
TABLE ACCESS BY INDEX ROWID GL.GL_CODE_COMBINATIONS
AND-EQUAL
INDEX RANGE SCAN GL.GL_CODE_COMBINATIONS_N2
INDEX RANGE SCAN GL.GL_CODE_COMBINATIONS_N1
TABLE ACCESS BY INDEX ROWID APPLSYS.FND_FLEX_VALUES
INDEX RANGE SCAN APPLSYS.FND_FLEX_VALUES_N1
TABLE ACCESS BY INDEX ROWID APPLSYS.FND_FLEX_VALUE_SETS
INDEX UNIQUE SCAN APPLSYS.FND_FLEX_VALUE_SETS_U1
TABLE ACCESS BY INDEX ROWID APPLSYS.FND_FLEX_VALUES_TL
INDEX UNIQUE SCAN APPLSYS.FND_FLEX_VALUES_TL_U1
INDEX RANGE SCAN APPLSYS.FND_FLEX_VALUE_NORM_HIER_U1
TABLE ACCESS BY INDEX ROWID GL.GL_JE_LINES
INDEX RANGE SCAN GL.GL_JE_LINES_N1
INDEX UNIQUE SCAN GL.GL_JE_HEADERS_U1
INDEX UNIQUE SCAN GL.GL_SETS_OF_BOOKS_U2
TABLE ACCESS BY INDEX ROWID GL.GL_JE_HEADERS
INDEX UNIQUE SCAN GL.GL_JE_HEADERS_U1
INDEX UNIQUE SCAN GL.GL_DAILY_CONVERSION_TYPES_U1
TABLE ACCESS BY INDEX ROWID GL.GL_JE_SOURCES_TL
INDEX UNIQUE SCAN GL.GL_JE_SOURCES_TL_U1
INDEX UNIQUE SCAN GL.GL_JE_CATEGORIES_TL_U1
INDEX UNIQUE SCAN GL.GL_JE_HEADERS_U1
INDEX UNIQUE SCAN GL.GL_JE_HEADERS_U1
INDEX UNIQUE SCAN GL.GL_JE_BATCHES_U1
INDEX UNIQUE SCAN GL.GL_BUDGET_VERSIONS_U1
INDEX UNIQUE SCAN GL.GL_ENCUMBRANCE_TYPES_U1
INDEX UNIQUE SCAN GL.GL_SETS_OF_BOOKS_U2
TABLE ACCESS BY INDEX ROWID GL.GL_JE_BATCHES
INDEX UNIQUE SCAN GL.GL_JE_BATCHES_U1
INDEX UNIQUE SCAN GL.GL_SETS_OF_BOOKS_U2
INDEX UNIQUE SCAN GL.GL_JE_BATCHES_U1
TABLE ACCESS BY INDEX ROWID GL.GL_PERIODS
INDEX RANGE SCAN GL.GL_PERIODS_U1
After Condition
SELECT STATEMENT
SORT GROUP BY
VIEW SYS
SORT GROUP BY
NESTED LOOPS
NESTED LOOPS OUTER
NESTED LOOPS OUTER
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS OUTER
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS OUTER
NESTED LOOPS
NESTED LOOPS OUTER
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS OUTER
NESTED LOOPS
TABLE ACCESS FULL GL.GL_JE_BATCHES
INDEX UNIQUE SCAN GL.GL_SETS_OF_BOOKS_U2
INDEX UNIQUE SCAN GL.GL_JE_BATCHES_U1
TABLE ACCESS BY INDEX ROWID GL.GL_JE_HEADERS
INDEX RANGE SCAN GL.GL_JE_HEADERS_N1
INDEX UNIQUE SCAN GL.GL_SETS_OF_BOOKS_U2
INDEX UNIQUE SCAN GL.GL_ENCUMBRANCE_TYPES_U1
INDEX UNIQUE SCAN GL.GL_DAILY_CONVERSION_TYPES_U1
INDEX UNIQUE SCAN GL.GL_BUDGET_VERSIONS_U1
TABLE ACCESS BY INDEX ROWID GL.GL_JE_SOURCES_TL
INDEX UNIQUE SCAN GL.GL_JE_SOURCES_TL_U1
INDEX UNIQUE SCAN GL.GL_JE_CATEGORIES_TL_U1
INDEX UNIQUE SCAN GL.GL_JE_BATCHES_U1
TABLE ACCESS BY INDEX ROWID GL.GL_JE_LINES
INDEX RANGE SCAN GL.GL_JE_LINES_U1
INDEX UNIQUE SCAN GL.GL_SETS_OF_BOOKS_U2
TABLE ACCESS BY INDEX ROWID GL.GL_CODE_COMBINATIONS
INDEX UNIQUE SCAN GL.GL_CODE_COMBINATIONS_U1
TABLE ACCESS BY INDEX ROWID GL.GL_PERIODS
INDEX RANGE SCAN GL.GL_PERIODS_U1
TABLE ACCESS BY INDEX ROWID APPLSYS.FND_FLEX_VALUES
INDEX RANGE SCAN APPLSYS.FND_FLEX_VALUES_N1
INDEX RANGE SCAN APPLSYS.FND_FLEX_VALUE_NORM_HIER_U1
TABLE ACCESS BY INDEX ROWID APPLSYS.FND_FLEX_VALUES_TL
INDEX UNIQUE SCAN APPLSYS.FND_FLEX_VALUES_TL_U1
TABLE ACCESS BY INDEX ROWID APPLSYS.FND_FLEX_VALUE_SETS
INDEX UNIQUE SCAN APPLSYS.FND_FLEX_VALUE_SETS_U1
INDEX UNIQUE SCAN GL.GL_JE_HEADERS_U1
INDEX UNIQUE SCAN GL.GL_JE_HEADERS_U1
INDEX UNIQUE SCAN GL.GL_JE_HEADERS_U1
_________________________________

Serial table scan with direct path read compared to db file scattered read

Hi,
The environment
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit
8K block size
db_file_multiblock_read_count is 128
show sga
Total System Global Area 1.6702E+10 bytes
Fixed Size                  2219952 bytes
Variable Size            7918846032 bytes
Database Buffers         8724152320 bytes
Redo Buffers               57090048 bytes
16GB of SGA with 8GB of db buffer cache.
-- database is built on Solid State Disks
-- SQL trace and wait events
DBMS_MONITOR.SESSION_TRACE_ENABLE ( waits=>true )
-- The underlying table is called tdash. It has 1.7 Million rows based on data in all_objects. NO index
TABLE_NAME                             Rows Table Size/MB      Used/MB    Free/MB
TDASH                             1,729,204        15,242       15,186         56
TABLE_NAME                     Allocated blocks Empty blocks Average space/KB Free list blocks
TDASH                                 1,943,823        7,153              805                0
Objectives
To show that when serial scans are performed on database built on Solid State Disks (SSD) compared to Magnetic disks (HDD), the performance gain is far less compared to random reads with index scans on SSD compared to HDD
Approach
We want to read the first 100 rows of tdash table randomly into buffer, taking account of wait events and wait times generated. The idea is that on SSD the wait times will be better compared to HDD but not that much given the serial nature of table scans.
The code used
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'test_with_tdash_ssdtester_noindex';
DECLARE
        type array is table of tdash%ROWTYPE index by binary_integer;
        l_data array;
        l_rec tdash%rowtype;
BEGIN
        SELECT
                a.*
                ,RPAD('*',4000,'*') AS PADDING1
                ,RPAD('*',4000,'*') AS PADDING2
        BULK COLLECT INTO
        l_data
        FROM ALL_OBJECTS a;
        DBMS_MONITOR.SESSION_TRACE_ENABLE ( waits=>true );
        FOR rs IN 1 .. 100
        LOOP
                BEGIN
                        SELECT * INTO l_rec FROM tdash WHERE object_id = l_data(rs).object_id;
                EXCEPTION
                  WHEN NO_DATA_FOUND THEN NULL;
                END;
        END LOOP;
END;
/Server is rebooted prior to any tests
Whern run as default, the optimizer (although some attribute this to the execution engine) chooses direct path read into PGA in preference to db file scattered read.
With this choice it takes 6,520 seconds to complete the query. The results are shown below
SQL ID: 78kxqdhk1ubvq
Plan Hash: 1148949653
SELECT *
FROM
TDASH WHERE OBJECT_ID = :B1
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.01       0.00          2         47          0           0
Execute    100      0.00       0.00          1         51          0           0
Fetch      100     10.88    6519.89 194142802 194831012          0         100
total      201     10.90    6519.90 194142805 194831110          0         100
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 96 (SSDTESTER)   (recursive depth: 1)
Rows     Row Source Operation
      1 TABLE ACCESS FULL TDASH (cr=1948310 pr=1941430 pw=0 time=0 us cost=526908 size=8091 card=1)
Rows     Execution Plan
      0 SELECT STATEMENT   MODE: ALL_ROWS
      1   TABLE ACCESS   MODE: ANALYZED (FULL) OF 'TDASH' (TABLE)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
Disk file operations I/O                        3        0.00          0.00
db file sequential read                         2        0.00          0.00
direct path read                          1517504        0.05       6199.93
asynch descriptor resize                      196        0.00          0.00
DECLARE
        type array is table of tdash%ROWTYPE index by binary_integer;
        l_data array;
        l_rec tdash%rowtype;
BEGIN
        SELECT
                a.*
                ,RPAD('*',4000,'*') AS PADDING1
                ,RPAD('*',4000,'*') AS PADDING2
        BULK COLLECT INTO
        l_data
        FROM ALL_OBJECTS a;
        DBMS_MONITOR.SESSION_TRACE_ENABLE ( waits=>true );
        FOR rs IN 1 .. 100
        LOOP
                BEGIN
                        SELECT * INTO l_rec FROM tdash WHERE object_id = l_data(rs).object_id;
                EXCEPTION
                  WHEN NO_DATA_FOUND THEN NULL;
                END;
        END LOOP;
END;
call     count       cpu    elapsed       disk      query    current        rows
Parse        0      0.00       0.00          0          0          0           0
Execute      1      3.84       4.03        320      48666          0           1
Fetch        0      0.00       0.00          0          0          0           0
total        1      3.84       4.03        320      48666          0           1
Misses in library cache during parse: 0
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 96 (SSDTESTER)
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
SQL ID: 9babjv8yq8ru3
Plan Hash: 0
BEGIN DBMS_OUTPUT.GET_LINES(:LINES, :NUMLINES); END;
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           1
Fetch        0      0.00       0.00          0          0          0           0
total        2      0.00       0.00          0          0          0           1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 96 (SSDTESTER)
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
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      2      3.84       4.03        320      48666          0           2
Fetch        0      0.00       0.00          0          0          0           0
total        3      3.84       4.03        320      48666          0           2
Misses in library cache during parse: 0
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                       2        0.00          0.00
SQL*Net message from client                     2        0.00          0.00
log file sync                                   1        0.00          0.00
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        9      0.01       0.00          2         47          0           0
Execute    129      0.01       0.00          1         52          2           1
Fetch      140     10.88    6519.89 194142805 194831110          0         130
total      278     10.91    6519.91 194142808 194831209          2         131
Misses in library cache during parse: 9
Misses in library cache during execute: 8
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
db file sequential read                         5        0.00          0.00
Disk file operations I/O                        3        0.00          0.00
direct path read                          1517504        0.05       6199.93
asynch descriptor resize                      196        0.00          0.00
102 user SQL statements in session.
   29 internal SQL statements in session.
131 SQL statements in session.
    1 statement EXPLAINed in this session.
Trace file: mydb_ora_16394_test_with_tdash_ssdtester_noindex.trc
Trace file compatibility: 11.1.0.7
Sort options: default
       1 session in tracefile.
     102 user SQL statements in trace file.
      29 internal SQL statements in trace file.
     131 SQL statements in trace file.
      11 unique SQL statements in trace file.
       1 SQL statements EXPLAINed using schema:
           ssdtester.plan_table
             Schema was specified.
             Table was created.
             Table was dropped.
1531657 lines in trace file.
    6520 elapsed seconds in trace file.I then force the query not to use direct path read by invoking
ALTER SESSION SET EVENTS '10949 trace name context forever, level 1' -- No Direct path read ;In this case the optimizer uses db file scattered read predominantly and the query takes 4,299 seconds to finish which is around 34% faster than using direct path read (default).
The report is shown below
SQL ID: 78kxqdhk1ubvq
Plan Hash: 1148949653
SELECT *
FROM
TDASH WHERE OBJECT_ID = :B1
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          2         47          0           0
Execute    100      0.00       0.00          2         51          0           0
Fetch      100    143.44    4298.87 110348670 194490912          0         100
total      201    143.45    4298.88 110348674 194491010          0         100
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 96 (SSDTESTER)   (recursive depth: 1)
Rows     Row Source Operation
      1 TABLE ACCESS FULL TDASH (cr=1944909 pr=1941430 pw=0 time=0 us cost=526908 size=8091 card=1)
Rows     Execution Plan
      0 SELECT STATEMENT   MODE: ALL_ROWS
      1   TABLE ACCESS   MODE: ANALYZED (FULL) OF 'TDASH' (TABLE)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
Disk file operations I/O                        3        0.00          0.00
db file sequential read                    129759        0.01         17.50
db file scattered read                    1218651        0.05       3770.02
latch: object queue header operation            2        0.00          0.00
DECLARE
        type array is table of tdash%ROWTYPE index by binary_integer;
        l_data array;
        l_rec tdash%rowtype;
BEGIN
        SELECT
                a.*
                ,RPAD('*',4000,'*') AS PADDING1
                ,RPAD('*',4000,'*') AS PADDING2
        BULK COLLECT INTO
        l_data
        FROM ALL_OBJECTS a;
        DBMS_MONITOR.SESSION_TRACE_ENABLE ( waits=>true );
        FOR rs IN 1 .. 100
        LOOP
                BEGIN
                        SELECT * INTO l_rec FROM tdash WHERE object_id = l_data(rs).object_id;
                EXCEPTION
                  WHEN NO_DATA_FOUND THEN NULL;
                END;
        END LOOP;
END;
call     count       cpu    elapsed       disk      query    current        rows
Parse        0      0.00       0.00          0          0          0           0
Execute      1      3.92       4.07        319      48625          0           1
Fetch        0      0.00       0.00          0          0          0           0
total        1      3.92       4.07        319      48625          0           1
Misses in library cache during parse: 0
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 96 (SSDTESTER)
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
SQL ID: 9babjv8yq8ru3
Plan Hash: 0
BEGIN DBMS_OUTPUT.GET_LINES(:LINES, :NUMLINES); END;
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           1
Fetch        0      0.00       0.00          0          0          0           0
total        2      0.00       0.00          0          0          0           1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 96 (SSDTESTER)
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
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      2      3.92       4.07        319      48625          0           2
Fetch        0      0.00       0.00          0          0          0           0
total        3      3.92       4.07        319      48625          0           2
Misses in library cache during parse: 0
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                       2        0.00          0.00
SQL*Net message from client                     2        0.00          0.00
log file sync                                   1        0.00          0.00
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        9      0.01       0.00          2         47          0           0
Execute    129      0.00       0.00          2         52          2           1
Fetch      140    143.44    4298.87 110348674 194491010          0         130
total      278    143.46    4298.88 110348678 194491109          2         131
Misses in library cache during parse: 9
Misses in library cache during execute: 8
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
db file sequential read                    129763        0.01         17.50
Disk file operations I/O                        3        0.00          0.00
db file scattered read                    1218651        0.05       3770.02
latch: object queue header operation            2        0.00          0.00
102 user SQL statements in session.
   29 internal SQL statements in session.
131 SQL statements in session.
    1 statement EXPLAINed in this session.
Trace file: mydb_ora_26796_test_with_tdash_ssdtester_noindex_NDPR.trc
Trace file compatibility: 11.1.0.7
Sort options: default
       1 session in tracefile.
     102 user SQL statements in trace file.
      29 internal SQL statements in trace file.
     131 SQL statements in trace file.
      11 unique SQL statements in trace file.
       1 SQL statements EXPLAINed using schema:
           ssdtester.plan_table
             Schema was specified.
             Table was created.
             Table was dropped.
1357958 lines in trace file.
    4299 elapsed seconds in trace file.I note that there are 1,517,504 waits with direct path read with total time of nearly 6,200 seconds. In comparison with no direct path read, there are 1,218,651 db file scattered read waits with total wait time of 3,770 seconds. My understanding is that direct path read can use single or multi-block read into the PGA. However db file scattered reads do multi-block read into multiple discontinuous SGA buffers. So it is possible given the higher number of direct path waits that the optimizer cannot do multi-block reads (contigious buffers within PGA) and hence has to revert to single blocks reads which results in more calls and more waits?.
Appreciate any advise and apologies for being long winded.
Thanks,
Mich

Hi Charles,
I am doing your tests for t1 table using my server.
Just to clarify my environment is:
I did the whole of this test on my server. My server has I7-980 HEX core processor with 24GB of RAM and 1 TB of HDD SATA II for test/scratch backup and archive. The operating system is RHES 5.2 64-bit installed on a 120GB OCZ Vertex 3 Series SATA III 2.5-inch Solid State Drive.
Oracle version installed was 11g Enterprise Edition Release 11.2.0.1.0 -64bit. The binaries were created on HDD. Oracle itself was configured with 16GB of SGA, of which 7.5GB was allocated to Variable Size and 8GB to Database Buffers.
For Oracle tablespaces including SYS, SYSTEM, SYSAUX, TEMPORARY, UNDO and redo logs, I used file systems on 240GB OCZ Vertex 3 Series SATA III 2.5-inch Solid State Drive. With 4K Random Read at 53,500 IOPS and 4K Random Write at 56,000 IOPS (manufacturer’s figures), this drive is probably one of the fastest commodity SSDs using NAND flash memory with Multi-Level Cell (MLC). Now my T1 table created as per your script and has the following rows and blocks (8k block size)
SELECT
NUM_ROWS,
BLOCKS
FROM
USER_TABLES
WHERE
TABLE_NAME='T1';
NUM_ROWS     BLOCKS
12000000     178952which is pretty identical to yours.
Then I run the query as brelow
set timing on
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'test_bed_T1';
ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT FOREVER, LEVEL 8';
SELECT
        COUNT(*)
FROM
        T1
WHERE
        RN=1;
which gives
COUNT(*)
     60000
Elapsed: 00:00:05.29
tkprof output shows
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.02       5.28     178292     178299          0           1
total        4      0.02       5.28     178292     178299          0           1
Compared to yours:
Fetch        2      0.60       4.10     178493     178498          0           1
It appears to me that my CPU utilisation is by order of magnitude better but my elapsed time is worse!
Now the way I see it elapsed time = CPU time + wait time. Further down I have
Rows     Row Source Operation
      1 SORT AGGREGATE (cr=178299 pr=178292 pw=0 time=0 us)
60000   TABLE ACCESS FULL T1 (cr=178299 pr=178292 pw=0 time=42216 us cost=48697 size=240000 card=60000)
Rows     Execution Plan
      0 SELECT STATEMENT   MODE: ALL_ROWS
      1   SORT (AGGREGATE)
60000    TABLE ACCESS   MODE: ANALYZED (FULL) OF 'T1' (TABLE)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
SQL*Net message to client                       3        0.00          0.00
SQL*Net message from client                     3        0.00          0.00
Disk file operations I/O                        3        0.00          0.00
direct path read                             1405        0.00          4.68
Your direct path reads are
direct path read                             1404        0.01          3.40Which indicates to me you have faster disks compared to mine, whereas it sounds like my CPU is faster than yours.
With db file scattered read I get
Elapsed: 00:00:06.95
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      1.22       6.93     178293     178315          0           1
total        4      1.22       6.94     178293     178315          0           1
Rows     Row Source Operation
      1 SORT AGGREGATE (cr=178315 pr=178293 pw=0 time=0 us)
60000   TABLE ACCESS FULL T1 (cr=178315 pr=178293 pw=0 time=41832 us cost=48697 size=240000 card=60000)
Rows     Execution Plan
      0 SELECT STATEMENT   MODE: ALL_ROWS
      1   SORT (AGGREGATE)
60000    TABLE ACCESS   MODE: ANALYZED (FULL) OF 'T1' (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
Disk file operations I/O                        3        0.00          0.00
db file sequential read                         1        0.00          0.00
db file scattered read                       1414        0.00          5.36
SQL*Net message from client                     2        0.00          0.00
compared to your
db file scattered read                       1415        0.00          4.16On the face of it with this test mine shows 21% improvement with direct path read compared to db scattered file read. So now I can go back to re-visit my original test results:
First default with direct path read
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.01       0.00          2         47          0           0
Execute    100      0.00       0.00          1         51          0           0
Fetch      100     10.88    6519.89 194142802 194831012          0         100
total      201     10.90    6519.90 194142805 194831110          0         100
CPU ~ 11 sec, elapsed ~ 6520 sec
wait stats
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
direct path read                          1517504        0.05       6199.93
roughly 0.004 sec for each I/ONow with db scattered file read I get
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          2         47          0           0
Execute    100      0.00       0.00          2         51          0           0
Fetch      100    143.44    4298.87 110348670 194490912          0         100
total      201    143.45    4298.88 110348674 194491010          0         100
CPU ~ 143 sec, elapsed ~ 4299 sec
and waits:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
db file sequential read                    129759        0.01         17.50
db file scattered read                    1218651        0.05       3770.02
roughly 17.5/129759 = .00013 sec for single block I/O and 3770.02/1218651 = .0030 for multi-block I/ONow my theory is that the improvements comes from the large buffer cache (8320MB) inducing it to do some read aheads (async pre-fetch). Read aheads are like quasi logical I/Os and they will be cheaper compared to physical I/O. When there is large buffer cache and read aheads can be done then using buffer cache is a better choice than PGA?
Regards,
Mich

Issue with index on table

Hi,
We have created an index(assume z2) on table CATSDB with 2 fields. There is an other index(Z1 assume) with the same fields and the order is also same. When a report accesing the table it is taking more time to run when index Z2 is on table. But when deleted then the report ran quickly. Is it with the duplicate index created???
Please let me know
Regards
Shiva

Hi
i am giving total index and buffering concept details by seeing this you can understand how we can achive performance through these
reward if usefull
Performance during table access
Indexes
Primary and secondary indexes
Structure of an index
Accessing tables using indexes
Table buffering
Advantages of buffering
Concept of buffering
Buffering types
Buffer synchronization
Primary and secondary indexes
Index: Technical key of a database table.
Primary index: The primary index contains the key fields of the table and a pointer to the non-key fields of the table. The primary index is created automatically when the table is created in the database.
Secondary index: Additional indexes could be created considering the most frequently accessed dimensions of the table.
Structure of an Index
An index can be used to speed up the selection of data records from a table.
An index can be considered to be a copy of a database table reduced to certain fields. The data is stored in sorted form in this copy. This sorting permits fast access to the records of the table (for example using a binary search). Not all of the fields of the table are contained in the index. The index also contains a pointer from the index entry to the corresponding table entry to permit all the field contents to be read.
When creating indexes, please note that:
An index can only be used up to the last specified field in the selection! The fields which are specified in the WHERE clause for a large number of selections should be in the first position.
Only those fields whose values significantly restrict the amount of data are meaningful in an index.
When you change a data record of a table, you must adjust the index sorting. Tables whose contents are frequently changed therefore should not have too many indexes.
Make sure that the indexes on a table are as disjunctive as possible.
(That is they should contain as few fields in common as possible. If two indexes on a table have a large number of common fields, this could make it more difficult for the optimizer to choose the most selective index.)
Accessing tables using Indexes
The database optimizer decides which index on the table should be used by the database to access data records.
You must distinguish between the primary index and secondary indexes of a table. The primary index contains the key fields of the table. The primary index is automatically created in the database when the table is activated. If a large table is frequently accessed such that it is not possible to apply primary index sorting, you should create secondary indexes for the table.
The indexes on a table have a three-character index ID. '0' is reserved for the primary index. Customers can create their own indexes on SAP tables; their IDs must begin with Y or Z.
If the index fields have key function, i.e. they already uniquely identify each record of the table, an index can be called a unique index. This ensures that there are no duplicate index fields in the database.
When you define a secondary index in the ABAP Dictionary, you can specify whether it should be created on the database when it is activated. Some indexes only result in a gain in performance for certain database systems. You can therefore specify a list of database systems when you define an index. The index is then only created on the specified database systems when activated
Database access using Buffer concept
Buffering allows you to access data quicker by letting you
access it from the application server instead of the database.
Advantages of buffering
Table buffering increases the performance when the records of the table are read.
As records of a buffered table are read directly from the local buffer of the application server on which the accessing transaction is running, time required to access data is greatly reduced. The access improves by a factor of 10 to 100 depending on the structure of the table and on the exact system configuration.
If the storage requirements in the buffer increase due to further data, the data that has not been accessed for the longest time is displaced. This displacement takes place asynchronously at certain times which are defined dynamically based on the buffer accesses. Data is only displaced if the free space in the buffer is less than a predefined value or the quality of the access is not satisfactory at this time.
Entering $TAB in the command field resets the table buffers on the corresponding application server. Only use this command if there are inconsistencies in the buffer. In large systems, it can take several hours to fill the buffers. The performance is considerably reduced during this time.
Concept of buffering
The R/3 System manages and synchronizes the buffers on the individual application servers. If an application program accesses data of a table, the database interfaces determines whether this data lies in the buffer of the application server. If this is the case, the data is read directly from the buffer. If the data is not in the buffer of the application server, it is read from the database and loaded into the buffer. The buffer can therefore satisfy the next access to this data.
The buffering type determines which records of the table are loaded into the buffer of the application server when a record of the table is accessed. There are three different buffering types.
With full buffering, all the table records are loaded into the buffer when one record of the table is accessed.
With generic buffering, all the records whose left-justified part of the key is the same are loaded into the buffer when a table record is accessed.
With single-record buffering, only the record that was accessed is loaded into the buffer.
Buffering types
With full buffering, the table is either completely or not at all in the buffer. When a record of the table is accessed, all the records of the table are loaded into the buffer.
When you decide whether a table should be fully buffered, you must take the table size, the number of read accesses and the number of write accesses into consideration. The smaller the table is, the more frequently it is read and the less frequently it is written, the better it is to fully buffer the table.
Full buffering is also advisable for tables having frequent accesses to records that do not exist. Since all the records of the table reside in the buffer, it is already clear in the buffer whether or not a record exists.
The data records are stored in the buffer sorted by table key. When you access the data with SELECT, only fields up to the last specified key field can be used for the access. The left-justified part of the key should therefore be as large as possible for such accesses. For example, if the first key field is not defined, the entire table is scanned in the buffer. Under these circumstances, a direct access to the database could be more efficient if there is a suitable secondary index there.
With generic buffering, all the records whose generic key fields agree with this record are loaded into the buffer when one record of the table is accessed. The generic key is a left-justified part of the primary key of the table that must be defined when the buffering type is selected. The generic key should be selected so that the generic areas are not too small, which would result in too many generic areas. If there are only a few records for each generic area, full buffering is usually preferable for the table. If you choose too large a generic key, too much data will be invalidated if there are changes to table entries, which would have a negative effect on the performance.
A table should be generically buffered if only certain generic areas of the table are usually needed for processing.
Client-dependent, fully buffered tables are automatically generically buffered. The client field is the generic key. It is assumed that not all of the clients are being processed at the same time on one application server. Language-dependent tables are a further example of generic buffering. The generic key includes all the key fields up to and including the language field.
The generic areas are managed in the buffer as independent objects. The generic areas are managed analogously to fully buffered tables. You should therefore also read the information about full buffering.
Single-record buffering is recommended particularly for large tables in which only a few records are accessed repeatedly with SELECT SINGLE. All the accesses to the table that do not use SELECT SINGLE bypass the buffer and directly access the database.
If you access a record that was not yet buffered using SELECT SINGLE, there is a database access to load the record. If the table does not contain a record with the specified key, this record is recorded in the buffer as non-existent. This prevents a further database access if you make another access with the same key
You only need one database access to load a table with full buffering, but you need several database accesses with single-record buffering. Full buffering is therefore generally preferable for small tables that are frequently accessed.
Synchronizing local buffers
The table buffers reside locally on each application server in the system. However, this makes it necessary for the buffer administration to transfer all changes made to buffered objects to all the application servers of the system.
If a buffered table is modified, it is updated synchronously in the buffer of the application server from which the change was made. The buffers of the whole network, that is, the buffers of all the other application servers, are synchronized with an asynchronous procedure.
Entries are written in a central database table (DDLOG) after each table modification that could be buffered. Each application server reads these entries at fixed time intervals.
If entries are found that show a change to the data buffered by this server, this data is invalidated. If this data is accessed again, it is read directly from the database. In such an access, the table can then be loaded to the buffer again.

Query on a table with indexed date field

I have a table with a date column which is indexed. If I run a query like "select column1 where date_field='20-JAN-04' for example it is fast and uses index.
If I run select column1 where date < '20-JAN-04' it is slow and doesnt use the index. I logged a TAR and Oracle told me that this is to be expected as not using the index in this case is the most effiecient way of doing the query.
Now my concept of an index is like the index of Yellow Pages(telephone directory) for example. In this example if I look for a name that is say "Halfords" or below, I can see all entries for Halfords and all the way to ZZZ in one block.
I just cant see , in a common sense way why Oracle wont use the index in this type of query.
George

Using the concept of a telephone directory is wrong. In a telephone directory you have all information order by the name. However in your table (if it is not an IOT) you don't have all information/rows ordered by your date_field. Rather think at the document "Oracle9i Database Concepts" and it's index.
Let's say you want to find all indexed words larger then "ISO SQL standard" (ok that doesn't make sense but it is just an example). So would it be faster to read the whole document or to lookup each word in the index and then read the entire page (Oracle block) to find the word.
It's not allways easy to know in advance if the query will be faster over the index or a full table scan. what you need to do is to well analyze (dbms_stats) the table and it's index, in most cases Oracle chooses the right way. You may also use the hint /*+ index(table_name index_name) */ and will see if it would be faster over the index or not.
A good document about that subject is:
http://www.ioug.org/tech/IOUGinDefense.pdf
HTH
Maurice

Why it is taking full table scan when index is available

Hi all,
I am facing a strange problem with index.
I created index on a column like
1. CREATE INDEX ASSETS_ARTIST_IDX2 ON ASSETS(artist).
SELECT asset.artist AS NAME FROM ASSETS asset WHERE asset.artist LIKE 'J%'
Explain Plan : INDEX RANGE SCAN
2. CREATE INDEX ASSETS_ARTIST_IDX2 ON ASSETS(UPPER (TRANSLATE (artist, ',;:"', ' ')));
SELECT asset.artist AS NAME FROM ASSETS asset WHERE UPPER (TRANSLATE (artist, ',;:"', ' ')) LIKE 'J%'
          Explain Plan : TABLE ACCESS FULL
first time it is taking index range scan,but in second situation scaning full table.Please let me know how to avoid the full table scan.
Regards,
Rajasekhar

Actually, I misseunderstood damorgan' s statement about NULL and OP did not provide table definition. So based on FTS I would say it is more likely column is NULLable, otherwise I would expect INDEX FAST SCAN:
SQL> create table emp1 as select * from emp
2 /
Table created.
SQL> create index emp1_idx1 on emp1(empno)
2 /
Index created.
SQL> exec dbms_stats.gather_table_stats('SCOTT','EMP1');
PL/SQL procedure successfully completed.
SQL> desc emp1
Name                                                                     Null?    Type
EMPNO                                                                             NUMBER(4)
ENAME                                                                             VARCHAR2(10)
JOB                                                                               VARCHAR2(9)
MGR                                                                               NUMBER(4)
HIREDATE                                                                          DATE
SAL                                                                               NUMBER(7,2)
COMM                                                                              NUMBER(7,2)
DEPTNO                                                                            NUMBER(2)
SQL> explain plan for
2 select empno
3 from emp1 where UPPER(TRANSLATE(empno, ',;:"', ' ')) LIKE '7%'
4 /
Explained.
SQL> @?\rdbms\admin\utlxpls
PLAN_TABLE_OUTPUT
Plan hash value: 2226897347
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      |     1 |     4 |     3   (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| EMP1 |     1 |     4 |     3   (0)| 00:00:01 |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
   1 - filter(UPPER(TRANSLATE(TO_CHAR("EMPNO"),',;:"',' ')) LIKE '7%')
13 rows selected.
SQL> alter table emp1 modify empno not null
2 /
Table altered.
SQL> explain plan for
2 select empno
3 from emp1 where UPPER(TRANSLATE(empno, ',;:"', ' ')) LIKE '7%'
4 /
Explained.
SQL> @?\rdbms\admin\utlxpls
PLAN_TABLE_OUTPUT
Plan hash value: 2850860361
| Id | Operation        | Name      | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |           |     1 |     4 |     1   (0)| 00:00:01 |
|* 1 | INDEX FULL SCAN | EMP1_IDX1 |     1 |     4 |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
   1 - filter(UPPER(TRANSLATE(TO_CHAR("EMPNO"),',;:"',' ')) LIKE '7%')
13 rows selected.
SQL> SY.

Table scan even with index

Similar Messages

Maybe you are looking for