Full scan query

Hi, we are using 9.2.0.6.0 database.Before on month it went to live,it is responding slow,so
i am checking sql statements involving full table scan by using follwoing query.
select a.OBJECT_OWNER,a.OBJECT_NAME,b.SQL_TEXT from V$SQL_PLAN a,V$SQL b WHERE a.address=b.address and a.hash_value=b.hash_value AND A.OPTIONS LIKE 'FULL' and a.OPERATION LIKE 'TABLE ACCESS'AND A.OBJECT_OWNER in ('ABC') order by OBJECT_NAME
first thing sql_txt is showing only 1000 character of the query so for full sql statement we need to use one other column piece for getting full query...so how to group by this ...
then after finding sql statement wht will be the next step to tune this query..
and wht are other areas where i need to look for improving database performance .....

start by using statspack to take snapshots of the database, this will give you an overview of performance and a guide to which SQL is using most resources, either use crontab/windows scheduler or dbms_jobs to schedule a snapshot every 15 minutes you can then generate a report on how the database is performing foro any 15 minute block (or 30 min or hourly if you want). THis should give you a better idea of which sql statements are causing the pain.
Chris

Similar Messages

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

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

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

The plan doesn't use the index but the cost of INDEX FULL SCAN looks better

Hi,
Well, I'm sure I miss the boat... and if the question is pretty tricky, the answer is probably :"You're stupid Greg!". Well anyway, you'll probably be interested in trying to answer it as I've spent some times on it without any result ! I use Oracle XE on Windows...
1) Below is my query and its plan. You'll find the full schema generation script at the end of this email. Look at the cost (468) of the plan and the cost of the same query when you force the use of the index (116). Why is this ?
select count(distinct col5)
2    from demo
3      where col1 between 1 and 50000
4        and col2=col1
5        and col3=col1
6        and col4=col1;
Plan d'execution
Plan hash value: 2072716547
| Id | Operation          | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |      |     1 |   116 |   468   (2)| 00:00:06 |
|   1 | SORT GROUP BY     |      |     1 |   116 |            |          |
|* 2 |   TABLE ACCESS FULL| DEMO |     1 |   116 |   468   (2)| 00:00:06 |
Predicate Information (identified by operation id):
   2 - filter("COL2"="COL1" AND "COL3"="COL1" AND "COL4"="COL1" AND
              "COL1"<=50000 AND "COL2"<=50000 AND "COL3"<=50000 AND "COL4"<=50000 AND
              "COL1">=1 AND "COL2">=1 AND "COL3">=1 AND "COL4">=1)2) When I force the use of an index (with a Hint), You'll see the cost of the plan is 116 which is definitly better than the TABLE ACCESS FULL (468) :
SQL> l
1 select /*+ index(demo demo_idx)*/ count(distinct col5)
2    from demo
3      where col1 between 1 and 50000
4        and col2=col1
5        and col3=col1
6*       and col4=col1
SQL> /
Plan d'execution
Plan hash value: 189561699
| Id | Operation                    | Name     | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT             |          |     1 |   116 |   437   (2)| 00:00:06 |
|   1 | SORT GROUP BY               |          |     1 |   116 |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID| DEMO     |     1 |   116 |   437   (2)| 00:00:06 |
|* 3 |    INDEX FULL SCAN           | DEMO_IDX |     1 |       |   436   (2)| 00:00:06 |
Predicate Information (identified by operation id):
   3 - filter("COL2"="COL1" AND "COL3"="COL1" AND "COL4"="COL1" AND
              "COL1"<=50000 AND "COL2"<=50000 AND "COL3"<=50000 AND "COL4"<=50000 AND
              "COL1">=1 AND "COL2">=1 AND "COL3">=1 AND "COL4">=1)3) My question is why is plan1 used while plan2 should be considered better by the optimizer regarding the cost (to make the case even more complex, plan1 is actually more efficient but this is out of the scope of my question. I know that and I know why !).
You'll find a script to generate the structures and data below. I can send you the 10053 traces if you what to go furthermore. Take care the index is a REVERSE index (Don't know if query rewrite should be enabled in order to take advantage of this type of index but it is set to "true" (and "trusted") :
drop table demo;
create table demo (col1 number not null,
    col2 number,
    col3 number,
    col4 number,
    col5 varchar2(500));
begin
for i in 1..100000 loop
    insert into demo values (i,i,i,i,'This column is used to raise the High Water Mark and '||
                             ' the cost of an TABLE ACCESS FULL operation');
end loop;
end;
commit;
create index demo_idx on demo(col1,col2,col3,col4) reverse;
exec dbms_stats.gather_table_stats(USER, 'DEMO', cascade=>true, -
method_opt=>'FOR ALL COLUMNS SIZE 254', no_invalidate=>false) Any comments are welcome ! Best Regards,
Gregory
Message was edited by:
arkzoyd... I've added the "pre" tags

I suspect this has something to do with db_file_multiblock_read_count
After running provided creation statements by you I got following results:
SQL> show parameter multiblock
NAME                                 TYPE        VALUE
db_file_multiblock_read_count        integer     16
SQL> set autotrace on
SQL> select count(distinct col5)
2   from demo
3   where col1 between 1 and 50000
4   and col2=col1
5   and col3=col1
6   and col4=col1
7 /
COUNT(DISTINCTCOL5)
                  1
Execution Plan
Plan hash value: 2072716547
| Id | Operation          | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |      |     1 |   116 |   375   (1)| 00:00:05 |
|   1 | SORT GROUP BY     |      |     1 |   116 |            |          |
|* 2 |   TABLE ACCESS FULL| DEMO |     1 |   116 |   375   (1)| 00:00:05 |
Predicate Information (identified by operation id):
   2 - filter("COL2"="COL1" AND "COL3"="COL1" AND "COL4"="COL1" AND
              "COL1"<=50000 AND "COL2"<=50000 AND "COL3"<=50000 AND "COL4"<=5000
0 AND
              "COL1">=1 AND "COL2">=1 AND "COL3">=1 AND "COL4">=1)
Statistics
        196 recursive calls
          0 db block gets
       1734 consistent gets
        850 physical reads
          0 redo size
        422 bytes sent via SQL*Net to client
        385 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          7 sorts (memory)
          0 sorts (disk)
          1 rows processed
SQL> select /*+ index(demo demo_idx)*/ count(distinct col5)
2   from demo
3   where col1 between 1 and 50000
4   and col2=col1
5   and col3=col1
6   and col4=col1
7 /
COUNT(DISTINCTCOL5)
                  1
Execution Plan
Plan hash value: 189561699
| Id | Operation                    | Name     | Rows | Bytes | Cost (%CPU)| T
ime     |
|   0 | SELECT STATEMENT             |          |     1 |   116 |   431   (1)| 0
0:00:06 |
|   1 | SORT GROUP BY               |          |     1 |   116 |            |
        |
|   2 |   TABLE ACCESS BY INDEX ROWID| DEMO     |     1 |   116 |   431   (1)| 0
0:00:06 |
|* 3 |    INDEX FULL SCAN           | DEMO_IDX |     1 |       |   430   (1)| 0
0:00:06 |
Predicate Information (identified by operation id):
   3 - filter("COL2"="COL1" AND "COL3"="COL1" AND "COL4"="COL1" AND
              "COL1"<=50000 AND "COL2"<=50000 AND "COL3"<=50000 AND "COL4"<=5000
0 AND
              "COL1">=1 AND "COL2">=1 AND "COL3">=1 AND "COL4">=1)
Statistics
          1 recursive calls
          0 db block gets
      50426 consistent gets
        428 physical reads
          0 redo size
        422 bytes sent via SQL*Net to client
        385 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          1 sorts (memory)
          0 sorts (disk)
          1 rows processedNow I modify multiblock_read_count and full scan cost is going up although anyway Oracle by default chooses full scan instead of index access.
SQL> alter session set db_file_multiblock_read_count = 8;
Session altered.
SQL> select count(distinct col5)
2   from demo
3   where col1 between 1 and 50000
4   and col2=col1
5   and col3=col1
6   and col4=col1
7 /
COUNT(DISTINCTCOL5)
                  1
Execution Plan
Plan hash value: 2072716547
| Id | Operation          | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |      |     1 |   116 |   463   (1)| 00:00:06 |
|   1 | SORT GROUP BY     |      |     1 |   116 |            |          |
|* 2 |   TABLE ACCESS FULL| DEMO |     1 |   116 |   463   (1)| 00:00:06 |
Predicate Information (identified by operation id):
   2 - filter("COL2"="COL1" AND "COL3"="COL1" AND "COL4"="COL1" AND
              "COL1"<=50000 AND "COL2"<=50000 AND "COL3"<=50000 AND "COL4"<=5000
0 AND
              "COL1">=1 AND "COL2">=1 AND "COL3">=1 AND "COL4">=1)
Statistics
          1 recursive calls
          0 db block gets
       1697 consistent gets
        850 physical reads
          0 redo size
        422 bytes sent via SQL*Net to client
        385 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          1 sorts (memory)
          0 sorts (disk)
          1 rows processed
SQL> select /*+ index(demo demo_idx)*/ count(distinct col5)
2   from demo
3   where col1 between 1 and 50000
4   and col2=col1
5   and col3=col1
6   and col4=col1
7 /
COUNT(DISTINCTCOL5)
                  1
Execution Plan
Plan hash value: 189561699
| Id | Operation                    | Name     | Rows | Bytes | Cost (%CPU)| T
ime     |
|   0 | SELECT STATEMENT             |          |     1 |   116 |   431   (1)| 0
0:00:06 |
|   1 | SORT GROUP BY               |          |     1 |   116 |            |
        |
|   2 |   TABLE ACCESS BY INDEX ROWID| DEMO     |     1 |   116 |   431   (1)| 0
0:00:06 |
|* 3 |    INDEX FULL SCAN           | DEMO_IDX |     1 |       |   430   (1)| 0
0:00:06 |
Predicate Information (identified by operation id):
   3 - filter("COL2"="COL1" AND "COL3"="COL1" AND "COL4"="COL1" AND
              "COL1"<=50000 AND "COL2"<=50000 AND "COL3"<=50000 AND "COL4"<=5000
0 AND
              "COL1">=1 AND "COL2">=1 AND "COL3">=1 AND "COL4">=1)
Statistics
          1 recursive calls
          0 db block gets
      50426 consistent gets
          0 physical reads
          0 redo size
        422 bytes sent via SQL*Net to client
        385 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          1 sorts (memory)
          0 sorts (disk)
          1 rows processedSo I don't know what is the default value of dbfmbrc in XE and not gone too deep to understand how for example system statistics may change your situation.
Gints Plivna
http://www.gplivna.eu
P.S. BTW I used Oracle Database 10g Enterprise Edition Release 10.2.0.1.0.
Message was edited by:
gintsp
listened to Williams suggestion :)

What is mean by index range scan and fast full scan

What is mean by the following execution plans
1)Table access by index rowid
2) Index range scan
3) Index fast full scan
4) global index by rowid
..etc
where i can get this information.In what situation CBO take these paths.Can you pls give me a link where i can find all these.I read these long time ago but not able to recollect
Thanks
Anand

Oracle® Database Performance Tuning Guide
10g Release 2 (10.2)
Part Number B14211-01
13.5 Understanding Access Paths for the Query Optimizer
http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14211/optimops.htm#sthref1281

Index vs Full Scan - Parallelism

Hi everyone, i have an problem my scenario is a plataform Linux x64 bits in RAC 10gR2 (10.2.0.5) and we are migrating to RAC 11gR2 (11.2.0.3.3) in AIX 7.1 and my query: Update movimientos set ESTADOENCOLADO = :"SYS_B_0" where tipoproceso = :"SYS_B_1" and ESTADOENCOLADO = :"SYS_B_2"; in my Oracle 10g uses an index in the table MOVIMIENTOS and in the Oracle 11g the optimizer takes a FULL SCAN.
In both database server the statistics are updated with estimate 100% even the system statistics, fixed tables and data dictionary are taken its statistics.
I review the cost in both plans in Oracle 11g (with a full scan and other using a hint to index) and the full scan plan has less cost that the index. My db_file_multiblock_read_count is not set up, but in the Oracle 10g i see a value of 16 and in the 11g i see a value dinamic of 192. Understand that it too helps an uses a full scan.
The problem is that the query taken in Oracle 10g 20 minutes, but in the Oracle 11g with full scan 1.4 h whereas with a hint takes too 20 minutes.
I use the advisor tuning and no recommendations.
So basicaly i fix it modifily my parameter optimizer_index_cost_adj to 80 and it works well.
My doubt is why Oracle11gR2 says me that a full scan is faster than take an index when in the real live it is not working in this mode. I need some posible reasons please.
Thank you very much if somebody can help me with some tip or idea.
Regards

>
My doubt is why Oracle11gR2 says me that a full scan is faster than take an index when in the real live it is not working in this mode. I need some posible reasons please.
>
Well if you can't figure it out by looking at the plans what makes you think anyone can figure it out without looking at them?
We have no idea what the plans contain. Post the plans, record counts for the table(s) involved, record counts for any filter predicates and the other information needed. See the FAQ for how to post a tuning request and the information needed.

INDEX UNIQUE SCAN instead of   INDEX FULL SCAN or TABLE ACCESS FULL

I have calculated statistics in all tables and indexes
I have a table and a view and when I put it
SELECT *
FROM TABLE_A A
INNER JOIN VIEW_B B ON A.KEY_ID = B.PFK_KEY_ID
WHERE (B.FK_ID_XXX = 1)
If I see the execution plan:
In TABLE_A make a
TABLE ACCESS BY INDEX ROWID
INDEX UNIQUE SCAN (FIELD_A_TABLE_A_PK)
Itâs OK. I NEED IT (INDEX UNIQUE SCAN)
But If I put
SELECT A.Field_1, A.Field_2, A.Field_3, A.Field_4
FROM TABLE_A A
INNER JOIN VIEW_B B ON A.KEY_ID = B.PFK_KEY_ID
WHERE (B.FK_ID_XXX = 1)
In table A make a TABLE ACCESS FULL.
Then If I put:
SELECT /*+ INDEX(A FIELD_A_TABLE_A_PK) */ A.Field_1, A.Field_2, A.Field_3, A.Field_4
FROM TABLE_A A
INNER JOIN VIEW_B B ON A.KEY_ID = B.PFK_KEY_ID
WHERE (B.FK_ID_XXX = 1)
If I see the execution plan:
In TABLE_A make a
TABLE ACCESS BY INDEX ROWID
INDEX UNIQUE SCAN (FIELD_A_TABLE_A_PK)
Itâs OK. I NEED IT (INDEX UNIQUE SCAN)
Finally, If I put other tables and views in the query (I NEED IT)
For example:
SELECT /*+ INDEX(A FIELD_A_TABLE_A_PK) */ A.Field_1, A.Field_2, A.Field_3, A.Field_4
FROM TABLE_A A
INNER JOIN VIEW_B B ON A.KEY_ID = B.PFK_KEY_ID
INNER JOIN TABLE_Câ¦.
LEFT JOIN VIEW_Dâ¦.
WHERE (B.FK_ID_XXX = 1)
If I see the execution plan:
In TABLE_A make a
TABLE ACCESS BY INDEX ROWID
INDEX FULL SCAN (FIELD_A_TABLE_A_PK)
I need INDEX UNIQUE SCAN instead of INDEX FULL SCAN or TABLE ACCESS FULL.
How can obtain it?
What happens???
Thanks!

Notice the difference in cardinality between your two select statements:
SELECT STATEMENT, GOAL = ALL_ROWS Cost=5 Cardinality=1
SELECT STATEMENT, GOAL = ALL_ROWS Cost=10450 Cardinality=472161Apparently since the optimizer believed the first statement was going to return one row, it used an index. But in the second statement it believed it was going to return nearly the whole table (didn't you say it had around 500k rows?). Hence full table scan.

Why a table full scan when I've got the PK in the WHERE clause?

There is a very complex query that I need to optimize in an Oracle 10gR2 environment. I am deconstructing it into layers to see what is causing the first bottleneck. The innermost portion is fine, with an explain plan cost of 54. With a typical value for the bind variable, it returns 125 zero_id values. There are over 100,000 rows in table T_ONE in my test database, but my customer has over one million rows in their production instance.
              WITH t_merged_id AS (SELECT DISTINCT zero_id FROM t_zero WHERE NVL(column2, zero_id) = :i_id)
              SELECT   t_one.one_id
                  FROM t_one
                      INNER JOIN t_two
                          ON t_one.column1 = t_two.two_id
                      INNER JOIN t_merged_id
                          ON t_two.column10 = t_merged_id.zero_id
              UNION ALL
              SELECT   t_one.one_id
                  FROM t_one
                      INNER JOIN t_two
                          ON t_one.column2 = t_two.two_id
                      INNER JOIN t_merged_id
                          ON t_two.column10 = t_merged_id.zero_id
              UNION ALL
              SELECT   t_one.one_id
                  FROM t_one
                      INNER JOIN t_three
                          ON t_one.column3 = t_three.three_id
                      INNER JOIN t_merged_id
                          ON t_three.column10 = t_merged_id.zero_id
              UNION ALL
              SELECT   t_one.one_id
                  FROM t_one
                      INNER JOIN t_four
                          ON t_one.column4 = t_four.four_id
                      INNER JOIN t_two
                          ON t_four.column1 = t_two.two_id
                      INNER JOIN t_merged_id
                          ON t_two.two_id = t_merged_id.zero_id
              UNION ALL
              SELECT   t_one.one_id
                  FROM t_one INNER JOIN t_merged_id ON t_one.column5 = t_merged_id.zero_id
              UNION
              SELECT   t_one.one_id
                  FROM t_one INNER JOIN t_merged_id ON t_one.column6 = t_merged_id.zero_idHowever, the next step is to obtain a bunch of columns from T_ONE for each of those ONE_ID values. Adding that looks like the following, which causes a table full scan on T_ONE (and an explain plan cost over 1,500 for this query in my test system) and it takes far too long to return the results.
SELECT   t_one.*
    FROM     t_one
         INNER JOIN
             (--This is the start of the query shown above
              WITH t_merged_id AS (SELECT DISTINCT zero_id FROM t_zero WHERE NVL(column2, zero_id) = :i_id)
              SELECT   t_one.one_id
                  FROM t_one
                      INNER JOIN t_two
                          ON t_one.column1 = t_two.two_id
                      INNER JOIN t_merged_id
                          ON t_two.column10 = t_merged_id.zero_id
              UNION ALL
              SELECT   t_one.one_id
                  FROM t_one
                      INNER JOIN t_two
                          ON t_one.column2 = t_two.two_id
                      INNER JOIN t_merged_id
                          ON t_two.column10 = t_merged_id.zero_id
              UNION ALL
              SELECT   t_one.one_id
                  FROM t_one
                      INNER JOIN t_three
                          ON t_one.column3 = t_three.three_id
                      INNER JOIN t_merged_id
                          ON t_three.column10 = t_merged_id.zero_id
              UNION ALL
              SELECT   t_one.one_id
                  FROM t_one
                      INNER JOIN t_four
                          ON t_one.column4 = t_four.four_id
                      INNER JOIN t_two
                          ON t_four.column1 = t_two.two_id
                      INNER JOIN t_merged_id
                          ON t_two.two_id = t_merged_id.zero_id
              UNION ALL
              SELECT   t_one.one_id
                  FROM t_one INNER JOIN t_merged_id ON t_one.column5 = t_merged_id.zero_id
              UNION
              SELECT   t_one.one_id
                  FROM t_one INNER JOIN t_merged_id ON t_one.column6 = t_merged_id.zero_id
               --This is the end of the query shown above
               ) t_list
         ON t_one.one_id = t_list.one_idMy question is, why wouldn’t Oracle use the existing index PK_T_ONE, which is keyed on T_ONE.ONE_ID? I tried refactoring the query using a “WHERE t_one.one_id IN” construct instead of the INNER JOIN but it didn’t make any difference. Neither did adding an index hint, which I hoped would force the use of the PK index.
Any ideas?

I was able to completely resolve my problem, but I still want to understand why the original query wouldn't use an index.
(My solution was to move all the joins and where clauses from the query that wrapped the one we've been discussing and put them into each SELECT in the UNION, so there is no longer any inner subquery. So instead of trying to first get a list of ID values from the subquery, get the full records for the IDs from an outer query, and then joining to the outer query, I made SELECT in the UNION contain the full logic. This makes the query a lot more verbose, because all the joins and wheres are repeated six times, but it does use the index and returns in 0.04 seconds instead of over nine minutes in my test database.)
hoek wrote:
Values for optimizer_index_caching and optimizer_index_cost_adj are not the defaults. Any reasons for that?I am not a DBA and have no idea. However, I did a Google search and found this: http://decipherinfosys.wordpress.com/2007/02/13/optimizer_index_cost_adj-and-optimizer_index_caching/. Apparently Tom Kyte would approve more of our settings than the defaults.
hoek wrote:
Any chance to get a realistic dataset on your test server?Unfortunately, not for quite some time. The customer won't provide any real data, and generating data for testing is complex because of all the interrelationships. I have someone working on that. However, I was able to get back on the primary test server that has 136k records in the main table instead of only 2k. So far as I know, the Oracle configuration between the test server and the customer's server is the same. However, they have much more serious hardware that I do (more processors, more RAM, more platters). On the other hand, they have 10 times as much data.
hoek wrote:
Your second execution plan contains differents stats, they're not the 'common ones'. (E-rows etc.)The predicates are the same as the first. The 2nd plan was generated by the 10g-specific portion of Randolph's script using the command "select * from table(dbms_xplan.display_cursor(null, null, 'ALLSTATS LAST'));".
This is the result from running the script on the main test server:
NAME                                 TYPE                             VALUE
_optimizer_cost_based_transformation string                           OFF
optimizer_dynamic_sampling           integer                          2
optimizer_features_enable            string                           10.2.0.4
optimizer_index_caching              integer                          95
optimizer_index_cost_adj             integer                          10
optimizer_mode                       string                           CHOOSE
optimizer_secure_view_merging        boolean                          TRUE
db_file_multiblock_read_count        integer                          32
db_block_size                        integer                          8192
cursor_sharing                       string                           FORCE
SNAME                PNAME                     PVAL1 PVAL2
SYSSTATS_INFO        STATUS                          COMPLETED
SYSSTATS_INFO        DSTART                          04-04-2008 07:02
SYSSTATS_INFO        DSTOP                           04-04-2008 07:02
SYSSTATS_INFO        FLAGS                         1
SYSSTATS_MAIN        CPUSPEEDNW            646.57331
SYSSTATS_MAIN        IOSEEKTIM                    10
SYSSTATS_MAIN        IOTFRSPEED                 4096
SYSSTATS_MAIN        SREADTIM
SYSSTATS_MAIN        MREADTIM
SYSSTATS_MAIN        CPUSPEED
SYSSTATS_MAIN        MBRC
SYSSTATS_MAIN        MAXTHR
SYSSTATS_MAIN        SLAVETHR
SQL> SELECT st.*
2    FROM t_senttsk st INNER JOIN (WITH t_mrgdusr AS (SELECT DISTINCT usr_id
3                                                       FROM t_usr
4                                                      WHERE NVL(usr_mrgemstr, usr_id) = 10000002                    /* i_payer_id */
5                                                                                                )
6                                  SELECT t_senttsk.setk_id
7                                    FROM t_senttsk INNER JOIN t_mrgdusr
8                                             ON t_senttsk.setk_affn_memb = t_mrgdusr.usr_id
9                                  UNION
10                                  SELECT t_senttsk.setk_id
11                                    FROM t_senttsk INNER JOIN t_mrgdusr
12                                             ON t_senttsk.setk_ownr = t_mrgdusr.usr_id) t_affil
13             ON st.setk_id = t_affil.setk_id;
no rows selected
Elapsed: 00:13:14.54
Execution Plan
Plan hash value: 1241660758
| Id | Operation                         | Name                        | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                  |                             |   169K|    64M| 1403   (3)| 00:00:17 |
|   1 | NESTED LOOPS                     |                             |   169K|    64M| 1403   (3)| 00:00:17 |
|   2 |   TABLE ACCESS FULL               | T_SENTTSK                   |   136K|    51M| 1400   (3)| 00:00:17 |
|   3 |   VIEW                            |                             |     1 |     6 |     1   (0)| 00:00:01 |
|   4 |    TEMP TABLE TRANSFORMATION      |                             |       |       |            |          |
|   5 |     LOAD AS SELECT                |                             |       |       |            |          |
|   6 |      TABLE ACCESS BY INDEX ROWID | T_USR                       |     1 |     8 |     1   (0)| 00:00:01 |
|* 7 |       INDEX RANGE SCAN            | IX_NVL_USR_MRGEMSTR_USR_ID |     1 |       |     1   (0)| 00:00:01 |
|   8 |     SORT UNIQUE                   |                             |       |       |            |          |
|   9 |      UNION-ALL PARTITION          |                             |       |       |            |          |
| 10 |       NESTED LOOPS                |                             |     1 |    25 |     3   (0)| 00:00:01 |
| 11 |        TABLE ACCESS BY INDEX ROWID| T_SENTTSK                   |     1 |    12 |     1   (0)| 00:00:01 |
|* 12 |         INDEX UNIQUE SCAN         | PK_T_SENTTSK                |     1 |       |     1   (0)| 00:00:01 |
|* 13 |        VIEW                       |                             |     1 |    13 |     2   (0)| 00:00:01 |
| 14 |         TABLE ACCESS FULL         | SYS_TEMP_0FD9D6608_399116CE |     1 |     6 |     2   (0)| 00:00:01 |
| 15 |       NESTED LOOPS                |                             |     1 |    22 |     3   (0)| 00:00:01 |
|* 16 |        TABLE ACCESS BY INDEX ROWID| T_SENTTSK                   |     1 |     9 |     1   (0)| 00:00:01 |
|* 17 |         INDEX UNIQUE SCAN         | PK_T_SENTTSK                |     1 |       |     1   (0)| 00:00:01 |
|* 18 |        VIEW                       |                             |     1 |    13 |     2   (0)| 00:00:01 |
| 19 |         TABLE ACCESS FULL         | SYS_TEMP_0FD9D6608_399116CE |     1 |     6 |     2   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   7 - access(NVL("USR_MRGEMSTR","USR_ID")=10000002)
12 - access("T_SENTTSK"."SETK_ID"="ST"."SETK_ID")
13 - filter("T_SENTTSK"."SETK_AFFN_MEMB"="T_MRGDUSR"."USR_ID")
16 - filter("T_SENTTSK"."SETK_OWNR" IS NOT NULL)
17 - access("T_SENTTSK"."SETK_ID"="ST"."SETK_ID")
18 - filter("T_SENTTSK"."SETK_OWNR"="T_MRGDUSR"."USR_ID")
Statistics
        349 recursive calls
     275041 db block gets
    1239881 consistent gets
         26 physical reads
   52730252 redo size
       3312 bytes sent via SQL*Net to client
        240 bytes received via SQL*Net from client
          1 SQL*Net roundtrips to/from client
     136835 sorts (memory)
          0 sorts (disk)
          0 rows processed
SQL> SELECT /*+ gather_plan_statistics */ st.*
2    FROM t_senttsk st INNER JOIN (WITH t_mrgdusr AS (SELECT DISTINCT usr_id
3                                                       FROM t_usr
4                                                      WHERE NVL(usr_mrgemstr, usr_id) = 10000002                    /* i_payer_id */
5                                                                                                )
6                                  SELECT t_senttsk.setk_id
7                                    FROM t_senttsk INNER JOIN t_mrgdusr
8                                             ON t_senttsk.setk_affn_memb = t_mrgdusr.usr_id
9                                  UNION
10                                  SELECT t_senttsk.setk_id
11                                    FROM t_senttsk INNER JOIN t_mrgdusr
12                                             ON t_senttsk.setk_ownr = t_mrgdusr.usr_id) t_affil
13             ON st.setk_id = t_affil.setk_id;
no rows selected
Elapsed: 00:09:15.90
SQL>
SQL> select * from table(dbms_xplan.display_cursor(null, null, 'ALLSTATS LAST'));
PLAN_TABLE_OUTPUT
SQL_ID 2rc9d2c83a7ak, child number 0
SELECT /*+ gather_plan_statistics */ st.*   FROM t_senttsk st INNER JOIN (WITH t_mrgdusr AS (SELECT DISTINCT usr_id
                           FROM t_usr                                                     WHERE NVL(usr_mrgemstr, usr_id) = :"SYS_B_0"
            /* i_payer_id */                                                                                               )
               SELECT t_senttsk.setk_id                                   FROM t_senttsk INNER JOIN t_mrgdusr
           ON t_senttsk.setk_affn_memb = t_mrgdusr.usr_id                                 UNION                                 SELECT
t_senttsk.setk_id                                   FROM t_senttsk INNER JOIN t_mrgdusr                                            ON
t_senttsk.setk_ownr = t_mrgdusr.usr_id) t_affil            ON st.setk_id = t_affil.setk_id
Plan hash value: 1065206678
| Id | Operation                         | Name                        | Starts | E-Rows | A-Rows |   A-Time   | Buffers | OMem | 1Mem | Used-Mem |
|   1 | NESTED LOOPS                     |                             |      1 |    169K|      0 |00:09:02.47 |    1514K|       |       |          |
|   2 |   TABLE ACCESS FULL               | T_SENTTSK                   |      1 |    136K|    136K|00:00:01.64 |    7062 |       |       |          |
|   3 |   VIEW                            |                             |    136K|      1 |      0 |00:09:00.54 |    1507K|       |       |          |
|   4 |    TEMP TABLE TRANSFORMATION      |                             |    136K|        |      0 |00:09:00.12 |    1507K|       |       |          |
|   5 |     LOAD AS SELECT                |                             |    136K|        |      0 |00:08:24.31 |     548K| 1024 | 1024 |          |
|   6 |      TABLE ACCESS BY INDEX ROWID | T_USR                       |    136K|      1 |      0 |00:00:06.12 |     410K|       |       |          |
|* 7 |       INDEX RANGE SCAN            | IX_NVL_USR_MRGEMSTR_USR_ID |    136K|      1 |      0 |00:00:05.41 |     410K|       |       |          |
|   8 |     SORT UNIQUE                   |                             |    136K|        |      0 |00:00:19.10 |     822K| 1024 | 1024 |          |
|   9 |      UNION-ALL PARTITION          |                             |    136K|        |      0 |00:00:17.40 |     822K|       |       |          |
| 10 |       NESTED LOOPS                |                             |    136K|      1 |      0 |00:00:08.02 |     411K|       |       |          |
| 11 |        TABLE ACCESS BY INDEX ROWID| T_SENTTSK                   |    136K|      1 |    136K|00:00:06.36 |     411K|       |       |          |
|* 12 |         INDEX UNIQUE SCAN         | PK_T_SENTTSK                |    136K|      1 |    136K|00:00:03.68 |     273K|       |       |          |
|* 13 |        VIEW                       |                             |    136K|      1 |      0 |00:00:01.03 |       0 |       |       |          |
| 14 |         TABLE ACCESS FULL         | SYS_TEMP_0FD9D6609_399116CE |    136K|      1 |      0 |00:00:00.67 |       0 |       |       |          |
| 15 |       NESTED LOOPS                |                             |    136K|      1 |      0 |00:00:06.54 |     411K|       |       |          |
|* 16 |        TABLE ACCESS BY INDEX ROWID| T_SENTTSK                   |    136K|      1 | 34256 |00:00:05.87 |     411K|       |       |          |
|* 17 |         INDEX UNIQUE SCAN         | PK_T_SENTTSK                |    136K|      1 |    136K|00:00:03.46 |     273K|       |       |          |
|* 18 |        VIEW                       |                             | 34256 |      1 |      0 |00:00:00.25 |       0 |       |       |          |
| 19 |         TABLE ACCESS FULL         | SYS_TEMP_0FD9D6609_399116CE | 34256 |      1 |      0 |00:00:00.16 |       0 |       |       |          |
Predicate Information (identified by operation id):
   7 - access("T_USR"."SYS_NC00127$"=:SYS_B_0)
12 - access("T_SENTTSK"."SETK_ID"="ST"."SETK_ID")
13 - filter("T_SENTTSK"."SETK_AFFN_MEMB"="T_MRGDUSR"."USR_ID")
16 - filter("T_SENTTSK"."SETK_OWNR" IS NOT NULL)
17 - access("T_SENTTSK"."SETK_ID"="ST"."SETK_ID")
18 - filter("T_SENTTSK"."SETK_OWNR"="T_MRGDUSR"."USR_ID")
hoek wrote:Does rewriting 'the heart of the issue' into like below make any difference?
select a.*
from   foo a
where exists ( select null
from   bar b
where a.foo_pk_id = b.foo_pk_id
and    b.some_col = :bind_var
The UNION in the subquery seems to make that difficult.

How to make single full scan

Hi, ALL
I have this query like below and I see that it produced 3 <TABLE ACCESS FULL> for each Unioin, how to make it work with single Scan? It's simple table 2 colums, not indexes or PK, just for sample.
explain plan for
select count(*) from tt where amt between 0 and 100 union all
select       count(*) from tt where amt between 100 and 200 union all
select       count(*) from tt where amt >200
| Id | Operation           | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT    |      |     3 |    39 |     9 (67)| 00:00:01 |
|   1 | UNION-ALL          |      |       |       |            |          |
|   2 |   SORT AGGREGATE    |      |     1 |    13 |            |          |
|* 3 |    TABLE ACCESS FULL| TT   |     2 |    26 |     3   (0)| 00:00:01 |
|   4 |   SORT AGGREGATE    |      |     1 |    13 |            |          |
|* 5 |    TABLE ACCESS FULL| TT   |     3 |    39 |     3   (0)| 00:00:01 |
|   6 |   SORT AGGREGATE    |      |     1 |    13 |            |          |
|* 7 |    TABLE ACCESS FULL| TT   |     3 |    39 |     3   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   3 - filter("AMT">=0 AND "AMT"<=100)
   5 - filter("AMT">=100 AND "AMT"<=200)
   7 - filter("AMT">200)
Note
   - dynamic sampling used for this statement

SQL> explain plan for
2 select count(*) from emp where sal between 0 and 100 union all
3 select       count(*) from emp where sal between 100 and 200 union all
4 select       count(*) from emp where sal > 200
5 /
Explained.
SQL> @?\rdbms\admin\utlxpls
PLAN_TABLE_OUTPUT
Plan hash value: 3840822464
| Id | Operation         | Name     | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |          |     3 |    12 |     3 (67)| 00:00:01 |
|   1 | UNION-ALL        |          |       |       |            |          |
|   2 |   SORT AGGREGATE |          |     1 |     4 |            |          |
|* 3 |    INDEX FULL SCAN| EMP_IDX3 |     1 |     4 |     1   (0)| 00:00:01 |
|   4 |   SORT AGGREGATE |          |     1 |     4 |            |          |
|* 5 |    INDEX FULL SCAN| EMP_IDX3 |     1 |     4 |     1   (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
|   6 |   SORT AGGREGATE |          |     1 |     4 |            |          |
|* 7 |    INDEX FULL SCAN| EMP_IDX3 |    14 |    56 |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   3 - access("SAL">=0 AND "SAL"<=100)
       filter("SAL"<=100 AND "SAL">=0)
   5 - access("SAL">=100 AND "SAL"<=200)
       filter("SAL"<=200 AND "SAL">=100)
PLAN_TABLE_OUTPUT
   7 - access("SAL">200)
       filter("SAL">200)
24 rows selected.
SQL> explain plan for
2 with t as (
3             select count(case when sal between 0 and 100 then 1 end) cnt1,
4                     count(case when sal between 100 and 200 then 1 end) cnt2,
5                     count(case when sal > 200 then 1 end) cnt3
6               from emp
7            )
8 select cnt1 from t union all
9 select cnt2 from t union all
10 select cnt3 from t
11 /
Explained.
SQL> @?\rdbms\admin\utlxpls
PLAN_TABLE_OUTPUT
Plan hash value: 2586840053
| Id | Operation                  | Name                        | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT           |                             |     3 |    39 |     6 (67)| 00:00:01 |
|   1 | TEMP TABLE TRANSFORMATION |                             |       |       |            |          |
|   2 |   LOAD AS SELECT           |                             |       |       |            |          |
|   3 |    SORT AGGREGATE          |                             |     1 |     4 |            |          |
|   4 |     TABLE ACCESS FULL      | EMP                         |    14 |    56 |     3   (0)| 00:00:01 |
|   5 |   UNION-ALL                |                             |       |       |            |          |
PLAN_TABLE_OUTPUT
|   6 |    VIEW                    |                             |     1 |    13 |     2   (0)| 00:00:01 |
|   7 |     TABLE ACCESS FULL      | SYS_TEMP_0FD9D662A_D5091620 |     1 |     4 |     2   (0)| 00:00:01 |
|   8 |    VIEW                    |                             |     1 |    13 |     2   (0)| 00:00:01 |
|   9 |     TABLE ACCESS FULL      | SYS_TEMP_0FD9D662A_D5091620 |     1 |     4 |     2   (0)| 00:00:01 |
| 10 |    VIEW                    |                             |     1 |    13 |     2   (0)| 00:00:01 |
| 11 |     TABLE ACCESS FULL      | SYS_TEMP_0FD9D662A_D5091620 |     1 |     4 |     2   (0)| 00:00:01 |
18 rows selected.
SQL> SY.

Why "full scans are not evil, indexes are not good"

in this article inside asktom page
http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:9422487749968
tell about "full scans are not evil, indexes are not good"
someone tell me why for this select mentioned index are not good?

...and if you read next post, nothing is black or white, it is all shades of grey .
This is not because your query will use index that it would be faster, and the example which Tom gave is really explicit :
With index usage 60127 consistent gets, and without index usage 92 consistent gets
Nicolas.
Message was edited by:
N. Gasparotto

Full Scan on table

The following query takes for ever to run and it goes into full scan on the job_det_line table which has abt 2 million records. Any suggestions on how to optimize it?
SELECT DISTINCT to_skid_allocation.get_truck(bb.truck_locator_id) truck,
to_char(bb.bol_id) bol,
to_skid_allocation.get_ship_to_dest(bb.ship_to_id) dest,
to_char(BS.SKID_ID) skidid,
ddps.INVENTORY_ITEM_ID iid,
to_custom_selection.get_item(102,ddps.INVENTORY_ITEM_ID) Selection,
to_skid_allocation.get_skid_item_qty(BS.SKID_ID,ddps.INVENTORY_ITEM_ID) qty,
to_custom_selection.get_title(jdl.inventory_item_id) Jot_title,
ddpc.job_number djobnum,
jdl.job_num jotjobnum
FROM tor.job_det_line jdl,
tor.dvd_disc_print_supply ddps,
tor.dvd_disc_print_carton ddpc,
tor.bulk_skid bs,
tor.bulk_bol bb
where bs.bol_id_ref = bb.BOL_ID
and ddpc.skid_id_ref = bs.SKID_ID
and ddpc.DISC_PRINT_ID = ddps.DISC_PRINT_ID
and bb.status = 2
and bb.ship_to_id in ( 41 , 885900)
and ( jdl.job_num = dvd_disc_txn_pkg.get_jot_x_ref(ddpc.job_number) or jdl.job_num in
select jdl.job_num
FROM apps.mtl_system_items msi,
apps.mtl_system_items msi2,
apps.bom_bill_of_materials bbm,
apps.bom_inventory_components bic,
tor.job_det_line jdl
WHERE msi.inventory_item_id = ddps.INVENTORY_ITEM_ID
AND msi.organization_id = 102
AND msi.organization_id = bbm.organization_id
AND msi.organization_id = msi2.organization_id
AND msi.inventory_item_id = bic.component_item_id
AND bic.bill_sequence_id = bbm.bill_sequence_id
AND bbm.assembly_item_id = msi2.inventory_item_id
and jdl.bill_sequence_id = bbm.bill_sequence_id and
jdl.alternate_bom_designator = bbm.alternate_bom_designator
and jdl.inventory_item_id = msi2.inventory_item_id ) )

Please post your query in proper format. It is very disturbing to get such unformatted code.
Regards.
Satyaki De.

Firefox 3.6.12 won't open under WinXP. Have uninstalled/reinstalled several times. When I start the program (including safe mode) I see a Firefox process appear for about 3 seconds, then disappear. Run full scan with Norton with no malware discovered.

I've used Firefox for years with no problems. I've not installed any new extensions or programs between the time it worked great and when the problem began.
I click to start FF (shortcut, directly on program file, etc.) and I get an hourglass for a couple of seconds like it's starting, then nada. As mentioned, I see FF show up as a process in Task Manager for about 3 seconds, then disappear.
Solutions I've tried include: Uninstall/reinstall on the same drive and a separate drive, registry cleanup/optimization w/Norton Utilities, full scan for malware/viruses with Norton, stopping some autostartup programs that were installed and in use while FF was running fine.

I've used Firefox for years with no problems. I've not installed any new extensions or programs between the time it worked great and when the problem began.
I click to start FF (shortcut, directly on program file, etc.) and I get an hourglass for a couple of seconds like it's starting, then nada. As mentioned, I see FF show up as a process in Task Manager for about 3 seconds, then disappear.
Solutions I've tried include: Uninstall/reinstall on the same drive and a separate drive, registry cleanup/optimization w/Norton Utilities, full scan for malware/viruses with Norton, stopping some autostartup programs that were installed and in use while FF was running fine.

How can I avoid a full scan when ...

Hello
How can I avoid a full scan with I apply the aggregate function "MIN"
SQL> select min(c1) from hh;
   MIN(C1)
         1
Execution Plan
   0      SELECT STATEMENT Optimizer=CHOOSE
   1    0   SORT (AGGREGATE)
   2    1     TABLE ACCESS (FULL) OF 'HH'Regards
James King

The table 'hh' does not have statistics. Assuming that there is an index on the column c1, statistics are computed on the table and its indexes, you may see a
INDEX (FULL SCAN (MIN/MAX)) of the index on column 'c1'.

How do I see the full SQLl/Query text of a spid?

How do I see the full SQLl/Query text of a spid?
I use different ways to get the query, the problem is it truncates the end, so I cannot see the entire query/sql text. Is there another way to a query/sql text that is being run?
Please mark solved if I've answered your question, vote for it as helpful to help other users find a solution quicker
Praveen Dsa | MCITP - Database Administrator 2008 |
My Blog | My Page

IF @@TRANCOUNT > 0 COMMIT TRAN
What i want to see is the entire batch.
It means this was the last batch submitted by client. You can try below as well.
SELECT s.session_id,
r.status,
r.blocking_session_id 'Blk by',
r.wait_type,
wait_resource,
r.wait_time / (1000.0) 'Wait Sec',
r.cpu_time,
r.logical_reads,
r.reads,
r.writes,
r.total_elapsed_time / (1000.0) 'Elaps Sec',
Substring(st.TEXT,(r.statement_start_offset / 2) + 1,
((CASE r.statement_end_offset
WHEN -1
THEN Datalength(st.TEXT)
ELSE r.statement_end_offset
END - r.statement_start_offset) / 2) + 1) AS statement_text,
Coalesce(Quotename(Db_name(st.dbid)) + N'.' + Quotename(Object_schema_name(st.objectid,st.dbid)) + N'.' + Quotename(Object_name(st.objectid,st.dbid)),
'') AS command_text,
r.command,
s.login_name,
s.host_name,
s.program_name,
s.last_request_end_time,
s.login_time,
r.open_transaction_count
FROM sys.dm_exec_sessions AS s
JOIN sys.dm_exec_requests AS r
ON r.session_id = s.session_id
CROSS APPLY sys.Dm_exec_sql_text(r.sql_handle) AS st
WHERE r.session_id != @@SPID
ORDER BY r.cpu_time desc, r.status,
r.blocking_session_id,
s.session_id
Balmukund Lakhani
Please mark solved if I've answered your question, vote for it as helpful to help other users find a solution quicker
This posting is provided "AS IS" with no warranties, and confers no rights.
My Blog |
Team Blog | @Twitter
| Facebook
Author: SQL Server 2012 AlwaysOn -
Paperback, Kindle

Monitors: SQL Server: Access Methods: Full Scans/sec

Hello,
I created a Monitor:
Monitors: SQL Server: Access Methods:
Full Scans/sec
It appears in Heath explorer on the servers
but is not available in the Performance Data for the Views...
What did I miss? I need to create a rule but which type ? linked to the monitor?
Should I use a Rule or a Monitor or a combination?
Thanks,
Dom
System Center
Operations Manager 2007 / System Center
Configuration Manager 2007 R2 /
Forefront Client Security
/ Forefront Identity Manager

Hello,
I got on the servers the
1200:New Management Pack(s) requested. Management group "SCOM-MED", configuration id:"68 D8 86 93 7A 48 27 13 C0 6F B2 76 3C A4 07 87 DA 53 22 7F ".
1201:New Management Pack with id:"xxxx.SQL.Servers", version:"1.0.0.1" received.
1207... Rule/Monitor "Microsoft.Windows.SystemCenterDPM.DPMServerDiscovery" running for remote instance "MSQLCL1SQLBU.ad.medctr.ucla.edu" with id:"{A3100D57-1657-A51E-CD3E-6ACF2679A501}" will be disabled as it is not remotable.
Management group "SCOM-MED".
1210 New configuration became active. Management group "SCOM-MED", configuration id:"68 D8 86 93 7A 48 27 13 C0 6F B2 76 3C A4 07 87 DA 53 22 7F ".
still waiting ...
1204: Management Pack with id:"xxxx.SQL.Servers", version:"1.0.0.1" is no longer used by HealthService and will be deleted from cache.
Is this 1204 okay !!!!!
Thanks,
Dom
System Center Operations Manager 2007 / System Center Configuration Manager 2007 R2 / Forefront Client Security / Forefront Identity Manager

I still get a firefox security alert that my system affected by numerous virus attack even after I performed a full scan using microsoft security essential. what is the problem?

I get a firefox security alert that my system affected by numerous virus attack. I performed a full scan using microsoft security essential immediately but same message still pop up after that even though no virus was found during the scan.

You may be visiting a web site that has been infected or is hosting malware.<br />
You should never respond unrequested pop-ups that try to persuade you to download and install software.<br />
Doing that is the way to get malware because no decent company would use such methods to inform you about that.<br />
You only saw an animation and not a real scan.<br />

Full scan query

Similar Messages

Maybe you are looking for