To improve the query???

Example:
select money,sum(total),sum(amount),sum(credit), sum(total_im), sum(total_am)
from account group by money;
The problem is: The function sum -> because "TABLE ACCESS FULL" of the table account.
How to improve the query? Without to create an index for each column (sum).
Regards.

user9331221 wrote:
How to improve the query?There is not much room for improvement. The select statement has to compute those five aggregates. It cannot do that without reading the entire table. So a TABLE ACCESS FULL is almost necessary. The only option (besides Keith's materialized view suggestion) is to create an index on (money,total,amount,credit,total_im,total_am) in which case this statement can do a full index scan. But this is only advantageous for your query when the table contains lots of other columns that make the table relatively big compared to the index. And the obvious disadvantage is that you now have an extra index to maintain during DML.
Regards,
Rob.
Edited by: Rob van Wijk on 9-sep-2010 13:34

Similar Messages

How to improve the query performance in to report level and designer level

How to improve the query performance in to report level and designer level......?
Plz let me know the detail view......

first its all based on the design of the database, universe and the report.
at the universe Level, you have to check your Contexts very well to get the optimal performance of the universe and also your joins, keep your joins with key fields, will give you the best performance.
at the report level, try to make the reports dynamic as much as you can, (Parameters) and so on.
and when you create a paremeter try to get it match with the key fields in the database.
good luck
Amr

How to improve the query performance

ALTER PROCEDURE [SPNAME]
@Portfolio INT,
@Program INT,
@Project INT
AS
BEGIN
--DECLARE @StartDate DATETIME
--DECLARE @EndDate DATETIME
--SET @StartDate = '11/01/2013'
--SET @EndDate = '02/28/2014'
IF OBJECT_ID('tempdb..#Dates') IS NOT NULL
DROP TABLE #Dates
IF OBJECT_ID('tempdb..#DailyTasks') IS NOT NULL
DROP TABLE #DailyTasks
CREATE TABLE #Dates(WorkDate DATE)
--CREATE INDEX IDX_Dates ON #Dates(WorkDate)
;WITH Dates AS
SELECT (@StartDate) DateValue
UNION ALL
SELECT DateValue + 1
FROM Dates
WHERE DateValue + 1 <= @EndDate
INSERT INTO #Dates
SELECT DateValue
FROM Dates D
LEFT JOIN tb_Holidays H
ON H.HolidayOn = D.DateValue
AND H.OfficeID = 2
WHERE DATEPART(dw,DateValue) NOT IN (1,7)
AND H.UID IS NULL
OPTION(MAXRECURSION 0)
SELECT TSK.TaskID,
TR.ResourceID,
WC.WorkDayCount,
(TSK.EstimateHrs/WC.WorkDayCount) EstimateHours,
D.WorkDate,
TSK.ProjectID,
RES.ResourceName
INTO #DailyTasks
FROM Tasks TSK
INNER JOIN TasksResource TR
ON TSK.TaskID = TR.TaskID
INNER JOIN tb_Resource RES
ON TR.ResourceID=RES.UID
OUTER APPLY (SELECT COUNT(*) WorkDayCount
FROM #Dates
WHERE WorkDate BETWEEN TSK.StartDate AND TSK.EndDate)WC
INNER JOIN #Dates D
ON WorkDate BETWEEN TSK.StartDate AND TSK.EndDate
-------WHERE TSK.ProjectID = @Project-----
SELECT D.ResourceID,
D.WorkDayCount,
SUM(D.EstimateHours/D.WorkDayCount) EstimateHours,
D.WorkDate,
T.TaskID,
D.ResourceName
FROM #DailyTasks D
OUTER APPLY (SELECT (SELECT CAST(TaskID AS VARCHAR(255))+ ','
FROM #DailyTasks DA
WHERE D.WorkDate = DA.WorkDate
AND D.ResourceID = DA.ResourceID
FOR XML PATH('')) AS TaskID) T
LEFT JOIN tb_Project PRJ
ON D.ProjectID=PRJ.UID
INNER JOIN tb_Program PR
ON PRJ.ProgramID=PR.UID
INNER JOIN tb_Portfolio PF
ON PR.PortfolioID=PF.UID
WHERE (@Portfolio = -1 or PF.UID = @Portfolio)
AND (@Program = -1 or PR.UID = @Program)
AND (@Project = -1 or PRJ.UID = @Project)
GROUP BY D.ResourceID,
D.WorkDate,
T.TaskID,
D.WorkDayCount,
D.ResourceName
HAVING SUM(D.EstimateHours/D.WorkDayCount) > 8
hi..
My SP is as above..
I connected this SP to dataset in SSRS report..as per my logic..Portfolio contains many Programs and Program contains many Projects.
When i selected the ALL value for parameters Program and Project..i'm unable to get output.
but when i select values for all 3 parameters i'm getting output. i took default values for paramters also.
so i commented the where condition in SP as shown above
--------where TSK.ProjectID=@Project-------------
now i'm getting output when selecting ALL value for parameters.
but here the issue is performance..it takes 10sec to retrieve for single project when i'm executing the sp.
how can i create index on temp table in this sp and how can i improve the query performance..
please help.
thanks in advance..
lucky

Didnt i provide you solution in other thread?
ALTER PROCEDURE [SPNAME]
@Portfolio INT,
@Program INT,
@Project INT
AS
BEGIN
--DECLARE @StartDate DATETIME
--DECLARE @EndDate DATETIME
--SET @StartDate = '11/01/2013'
--SET @EndDate = '02/28/2014'
IF OBJECT_ID('tempdb..#Dates') IS NOT NULL
DROP TABLE #Dates
IF OBJECT_ID('tempdb..#DailyTasks') IS NOT NULL
DROP TABLE #DailyTasks
CREATE TABLE #Dates(WorkDate DATE)
--CREATE INDEX IDX_Dates ON #Dates(WorkDate)
;WITH Dates AS
SELECT (@StartDate) DateValue
UNION ALL
SELECT DateValue + 1
FROM Dates
WHERE DateValue + 1 <= @EndDate
INSERT INTO #Dates
SELECT DateValue
FROM Dates D
LEFT JOIN tb_Holidays H
ON H.HolidayOn = D.DateValue
AND H.OfficeID = 2
WHERE DATEPART(dw,DateValue) NOT IN (1,7)
AND H.UID IS NULL
OPTION(MAXRECURSION 0)
SELECT TSK.TaskID,
TR.ResourceID,
WC.WorkDayCount,
(TSK.EstimateHrs/WC.WorkDayCount) EstimateHours,
D.WorkDate,
TSK.ProjectID,
RES.ResourceName
INTO #DailyTasks
FROM Tasks TSK
INNER JOIN TasksResource TR
ON TSK.TaskID = TR.TaskID
INNER JOIN tb_Resource RES
ON TR.ResourceID=RES.UID
OUTER APPLY (SELECT COUNT(*) WorkDayCount
FROM #Dates
WHERE WorkDate BETWEEN TSK.StartDate AND TSK.EndDate)WC
INNER JOIN #Dates D
ON WorkDate BETWEEN TSK.StartDate AND TSK.EndDate
WHERE (TSK.ProjectID = @Project OR @Project = -1)
SELECT D.ResourceID,
D.WorkDayCount,
SUM(D.EstimateHours/D.WorkDayCount) EstimateHours,
D.WorkDate,
T.TaskID,
D.ResourceName
FROM #DailyTasks D
OUTER APPLY (SELECT (SELECT CAST(TaskID AS VARCHAR(255))+ ','
FROM #DailyTasks DA
WHERE D.WorkDate = DA.WorkDate
AND D.ResourceID = DA.ResourceID
FOR XML PATH('')) AS TaskID) T
LEFT JOIN tb_Project PRJ
ON D.ProjectID=PRJ.UID
INNER JOIN tb_Program PR
ON PRJ.ProgramID=PR.UID
INNER JOIN tb_Portfolio PF
ON PR.PortfolioID=PF.UID
WHERE (@Portfolio = -1 or PF.UID = @Portfolio)
AND (@Program = -1 or PR.UID = @Program)
AND (@Project = -1 or PRJ.UID = @Project)
GROUP BY D.ResourceID,
D.WorkDate,
T.TaskID,
D.WorkDayCount,
D.ResourceName
HAVING SUM(D.EstimateHours/D.WorkDayCount) > 8
Please Mark This As Answer if it helps to solve the issue Visakh ---------------------------- http://visakhm.blogspot.com/ https://www.facebook.com/VmBlogs

Improve the query's performance

Hi Guys,
I'm an Oracle beginner and I'm getting the following issue:
I have to run a query with a join between two tables, let me say A and B.
The table A has 10 Milions of records (800MB) and is indexed on two columns (a1 and a2).
The table B has 100000 records (64MB) no index.
The query is:
select
A.a1,
A.a2,
B.b1
from A,B
where A.a1 >= B.b1 and A.a2<=B.b1
The problem is that it is really slow (more that 1 day) although the execution plan used is NESTED LOOPS.
How can I improve the performance of this query?
Please help me,
GF

Hi Guys,
First of all thank you very much for your prompt response.
devmiral your advise could help me. I have just realized that the statistic have never been updated.
I'll try to update it and let you know.
Eric here is an quick example:
Table A Table B
a2 a1 a3 b1
10 14 1 10
15 16 2 11
18 19 3 15
20 21 4
The query is:
select
A.a2,
A.a1,
A.a3,
B.b1
from A,B
where A.a1 >= B.b1 and A.a2<=B.b1
The output expected should be:
a2 a1 a3 b1
10 14 1 10
10 14 1 11
15 16 2 15
Thank you
GF

Improve the query performance

Hi, I need help for improving query performance..
I have a query in which i am joining 2 tables, join after some aggregation. Both table has more than 50 million record.
There is no index created on these table,both tables are loaded after truncation. So is it required to create index on this table before joining? The query status was showing 'suspended' since it was running for long time. For temporary purpose, i just executed
the query multiple times by changing month filter each times.
How can i improve this instead of adding month filter and running multiple times

Hi Nikkred,
According to your description, you are joining 2 table which contain more than 50 million records. Now what you want is improving query performance, right?
Query tuning is not an easy task. Basically it depends on three factors: your degree of knowledge, the query itself and the amount of optimization required. So in your scenario, you can post your detail query, so that you can get more help. Besides, you
can create index on your table which can improve the performance. Here are some links about performance tuning tips for you reference.
http://www.mssqltips.com/sql-server-tip-category/9/performance-tuning/
http://www.infoworld.com/d/data-management/7-performance-tips-faster-sql-queries-262
Regards,
Charlie Liao
TechNet Community Support

How to improve the query performance or tune query from Explain Plan

Hi
The following is my explain plan for sql query. (The plan is generated by Toad v9.7). How to fix the query?
SELECT STATEMENT ALL_ROWSCost: 4,160 Bytes: 25,296 Cardinality: 204
     8 NESTED LOOPS Cost: 3 Bytes: 54 Cardinality: 1
          5 NESTED LOOPS Cost: 2 Bytes: 23 Cardinality: 1
               2 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 13 Cardinality: 1
                    1 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
               4 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_ACCOUNTS Cost: 1 Bytes: 10 Cardinality: 1
                    3 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 1 Cardinality: 1
          7 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_PARTIES Cost: 1 Bytes: 31 Cardinality: 1
               6 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_PARTIES_U1 Cost: 1 Cardinality: 1
     10 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
          9 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
     15 NESTED LOOPS Cost: 2 Bytes: 29 Cardinality: 1
          12 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
               11 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
          14 TABLE ACCESS BY INDEX ROWID TABLE ONT.OE_ORDER_HEADERS_ALL Cost: 1 Bytes: 17 Cardinality: 1
               13 INDEX RANGE SCAN INDEX (UNIQUE) ONT.OE_ORDER_HEADERS_U2 Cost: 1 Cardinality: 1
     21 FILTER
          16 TABLE ACCESS FULL TABLE ONT.OE_TRANSACTION_TYPES_TL Cost: 2 Bytes: 1,127 Cardinality: 49
          20 NESTED LOOPS Cost: 2 Bytes: 21 Cardinality: 1
               18 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
                    17 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
               19 INDEX RANGE SCAN INDEX (UNIQUE) ONT.OE_ORDER_HEADERS_U2 Cost: 1 Bytes: 9 Cardinality: 1
     23 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
          22 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
     45 NESTED LOOPS Cost: 4,160 Bytes: 25,296 Cardinality: 204
          42 NESTED LOOPS Cost: 4,150 Bytes: 23,052 Cardinality: 204
               38 NESTED LOOPS Cost: 4,140 Bytes: 19,992 Cardinality: 204
                    34 NESTED LOOPS Cost: 4,094 Bytes: 75,850 Cardinality: 925
                         30 NESTED LOOPS Cost: 3,909 Bytes: 210,843 Cardinality: 3,699
                              26 PARTITION LIST ALL Cost: 2,436 Bytes: 338,491 Cardinality: 14,717 Partition #: 29 Partitions accessed #1 - #18
                                   25 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_AE_HEADERS Cost: 2,436 Bytes: 338,491 Cardinality: 14,717 Partition #: 29 Partitions accessed #1 - #18
                                        24 INDEX SKIP SCAN INDEX XLA.XLA_AE_HEADERS_N1 Cost: 264 Cardinality: 1,398,115 Partition #: 29 Partitions accessed #1 - #18
                              29 PARTITION LIST ITERATOR Cost: 1 Bytes: 34 Cardinality: 1 Partition #: 32
                                   28 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_AE_LINES Cost: 1 Bytes: 34 Cardinality: 1 Partition #: 32
                                        27 INDEX RANGE SCAN INDEX (UNIQUE) XLA.XLA_AE_LINES_U1 Cost: 1 Cardinality: 1 Partition #: 32
                         33 PARTITION LIST ITERATOR Cost: 1 Bytes: 25 Cardinality: 1 Partition #: 35
                              32 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_DISTRIBUTION_LINKS Cost: 1 Bytes: 25 Cardinality: 1 Partition #: 35
                                   31 INDEX RANGE SCAN INDEX XLA.XLA_DISTRIBUTION_LINKS_N3 Cost: 1 Cardinality: 1 Partition #: 35
                    37 PARTITION LIST SINGLE Cost: 1 Bytes: 16 Cardinality: 1 Partition #: 38
                         36 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_EVENTS Cost: 1 Bytes: 16 Cardinality: 1 Partition #: 39 Partitions accessed #2
                              35 INDEX UNIQUE SCAN INDEX (UNIQUE) XLA.XLA_EVENTS_U1 Cost: 1 Cardinality: 1 Partition #: 40 Partitions accessed #2
               41 PARTITION LIST SINGLE Cost: 1 Bytes: 15 Cardinality: 1 Partition #: 41
                    40 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_TRANSACTION_ENTITIES Cost: 1 Bytes: 15 Cardinality: 1 Partition #: 42 Partitions accessed #2
                         39 INDEX UNIQUE SCAN INDEX (UNIQUE) XLA.XLA_TRANSACTION_ENTITIES_U1 Cost: 1 Cardinality: 1 Partition #: 43 Partitions accessed #2
          44 TABLE ACCESS BY INDEX ROWID TABLE GL.GL_CODE_COMBINATIONS Cost: 1 Bytes: 11 Cardinality: 1
               43 INDEX UNIQUE SCAN INDEX (UNIQUE) GL.GL_CODE_COMBINATIONS_U1 Cost: 1 Cardinality: 1

damorgan wrote:
Tuning is NOT about reducing the cost of i/o.
i/o is only one of many contributors to cost and only one of many contributors to waits.
Any time you would like to explore this further run this code:
SELECT 1 FROM dual
WHERE regexp_like(' ','^*[ ]*a');but not on a production box because you are going to experience an extreme tuning event with zero i/o.
And when I say "extreme" I mean "EXTREME!"
You've been warned.I think you just need a faster server.
SQL> set autotrace traceonly statistics
SQL> set timing on
SQL> select 1 from dual
2 where
3 regexp_like   (' ','^*[ ]*a');
no rows selected
Elapsed: 00:00:00.00
Statistics
          1 recursive calls
          0 db block gets
          0 consistent gets
          0 physical reads
          0 redo size
        243 bytes sent via SQL*Net to client
        349 bytes received via SQL*Net from client
          1 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          0 rows processedRepeated from an Oracle 10.2.0.x instance:
SQL> SELECT DISTINCT SID FROM V$MYSTAT;
       SID
       310
SQL> ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';
Session altered.
SQL> select 1 from dual
2 where
3 regexp_like   (' ','^*[ ]*a');The session is hung. Wait a little while and connect to the database using a different session:
COLUMN STAT_NAME FORMAT A35 TRU
SET PAGESIZE 200
SELECT
STAT_NAME,
VALUE
FROM
V$SESS_TIME_MODEL
WHERE
SID=310;
STAT_NAME                                VALUE
DB time                                   9247
DB CPU                                    9247
background elapsed time                      0
background cpu time                          0
sequence load elapsed time                   0
parse time elapsed                        6374
hard parse elapsed time                   5997
sql execute elapsed time                  2939
connection management call elapsed        1660
failed parse elapsed time                    0
failed parse (out of shared memory)          0
hard parse (sharing criteria) elaps          0
hard parse (bind mismatch) elapsed           0
PL/SQL execution elapsed time               95
inbound PL/SQL rpc elapsed time              0
PL/SQL compilation elapsed time              0
Java execution elapsed time                  0
repeated bind elapsed time                  48
RMAN cpu time (backup/restore)               0Seems to be using a bit of time for the hard parse (hard parse elapsed time). Wait a little while, then re-execute the query:
STAT_NAME                                VALUE
DB time                                   9247
DB CPU                                    9247
background elapsed time                      0
background cpu time                          0
sequence load elapsed time                   0
parse time elapsed                        6374
hard parse elapsed time                   5997
sql execute elapsed time                  2939
connection management call elapsed        1660
failed parse elapsed time                    0
failed parse (out of shared memory)          0
hard parse (sharing criteria) elaps          0
hard parse (bind mismatch) elapsed           0
PL/SQL execution elapsed time               95
inbound PL/SQL rpc elapsed time              0
PL/SQL compilation elapsed time              0
Java execution elapsed time                  0
repeated bind elapsed time                  48
RMAN cpu time (backup/restore)               0The session is not reporting additional CPU usage or parse time.
Let's check one of the session's statistics:
SELECT
SS.VALUE
FROM
V$SESSTAT SS,
V$STATNAME SN
WHERE
SN.NAME='consistent gets'
AND SN.STATISTIC#=SS.STATISTIC#
AND SS.SID=310;
     VALUE
       163Not many consistent gets after 20+ minutes.
Let's take a look at the plan:
SQL> SELECT SQL_ID,CHILD_NUMBER FROM V$SQL WHERE SQL_TEXT LIKE 'select 1 from du
al%';
SQL_ID        CHILD_NUMBER
04mpgrzhsv72w            0
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('04mpgrzhsv72w',0,'TYPICAL'))
select 1 from dual where regexp_like   (' ','^*[ ]*a')
NOTE: cannot fetch plan for SQL_ID: 04mpgrzhsv72w, CHILD_NUMBER: 0
      Please verify value of SQL_ID and CHILD_NUMBER;
      It could also be that the plan is no longer in cursor cache (check v$sql_p
lan)No plan...
Let's take a look at the 10053 trace file:
Registered qb: SEL$1 0x19157f38 (PARSER)
signature (): qb_name=SEL$1 nbfros=1 flg=0
    fro(0): flg=4 objn=258 hint_alias="DUAL"@"SEL$1"
Predicate Move-Around (PM)
PM: Considering predicate move-around in SEL$1 (#0).
PM:   Checking validity of predicate move-around in SEL$1 (#0).
CBQT: Validity checks failed for 7uqx4guu04x3g.
CVM: Considering view merge in query block SEL$1 (#0)
CBQT: Validity checks failed for 7uqx4guu04x3g.
Subquery Unnest
SU: Considering subquery unnesting in query block SEL$1 (#0)
Set-Join Conversion (SJC)
SJC: Considering set-join conversion in SEL$1 (#0).
Predicate Move-Around (PM)
PM: Considering predicate move-around in SEL$1 (#0).
PM:   Checking validity of predicate move-around in SEL$1 (#0).
PM:     PM bypassed: Outer query contains no views.
FPD: Considering simple filter push in SEL$1 (#0)
FPD:   Current where clause predicates in SEL$1 (#0) :
          REGEXP_LIKE (' ','^*[ ]*a')
kkogcp: try to generate transitive predicate from check constraints for SEL$1 (#0)
predicates with check contraints: REGEXP_LIKE (' ','^*[ ]*a')
after transitive predicate generation: REGEXP_LIKE (' ','^*[ ]*a')
finally: REGEXP_LIKE (' ','^*[ ]*a')
apadrv-start: call(in-use=592, alloc=16344), compile(in-use=37448, alloc=42256)
kkoqbc-start
            : call(in-use=592, alloc=16344), compile(in-use=38336, alloc=42256)
kkoqbc-subheap (create addr=000000001915C238)Looks like the query never had a chance to start executing - it is still parsing after 20 minutes.
I am not sure that this is a good example - the query either executes very fast, or never has a chance to start executing. But, it might still make your point physical I/O is not always the problem when performance problems are experienced.
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

Select Statement taking more time.How to improve the query performance.

SELECT DISTINCT ORDERKEY, SUM(IMPRESSIONCNT) AS ActualImpressions ,SUM(DiscountedSales)AS ActualRevenue ,SUM(AgencyCommAmt) as AgencyCommAmt
,SUM(SalesHouseCommAMT) as SalesHouseCommAMT
--INTO Anticiapted_ADXActualsMeasures
FROM AdRevenueFact_ADX ADx WITH(NOLOCK)
Where FiscalMonthkey >=201301 and Exists (Select 1 from Anticipated_cdr_AX_OrderItem OI Where Adx.Orderkey=Oi.Orderkey)
GROUP BY ORDERKEY
Clustered indexes on orderkey,fiscalmonthkey and orderkey in AdRevenueFact_ADX(contain more than 170 million rows)
thanks

As mentioned by Kalman, if your clustered index starts with Orderkey, then this query will require a full table scan. If it is an option to change the clustered index in such a way that FiscalMonthkey is the leading column, then only the data of the last
two year has to be queried.
In addition, you should have a look at the indexes of table Anticipated_cdr_AX_OrderItem. Ideally, there is a nonclustered index on Orderkey.
To get better advice, please post the query plan and list all available indexes of these tables.
Finally, an off topic remark: it is a good practice to keep consistent spelling of object names, and to keep the same spelling as their declaration. Your query would cause serious problems if the database is ever run with case sensitive collation.
Gert-Jan

How to eleminate the co-releated Subquery to improve the query performance

Please find the query below which takes long time to fetch the records.
SQL> SET LINE 120
SQL> EXPLAIN PLAN FOR select *
2                 from KEMP_SRC a1
3                 where ('MOFF' is null or eq_name = 'MOFF')
4                       and
5                         is_ad_hoc <> 1
6                         and (pb_proc_id is null
7                         or pb_proc_id in (select proc_id from KEMP_CONFIG where frequency_type <> -1)
8                         )
9                    and     KEMPUtility.DTTM(end_dt, end_tm) in      (select max(KEMPUtility.DTTM(end_dt, end_tm))
10                                from KEMP_SRC a2
11                                where a2.eq_name = a1.eq_name
12                                and (a2.pb_proc_id = a1.pb_proc_id or (a2.pb_proc_id is null and a1.pb_proc_id is null))
13                                and a2.is_ad_hoc <> -1 -- repeating case
14                                group by eq_name, pb_proc_id
15                                );
Explained.
SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY());
PLAN_TABLE_OUTPUT
Plan hash value: 2624956131
| Id | Operation             | Name                      | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT      |                           |     1 |    96 | 69399   (3)| 00:13:53 |
|* 1 | FILTER               |                           |       |       |            |          |
|* 2 |   TABLE ACCESS FULL   | KEMP_SRC                  | 2896 |   271K|   124   (2)| 00:00:02 |
|* 3 |   TABLE ACCESS FULL   | KEMP_CONFIG               |     1 |    26 |     2   (0)| 00:00:01 |
|* 4 |    FILTER             |                           |       |       |            |          |
|   5 |     HASH GROUP BY     |                           |     1 |    35 |   125   (3)| 00:00:02 |
PLAN_TABLE_OUTPUT
|* 6 |      TABLE ACCESS FULL| KEMP_SRC               |   364 | 12740 |   124   (2)| 00:00:02 |
Predicate Information (identified by operation id):
   1 - filter(("PB_PROC_ID" IS NULL OR EXISTS (SELECT /*+ */ 0 FROM
              "KEMP_CONFIG" "KEMP_CONFIG" WHERE "PROC_ID"=:B1 AND
              "FREQUENCY_TYPE"<>(-1))) AND EXISTS (SELECT /*+ */ 0 FROM "KEMP_SRC" "A2" WHERE
              "A2"."EQ_NAME"=:B2 AND ("A2"."PB_PROC_ID"=:B3 OR :B4 IS NULL AND "A2"."PB_PROC_ID" IS
              NULL) AND "A2"."IS_AD_HOC"<>(-1) GROUP BY "EQ_NAME","PB_PROC_ID" HAVING
PLAN_TABLE_OUTPUT
              "KEMPUtility"."DTTM"(:B5,:B6)=MAX("KEMPUtility"."DTTM"("END_DT","END_TM"))))
   2 - filter("EQ_NAME"='BILAN_MAZOUT_BFOE' AND "IS_AD_HOC"<>1)
   3 - filter("PROC_ID"=:B1 AND "FREQUENCY_TYPE"<>(-1))
   4 - filter("KEMPUtility"."DTTM"(:B1,:B2)=MAX("KEMPUtility"."DTTM"("END_DT","END_TM")))
   6 - filter("A2"."EQ_NAME"=:B1 AND ("A2"."PB_PROC_ID"=:B2 OR :B3 IS NULL AND
              "A2"."PB_PROC_ID" IS NULL) AND "A2"."IS_AD_HOC"<>(-1))
28 rows selected.

When i comment the reference to a1 in the subquery , then the cost drastically reduced .
select *
2                 from KEMP_SRC a1
3                 where ('MOFF' is null or eq_name = 'MOFF')
4                       and
5                         is_ad_hoc != 1
6                         and (pb_proc_id is null
7                         or pb_proc_id in (select proc_id from KEMP_CONFIG where frequency_type -1)
8                         )
9                    and     KEMPUtility.DTTM(end_dt, end_tm) in      (select max(KEMPUtility.DTTM(end_dt, end_tm))
10                                from KEMP_SRC a2
11                                where
                                             -- a2.eq_name = a1.eq_name
12                            --    and (a2.pb_proc_id = a1.pb_proc_id or (a2.pb_proc_id is null and a1.pb_proc_id is null))
13                                --and
                                             a2.is_ad_hoc != -1 -- repeating case
14                                group by eq_name, pb_proc_id
15                                );
PLAN_TABLE_OUTPUT
Plan hash value: 3739658629
| Id | Operation              | Name                      | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT       |                           |    78 | 8190 |   249   (3)| 00:00:03 |
|* 1 | FILTER                |                           |       |       |            |          |
|* 2 |   HASH JOIN            |                           |   203 | 21315 |   249   (3)| 00:00:03 |
|   3 |    VIEW                | VW_NSO_1                  |     7 |    63 |   125   (3)| 00:00:02 |
|   4 |     HASH UNIQUE        |                           |     7 |   245 |   125   (3)| 00:00:02 |
|   5 |      HASH GROUP BY     |                           |     7 |   245 |   125   (3)| 00:00:02 |
PLAN_TABLE_OUTPUT
|* 6 |       TABLE ACCESS FULL| KEMP_SRC               | 2896 |    98K|   124   (2)| 00:00:02 |
|* 7 |    TABLE ACCESS FULL   | KEMP_SRC               | 2896 |   271K|   124   (2)| 00:00:02 |
|* 8 |   TABLE ACCESS FULL    | KEMP_CONFIG |     1 |    26 |     2   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("PB_PROC_ID" IS NULL OR EXISTS (SELECT /*+ */ 0 FROM
              "KEMP_CONFIG" "KEMP_CONFIG" WHERE "PROC_ID"=:B1 AND
              "FREQUENCY_TYPE"<>(-1)))
PLAN_TABLE_OUTPUT
   2 - access("$nso_col_1"="KEMPUTILITY"."DTTM"("END_DT","END_TM"))
   6 - filter("A2"."EQ_NAME"='BILAN_MAZOUT_BFOE' AND "A2"."IS_AD_HOC"<>(-1))
   7 - filter("EQ_NAME"='BILAN_MAZOUT_BFOE' AND "IS_AD_HOC"<>1)
   8 - filter("PROC_ID"=:B1 AND "FREQUENCY_TYPE"<>(-1))

Can we improve the query further

In Oracle 10g on Windows, can the following query be improved:
update A
set ( col3,col4 ) =
          ( select col3, col4
from B
where A.col1=B.col1
and A.col2=b.col2
where exists
     ( select 1
     from B
     where A.col1=B.col1
     and A.col2=b.col2
The above query taken more than 2 hours to update table A from table B.
Table A contains about 800 million records
Table B contains about 1 million records

I have just mailed the sample query,
Following is the acutal query ( Currenlty both tables CsgSec and CsgSec_changes_pk are empty ):
Query_
update CsgSec
set
(GVKEY,
IID,
CUSIP,
DLDTEI,
DLRSNI,
DSCI,
EPF,
EXCHG,
EXCNTRY,
IBTIC,
ISIN,
SECSTAT,
SEDOL,
TIC,
TPCI,
SECID,
NAME) = ( select GVKEY,
IID,
CUSIP,
DLDTEI,
DLRSNI,
DSCI,
EPF,
EXCHG,
EXCNTRY,
IBTIC,
ISIN,
SECSTAT,
SEDOL,
TIC,
TPCI,
SECID,
NAME from CsgSec_changes_pk
where CsgSec_changes_pk.UpdateFlag_ = 'X'
and CsgSec.GVKEY = CsgSec_changes_pk.GVKEY
and CsgSec.IID = CsgSec_changes_pk.IID)
where exists
( select 1
from CsgSec_changes_pk
where CsgSec_changes_pk.UpdateFlag_ = 'X'
and CsgSec.GVKEY = CsgSec_changes_pk.GVKEY
and CsgSec.IID = CsgSec_changes_pk.IID
Version_
The version of the database is 10.2.0.2.0
Optimizer Parameters_
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 10.2.0.2
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean TRUE
Explain Plan_
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | UPDATE STATEMENT | | 1 | 279 | 1 (100)| 00:00:01 |
| 1 | UPDATE | CSGSEC | | | | |
| 2 | MERGE JOIN SEMI | | 1 | 279 | 1 (100)| 00:00:01 |
| 3 | INDEX FULL SCAN | PKEY_IDX_CSGSEC | 1 | 259 | 0 (0)| 00:00:01 |
|* 4 | SORT UNIQUE | | 1 | 20 | 1 (100)| 00:00:01 |
|* 5 | INDEX RANGE SCAN | PKEY_CSGSEC_CHANGES | 1 | 20 | 0 (0)| 00:00:01 |
| 6 | TABLE ACCESS BY INDEX ROWID| CSGSEC_CHANGES_PK | 1 | 262 | 0 (0)| 00:00:01 |
|* 7 | INDEX UNIQUE SCAN | PKEY_CSGSEC_CHANGES | 1 | | 0 (0)| 00:00:01 |
Edited by: Moazzam on Jun 1, 2009 3:30 PM

How to improve the query

Guys,
I have the following query which seem to take quite a lot of time. About 7 hours
It is spending significant amount of time on doing the max(dt), as the table has about a million records. Any know a better way of writing this query ?
SELECT   ABS (amount) AS amount, date_from
    FROM (SELECT   SUM
                      ( k$forex.rate (f$evaluation.eval_ccy,
                                       :b5,
                                       f$card.date_until,
                                       f$card.date_until
                       * ( f$evaluation.eval_market_value
                          + DECODE (k$structure.total_includes_accrued,
                                    1, NVL
                                         (f$evaluation.eval_accrued_interests,
                                          0
                                    0
                      ) AS amount,
                   f$card.date_from AS date_from
              FROM f$card, f$evaluation, k$portfolio, k$structure
             WHERE f$evaluation.STRUCTURE = k$structure.ID
               AND f$card.ID = f$evaluation.card
               AND f$card.portfolio = k$portfolio.ID
               AND f$card.fee = :b4
               AND k$portfolio.fee_profile = :b3
               AND f$card.date_from >= :b2
               AND f$card.date_until <= :b1
               AND f$evaluation.off_balance_sheet = 0
               AND f$evaluation.asset = 2
               AND f$evaluation.eval_market_value IS NOT NULL
               AND f$evaluation.dte =
                        (SELECT MAX (e2.dte)
                           FROM f$evaluation e2
                          WHERE e2.card = f$card.ID AND e2.dte <= TRUNC (:b6))
          GROUP BY f$card.date_from)
ORDER BY date_from
TKPROF outout shows
call     count       cpu    elapsed       disk      query    current        rows
Parse     1598      0.07       0.07          0          0          0           0
Execute   2398      1.19       1.20          0          0          0           0
Fetch     4326   2687.62    2630.06        326   17291480          0        1929
total     8322   2688.89    2631.34        326   17291480          0        1929
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: FIRST_ROWS
Parsing user id: 78 (PROSPERO)   (recursive depth: 1)
Rows     Row Source Operation
      1 SORT ORDER BY (cr=7485 pr=0 pw=0 time=1118615 us)
      1   VIEW (cr=7485 pr=0 pw=0 time=1118575 us)
      1    HASH GROUP BY (cr=7485 pr=0 pw=0 time=1118566 us)
     45     HASH JOIN (cr=7215 pr=0 pw=0 time=1093439 us)
     45      TABLE ACCESS BY INDEX ROWID F$EVALUATION (cr=7185 pr=0 pw=0 time=1085972 us)
   1263       NESTED LOOPS (cr=7144 pr=0 pw=0 time=136812196 us)
      1        HASH JOIN (cr=7136 pr=0 pw=0 time=1091026 us)
      1         TABLE ACCESS BY INDEX ROWID F$CARD (cr=7 pr=0 pw=0 time=112 us)
      4          NESTED LOOPS (cr=5 pr=0 pw=0 time=200 us)
      1           TABLE ACCESS BY INDEX ROWID K$PORTFOLIO (cr=3 pr=0 pw=0 time=62 us)
      1            INDEX RANGE SCAN IDX_K$PORTFOLIO$FEE_PROFILE (cr=2 pr=0 pw=0 time=46 us)(object id 81335)
      2           INDEX RANGE SCAN IDX_F$CARD$PORTFOLIO (cr=2 pr=0 pw=0 time=11 us)(object id 81336)
   3106         VIEW VW_SQ_1 (cr=7129 pr=0 pw=0 time=1092079 us)
   3106          HASH GROUP BY (cr=7129 pr=0 pw=0 time=1085865 us)
806960           INDEX FAST FULL SCAN PK_F$EVALUATION (cr=7129 pr=0 pw=0 time=807031 us)(object id 53621)
   1261        INDEX RANGE SCAN IDX_F$EVALUATION$CARD (cr=8 pr=0 pw=0 time=1306 us)(object id 53622)
     15      TABLE ACCESS FULL K$STRUCTURE (cr=30 pr=0 pw=0 time=64 us)Thanks in advance

Thanks for your help on this.. Do you know any links where i can gather more information on this ? I've now replaced the last bind with SYSDATE to make it easier. but not sure if it has any impact on the plan
PLAN_TABLE_OUTPUT
Plan hash value: 2614864167
| Id | Operation                           | Name                        | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                    |                             |     1 |    22 | 1470   (1)| 00:00:18 |
|   1 | SORT ORDER BY                      |                             |     1 |    22 | 1470   (1)| 00:00:18 |
|   2 |   VIEW                              |                             |     1 |    22 | 1470   (1)| 00:00:18 |
|   3 |    HASH GROUP BY                    |                             |     1 |    79 | 1470   (1)| 00:00:18 |
|* 4 |     FILTER                          |                             |       |       |            |          |
|* 5 |      HASH JOIN                      |                             |    73 | 5767 |    54   (2)| 00:00:01 |
|* 6 |       TABLE ACCESS BY INDEX ROWID   | F$EVALUATION                |   291 | 10476 |    38   (0)| 00:00:01 |
|   7 |        NESTED LOOPS                 |                             |    73 | 5256 |    45   (0)| 00:00:01 |
|   8 |         NESTED LOOPS                |                             |     1 |    36 |     7   (0)| 00:00:01 |
|   9 |          TABLE ACCESS BY INDEX ROWID| K$PORTFOLIO                 |     2 |    16 |     2   (0)| 00:00:01 |
|* 10 |           INDEX RANGE SCAN          | IDX_K$PORTFOLIO$FEE_PROFILE |     2 |       |     1   (0)| 00:00:01 |
|* 11 |          TABLE ACCESS BY INDEX ROWID| F$CARD                      |     1 |    28 |     3   (0)| 00:00:01 |
|* 12 |           INDEX RANGE SCAN          | IDX_F$CARD$PORTFOLIO        |     2 |       |     1   (0)| 00:00:01 |
|* 13 |         INDEX RANGE SCAN            | IDX_F$EVALUATION$CARD       |   406 |       |     3   (0)| 00:00:01 |
| 14 |       TABLE ACCESS FULL             | K$STRUCTURE                 |    15 |   105 |     8   (0)| 00:00:01 |
| 15 |      SORT AGGREGATE                 |                             |     1 |    12 |            |          |
|* 16 |       TABLE ACCESS BY INDEX ROWID   | F$EVALUATION                |   406 | 4872 |    39   (0)| 00:00:01 |
|* 17 |        INDEX RANGE SCAN             | IDX_F$EVALUATION$CARD       |   406 |       |     4   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   4 - filter("F$EVALUATION"."DTE"= (SELECT MAX("E2"."DTE") FROM "PROSPERO"."F$EVALUATION" "E2" WHERE
              "E2"."CARD"=:B1 AND "E2"."DTE"<=TRUNC(SYSDATE@!)))
   5 - access("F$EVALUATION"."STRUCTURE"="K$STRUCTURE"."ID")
   6 - filter("F$EVALUATION"."OFF_BALANCE_SHEET"=0 AND "F$EVALUATION"."ASSET"=2 AND
              "F$EVALUATION"."EVAL_MARKET_VALUE" IS NOT NULL)
10 - access("K$PORTFOLIO"."FEE_PROFILE"=TO_NUMBER(:B3))
11 - filter("F$CARD"."FEE"=TO_NUMBER(:B4) AND "F$CARD"."DATE_UNTIL"<=:B1 AND "F$CARD"."DATE_FROM">=:B2)
12 - access("F$CARD"."PORTFOLIO"="K$PORTFOLIO"."ID")
13 - access("F$CARD"."ID"="F$EVALUATION"."CARD")
16 - filter("E2"."DTE"<=TRUNC(SYSDATE@!))
17 - access("E2"."CARD"=:B1)
39 rows selected.

Please help me to increase the performance of the query

Hello
I am not an oracle expert or developer and i have a problem to resolve.
Below is the query and explaiation plan and seeking the help to improve the performance of the query.
Our Analysis,
The query runs good,takes less one minute and fetches the results but during peak time it takes 8 minutes
Require anyone suggestion's to improve the query.
The query is generated from the Microsft dll so we dont have SQL code and require some help on tuning the tables.
If tuning the query improves then also fine please suggest for that also.
Enviroment: Solaris 8
DB : oracle 9i
(SELECT vw.dispapptobjid, vw.custsiteobjid, vw.emplastname, vw.empfirstname,
vw.scheduledonsite AS starttime, vw.appttype, vw.latestart,
vw.endtime, vw.typetitle, vw.empobjid, vw.latitude, vw.longitude,
vw.workduration AS DURATION, vw.dispatchtype, vw.availability
FROM ora_appt_disp_view vw
WHERE ( ( vw.starttime >=
TO_DATE ('2/12/2007 4:59 PM', 'MM/DD/YYYY HH12:MI AM')
AND vw.starttime <
TO_DATE ('2/21/2007 3:59 PM', 'MM/DD/YYYY HH12:MI AM')
OR vw.endtime >
TO_DATE ('2/12/2007 4:59 PM', 'MM/DD/YYYY HH12:MI AM')
AND vw.endtime <=
TO_DATE ('2/21/2007 3:59 PM', 'MM/DD/YYYY HH12:MI AM')
OR ( vw.starttime <=
TO_DATE ('2/12/2007 4:59 PM', 'MM/DD/YYYY HH12:MI AM')
AND vw.endtime >=
TO_DATE ('2/21/2007 3:59 PM', 'MM/DD/YYYY HH12:MI AM')
UNION
(SELECT 0 AS dispapptobjid, emp.emp_physical_site2site AS custsiteobjid,
emp.last_name AS emplastname, emp.first_name AS empfirstname,
TO_DATE ('1/1/3000', 'MM/DD/YYYY') AS starttime, 'E' AS appttype,
NULL AS latestart, NULL AS endtime, '' AS typetitle,
emp.objid AS empobjid, 0 AS latitude, 0 AS longitude, 0 AS DURATION,
'' AS dispatchtype, 0 AS availability
FROM table_employee emp, table_user usr
WHERE emp.employee2user = usr.objid AND emp.field_eng = 1 AND usr.status = 1)
ORDER BY empobjid, starttime, endtime DESC
Operation     Object Name     Rows     Bytes     Cost     Object Node     In/Out     PStart     PStop
SELECT STATEMENT Optimizer Mode=HINT: ALL_ROWS          23 K          11312
SORT UNIQUE          23 K     3 M     11140
UNION-ALL
VIEW     ORA_APPT_DISP_VIEW     17 K     3 M     10485
UNION-ALL
CONCATENATION
NESTED LOOPS OUTER          68      24 K     437
NESTED LOOPS          68      23 K     369
NESTED LOOPS OUTER          68      25 K     505
NESTED LOOPS OUTER          68      24 K     505
NESTED LOOPS          68      23 K     369
NESTED LOOPS          68      22 K     369
NESTED LOOPS OUTER          68      22 K     369
NESTED LOOPS          19      6 K     312
NESTED LOOPS          19      5 K     312
HASH JOIN          19      5 K     293
NESTED LOOPS          19      5 K     274
NESTED LOOPS          19      4 K     236
NESTED LOOPS          19      4 K     198
NESTED LOOPS OUTER          19      3 K     160
NESTED LOOPS OUTER          19      3 K     160
NESTED LOOPS OUTER          19      4 K     160
NESTED LOOPS OUTER          19      1 K     103
NESTED LOOPS OUTER          19      2 K     103
NESTED LOOPS OUTER          19      2 K     103
TABLE ACCESS BY INDEX ROWID     TABLE_DISPTCHFE     19      1 K     46
INDEX RANGE SCAN     GSA_SCHED_REPAIR     44           3
TABLE ACCESS BY INDEX ROWID     TABLE_COMMIT_LOG     1      22
INDEX RANGE SCAN     GSA_COMDFE     1           2
TABLE ACCESS BY INDEX ROWID     TABLE_COMMIT_LOG     1      22
INDEX RANGE SCAN     GSA_COMDFE     1           2
TABLE ACCESS BY INDEX ROWID     TABLE_COMMIT_LOG     1      22      3
INDEX RANGE SCAN     GSA_COMDFE     1           2
TABLE ACCESS BY INDEX ROWID     TABLE_COMMIT_LOG     1      28
INDEX RANGE SCAN     IND_CASE_COMMIT2CASE     2           2
TABLE ACCESS BY INDEX ROWID     TABLE_COMMIT_LOG     1      28
INDEX RANGE SCAN     IND_CASE_COMMIT2CASE     2           2
TABLE ACCESS BY INDEX ROWID     TABLE_COMMIT_LOG     1      28      3
INDEX RANGE SCAN     IND_CASE_COMMIT2CASE     2           2
TABLE ACCESS BY INDEX ROWID     TABLE_CASE     1      30      2
INDEX UNIQUE SCAN     CASE_OBJINDEX     1           1
TABLE ACCESS BY INDEX ROWID     TABLE_SITE     1      12      2
INDEX UNIQUE SCAN     SITE_OBJINDEX     1           1
TABLE ACCESS BY INDEX ROWID     TABLE_ADDRESS     1      12      2
INDEX UNIQUE SCAN     ADDRESS_OBJINDEX     1           1
TABLE ACCESS FULL     TABLE_EMPLOYEE     1      34      1
INDEX UNIQUE SCAN     SITE_OBJINDEX     1      6      1
INDEX UNIQUE SCAN     USER_OBJINDEX     1      6
TABLE ACCESS BY INDEX ROWID     TABLE_X_GSA_TIME_STAMPS     4      48      3
INDEX RANGE SCAN     GSAIDX_TS2DISP     1           2
INDEX UNIQUE SCAN     GBST_ELM_OBJINDEX     1      6
INDEX UNIQUE SCAN     GBST_ELM_OBJINDEX     1      6
TABLE ACCESS BY INDEX ROWID     TABLE_MOD_LEVEL     1      12      1
INDEX UNIQUE SCAN     MOD_LEVEL_OBJINDEX     1
INDEX UNIQUE SCAN     PART_NUM_OBJINDEX     1      6
INDEX UNIQUE SCAN     GBST_ELM_OBJINDEX     1      6
INDEX UNIQUE SCAN     SUBCASE_OBJINDX     1      6      1
NESTED LOOPS OUTER          68      25 K     505
NESTED LOOPS OUTER          68      24 K     505
NESTED LOOPS OUTER          68      24 K     437
NESTED LOOPS          68      23 K     369
NESTED LOOPS          68      23 K     369
NESTED LOOPS          68      22 K     369
NESTED LOOPS OUTER          68      22 K     369
NESTED LOOPS          19      6 K     312
NESTED LOOPS          19      5 K     312
NESTED LOOPS          19      5 K     293
NESTED LOOPS          19      5 K     274
NESTED LOOPS          19      4 K     236
NESTED LOOPS          19      4 K     198
NESTED LOOPS OUTER          19      4 K     160
NESTED LOOPS OUTER          19      3 K     160
NESTED LOOPS OUTER          19      3 K     160
NESTED LOOPS OUTER          19      2 K     103
NESTED LOOPS OUTER          19      2 K     103
NESTED LOOPS OUTER          19      1 K     103
TABLE ACCESS BY INDEX ROWID     TABLE_DISPTCHFE     19      1 K     46
INDEX RANGE SCAN     GSA_SCHED_REPAIR     44           3
TABLE ACCESS BY INDEX ROWID     TABLE_COMMIT_LOG     1      22      3
INDEX RANGE SCAN     GSA_COMDFE     1           2
TABLE ACCESS BY INDEX ROWID     TABLE_COMMIT_LOG     1      22
INDEX RANGE SCAN     GSA_COMDFE     1           2
TABLE ACCESS BY INDEX ROWID     TABLE_COMMIT_LOG     1      22
INDEX RANGE SCAN     GSA_COMDFE     1           2
TABLE ACCESS BY INDEX ROWID     TABLE_COMMIT_LOG     1      28      3
INDEX RANGE SCAN     IND_CASE_COMMIT2CASE     2           2
TABLE ACCESS BY INDEX ROWID     TABLE_COMMIT_LOG     1      28
INDEX RANGE SCAN     IND_CASE_COMMIT2CASE     2           2
TABLE ACCESS BY INDEX ROWID     TABLE_COMMIT_LOG     1      28
INDEX RANGE SCAN     IND_CASE_COMMIT2CASE     2           2
TABLE ACCESS BY INDEX ROWID     TABLE_CASE     1      30      2
INDEX UNIQUE SCAN     CASE_OBJINDEX     1           1
TABLE ACCESS BY INDEX ROWID     TABLE_SITE     1      12      2
INDEX UNIQUE SCAN     SITE_OBJINDEX     1           1
TABLE ACCESS BY INDEX ROWID     TABLE_ADDRESS     1      12      2
INDEX UNIQUE SCAN     ADDRESS_OBJINDEX     1           1
TABLE ACCESS BY INDEX ROWID     TABLE_EMPLOYEE     1      34      1
INDEX UNIQUE SCAN     EMPLOYEE_OBJINDEX     1
INDEX UNIQUE SCAN     SITE_OBJINDEX     1      6      1
INDEX UNIQUE SCAN     USER_OBJINDEX     1      6
TABLE ACCESS BY INDEX ROWID     TABLE_X_GSA_TIME_STAMPS     4      48      3
INDEX RANGE SCAN     GSAIDX_TS2DISP     1           2
INDEX UNIQUE SCAN     GBST_ELM_OBJINDEX     1      6
INDEX UNIQUE SCAN     GBST_ELM_OBJINDEX     1      6
INDEX UNIQUE SCAN     GBST_ELM_OBJINDEX     1      6
INDEX UNIQUE SCAN     SUBCASE_OBJINDX     1      6      1
TABLE ACCESS BY INDEX ROWID     TABLE_MOD_LEVEL     1      12      1
INDEX UNIQUE SCAN     MOD_LEVEL_OBJINDEX     1
INDEX UNIQUE SCAN     PART_NUM_OBJINDEX     1      6
NESTED LOOPS OUTER          68      25 K     505
NESTED LOOPS OUTER          68      24 K     505
NESTED LOOPS OUTER          68      24 K     437
NESTED LOOPS          68      23 K     369
NESTED LOOPS          68      23 K     369
NESTED LOOPS          68      22 K     369
NESTED LOOPS OUTER          68      22 K     369
NESTED LOOPS          19      6 K     312
NESTED LOOPS          19      5 K     312
NESTED LOOPS          19      5 K     293
NESTED LOOPS          19      5 K     274
NESTED LOOPS          19      4 K     236
NESTED LOOPS          19      4 K     198
NESTED LOOPS OUTER          19      4 K     160
NESTED LOOPS OUTER          19      3 K     160
NESTED LOOPS OUTER          19      3 K     160
NESTED LOOPS OUTER          19      2 K     103
NESTED LOOPS OUTER          19      2 K     103
NESTED LOOPS OUTER          19      1 K     103
TABLE ACCESS BY INDEX ROWID     TABLE_DISPTCHFE     19      1 K     46
INDEX RANGE SCAN     GSA_REQ_ETA     44           3
TABLE ACCESS BY INDEX ROWID     TABLE_COMMIT_LOG     1      22      3
INDEX RANGE SCAN     GSA_COMDFE     1           2
TABLE ACCESS BY INDEX ROWID     TABLE_COMMIT_LOG     1      22
INDEX RANGE SCAN     GSA_COMDFE     1           2
TABLE ACCESS BY INDEX ROWID     TABLE_COMMIT_LOG     1      22
INDEX RANGE SCAN     GSA_COMDFE     1           2
TABLE ACCESS BY INDEX ROWID     TABLE_COMMIT_LOG     1      28      3
INDEX RANGE SCAN     IND_CASE_COMMIT2CASE     2           2
TABLE ACCESS BY INDEX ROWID     TABLE_COMMIT_LOG     1      28
INDEX RANGE SCAN     IND_CASE_COMMIT2CASE     2           2
TABLE ACCESS BY INDEX ROWID     TABLE_COMMIT_LOG     1      28
INDEX RANGE SCAN     IND_CASE_COMMIT2CASE     2           2
TABLE ACCESS BY INDEX ROWID     TABLE_CASE     1      30      2
INDEX UNIQUE SCAN     CASE_OBJINDEX     1           1
TABLE ACCESS BY INDEX ROWID     TABLE_SITE     1      12      2
INDEX UNIQUE SCAN     SITE_OBJINDEX     1           1
TABLE ACCESS BY INDEX ROWID     TABLE_ADDRESS     1      12      2
INDEX UNIQUE SCAN     ADDRESS_OBJINDEX     1           1
TABLE ACCESS BY INDEX ROWID     TABLE_EMPLOYEE     1      34      1
INDEX UNIQUE SCAN     EMPLOYEE_OBJINDEX     1
INDEX UNIQUE SCAN     SITE_OBJINDEX     1      6      1
INDEX UNIQUE SCAN     USER_OBJINDEX     1      6
TABLE ACCESS BY INDEX ROWID     TABLE_X_GSA_TIME_STAMPS     4      48      3
INDEX RANGE SCAN     GSAIDX_TS2DISP     1           2
INDEX UNIQUE SCAN     GBST_ELM_OBJINDEX     1      6
INDEX UNIQUE SCAN     GBST_ELM_OBJINDEX     1      6
INDEX UNIQUE SCAN     GBST_ELM_OBJINDEX     1      6
INDEX UNIQUE SCAN     SUBCASE_OBJINDX     1      6      1
TABLE ACCESS BY INDEX ROWID     TABLE_MOD_LEVEL     1      12      1
INDEX UNIQUE SCAN     MOD_LEVEL_OBJINDEX     1
INDEX UNIQUE SCAN     PART_NUM_OBJINDEX     1      6
NESTED LOOPS          16 K     2 M     5812
HASH JOIN          16 K     2 M     5812
HASH JOIN          16 K     2 M     5286
TABLE ACCESS FULL     TABLE_EMPLOYEE     13 K     441 K     28
HASH JOIN          16 K     1 M     5243
TABLE ACCESS FULL     TABLE_SCHEDULE     991      11 K     2
HASH JOIN OUTER          16 K     1 M     5240
HASH JOIN OUTER          16 K     1 M     3866
HASH JOIN OUTER          16 K     1 M     450
HASH JOIN          16 K     1 M     44
TABLE ACCESS FULL     TABLE_GBST_ELM     781      14 K     2
TABLE ACCESS FULL     TABLE_APPOINTMENT     16 K     822 K     41
INDEX FAST FULL SCAN     CASE_OBJINDEX     1 M     6 M     201
TABLE ACCESS FULL     TABLE_SITE     967 K     11 M     3157
TABLE ACCESS FULL     TABLE_ADDRESS     961 K     11 M     1081
INDEX FAST FULL SCAN     SITE_OBJINDEX     967 K     5 M     221
INDEX UNIQUE SCAN     USER_OBJINDEX     1      6
HASH JOIN          6 K     272 K     51
TABLE ACCESS FULL     TABLE_USER     6 K     51 K     21
TABLE ACCESS FULL     TABLE_EMPLOYEE     6 K     220 K     28

Hi,
First-off, it appear that you are querying a view. I would redo the auery against the base table.
Next, look at a function-based index for the DATE column. Here are my notes:
http://www.dba-oracle.com/t_function_based_indexes.htm
http://www.dba-oracle.com/oracle_tips_index_scan_fbi_sql.htm
Also, make sure you are analyzed properly with dbms_stats:
http://www.dba-oracle.com/art_builder_dbms_stats.htm
And histograms, if appropriate:
http://www.dba-oracle.com/art_builder_histo.htm
Lasty, look at increasing hash_area_size or pga_aggregate_tagtet, depending on your table sizes:
http://www.dba-oracle.com/art_so_undocumented_pga_parameters.htm
Hope this helps. . . .
Donald K. Burleson
Oracle Press Author

Help required in optimizing the query response time

Hi,
I am working on a application which uses a jdbc thin client. My requirement is to select all the table rows in one table and use the column values to select data in another table in another database.
The first table can have maximum of 6 million rows but the second table rows will be around 9000.
My first query is returning within 30-40 milliseconds when the table is having 200000 rows. But when I am iterating the result set and query the second table the query is taking around 4 millisecond for each query.
the second query selection criteria is to find the value in the range .
for example my_table ( varchar2 column1, varchar2 start_range, varchar2 end_range);
My first query returns a result which then will be used to select using the following query
select column1 from my_table where start_range < my_value and end_range> my_value;
I have created an index on start_range and end_range. this query is taking around 4 millisseconds which I think is too much.
I am using a preparedStatement for the second query loop.
Can some one suggest me how I can improve the query response time?
Regards,
Shyam

Try the code below.
Pre-requistee: you should know how to pass ARRAY objects to oracle and receive resultsets from java. There are 1000s of samples available on net.
I have written a sample db code for the same interraction.
Procedure get_list takes a array input from java and returns the record set back to java. You can change the tablenames and the creteria.
Good luck.
DROP TYPE idlist;
CREATE OR REPLACE TYPE idlist AS TABLE OF NUMBER;
CREATE OR REPLACE PACKAGE mypkg1
AS
   PROCEDURE get_list (myval_list idlist, orefcur OUT sys_refcursor);
END mypkg1;
CREATE OR REPLACE PACKAGE BODY mypkg1
AS
   PROCEDURE get_list (myval_list idlist, orefcur OUT sys_refcursor)
   AS
      ctr   NUMBER;
   BEGIN
      DBMS_OUTPUT.put_line (myval_list.COUNT);
      FOR x IN (SELECT object_name, object_id, myvalue
                  FROM user_objects a,
                       (SELECT myval_list (ROWNUM + 1) myvalue
                          FROM TABLE (myval_list)) b
                 WHERE a.object_id < b.myvalue)
      LOOP
         DBMS_OUTPUT.put_line (   x.object_name
                               || ' - '
                               || x.object_id
                               || ' - '
                               || x.myvalue
      END LOOP;
   END;
END mypkg1;
[pre]
Testing the code above. Make sure dbms output is ON.
[pre]
DECLARE
   a      idlist;
   refc   sys_refcursor;
   c number;
BEGIN
   SELECT x.nu
   BULK COLLECT INTO a
     FROM (SELECT 5000 nu
             FROM DUAL) x;
   mypkg1.get_list (a, refc);
END;
[pre]
Vishal V.

How to improve the performance.

Hi All,
My question is , What and all we have to check to improve the Query performance . In our schema , all the tables are partitioned and all the tables have indexes . And the tables are not compressed , if i do table compression in my schema , will the query performance increase ? or Do i need to check any other things. Could you please share your ideas.
Thanks
Sree

Hi Sree,
all the things you mentioned, indexing, partitioning and compression, are not necessarily related to performance or can be both advantageous and deleterious to performance. Just putting them in place is no guarantee of performance.
Indexing speeds up access but slows down DML. Partitioning is used just as much (if not more) for archival management as it is for performance. Compression is used primarily for space management but has the added benefit of possibly speeding up scan type queries but can slow down DML. Just using these is no guarantee of performance, and can be a hindrance.
The normal recommendations for performance begin with database design and implementation. Design and implement your database to sound relational principles.
Design a normalised database to at least 3rd normal form.
Use appropriate data types.
Index appropriately, PK's, UK's and obvious FK's (I don't subscribe to the theory that all FK's should be indexed, but that's another argument) Err on the side of less is more.
Use primarily simple tables, unless experience indicates other storage options such as partitioning or IOT's may be useful.
Once the application starts to move beyond development then performance issues may start to become obvious, but the method here is to fix the problems. Simply implementing a feature such as partitioning across the whole database in the hope of avoiding future problems will probably be a waste of time at best and cause more issues than it solves at worst. This is not to say that performance is only considered in the last phases. Performance should be a consideration through the whole process, and can be achieved by sound and understood design, implementation and coding principles.
Once the application moves to testing and implementation phases, then you may be surprised at how few performance issues there are, and even here there is an established performance and tuning methodology for diagnosis and resolution.
There are whole books written and careers forged in the field of database performance, so it is beyond the scope of this rant to do anything more than give a broad brush stroke of the overall principles. But I hope this at least points you in the right direction.
Regards
Andre

How to improve this query speed ?....help me

How to improve the query speed. Any hints can u suggest in the query or any correction. Here i am using sample tables for checking purpose, When i am trying with my original values, this type of query taking longer time to run
select ename,sal,comm from emp where(comm is null and &status='ok') or (comm is not null and &status='failed');
Thanx in advance
prasanth a.s.

What about
select ename,sal,comm from emp where comm is null and &status='ok'
union all
select ename,sal,comm from emp where comm is not null and &status='failed';
Regards
Vaishnavi

Improving a query performance

Hello gurus,
We do use RSRT, ST03(expert mode) to check if a query is running slowly. what actually do we check there and how?
Can anyone please explain me how its done.
Thanks in advance
S N

Hi SN,
You need to check the DB time taken by the queries and the summarization ratio for the queries. As a rule of thumb if the summarization ration > 10 and the database time > 30% then creating an aggregate will improve the query performance.
BY summarization ration i mean ratio between the number of records read from the cube to the number of records displayed in the report.
Thx,
Soumya

To improve the query???

Similar Messages

Maybe you are looking for