Sql execution plan

There was a query to create the execution plan for owner name.view name
i know to generate the explain plan for sql query using
explain plan for <sql query>
whereas how to generate the execution plan for owner name.view name using explain plan.
Please explain and guide me in this
Aram

aram wrote:
There was a query to create the execution plan for owner name.view name
i know to generate the explain plan for sql query using
explain plan for <sql query>
whereas how to generate the execution plan for owner name.view name using explain plan.
Please explain and guide me in this
Aramexplain plan for SELECT * FROM OWNER_NAME.VIEW;

Similar Messages

How to get the SQL Execution Plan from complex Extractors ?

Hi
I am looking for a way to get the
SQL Execution Plan(s!)
from
Complex Extractors like 0CO_OM_CCA_9 ?
Anybody has got a suggestion ?
How to get this in SM50 ?
ThanXs
Martin

Identifying the query is the hard part. If you can identify it(based on table access or some such parameter, getting the execution plan is easy in ST04 .

How to find out if SQL execution plan is changed proactively using job/grid

Hello,
Can you help me on How to find out if SQL execution plan is changed proactively using job/grid control?
Thank you..
-

The answers so far are supposed to show ways how to see that a plan changed after the fact - that is not really proactive but that was the question.
A way to see a plan change proactively would be to create a SQL Plan Baseline for the SQL statement with the 'good old' plan and then watch DBA_SQL_PLAN_BASELINES for new rows with that SQL_HANDLE which would indicate that a new execution plan was computed - although not yet used.
Kind regards
Uwe Hesse
"Don't believe it, test it!"
http://uhesse.com

How to write SQL in crystal report that can reuse SQL execution plan cache?

I write the following SQL with crystal report parameter fields, and it is connecting to SQL 2005
Select Name from Customer where CustID = '{?CustID}'
The SQL profiler show that It is an ad-hoc query, how to write parameterized SQL which can reuse Execution Plan.
Edited by: Chan Yue Wah on May 14, 2009 3:17 AM

Since there are too many report, it is not possible rewrite all. Is that crystal report do not have option to change how it query the database ?

Question for SQL execution plan, strange..

HI, all
We meet a strange problem for a execution plan. First, we have a StoreProc, it runs around less than 20 secs. One day, it runs more than 5 mins (Execution plan 1). I checked all the index (fragmentation is low and Scan density is high), and re-run the update
statistics, but the performance still have no any improvement.
This is very strange for me, why the query becomes slow suddenly on one day (we will know the performance immedidately because it is a daily function, user will report to us if the performance is low, we only got complain today.)?
Finally, we tested in two ways.
1. We run the below update statistic command with one index - "update statistics dbo.PCMS_CARD_TRANS MGM_IDX_PCMS_TRANS_TIME_PROCESSING"
Result: It runs under 20 secs.
2. We create a new index - "MGM_IDX_Test_TRANS_TIME"
Result: It runs around 1 second, but I checked the execution plan (Execution plan 2) didn't change and the new index is not use for it...we feel strange again on it......
All information was included in below:
Table - PCMS_CARD_TRANS, PCMS_CARD_PROFILE.
VIEW - PCMS_V_CR_CARD_STOCK
StoreProc: PCMS_CardRoom_GetProcessedCardStock
Index: All zipped.

USE [PCMS]
GO
/****** Object: View [dbo].[PCMS_V_CR_CARD_STOCK] Script Date: 4/9/2014 4:30:54 PM ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE VIEW [dbo].[PCMS_V_CR_CARD_STOCK]
AS
SELECT dbo.PCMS_CARD_PROFILE.CARD_ID, dbo.PCMS_CARD_PROFILE.TYPE_CODE, dbo.PCMS_CARD_PROFILE.COLOR_SET_CODE,
dbo.PCMS_CARD_PROFILE.VENDOR_ID, dbo.PCMS_CARD_PROFILE.CARD_STATUS, dbo.PCMS_CARD_PROFILE.LOC, dbo.PCMS_CARD_PROFILE.LOC_ID,
dbo.PCMS_CARD_PROFILE.LAST_TRANS_NO, dbo.PCMS_CARD_COLOR_SET_MASTER.COLOR_SET_DESC, dbo.PCMS_CARD_TYPE.TYPE_DESC,
dbo.PCMS_CARD_PROFILE.DECK_AMOUNT, dbo.PCMS_CARD_PROFILE.USAGE_TYPE, dbo.PCMS_CARD_PROFILE.STORAGE_ID,
dbo.PCMS_CARD_PROFILE.STORAGE, dbo.PCMS_CARD_TYPE.CARD_TYPE_GROUP
FROM dbo.PCMS_CARD_PROFILE INNER JOIN
dbo.PCMS_CARD_COLOR_SET_MASTER ON
dbo.PCMS_CARD_PROFILE.COLOR_SET_CODE = dbo.PCMS_CARD_COLOR_SET_MASTER.COLOR_SET_CODE INNER JOIN
dbo.PCMS_CARD_TYPE ON dbo.PCMS_CARD_PROFILE.TYPE_CODE = dbo.PCMS_CARD_TYPE.TYPE_CODE
WHERE (dbo.PCMS_CARD_COLOR_SET_MASTER.ENABLED = 1) AND (dbo.PCMS_CARD_TYPE.ENABLED = 1)
GO
EXEC sys.sp_addextendedproperty @name=N'MS_DiagramPane1', @value=N'[0E232FF0-B466-11cf-A24F-00AA00A3EFFF, 1.00]
Begin DesignProperties =
Begin PaneConfigurations =
Begin PaneConfiguration = 0
NumPanes = 4
Configuration = "(H (1[40] 4[20] 2[20] 3) )"
End
Begin PaneConfiguration = 1
NumPanes = 3
Configuration = "(H (1 [50] 4 [25] 3))"
End
Begin PaneConfiguration = 2
NumPanes = 3
Configuration = "(H (1 [50] 2 [25] 3))"
End
Begin PaneConfiguration = 3
NumPanes = 3
Configuration = "(H (4 [30] 2 [40] 3))"
End
Begin PaneConfiguration = 4
NumPanes = 2
Configuration = "(H (1 [56] 3))"
End
Begin PaneConfiguration = 5
NumPanes = 2
Configuration = "(H (2 [66] 3))"
End
Begin PaneConfiguration = 6
NumPanes = 2
Configuration = "(H (4 [50] 3))"
End
Begin PaneConfiguration = 7
NumPanes = 1
Configuration = "(V (3))"
End
Begin PaneConfiguration = 8
NumPanes = 3
Configuration = "(H (1[56] 4[18] 2) )"
End
Begin PaneConfiguration = 9
NumPanes = 2
Configuration = "(H (1 [75] 4))"
End
Begin PaneConfiguration = 10
NumPanes = 2
Configuration = "(H (1[66] 2) )"
End
Begin PaneConfiguration = 11
NumPanes = 2
Configuration = "(H (4 [60] 2))"
End
Begin PaneConfiguration = 12
NumPanes = 1
Configuration = "(H (1) )"
End
Begin PaneConfiguration = 13
NumPanes = 1
Configuration = "(V (4))"
End
Begin PaneConfiguration = 14
NumPanes = 1
Configuration = "(V (2))"
End
ActivePaneConfig = 0
End
Begin DiagramPane =
Begin Origin =
Top = 0
Left = 0
End
Begin Tables =
Begin Table = "PCMS_CARD_PROFILE"
Begin Extent =
Top = 6
Left = 38
Bottom = 265
Right = 212
End
DisplayFlags = 280
TopColumn = 0
End
Begin Table = "PCMS_CARD_COLOR_SET_MASTER"
Begin Extent =
Top = 6
Left = 250
Bottom = 121
Right = 426
End
DisplayFlags = 280
TopColumn = 0
End
Begin Table = "PCMS_CARD_TYPE"
Begin Extent =
Top = 6
Left = 464
Bottom = 121
Right = 637
End
DisplayFlags = 280
TopColumn = 0
End
End
End
Begin SQLPane =
End
Begin DataPane =
Begin ParameterDefaults = ""
End
Begin ColumnWidths = 13
Width = 284
Width = 1500
Width = 1500
Width = 1500
Width = 1500
Width = 1500
Width = 1500
Width = 1500
Width = 1500
Width = 1500
Width = 1500
Width = 1500
Width = 1500
End
End
Begin CriteriaPane =
Begin ColumnWidths = 11
Column = 1440
Alias = 900
Table = 1170
Output = 720
Append = 1400
NewValue = 1170
SortType = 1350
SortOrder = 1410
GroupBy = 1350
Filter = 1350
Or = 1350
Or = 1350
Or = 1350
End
End
End
' , @level0type=N'SCHEMA',@level0name=N'dbo', @level1type=N'VIEW',@level1name=N'PCMS_V_CR_CARD_STOCK'
GO
EXEC sys.sp_addextendedproperty @name=N'MS_DiagramPaneCount', @value=1 , @level0type=N'SCHEMA',@level0name=N'dbo', @level1type=N'VIEW',@level1name=N'PCMS_V_CR_CARD_STOCK'
GO
USE [PCMS]
GO
/****** Object: Index [IDX_PCMS_CARD_PROFILE_LOC] Script Date: 4/9/2014 4:39:51 PM ******/
CREATE NONCLUSTERED INDEX [IDX_PCMS_CARD_PROFILE_LOC] ON [dbo].[PCMS_CARD_PROFILE]
[LOC] ASC,
[LOC_ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY]
GO
USE [PCMS]
GO
/****** Object: Index [IDX_PCMS_CARD_PROFILE_LOC_USAGE] Script Date: 4/9/2014 4:39:56 PM ******/
CREATE NONCLUSTERED INDEX [IDX_PCMS_CARD_PROFILE_LOC_USAGE] ON [dbo].[PCMS_CARD_PROFILE]
[LOC] ASC,
[USAGE_TYPE] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY]
GO
USE [PCMS]
GO
/****** Object: Index [IDX_PCMS_CARD_PROFILE_STORAGE] Script Date: 4/9/2014 4:40:01 PM ******/
CREATE NONCLUSTERED INDEX [IDX_PCMS_CARD_PROFILE_STORAGE] ON [dbo].[PCMS_CARD_PROFILE]
[STORAGE] ASC,
[STORAGE_ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY]
GO
USE [PCMS]
GO
/****** Object: Index [MGM_IDX_PCMS_CARD_PROFILE_CARD_ID] Script Date: 4/9/2014 4:40:07 PM ******/
CREATE NONCLUSTERED INDEX [MGM_IDX_PCMS_CARD_PROFILE_CARD_ID] ON [dbo].[PCMS_CARD_PROFILE]
[CARD_ID] ASC,
[STORAGE] ASC,
[CARD_STATUS] ASC,
[LOC] ASC
INCLUDE ( [TYPE_CODE],
[COLOR_SET_CODE],
[LOC_ID]) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
USE [PCMS]
GO
/****** Object: Index [MGM_IDX_PCMS_CARD_PROFILE_CARD_STATUS] Script Date: 4/9/2014 4:40:12 PM ******/
CREATE NONCLUSTERED INDEX [MGM_IDX_PCMS_CARD_PROFILE_CARD_STATUS] ON [dbo].[PCMS_CARD_PROFILE]
[CARD_STATUS] ASC,
[VENDOR_ID] ASC,
[LOC] ASC
INCLUDE ( [CARD_ID],
[TYPE_CODE],
[COLOR_SET_CODE],
[USAGE_TYPE],
[DECK_AMOUNT],
[LAST_TRANS_NO]) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
USE [PCMS]
GO
/****** Object: Index [PK_PCMS_CARD_PROFILE] Script Date: 4/9/2014 4:40:18 PM ******/
ALTER TABLE [dbo].[PCMS_CARD_PROFILE] ADD CONSTRAINT [PK_PCMS_CARD_PROFILE] PRIMARY KEY CLUSTERED
[CARD_ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY]
GO

Explain SQL Query execution plan: Oracle

Dear Masters,
Kindly help me to understand execution plan for an SQL statement. I have following SQL execution plan for a query in system. How should I interpret it. I thank You in advace for your guidance.
SELECT STATEMENT ( Estimated Costs = 1.372.413 , Estimated #Rows = 0 )
       5 NESTED LOOPS
         ( Estim. Costs = 1.372.413 , Estim. #Rows = 3.125 )
         Estim. CPU-Costs = 55.798.978.498 Estim. IO-Costs = 1.366.482
           2 TABLE ACCESS BY INDEX ROWID MSEG
             ( Estim. Costs = 1.326.343 , Estim. #Rows = 76.717 )
             Estim. CPU-Costs = 55.429.596.575 Estim. IO-Costs = 1.320.451
             Filter Predicates
               1 INDEX RANGE SCAN MSEG~R
                 ( Estim. Costs = 89.322 , Estim. #Rows = 60.069.500 )
                 Search Columns: 1
                 Estim. CPU-Costs = 2.946.739.229 Estim. IO-Costs = 89.009
                 Access Predicates
           4 TABLE ACCESS BY INDEX ROWID MKPF
             ( Estim. Costs = 1 , Estim. #Rows = 1 )
             Estim. CPU-Costs = 4.815 Estim. IO-Costs = 1
             Filter Predicates
               3 INDEX UNIQUE SCAN MKPF~0
                 Search Columns: 3
                 Estim. CPU-Costs = 3.229 Estim. IO-Costs = 0
                 Access Predicates

Hi Panjak,
Yeahh, there's a huge unperformatic SQL statment, what I can see from this acces plan is:
1 DBO decided to start the query on index R on MSEG, using only part of the index (only one column) with no good uniqueness, accessing disk IO-Costs for this (60mi records), and expecting many interactions (loops) in memory to filter, see CPU-Costs.
So with the parameters you gave to SQL, they start in a very bad way.
2 After that program will access the MSEG commanded by what was found on First step, also with a huge loading from DB and filtering (another where criteria on MSEG fields, not found on index R), reducing the result set to 76.717 rows.
3/4 With this, program goes direct to primary key index on MKPF with direct access (optimized access) and follow to access database table MKPF.
5 At last will "loop" the result sets from MSEG and MKPF, mixing the tuplas generating the final result set.
Do you want to share your SQL, the parameters you are sending and code which generate it with us?
Regards, Fernando Da Ró

SQL query with Bind variable with slower execution plan

I have a 'normal' sql select-insert statement (not using bind variable) and it yields the following execution plan:-
Execution Plan
0 INSERT STATEMENT Optimizer=CHOOSE (Cost=7 Card=1 Bytes=148)
1 0 HASH JOIN (Cost=7 Card=1 Bytes=148)
2 1 TABLE ACCESS (BY INDEX ROWID) OF 'TABLEA' (Cost=4 Card=1 Bytes=100)
3 2 INDEX (RANGE SCAN) OF 'TABLEA_IDX_2' (NON-UNIQUE) (Cost=3 Card=1)
4 1 INDEX (FAST FULL SCAN) OF 'TABLEB_IDX_003' (NON-UNIQUE)
(Cost=2 Card=135 Bytes=6480)
Statistics
0 recursive calls
18 db block gets
15558 consistent gets
47 physical reads
9896 redo size
423 bytes sent via SQL*Net to client
1095 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
55 rows processed
I have the same query but instead running using bind variable (I test it with both oracle form and SQL*plus), it takes considerably longer with a different execution plan:-
Execution Plan
0 INSERT STATEMENT Optimizer=CHOOSE (Cost=407 Card=1 Bytes=148)
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'TABLEA' (Cost=3 Card=1 Bytes=100)
2 1 NESTED LOOPS (Cost=407 Card=1 Bytes=148)
3 2 INDEX (FAST FULL SCAN) OF TABLEB_IDX_003' (NON-UNIQUE) (Cost=2 Card=135 Bytes=6480)
4 2 INDEX (RANGE SCAN) OF 'TABLEA_IDX_2' (NON-UNIQUE) (Cost=2 Card=1)
Statistics
0 recursive calls
12 db block gets
3003199 consistent gets
54 physical reads
9448 redo size
423 bytes sent via SQL*Net to client
1258 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
55 rows processed
TABLEA has around 3million record while TABLEB has 300 records. Is there anyway I can improve the speed of the sql query with bind variable? I have DBA Access to the database
Regards
Ivan

Many thanks for your reply.
I have run the statistic already for the both tableA and tableB as well all the indexes associated with both table (using dbms_stats, I am on 9i db ) but not the indexed columns.
for table I use:-
begin
dbms_stats.gather_table_stats(ownname=> 'IVAN', tabname=> 'TABLEA', partname=> NULL);
end;
for index I use:-
begin
dbms_stats.gather_index_stats(ownname=> 'IVAN', indname=> 'TABLEB_IDX_003', partname=> NULL);
end;
Is it possible to show me a sample of how to collect statisc for INDEX columns stats?
regards
Ivan

Multiple Executions Plans for the same SQL statement

Dear experts,
awrsqrpt.sql is showing multiple executions plans for a single SQL statement. How is it possible that one SQL statement will have multiple Executions Plans within the same AWR report.
Below is the awrsqrpt's output for your reference.
WORKLOAD REPOSITORY SQL Report
Snapshot Period Summary
DB Name         DB Id    Instance     Inst Num Release     RAC Host
TESTDB          2157605839 TESTDB1               1 10.2.0.3.0 YES testhost1
              Snap Id      Snap Time      Sessions Curs/Sess
Begin Snap:     32541 11-Oct-08 21:00:13       248     141.1
End Snap:     32542 11-Oct-08 21:15:06       245     143.4
   Elapsed:               14.88 (mins)
   DB Time:               12.18 (mins)
SQL Summary                            DB/Inst: TESTDB/TESTDB1 Snaps: 32541-32542
                Elapsed
   SQL Id      Time (ms)
51szt7b736bmg     25,131
Module: SQL*Plus
UPDATE TEST SET TEST_TRN_DAY_CL = (SELECT (NVL(ACCT_CR_BAL,0) + NVL(ACCT_DR_BAL,
0)) FROM ACCT WHERE ACCT_TRN_DT = (:B1 ) AND TEST_ACC_NB = ACCT_ACC_NB(+)) WHERE
TEST_BATCH_DT = (:B1 )
SQL ID: 51szt7b736bmg                  DB/Inst: TESTDB/TESTDB1 Snaps: 32541-32542
-> 1st Capture and Last Capture Snap IDs
   refer to Snapshot IDs witin the snapshot range
-> UPDATE TEST SET TEST_TRN_DAY_CL = (SELECT (NVL(ACCT_CR_BAL,0) + NVL(AC...
    Plan Hash           Total Elapsed                 1st Capture   Last Capture
#   Value                    Time(ms)    Executions       Snap ID        Snap ID
1   2960830398                 25,131             1         32542          32542
2   3834848140                      0             0         32542          32542
Plan 1(PHV: 2960830398)
Plan Statistics                        DB/Inst: TESTDB/TESTDB1 Snaps: 32541-32542
-> % Total DB Time is the Elapsed Time of the SQL statement divided
   into the Total Database Time multiplied by 100
Stat Name                                Statement   Per Execution % Snap
Elapsed Time (ms)                            25,131       25,130.7     3.4
CPU Time (ms)                                23,270       23,270.2     3.9
Executions                                        1            N/A     N/A
Buffer Gets                               2,626,166    2,626,166.0    14.6
Disk Reads                                      305          305.0     0.3
Parse Calls                                       1            1.0     0.0
Rows                                        371,735      371,735.0     N/A
User I/O Wait Time (ms)                         564            N/A     N/A
Cluster Wait Time (ms)                            0            N/A     N/A
Application Wait Time (ms)                        0            N/A     N/A
Concurrency Wait Time (ms)                        0            N/A     N/A
Invalidations                                     0            N/A     N/A
Version Count                                     2            N/A     N/A
Sharable Mem(KB)                                 26            N/A     N/A
Execution Plan
| Id | Operation                    | Name            | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | UPDATE STATEMENT             |                 |       |       | 1110 (100)|          |
|   1 | UPDATE                      | TEST            |       |       |            |          |
|   2 |   TABLE ACCESS FULL          | TEST            |   116K| 2740K| 1110   (2)| 00:00:14 |
|   3 |   TABLE ACCESS BY INDEX ROWID| ACCT            |     1 |    26 |     5   (0)| 00:00:01 |
|   4 |    INDEX RANGE SCAN          | ACCT_DT_ACC_IDX |     1 |       |     4   (0)| 00:00:01 |
Plan 2(PHV: 3834848140)
Plan Statistics                        DB/Inst: TESTDB/TESTDB1 Snaps: 32541-32542
-> % Total DB Time is the Elapsed Time of the SQL statement divided
   into the Total Database Time multiplied by 100
Stat Name                                Statement   Per Execution % Snap
Elapsed Time (ms)                                 0            N/A     0.0
CPU Time (ms)                                     0            N/A     0.0
Executions                                        0            N/A     N/A
Buffer Gets                                       0            N/A     0.0
Disk Reads                                        0            N/A     0.0
Parse Calls                                       0            N/A     0.0
Rows                                              0            N/A     N/A
User I/O Wait Time (ms)                           0            N/A     N/A
Cluster Wait Time (ms)                            0            N/A     N/A
Application Wait Time (ms)                        0            N/A     N/A
Concurrency Wait Time (ms)                        0            N/A     N/A
Invalidations                                     0            N/A     N/A
Version Count                                     2            N/A     N/A
Sharable Mem(KB)                                 26            N/A     N/A
Execution Plan
| Id | Operation                    | Name         | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | UPDATE STATEMENT             |              |       |       |     2 (100)|          |
|   1 | UPDATE                      | TEST         |       |       |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID| TEST         |     1 |    28 |     2   (0)| 00:00:01 |
|   3 |    INDEX RANGE SCAN          | TEST_DT_IND |     1 |       |     1   (0)| 00:00:01 |
|   4 |   TABLE ACCESS BY INDEX ROWID| ACCT         |     1 |    26 |     4   (0)| 00:00:01 |
|   5 |    INDEX RANGE SCAN          | INDX_ACCT_DT |     1 |       |     3   (0)| 00:00:01 |
Full SQL Text
SQL ID       SQL Text
51szt7b736bm UPDATE TEST SET TEST_TRN_DAY_CL = (SELECT (NVL(ACCT_CR_BAL, 0) +
              NVL(ACCT_DR_BAL, 0)) FROM ACCT WHERE ACCT_TRN_DT = (:B1 ) AND PB
             RN_ACC_NB = ACCT_ACC_NB(+)) WHERE TEST_BATCH_DT = (:B1 )Your input is highly appreciated.
Thanks for taking your time in answering my question.
Regards

Oracle Lover3 wrote:
Dear experts,
awrsqrpt.sql is showing multiple executions plans for a single SQL statement. How is it possible that one SQL statement will have multiple Executions Plans within the same AWR report.If you're using bind variables and you've histograms on your columns which can be created by default in 10g due to the "SIZE AUTO" default "method_opt" parameter of DBMS_STATS.GATHER__STATS it is quite normal that you get different execution plans for the same SQL statement. Depending on the values passed when the statement is hard parsed (this feature is called "bind variable peeking" and enabled by default since 9i) an execution plan is determined and re-used for all further executions of the same "shared" SQL statement.
If now your statement ages out of the shared pool or is invalidated due to some DDL or statistics gathering activity it will be re-parsed and again the values passed in that particular moment will determine the execution plan. If you have skewed data distribution and a histogram in place that reflects that skewness you might get different execution plans depending on the actual values used.
Since this "flip-flop" behaviour can sometimes be counter-productive if you're unlucky and the values used to hard parse the statement leading to a plan that is unsuitable for the majority of values used afterwards, 11g introduced the "adaptive" cursor sharing that attempts to detect such a situation and can automatically re-evaluate the execution plan of the statement.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

NEW FEATURE:AUTOTRACE IN SQL*PLUS 3.3(EXECUTION PLAN)

제품 : SQL*PLUS
작성날짜 : 2003-10-07
NEW FEATURE:AUTOTRACE IN SQL*PLUS 3.3
======================================
Autotrace는 SQL*Plus 3.3부터 지원하는 New feature로서 기존에는 init.ora에
SQL_TRACE=TRUE를 setting 후 얻어진 trace file을 TKPROF란 utility를
이용하여 SQL 문의 수행 경로, 각종 통계 정보를 얻었다.
그러나, SQL*Plus 3.3부터는 이것을 간단히 처리할 수 있는 방법을 제공한다.
1. SQL*Plus를 실행하여 scott user로 접속한 후, plan table을 생성한다.
#sqlplus scott/tiger
SQL>@$ORACLE_HOME/rdbms/admin/utlxplan
2. 다음에 sys user에서 PLUSTRACE란 ROLE을 만든다.
SVRMGR>connect internal;
SVRMGR>create role plustrace;
SVRMGR>grant select on v_$sesstat to plustrace;
SVRMGR>grant select on v_$statname to plustrace;
SVRMGR>grant select on v_$session to plustrace;
SVRMGR>grant plustrace to dba with admin option;
SVRMGR>grant plustrace to scott;
비고) 위의 grant 문은 client에 SQL*Plus 3.3이 install되어 있는 경우
C:ORAWIN95\PLUS33\PLUSTRCE.SQL이라는 script에 기록되어 있다.
다음과 같이 실행해 주면 된다.
1> connect sys/manager
2> @$ORACLE_HOME/sqlplus/admin/plustrce.sql
3> grant plustrace to scott;
3. 다음에는 scott user로 connect하여 작업한다.
#sqlplus scott/tiger
SQL>set autotrace on
SQL>select * from emp;
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 TABLE ACCESS (FULL) OF 'EMP'
Statistics
389 recursive calls
5 db block gets
53 consistent gets
12 physical reads
0 redo size
1049 bytes sent via SQL*Net to client
239 bytes received via SQL*Net from client
4 SQL*Net round-trips to/from client
0 sorts (memory)
0 sorts (disk)
13 rows processed
4. 참고로 set autotrace에는 여러가지 option을 부여해 작업할 수도 있다.
예)set autotrace on => Explain plan and statistics.
set autotrace on explain => Explain plan only.
set autotrace traceonly => select된 결과는 빼고 trace만 display
시킴.
set autotrace on statistics=> sql statement execution statistics.
5. 서버 버젼과 상관없다.
Server가 7.2 version 이하일지라도 clinet에 SQL*Plus 3.3이 install되어
있으면 client에서 sqlplus 3.3을 구동시켜 server에 접속하여 위와 같이
작업하면 무리없이 작업이 가능하다.
Reference Documents
<Note:43214.1>

Hi Roman,
I don't have an Oracle 9.2 database readily available, but it works fine on 10g XE. Please note 3.1 is not certified with 9i:
http://www.oracle.com/technetwork/developer-tools/sql-developer/certification-096745.html
Regards,
Gary
SQL Developer Team

Different 'execution plans' for same sql in 10R2

DB=10.2.0.5
OS=RHEL 3
Im not sure of this, but seeing different plans for same SQL.
select sql_text from v$sqlarea where sql_id='92mb4z83fg4st'; <---TOP SQL from AWR
SELECT /*+ OPAQUE_TRANSFORM */ "ENDUSERID","LASTLOGINATTEMPTTIMESTAMP","LOGINSOURCECD","LOGINSUCCESSFLG",
"ENDUSERLOGINATTEMPTHISTORYID","VERSION_NUM","CREATEDATE"
FROM "BOMB"."ENDUSERLOGINATTEMPTHISTORY" "ENDUSERLOGINATTEMPTHISTORY";
SQL> set autotrace traceonly
SQL> SELECT /*+ OPAQUE_TRANSFORM */ "ENDUSERID","LASTLOGINATTEMPTTIMESTAMP","LOGINSOURCECD","LOGINSUCCESSFLG",
"ENDUSERLOGINATTEMPTHISTORYID","VERSION_NUM","CREATEDATE"
FROM "BOMB"."ENDUSERLOGINATTEMPTHISTORY" "ENDUSERLOGINATTEMPTHISTORY"; 2 3
1822203 rows selected.
Execution Plan
Plan hash value: 568996432
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1803K| 75M| 2919 (2)| 00:00:36 |
| 1 | TABLE ACCESS FULL| ENDUSERLOGINATTEMPTHISTORY | 1803K| 75M| 2919 (2)| 00:00:36 |
Statistics
0 recursive calls
0 db block gets
133793 consistent gets
0 physical reads
0 redo size
76637183 bytes sent via SQL*Net to client
1336772 bytes received via SQL*Net from client
121482 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1822203 rows processed
===================================== another plan ===============
SQL> select * from TABLE(dbms_xplan.display_awr('92mb4z83fg4st'));
15 rows selected.
Execution Plan
Plan hash value: 3015018810
| Id | Operation | Name |
| 0 | SELECT STATEMENT | |
| 1 | COLLECTION ITERATOR PICKLER FETCH| DISPLAY_AWR |
Note
- rule based optimizer used (consider using cbo)
Statistics
24 recursive calls
24 db block gets
49 consistent gets
0 physical reads
0 redo size
1529 bytes sent via SQL*Net to client
492 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
15 rows processed
=========second one shows only 15 rows...
Which one is correct ?

Understood, second plan is for self 'dbms_xplan'.
Anyhow I opened a new session where I did NOT on 'auto-trace'. but plan is somewhat than the original.
SQL> /
PLAN_TABLE_OUTPUT
SQL_ID 92mb4z83fg4st
SELECT /*+ OPAQUE_TRANSFORM */ "ENDUSERID","LASTLOGINATTEMPTTIMESTAMP","LOGINSOURCECD","
LOGINSUCCESSFLG","ENDUSERLOGINATTEMPTHISTORYID","VERSION_NUM","CREATEDATE" FROM
"BOMB"."ENDUSERLOGINATTEMPTHISTORY" "ENDUSERLOGINATTEMPTHISTORY"
Plan hash value: 568996432
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
PLAN_TABLE_OUTPUT
| 0 | SELECT STATEMENT | | | | 2919 (100)| |
| 1 | TABLE ACCESS FULL| ENDUSERLOGINATTEMPTHISTORY | 1803K| 75M| 2919 (2)| 00:00:36 |
15 rows selected.
I am just wondering, which plan is the accurate and which I need to believe ?

Tool to find the execution plan of a SQL query

Hi,
I new to Oracle. I come from the SQL Server world.
I would like to know what tool(s) should I use to identify the execution plan for a SQL statement and to see if a query is missing indices.
Thanks,
Paul

Use SQL*PLUS.
SQL> select dummy from dual;
D
X
SQL> set autotrace on explain
SQL> r
1* select dummy from dual
D
X
Execution Plan
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=1 Bytes=2)
   1    0   TABLE ACCESS (FULL) OF 'DUAL' (TABLE) (Cost=2 Card=1 Bytes
          =2)
SQL> set autot off
SQL> explain plan for select dummy from dual;
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 1157671242
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      |     1 |     2 |     2   (0)| 00:00:01 |
|   1 | TABLE ACCESS FULL| DUAL |     1 |     2 |     2   (0)| 00:00:01 |
8 rows selected.
SQL> disconnect
Disconnected from Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - 64bit Production
With the Partitioning, Oracle Label Security, OLAP and Data Mining options
SQL>

Partitioned views in SQL 2014 have incorrect execution plans

I've been using partitioned views in the past
and used the check constraint in the source tables to make sure the only the table with the condition in the where clause on the view was used. In SQL Server 2012 this was working just fine (I had to do some tricks to suppress parameter sniffing, but it was
working correct after doing that). Now I've been installing SQL Server 2014 Developer and used exactly the same logic and in the actual query plan it is still using the other tables. I've tried the following things to avoid this:
- OPTION (RECOMPILE)
- Using dynamic SQL to pass the parameter values as a static string.
- Set the lazy schema validation option to true on the linked servers
To explain wat I'm doing is this:
1. I have 3 servers with the same source tables, the only difference in the tables is one column with the server name.
2. I've created a CHECK CONSTRAINT on the server name column on each server.
3. On one of the three server (in my case server 3) I've setup linked server connections to Server 1 and 2.
4. On Server 3 I've created a partioned view that is build up like this:
SELECT * FROM [server1].[database].[dbo].[table]
UNION ALL SELECT * FROM [server2].[database].[dbo].[table]
UNION ALL SELECT * FROM [server3].[database].[dbo].[table]
5. To query the partioned view I use a query like this:
SELECT *
FROM [database].[dbo].[partioned_view_name]
WHERE [server_name] = 'Server2'
Now when I look at the execution plan on the 2014 environment it is still using all the servers instead of just Server2 like it should be. The strange thing is that SQL 2008 and 2012 are working just fine but 2014 seems not to use the correct plan. Maybe I
forgot something, or something is changed in 2014 and a new approach is needed but I'm a little stuck here.
Did someone experience the same thing and if so, how did you fix this?

Hi Jos,
Glad to hear that you have found a solution for your problem. Thank you for your sharing which will help other forum members who have the similar issue.
Regards,
Charlie Liao
TechNet Community Support

Current running SQL stms execution plan?

Hi,
Is it any ways to findout the current running SQL stms execution plan?
without using Explain plan & autotrace.
Thanks in advance,
Thomas.

I'm using this code. You just have to give the Session Identifier (&SID ):SELECT     '| Operation                                     | Objet   | Lignes| Bytes| Cout | Pstart| Pstop |' as "Plan Table" FROM DUAL
UNION ALL
SELECT     '----------------------------------------------------------------------------------------------------' FROM DUAL
UNION ALL
SELECT * FROM
         (SELECT /*+ NO_MERGE */
          RPAD('| '||
               SUBSTR(
                    LPAD(' ',1*(LEVEL-1)) || OPERATION || DECODE(OPTIONS, NULL,'',' '||OPTIONS), 1, 47
                     ), 48, ' '
          )||'|'||
          RPAD(
               SUBSTR(OBJECT_NAME||' ',1, 9), 10, ' '
          )||'|'||
          LPAD(
               DECODE(CARDINALITY,
                    NULL,' ',
                    DECODE(SIGN(CARDINALITY-1000),
                          -1, CARDINALITY||' ',
                         DECODE(SIGN(CARDINALITY-1000000),
                               -1,TRUNC(CARDINALITY/1000)||'K',
                              DECODE(SIGN(CARDINALITY-1000000000),
                                   -1,TRUNC(CARDINALITY/1000000)||'M',
                                   TRUNC(CARDINALITY/1000000000)||'G')
                    ), 7, ' '
          )||'|'||
          LPAD(
               DECODE(BYTES,
                    NULL,' ',
                    DECODE(SIGN(BYTES-1024),
                         -1, BYTES||' ',
                         DECODE(SIGN(BYTES-1048576),
                              -1, TRUNC(BYTES/1024)||'K',
                              DECODE(SIGN(BYTES-1073741824),
                                   -1,TRUNC(BYTES/1048576)||'M',
                                   TRUNC(BYTES/1073741824)||'G')
                    ), 6, ' '
          )||'|'||
          LPAD(
               DECODE(COST,
                    NULL,' ',
                    DECODE(SIGN(COST-10000000),
                         -1, COST||' ',
                         DECODE(SIGN(COST-1000000000),
                              -1, TRUNC(COST/1000000)||'M',
                              TRUNC(COST/1000000000)||'G')
                    ), 8, ' '
          )||'|'||
          LPAD(
               DECODE(PARTITION_START,
                    'ROW LOCATION', 'ROWID',
                    DECODE(PARTITION_START,
                         'KEY', 'KEY',
                         DECODE(PARTITION_START,
                              'KEY(INLIST)', 'KEY(I)',
                              DECODE(SUBSTR(PARTITION_START, 1, 6),
                                   'NUMBER', SUBSTR(SUBSTR(PARTITION_START, 8, 10), 1,LENGTH(SUBSTR(PARTITION_START, 8, 10))-1),
                                   DECODE(PARTITION_START,
                                        NULL,' ',
                                        PARTITION_START)
                    )||' ', 7, ' '
          )||'|'||
          LPAD(
               DECODE(PARTITION_STOP,
                    'ROW LOCATION', 'ROW L',
                    DECODE(PARTITION_STOP,
                         'KEY', 'KEY',
                         DECODE(PARTITION_STOP,
                              'KEY(INLIST)', 'KEY(I)',
                              DECODE(SUBSTR(PARTITION_STOP, 1, 6),
                              'NUMBER', SUBSTR(SUBSTR(PARTITION_STOP, 8, 10), 1,LENGTH(SUBSTR(PARTITION_STOP, 8, 10))-1),
                              DECODE(PARTITION_STOP,
                                   NULL,' ',
                                   PARTITION_STOP)
               )||' ', 7, ' '
          )||'|' AS "Explain plan"
     FROM V$SQL_PLAN
     START WITH (ADDRESS = (SELECT SQL_ADDRESS FROM V$SESSION WHERE SID=&SID)
               AND HASH_VALUE = (SELECT SQL_HASH_VALUE FROM V$SESSION WHERE SID=&SID)
               AND CHILD_NUMBER = 0
               AND ID=0 )
     CONNECT BY PRIOR ID = PARENT_ID
                    AND PRIOR ADDRESS = ADDRESS
                    AND PRIOR HASH_VALUE = HASH_VALUE
                    AND PRIOR CHILD_NUMBER = CHILD_NUMBER
     ORDER BY ID, POSITION)
UNION ALL
SELECT '----------------------------------------------------------------------------------------------------' FROM DUAL;Regards,
Yoann.

SQL Query C# Using Execution Plan Cache Without SP

I have a situation where i am executing an SQL query thru c# code. I cannot use a stored procedure because the database is hosted by another company and i'm not allowed to create any new procedures. If i run my query on the sql mgmt studio the first time
is approx 3 secs then every query after that is instant. My query is looking for date ranges and accounts. So if i loop thru accounts each one takes approx 3 secs in my code. If i close the program and run it again the accounts that originally took 3 secs
now are instant in my code. So my conclusion was that it is using an execution plan that is cached. I cannot find how to make the execution plan run on non-stored procedure code. I have created a sqlcommand object with my queary and 3 params. I loop thru each
one keeping the same command object and only changing the 3 params. It seems that each version with the different params are getting cached in the execution plans so they are now fast for that particular query. My question is how can i get sql to not do this
by either loading the execution plan or by making sql think that my query is the same execution plan as the previous? I have found multiple questions on this that pertain to stored procedures but nothing i can find with direct text query code.
Bob;

I did the query running different accounts and different dates with instant results AFTER the very first query that took the expected 3 secs. I changed all 3 fields that i've got code for parameters for and it still remains instant in the mgmt studio but
still remains slow in my code. I'm providing a sample of the base query i'm using.
select i.Field1, i.Field2,
d.Field3 'Field3',
ip.Field4 'Field4',
k.Field5 'Field5'
from SampleDataTable1 i,
SampleDataTable2 k,
SampleDataTable3 ip,
SampleDataTable4 d
where i.Field1 = k.Field1 and i.Field4 = ip.Field4
i.FieldDate between '<fromdate>' and '<thrudate>'
and k.Field6 = <Account>
Obviously the field names have been altered because the database is not mine but other then the actual names it is accurate. It works it just takes too long in code as described in the initial post.
My params setup during the init for the connection and the command.
sqlCmd.Parameters.Add("@FromDate", SqlDbType.DateTime);
sqlCmd.Parameters.Add("@ThruDate", SqlDbType.DateTime);
sqlCmd.Parameters.Add("@Account", SqlDbType.Decimal);
Each loop thru the code changes these 3 fields.
sqlCommand.Parameters["@FromDate"].Value = dtFrom;
sqlCommand.Parameters["@ThruDate"].Value = dtThru;
sqlCommand.Parameters["@Account"].Value = sAccountNumber;
SqlDataReader reader = sqlCommand.ExecuteReader();
while (reader.Read())
reader.Close();
One thing i have noticed is that the account field is decimal(20,0) and by default the init i'm using defaults to decimal(10) so i'm going to change the init to
sqlCmd.Parameters["@Account"].Precision = 20;
sqlCmd.Parameters["@Account"].Scale = 0;
I don't believe this would change anything but at this point i'm ready to try anything to get the query running faster.
Bob;

SQL - Need Tunning tips for group by [LATEST EXECUTION PLAN IS ATTACHED]

Hi All Experts,
My SQL is taking so much time to execute. If I remove the group by clause it is running within a minute but as soon as I am putting sum() and group by clause it is taking ages to run the sql. Number of records are wihout group by clause is almost 85 Lachs (8 Million). Is hugh dataset is killing this? Is there any way to tune the data on Group by clause. Below is my Select hints and execution plan. Please help.
SQL
SELECT /*+ CURSOR_SHARING_EXACT gather_plan_statistics all_rows no_index(atm) no_expand
leading (src cpty atm)
index(bk WBKS_PK) index(src WSRC_UK1) index(acct WACC_UK1)
use_nl(acct src ccy prd cpty grate sb) */
EXECUTION PLAN
PLAN_TABLE_OUTPUT
SQL_ID 1y5pdhnb9tks5, child number 0
SELECT /*+ CURSOR_SHARING_EXACT gather_plan_statistics all_rows no_index(atm) no_expand leading (src cpty atm) index(bk
WBKS_PK) index(src WSRC_UK1) index(acct WACC_UK1) use_nl(acct src ccy prd cpty grate sb) */ atm.business_date,
atm.entity legal_entity, TO_NUMBER (atm.set_of_books) setofbooksid, atm.source_system_id sourcesystemid,
ccy.ccy_currency_code ccy_currency_code, acct.acct_account_code, 0 gl_bal, SUM (atm.amount)
atm_bal, 0 gbp_equ, ROUND (SUM (atm.amount * grate.rate), 4) AS
atm_equ, prd.prd_product_code, glacct.parentreportingclassification parentreportingclassification,
cpty_counterparty_code FROM wh_sources_d src,
Plan hash value: 4193892926
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads | OMem | 1Mem | Used-Mem |
| 1 | HASH GROUP BY | | 1 | 1 | 471 |00:31:38.26 | 904M| 76703 | 649K| 649K| 1149K (0)|
| 2 | NESTED LOOPS | | 1 | 1 | 8362K|00:47:06.06 | 904M| 76703 | | | |
| 3 | NESTED LOOPS | | 1 | 1 | 10M|00:28:48.84 | 870M| 17085 | | | |
| 4 | NESTED LOOPS | | 1 | 1 | 10M|00:27:56.05 | 849M| 17084 | | | |
| 5 | NESTED LOOPS | | 1 | 8 | 18M|00:14:10.93 | 246M| 17084 | | | |
| 6 | NESTED LOOPS | | 1 | 22 | 18M|00:11:58.96 | 189M| 17084 | | | |
| 7 | NESTED LOOPS | | 1 | 22 | 18M|00:10:24.69 | 152M| 17084 | | | |
| 8 | NESTED LOOPS | | 1 | 1337 | 18M|00:06:00.74 | 95M| 17083 | | | |
| 9 | NESTED LOOPS | | 1 | 1337 | 18M|00:02:52.20 | 38M| 17073 | | | |
|* 10 | HASH JOIN | | 1 | 185K| 18M|00:03:46.38 | 1177K| 17073 | 939K| 939K| 575K (0)|
| 11 | NESTED LOOPS | | 1 | 3 | 3 |00:00:00.01 | 11 | 0 | | | |
| 12 | TABLE ACCESS BY INDEX ROWID | WH_SOURCES_D | 1 | 3 | 3 |00:00:00.01 | 3 | 0 | | | |
|* 13 | INDEX RANGE SCAN | WSRC_UK1 | 1 | 3 | 3 |00:00:00.01 | 2 | 0 | | | |
|* 14 | TABLE ACCESS BY INDEX ROWID | WH_COUNTERPARTIES_D | 3 | 1 | 3 |00:00:00.01 | 8 | 0 | | | |
|* 15 | INDEX UNIQUE SCAN | WCPY_U1 | 3 | 1 | 3 |00:00:00.01 | 5 | 0 | | | |
| 16 | PARTITION RANGE SINGLE | | 1 | 91M| 91M|00:00:00.08 | 1177K| 17073 | | | |
|* 17 | TABLE ACCESS FULL | WH_ATM_BALANCES_F | 1 | 91M| 91M|00:00:00.04 | 1177K| 17073 | | | |
|* 18 | TABLE ACCESS BY INDEX ROWID | WH_PRODUCTS_D | 18M| 1 | 18M|00:01:43.88 | 37M| 0 | | | |
|* 19 | INDEX UNIQUE SCAN | WPRD_UK1 | 18M| 1 | 18M|00:00:52.13 | 18M| 0 | | | |
|* 20 | TABLE ACCESS BY GLOBAL INDEX ROWID| WH_BOOKS_D | 18M| 1 | 18M|00:02:53.01 | 56M| 10 | | | |
|* 21 | INDEX UNIQUE SCAN | WBKS_PK | 18M| 1 | 18M|00:01:08.32 | 37M| 10 | | | |
|* 22 | TABLE ACCESS BY INDEX ROWID | T_SDM_SOURCEBOOK | 18M| 1 | 18M|00:03:43.66 | 56M| 1 | | | |
|* 23 | INDEX RANGE SCAN | TSSB_N5 | 18M| 2 | 23M|00:01:11.50 | 18M| 1 | | | |
|* 24 | TABLE ACCESS BY INDEX ROWID | WH_CURRENCIES_D | 18M| 1 | 18M|00:01:51.21 | 37M| 0 | | | |
|* 25 | INDEX UNIQUE SCAN | WCUR_PK | 18M| 1 | 18M|00:00:49.26 | 18M| 0 | | | |
| 26 | TABLE ACCESS BY INDEX ROWID | WH_GL_DAILY_RATES_F | 18M| 1 | 18M|00:01:55.84 | 56M| 0 | | | |
|* 27 | INDEX UNIQUE SCAN | WGDR_U2 | 18M| 1 | 18M|00:01:10.89 | 37M| 0 | | | |
| 28 | INLIST ITERATOR | | 18M| | 10M|00:22:40.03 | 603M| 0 | | | |
|* 29 | TABLE ACCESS BY INDEX ROWID | WH_ACCOUNTS_D | 150M| 1 | 10M|00:20:19.05 | 603M| 0 | | | |
|* 30 | INDEX UNIQUE SCAN | WACC_UK1 | 150M| 5 | 150M|00:10:16.81 | 452M| 0 | | | |
| 31 | TABLE ACCESS BY INDEX ROWID | T_SDM_GLACCOUNT | 10M| 1 | 10M|00:00:50.64 | 21M| 1 | | | |
|* 32 | INDEX UNIQUE SCAN | TSG_PK | 10M| 1 | 10M|00:00:26.17 | 10M| 0 | | | |
|* 33 | TABLE ACCESS BY INDEX ROWID | WH_COMMON_TRADES_D | 10M| 1 | 8362K|00:18:52.56 | 33M| 59618 | | | |
|* 34 | INDEX UNIQUE SCAN | WCTD_PK | 10M| 1 | 10M|00:03:06.56 | 21M| 5391 | | | |
Edited by: user535789 on Mar 17, 2011 9:45 PM
Edited by: user535789 on Mar 20, 2011 8:33 PM

user535789 wrote:
Hi All Experts,
My SQL is taking so much time to execute. If I remove the group by clause it is running within a minute but as soon as I am putting sum() and group by clause it is taking ages to run the sql. Number of records are wihout group by clause is almost 85 Lachs (*8 Million*). Is hugh dataset is killing this? Is there any way to tune the data on Group by clause. Below is my Select hints and execution plan. Please help.I doubt that your 8 million records are shown within minutes.
I guess that the output started after a few minutes. But this does not mean that the full resultset is there. It just means the database is able to return to you the first few records after a few minutes.
Once you add a group by (or an order by) then this requires that all the rows need to be fetched before the database can start showing them to you.
But maybe you could run some tests to compare the full output. I find it useful to SET AUTOTRACE TRACEONLY for such a purpose (in sql plus). This avoids to print the selection on the screen.

Sql execution plan

Similar Messages

Maybe you are looking for