Query is slow taking so much Time

Question

Hi All,
My DB Version is 10.2.0
OS is Windows Server 2003
I am new to performance tunning, can anyone guru suggest me what i need to do as one of the user coming to me and said that my query is running slow. So from where i need to start or what are the steps sequence i need to follow wheather i start with explain plan or with AWR.
Thanks in advance

Answer 1

I am getting below error as i search from addm
DETAILED ADDM REPORT FOR TASK 'ADDM:1051257157_1_1412' WITH ID 12851
              Analysis Period: 22-JUN-2012 from 13:30:14 to 14:22:25
         Database ID/Instance: 1051257157/1
      Database/Instance Names: SIDB/sidb
                    Host Name: SERVER1
             Database Version: 10.2.0.1.0
               Snapshot Range: from 1411 to 1412
                Database Time: 2037 seconds
        Average Database Load: .7 active sessions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
FINDING 1: 41% impact (829 seconds)
Individual database segments responsible for significant user I/O wait were
found.
   RECOMMENDATION 1: Segment Tuning, 17% benefit (346 seconds)
      ACTION: Run "Segment Advisor" on TABLE "SIUSER.SAL_ORD_D" with object id
         52739.
         RELEVANT OBJECT: database object with id 52739
      ACTION: Investigate application logic involving I/O on TABLE
         "SIUSER.SAL_ORD_D" with object id 52739.
         RELEVANT OBJECT: database object with id 52739
      RATIONALE: The I/O usage statistics for the object are: 243 full object
         scans, 1763014 physical reads, 64170 physical writes and 0 direct
         reads.
      RATIONALE: The SQL statement with SQL_ID "4ws9bwmth4yn0" spent
         significant time waiting for User I/O on the hot object.
         RELEVANT OBJECT: SQL statement with SQL_ID 4ws9bwmth4yn0
         Update SAL_ORD_D set SOD_BLCK_QTY  = nvl((select sum(BIQD_BLCK_QTY)
         from SAL_BLCK_ITEM_QTY_D,SAL_BLCK_ITEM_QTY_M where
         BIQD_DIV_CODE=BIQM_DIV_CODE and BIQD_MASCOM_CODE=BIQM_MASCOM_CODE and
         BIQD_REF_NUM=BIQM_REF_NUM  and BIQD_DIV_CODE='LM0000' and
         BIQD_MASCOM_CODE='LATL01' and BIQM_APPROVED_FLAG='Y' and
         BIQD_ITEM_CODE=SOD_ITEM_CODE),0)   where  SOD_CANCELED_FLAG 'Y' and
         SOD_STAT_FLAG 'Y' and SOD_DIV_CODE='LM0000' and
         SOD_MASCOM_CODE='LATL01' 
   RECOMMENDATION 2: Segment Tuning, 11% benefit (231 seconds)
      ACTION: Run "Segment Advisor" on TABLE "SIUSER.SAL_INVC_M" with object
         id 52723.
         RELEVANT OBJECT: database object with id 52723
      ACTION: Investigate application logic involving I/O on TABLE
         "SIUSER.SAL_INVC_M" with object id 52723.
         RELEVANT OBJECT: database object with id 52723
      RATIONALE: The I/O usage statistics for the object are: 387 full object
         scans, 607878 physical reads, 22 physical writes and 0 direct reads.
   RECOMMENDATION 3: Segment Tuning, 8.8% benefit (178 seconds)
      ACTION: Run "Segment Advisor" on TABLE "SIUSER.SAL_DA_D" with object id
         52694.
         RELEVANT OBJECT: database object with id 52694
      ACTION: Investigate application logic involving I/O on TABLE
         "SIUSER.SAL_DA_D" with object id 52694.
         RELEVANT OBJECT: database object with id 52694
      RATIONALE: The I/O usage statistics for the object are: 56 full object
         scans, 708645 physical reads, 24904 physical writes and 0 direct
         reads.
   RECOMMENDATION 4: Segment Tuning, 3.6% benefit (73 seconds)
      ACTION: Run "Segment Advisor" on TABLE "SIUSER.SAL_DA_SRV_N_RATE" with
         object id 52712.
         RELEVANT OBJECT: database object with id 52712
      ACTION: Investigate application logic involving I/O on TABLE
         "SIUSER.SAL_DA_SRV_N_RATE" with object id 52712.
         RELEVANT OBJECT: database object with id 52712
      RATIONALE: The I/O usage statistics for the object are: 112 full object
         scans, 173184 physical reads, 5402 physical writes and 0 direct
         reads.
   SYMPTOMS THAT LED TO THE FINDING:
      SYMPTOM: Wait class "User I/O" was consuming significant database time.
               (57% impact [1165 seconds])
FINDING 2: 16% impact (324 seconds)
The SGA was inadequately sized, causing additional I/O or hard parses.
   RECOMMENDATION 1: DB Configuration, 15% benefit (297 seconds)
      ACTION: Increase the size of the SGA by setting the parameter
         "sga_target" to 876 M.
   ADDITIONAL INFORMATION:
      The value of parameter "sga_target" was "584 M" during the analysis
      period.
   SYMPTOMS THAT LED TO THE FINDING:
      SYMPTOM: Wait class "User I/O" was consuming significant database time.
               (57% impact [1165 seconds])
      SYMPTOM: Hard parsing of SQL statements was consuming significant
               database time. (5.9% impact [120 seconds])
FINDING 3: 6.1% impact (125 seconds)
Time spent on the CPU by the instance was responsible for a substantial part
of database time.
   RECOMMENDATION 1: Application Analysis, 6.1% benefit (125 seconds)
      ACTION: Parsing SQL statements were consuming significant CPU. Please
         refer to other findings in this task about parsing for further
         details.
   ADDITIONAL INFORMATION:
      The instance spent significant time on CPU. However, there were no
      predominant SQL statements responsible for the CPU load.
FINDING 4: 5.5% impact (112 seconds)
SQL statements were not shared due to the usage of literals. This resulted in
additional hard parses which were consuming significant database time.
   RECOMMENDATION 1: Application Analysis, 5.5% benefit (112 seconds)
      ACTION: Investigate application logic for possible use of bind variables
         instead of literals.
      ACTION: Alternatively, you may set the parameter "cursor_sharing" to
         "force".
      RATIONALE: At least 28 SQL statements with PLAN_HASH_VALUE 3296081222
         were found to be using literals. Look in V$SQL for examples of such
         SQL statements.
      RATIONALE: At least 14 SQL statements with PLAN_HASH_VALUE 3662582453
         were found to be using literals. Look in V$SQL for examples of such
         SQL statements.
      RATIONALE: At least 7 SQL statements with PLAN_HASH_VALUE 3360087625
         were found to be using literals. Look in V$SQL for examples of such
         SQL statements.
      RATIONALE: At least 6 SQL statements with PLAN_HASH_VALUE 571809715 were
         found to be using literals. Look in V$SQL for examples of such SQL
         statements.
   SYMPTOMS THAT LED TO THE FINDING:
      SYMPTOM: Hard parsing of SQL statements was consuming significant
               database time. (5.9% impact [120 seconds])
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          ADDITIONAL INFORMATION
Wait class "Application" was not consuming significant database time.
Wait class "Commit" was not consuming significant database time.
Wait class "Concurrency" was not consuming significant database time.
Wait class "Configuration" was not consuming significant database time.
Wait class "Network" was not consuming significant database time.
Session connect and disconnect calls were not consuming significant database
time.
The database's maintenance windows were active during 100% of the analysis
period.
The analysis of I/O performance is based on the default assumption that the
average read time for one database block is 10000 micro-seconds.
An explanation of the terminology used in this report is available when you
run the report with the 'ALL' level of detail.
Please guide me over the same
Edited by: Vikas Kohli on Jun 22, 2012 3:18 PM