TUNNING A SQL QUERY AND UNSERSTAND EXPLAIN PLAN
I was trying my handing in tunning sql queries -
Though I have manged to reduce the cost lil ..creating some index, but have genarated a g8 interesting in tunning - Can some experts ( I know there are lots available :-) ) help me on the approch on "HOW TO TUNE A QUERY"
moreover I also would like to understand - how to debug a explain plan, - please help ...
Regards..
Hi,
Welcome to this forum...
I would suggest your to read first the official documentations :
- The concepts of an Oracle DBMS (this is important to know, because Oracle structures, processes, objects (etc) are the building blocks of your database)
- SQL reference guide
- PL/SQL reference guide
and then at a later stage the Performance and tuning guide:
You can start there:
http://download.oracle.com/docs/cd/B14117_01/nav/portal_1.htm
Once it's done maybe read the Performance and tuning guide:
http://download.oracle.com/docs/cd/B14117_01/server.101/b10752/toc.htm
(Chapter 19 explain ... how to interpret the explain plan ..)
I wish you good chance and be patient: I'm working with Oracle for more that 10 years and I'm still learning! ...
Rem: The Oracle website is full of interesting articles, and examples, just "search" your special points of interests ..
Similar Messages
-
SQL Query to get Project Plan Name and Resource Name from Reporting database of Project Server 2007
Can you please help me to write an SQL Query to get Project Plan Name and Resource Name from Reporting database of Project Server 2007. Thanks!!
Refer
http://gallery.technet.microsoft.com/projectserver/Server-20072010-SQL-Get-a99d4bc6
SELECT
dbo.MSP_EpmAssignment_UserView.ProjectUID,
dbo.MSP_EpmAssignment_UserView.TaskUID,
dbo.MSP_EpmProject_UserView.ProjectName,
dbo.MSP_EpmTask_UserView.TaskName,
dbo.MSP_EpmAssignment_UserView.ResourceUID,
dbo.MSP_EpmResource_UserView.ResourceName,
dbo.MSP_EpmResource_UserView.ResourceInitials
INTO #TempTable
FROM dbo.MSP_EpmAssignment_UserView INNER JOIN
dbo.MSP_EpmProject_UserView ON dbo.MSP_EpmAssignment_UserView.ProjectUID = dbo.MSP_EpmProject_UserView.ProjectUID INNER JOIN
dbo.MSP_EpmTask_UserView ON dbo.MSP_EpmAssignment_UserView.TaskUID = dbo.MSP_EpmTask_UserView.TaskUID INNER JOIN
dbo.MSP_EpmResource_UserView ON dbo.MSP_EpmAssignment_UserView.ResourceUID = dbo.MSP_EpmResource_UserView.ResourceUID
SELECT
ProjectUID,
TaskUID,
ProjectName,
TaskName,
STUFF((
SELECT ', ' + ResourceInitials
FROM #TempTable
WHERE (TaskUID = Results.TaskUID)
FOR XML PATH (''))
,1,2,'') AS ResourceInitialsCombined,
STUFF((
SELECT ', ' + ResourceName
FROM #TempTable
WHERE (TaskUID = Results.TaskUID)
FOR XML PATH (''))
,1,2,'') AS ResourceNameCombined
FROM #TempTable Results
GROUP BY TaskUID,ProjectUID,ProjectName,TaskName
DROP TABLE #TempTable
-Prashanth -
Same query with different explain plans
Hi All,
I have one of the select query with different explain plans on two separate env, the query fetches the correct index on test env whereas on prod it's not fetching the same index.
The structure, indices, no. of rows are similar in CRMINFO table with up-to-date statistics.
Env Details :
OS - Sun Solaris 5.10
DB - 10.2.0.4
Init param:
Optimizer_mode = ALL_ROWS
optimizer_dynamic_sampling integer 5
optimizer_features_enable string 10.2.0.4
optimizer_index_caching integer 90
optimizer_index_cost_adj integer 30
Query :*
SELECT COUNT (*)
FROM CRMINFO
WHERE RETAILER = :1
AND STATUS = 20
AND EXC = :1
AND SUBNO IS NULL
Expain Plan (TST):
SELECT STATEMENT ALL_ROWSCost: 916 Bytes: 19 Cardinality: 1
3 SORT AGGREGATE Bytes: 19 Cardinality: 1
2 TABLE ACCESS BY INDEX ROWID TABLE TST.CRMINFO Cost: 916 Bytes: 16,663 Cardinality: 877
1 INDEX RANGE SCAN INDEX TST.CRMINFO_X1 Cost: 42 Cardinality: 12,549
Index (TST):
CRMINFO_X1(EXC, RETAILER, STATUS)
Explain Plan (PROD):
SELECT STATEMENT ALL_ROWSCost: 1,832 Bytes: 19 Cardinality: 1
3 SORT AGGREGATE Bytes: 19 Cardinality: 1
2 TABLE ACCESS BY INDEX ROWID TABLE PROD.CRMINFO Cost: 1,832 Bytes: 2,052 Cardinality: 108
1 INDEX RANGE SCAN INDEX PROD.CRMINFO_X2 Cost: 117 Cardinality: 42,519
Index (PROD):
CRMINFO_X2 (RETAILER)
How does Oracle calculates the cost and decides which index it should fetch ? Why it didn't choose the same index as of test env? How should i approach and which domains i need to dig-in to find the cause?
I did try playing with the above mentioned init parameters but it didn't help at all.
Thanks.
Regards,
~PointerPointer wrote:
Hmm, my worry is how do i force oracle to grap the proper index on prod i.e (CRMINFO_X1). I certainly believe it's a bad approach on adding a hint in the select statement and to force oralce to fetch that index.Why do you believe that, the index you mention is the "proper" index versus what Oracle is choosing? Can you prove with hinting that the "proper" index results in a faster and more efficient execution plan? If it does, then the next place I would look at is the statistics for the tables and columns of interest. From here you could try and estimate why Oracle thinks the other index is better. Another option is to run a 10053 (CBO) trace and see why Oracle thinks it is better.
I would not support a hint in a production environment, except in the most extreme cases. Usually the CBO makes the right choice, but it only can if the statistics match the distribution of data.
Refreshing the data may help me simulating the issue on TST but it wouldn't help me to understand why on prod it uses CRMINFO_X2 instead of CRMINFO_X1 which has all the three columns in the Where clause of the query.It would help because it's a test environment and you wouldn't have to do any queries directly on your production system to achieve the same results.
>
A bad thought here :( , if i create a new index by changing the column positioning say like ( RETAILER, STATUS , EXC) instead of (EXC, RETAILER, STATUS) will oracle fetch it ? or would it help in reducing the cost and cardinatlity of the select query.It's not that easy. There is a lot that goes into the cost calculation, some of that is known (through the great work by Jonathan Lewis and Richard Foote), and some of that is purely internal to Oracle. If you are more interested in the internals Cost-Based Oracle Fundamentals by Jonathan Lewis is a great book.
HTH! -
SQL Tuning- slow query on GL_BALANCES- Explain plan provided
Hi- I really need some help here.
The following SQL statement has been identified to perform poorly.
It currently takes from 2-3 minutes to execute. I see it is because GL_BALANCES has so many rows.
Is there any way around this? Explain and info below. Thanks gurus!
This is the SQL statement:
SELECT DISTINCT GLB.CODE_COMBINATION_ID CCID
FROM gl_balances GLB, gl_code_combinations GCC
WHERE GLB.ACTUAL_FLAG = 'A'
AND GLB.Last_Update_Date > to_date('11-JAN-2010','DD-MON-YYYY')
AND GLB.code_combination_id = GCC.code_combination_id
AND EXISTS (
SELECT 1
FROM fnd_flex_value_sets A, fnd_flex_values B
WHERE A.flex_value_set_name = 'XXX_XXX'
AND UPPER(B.ATTRIBUTE3) = 'APPORTIONMENT'
AND A.flex_value_set_id = b.flex_value_set_id
AND GCC.segment11 = b.flex_value
);The version of the database is 11.1.0.7.
These are the parameters relevant to the optimizer:
NAME TYPE VALUE
optimizerautostats_job boolean FALSE
optimizerextended_cursor_sharing_r string NONE
el
optimizer_capture_sql_plan_baselines boolean FALSE
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 11.1.0.7
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean FALSE
optimizer_use_invisible_indexes boolean FALSE
NAME TYPE VALUE
optimizer_use_pending_statistics boolean FALSE
optimizer_use_sql_plan_baselines boolean TRUE
SQL> show parameter db_file_multi
NAME TYPE VALUE
db_file_multiblock_read_count integer 128
SQL> show parameter db_block_size
NAME TYPE VALUE
db_block_size integer 8192
SQL> show parameter cursor_sharing
NAME TYPE VALUE
optimizerextended_cursor_sharing_r string NONE
el
cursor_sharing string EXACT
select
2 sname
3 , pname
4 , pval1
5 , pval2
6 from
7 sys.aux_stats$;
SNAME PNAME PVAL1
PVAL2
SYSSTATS_INFO STATUS
COMPLETED
SYSSTATS_INFO DSTART
09-02-2006 14:35
SYSSTATS_INFO DSTOP
09-02-2006 14:35
SNAME PNAME PVAL1
PVAL2
SYSSTATS_INFO FLAGS 1
SYSSTATS_MAIN CPUSPEEDNW 451.262136
SYSSTATS_MAIN IOSEEKTIM 10
SNAME PNAME PVAL1
PVAL2
SYSSTATS_MAIN IOTFRSPEED 4096
SYSSTATS_MAIN SREADTIM
SYSSTATS_MAIN MREADTIM
SNAME PNAME PVAL1
PVAL2
SYSSTATS_MAIN CPUSPEED
SYSSTATS_MAIN MBRC
SYSSTATS_MAIN MAXTHR
SNAME PNAME PVAL1
PVAL2
SYSSTATS_MAIN SLAVETHR
13 rows selected.
SQL> explain plan for
2 SELECT DISTINCT GLB.CODE_COMBINATION_ID CCID
3 FROM gl_balances GLB, gl_code_combinations GCC
4 WHERE GLB.code_combination_id = GCC.code_combination_id
5 AND GLB.ACTUAL_FLAG = 'A'
6 AND GLB.Last_Update_Date > '11-JAN-2010'
7 AND EXISTS (SELECT 1
8 FROM fnd_flex_value_sets A, fnd_flex_values B
9 WHERE A.flex_value_set_id = b.flex_value_set_id
10 AND A.flex_value_set_name = 'XXX_XXX'
11 AND UPPER(B.ATTRIBUTE3) = 'APPORTIONMENT'
12 AND GCC.segment11 = b.flex_value);
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 1839014065
| Id | Operation | Name | Rows | By
tes | Cost (%CPU)| Time |
PLAN_TABLE_OUTPUT
| 0 | SELECT STATEMENT | | 4102 |
296K| 955K (3)| 03:11:03 |
| 1 | HASH UNIQUE | | 4102 |
296K| 955K (3)| 03:11:03 |
|* 2 | HASH JOIN | | 4102 |
296K| 955K (3)| 03:11:03 |
| 3 | NESTED LOOPS | | |
| | |
PLAN_TABLE_OUTPUT
| 4 | NESTED LOOPS | | 23907 | 1
354K| 2598 (1)| 00:00:32 |
| 5 | NESTED LOOPS | | 1 |
45 | 5 (0)| 00:00:01 |
| 6 | TABLE ACCESS BY INDEX ROWID| FND_FLEX_VALUE_SETS | 1 |
28 | 2 (0)| 00:00:01 |
|* 7 | INDEX UNIQUE SCAN | FND_FLEX_VALUE_SETS_U2 | 1 |
PLAN_TABLE_OUTPUT
| 1 (0)| 00:00:01 |
|* 8 | TABLE ACCESS BY INDEX ROWID| FND_FLEX_VALUES | 1 |
17 | 3 (0)| 00:00:01 |
|* 9 | INDEX RANGE SCAN | FND_FLEX_VALUES_N2 | 53 |
| 1 (0)| 00:00:01 |
|* 10 | INDEX RANGE SCAN | GL_CODE_COMBINATIONS_N11 | 25427 |
| 106 (1)| 00:00:02 |
PLAN_TABLE_OUTPUT
| 11 | TABLE ACCESS BY INDEX ROWID | GL_CODE_COMBINATIONS | 18664 |
236K| 2593 (1)| 00:00:32 |
|* 12 | TABLE ACCESS FULL | GL_BALANCES | 1022K|
15M| 952K (3)| 03:10:32 |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
2 - access("GLB"."CODE_COMBINATION_ID"="GCC"."CODE_COMBINATION_ID")
7 - access("A"."FLEX_VALUE_SET_NAME"='SSA_SGL')
8 - filter(UPPER("B"."ATTRIBUTE3")='APPORTIONMENT')
9 - access("A"."FLEX_VALUE_SET_ID"="B"."FLEX_VALUE_SET_ID")
10 - access("GCC"."SEGMENT11"="B"."FLEX_VALUE")
12 - filter("GLB"."LAST_UPDATE_DATE">TO_DATE(' 2010-01-11 00:00:00', 'syyyy-mm
-dd hh24:mi:ss') AND
"GLB"."ACTUAL_FLAG"='A')
30 rows selected.As per the other replies, you've not really given enough information to go on - what are you trying to achieve, versions, etc.
On my old apps 11.5.8 system, the explain plan for your query uses GL_CODE_COMBINATIONS_U1 rather than a full scan of gl_code_combinations.
Check your stats are up to date (select table_name, num_rows, last_analyzed from dba_tables where ...)
See if you can also use period_name and/or period_set_name (or period_num) from GL_Periods rather than period_year (i.e. use P_YEAR to lookup the period_name/period_set_name/period_num from gl_periods). It might be faster to do per period and then consolidate for the whole year, as there are indexes on gl_balances for columns period_name, period_set_name, period_num.
regards, Ivan -
Query with diff. explain plans
Hi,
Our query returns different execution plans in Prod and non-prod. It is slow in PROD. The data size is the same in both DBs and stats are gathered at 50% estimate for both schemas:
Prod (slow) explain plan:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 852 | 33 (4)| 00:00:01 |
|* 1 | FILTER | | | | | |
| 2 | HASH GROUP BY | | 1 | 852 | 33 (4)| 00:00:01 |
| 3 | NESTED LOOPS | | 1 | 852 | 32 (0)| 00:00:01 |
| 4 | NESTED LOOPS | | 1 | 802 | 31 (0)| 00:00:01 |
| 5 | NESTED LOOPS OUTER | | 1 | 785 | 30 (0)| 00:00:01 |
| 6 | NESTED LOOPS OUTER | | 1 | 742 | 29 (0)| 00:00:01 |
| 7 | NESTED LOOPS | | 1 | 732 | 29 (0)| 00:00:01 |
| 8 | NESTED LOOPS | | 1 | 678 | 26 (0)| 00:00:01 |
| 9 | NESTED LOOPS | | 1 | 666 | 26 (0)| 00:00:01 |
| 10 | NESTED LOOPS | | 1 | 623 | 25 (0)| 00:00:01 |
| 11 | NESTED LOOPS | | 1 | 580 | 24 (0)| 00:00:01 |
| 12 | NESTED LOOPS | | 1 | 576 | 24 (0)| 00:00:01 |
| 13 | NESTED LOOPS | | 2 | 1076 | 13 (0)| 00:00:01 |
| 14 | NESTED LOOPS | | 2 | 1040 | 13 (0)| 00:00:01 |
| 15 | NESTED LOOPS | | 2 | 1028 | 13 (0)| 00:00:01 |
| 16 | NESTED LOOPS | | 2 | 996 | 13 (0)| 00:00:01 |
| 17 | NESTED LOOPS | | 2 | 988 | 13 (0)| 00:00:01 |
| 18 | NESTED LOOPS | | 2 | 954 | 13 (0)| 00:00:01 |
| 19 | NESTED LOOPS | | 2 | 944 | 13 (0)| 00:00:01 |
| 20 | NESTED LOOPS | | 2 | 920 | 13 (0)| 00:00:01 |
| 21 | NESTED LOOPS | | 2 | 912 | 13 (0)| 00:00:01 |
| 22 | NESTED LOOPS | | 2 | 826 | 11 (0)| 00:00:01 |
| 23 | NESTED LOOPS | | 1 | 370 | 9 (0)| 00:00:01 |
| 24 | NESTED LOOPS | | 1 | 306 | 8 (0)| 00:00:01 |
| 25 | NESTED LOOPS | | 1 | 263 | 7 (0)| 00:00:01 |
| 26 | NESTED LOOPS | | 1 | 220 | 6 (0)| 00:00:01 |
| 27 | NESTED LOOPS | | 1 | 177 | 5 (0)| 00:00:01 |
| 28 | NESTED LOOPS | | 1 | 129 | 4 (0)| 00:00:01 |
| 29 | NESTED LOOPS | | 1 | 86 | 3 (0)| 00:00:01 |
| 30 | TABLE ACCESS BY INDEX ROWID| SYMMETADATA | 1 | 43 | 2 (0)| 00:00:01 |
|* 31 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 1 (0)| 00:00:01 |
| 32 | TABLE ACCESS BY INDEX ROWID| SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 33 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 34 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 35 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 36 | TABLE ACCESS BY INDEX ROWID | TPRODUCT | 1 | 48 | 1 (0)| 00:00:01 |
|* 37 | INDEX UNIQUE SCAN | TPRODUCT_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 38 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 39 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 40 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 41 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 42 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 43 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 44 | TABLE ACCESS BY INDEX ROWID | TPRODUCT | 1 | 64 | 1 (0)| 00:00:01 |
|* 45 | INDEX UNIQUE SCAN | TPRODUCT_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 46 | INLIST ITERATOR | | | | | |
| 47 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 2 | 86 | 2 (0)| 00:00:01 |
|* 48 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 2 | | 1 (0)| 00:00:01 |
| 49 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 50 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
|* 51 | INDEX UNIQUE SCAN | SYMUSERCOUNT_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 52 | INDEX UNIQUE SCAN | SYMUSERCOUNT_PK | 1 | 12 | 0 (0)| 00:00:01 |
|* 53 | INDEX UNIQUE SCAN | SYMSKUTYPE_PK | 1 | 5 | 0 (0)| 00:00:01 |
|* 54 | INDEX UNIQUE SCAN | SYMSKUTYPE_PK | 1 | 17 | 0 (0)| 00:00:01 |
|* 55 | INDEX UNIQUE SCAN | SYMSKULANGUAGE_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 56 | INDEX UNIQUE SCAN | SYMSKULANGUAGE_PK | 1 | 16 | 0 (0)| 00:00:01 |
|* 57 | INDEX UNIQUE SCAN | SYMVENDOR_PK | 1 | 6 | 0 (0)| 00:00:01 |
|* 58 | INDEX UNIQUE SCAN | SYMVENDOR_PK | 1 | 18 | 0 (0)| 00:00:01 |
| 59 | TABLE ACCESS BY INDEX ROWID | SYMPRODUCTSKU | 1 | 38 | 6 (0)| 00:00:01 |
|* 60 | INDEX RANGE SCAN | I_PSKU_MERCH_LOOKUP | 1 | | 5 (0)| 00:00:01 |
|* 61 | INDEX UNIQUE SCAN | SYMMEDIATYPE_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 62 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 63 | INDEX UNIQUE SCAN | SYMMETADATA_PK | 1 | | 0 (0)| 00:00:01 |
| 64 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 65 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
|* 66 | INDEX UNIQUE SCAN | SYMMEDIATYPE_PK | 1 | 12 | 0 (0)| 00:00:01 |
| 67 | TABLE ACCESS BY INDEX ROWID | SYMPRODUCTSKU | 1 | 54 | 3 (0)| 00:00:01 |
|* 68 | INDEX RANGE SCAN | I_PSKU_MERCH_LOOKUP | 1 | | 2 (0)| 00:00:01 |
|* 69 | INDEX UNIQUE SCAN | SYMPCCOUNT_PK | 1 | 10 | 0 (0)| 00:00:01 |
| 70 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 71 | INDEX UNIQUE SCAN | SYMMETADATA_PK | 1 | | 0 (0)| 00:00:01 |
|* 72 | TABLE ACCESS BY INDEX ROWID | TPRODUCTSKU | 1 | 17 | 1 (0)| 00:00:01 |
|* 73 | INDEX UNIQUE SCAN | TPRODUCTSKU_PK | 1 | | 0 (0)| 00:00:01 |
|* 74 | TABLE ACCESS BY INDEX ROWID | TPRODUCTSKU | 1 | 50 | 1 (0)| 00:00:01 |
|* 75 | INDEX UNIQUE SCAN | TPRODUCTSKU_PK | 1 | | 0 (0)| 00:00:01 |
Non Prod (Fast) Plan:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 383 | 28 (0)| 00:00:01 |
|* 1 | FILTER | | | | | |
| 2 | NESTED LOOPS | | 1 | 383 | 17 (0)| 00:00:01 |
| 3 | NESTED LOOPS OUTER | | 1 | 350 | 16 (0)| 00:00:01 |
| 4 | NESTED LOOPS | | 1 | 308 | 15 (0)| 00:00:01 |
| 5 | NESTED LOOPS | | 1 | 266 | 14 (0)| 00:00:01 |
| 6 | NESTED LOOPS OUTER | | 1 | 262 | 14 (0)| 00:00:01 |
| 7 | NESTED LOOPS | | 1 | 258 | 14 (0)| 00:00:01 |
| 8 | NESTED LOOPS | | 2 | 438 | 7 (0)| 00:00:01 |
| 9 | NESTED LOOPS | | 2 | 428 | 7 (0)| 00:00:01 |
| 10 | NESTED LOOPS | | 2 | 420 | 7 (0)| 00:00:01 |
| 11 | NESTED LOOPS | | 2 | 410 | 7 (0)| 00:00:01 |
| 12 | NESTED LOOPS | | 2 | 402 | 7 (0)| 00:00:01 |
| 13 | NESTED LOOPS | | 1 | 159 | 5 (0)| 00:00:01 |
| 14 | NESTED LOOPS | | 1 | 126 | 4 (0)| 00:00:01 |
| 15 | NESTED LOOPS | | 1 | 84 | 3 (0)| 00:00:01 |
| 16 | TABLE ACCESS BY INDEX ROWID| SYMMETADATA | 1 | 42 | 2 (0)| 00:00:01 |
|* 17 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 1 (0)| 00:00:01 |
| 18 | TABLE ACCESS BY INDEX ROWID| SYMMETADATA | 1 | 42 | 1 (0)| 00:00:01 |
|* 19 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 20 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 42 | 1 (0)| 00:00:01 |
|* 21 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 22 | TABLE ACCESS BY INDEX ROWID | TPRODUCT | 1 | 33 | 1 (0)| 00:00:01 |
|* 23 | INDEX UNIQUE SCAN | TPRODUCT_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 24 | INLIST ITERATOR | | | | | |
| 25 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 2 | 84 | 2 (0)| 00:00:01 |
|* 26 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 2 | | 1 (0)| 00:00:01 |
|* 27 | INDEX UNIQUE SCAN | SYMUSERCOUNT_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 28 | INDEX UNIQUE SCAN | SYMSKUTYPE_PK | 1 | 5 | 0 (0)| 00:00:01 |
|* 29 | INDEX UNIQUE SCAN | SYMSKULANGUAGE_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 30 | INDEX UNIQUE SCAN | SYMVENDOR_PK | 1 | 5 | 0 (0)| 00:00:01 |
| 31 | TABLE ACCESS BY INDEX ROWID | SYMPRODUCTSKU | 1 | 39 | 4 (0)| 00:00:01 |
|* 32 | INDEX RANGE SCAN | I_PSKU_MERCH_LOOKUP | 1 | | 3 (0)| 00:00:01 |
|* 33 | INDEX UNIQUE SCAN | SYMPCCOUNT_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 34 | INDEX UNIQUE SCAN | SYMMEDIATYPE_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 35 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 42 | 1 (0)| 00:00:01 |
|* 36 | INDEX UNIQUE SCAN | SYMMETADATA_PK | 1 | | 0 (0)| 00:00:01 |
| 37 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 42 | 1 (0)| 00:00:01 |
|* 38 | INDEX UNIQUE SCAN | SYMMETADATA_PK | 1 | | 0 (0)| 00:00:01 |
|* 39 | TABLE ACCESS BY INDEX ROWID | TPRODUCTSKU | 1 | 33 | 1 (0)| 00:00:01 |
|* 40 | INDEX UNIQUE SCAN | TPRODUCTSKU_PK | 1 | | 0 (0)| 00:00:01 |
| 41 | SORT AGGREGATE | | 1 | 252 | | |
| 42 | NESTED LOOPS | | 1 | 252 | 11 (0)| 00:00:01 |
| 43 | NESTED LOOPS | | 1 | 240 | 10 (0)| 00:00:01 |
| 44 | NESTED LOOPS | | 1 | 205 | 7 (0)| 00:00:01 |
| 45 | NESTED LOOPS | | 1 | 200 | 7 (0)| 00:00:01 |
| 46 | NESTED LOOPS | | 1 | 196 | 7 (0)| 00:00:01 |
| 47 | NESTED LOOPS | | 1 | 191 | 7 (0)| 00:00:01 |
| 48 | NESTED LOOPS | | 1 | 187 | 7 (0)| 00:00:01 |
| 49 | NESTED LOOPS | | 1 | 183 | 7 (0)| 00:00:01 |
| 50 | NESTED LOOPS | | 1 | 150 | 6 (0)| 00:00:01 |
| 51 | NESTED LOOPS | | 1 | 120 | 5 (0)| 00:00:01 |
| 52 | NESTED LOOPS | | 1 | 90 | 4 (0)| 00:00:01 |
| 53 | NESTED LOOPS | | 1 | 60 | 3 (0)| 00:00:01 |
| 54 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 30 | 2 (0)| 00:00:01 |
|* 55 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 1 (0)| 00:00:01 |
| 56 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 30 | 1 (0)| 00:00:01 |
|* 57 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 58 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 30 | 1 (0)| 00:00:01 |
|* 59 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 60 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 30 | 1 (0)| 00:00:01 |
|* 61 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 62 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 30 | 1 (0)| 00:00:01 |
|* 63 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 64 | TABLE ACCESS BY INDEX ROWID | TPRODUCT | 1 | 33 | 1 (0)| 00:00:01 |
|* 65 | INDEX UNIQUE SCAN | TPRODUCT_UNIQUE | 1 | | 0 (0)| 00:00:01 |
|* 66 | INDEX UNIQUE SCAN | SYMUSERCOUNT_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 67 | INDEX UNIQUE SCAN | SYMMEDIATYPE_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 68 | INDEX UNIQUE SCAN | SYMSKUTYPE_PK | 1 | 5 | 0 (0)| 00:00:01 |
|* 69 | INDEX UNIQUE SCAN | SYMSKULANGUAGE_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 70 | INDEX UNIQUE SCAN | SYMVENDOR_PK | 1 | 5 | 0 (0)| 00:00:01 |
| 71 | TABLE ACCESS BY INDEX ROWID | SYMPRODUCTSKU | 1 | 35 | 3 (0)| 00:00:01 |
|* 72 | INDEX RANGE SCAN | I_PSKU_MERCH_LOOKUP | 1 | | 2 (0)| 00:00:01 |
|* 73 | TABLE ACCESS BY INDEX ROWID | TPRODUCTSKU | 1 | 12 | 1 (0)| 00:00:01 |
|* 74 | INDEX UNIQUE SCAN | TPRODUCTSKU_PK | 1 | | 0 (0)| 00:00:01 |
Database version is 10.2.0.4. Can anyone help me understand what else to be looking for to make it work faster?Please see the following threads for the ideal information required:
How to post a sql tuning request:
HOW TO: Post a SQL statement tuning request - template posting
When your query takes too long:
When your query takes too long ... -
Query needs tuning; Explain plan attached
DB version:10gR2
Currently, the below query is taking more than 28 secs to complete. The table stats are up-to-date.
Is there a way to rewrite/tune this query?
SELECT DISTINCT TASK_HDR.TASK_ID,
TASK_HDR.WHSE,
TASK_HDR.TASK_DESC,
TASK_HDR.INVN_TYPE,
TASK_HDR.INVN_NEED_TYPE,
TASK_HDR.DFLT_TASK_PRTY,
TASK_HDR.CURR_TASK_PRTY,
TASK_HDR.XPECTD_DURTN,
TASK_HDR.ACTL_DURTN,
TASK_HDR.ERLST_START_DATE_TIME,
TASK_HDR.LTST_START_DATE_TIME,
TASK_HDR.LTST_CMPL_DATE_TIME,
TASK_HDR.BEGIN_AREA,
TASK_HDR.BEGIN_ZONE,
TASK_HDR.BEGIN_AISLE,
TASK_HDR.END_AREA,
TASK_HDR.END_ZONE,
TASK_HDR.END_AISLE,
TASK_HDR.START_CURR_WORK_GRP,
TASK_HDR.START_CURR_WORK_AREA,
TASK_HDR.END_CURR_WORK_GRP,
TASK_HDR.END_CURR_WORK_AREA,
TASK_HDR.START_DEST_WORK_GRP,
TASK_HDR.START_DEST_WORK_AREA,
TASK_HDR.END_DEST_WORK_GRP,
TASK_HDR.END_DEST_WORK_AREA,
TASK_HDR.TASK_TYPE,
TASK_HDR.TASK_GENRTN_REF_CODE,
TASK_HDR.TASK_GENRTN_REF_NBR,
TASK_HDR.NEED_ID,
TASK_HDR.TASK_BATCH,
TASK_HDR.STAT_CODE,
TASK_HDR.CREATE_DATE_TIME,
TASK_HDR.MOD_DATE_TIME,
TASK_HDR.USER_ID,
TASK_HDR.RLS_DATE_TIME,
TASK_HDR.SKU_ID,
TASK_HDR.TASK_CMPL_REF_CODE,
TASK_HDR.TASK_CMPL_REF_NBR,
TASK_HDR.OWNER_USER_ID,
TASK_HDR.ONE_USER_PER_GRP,
TASK_HDR.NEXT_TASK_ID,
TASK_HDR.EXCEPTION_CODE,
TASK_HDR.CURR_LOCN_ID,
TASK_HDR.TASK_PARM_ID,
TASK_HDR.RULE_ID,
TASK_HDR.VOCOLLECT_ASSIGN_ID,
TASK_HDR.CURR_USER_ID,
TASK_HDR.MHE_FLAG,
TASK_HDR.PICK_TO_TOTE_FLAG,
TASK_HDR.MHE_ORD_STATE,
TASK_HDR.PRT_TASK_LIST_FLAG,
TASK_HDR.RPT_PRTR_REQSTR,
TASK_HDR.ORIG_TASK_ID
FROM INVN_NEED_TYPE, TASK_DTL, TASK_HDR
WHERE (TASK_HDR.TASK_ID = TASK_DTL.TASK_ID(+))
AND TASK_HDR.WHSE = '01' AND TASK_HDR.STAT_CODE >= 99 AND
TASK_HDR.INVN_NEED_TYPE = INVN_NEED_TYPE.INVN_NEED_TYPE AND
INVN_NEED_TYPE.WHSE = TASK_HDR.WHSE AND
(INVN_NEED_TYPE.CO = '88') AND (INVN_NEED_TYPE.DIV = '51') AND
(TASK_DTL.PKT_CTRL_NBR IS NULL OR TASK_DTL.INVN_NEED_TYPE = 1) AND
TASK_HDR.MOD_DATE_TIME <= sysdate-85
ORDER BY TASK_HDR.CREATE_DATE_TIME DESC
The explain plan:
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)|
| 0 | SELECT STATEMENT | | 10032 | 1969K| | 3143 (2)|
| 1 | SORT ORDER BY | | 10032 | 1969K| 4232K| 3143 (2)|
| 2 | HASH UNIQUE | | 10032 | 1969K| 4232K| 2689 (2)|
| 3 | FILTER | | | | | |
| 4 | NESTED LOOPS OUTER | | 10032 | 1969K| | 2235 (1)|
| 5 | NESTED LOOPS | | 3226 | 570K| | 284 (3)|
| 6 | TABLE ACCESS BY INDEX ROWID| TASK_HDR | 3412 | 559K| | 282 (2)|
| 7 | INDEX RANGE SCAN | TASK_HDR_IND_3 | 9042 | | | 8 (13)|
| 8 | INDEX UNIQUE SCAN | PK_INVN_NEED_TYPE | 1 | 13 | | 1 (0)|
| 9 | TABLE ACCESS BY INDEX ROWID | TASK_DTL | 3 | 60 | | 1 (0)|
| 10 | INDEX RANGE SCAN | PK_TASK_DTL | 3 | | | 1 (0)|
---------------------------------------------------------------------------------------------------My apologies, yes, it is:
SELECT TASK_HDR.TASK_ID,
TASK_HDR.WHSE,
TASK_HDR.TASK_DESC,
TASK_HDR.INVN_TYPE,
TASK_HDR.INVN_NEED_TYPE,
TASK_HDR.DFLT_TASK_PRTY,
TASK_HDR.CURR_TASK_PRTY,
TASK_HDR.XPECTD_DURTN,
TASK_HDR.ACTL_DURTN,
TASK_HDR.ERLST_START_DATE_TIME,
TASK_HDR.LTST_START_DATE_TIME,
TASK_HDR.LTST_CMPL_DATE_TIME,
TASK_HDR.BEGIN_AREA,
TASK_HDR.BEGIN_ZONE,
TASK_HDR.BEGIN_AISLE,
TASK_HDR.END_AREA,
TASK_HDR.END_ZONE,
TASK_HDR.END_AISLE,
TASK_HDR.START_CURR_WORK_GRP,
TASK_HDR.START_CURR_WORK_AREA,
TASK_HDR.END_CURR_WORK_GRP,
TASK_HDR.END_CURR_WORK_AREA,
TASK_HDR.START_DEST_WORK_GRP,
TASK_HDR.START_DEST_WORK_AREA,
TASK_HDR.END_DEST_WORK_GRP,
TASK_HDR.END_DEST_WORK_AREA,
TASK_HDR.TASK_TYPE,
TASK_HDR.TASK_GENRTN_REF_CODE,
TASK_HDR.TASK_GENRTN_REF_NBR,
TASK_HDR.NEED_ID,
TASK_HDR.TASK_BATCH,
TASK_HDR.STAT_CODE,
TASK_HDR.CREATE_DATE_TIME,
TASK_HDR.MOD_DATE_TIME,
TASK_HDR.USER_ID,
TASK_HDR.RLS_DATE_TIME,
TASK_HDR.SKU_ID,
TASK_HDR.TASK_CMPL_REF_CODE,
TASK_HDR.TASK_CMPL_REF_NBR,
TASK_HDR.OWNER_USER_ID,
TASK_HDR.ONE_USER_PER_GRP,
TASK_HDR.NEXT_TASK_ID,
TASK_HDR.EXCEPTION_CODE,
TASK_HDR.CURR_LOCN_ID,
TASK_HDR.TASK_PARM_ID,
TASK_HDR.RULE_ID,
TASK_HDR.VOCOLLECT_ASSIGN_ID,
TASK_HDR.CURR_USER_ID,
TASK_HDR.MHE_FLAG,
TASK_HDR.PICK_TO_TOTE_FLAG,
TASK_HDR.MHE_ORD_STATE,
TASK_HDR.PRT_TASK_LIST_FLAG,
TASK_HDR.RPT_PRTR_REQSTR,
TASK_HDR.ORIG_TASK_ID
FROM INVN_NEED_TYPE,TASK_HDR
WHERE TASK_HDR.WHSE = '01' AND TASK_HDR.STAT_CODE >= 99 AND
TASK_HDR.INVN_NEED_TYPE = INVN_NEED_TYPE.INVN_NEED_TYPE AND
INVN_NEED_TYPE.WHSE = TASK_HDR.WHSE AND
(INVN_NEED_TYPE.CO = '88') AND (INVN_NEED_TYPE.DIV = '51') AND
TASK_HDR.MOD_DATE_TIME <= sysdate-85
AND EXISTS (SELECT 1
FROM TASK_DTL
WHERE TASK_HDR.TASK_ID = TASK_DTL.TASK_ID
AND (TASK_DTL.PKT_CTRL_NBR IS NULL OR TASK_DTL.INVN_NEED_TYPE = 1))
ORDER BY TASK_HDR.CREATE_DATE_TIME DESCAlthough you have an OUTER JOIN on TASK_DTL.TASK_ID, this is converted to an INNER JOIN with (TASK_DTL.PKT_CTRL_NBR IS NULL OR TASK_DTL.INVN_NEED_TYPE = 1), which is the equivalent of the 'EXISTS' version above.
I haven't been able to test this. -
Hello,
database is oracle 10.2.0.4.0
a query is
SELECT * FROM OPTIVA.SFI_AP_BATCH_ING_LTS_SUBLTS_V WHERE Plant = 'GB' and Batch_no = 000361602;
its explain plan is
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Inst |IN-OUT|
| 0 | SELECT STATEMENT | | 1 | 1567 | | 44518 (9)| 00:08:55 | | |
| 1 | NESTED LOOPS | | 1 | 1567 | | 44518 (9)| 00:08:55 | | |
|* 2 | HASH JOIN | | 1 | 1548 | | 44517 (9)| 00:08:55 | | |
| 3 | MERGE JOIN CARTESIAN | | 1 | 1531 | | 44402 (9)| 00:08:53 | | |
|* 4 | HASH JOIN | | 1 | 1488 | | 44179 (9)| 00:08:51 | | |
|* 5 | HASH JOIN | | 1 | 1188 | | 37416 (2)| 00:07:29 | | |
| 6 | REMOTE | | 12000 | 738K| | 1675 (2)| 00:00:21 | OPTIV~ | R->S |
| 7 | MERGE JOIN CARTESIAN | | 2900 | 3186K| | 35740 (2)| 00:07:09 | | |
|* 8 | HASH JOIN | | 1 | 1103 | | 35517 (2)| 00:07:07 | | |
|* 9 | HASH JOIN | | 1 | 627 | | 18611 (2)| 00:03:44 | | |
| 10 | VIEW | SFI_PLM_BATCH_HDR_V | 1 | 140 | | 16906 (2)| 00:03:23 | | |
| 11 | SORT ORDER BY | | 1 | 283 | | 16906 (2)| 00:03:23 | | |
| 12 | SORT UNIQUE | | 1 | 283 | | 16905 (2)| 00:03:23 | | |
|* 13 | HASH JOIN | | 1 | 283 | | 16904 (2)| 00:03:23 | | |
| 14 | MERGE JOIN CARTESIAN | | 38 | 7486 | | 15914 (2)| 00:03:11 | | |
| 15 | REMOTE | GME_BATCH_HEADER | 1 | 162 | | 15531 (2)| 00:03:07 | OPTIV~ | R->S |
| 16 | BUFFER SORT | | 2204 | 77140 | | 383 (2)| 00:00:05 | | |
|* 17 | TABLE ACCESS FULL | FSFORMULA | 2204 | 77140 | | 383 (2)| 00:00:05 | | |
| 18 | REMOTE | FM_FORM_MST | 413K| 33M| | 985 (3)| 00:00:12 | OPTIV~ | R->S |
| 19 | VIEW | SFI_AP_INVENTORY_V_MOD | 1 | 487 | | 1705 (2)| 00:00:21 | | |
| 20 | SORT ORDER BY | | 1 | 411 | | 1705 (2)| 00:00:21 | | |
| 21 | NESTED LOOPS | | 1 | 411 | | 1704 (2)| 00:00:21 | | |
| 22 | NESTED LOOPS OUTER | | 1 | 252 | | 1702 (2)| 00:00:21 | | |
| 23 | NESTED LOOPS | | 1 | 204 | | 1700 (2)| 00:00:21 | | |
| 24 | MERGE JOIN CARTESIAN | | 1 | 152 | | 1695 (2)| 00:00:21 | | |
| 25 | MERGE JOIN CARTESIAN| | 1 | 65 | | 5 (0)| 00:00:01 | | |
| 26 | NESTED LOOPS | | 1 | 57 | | 4 (0)| 00:00:01 | | |
| 27 | REMOTE | ORG_ORGANIZATION_DEFINITIONS | 1 | 22 | | 3 (0)| 00:00:01 | OPTIV~ | R->S |
| 28 | REMOTE | MTL_PARAMETERS | 1 | 35 | | 1 (0)| 00:00:01 | OPTIV~ | R->S |
| 29 | BUFFER SORT | | 1 | 8 | | 4 (0)| 00:00:01 | | |
| 30 | REMOTE | IC_WHSE_MST | 1 | 8 | | 1 (0)| 00:00:01 | OPTIV~ | R->S |
| 31 | BUFFER SORT | | 239 | 20793 | | 1694 (2)| 00:00:21 | | |
| 32 | REMOTE | IC_ITEM_MST | 239 | 20793 | | 1690 (2)| 00:00:21 | OPTIV~ | R->S |
| 33 | REMOTE | IC_LOCT_INV | 1 | 52 | | 5 (0)| 00:00:01 | OPTIV~ | R->S |
| 34 | REMOTE | BULK_ASSAYS | 1 | 48 | | 2 (0)| 00:00:01 | OPTIV~ | R->S |
| 35 | REMOTE | IC_LOTS_MST | 1 | 159 | | 2 (0)| 00:00:01 | OPTIV~ | R->S |
| 36 | VIEW | SFI_PLM_BATCH_HDR_V | 1 | 476 | | 16906 (2)| 00:03:23 | | |
| 37 | SORT ORDER BY | | 1 | 283 | | 16906 (2)| 00:03:23 | | |
| 38 | SORT UNIQUE | | 1 | 283 | | 16905 (2)| 00:03:23 | | |
|* 39 | HASH JOIN | | 1 | 283 | | 16904 (2)| 00:03:23 | | |
| 40 | MERGE JOIN CARTESIAN | | 38 | 7486 | | 15914 (2)| 00:03:11 | | |
| 41 | REMOTE | GME_BATCH_HEADER | 1 | 162 | | 15531 (2)| 00:03:07 | OPTIV~ | R->S |
| 42 | BUFFER SORT | | 2204 | 77140 | | 383 (2)| 00:00:05 | | |
|* 43 | TABLE ACCESS FULL | FSFORMULA | 2204 | 77140 | | 383 (2)| 00:00:05 | | |
| 44 | REMOTE | FM_FORM_MST | 413K| 33M| | 985 (3)| 00:00:12 | OPTIV~ | R->S |
| 45 | BUFFER SORT | | 2900 | 63800 | | 35740 (2)| 00:07:09 | | |
|* 46 | TABLE ACCESS FULL | FSITEM | 2900 | 63800 | | 223 (2)| 00:00:03 | | |
| 47 | VIEW | SFI_AP_FLAT_FORMULA_V | 24429 | 2099K| | 6722 (50)| 00:01:21 | | |
| 48 | SORT GROUP BY | | 24429 | 2457K| 5768K| 6722 (50)| 00:01:21 | | |
|* 49 | HASH JOIN | | 24429 | 2457K| | 6145 (55)| 00:01:14 | | |
|* 50 | TABLE ACCESS FULL | FSFORMULA | 2204 | 154K| | 383 (2)| 00:00:05 | | |
|* 51 | TABLE ACCESS FULL | FSFORMULATECHPARAM | 145K| 4394K| | 5760 (59)| 00:01:10 | | |
| 52 | BUFFER SORT | | 34797 | 1461K| | 44402 (9)| 00:08:53 | | |
|* 53 | TABLE ACCESS FULL | FSITEM | 34797 | 1461K| | 223 (2)| 00:00:03 | | |
|* 54 | TABLE ACCESS FULL | FSFORMULAINGRED | 44332 | 735K| | 114 (4)| 00:00:02 | | |
|* 55 | TABLE ACCESS BY INDEX ROWID | FSFORMULA | 1 | 19 | | 1 (0)| 00:00:01 | | |
|* 56 | INDEX UNIQUE SCAN | FS_FORMULA_PK | 1 | | | 0 (0)| 00:00:01 | | |
it runs about 2 minutes 45 seconds, I use hint (like parallel and DRIVING_SITE), can make it faster as 2 minutes, but can't gain more,
any better idea?
thanks a lot
Edited by: 951932 on Sep 7, 2012 4:12 PM951932 wrote:
its explain plan is
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Inst |IN-OUT|
| 0 | SELECT STATEMENT | | 1 | 1567 | | 44518 (9)| 00:08:55 | | |
| 1 | NESTED LOOPS | | 1 | 1567 | | 44518 (9)| 00:08:55 | | |
|* 2 | HASH JOIN | | 1 | 1548 | | 44517 (9)| 00:08:55 | | |
| 3 | MERGE JOIN CARTESIAN | | 1 | 1531 | | 44402 (9)| 00:08:53 | | |
|* 4 | HASH JOIN | | 1 | 1488 | | 44179 (9)| 00:08:51 | | |
|* 5 | HASH JOIN | | 1 | 1188 | | 37416 (2)| 00:07:29 | | |
| 6 | REMOTE | | 12000 | 738K| | 1675 (2)| 00:00:21 | OPTIV~ | R->S |
| 7 | MERGE JOIN CARTESIAN | | 2900 | 3186K| | 35740 (2)| 00:07:09 | | |
|* 8 | HASH JOIN | | 1 | 1103 | | 35517 (2)| 00:07:07 | | |
|* 9 | HASH JOIN | | 1 | 627 | | 18611 (2)| 00:03:44 | | |
| 10 | VIEW | SFI_PLM_BATCH_HDR_V | 1 | 140 | | 16906 (2)| 00:03:23 | | |
| 11 | SORT ORDER BY | | 1 | 283 | | 16906 (2)| 00:03:23 | | |
| 12 | SORT UNIQUE | | 1 | 283 | | 16905 (2)| 00:03:23 | | |
|* 13 | HASH JOIN | | 1 | 283 | | 16904 (2)| 00:03:23 | | |
| 14 | MERGE JOIN CARTESIAN | | 38 | 7486 | | 15914 (2)| 00:03:11 | | |
| 15 | REMOTE | GME_BATCH_HEADER | 1 | 162 | | 15531 (2)| 00:03:07 | OPTIV~ | R->S |
| 16 | BUFFER SORT | | 2204 | 77140 | | 383 (2)| 00:00:05 | | |
|* 17 | TABLE ACCESS FULL | FSFORMULA | 2204 | 77140 | | 383 (2)| 00:00:05 | | |
| 18 | REMOTE | FM_FORM_MST | 413K| 33M| | 985 (3)| 00:00:12 | OPTIV~ | R->S |
| 19 | VIEW | SFI_AP_INVENTORY_V_MOD | 1 | 487 | | 1705 (2)| 00:00:21 | | |
| 20 | SORT ORDER BY | | 1 | 411 | | 1705 (2)| 00:00:21 | | |
| 21 | NESTED LOOPS | | 1 | 411 | | 1704 (2)| 00:00:21 | | |
| 22 | NESTED LOOPS OUTER | | 1 | 252 | | 1702 (2)| 00:00:21 | | |
| 23 | NESTED LOOPS | | 1 | 204 | | 1700 (2)| 00:00:21 | | |
| 24 | MERGE JOIN CARTESIAN | | 1 | 152 | | 1695 (2)| 00:00:21 | | |
| 25 | MERGE JOIN CARTESIAN| | 1 | 65 | | 5 (0)| 00:00:01 | | |
| 26 | NESTED LOOPS | | 1 | 57 | | 4 (0)| 00:00:01 | | |
| 27 | REMOTE | ORG_ORGANIZATION_DEFINITIONS | 1 | 22 | | 3 (0)| 00:00:01 | OPTIV~ | R->S |
| 28 | REMOTE | MTL_PARAMETERS | 1 | 35 | | 1 (0)| 00:00:01 | OPTIV~ | R->S |
| 29 | BUFFER SORT | | 1 | 8 | | 4 (0)| 00:00:01 | | |
| 30 | REMOTE | IC_WHSE_MST | 1 | 8 | | 1 (0)| 00:00:01 | OPTIV~ | R->S |
| 31 | BUFFER SORT | | 239 | 20793 | | 1694 (2)| 00:00:21 | | |
| 32 | REMOTE | IC_ITEM_MST | 239 | 20793 | | 1690 (2)| 00:00:21 | OPTIV~ | R->S |
| 33 | REMOTE | IC_LOCT_INV | 1 | 52 | | 5 (0)| 00:00:01 | OPTIV~ | R->S |
| 34 | REMOTE | BULK_ASSAYS | 1 | 48 | | 2 (0)| 00:00:01 | OPTIV~ | R->S |
| 35 | REMOTE | IC_LOTS_MST | 1 | 159 | | 2 (0)| 00:00:01 | OPTIV~ | R->S |
| 36 | VIEW | SFI_PLM_BATCH_HDR_V | 1 | 476 | | 16906 (2)| 00:03:23 | | |
| 37 | SORT ORDER BY | | 1 | 283 | | 16906 (2)| 00:03:23 | | |
| 38 | SORT UNIQUE | | 1 | 283 | | 16905 (2)| 00:03:23 | | |
|* 39 | HASH JOIN | | 1 | 283 | | 16904 (2)| 00:03:23 | | |
| 40 | MERGE JOIN CARTESIAN | | 38 | 7486 | | 15914 (2)| 00:03:11 | | |
| 41 | REMOTE | GME_BATCH_HEADER | 1 | 162 | | 15531 (2)| 00:03:07 | OPTIV~ | R->S |
| 42 | BUFFER SORT | | 2204 | 77140 | | 383 (2)| 00:00:05 | | |
|* 43 | TABLE ACCESS FULL | FSFORMULA | 2204 | 77140 | | 383 (2)| 00:00:05 | | |
| 44 | REMOTE | FM_FORM_MST | 413K| 33M| | 985 (3)| 00:00:12 | OPTIV~ | R->S |
| 45 | BUFFER SORT | | 2900 | 63800 | | 35740 (2)| 00:07:09 | | |
|* 46 | TABLE ACCESS FULL | FSITEM | 2900 | 63800 | | 223 (2)| 00:00:03 | | |
| 47 | VIEW | SFI_AP_FLAT_FORMULA_V | 24429 | 2099K| | 6722 (50)| 00:01:21 | | |
| 48 | SORT GROUP BY | | 24429 | 2457K| 5768K| 6722 (50)| 00:01:21 | | |
|* 49 | HASH JOIN | | 24429 | 2457K| | 6145 (55)| 00:01:14 | | |
|* 50 | TABLE ACCESS FULL | FSFORMULA | 2204 | 154K| | 383 (2)| 00:00:05 | | |
|* 51 | TABLE ACCESS FULL | FSFORMULATECHPARAM | 145K| 4394K| | 5760 (59)| 00:01:10 | | |
| 52 | BUFFER SORT | | 34797 | 1461K| | 44402 (9)| 00:08:53 | | |
|* 53 | TABLE ACCESS FULL | FSITEM | 34797 | 1461K| | 223 (2)| 00:00:03 | | |
|* 54 | TABLE ACCESS FULL | FSFORMULAINGRED | 44332 | 735K| | 114 (4)| 00:00:02 | | |
|* 55 | TABLE ACCESS BY INDEX ROWID | FSFORMULA | 1 | 19 | | 1 (0)| 00:00:01 | | |
|* 56 | INDEX UNIQUE SCAN | FS_FORMULA_PK | 1 | | | 0 (0)| 00:00:01 | | |
it runs about 2 minutes 45 seconds, I use hint (like parallel and DRIVING_SITE), can make it faster as 2 minutes, but can't gain more,
This isn't a complete execution plan - you've omitted the predicate section, and you've omitted the "remote SQL" section. However, even with those bits in place you're probably not going to find anyone who can unravel the plan to figure why you have a problem - even if you supply the definitions of all the views involved.
Given the earlier comments about cartesian merge joins, it's possible that the statistics on the remote database (particularly) are sufficiently stale that the optimizer's estimates are completely wrecked - so check stats.
To get a handle on where the time is going, and where you most need to spend your energy, you could run the query with the /*+ gather_plan_statistics */ hint (or set statistics_level=all) and they use dbms_xplan.display_cursor() with the 'allstats last' format option to show us where the work was done.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
Author: <b><em>Oracle Core</em></b>
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
There is a +"Preview"+ tab at the top of the text entry panel. Use this to check what your message will look like before you post the message. If it looks a complete mess you're unlikely to get a response. (Click on the +"Plain text"+ tab if you want to edit the text to tidy it up.) -
Save and Compare Explain Plans
We have a requirement to save all explain plans per statement run out of two long-running batch jobs. The purpose is to be able to compare these plans before/after upgrades. patches, or tuning. The environement is:
O/S: Tru-64 Unix
DB: Oracle 9.2.0.4
I am not having much luck finding anything at all about this anywhere on the web.
Has anyone done anything like this or have any ideas on how it can be done (all ideas are welcome)?
Thank you.You've got a variety of options
- You can do 10046 event traces on the jobs, run those through tkprof, and store the results off
- You can run the jobs and periodically query the data dictionary looking for new SQL statements (and their plans) in the shared pool
- You can capture the SQL being run and just do an EXPLAIN PLAN on each query
- You can use optimizer plan stability to generate outlines for every statement run as part of the jobs and store off those outlines for comparison
Justin -
Hi,
PLease help me to tune the query
select primary_rep,
rep_ssn,
nvl(product_type_desc, 'UNKNOWN') as productName,
ROUND(sum(contributions)) as contribution,
ROUND(sum(withdrawls)) as withdrawls,
ROUND(sum(netflow)) as netflow
from dev.NETFLOW_VIEW_TSS_P
where bd = 'TSS'
and actvtydate between '01-Jan-2011' and '30-Sep-2011'
and rep_ssn IN (select tax_id from broker_view where broker_id = '600468')
group by primary_rep, rep_ssn, nvl(product_type_desc, 'UNKNOWN');
explain plan details below
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 79 | 158K| | 74348 (1)| 00:14:53 | | |
| 1 | HASH GROUP BY | | 79 | 158K| | 74348 (1)| 00:14:53 | | |
|* 2 | HASH JOIN | | 79 | 158K| | 74347 (1)| 00:14:53 | | |
| 3 | VIEW | VW_NSO_1 | 1 | 6 | | 18 (17)| 00:00:01 | | |
| 4 | HASH UNIQUE | | 1 | 100 | | 18 (17)| 00:00:01 | | |
| 5 | NESTED LOOPS OUTER | | 1 | 100 | | 17 (12)| 00:00:01 | | |
| 6 | MERGE JOIN CARTESIAN | | 1 | 92 | | 17 (12)| 00:00:01 | | |
| 7 | NESTED LOOPS OUTER | | 1 | 71 | | 15 (14)| 00:00:01 | | |
| 8 | NESTED LOOPS OUTER | | 1 | 67 | | 12 (17)| 00:00:01 | | |
|* 9 | HASH JOIN OUTER | | 1 | 63 | | 10 (20)| 00:00:01 | | |
| 10 | NESTED LOOPS OUTER | | 1 | 56 | | 6 (0)| 00:00:01 | | |
| 11 | NESTED LOOPS OUTER | | 1 | 52 | | 4 (0)| 00:00:01 | | |
| 12 | TABLE ACCESS BY INDEX ROWID | AFFILIATE | 1 | 45 | | 2 (0)| 00:00:01 | | |
|* 13 | INDEX UNIQUE SCAN | AFFILIATE_PK | 1 | | | 1 (0)| 00:00:01 | | |
|* 14 | TABLE ACCESS FULL | PORTAL_BROKER | 1 | 7 | | 2 (0)| 00:00:01 | | |
| 15 | VIEW PUSHED PREDICATE | | 1 | 4 | | 2 (0)| 00:00:01 | | |
| 16 | NESTED LOOPS | | 1 | 28 | | 2 (0)| 00:00:01 | | |
| 17 | NESTED LOOPS | | 1 | 21 | | 2 (0)| 00:00:01 | | |
|* 18 | TABLE ACCESS BY INDEX ROWID | LOCATION_GROUP_TYPE_DESC | 1 | 5 | | 1 (0)| 00:00:01 | | |
|* 19 | INDEX UNIQUE SCAN | LOCATION_GROUP_TYPE_DESC_PK | 1 | | | 0 (0)| 00:00:01 | | |
|* 20 | INDEX RANGE SCAN | LOCATION_GROUP_UK | 1 | 16 | | 1 (0)| 00:00:01 | | |
|* 21 | INDEX UNIQUE SCAN | CONTACT_METHOD_PK | 1 | 7 | | 0 (0)| 00:00:01 | | |
| 22 | VIEW | | 1 | 7 | | 3 (34)| 00:00:01 | | |
| 23 | HASH UNIQUE | | 1 | 11 | | 3 (34)| 00:00:01 | | |
|* 24 | INDEX RANGE SCAN | AFFILIATE_TYPE_PK | 1 | 11 | | 2 (0)| 00:00:01 | | |
| 25 | VIEW PUSHED PREDICATE | | 1 | 4 | | 2 (0)| 00:00:01 | | |
| 26 | NESTED LOOPS | | 1 | 28 | | 2 (0)| 00:00:01 | | |
| 27 | NESTED LOOPS | | 1 | 21 | | 2 (0)| 00:00:01 | | |
|* 28 | TABLE ACCESS BY INDEX ROWID | LOCATION_GROUP_TYPE_DESC | 1 | 5 | | 1 (0)| 00:00:01 | | |
|* 29 | INDEX UNIQUE SCAN | LOCATION_GROUP_TYPE_DESC_PK | 1 | | | 0 (0)| 00:00:01 | | |
|* 30 | INDEX RANGE SCAN | LOCATION_GROUP_UK | 1 | 16 | | 1 (0)| 00:00:01 | | |
|* 31 | INDEX UNIQUE SCAN | CONTACT_METHOD_PK | 1 | 7 | | 0 (0)| 00:00:01 | | |
| 32 | VIEW PUSHED PREDICATE | | 1 | 4 | | 3 (0)| 00:00:01 | | |
| 33 | NESTED LOOPS OUTER | | 1 | 35 | | 3 (0)| 00:00:01 | | |
| 34 | NESTED LOOPS | | 1 | 32 | | 3 (0)| 00:00:01 | | |
| 35 | NESTED LOOPS | | 1 | 22 | | 2 (0)| 00:00:01 | | |
|* 36 | TABLE ACCESS BY INDEX ROWID | LOCATION_GROUP_TYPE_DESC | 1 | 5 | | 1 (0)| 00:00:01 | | |
|* 37 | INDEX UNIQUE SCAN | LOCATION_GROUP_TYPE_DESC_PK | 1 | | | 0 (0)| 00:00:01 | | |
|* 38 | INDEX RANGE SCAN | LOCATION_GROUP_UK | 1 | 17 | | 1 (0)| 00:00:01 | | |
| 39 | TABLE ACCESS BY INDEX ROWID | ADDRESS | 1 | 10 | | 1 (0)| 00:00:01 | | |
|* 40 | INDEX UNIQUE SCAN | ADDRESS_PK | 1 | | | 0 (0)| 00:00:01 | | |
|* 41 | INDEX UNIQUE SCAN | PROV_STDSC_PK | 1 | 3 | | 0 (0)| 00:00:01 | | |
| 42 | BUFFER SORT | | 1 | 21 | | 14 (15)| 00:00:01 | | |
|* 43 | INDEX RANGE SCAN | I_BROKER_BKBRCMB | 1 | 21 | | 2 (0)| 00:00:01 | | |
|* 44 | INDEX UNIQUE SCAN | BROKER_BRANCH_PK | 1 | 8 | | 0 (0)| 00:00:01 | | |
| 45 | VIEW | NETFLOW_VIEW_TSS_P | 391K| 766M| | 74325 (1)| 00:14:52 | | |
| 46 | UNION-ALL | | | | | | | | |
|* 47 | HASH JOIN RIGHT OUTER | | 11645 | 1671K| | 49023 (1)| 00:09:49 | | |
| 48 | VIEW | | 1 | 38 | | 13602 (1)| 00:02:44 | | |
|* 49 | FILTER | | | | | | | | |
| 50 | TABLE ACCESS FULL | SALES_REPORT_REP_MAPPING | 9023 | 326K| | 58 (2)| 00:00:01 | | |
|* 51 | FILTER | | | | | | | | |
| 52 | SORT GROUP BY NOSORT | | 1 | 11 | | 3 (0)| 00:00:01 | | |
| 53 | TABLE ACCESS BY INDEX ROWID | SALES_REPORT_REP_MAPPING | 1 | 11 | | 3 (0)| 00:00:01 | | |
|* 54 | INDEX RANGE SCAN | I_SAL_REP_MAP_REPID | 1 | | | 2 (0)| 00:00:01 | | |
| 55 | NESTED LOOPS | | 11645 | 1239K| | 35420 (1)| 00:07:06 | | |
|* 56 | HASH JOIN RIGHT OUTER | | 11645 | 898K| | 12112 (1)| 00:02:26 | | |
| 57 | INDEX FAST FULL SCAN | I_VENDORS_ACCTLOC | 986 | 3944 | | 2 (0)| 00:00:01 | | |
|* 58 | HASH JOIN RIGHT OUTER | | 11645 | 852K| | 12109 (1)| 00:02:26 | | |
|* 59 | MAT_VIEW ACCESS FULL | SECS_DESC | 26777 | 418K| | 3082 (1)| 00:00:37 | | |
|* 60 | FILTER | | | | | | | | |
|* 61 | HASH JOIN RIGHT OUTER | | 11645 | 670K| | 9026 (1)| 00:01:49 | | |
| 62 | MAT_VIEW ACCESS FULL | ENTRYCODES | 1640 | 11480 | | 8 (0)| 00:00:01 | | |
|* 63 | HASH JOIN | | 34936 | 1774K| | 9017 (1)| 00:01:49 | | |
|* 64 | INDEX FULL SCAN | I_CODE | 30 | 420 | | 1 (0)| 00:00:01 | | |
| 65 | PARTITION RANGE ALL | | 342K| 12M| | 9013 (1)| 00:01:49 | 1 | 20 |
| 66 | TABLE ACCESS BY LOCAL INDEX ROWID| BKPG | 342K| 12M| | 9013 (1)| 00:01:49 | 1 | 20 |
|* 67 | INDEX RANGE SCAN | I_BKPG_ACT_REC_IDX | 342K| | | 1412 (1)| 00:00:17 | 1 | 20 |
| 68 | TABLE ACCESS BY INDEX ROWID | ACCT_CUBE | 1 | 30 | | 2 (0)| 00:00:01 | | |
|* 69 | INDEX UNIQUE SCAN | ACCT_CUBE_PK | 1 | | | 1 (0)| 00:00:01 | | |
|* 70 | HASH JOIN RIGHT OUTER | | 379K| 52M| | 25303 (1)| 00:05:04 | | |
| 71 | VIEW | | 1 | 38 | | 13602 (1)| 00:02:44 | | |
|* 72 | FILTER | | | | | | | | |
| 73 | TABLE ACCESS FULL | SALES_REPORT_REP_MAPPING | 9023 | 326K| | 58 (2)| 00:00:01 | | |
|* 74 | FILTER | | | | | | | | |
| 75 | SORT GROUP BY NOSORT | | 1 | 11 | | 3 (0)| 00:00:01 | | |
| 76 | TABLE ACCESS BY INDEX ROWID | SALES_REPORT_REP_MAPPING | 1 | 11 | | 3 (0)| 00:00:01 | | |
|* 77 | INDEX RANGE SCAN | I_SAL_REP_MAP_REPID | 1 | | | 2 (0)| 00:00:01 | | |
|* 78 | HASH JOIN | | 379K| 39M| 33M| 11696 (2)| 00:02:21 | | |
|* 79 | HASH JOIN | | 379K| 28M| | 3210 (2)| 00:00:39 | | |
|* 80 | INDEX FAST FULL SCAN | I_VENDORS_ACCTLOC | 986 | 3944 | | 2 (0)| 00:00:01 | | |
|* 81 | HASH JOIN | | 379K| 27M| 14M| 3204 (2)| 00:00:39 | | |
| 82 | INDEX FAST FULL SCAN | SECS_DESC_PK | 744K| 6545K| | 457 (3)| 00:00:06 | | |
|* 83 | FILTER | | | | | | | | |
|* 84 | HASH JOIN RIGHT OUTER | | 379K| 24M| | 569 (3)| 00:00:07 | | |
| 85 | MAT_VIEW ACCESS FULL | MFENTRYCODES | 6853 | 61677 | | 15 (0)| 00:00:01 | | |
| 86 | PARTITION RANGE ALL | | 1138K| 62M| | 542 (1)| 00:00:07 | 1 | 15 |
|* 87 | TABLE ACCESS BY LOCAL INDEX ROWID | MFBKPG | 1138K| 62M| | 542 (1)| 00:00:07 | 1 | 15 |
|* 88 | INDEX RANGE SCAN | I_MFBKPGP_ACTDT_ACCT_TST | 904 | | | 107 (0)| 00:00:02 | 1 | 15 |
| 89 | INDEX FAST FULL SCAN | I_ACCT_CUBE_REPID_MKT | 1952K| 52M| | 3096 (2)| 00:00:38 | | |
Predicate Information (identified by operation id):
2 - access("REP_SSN"="$nso_col_1")
9 - access("A"."AFFILIATE_ID"="MGR"."AFFILIATE_ID"(+))
13 - access("A"."AFFILIATE_ID"='600468')
14 - filter("PORTAL_BROKER"."BROKER_ID"(+)='600468')
18 - filter("LT"."ADDRESS_CONTACT_IND"='C')
19 - access("LT"."LOCATION_GROUP_TYPE_CODE"='WF')
20 - access("L"."LOCATION_GROUP_TYPE_CODE"='WF' AND "L"."AFFILIATE_ID"="A"."AFFILIATE_ID")
filter("L"."CONTACT_METHOD_ID" IS NOT NULL)
21 - access("L"."CONTACT_METHOD_ID"="B"."CONTACT_METHOD_ID")
24 - access("AFFILIATE_ID"='600468')
filter("AFFILIATE_TYPE"='BBE' OR "AFFILIATE_TYPE"='BRM' OR "AFFILIATE_TYPE"='ISP')
28 - filter("LT"."ADDRESS_CONTACT_IND"='C')
29 - access("LT"."LOCATION_GROUP_TYPE_CODE"='WT')
30 - access("L"."LOCATION_GROUP_TYPE_CODE"='WT' AND "L"."AFFILIATE_ID"="A"."AFFILIATE_ID")
filter("L"."CONTACT_METHOD_ID" IS NOT NULL)
31 - access("L"."CONTACT_METHOD_ID"="B"."CONTACT_METHOD_ID")
36 - filter("LT"."ADDRESS_CONTACT_IND"='A')
37 - access("LT"."LOCATION_GROUP_TYPE_CODE"='WM')
38 - access("L"."LOCATION_GROUP_TYPE_CODE"='WM' AND "L"."AFFILIATE_ID"="A"."AFFILIATE_ID")
filter("L"."ADDRESS_ID" IS NOT NULL)
40 - access("L"."ADDRESS_ID"="A"."ADDRESS_ID")
41 - access("A"."PROVINCE_STATE_CODE"="S"."PROVINCE_STATE_CODE"(+))
43 - access("B"."BROKER_ID"='600468')
44 - access("B"."BRANCH_ID"="BR"."BRANCH_ID"(+))
47 - access("B"."REPID"="K"."REPID"(+))
49 - filter( EXISTS (SELECT 0 FROM DEV."SALES_REPORT_REP_MAPPING" "SALES_REPORT_REP_MAPPING" WHERE "REPID"=:B1 GROUP BY "REPID" HAVING
SUM(NVL("PCT",100))=100))
51 - filter(SUM(NVL("PCT",100))=100)
54 - access("REPID"=:B1)
56 - access(NVL("V"."VENDOR_CD"(+),'xxx')=NVL("VENDOR_CD",'yyy'))
58 - access("CUSIP"(+)="A"."CUSIP")
59 - filter("COMM_SECTYPE"(+)='MF')
60 - filter(NVL("Z"."PERF_INCLUDE_PORTFOLIO",'xx')='Y')
61 - access("A"."ENTRYCODE"="Z"."ENTRYCODE"(+))
63 - access("CODE_IN"=SUBSTR("A"."ACCT",1,3))
64 - access("CODE_TYPE"='NETFLOW')
filter("CODE_TYPE"='NETFLOW')
67 - access("A"."ACTVTYDATE">=TO_DATE(' 2011-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "A"."ACTVTYDATE"<=TO_DATE(' 2011-09-30
00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
69 - access("B"."ACCOUNTKEY"='11,,,'||"A"."ACCT")
70 - access("A"."REPID"="K"."REPID"(+))
72 - filter( EXISTS (SELECT 0 FROM DEV."SALES_REPORT_REP_MAPPING" "SALES_REPORT_REP_MAPPING" WHERE "REPID"=:B1 GROUP BY "REPID" HAVING
SUM(NVL("PCT",100))=100))
74 - filter(SUM(NVL("PCT",100))=100)
77 - access("REPID"=:B1)
78 - access("A"."ACCOUNTKEY"='20,'||"B"."VENDOR_CD"||','||"B"."FUNDNO"||','||"B"."ACCT")
79 - access("V"."VENDOR_CD"="B"."VENDOR_CD")
80 - filter("V"."VENDOR_CD"<>'HNR' AND "V"."VENDOR_CD"<>'CNL' AND "V"."VENDOR_CD"<>'IRE' AND "V"."VENDOR_CD"<>'WLR' AND
"V"."VENDOR_CD"<>'WLP' AND "V"."VENDOR_CD"<>'PER' AND "V"."VENDOR_CD"<>'BHV')
81 - access("SD"."CUSIP"="B"."CUSIP")
83 - filter(NVL("E"."PERF_INCLUDE_PORTFOLIO",'xx')='Y')
84 - access("B"."ENTRYCODE"="E"."ENTRYCODE"(+))
87 - filter("B"."VENDOR_CD"<>'HNR' AND "B"."VENDOR_CD"<>'CNL' AND "B"."VENDOR_CD"<>'IRE' AND "B"."VENDOR_CD"<>'WLR' AND
"B"."VENDOR_CD"<>'WLP' AND "B"."VENDOR_CD"<>'PER' AND "B"."VENDOR_CD"<>'BHV')
88 - access(SYS_OP_DESCEND("ACTVTYDATE")>=HEXTORAW('8790F6E1FEF8FEFAFF') AND SYS_OP_DESCEND("ACTVTYDATE")<=HEXTORAW('8790FEF8FEF8FEFAFF')
filter(SYS_OP_UNDESCEND(SYS_OP_DESCEND("ACTVTYDATE"))>=TO_DATE(' 2011-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
SYS_OP_UNDESCEND(SYS_OP_DESCEND("ACTVTYDATE"))<=TO_DATE(' 2011-09-30 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
158 rows selected.ThanksSo this is a VIEW with I think 18 tables (I may have missed one or two), some of which are referenced more than one. Some of these tables have tens of miilions of rows. What exactly are you expecting from us?
I guess this is a data warehouse or BI query. Sometimes such queries just take an age to run and there's nothing which can be done except result caching. Other times the queries can be tuned, but iit requires way more context and domain knowledge than you have provided.
Please start by reading [url https://forums.oracle.com/forums/thread.jspa?threadID=2174552#9360003]this FAQ. .
Cheers, APC -
Can HTML-based reports be built in BLS via an SQL Query and XSLT?
Hello xMII experts,
I have already built a report in xMII which uses XSLT to provide group/sum totals in a web browser. However in a new project, the report must run at certain times and possibly when certain signals become true in the process.
It appears that BLS is a good choice to achieve this and my proposed Transaction was:
1. SQL Query Action(uses the same QueryTemplate as in xMII)
2. XSLTransform Action on the resulting XML resultset (The .xsl file contains HTML which is the original used in xMII to produce the report there)
3. HTML Loader action with the resulting output of the transformation
I have now got some output in the resulting HTML file - however it omits all XSLT code - and I am left with an empty HTML shell but for a few images.
This indicates that perhaps no SQL data was ever returned.
I have therefore two questions:
1. How can I check if the SQL returned data?
2. Is it possible to deliver data to a HTML file directly after an XSLTransformation.
Looking forward to your responses
Best Regards
Robert SalesThank you for the replies.
I am a little closer the result I need - however I think I need to explain what I had and what I need a little better.
Before BLS
1 xMII report page (.irpt extension) with two iCalendar applets (start/end date) and a set of buttons (1 for each report)
Upon clicking on a button the two dates are passed into an .irpt file, and via a servlet an SQL QueryTemplate and a XSL DisplayTemplate are used to build the report.
The HTML is embedded in the XSL file - thereby generating the report direct in the web browser.
- This all works fine
With BLS
A transaction which uses a modified SQL QueryTemplate (no date parameters) passing the results to an XML file. This works.
Now when I click on the button in my xMII screen the .irpt file is called with no Date parameters and the xAcute QueryTemplate called with the XSL DisplayTemplate. The irpt file has <html> and <body> tags with XSL file in the Servlet call providing the tables and data extraction from the XML.
I have no additional HTML file so I placed the iframe tag inside the XSL file - but it refers to the .irpt file - this doesn't sound right!
I do get a little output in the web browser but it still omits all XSLT code.
One more point - The Transaction can be scheduled and run as required - but I need the entire report to created and stored for viewing at a later date. Will a servlet tag running inside an .irpt file achieve this?
Sorry for the chaotic writing here - but I must leave the office.
Regards
Robert Sales -
Query with same explain-plan but slower in one env
Hi there
I have a stored procedure which is executed from a web application. It contains a query (insert-select-from statement). When this stored procedure is called by the web application in PROD, it takes 13sec but it takes 19sec in TEST env. I checked the explain plan for this insert statement in both instances and it is same (see below). Actually, the cost is lower in TEST env.
ENV: Oracle 10gR2 EE, on ASM - RHEL 64bit
The TEST server is on a better/faster hardware and will become the new PROD in near future (faster and 16 CPUs vs 8 in PROD, high performance SAN, 132GB RAM vs 96GB in PROD, etc). The TEST database has exact same init parameter and version/patch level as current PROD. So the application is being tested against it at the moment.
Here are the explain-plans from both environments:
From PROD Server
Plan
INSERT STATEMENT ALL_ROWS Cost: 143 Bytes: 696 Cardinality: 3
18 SORT ORDER BY Cost: 143 Bytes: 696 Cardinality: 3
17 HASH UNIQUE Cost: 142 Bytes: 696 Cardinality: 3
16 WINDOW SORT Cost: 143 Bytes: 696 Cardinality: 3
15 HASH JOIN Cost: 141 Bytes: 696 Cardinality: 3
13 HASH JOIN Cost: 128 Bytes: 519 Cardinality: 3
11 TABLE ACCESS BY INDEX ROWID TABLE MKTG.SATDATAIMPORT Cost: 125 Bytes: 1,728 Cardinality: 12
10 NESTED LOOPS Cost: 125 Bytes: 1,992 Cardinality: 12
3 HASH JOIN Cost: 5 Bytes: 22 Cardinality: 1
1 TABLE ACCESS FULL TABLE MKTG.TMPG_CLICKS_HDGS Cost: 2 Bytes: 12 Cardinality: 1
2 TABLE ACCESS FULL TABLE MKTG.TMPG_CLICKS_DIRS Cost: 2 Bytes: 10 Cardinality: 1
9 BITMAP CONVERSION TO ROWIDS
8 BITMAP AND
5 BITMAP CONVERSION FROM ROWIDS
4 INDEX RANGE SCAN INDEX MKTG.SATDATAIMPORT_HEADINGNO Cost: 19 Cardinality: 4,920
7 BITMAP CONVERSION FROM ROWIDS
6 INDEX RANGE SCAN INDEX MKTG.SATDATAIMPORT_DIRNO Cost: 89 Cardinality: 4,920
12 TABLE ACCESS FULL TABLE MKTG.MONTHS12 Cost: 2 Bytes: 84 Cardinality: 12
14 TABLE ACCESS FULL TABLE MKTG.REF_WEST_CATEGORY Cost: 12 Bytes: 191,809 Cardinality: 3,251
From TEST Server
Plan
INSERT STATEMENT ALL_ROWS Cost: 107 Bytes: 232 Cardinality: 1
18 SORT ORDER BY Cost: 107 Bytes: 232 Cardinality: 1
17 HASH UNIQUE Cost: 106 Bytes: 232 Cardinality: 1
16 WINDOW SORT Cost: 107 Bytes: 232 Cardinality: 1
15 HASH JOIN Cost: 105 Bytes: 232 Cardinality: 1
13 HASH JOIN Cost: 93 Bytes: 173 Cardinality: 1
11 TABLE ACCESS BY INDEX ROWID TABLE MKTG.SATDATAIMPORT Cost: 89 Bytes: 864 Cardinality: 6
10 NESTED LOOPS Cost: 89 Bytes: 996 Cardinality: 6
3 HASH JOIN Cost: 7 Bytes: 22 Cardinality: 1
1 TABLE ACCESS FULL TABLE MKTG.TMPG_CLICKS_HDGS Cost: 3 Bytes: 12 Cardinality: 1
2 TABLE ACCESS FULL TABLE MKTG.TMPG_CLICKS_DIRS Cost: 3 Bytes: 10 Cardinality: 1
9 BITMAP CONVERSION TO ROWIDS
8 BITMAP AND
5 BITMAP CONVERSION FROM ROWIDS
4 INDEX RANGE SCAN INDEX MKTG.SATDATAIMPORT_HEADINGNO Cost: 9 Cardinality: 2,977
7 BITMAP CONVERSION FROM ROWIDS
6 INDEX RANGE SCAN INDEX MKTG.SATDATAIMPORT_DIRNO Cost: 59 Cardinality: 2,977
12 TABLE ACCESS FULL TABLE MKTG.MONTHS12 Cost: 3 Bytes: 84 Cardinality: 12
14 TABLE ACCESS FULL TABLE MKTG.REF_WEST_CATEGORY Cost: 12 Bytes: 191,868 Cardinality: 3,252
What else can I check to find out why the query is slower in TEST env?
Please advise.
Best regardsHere is some more info. The query is below:
select distinct dr.line_num
,row_number() over (partition by di.HEADINGNO,di.DIRECTORYNO order by reportyear,to_number(di.monthno)) monthposition
,di.SATID,di.REPORTYEAR,di.MONTHNO,di.MONTHEN,di.MONTHFR,di.HEADINGNO,hn.NAME_EN,hn.NAME_FR,di.DIRECTORYNO
,di.SUPERDIRECTORYNO,di.PRINTDIRCODE,di.DIRECTORYNAME,round(to_number(di.IMPTTOTAL)) imptotal
,round(to_number(di.IMPBEST)) impbest ,round(to_number(di.IMPTAVERAGE)) imptaverage
,round(to_number(di.CLICKTOTAL)) clicktotal,round(to_number(di.CLICKBEST)) clickbest
,round(to_number(di.CLICKAVERAGE)) clickaverage
,round(avg(to_number(impttotal)) over(partition by di.HEADINGNO,di.DIRECTORYNO)) avgimp
from satdataimport di,tmpg_clicks_hdgs hd,tmpg_clicks_dirs dr, months12 m12, ref_west_category hn
where di.headingno = hd.id
and di.directoryno = dr.id
and dr.line_num=hd.line_num
and di.reportyear = m12.year
and di.monthno = m12.month
and hn.CATEGORY_CODE = di.headingno
order by di.headingno, di.directoryno,di.reportyear,to_number(di.monthno)
The largest table is "satdataimport" in the query has "12274818" rows. Rest of the tables are very small containing few rows to less than 4000 rows.
I have refreshed the statistics of the larger table but this did not help either. Even a simple query like "select count(*) from satdataimport" is taking 15sec in TEST while it takes 4Sec in PROD when I run it from TOAD.
The other strange thing is that when I run this stored procedure from TOAD, it takes 200 milli sec to complete. There is a logging table to which the stored procedure records the elapsed time taken by this INSERT statement.
Since this query is in a stored procedure being called from the web app, the QA team wants quicker response. Current PROD is faster.
The tables have same indexes, etc and contain identical data as that in PROD (were refreshed from PROD yesterday).
What else can I check?
Best regards -
Query returns different Explain Plan
Hi,
I have two databases that are identical to each other. But I have a query that runs on both and returns different explain plans in both. It runs slower in one than other. How can I troubleshoot this further to get faster times in the slower database?
THanks,
PrachiQuery:
=====
SELECT sum(total_contacts), sum(email_partner_news), sum(email_tech_news),
sum(email_enduser_news), sum(email), sum(email_gmo), sum(gmo_nophone),
sum(email_gmo_noaddress), sum(email_gmo_address), sum(
email_gmo_nocertaddr), sum(email_gmo_certaddress), sum(
email_gmo_nophone_noaddr), sum(phone_number), sum(gmo_with_phone),
sum(phone_number_email_gmo_noaddr), sum(phone_number_email_gmo_nocert),
sum(phone_number_address), sum(phone_number_address_noemail), sum(
phone_address_email_nogmo), sum(phone_number_address_email), sum(
phone_number_certaddr), sum(phone_number_certaddr_noemail), sum(
phone_certaddr_email_nogmo), sum(phone_number_address_gmo), sum(
phone_certaddr_email_gmo), sum(address), sum(
address_nophone_number_nogmo), sum(address_certified), sum(
certaddr_nophone_nogmo), sum(address_email_nophone_gmo), sum(
certaddr_email_nophone_gmo), sum(phone_gmo), sum(smail_gmo), sum(fax_gmo
), sum(email_wcast), sum(email_inews), sum(email_salrt), sum(
phone_gmo_phone), sum(smail_gmo_address), sum(fax_gmo_fax)
FROM contact_values_vw_tc_2 cv, ((SELECT gcd_contact_id
FROM contact_values)
INTERSECT
((SELECT gcd_contact_id
FROM gcddata.contact_country s, gcd.country c,
segmentation_query_values v
WHERE s.country_id = c.country_id
AND c.region_id = v.query_value
AND v.selection_type = 'I'
AND v.query_id = 2088
AND v.query_sequence = 1)
INTERSECT
(SELECT gcd_contact_id
FROM gcddata.contact_country s, gcd.country c,
segmentation_query_values v
WHERE s.country_id = c.country_id
AND c.sub_region_id = v.query_value
AND v.selection_type = 'I'
AND v.query_id = 2088
AND v.query_sequence = 2)) ) sl
WHERE cv.gcd_contact_id = sl.gcd_contact_id
AND cv.country_id IN (SELECT cm.country_id
FROM segmentation_user_country_map cm
WHERE cm.user_name = 'E30590')
========================================
Execution Plan - FAST
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=32931 Card=1 Bytes=73)
1 0 SORT (AGGREGATE)
2 1 HASH JOIN (Cost=32931 Card=386388 Bytes=28206324)
3 2 VIEW (Cost=29617 Card=1142043 Bytes=14846559)
4 3 INTERSECTION
5 4 SORT (UNIQUE)
6 5 INDEX (FAST FULL SCAN) OF 'CONTACT_VALUES1_PK' (UNIQUE) (Cost=5 Card=1907737 Bytes=11446422)
7 4 INTERSECTION
8 7 SORT (UNIQUE)
9 8 HASH JOIN (Cost=655 Card=1998575 Bytes=57958675)
10 9 HASH JOIN (Cost=6 Card=110 Bytes=2200)
11 10 TABLE ACCESS (BY INDEX ROWID) OF 'SEGMENTATION_QUERY_VALUES' (Cost=3 Card=7 Bytes=91)
12 11 INDEX (RANGE SCAN) OF 'SEG_QUERY_VALUES_ PK' (UNIQUE) (Cost=2 Card=15)
13 10 TABLE ACCESS (FULL) OF 'COUNTRY' (Cost=2 Card=120 Bytes=840)
14 9 TABLE ACCESS (FULL) OF 'CONTACT_COUNTRY1' (Cost=643 Card=2199855 Bytes=19798695)
15 7 SORT (UNIQUE)
16 15 HASH JOIN (Cost=655 Card=1142043 Bytes=33119247)
17 16 HASH JOIN (Cost=6 Card=63 Bytes=1260)
18 17 TABLE ACCESS (BY INDEX ROWID) OF 'SEGMENTATION_QUERY_VALUES' (Cost=3 Card=7 Bytes=91)
19 18 INDEX (RANGE SCAN) OF 'SEG_QUERY_VALUES_PK' (UNIQUE) (Cost=2 Card=15)
20 17 TABLE ACCESS (FULL) OF 'COUNTRY' (Cost=2 Card=120 Bytes=840)
21 16 TABLE ACCESS (FULL) OF 'CONTACT_COUNTRY1' (Cost=643 Card=2199855 Bytes=19798695)
22 2 HASH JOIN (Cost=2174 Card=645445 Bytes=38726700)
23 22 SORT (UNIQUE)
24 23 TABLE ACCESS (FULL) OF 'SEGMENTATION_USER_COUNTRY_MAP' (Cost=5 Card=43 Bytes=473)
25 22 TABLE ACCESS (FULL) OF 'CONTACT_VALUES1' (Cost=2151 Card=1907737 Bytes=93479113)
=====================================================
Execution Plan -SLOW
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=8751 Card=1 Bytes=73 )
1 0 SORT (AGGREGATE)
2 1 HASH JOIN (SEMI) (Cost=8751 Card=14477 Bytes=1056821)
3 2 MERGE JOIN (Cost=8583 Card=89527 Bytes=5550674)
4 3 TABLE ACCESS (BY INDEX ROWID) OF 'CONTACT_VALUES1' ( Cost=826 Card=1852109 Bytes=90753341)
5 4 INDEX (FULL SCAN) OF 'CONTACT_VALUES1_PK' (UNIQUE) (Cost=26 Card=1852109)
6 3 SORT (JOIN) (Cost=7757 Card=89527 Bytes=1163851)
7 6 VIEW (Cost=7454 Card=89527 Bytes=1163851)
8 7 INTERSECTION
9 8 SORT (UNIQUE)
10 9 INDEX (FAST FULL SCAN) OF 'CONTACT_VALUES1_PK' (UNIQUE) (Cost=5 Card=1852109 Bytes=11112654)
11 8 INTERSECTION
12 11 SORT (UNIQUE)
13 12 HASH JOIN (Cost=640 Card=250676 Bytes=7269604)
14 13 HASH JOIN (Cost=6 Card=28 Bytes=560)
15 14 TABLE ACCESS (BY INDEX ROWID) OF 'SEGMENTATION_QUERY_VALUES' (Cost=3 Card=1 Bytes=13)
16 15 INDEX (RANGE SCAN) OF 'SEG_QUERY_VALUES_PK' (UNIQUE) (Cost=2 Card=2)
17 14 TABLE ACCESS (FULL) OF 'COUNTRY' (Cost =2 Card=120 Bytes=840)
18 13 TABLE ACCESS (FULL) OF 'CONTACT_COUNTRY1 ' (Cost=628 Card=2135370 Bytes=19218330)
19 11 SORT (UNIQUE)
20 19 HASH JOIN (Cost=640 Card=89527 Bytes=25962 83)
21 20 HASH JOIN (Cost=6 Card=10 Bytes=200)
22 21 TABLE ACCESS (BY INDEX ROWID) OF 'SEGMENTATION_QUERY_VALUES' (Cost=3 Card=1 Bytes=13)
23 22 INDEX (RANGE SCAN) OF 'SEG_QUERY_VALUES_PK' (UNIQUE) (Cost=2 Card=2)
24 21 TABLE ACCESS (FULL) OF 'COUNTRY' (Cost =2 Card=120 Bytes=840)
25 20 TABLE ACCESS (FULL) OF 'CONTACT_COUNTRY1 ' (Cost=628 Card=2135370 Bytes=19218330)
26 2 TABLE ACCESS (FULL) OF 'SEGMENTATION_USER_COUNTRY_MAP'
(Cost=5 Card=45 Bytes=495) -
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 Query and Exception ORA-01722
Hi,
I have a table called t_lookup which has three columns Lookup_Value, Description and Lookup_Type all of them are varchar2 type. If I execute the below query, its working fine
SELECT *
FROM (SELECT Lookup_Value
*,To_Number(Description) Dd*
FROM t_Lookup
WHERE Lookup_Type = 'CALENDAR') Tab ;
Here is the result
Lookup_Value .............. Dd
January....................... 1
February..................... 2
March......................... 3
April........................... 4
May........................... 5
June.......................... 6
July........................... 7
August....................... 8
September................... 9
October...................... 10
November................... 11
December................... 12
But when i execute
SELECT *
FROM (SELECT Lookup_Value
*,To_Number(Description) Dd*
FROM t_Lookup
WHERE Lookup_Type = 'CALENDAR') Tab
AND Dd = 9;
then it is throwing ORA exception
ORA-01722: invalid number
Can any one help me on this in order to understand the root cause of this problem? Oracle server I am using is "Oracle9i Release 9.2.0.8.0" .
ThanksI'm assuming that it is intended that certain descriptions will have non-numeric data in them, right?
Assuming that is the case, the success or failure of the query will depend on how the optimizer happens to choose to execute your query. If it happens to run the TO_NUMBER function before it filters out a row with non-numeric data, you'll get an error. If it happens to run the TO_NUMBER after filtering out all the rows with non-numeric data, the query will be successful. Given that query plans are subject to change, particularly when you eventually upgrade, you probably don't want to just find a SQL query that works, you'll need to ensure that either the query plan never changes or that the query is formulated in such a way that it will never fail.
My first thought would be whether you really need to store numeric data in a VARCHAR2 field in the first place. I'm guessing this is some sort of generic lookup table (which cause a raft of issues, this being one). Can you at least store string, date, and number data in separate columns?
Barring that, can you create your own PL/SQL function that converts a string to a number and catches the exception?
CREATE OR REPLACE FUNCTION my_to_number( p_arg IN varchar2 )
RETURN NUMBER
IS
l_num NUMBER;
BEGIN
l_num := to_number( p_arg );
RETURN l_num;
EXCEPTION
WHEN others THEN
RETURN NULL;
END;That will ensure that the query will be successful regardless of the plan. Note that you would probably want to catch just the ORA-01722 error, not OTHERS, in your real code-- this is just a sample.
Barring that, you'll need to do something to enforce stability in the query plan. A stored outline that forces this query to use the query plan that doesn't generate an error.
Justin -
Performance issue with sql query. Please explain
I have a sql query
A.column1 and B.column1 are indexed.
Query1: select A.column1,A.column3, B.column2 from tableA , tableB where A.column1=B.column1;
query2: select A.column1,A.column3,B.column2,B.column4 from tableA , tableB where A.column1=B.column1;
1. Does both query takes same time? If not why?.
As they both go for same row with different number of columns. And Since the complete datablock is loaded in Database buffer cache. so there should not be extra time taken upto this time.
Please tell me if I am wrong.For me apart from required excessive bytes sent via SQL*Net to client as well bytes received via SQL*Net from client will cause to chatty network which will degrade the performance.
SQL> COLUMN plan_plus_exp FORMAT A100
SQL> SET LINESIZE 1000
SQL> SET AUTOTRACE TRACEONLY
SQL> SELECT *
2 FROM emp
3 /
14 rows selected.
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=3 Card=14 Bytes=616)
1 0 TABLE ACCESS (FULL) OF 'EMP' (TABLE) (Cost=3 Card=14 Bytes=616)
Statistics
1 recursive calls
0 db block gets
8 consistent gets
0 physical reads
0 redo size
1631 bytes sent via SQL*Net to client
423 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
14 rows processed
SQL> SELECT ename
2 FROM emp
3 /
14 rows selected.
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=3 Card=14 Bytes=154)
1 0 TABLE ACCESS (FULL) OF 'EMP' (TABLE) (Cost=3 Card=14 Bytes=154)
Statistics
1 recursive calls
0 db block gets
8 consistent gets
0 physical reads
0 redo size
456 bytes sent via SQL*Net to client
423 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
14 rows processed Khurram
Maybe you are looking for
-
which is the best phone that works with mac os 10.4 and that can be used as a external modem to navigate on internet? thanks
-
Help required in SAPscript - new to sapscript
Dear all, I have copied WESCHEINVERS3 from NACE and renamed it as ZWESCHEINVERS3. I have made modifications in the form and the program SAPMO7DR and renamed it has ZSAPMO7DR.Now, from where i will run the debug mode to see whatz happening inside the
-
Noob? Need to make Macbook primary iTunes (from Macbook Pro)
Ok, here's the deal. Work has supplied everyone with a Macbook and my phone is set to use my Macbook Pro as the standard iTunes account. On my iPhone I have podcasts, some images, recorded notes, and of course, eight (8) pages of applications. Now, I
-
Keychain and gpg-agent not getting along
I have a problem with gpg-agent. I have been using the Funtoo keychain tool for a while, for my SSH keys exclusively. Works flawlessly - I log in, I call keychain, I type in my passphrases, and it caches my keys. Never get prompted for a passphrase d
-
Can someone please tell me exactly where to set the true display size for photos/pictures on my Photoshop Elements 8 ?? Things so far are displayed much smaller than the actual size. I have used Adobe Photoshop for years and still SO much I do not k