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

Similar Messages

  • Full Table Scan issue

    Hi,
    I have a two tables (TAB1, TAB2)
    I wrote a SQL query on these two tables and included other tables..
    Col1 & Col2 in TAB1 defined as Char(8)
    Col1 & Col2 in TAB2 defined as VarChar(8)
    in the query where clause I wrote like
    TAB2.Col1 = TRIM(TAB1.Col1)
    and TAB2.Col1 = TRIM(TAB1.Col2)
    Problem: If I add TRIM(), it is doing a full table scan and query is very very slow..
    How to fix this issue?
    Thanks

    Sorry, I am not giving full details here.. but here is some info..
    (11) TABLE ACCESS FULL TAB1 [Analyzed]
    (11) Blocks: 430 Est. Rows: 62,770 of 62,770 Cost: 67
    (19) TABLE ACCESS FULL STAT_ONE [Analyzed]
    (19) Blocks: 821 Est. Rows: 53,580 of 53,580 Cost: 63
    Index? U mean on COL1 & COL2? no idea I will find out..
    Thanks

  • 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.
    I’ve 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’. I’m 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
    _________________________________

  • 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

  • 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

  • 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

  • Query is doing full table scan

    Hi All,
    The below query is doing full table scan. So many threads from application trigger this query and doing full table scan. Can you please tell me how to improve the performance of this query?
    Env is 11.2.0.3 RAC (4 node). Unique index on VZ_ID, LOGGED_IN. The table row count is 2,501,103.
    Query is :-
    select ccagentsta0_.LOGGED_IN as LOGGED1_404_, ccagentsta0_.VZ_ID as VZ2_404_, ccagentsta0_.ACTIVE as ACTIVE404_, ccagentsta0_.AGENT_STATE as AGENT4_404_,
    ccagentsta0_.APPLICATION_CODE as APPLICAT5_404_, ccagentsta0_.CREATED_ON as CREATED6_404_, ccagentsta0_.CURRENT_ORDER as CURRENT7_404_,
    ccagentsta0_.CURRENT_TASK as CURRENT8_404_, ccagentsta0_.HELM_ID as HELM9_404_, ccagentsta0_.LAST_UPDATED as LAST10_404_, ccagentsta0_.LOCATION as LOCATION404_,
    ccagentsta0_.LOGGED_OUT as LOGGED12_404_, ccagentsta0_.SUPERVISOR_VZID as SUPERVISOR13_404_, ccagentsta0_.VENDOR_NAME as VENDOR14_404_
    from AGENT_STATE ccagentsta0_ where ccagentsta0_.VZ_ID='v790531'  and ccagentsta0_.ACTIVE='Y';
    Table Scan                                                       AGENT_STATE                                                2.366666667
    Table Scan                                                       AGENT_STATE                                                0.3666666667
    Table Scan                                                       AGENT_STATE                                                1.633333333
    Table Scan                                                       AGENT_STATE                                                       0.75
    Table Scan                                                       AGENT_STATE                                                1.866666667
    Table Scan                                                       AGENT_STATE                                                2.533333333
    Table Scan                                                       AGENT_STATE                                                0.5333333333
    Table Scan                                                       AGENT_STATE                                                       1.95
    Table Scan                                                       AGENT_STATE                                                        0.8
    Table Scan                                                       AGENT_STATE                                                0.2833333333
    Table Scan                                                       AGENT_STATE                                                1.983333333
    Table Scan                                                       AGENT_STATE                                                        2.5
    Table Scan                                                       AGENT_STATE                                                1.866666667
    Table Scan                                                       AGENT_STATE                                                1.883333333
    Table Scan                                                       AGENT_STATE                                                        0.9
    Table Scan                                                       AGENT_STATE                                                2.366666667
    But the explain plan shows the query is taking the index
    Explain plan output:-
    PLAN_TABLE_OUTPUT
    Plan hash value: 1946142815
    | Id  | Operation                   | Name            | Rows  | Bytes | Cost (%C
    PU)| Time     |
    PLAN_TABLE_OUTPUT
    |   0 | SELECT STATEMENT            |                 |     1 |   106 |   244
    (0)| 00:00:03 |
    |*  1 |  TABLE ACCESS BY INDEX ROWID| AGENT_STATE     |     1 |   106 |   244
    (0)| 00:00:03 |
    |*  2 |   INDEX RANGE SCAN          | AGENT_STATE_IDX |   229 |       |     4
    (0)| 00:00:01 |
    PLAN_TABLE_OUTPUT
    Predicate Information (identified by operation id):
       1 - filter("CCAGENTSTA0_"."ACTIVE"='Y')
       2 - access("CCAGENTSTA0_"."VZ_ID"='v790531')
    The values (VZ_ID) i have given are dummy values picked from the table. I dont get the actual values since the query is coming with bind variables. Please let me know your suggestion on this.
    Thanks,
    Mani

    Hi,
    But I am not getting what is the issue..its a simple select query and index is there on one of the leading columns (VZ_ID --- PK). Explain plan says its using its using Index and it only select fraction of rows from the table. Then why it is doing FTS. For Optimizer, why its like a query doing FTS.
    The rule-based optimizer would have  picked the plan with the index. The cost-based optimizer, however, is picking the plan with the lowest cost. Apparently, the lowest cost plan is the one with the full table scan. And the optimizer isn't necessarily wrong about this.
    Reading data from a table via index probes is only efficient when selecting a relatively small percentage of rows. For larger percentages, a full table scan is generally better.
    Consider a simple example: a query that selects from a table with biographies for all people on the planet. Suppose you are interested in all people from a certain country.
    select * from all_people where country='Vatican'
    would only return only 800 rows (as Vatican is an extremely small country with population of just 800 people). For this case, obviously, using an index would be very efficient.
    Now if we run this query:
    select * from all_people where contry = 'India',
    we'd be getting over a billion of rows. For this case, a full table scan would be several thousand times faster.
    Now consider the third case:
    select * from all_people where country = :b1
    What plan should the optimizer choose? The value of :b1 bind variable is generally not known during the parse time, it will be passed by the user when the query is already parsed, during run-time.
    In this case, one of two scenarios takes place: either the optimizer relies on some built-in default selectivities (basically, it takes a wild guess), or the optimizer postpones taking the final decision until the
    first time the query is run, 'peeks' the value of the bind, and optimizes the query for this case.
    In means, that if the first time the query is parsed, it was called with :b1 = 'India', a plan with a full table scan will be generated and cached for subsequent usage. And until the cursor is aged out of library cache
    or invalidated for some reason, this will be the plan for this query.
    If the first time it was called with :b1='Vatican', then an index-based plan will be picked.
    Either way, bind peeking only gives good results if the subsequent usage of the query is the same kind as the first usage. I.e. in the first case it will be efficient, if the query would always be run for countries with big popultions.
    And in the second case, if it's always run for countries with small populations.
    This mechanism is called 'bind peeking' and it's one of the most common causes of performance problems. In 11g, there are more sophisticated mechanisms, such a cardinality feedback, but they don't always work as expected.
    This mechanism is the most likely explanation for your issue. However, without proper diagnostic information we cannot be 100% sure.
    Best regards,
      Nikolay

  • Problem of full table scan on a partitioned table

    hi all
    There is a table called "si_sync_operation" that have 171040 number of rows.
    I partitioned that table into a new table called "si_sync_operation_par" with 7 partitoins.
    I issued the following statements
    SELECT * FROM si_sync_operation_par.
    SELECT * FROM si_sync_operation.
    The explain plan show that the cost of the first statement is 1626 and that of the second statments is 1810.
    The "cost" of full table scan on partitioned table is lower than the that of non-partitioned table.That's fine.
    But the "Bytes" of full table scan on partitioned table is 5761288680 and that of the non-partitioned table is 263743680.
    Why full table scan on partitioned table access more bytes than non-partitioned table?
    And how could a statment that access more bytes results a lower cost?
    Thank u very much

    As Hemant metioned bytes reported are approximate number of bytes. As far as Cost is concerned, according to Tom its just a number and we should not compare queries by their cost. (search asktom.oracle.com for more information)
    SQL> drop table non_part purge;
    Table dropped.
    SQL> drop table part purge;
    Table dropped.
    SQL>
    SQL> CREATE TABLE non_part
      2        (id  NUMBER(5),
      3         dt    DATE);
    Table created.
    SQL>
    SQL> CREATE TABLE part
      2        (id  NUMBER(5),
      3         dt    DATE)
      4         PARTITION BY RANGE(dt)
      5         (
      6         PARTITION part1_jan2008 VALUES LESS THAN(TO_DATE('01/02/2008','DD/MM/YYYY')),
      7         PARTITION part2_feb2008 VALUES LESS THAN(TO_DATE('01/03/2008','DD/MM/YYYY')),
      8         PARTITION part3_mar2008 VALUES LESS THAN(TO_DATE('01/04/2008','DD/MM/YYYY')),
      9         PARTITION part4_apr2008 VALUES LESS THAN(TO_DATE('01/05/2008','DD/MM/YYYY')),
    10         PARTITION part5_may2008 VALUES LESS THAN(TO_DATE('01/06/2008','DD/MM/YYYY'))
    11       );
    Table created.
    SQL>
    SQL>
    SQL> insert into non_part select rownum, trunc(sysdate) - rownum from dual connect by level <= 140;
    140 rows created.
    Execution Plan
    Plan hash value: 1731520519
    | Id  | Operation                     | Name | Rows  | Cost (%CPU)| Time     |
    |   0 | INSERT STATEMENT              |      |     1 |     2   (0)| 00:00:01 |
    |   1 |  COUNT                        |      |       |            |          |
    |*  2 |   CONNECT BY WITHOUT FILTERING|      |       |            |          |
    |   3 |    FAST DUAL                  |      |     1 |     2   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - filter(LEVEL<=140)
    SQL>
    SQL> insert into part select * from non_part;
    140 rows created.
    Execution Plan
    Plan hash value: 1654070669
    | Id  | Operation         | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | INSERT STATEMENT  |          |   140 |  3080 |     3   (0)| 00:00:01 |
    |   1 |  TABLE ACCESS FULL| NON_PART |   140 |  3080 |     3   (0)| 00:00:01 |
    Note
       - dynamic sampling used for this statement
    SQL>
    SQL> commit;
    Commit complete.
    SQL>
    SQL> set line 10000
    SQL> set autotrace traceonly exp
    SQL> select * from non_part;
    Execution Plan
    Plan hash value: 1654070669
    | Id  | Operation         | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |          |   140 |  3080 |     3   (0)| 00:00:01 |
    |   1 |  TABLE ACCESS FULL| NON_PART |   140 |  3080 |     3   (0)| 00:00:01 |
    Note
       - dynamic sampling used for this statement
    SQL> select * from part;
    Execution Plan
    Plan hash value: 3392317243
    | Id  | Operation           | Name | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
    |   0 | SELECT STATEMENT    |      |   140 |  3080 |     9   (0)| 00:00:01 |       |       |
    |   1 |  PARTITION RANGE ALL|      |   140 |  3080 |     9   (0)| 00:00:01 |     1 |     5 |
    |   2 |   TABLE ACCESS FULL | PART |   140 |  3080 |     9   (0)| 00:00:01 |     1 |     5 |
    Note
       - dynamic sampling used for this statement
    SQL>
    SQL> exec dbms_stats.gather_table_stats(user, 'non_part');
    PL/SQL procedure successfully completed.
    SQL> exec dbms_stats.gather_table_stats(user, 'part');
    PL/SQL procedure successfully completed.
    SQL>
    SQL>
    SQL> select * from non_part;
    Execution Plan
    Plan hash value: 1654070669
    | Id  | Operation         | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |          |   140 |  1540 |     3   (0)| 00:00:01 |
    |   1 |  TABLE ACCESS FULL| NON_PART |   140 |  1540 |     3   (0)| 00:00:01 |
    SQL> select * from part;
    Execution Plan
    Plan hash value: 3392317243
    | Id  | Operation           | Name | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
    |   0 | SELECT STATEMENT    |      |   140 |  1540 |     9   (0)| 00:00:01 |       |       |
    |   1 |  PARTITION RANGE ALL|      |   140 |  1540 |     9   (0)| 00:00:01 |     1 |     5 |
    |   2 |   TABLE ACCESS FULL | PART |   140 |  1540 |     9   (0)| 00:00:01 |     1 |     5 |
    SQL>After analyzing the tables, notice that the Bytes column has changed value

  • Strange full table scan behavior

    Hi all you sharp-eyed oracle gurus out there..
    I need some help/tips on a update I'm running which is taking very long time. Oracle RDMBS is 11.2.0.1 with advanced compression option.
    I'm currently updating all rows in a table from value 1 to 0. (update mistaf set b_code='0';)
    The column in question is a CHAR(1) column and the column is not indexed. The table is a fairly large heap-table with 55 million rows to be updated and it's size is approx 11GB. The table is compressed with the compress for OLTP option.
    What is strange to me is that I can clearly see that a full table scan is running but i cannot see any db file scattered read, as i would expect, but instead i'm only seeing db file sequential reads. I suppose this might be the reason for its long execution time (dbconsole estimates 20 hours to complete looking at sql monitoring).
    Any views on why Oracle would do db file sequential reads on a FTS? And do you agree that this might be the reason why it takes so long to complete?
    More info: I first started the update and left work and the next morning i saw that the update still wasnt finished to which i realised that i had a bitmap index on the column to be updated. I dropped the index and started the update once again.. It seemed to execute very fast at the begining before rapildy declining in performance..
    THanks in advance for any help!

    tried to tkprof the trace file but no sql came up..
    however the raw trace file looks like this
    *** 2010-07-15 17:32:39.829
    WAIT #1: nam='db file sequential read' ela= 7516 file#=11 block#=1185541 blocks=1 obj#=221897 tim=1279207959829762
    WAIT #1: nam='db file sequential read' ela= 7519 file#=3 block#=567053 blocks=1 obj#=0 tim=1279207959837428
    WAIT #1: nam='db file sequential read' ela= 55317 file#=3 block#=186728 blocks=1 obj#=0 tim=1279207959892903
    WAIT #1: nam='db file sequential read' ela= 23363 file#=11 block#=3528062 blocks=1 obj#=221897 tim=1279207959916438
    WAIT #1: nam='db file sequential read' ela= 4796 file#=3 block#=92969 blocks=1 obj#=0 tim=1279207959921314
    WAIT #1: nam='db file sequential read' ela= 1426 file#=11 block#=1079147 blocks=1 obj#=221897 tim=1279207959922846
    WAIT #1: nam='db file sequential read' ela= 4510 file#=11 block#=4180577 blocks=1 obj#=221897 tim=1279207959927479
    WAIT #1: nam='db file sequential read' ela= 12 file#=11 block#=478 blocks=1 obj#=221897 tim=1279207959927715
    WAIT #1: nam='db file sequential read' ela= 11 file#=3 block#=566015 blocks=1 obj#=0 tim=1279207959927768
    WAIT #1: nam='db file sequential read' ela= 17343 file#=11 block#=1142438 blocks=1 obj#=221897 tim=1279207960025312
    WAIT #1: nam='db file sequential read' ela= 11 file#=11 block#=202520 blocks=1 obj#=221897 tim=1279207960025548
    WAIT #1: nam='db file sequential read' ela= 15 file#=3 block#=612704 blocks=1 obj#=0 tim=1279207960025592
    WAIT #1: nam='db file sequential read' ela= 17604 file#=11 block#=1198573 blocks=1 obj#=221897 tim=1279207960043303
    WAIT #1: nam='buffer busy waits' ela= 4 file#=11 block#=1473771 class#=1 obj#=221897 tim=1279207960059044
    WAIT #1: nam='buffer busy waits' ela= 21 file#=11 block#=4173048 class#=1 obj#=221897 tim=1279207960066512
    WAIT #1: nam='buffer busy waits' ela= 3 file#=509 block#=392139 class#=1 obj#=221897 tim=1279207960070049
    WAIT #1: nam='buffer busy waits' ela= 20 file#=11 block#=1134301 class#=1 obj#=221897 tim=1279207960075224
    WAIT #1: nam='db file sequential read' ela= 19164 file#=11 block#=3502287 blocks=1 obj#=221897 tim=1279207960120163
    WAIT #1: nam='buffer busy waits' ela= 70 file#=3 block#=156 class#=45 obj#=0 tim=1279207960126680
    WAIT #1: nam='db file sequential read' ela= 43587 file#=11 block#=3503000 blocks=1 obj#=221897 tim=1279207960189443
    WAIT #1: nam='db file sequential read' ela= 14214 file#=11 block#=4135977 blocks=1 obj#=221897 tim=1279207960203841
    WAIT #1: nam='latch: undo global data' ela= 28 address=11239411512 number=237 tries=0 obj#=221897 tim=1279207960226196
    WAIT #1: nam='buffer busy waits' ela= 376 file#=11 block#=1343104 class#=1 obj#=221897 tim=1279207960228124
    WAIT #1: nam='buffer busy waits' ela= 4 file#=11 block#=1450745 class#=1 obj#=221897 tim=1279207960236628
    WAIT #1: nam='buffer busy waits' ela= 14 file#=11 block#=1456732 class#=1 obj#=221897 tim=1279207960237393
    WAIT #1: nam='buffer busy waits' ela= 3 file#=11 block#=1469341 class#=1 obj#=221897 tim=1279207960239415
    WAIT #1: nam='buffer busy waits' ela= 16 file#=11 block#=3498660 class#=1 obj#=221897 tim=1279207960241348
    WAIT #1: nam='buffer busy waits' ela= 10 file#=11 block#=1478782 class#=1 obj#=221897 tim=1279207960242208
    WAIT #1: nam='buffer busy waits' ela= 11 file#=11 block#=3529073 class#=1 obj#=221897 tim=1279207960242774
    WAIT #1: nam='buffer busy waits' ela= 10 file#=11 block#=3506834 class#=1 obj#=221897 tim=1279207960243188
    WAIT #1: nam='buffer busy waits' ela= 2 file#=11 block#=3550683 class#=1 obj#=221897 tim=1279207960243589
    WAIT #1: nam='buffer busy waits' ela= 3 file#=11 block#=4082313 class#=1 obj#=221897 tim=1279207960244816
    WAIT #1: nam='buffer busy waits' ela= 3 file#=11 block#=4090328 class#=1 obj#=221897 tim=1279207960245086
    WAIT #1: nam='buffer busy waits' ela= 2 file#=11 block#=3555804 class#=1 obj#=221897 tim=1279207960245350
    WAIT #1: nam='buffer busy waits' ela= 2 file#=11 block#=3483832 class#=1 obj#=221897 tim=1279207960245549
    WAIT #1: nam='buffer busy waits' ela= 3 file#=11 block#=4115411 class#=1 obj#=221897 tim=1279207960246323
    WAIT #1: nam='buffer busy waits' ela= 2 file#=11 block#=4100593 class#=1 obj#=221897 tim=1279207960246791
    WAIT #1: nam='buffer busy waits' ela= 3 file#=11 block#=4135120 class#=1 obj#=221897 tim=1279207960247407
    WAIT #1: nam='buffer busy waits' ela= 2 file#=11 block#=4119599 class#=1 obj#=221897 tim=1279207960247832
    WAIT #1: nam='buffer busy waits' ela= 3 file#=11 block#=4174925 class#=1 obj#=221897 tim=1279207960249045
    WAIT #1: nam='buffer busy waits' ela= 3 file#=11 block#=4185250 class#=1 obj#=221897 tim=1279207960249699
    WAIT #1: nam='buffer busy waits' ela= 2 file#=11 block#=4188816 class#=1 obj#=221897 tim=1279207960250138
    WAIT #1: nam='buffer busy waits' ela= 3 file#=11 block#=4189312 class#=1 obj#=221897 tim=1279207960250363
    WAIT #1: nam='buffer busy waits' ela= 3 file#=11 block#=4190380 class#=1 obj#=221897 tim=1279207960250618
    WAIT #1: nam='buffer busy waits' ela= 3 file#=11 block#=4190996 class#=1 obj#=221897 tim=1279207960251339
    WAIT #1: nam='buffer busy waits' ela= 9 file#=11 block#=4176416 class#=1 obj#=221897 tim=1279207960251490
    WAIT #1: nam='buffer busy waits' ela= 11 file#=509 block#=436859 class#=1 obj#=221897 tim=1279207960253748
    WAIT #1: nam='buffer busy waits' ela= 2 file#=509 block#=426961 class#=1 obj#=221897 tim=1279207960253993
    WAIT #1: nam='db file sequential read' ela= 18802 file#=509 block#=413732 blocks=1 obj#=221897 tim=1279207960273210
    WAIT #1: nam='db file sequential read' ela= 13 file#=3 block#=615387 blocks=1 obj#=0 tim=1279207960273322
    WAIT #1: nam='db file sequential read' ela= 3948 file#=3 block#=569033 blocks=1 obj#=0 tim=1279207960277522
    WAIT #1: nam='db file sequential read' ela= 14 file#=11 block#=4191700 blocks=1 obj#=221897 tim=1279207960333755
    WAIT #1: nam='db file sequential read' ela= 3745 file#=11 block#=1197543 blocks=1 obj#=221897 tim=1279207960358279
    WAIT #1: nam='db file sequential read' ela= 4541 file#=11 block#=472946 blocks=1 obj#=221897 tim=1279207960363005
    WAIT #1: nam='db file sequential read' ela= 7775 file#=3 block#=229860 blocks=1 obj#=0 tim=1279207960370848
    WAIT #1: nam='db file sequential read' ela= 22319 file#=11 block#=1150525 blocks=1 obj#=221897 tim=1279207960393342
    WAIT #1: nam='db file sequential read' ela= 17058 file#=11 block#=3542375 blocks=1 obj#=221897 tim=1279207960410577
    WAIT #1: nam='db file sequential read' ela= 16042 file#=509 block#=437647 blocks=1 obj#=221897 tim=1279207960427928
    WAIT #1: nam='db file sequential read' ela= 6412 file#=3 block#=542118 blocks=1 obj#=0 tim=1279207960434440
    WAIT #1: nam='buffer busy waits' ela= 660 file#=3 block#=88 class#=23 obj#=0 tim=1279207960457208
    WAIT #1: nam='db file sequential read' ela= 13 file#=11 block#=4140513 blocks=1 obj#=221897 tim=1279207960467438
    WAIT #1: nam='db file sequential read' ela= 5451 file#=11 block#=3516234 blocks=1 obj#=221897 tim=1279207960472965
    WAIT #1: nam='db file sequential read' ela= 5121 file#=11 block#=3514597 blocks=1 obj#=221897 tim=1279207960478231
    WAIT #1: nam='db file sequential read' ela= 3982 file#=3 block#=1039898 blocks=1 obj#=0 tim=1279207960482281
    WAIT #1: nam='db file sequential read' ela= 5391 file#=509 block#=433941 blocks=1 obj#=221897 tim=1279207960487775
    WAIT #1: nam='db file sequential read' ela= 9707 file#=11 block#=3551543 blocks=1 obj#=221897 tim=1279207960529848
    WAIT #1: nam='buffer busy waits' ela= 4 file#=11 block#=4090328 class#=1 obj#=221897 tim=1279207960610165
    WAIT #1: nam='buffer busy waits' ela= 2 file#=11 block#=4115879 class#=1 obj#=221897 tim=1279207960611710
    WAIT #1: nam='buffer busy waits' ela= 2 file#=11 block#=4100364 class#=1 obj#=221897 tim=1279207960612167
    WAIT #1: nam='buffer busy waits' ela= 3 file#=11 block#=4133339 class#=1 obj#=221897 tim=1279207960612648
    WAIT #1: nam='db file sequential read' ela= 7254 file#=509 block#=405005 blocks=1 obj#=221897 tim=1279207960631133
    WAIT #1: nam='db file sequential read' ela= 25608 file#=11 block#=1181075 blocks=1 obj#=221897 tim=1279207960693920
    etc

  • Avod full table scan help...

    HI ,
    I have sql with some filter and all the have index. the table size is huge index is there in explain plan though index it's going for full table scan it's not recognizing index. i used index hint/*+ INDEX (SYM.SYM_DEPL,SYM.SYDB_DE_N18) */ though it's not recoginizing index in explian plan going for full table scan. and qury take more time.
    please help to resolve the issue and it should recognize index rather than full table scan..

    user13301356 wrote:
    HI ,
    I have sql with some filter and all the have index. the table size is huge index is there in explain plan though index it's going for full table scan it's not recognizing index. i used index hint/*+ INDEX (SYM.SYM_DEPL,SYM.SYDB_DE_N18) */ though it's not recoginizing index in explian plan going for full table scan. and qury take more time.
    please help to resolve the issue and it should recognize index rather than full table scan..What is database version? Are all columns in the table indexed? Copy and paste the query that you are executing.

  • Prompt on DATE forces FULL TABLE SCAN

    When using a prompt on a datetime field OBIEE sends a SQL to the Database with the TIMESTAMP COMMAND.
    Due to Timestamp the Oracle database does a Full Table Scan. The field ATIST is a date with time on the physical database.
    By Default ATIST was configured as TIMESTAMP in the rpd physical layer. The SQL request is sent to a Oracle 10 Database.
    That is the query sent to the database:
    -------------------- Sending query to database named PlantControl1 (id: <<10167>>):
    select distinct T1471.ATIST as c1,
    T1471.GUTMENGEMELD2 as c2
    from
    AGRUECK T1471 /* Fact_ARBEITSGANGMELDUNGEN */
    where ( T1471.ATIST = TIMESTAMP '2005-04-01 13:48:05' )
    order by c1, c2
    The result takes more than half a minute to appear.
    Because BIEE is using "TIMESTAMP" , the database performs a full table scan instead of using the index.
    By using TO_DATE instead of timestamp the result appears after a second.
    select distinct T1471.ATIST, T1471.GUTMENGEMELD2 as c2
    from
    AGRUECK T1471 /* Fact_ARBEITSGANGMELDUNGEN */
    where ( T1471.ATIST = to_date('2005.04.01 13:48:05', 'yyyy.mm.dd hh24:mi:ss') );
    Is there any way resolving the issue?
    PS:When the field ATIST is configured as date at the physical layer the SQL performs well is it uses the command "to_date" instead of "timestamp". But this cuts the time of the date, When it is configured as DATETIME, OBIEE uses TIMESTAMP again.
    What I need is a working date + time field.
    Anybody has encountered a similiar problem?

    To be honest I haven't come across many scenarios where the Time has been important. Most of our reporting stops at Day level.
    What is the real world business question being asked here that requires DayTime?
    Incidentally if you change your datatype on the base table you will see it works fine.
    CREATE TABLE daytime( daytime TIMESTAMP );
    CREATE UNIQUE INDEX dt ON daytime  (daytime)
    SQL> set autotrace traceonly
    SQL> SELECT * FROM daytime
      2  WHERE daytime = TIMESTAMP '2007-04-01 13:00:45';
    no rows selected
    Execution Plan
    Plan hash value: 3985400340
    | Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |      |     1 |    13 |     1   (0)| 00:00:01 |
    |*  1 |  INDEX UNIQUE SCAN| DT   |     1 |    13 |     1   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       1 - access("DAYTIME"=TIMESTAMP' 2007-04-01 13:00:45.000000000')
    Statistics
              1  recursive calls
              0  db block gets
              1  consistent gets
              0  physical reads
              0  redo size
            242  bytes sent via SQL*Net to client
            362  bytes received via SQL*Net from client
              1  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              0  rows processed
    SQL>However if its a date it would appear to do some internal function call which I guess is the source of the problem ...
    | Id  | Operation         | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |         |     1 |     9 |     2   (0)| 00:00:01 |
    |*  1 |  TABLE ACCESS FULL| DAYTIME |     1 |     9 |     2   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       1 - filter(INTERNAL_FUNCTION("DAYTIME")=TIMESTAMP' 2007-04-01
                  13:00:45.000000000')

  • SIDs for Full table scan wait events in db

    Guys,
    10.2.0.5/ 2 node RAC / RHEL-3
    CanAnyone provide me an sql to find all SID doing full table scans in a db?
    Thanks!
    Hari

    You ought to be able to query v$sql_plan for those sql plans with a full scan in them and if you want all the recent plans that contain a full table scan in them. You can join this back to v$session for those session currently executing a full table scan but if the sql in question was a previous statement executed by the session the join will not show the session because that statement is no longer the current statement.
    1 select p.sql_id, s.sid, p.object_name, p.operation, p.options
    2 from v$sql_plan p, v$session s
    3 where p.options like '%FULL%'
    4* and s.sql_id = p.sql_id
    You will probably want to filter out internal operations (operation = "FIXED TABLE")
    HTH -- Mark D Powell --

  • 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.

  • Cursors - More number of repeated full table scans

    Hai,
    If i execute the below mentioned query in sql*plus
    select distinct cod_acct_no, a.cod_cc_brn, a.cod_prod
    from account_master a, product_master b
    where a.prod_no = b.prod_no
    and b.cod_sc_pkg = var_pi_cod_sc_pkg
    and cod_acct_stat not in ( 1,5)
    UNION
    select distinct a.cod_acct_no, a.cod_cc_brn, a.cod_prod
    from account_master a, charge_account sc
    where sc.cod_acct_no = a.cod_acct_no
    and sc.cod_sc_pkg = var_pi_cod_sc_pkg
    and cod_acct_stat not in ( 1,5)
    I am getting results within a minute. Account_master is the big table in this join. And only one full table scan is happening for this table.
    IF the same query is used in pl/sql cursors, it is taking very long time and after analysis, it was found that multiple times of FTS is happening for account_master table. Why it is happening ? Any help pls.
    Regards
    Sridhar

    Hi,
    First thing, you don't need to issue a distinct for each Select section in a Union: Union automatically does that, by sorting and returning distinct values of both result sets combined.
    But most importantly, the performance is poor because you're running a loop, not because the query itself is any worse than what it was in SQL*Plus.
    When you run a cursor for loop, the PL/SQL engine has to switch context to the SQL engine repeatedly to fetch the next row, one at a time, and even though you may
    not notice a performance degradation when you have a small resultset, as it scales up the problem becomes more visible.
    What is it you're performing inside the loop?
    Bottom line is you should avoid the cursor for loop solution and do it in a single statement or at least using bulk collect/forall operations, that should increase your performance dramatically.
    If you can post a little more about your problem, instead the solution you initially thought of, it would help us help you. Basically please provide us your Oracle version, table structures and sample data for them,
    along with an expected output or data manipulation.
    Regards,
    Sitja.

  • 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

Maybe you are looking for