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
_________________________________

Similar Messages

Star Query Full Table Scan

Hi, Folks:
I have a complex SQL statement that runs very slowly.
Following is the statement:
SELECT
T3.POSITION_ID,
T12.PR_POSTN_ID,
T12.PR_TERR_ID,
T12.PR_REP_MANL_FLG,
T9.CREATED,
T10.PR_EMP_ID,
T9.MODIFICATION_NUM,
T12.DEDUP_TOKEN,
T12.LOCATION_LEVEL,
T12.PR_PRTNR_OU_ID,
T12.PR_OU_TYPE_ID,
T12.PAR_DUNS_NUM,
T3.ACCNT_NAME,
T11.ATTRIB_16,
T6.PAR_ROW_ID,
T3.INVSTR_FLG,
T6.ROW_ID,
T12.DUNS_NUM,
T12.BU_ID,
T10.ROW_ID,
T2.LAST_NAME,
T3.SRV_PROVDR_FLG,
T12.X_PR_MERCH_NBR_ID,
T3.ROW_STATUS,
T12.NAME,
T11.PAR_ROW_ID,
T6.LAST_UPD_BY,
T6.MODIFICATION_NUM,
T3.PRIORITY_FLG,
T10.NAME,
T3.ASGN_SYS_FLG,
T9.PROFIT,
T12.PR_BL_ADDR_ID,
T12.PR_REP_ASGN_TYPE,
T9.LAST_UPD_BY,
T3.FACILITY_FLG,
T12.LAST_UPD_BY,
T12.PR_SHIP_ADDR_ID,
T11.MODIFICATION_NUM,
T11.LAST_UPD_BY,
T5.LOGIN,
T3.ASGN_MANL_FLG
FROM
S_ADDR_ORG T1,
S_CONTACT T2,
S_ACCNT_POSTN T3,
S_ORG_INT T4,
S_EMPLOYEE T5,
S_ORG_EXT_FNX T6,
S_ORG_SYN T7,
S_INDUST T8,
S_ORG_EXT_T T9,
S_POSTN T10,
S_ORG_EXT_X T11,
S_ORG_EXT T12
WHERE
T12.BU_ID = T4.ROW_ID (+) AND
T12.PR_CON_ID = T2.ROW_ID (+) AND
T12.ROW_ID = T7.OU_ID AND
T12.ROW_ID = T11.PAR_ROW_ID (+) AND
T12.ROW_ID = T6.PAR_ROW_ID (+) AND
T12.ROW_ID = T9.PAR_ROW_ID (+) AND
T12.PR_INDUST_ID = T8.ROW_ID (+) AND
T12.PR_ADDR_ID = T1.ROW_ID (+) AND
T12.PR_POSTN_ID = T10.ROW_ID AND
T12.PR_POSTN_ID = T3.POSITION_ID AND
T12.ROW_ID = T3.OU_EXT_ID AND
T10.PR_EMP_ID = T5.ROW_ID (+) AND
(T12.X_BMO_CUST_FLG = 'Y') AND
(T7.NAME IS NULL );
***** SQL Statement Execute Time: 31.703 seconds *****
I do a explain plan and found the table S_ORG_EXT (T12)
get a full table scan.
But I found the table S_ORG_EXT did have lots of indexes
build on each column shown in the where statement.
Our database use RULE base optimizer and it should use
index instead of full table scan.
Then, I look at this SQL and realize it is a star query.
One more thing is that the table S_ORG_SYN (T7) defined
the column NAME as NOT NULL. If the query process, it
should return no row.
But I still don't know for what reason the Oracle use
full table scan and ignore the S_ORG_SYN.NAME should be
NOT NULL
If I want to avoid the full table scan, how can I do by
not switching to COST base optimizer mode ?
Thanks,
Ke

Michael:
A nice explanantion. In my experience, in versions up to 8.1.7, the RBO seems to be faster in the large majority of queries than the CBO. In our payroll application (version 8.0.5), removing statistics cut the time for the calculation run from 6.5 hours to under 2.
The CBO seems to be significantly faster in 9i. We only have one application currently running in a 9.0.1 database. In this app, a large stored procedure took about 2 minutes to run when there were no statistics, and about 10 seconds after we analyzed the tables.
As more of our vendors migrate to 9 (we just got the last vendor migrated off 7.3 to 8.0.6 a couple of months ago), I may become a bigger fan of the CBO. John,
I remember having a discussion with you about the CBO in a thread once and am aware of your opinion of the CBO. My opinion has been test which works for you RBO or CBO - in our case we verified that CBO worked better for us. Anyway, I was searching metalink and it looks like you'll be forced to become a "bigger fan" of the CBO after 9i release 2. This is from part of Doc ID 189702.1 on metalink:
The rule-based optimizer (RBO) will be no longer be a valid optimization choice when Oracle9i is de-supported. The release after Oracle9i
(referred to in this article as Oracle10i) will only support the cost-based optimizer (CBO). Hence Oracle9i Release 2 is the last releases to
contain the RBO. Partners and customers should certify their applications with the CBO before that time.
...but of course Oracle has been warning people of the demise of the RBO for some time.
Al

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.

Why full index scan is faster than full table scan?

Hi friends,
In the where clause of a query,if we give a column that contains index on it,then oracle uses index to search data rather than a TABLE ACCESS FULL Operation.
Why index searching is faster?

Sometimes it is faster to use index and sometimes it is faster to use full table scan. If your statistics are up to date Oracle is far more likely to get it right. If the query can be satisfied entirely from the index, then an index scan will almost always be faster as there are fewer blocks to read in the index than there would be if the table itself were scanned. However if the query must extract data from the table when that data is not in te index, then the index scan will be faster only if a small percentage of the rows are to be returned. Consiter the case of an index where 40% of the rows are returned. Assume the index values are distributed evenly among the data blocks. Assume 10 rows will fit in each data block thus 4 of the 10 rows will match the condition. Then the average datablock will be fetched 4 times since most of the time adjacent index entries will not be in the same block. The number of single datablock fetches will be about 4 times the number of datablocks. Compare this to a full table scan that does multiblock reads. Far fewer reads are required to read the entire table. Though it depends on the number of rows per block, a general rule is any query returning more than about 10% of a table is faster NOT using an index.

Source(oracle 11g) with oracle 8i using db link with full table scan

Hi,
I'm using oracle 8i version and i'm facing some issue while using DBlinks.
SourceDB1 I'm using oracle 8i(Source)
select * from tab1
tabl where id in
(select id from stab1@SourceDB1 where updt_seq_num > 167720 and work_grp_id in (2900,2901))
For this, I could able to retrive the data.
but, today we have migrated one of our source from oracle 8i to oracle 11G
when I'm executing
select * from tab2
tabl where id in
(select id from stab2@SourceDB2 where updt_seq_num > 167720 and work_grp_id in (2900,2901))
we couldn't able to retrive data as it's scaning full table scan.
when oracle 8i source it's scanning using INDEX scan but if the source oracle 11 h it's scanning full table scan.
Could you please advise how to resolve this issue for source oracle 11i ?
Please let us know, if you need any information.

Blocks that are read via full table scans are stored in the buffer cache, but putting them at the MRU end ensures that they don't push the rest of the useful blocks out of the buffer cache. In your example, if you're full scanning a 2 GB table (T) with a 500 MB buffer cache, the first block that is read from T is put at the MRU end of the buffer cache, displacing the previous block that was at the MRU end of the cache. The next block that is read from T is also put at the MRU end of the buffer cache, displacing the previous block that was at the MRU end of the cache, so block #2 from T displaces block #1 from T. So, you're reading 2 GB of data, but you're constantly purging the older blocks, so you're only really using that last block of the buffer cache.
Justin

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

Entity Framework Generated SQL for paging or using Linq skip take causes full table scans.

The slq genreated creates queries that cause a full table scan for pagination. Is there any way to fix this?
I am using
ODP.NET ODTwithODAC1120320_32bit
ASP.NET 4.5
EF 5
Oracle 11gR2
This table has 2 million records. The further into the records you page the longer it takes.
LINQ
var cnt = (from errorLog in ctx.ERRORLOGANDSERVICELOG_VIEW
                    select errorLog).Count();
                var query = (from errorLog in ctx.ERRORLOGANDSERVICELOG_VIEW
                             orderby errorLog.ERR_LOG_ID
                             select errorLog).Skip(cnt-10).Take(10).ToList();
Here is the query & execution plans.
SELECT *
FROM   (SELECT "Extent1"."ERR_LOG_ID" AS "ERR_LOG_ID",
               "Extent1"."SRV_LOG_ID" AS "SRV_LOG_ID",
               "Extent1"."TS"          AS "TS",
               "Extent1"."MSG"         AS "MSG",
               "Extent1"."STACK_TRACE" AS "STACK_TRACE",
               "Extent1"."MTD_NM"      AS "MTD_NM",
               "Extent1"."PRM"         AS "PRM",
               "Extent1"."INSN_ID"     AS "INSN_ID",
               "Extent1"."TS_1"        AS "TS_1",
               "Extent1"."LOG_ETRY"    AS "LOG_ETRY"
        FROM   (SELECT "Extent1"."ERR_LOG_ID"                                  AS "ERR_LOG_ID",
                       "Extent1"."SRV_LOG_ID"                                  AS "SRV_LOG_ID",
                       "Extent1"."TS"                                          AS "TS",
                       "Extent1"."MSG"                                         AS "MSG",
                       "Extent1"."STACK_TRACE"                                 AS "STACK_TRACE",
                       "Extent1"."MTD_NM"                                      AS "MTD_NM",
                       "Extent1"."PRM"                                         AS "PRM",
                       "Extent1"."INSN_ID"                                     AS "INSN_ID",
                       "Extent1"."TS_1"                                        AS "TS_1",
                       "Extent1"."LOG_ETRY"                                    AS "LOG_ETRY",
                       row_number() OVER (ORDER BY "Extent1"."ERR_LOG_ID" ASC) AS "row_number"
                FROM   (SELECT "ERRORLOGANDSERVICELOG_VIEW"."ERR_LOG_ID" AS "ERR_LOG_ID",
                               "ERRORLOGANDSERVICELOG_VIEW"."SRV_LOG_ID" AS "SRV_LOG_ID",
                               "ERRORLOGANDSERVICELOG_VIEW"."TS"          AS "TS",
                               "ERRORLOGANDSERVICELOG_VIEW"."MSG"         AS "MSG",
                               "ERRORLOGANDSERVICELOG_VIEW"."STACK_TRACE" AS "STACK_TRACE",
                               "ERRORLOGANDSERVICELOG_VIEW"."MTD_NM"      AS "MTD_NM",
                               "ERRORLOGANDSERVICELOG_VIEW"."PRM"         AS "PRM",
                               "ERRORLOGANDSERVICELOG_VIEW"."INSN_ID"     AS "INSN_ID",
                               "ERRORLOGANDSERVICELOG_VIEW"."TS_1"        AS "TS_1",
                               "ERRORLOGANDSERVICELOG_VIEW"."LOG_ETRY"    AS "LOG_ETRY"
                        FROM   "IDS_CORE"."ERRORLOGANDSERVICELOG_VIEW" "ERRORLOGANDSERVICELOG_VIEW") "Extent1") "Extent1"
        WHERE ("Extent1"."row_number" > 1933849)
        ORDER BY "Extent1"."ERR_LOG_ID" ASC)
WHERE (ROWNUM <= (10))
| Id | Operation              | Name                   | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT       |                        |    10 | 31750 |       |   821K (1)| 02:44:15 |
|* 1 | COUNT STOPKEY         |                        |       |       |       |            |          |
|   2 |   VIEW                 |                        | 1561K| 4728M|       |   821K (1)| 02:44:15 |
|* 3 |    VIEW                |                        | 1561K| 4748M|       |   821K (1)| 02:44:15 |
|   4 |     WINDOW SORT        |                        | 1561K| 3154M| 4066M|   821K (1)| 02:44:15 |
|* 5 |      HASH JOIN OUTER   |                        | 1561K| 3154M|       |   130K (1)| 00:26:09 |
|   6 |       TABLE ACCESS FULL| IDS_SERVICES_LOG       | 1047 | 52350 |       |     5   (0)| 00:00:01 |
|   7 |       TABLE ACCESS FULL| IDS_SERVICES_ERROR_LOG | 1561K| 3080M|       |   130K (1)| 00:26:08 |
Predicate Information (identified by operation id):
   1 - filter(ROWNUM<=10)
   3 - filter("Extent1"."row_number">1933849)
   5 - access("T1"."SRV_LOG_ID"(+)="T2"."SRV_LOG_ID")

I did try a sample from stack overflow that would apply it to all string types, but I didn't see any query results differences. Please note, I am having the problem without any order with or where statements. Of course the skip take generates them. Please advise how I would implement the EntityFunctions.AsNonUnicode method with this Linq query.
LINQ
var cnt = (from errorLog in ctx.ERRORLOGANDSERVICELOG_VIEW
                    select errorLog).Count();
                var query = (from errorLog in ctx.ERRORLOGANDSERVICELOG_VIEW
                             orderby errorLog.ERR_LOG_ID
                             select errorLog).Skip(cnt-10).Take(10).ToList();
This is what I inserted into my model to hopefully fix it. FROM:c# - EF Code First - Globally set varchar mapping over nvarchar - Stack Overflow
/// <summary>
/// Change the "default" of all string properties for a given entity to varchar instead of nvarchar.
/// </summary>
/// <param name="modelBuilder"></param>
/// <param name="entityType"></param>
protected void SetAllStringPropertiesAsNonUnicode(
   DbModelBuilder modelBuilder,
   Type entityType)
   var stringProperties = entityType.GetProperties().Where(
c => c.PropertyType == typeof(string)
   && c.PropertyType.IsPublic
   && c.

Find out the SQLs which are using a full table scan

Hello all , how can i to find out the queries which are using a full table scan ? Any idea ?

In general, though, why would you want to tune SQL statements that aren't causing problems? Statspack will tell you what the most resource-intensive SQL statements on your system are. A SQL*Net trace of sessions that are performing poorly will indicate which statements are the most resource-intensive for that session. If a statement is incorrectly doing a full-table scan, but it is not causing a problem, why spend time tuning it? If you're not focusing your tuning attention on identifying statements that are causing problems, you'll also miss out on 90% of tuning opportunities which involve rewriting (or eliminating) code to make it more efficient. I can simulate a join on two tables with nested cursor loops, which won't generate a single full table scan, but replacing that code with a real join, while it will cause at least one full table scan, will be orders of magnitude faster.
As an aside, full table scans aren't necessarily a bad thing. If a statement needs to retrieve more than a couple percent of the rows of a table, full table scans are the most efficient way to go.
Justin
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC

How to check small table scan full table scan if we will use index in where clause.

How to check small table scan full table scan if i will use index column in where clause.
Is there example link there i can test small table scan full table if index is used in where clause.

Use explain plan on your statement or set autotrace traceonly in your SQL*Plus session followed by the SQL you are testing.
For example
SQL> set autotrace traceonly
SQL> select *
2 from XXX
3 where id='fga';
no rows selected
Execution Plan
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=13 Card=1 Bytes=16
          5)
   1    0   PARTITION RANGE (ALL) (Cost=13 Card=1 Bytes=165)
   2    1     TABLE ACCESS (FULL) OF 'XXX' (TABLE) (Cost=13 Card
          =1 Bytes=165)
Statistics
          1 recursive calls
          0 db block gets
       1561 consistent gets
        540 physical reads
          0 redo size
       1864 bytes sent via SQL*Net to client
        333 bytes received via SQL*Net from client
          1 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          0 rows processed

How to force an MV to go through a FULL TABLE SCAN...

Hi all,
I'm trying to put a HINT in to this query to have the table MV_CLNT_SCDIM_MRGE go through a full table scan. However, for some reason, the view specification I'm using doesn't seem to work. Can anyone tell me what I should be doing to force the full table scan?
SELECT
DISTINCT 1 "c1",
t1."CALNDR_DT" "c2",
t2."OFFR_CD_ID" "c3",
t2."OFFR_COMM_CHNL_DESC" "c4",
t3."TCLNT_DIM_AGE_BASED_SGMNT_CD" "c5",
t3."TCLT_DM_CURR_CLNT_BUS_SGMNT_CD" "c6",
t2."OFFR_NM" "c7",
t2."CMPGN_NM" "c8",
t3."TCLNT_DIM_CLNT_DIM_KEY" "c9",
To_number(To_char(t1."CALNDR_DT", 'YYYY')) "c10", --only yyyy
DECODE(Substr(t2."OFFR_NM", 1, 3), 'MKT', 'MKT',
DECODE(Substr(t2."OFFR_NM", 1, 2), 'DP', 'DP',
DECODE(Substr(t2."OFFR_NM", 1, 2), 'AP', 'DP',
DECODE(Substr(t2."OFFR_NM", 1, 3), 'PRO','RRO',
DECODE(Substr(t2."OFFR_NM", 1, 5), 'SCPRO','PRO',
'NORPT'))))) "c11",
t4."PGE_NM_SRC_ID" "c12",
t4."WEB_PGE_NM" "c13",
To_number(To_char(t1."CALNDR_DT", 'YYYY')) "c14",
To_number(To_char(t1."CALNDR_DT", 'MM')) "c15",
To_number(To_char(t1."CALNDR_DT", 'WW')) "c16"
FROM "OCMADM"."VTRTMT_DIM" t2,
"OCMADM"."TDT_DIM" t1,
"OCMADM"."VR_OUTBND_CNTCT" t3,
"OCMADM"."TWEB_PGE_DIM" t4
WHERE t2."TRTMT_EFFTV_STRT_DT_DIM_KEY" = t1."DT_DIM_KEY"
AND t3."TRTMT_DIM_KEY" = t2."TRTMT_DIM_KEY"
AND t3."WEB_PGE_DIM_KEY" = t4."WEB_PGE_DIM_KEY"
AND t2."CMPGN_SYS_CD" IN ( 'INT' )
AND t2."TRTMT_STATUS_CD" = 'ACTV'
AND To_number(To_char(t1."CALNDR_DT", 'YYYY')) = 2010
and t3.outbnd_cntct_dt_dim_key > 12455197 --recommended by Brian
AND DECODE(Substr(t2."OFFR_NM", 1, 3), 'MKT', 'MKT',
DECODE(Substr(t2."OFFR_NM", 1, 2),'DP', 'DP',
DECODE(Substr(t2."OFFR_NM", 1, 2),'AP', 'DP',
DECODE(Substr(t2."OFFR_NM", 1, 3),'PRO','RRO',
DECODE(Substr(t2."OFFR_NM", 1, 5), 'SCPRO','PRO',
'NORPT'))))) IN ( 'MKT', 'DP', 'PRO' )
ORDER BY "c6" ASC,
"c5" ASC,
"c8" ASC,
"c7" ASC,
"c2" ASC,
"c11" ASC,
"c10" ASC,
"c4" ASC,
"c13" ASC,
"c12" ASC,
"c15" ASC,
"c16" ASC,
"c9" ASC,
"c3" ASC
Thanks, Pete

Here is the full query with the views and materialized views embedded. You can see the hints we gave this to work. I think it is one of two things... we just don't have the syntax correct or you cannot force the path of execution after a certain number of 'embedded' calls, for lack of a better term.
SELECT DISTINCT 1 "c1",
t1."CALNDR_DT" "c2",
t2."OFFR_CD_ID" "c3",
t2."OFFR_COMM_CHNL_DESC" "c4",
t3."TCLNT_DIM_AGE_BASED_SGMNT_CD" "c5",
t3."TCLT_DM_CURR_CLNT_BUS_SGMNT_CD" "c6",
t2."OFFR_NM" "c7",
t2."CMPGN_NM" "c8",
t3."TCLNT_DIM_CLNT_DIM_KEY" "c9",
To_number(To_char(t1."CALNDR_DT", 'YYYY')) "c10",
DECODE(Substr(t2."OFFR_NM", 1, 3), 'MKT', 'MKT',
DECODE(
Substr(t2."OFFR_NM", 1, 2), 'DP', 'DP'
DECODE(
Substr(t2."OFFR_NM", 1, 2), 'AP', 'DP'
DECODE(
Substr(t2."OFFR_NM", 1, 3), 'PRO',
'RRO',
DECODE(
Substr(t2."OFFR_NM", 1, 5), 'SCPRO',
'PRO',
'NORPT'))))) "c11",
t4."PGE_NM_SRC_ID" "c12",
t4."WEB_PGE_NM" "c13"
FROM "OCMADM"."VTRTMT_DIM" t2,
"OCMADM"."TDT_DIM" t1,
( SELECT /*+ FULL(mv_hhld_dim) FULL(clnt_scdim_mrge) */ tclnt_cmpgn_outbnd_cntct_fact.clnt_cmpgn_outbnd_cntct_key,
tclnt_cmpgn_outbnd_cntct_fact.outbnd_cntct_dt_dim_key,
tclnt_cmpgn_outbnd_cntct_fact.trtmt_dim_key,
tclnt_cmpgn_outbnd_cntct_fact.clnt_scdim_key,
tclnt_cmpgn_outbnd_cntct_fact.cmpgn_evnt_typ_dim_key,
tclnt_cmpgn_outbnd_cntct_fact.web_pge_dim_key,
tclnt_cmpgn_outbnd_cntct_fact.cmpgn_sys_cd,
tclnt_cmpgn_outbnd_cntct_fact.cntct_tm_dim_key,
tclnt_cmpgn_outbnd_cntct_fact.etl_procs_key,
tclnt_cmpgn_outbnd_cntct_fact.etl_ld_ts,
mv_clnt_dim.tclnt_dim_clnt_dim_key,
mv_clnt_dim.tclnt_dim_po_id,
mv_clnt_dim.tclnt_dim_po_typ_cd,
mv_clnt_dim.tclnt_dim_best_age,
mv_clnt_dim.tclnt_dim_age_based_sgmnt_cd,
mv_clnt_dim.tclnt_dim_gendr_cd,
mv_clnt_dim.tclnt_dim_prspct_incpt_dt,
mv_clnt_dim.tclnt_dim_entry_dt,
mv_clnt_dim.tclnt_dim_brth_dt,
mv_clnt_dim.tclnt_dim_wealth_rnking_cd,
mv_clnt_dim.tclt_dm_curr_clnt_bus_sgmnt_cd,
mv_hhld_dim.hhld_dim_key,
mv_hhld_dim.hhld_id,
mv_hhld_dim.hhld_bus_sgmnt_cd
FROM OCMADM.tclnt_cmpgn_outbnd_cntct_fact tclnt_cmpgn_outbnd_cntct_fact
INNER JOIN OCMADM.mv_clnt_scdim_mrge clnt_scdim_mrge
ON clnt_scdim_mrge.tclnt_scdim_clnt_scdim_key =
tclnt_cmpgn_outbnd_cntct_fact.clnt_scdim_key
INNER JOIN OCMADM.mv_clnt_dim mv_clnt_dim
ON mv_clnt_dim.tclnt_dim_clnt_dim_key =
clnt_scdim_mrge.tclnt_mrge_mrged_to_clnt_key
INNER JOIN (SELECT /*+ FULL(mv) */ THHLD_CLNT_BRDG.HHLD_CLNT_BRDG_KEY AS THHLD_CLNT_BRDG_KEY,
THHLD_CLNT_BRDG.HHLD_DIM_KEY AS THHLD_CLNT_BRDG_HHLD_DIM_KEY,
THHLD_CLNT_BRDG.STRT_DT_DIM_KEY AS THHLD_CLT_BRDG_STRT_DT_DIM_KEY,
THHLD_CLNT_BRDG.END_DT_DIM_KEY AS THHLD_CLT_BRDG_END_DT_DIM_KEY,
MV.TCLNT_SCDIM_CLNT_SCDIM_KEY AS TCLNT_SCDIM_CLNT_SCDIM_KEY,
MV.TCLNT_SCDIM_CLNT_DIM_KEY AS TCLNT_SCDIM_CLNT_DIM_KEY,
MV.TCLNT_SCDIM_BUS_SGMNT_CD AS TCLNT_SCDIM_BUS_SGMNT_CD,
MV.TCLNT_SCDIM_SGMNTN_RNK_NO AS TCLNT_SCDIM_SGMNTN_RNK_NO,
MV.TCLNT_SCDIM_STRT_DT_DIM_KEY AS TCLNT_SCDIM_STRT_DT_DIM_KEY,
MV.TCLNT_SCDIM_END_DT_DIM_KEY AS TCLNT_SCDIM_END_DT_DIM_KEY,
MV.TCLNT_MRGE_MRGED_TO_CLNT_KEY AS TCLNT_MRGE_MRGED_TO_CLNT_KEY,
MV.TCLNT_MRGE_MRGED_FR_CLNT_KEY AS TCLNT_MRGE_MRGED_FR_CLNT_KEY,
MV.TCLNT_MRGE_STRT_DT_DIM_KEY AS TCLNT_MRGE_STRT_DT_DIM_KEY,
MV.TCLNT_MRGE_END_DT_DIM_KEY AS TCLNT_MRGE_END_DT_DIM_KEY
FROM OCMADM.MV_CLNT_SCDIM_MRGE MV,
OCMADM.THHLD_CLNT_BRDG THHLD_CLNT_BRDG
WHERE THHLD_CLNT_BRDG.CLNT_SCDIM_KEY = MV.TCLNT_SCDIM_CLNT_SCDIM_KEY
AND MV.TCLNT_SCDIM_END_DT_DIM_KEY = 15373484
AND MV.TCLNT_MRGE_END_DT_DIM_KEY = 15373484
AND THHLD_CLNT_BRDG.END_DT_DIM_KEY = 15373484) v_hhld_clnt_brdg
ON v_hhld_clnt_brdg.tclnt_mrge_mrged_to_clnt_key =
mv_clnt_dim.tclnt_dim_clnt_dim_key
INNER JOIN OCMADM.mv_hhld_dim mv_hhld_dim
ON mv_hhld_dim.hhld_dim_key =
v_hhld_clnt_brdg.thhld_clnt_brdg_hhld_dim_key
WHERE v_hhld_clnt_brdg.thhld_clt_brdg_end_dt_dim_key = 15373484) t3,
"OCMADM"."TWEB_PGE_DIM" t4
WHERE t2."TRTMT_EFFTV_STRT_DT_DIM_KEY" = t1."DT_DIM_KEY"
AND t3."TRTMT_DIM_KEY" = t2."TRTMT_DIM_KEY"
AND t3."WEB_PGE_DIM_KEY" = t4."WEB_PGE_DIM_KEY"
AND t2."CMPGN_SYS_CD" IN ( 'INT' )
AND t2."TRTMT_STATUS_CD" = 'ACTV'
AND To_number(To_char(t1."CALNDR_DT", 'YYYY')) = 2010
AND DECODE(Substr(t2."OFFR_NM", 1, 3), 'MKT', 'MKT',
DECODE(Substr(t2."OFFR_NM", 1, 2),
'DP',
'DP'
DECODE
Substr(t2."OFFR_NM", 1, 2), 'AP', 'DP'
DECODE(
Substr(t2."OFFR_NM", 1, 3), 'PRO',
'RRO',
DECODE(
Substr(t2."OFFR_NM", 1, 5), 'SCPRO',
'PRO',
'NORPT'))))) IN ( 'MKT', 'DP', 'PRO' )
ORDER BY "c6" ASC,
"c5" ASC,
"c8" ASC,
"c7" ASC,
"c2" ASC,
"c11" ASC,
"c10" ASC,
"c4" ASC,
"c12" ASC,
"c13" ASC,
"c9" ASC,
"c3" ASC

Data Federator Full Table scan

Hi,
Is it possible to prevent a Full table scan when creating a join between tables of 2 catalogues in a Data Federator?
This is seriously hampering the development time within Data Federator Development.
I am working with IDT Beta to create a Universe based on Multiple Source. The delay is so huge when creating joins that we could revert to Universe Design Tool. I have posted it here as Data Federator gurus will have tweak about IDT as it incorporates DF within itself in BI 4.0.
Any inputs will be great.. In case this is in the wrong forums, then please move it accordingly.
VFernandes

The issue was fixed when the GA was released. This was present in Beta

Select statement in a function does Full Table Scan

All,
I have been coding a stored procedure that writes 38K rows in less than a minute. If I add another column which requires call to a package and 4 functions within that package, it runs for about 4 hours. I have confirmed that due to problems in one of the functions, the code does full table scans. The package and all of its functions were written by other contractors who have been long gone.
Please note that case_number_in (VARCHAR2) and effective_date_in (DATE) are parameters sent to the problem function and I have verified through TOAD’s debugger that their values are correct.
Table named ps2_benefit_register has over 40 million rows but case_number is an index for that table.
Table named ps1_case_fs has more than 20 million rows but also uses case_number as an index.
Select #1 – causes full table scan runs and writes 38K rows in a couple of hours.
{case}
SELECT max(a2.application_date)
INTO l_app_date
FROM dwfssd.ps2_benefit_register a1, dwfssd.ps2_case_fs a2
WHERE a2.case_number = case_number_in and
a1.case_number = a2.case_number and
a2.application_date <= effective_date_in and
a1.DOCUMENT_TYPE = 'F';
{case}
Select #2 – runs – hard coding values makes the code to write the same 38K rows in a few minutes.
{case}
SELECT max(a2.application_date)
INTO l_app_date
FROM dwfssd.ps2_benefit_register a1, dwfssd.ps2_case_fs a2
WHERE a2.case_number = 'A006438' and
a1.case_number = a2.case_number and
a2.application_date <= '01-Apr-2009' and
a1.DOCUMENT_TYPE = 'F';
{case}
Why using the values in the passed parameter in the first select statement causes full table scan?
Thank you for your help,
Seyed
Edited by: user11117178 on Jul 30, 2009 6:22 AM
Edited by: user11117178 on Jul 30, 2009 6:23 AM
Edited by: user11117178 on Jul 30, 2009 6:24 AM

Hello Dan,
Thank you for your input. The function is not determinsitic, therefore, I am providing you with the explain plan. By version number, if you are refering to the Database version, we are running 10g.
PLAN_TABLE_OUTPUT
Plan hash value: 2132048964
| Id | Operation                     | Name                    | Rows | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | SELECT STATEMENT              |                         |   324K|    33M| 3138   (5)| 00:00:38 |       |       |
|* 1 | HASH JOIN                    |                         |   324K|    33M| 3138   (5)| 00:00:38 |       |       |
|   2 |   BITMAP CONVERSION TO ROWIDS |                         |     3 |     9 |     1   (0)| 00:00:01 |       |       |
|* 3 |    BITMAP INDEX FAST FULL SCAN| IDX_PS2_ACTION_TYPES    |       |       |            |          |       |       |
|   4 |   PARTITION RANGE ITERATOR    |                         |   866K|    87M| 3121   (4)| 00:00:38 |   154 |   158 |
|   5 |    TABLE ACCESS FULL          | PS2_FS_TRANSACTION_FACT |   866K|    87M| 3121   (4)| 00:00:38 |   154 |   158 |
Predicate Information (identified by operation id):
   1 - access("AL1"."ACTION_TYPE_ID"="AL2"."ACTION_TYPE_ID")
   3 - filter("AL2"."ACTION_TYPE"='1' OR "AL2"."ACTION_TYPE"='2' OR "AL2"."ACTION_TYPE"='S')
Thank you very much,
Seyed

Simple Query in Oracle Linked Table in MS Access causes full table scan.

I am running a very simple query in MS ACCESS to a linked Oracle table as follows:
Select *
From EXPRESS_SERVICE_EVENTS --(the linked table name refers to EXPRESS.SERVICE_EVENTS)
Where performed > MyDate()
or
Select *
From EXPRESS_SERVICE_EVENTS --(the linked table name refers to EXPRESS.SERVICE_EVENTS)
Where performed > [Forms]![MyForm]![Date1]
We have over 50 machines and this query runs fine on over half of these, using an Oracle Index on the "performed" field. Running exactly the same thing on the other machines causes a full table scan, therefore ignoring the Index (all machines access the same Access DB).
Strangely, if we write the query as follows:
Select *
From EXPRESS_SERVICE_EVENTS
Where performed > #09/04/2009 08:00#
it works fast everywhere!
Any help on this 'phenominon' would be appreciated.
Things we've done:
Checked regional settings, ODBC driver settings, MS Access settings (as in Tools->Options), we have the latest XP and Office service packs, and re-linked all Access Tables on both the slow and fast machines independantly).

Primarily, thanks gdarling for your reply. This solved our problem.
Just a small note to those who may be using this thread.
Although this might not be the reason, my PC had Oracle 9iR2 installed with Administratiev Tools, where user machines had the same thing installed but using Runtime Installation. For some reason, my PC did not have 'bind date' etc. as an option in the workarounds, but user machines did have this workaround option. Strangely, although I did not have the option, my (ODBC) query was running as expected, but user queries were not.
When we set the workaround checkbox accordingly, the queries then run as expected (fast).
Once again,
Thanks

Where columnname like '%somevalue' causing full table scan

hi,
10.2.0.4 database
is it possible to force an index scan over a full table scan if I use a where clause similar to the following:
where col1 like '%somevalue';
There is an index with col1 as the first segment of the index and another column as the second segment of the index.
Thanks
JOhn

I have done it for you
SQL> create index empX on emp(job) ;
Index created.
SQL> explain plan for select * from emp where job like '%ERK' ;
Explained.
SQL> select * from table(dbms_xplan.display) ;
PLAN_TABLE_OUTPUT
Plan hash value: 3956160932
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      |     1 |    37 |     3   (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| EMP |     1 |    37 |     3   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("JOB" LIKE '%ERK')
13 rows selected.
SQL> explain plan for select * from emp where job like 'C%ERK' ;
Explained.
SQL> select * from table(dbms_xplan.display) ;
PLAN_TABLE_OUTPUT
Plan hash value: 140376749
| Id | Operation                   | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |      |     4 |   148 |     2   (0)| 00:00:01 |
|   1 | TABLE ACCESS BY INDEX ROWID| EMP |     4 |   148 |     2   (0)| 00:00:01 |
|* 2 |   INDEX RANGE SCAN          | EMPX |     4 |       |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("JOB" LIKE 'C%ERK')
       filter("JOB" LIKE 'C%ERK')
15 rows selected.
SQL> explain plan for select /*+index (emp,EMPX) */ * from emp where job like '%ERK' ;
Explained.
SQL> select * from table(dbms_xplan.display) ;
PLAN_TABLE_OUTPUT
Plan hash value: 3745534319
| Id | Operation                   | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |      |     1 |    37 |     2   (0)| 00:00:01 |
|   1 | TABLE ACCESS BY INDEX ROWID| EMP |     1 |    37 |     2   (0)| 00:00:01 |
|* 2 |   INDEX FULL SCAN           | EMPX |     1 |       |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - filter("JOB" LIKE '%ERK')
14 rows selected.SS

Trunc causing Full Table Scans

I have a situtaion here where my query is as follows.
SQL> select count(1) from HBSM_SM_ACCOUNT_INFO where OPTIONAL_PARM5='MH' and CUST_STATUS in ('UP','UUP') and trunc(FIRST_ACTVN_DATE) = trunc(sysdate);
COUNT(1)
6
PLAN_TABLE_OUTPUT
Plan hash value: 3951750498
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | 10 | 13904 (1)| 00:02:47 | | |
| 1 | SORT AGGREGATE | | 1 | 10 | | | | |
| 2 | PARTITION LIST SINGLE| | 1 | 10 | 13904 (1)| 00:02:47 | 12 | 12 |
|* 3 | TABLE ACCESS FULL | HBSM_SM_ACCOUNT_INFO | 1 | 10 | 13904 (1)| 00:02:47 | 12 | 12 |
Predicate Information (identified by operation id):
3 - filter(("CUST_STATUS"='UP' OR "CUST_STATUS"='UUP') AND
TO_DATE(INTERNAL_FUNCTION("FIRST_ACTVN_DATE"))=TO_DATE(TO_CHAR(SYSDATE@!)))
16 rows selected.
If I remove the trunc clause from the query the performance definitely improves the the results are wrong.
SQL> select count(1) from HBSM_SM_ACCOUNT_INFO where OPTIONAL_PARM5='MH' and CUST_STATUS in ('UP','UUP') and FIRST_ACTVN_DATE = trunc(sysdate);
COUNT(1)
0
PLAN_TABLE_OUTPUT
Plan hash value: 454529511
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | 40 | 47 (0)| 00:00:01 | | |
|* 1 | TABLE ACCESS BY GLOBAL INDEX ROWID| HBSM_SM_ACCOUNT_INFO | 1 | 40 | 47 (0)| 00:00:01 | 12 | 12 |
|* 2 | INDEX RANGE SCAN | IND_FIRST_ACTVN_DATE | 51 | | 4 (0)| 00:00:01 | | |
Can someone please help me whereby I can get the right data and I can also prevent these full table scans.

Unless you are using a functional index, applying any function to an indexed column prevents the use of the index.
The way round it in your case is to realise that
select count(1) from HBSM_SM_ACCOUNT_INFO where OPTIONAL_PARM5='MH' and CUST_STATUS in ('UP','UUP') and trunc(FIRST_ACTVN_DATE) = trunc(sysdate)Is really asking that FIRST_ACTVN_DATE should be sometime today. You could therefore rewrite it as
select count(1) from HBSM_SM_ACCOUNT_INFO where OPTIONAL_PARM5='MH' and CUST_STATUS in ('UP','UUP')
and FIRST_ACTVN_DATE >= trunc(sysdate)
and FIRST_ACTVN_DATE < trunc(sysdate) + 1Note, this still might not use the index depending on how many rows are within today's date versus how many are outside today's date.
Also, when posting, remember to put your code between tags and to post create table scripts and sample data inserts.

Preventing Discoverer using Full Table Scans with Decode in a View

Similar Messages

Maybe you are looking for