Query taking more response time
Hi Masters,
Today i am tuning One Query
The Following points are the Info regarding my query.
Table1- has 100 million records.
Table2 - has 7000 records.
I am Using table2 as Driving table.
I used the Ordered, index hint, use_nl hint and all
My Query:
select
max(t1.date)
from table2 t2*, table1 t1*
where t2.col1=12354
and
t1.col2=t2.col2 -- Is the Join b/w the two tables.
and t1.col3=0
Regarding Index Details:
There is a composite index on table1 (col2,col3).
Also there is an index on table1(col1).
The Query using the Right Index Only.
I found out from the explain Plan.
Then what is the Problem with the above Query.
Do i need to add any more Hints to work better?
One more Info man,
When i tried to retrieve only the t1.date column not as max(t.date), it will respond in subsequent mill seconds.
select
t1.date
from table2 t2, table1 t1
where t2.col1=12354
and
t1.col2=t2.col2 -- Is the Join b/w the two tables.
and t1.col3=0
And the result contains, 257000 records.
For finding the max value only it will take several hundred times more!!
Try to give some useful feedback!!
Edited by: user10376641 on Aug 21, 2009 1:32 AM
If i am harsh....sorry for that.
even after Sybrand's post, you asked for "anyother feedback". so i thought you had not gone through the link completely.
but good to hear that you are analyzing the things. please post your findings, so that we can help you out.
once again, sorry for my words.
Similar Messages
-
Consistent gets are reduced by 50% but the query taking more elapsed time.
Hi All,
While tuning a application my consistent gets are reduced by 50% but the query is still taking the same time.
In a Warehouse env data is coming from With clause that is having some 40000 rows .Then these 40K rows are joined to a table that is having 2 Billion records having indexes on primary key and date column(bitmap)indexes .
It is using Hash Joining method.Try forcing a hash join, if possible:
http://dba-oracle.com/tips_oracle_hash_joins.htm
Can you post the plans?
http://www.dba-oracle.com/plsql/t_plsql_plans.htm -
Iam having nearly 2 crores records at present in my table..
I want to get the avg of price from my table..
i put the query like
select avg(sum(price)) from table group by product_id
The query taking more than 5 mins to execute...
is that any other way i can simplify my query?Warren:
Your first query gives:
SQL> SELECT AVG(SUM(price)) sum_price
2 FROM t;
SELECT AVG(SUM(price)) sum_price
ERROR at line 1:
ORA-00978: nested group function without GROUP BYand your second gives:
SQL> SELECT product_id, AVG(SUM(price))
2 FROM t
3 GROUP BY product_id;
SELECT product_id, AVG(SUM(price))
ERROR at line 1:
ORA-00937: not a single-group group functionSymon:
What exactly are you ttrying to accomplish. Your query as posted will calculate the average of the sums of the prices for all product_id values. That is, it is equivalent to:
SELECT AVG(sum_price)
FROM (SELECT SUM(price) sum_price
FROM t
GROUP BY product_id)So given:
SQL> SELECT * FROM t;
PRODUCT_ID PRICE
PROD1 5
PROD1 7
PROD1 10
PROD2 3
PROD2 4
PROD2 5The sum of the prices per product_id is:
SQL> SELECT SUM(price) sum_price
2 FROM t
3 GROUP BY product_id;
SUM_PRICE
22
12 and the average of that is (22 + 12) / 2 = 17. Is that what you are looking for? If so, then the equivalent query I posted above is at least clearer, but may not be any faster. If this is not what you are looking for, then some sample data and expected results may help. Although, it appears that you need to full scan the table in either case, so that may be as good as it gets.
John -
Oracle internal queries taking more CPU time
Hi,
Following are queries taking more CPU time. I got this from awr report. Can anyone tell me why these queries are running? Is it a oracle enterprise manager query? should I use
emctl stop dbconsole to stop this?
DECLARE job BINARY_INTEGER := :job; next_date DATE := :mydate; broken BOOLEAN := FALSE; BEGIN EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS(); :mydate := next_date; IF broken THEN :b := 1; ELSE :b := 0; END IF; END;
SELECT COUNT(*) FROM MGMT_METRIC_DEPENDENCY_DETAILS DEP, MGMT_SEVERITY SEV WHERE DEP.TARGET_GUID = :B5 AND DEP.METRIC_GUID = :B4 AND DEP.KEY_VALUE = :B3 AND DEP.EDEP_TARGET_GUID = SEV.TARGET_GUID AND DEP.EDEP_METRIC_GUID = SEV.METRIC_GUID AND DEP.DEP_KEY_VALUE = SEV.KEY_VALUE AND SEV.COLLECTION_TIMESTAMP BETWEEN :B2 AND :B1
SELECT CURRENT_STATUS FROM MGMT_CURRENT_AVAILABILITY WHERE TARGET_GUID = :B1
Thanks in advance
With Regards
boobathi.PHi,
maybe this document will help if you are using 10g:
SQL run by SYSMAN consuming a lot of resources on OMS with 800+ targets [ID 330383.1]
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=PROBLEM&id=330383.1
there you'll find Cause and Solution too:
SYSMAN Job and Queries are Taking Up High CPU (DB Console) [ID 1288301.1]
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=PROBLEM&id=1288301.1
For databases above version 11.1 there are paches available.
Best,
Michael T. Z. -
How to find which query taking more cpu
Hi,
How to find which query taking more CPU
at a particular point of time .
Chhers,Take a look at Server Standard Reports. It has a few CPU usage oriented reports.
You can also track CPU usage by server-side tracing:
http://www.sqlusa.com/bestpractices/createtrace/
Glenn Berry's CPU usage query:
SELECT TOP(25) p.name AS [SP Name], qs.total_worker_time AS [TotalWorkerTime],
qs.total_worker_time/qs.execution_count AS [AvgWorkerTime], qs.execution_count,
ISNULL(qs.execution_count/DATEDIFF(Second, qs.cached_time, GETDATE()), 0) AS [Calls/Second],
qs.total_elapsed_time, qs.total_elapsed_time/qs.execution_count
AS [avg_elapsed_time], qs.cached_time
FROM sys.procedures AS p WITH (NOLOCK)
INNER JOIN sys.dm_exec_procedure_stats AS qs WITH (NOLOCK)
ON p.[object_id] = qs.[object_id]
WHERE qs.database_id = DB_ID()
ORDER BY qs.total_worker_time DESC OPTION (RECOMPILE);
LINK:
http://dba.stackexchange.com/questions/52216/sql-server-2008-high-cpu-historical-queries
Query optimization:
http://www.sqlusa.com/articles/query-optimization/
Kalman Toth Database & OLAP Architect
SELECT Video Tutorials 4 Hours
New Book / Kindle: Exam 70-461 Bootcamp: Querying Microsoft SQL Server 2012 -
when program execute at time my program takes more response time so what is reason.
hi krupa,
pls check with transaction SE30[Run time analysis] and identify the area where it is taking time.
pls Re-check u r code with below points.
1) should not write any select statement in side the loop and endloop.
2) Use Select into corresponding fields insted of select *
3) refresh your internal tables after data is processed.
4) use move corresponding insted of move single
5)use type insted of like while declaring the parameters.
6) it would be better if u use workarea
this is from ABAP side.
from basis side,
pls check whether the server is working fine or not??
if u want more help, pls post u r code. -
Sql Query taking very long time to complete
Hi All,
DB:oracle 9i R2
OS:sun solaris 8
Below is the Sql Query taking very long time to complete
Could any one help me out regarding this.
SELECT MAX (md1.ID) ID, md1.request_id, md1.jlpp_transaction_id,
md1.transaction_version
FROM transaction_data_arc md1
WHERE md1.transaction_name = :b2
AND md1.transaction_type = 'REQUEST'
AND md1.message_type_code = :b1
AND NOT EXISTS (
SELECT NULL
FROM transaction_data_arc tdar2
WHERE tdar2.request_id = md1.request_id
AND tdar2.jlpp_transaction_id != md1.jlpp_transaction_id
AND tdar2.ID > md1.ID)
GROUP BY md1.request_id,
md1.jlpp_transaction_id,
md1.transaction_version
Any alternate query to get the same results?
kindly let me know if any one knows.
regards,
kk.
Edited by: kk001 on Apr 27, 2011 11:23 AMDear
/* Formatted on 2011/04/27 08:32 (Formatter Plus v4.8.8) */
SELECT MAX (md1.ID) ID, md1.request_id, md1.jlpp_transaction_id,
md1.transaction_version
FROM transaction_data_arc md1
WHERE md1.transaction_name = :b2
AND md1.transaction_type = 'REQUEST'
AND md1.message_type_code = :b1
AND NOT EXISTS (
SELECT NULL
FROM transaction_data_arc tdar2
WHERE tdar2.request_id = md1.request_id
AND tdar2.jlpp_transaction_id != md1.jlpp_transaction_id
AND tdar2.ID > md1.ID)
GROUP BY md1.request_id
,md1.jlpp_transaction_id
,md1.transaction_versionCould you please post here :
(a) the available indexes on transaction_data_arc table
(b) the description of transaction_data_arc table
(c) and the formatted explain plan you will get after executing the query and issuing:
select * from table (dbms_xplan.display_cursor);Hope this helps
Mohamed Houri -
Dbms_stats.cleanup_stats_db_proc taking more CPU time.
Hi All,
Oracle 11g R2(11.2.0.3) EE , on Linux machine.
Oracle auto optimizer stats collection enabled in our environment. In that dbms_stats.cleanup_stats_db_proc() taking more CPU time (more than 24 hours).
Could you please suggest any solution.
Thanks in advance.
BR,
Suryasuresh.ratnaji wrote:
NAME TYPE VALUE
_optimizer_cost_based_transformation string OFF
filesystemio_options string asynch
object_cache_optimal_size integer 102400
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 10.2.0.4
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_mode string choose
optimizer_secure_view_merging boolean TRUE
plsql_optimize_level integer 2
please let me know why it taking more time in INDEX RANGE SCAN compare to the full table scan?Suresh,
Any particular reason why you have a non-default value for a hidden parameter, optimizercost_based_transformation ?
On my 10.2.0.1 database, its default value is "linear". What happens when you reset the value of the hidden parameter to default? -
Dear Gurus/Masters/All,
I request your valuble assistance in tuning one of my SQL.
We are using oracle 10.2.04 version and OS is HP-UX 11.23(ia64) version
In my production environment one SQL is taking more time to complete the task. According to EXPLAIN PLAN, i observed that one of it's WHERE condition execution is causing the issue.
I took the explain plan of the WHERE condition which is causing the issue. It is going for full table scan to satisfy the criteria. But a normal index exists on this column.
Main Query WHERE condition and Explain Plan.
SELECT column list ....
FROM
SIEBEL.S_ADDR_PER T1,
SIEBEL.S_PTY_PAY_PRFL T2,
SIEBEL.S_INVLOC T3,
SIEBEL.S_ORDER T4,
SIEBEL.S_ORG_EXT T5,
SIEBEL.S_POSTN T6,
SIEBEL.S_PARTY T7,
SIEBEL.S_PROJ T8,
SIEBEL.S_CON_ADDR T9,
SIEBEL.S_ORG_EXT T10,
SIEBEL.S_USER T11,
SIEBEL.S_DOC_QUOTE T12,
SIEBEL.S_ACCNT_POSTN T13,
SIEBEL.S_INS_CLAIM T14,
SIEBEL.S_USER T15,
SIEBEL.S_ORG_EXT T16,
SIEBEL.S_ASSET T17,
SIEBEL.S_ORDER_TNTX T18,
SIEBEL.S_ORG_EXT_TNTX T19,
SIEBEL.S_PERIOD T20,
SIEBEL.S_DEPOSIT_TNT T21,
SIEBEL.S_ADDR_PER T22,
SIEBEL.S_PAYMENT_TERM T23,
SIEBEL.S_ORG_EXT_X T24,
SIEBEL.S_ORG_EXT T25,
SIEBEL.S_INSCLM_ELMNT T26,
SIEBEL.S_INVOICE T27
WHERE
T25.BU_ID = T10.PAR_ROW_ID (+) AND
T26.INSCLM_ID = T14.ROW_ID (+) AND
T27.ELEMENT_ID = T26.ROW_ID (+) AND
T27.LAST_UPD_BY = T15.PAR_ROW_ID (+) AND
T4.QUOTE_ID = T12.ROW_ID (+) AND
T3.CG_ASSSET_ID = T17.ROW_ID (+) AND
T27.BL_ADDR_ID = T22.ROW_ID (+) AND
T8.BU_ID = T5.PAR_ROW_ID (+) AND
T27.PER_PAY_PRFL_ID = T2.ROW_ID (+) AND
T27.REMIT_ORG_EXT_ID = T16.PAR_ROW_ID (+) AND
T27.PROJ_ID = T8.ROW_ID (+) AND
T27.BL_PERIOD_ID = T20.ROW_ID (+) AND
T27.PAYMENT_TERM_ID = T23.ROW_ID (+) AND
T12.BU_ID = T19.PAR_ROW_ID (+) AND
T27.ACCNT_ID = T25.PAR_ROW_ID (+) AND
T27.ORDER_ID = T18.ROW_ID (+) AND
T4.SRC_INVLOC_ID = T3.ROW_ID (+) AND
T27.ORDER_ID = T4.ROW_ID (+) AND
T27.ACCNT_ID = T24.PAR_ROW_ID (+) AND
T18.PR_DEPOSIT_ID = T21.ROW_ID (+) AND
T27.BL_ADDR_ID = T9.ADDR_PER_ID (+) AND T27.ACCNT_ID = T9.ACCNT_ID (+) AND
T27.BL_ADDR_ID = T1.ROW_ID (+) AND
T25.PR_POSTN_ID = T13.POSITION_ID (+) AND T25.ROW_ID = T13.OU_EXT_ID (+) AND
T13.POSITION_ID = T7.ROW_ID (+) AND
T13.POSITION_ID = T6.PAR_ROW_ID (+) AND
T6.PR_EMP_ID = T11.PAR_ROW_ID (+) AND
(T27.INVC_TYPE_CD = :1)
ORDER BY
T27.INVC_DT;
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 2576210427
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 39M| 71G| | 624M (1)|278:42:59 |
| 1 | SORT ORDER BY | | 39M| 71G| 150G| 624M (1)|278:42:59 |
| 2 | NESTED LOOPS OUTER | | 39M| 71G| | 610M (1)|272:11:24 |
| 3 | NESTED LOOPS OUTER | | 39M| 70G| | 515M (1)|229:48:41 |
| 4 | NESTED LOOPS OUTER | | 39M| 69G| | 483M (1)|215:41:04 |
| 5 | NESTED LOOPS OUTER | | 39M| 68G| | 483M (1)|215:41:04 |
| 6 | NESTED LOOPS OUTER | | 39M| 67G| | 483M (1)|215:41:04 |
| 7 | NESTED LOOPS OUTER | | 39M| 66G| | 406M (1)|181:17:50 |
| 8 | NESTED LOOPS OUTER | | 39M| 65G| | 343M (1)|153:12:57 |
| 9 | NESTED LOOPS OUTER | | 39M| 64G| | 311M (1)|139:04:56 |
| 10 | NESTED LOOPS OUTER | | 39M| 63G| | 185M (1)| 82:37:56 |
| 11 | NESTED LOOPS OUTER | | 39M| 54G| | 108M (1)| 48:11:29 |
| 12 | NESTED LOOPS OUTER | | 39M| 53G| | 108M (1)| 48:11:29 |
| 13 | NESTED LOOPS OUTER | | 39M| 51G| | 76M (1)| 34:03:51 |
| 14 | NESTED LOOPS OUTER | | 39M| 49G| | 76M (1)| 34:03:51 |
| 15 | NESTED LOOPS OUTER | | 39M| 46G| | 76M (1)| 34:03:51 |
| 16 | NESTED LOOPS OUTER | | 39M| 44G| | 76M (1)| 34:03:51 |
| 17 | NESTED LOOPS OUTER | | 39M| 40G| | 65M (1)| 29:25:49 |
| 18 | NESTED LOOPS OUTER | | 39M| 39G| | 65M (1)| 29:25:49 |
| 19 | NESTED LOOPS OUTER | | 39M| 38G| | 65M (1)| 29:25:49 |
| 20 | NESTED LOOPS OUTER | | 39M| 34G| | 65M (1)| 29:17:44 |
| 21 | NESTED LOOPS OUTER | | 39M| 32G| | 65M (1)| 29:17:08 |
| 22 | NESTED LOOPS OUTER | | 39M| 31G| | 65M (1)| 29:09:04 |
| 23 | NESTED LOOPS OUTER | | 39M| 30G| | 2043K (9)| 00:54:42 |
| 24 | NESTED LOOPS OUTER | | 39M| 30G| | 2043K (9)| 00:54:42 |
| 25 | NESTED LOOPS OUTER | | 39M| 25G| | 2015K (7)| 00:53:57 |
| 26 | NESTED LOOPS OUTER | | 39M| 22G| | 2015K (7)| 00:53:57 |
| 27 | NESTED LOOPS OUTER | | 39M| 16G| | 2015K (7)| 00:53:57 |
|* 28 | TABLE ACCESS FULL | S_INVOICE | 39M| 9G| | 2015K (7)| 00:53:57 |
| 29 | TABLE ACCESS BY INDEX ROWID| S_PROJ | 1 | 188 | | 1 (0)| 00:00:01 |
|* 30 | INDEX UNIQUE SCAN | S_PROJ_P1 | 1 | | | 1 (0)| 00:00:01 |
| 31 | TABLE ACCESS BY INDEX ROWID | S_PAYMENT_TERM | 1 | 156 | | 1 (0)| 00:00:01 |
|* 32 | INDEX UNIQUE SCAN | S_PAYMENT_TERM_P1 | 1 | | | 1 (0)| 00:00:01 |
| 33 | TABLE ACCESS BY INDEX ROWID | S_INSCLM_ELMNT | 1 | 77 | | 1 (0)| 00:00:01 |
|* 34 | INDEX UNIQUE SCAN | S_INSCLM_ELMNT_P1 | 1 | | | 1 (0)| 00:00:01 |
| 35 | TABLE ACCESS BY INDEX ROWID | S_INS_CLAIM | 1 | 134 | | 1 (0)| 00:00:01 |
|* 36 | INDEX UNIQUE SCAN | S_INS_CLAIM_P1 | 1 | | | 1 (0)| 00:00:01 |
| 37 | TABLE ACCESS BY INDEX ROWID | S_PERIOD | 1 | 19 | | 1 (0)| 00:00:01 |
|* 38 | INDEX UNIQUE SCAN | S_PERIOD_P1 | 1 | | | 1 (0)| 00:00:01 |
| 39 | TABLE ACCESS BY INDEX ROWID | S_USER | 1 | 25 | | 2 (0)| 00:00:01 |
|* 40 | INDEX UNIQUE SCAN | S_USER_U2 | 1 | | | 1 (0)| 00:00:01 |
| 41 | TABLE ACCESS BY INDEX ROWID | S_ORDER_TNTX | 1 | 26 | | 2 (0)| 00:00:01 |
|* 42 | INDEX UNIQUE SCAN | S_ORDER_TNTX_P1 | 1 | | | 1 (0)| 00:00:01 |
| 43 | TABLE ACCESS BY INDEX ROWID | S_DEPOSIT_TNT | 1 | 45 | | 1 (0)| 00:00:01 |
|* 44 | INDEX UNIQUE SCAN | S_DEPOSIT_TNT_P1 | 1 | | | 1 (0)| 00:00:01 |
| 45 | TABLE ACCESS BY INDEX ROWID | S_ORDER | 1 | 101 | | 2 (0)| 00:00:01 |
|* 46 | INDEX UNIQUE SCAN | S_ORDER_P1 | 1 | | | 1 (0)| 00:00:01 |
| 47 | TABLE ACCESS BY INDEX ROWID | S_INVLOC | 1 | 47 | | 1 (0)| 00:00:01 |
|* 48 | INDEX UNIQUE SCAN | S_INVLOC_P1 | 1 | | | 1 (0)| 00:00:01 |
| 49 | TABLE ACCESS BY INDEX ROWID | S_DOC_QUOTE | 1 | 21 | | 1 (0)| 00:00:01 |
|* 50 | INDEX UNIQUE SCAN | S_DOC_QUOTE_P1 | 1 | | | 1 (0)| 00:00:01 |
|* 51 | TABLE ACCESS FULL | S_ORG_EXT_TNTX | 1 | 94 | | 0 (0)| 00:00:01 |
| 52 | TABLE ACCESS BY INDEX ROWID | S_PTY_PAY_PRFL | 1 | 74 | | 1 (0)| 00:00:01 |
|* 53 | INDEX UNIQUE SCAN | S_PTY_PAY_PRFL_P1 | 1 | | | 1 (0)| 00:00:01 |
| 54 | TABLE ACCESS BY INDEX ROWID | S_ADDR_PER | 1 | 84 | | 2 (0)| 00:00:01 |
|* 55 | INDEX UNIQUE SCAN | S_ADDR_PER_P1 | 1 | | | 1 (0)| 00:00:01 |
| 56 | TABLE ACCESS BY INDEX ROWID | S_ADDR_PER | 1 | 57 | | 1 (0)| 00:00:01 |
|* 57 | INDEX UNIQUE SCAN | S_ADDR_PER_P1 | 1 | | | 1 (0)| 00:00:01 |
| 58 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 32 | | 1 (0)| 00:00:01 |
|* 59 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | | 1 (0)| 00:00:01 |
| 60 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 32 | | 1 (0)| 00:00:01 |
|* 61 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | | 1 (0)| 00:00:01 |
| 62 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 256 | | 2 (0)| 00:00:01 |
|* 63 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | | 1 (0)| 00:00:01 |
| 64 | TABLE ACCESS BY INDEX ROWID | S_ACCNT_POSTN | 1 | 32 | | 3 (0)| 00:00:01 |
|* 65 | INDEX RANGE SCAN | S_ACCNT_POSTN_U1 | 1 | | | 2 (0)| 00:00:01 |
| 66 | TABLE ACCESS BY INDEX ROWID | S_POSTN | 1 | 21 | | 1 (0)| 00:00:01 |
|* 67 | INDEX UNIQUE SCAN | S_POSTN_U2 | 1 | | | 1 (0)| 00:00:01 |
| 68 | TABLE ACCESS BY INDEX ROWID | S_USER | 1 | 25 | | 2 (0)| 00:00:01 |
|* 69 | INDEX UNIQUE SCAN | S_USER_U2 | 1 | | | 1 (0)| 00:00:01 |
| 70 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 32 | | 2 (0)| 00:00:01 |
|* 71 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | | 1 (0)| 00:00:01 |
| 72 | TABLE ACCESS BY INDEX ROWID | S_ASSET | 1 | 24 | | 2 (0)| 00:00:01 |
|* 73 | INDEX UNIQUE SCAN | S_ASSET_P1 | 1 | | | 2 (0)| 00:00:01 |
| 74 | TABLE ACCESS BY INDEX ROWID | S_CON_ADDR | 1 | 36 | | 3 (0)| 00:00:01 |
|* 75 | INDEX RANGE SCAN | S_CON_ADDR_U1 | 1 | | | 2 (0)| 00:00:01 |
|* 76 | INDEX UNIQUE SCAN | S_PARTY_P1 | 1 | 12 | | 1 (0)| 00:00:01 |
| 77 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT_X | 1 | 37 | | 2 (0)| 00:00:01 |
|* 78 | INDEX RANGE SCAN | S_ORG_EXT_X_U1 | 1 | | | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
28 - filter("T27"."INVC_TYPE_CD"=:1)
30 - access("T27"."PROJ_ID"="T8"."ROW_ID"(+))
32 - access("T27"."PAYMENT_TERM_ID"="T23"."ROW_ID"(+))
34 - access("T27"."ELEMENT_ID"="T26"."ROW_ID"(+))
36 - access("T26"."INSCLM_ID"="T14"."ROW_ID"(+))
38 - access("T27"."BL_PERIOD_ID"="T20"."ROW_ID"(+))
40 - access("T27"."LAST_UPD_BY"="T15"."PAR_ROW_ID"(+))
42 - access("T27"."ORDER_ID"="T18"."ROW_ID"(+))
44 - access("T18"."PR_DEPOSIT_ID"="T21"."ROW_ID"(+))
46 - access("T27"."ORDER_ID"="T4"."ROW_ID"(+))
48 - access("T4"."SRC_INVLOC_ID"="T3"."ROW_ID"(+))
50 - access("T4"."QUOTE_ID"="T12"."ROW_ID"(+))
51 - filter("T12"."BU_ID"="T19"."PAR_ROW_ID"(+))
53 - access("T27"."PER_PAY_PRFL_ID"="T2"."ROW_ID"(+))
55 - access("T27"."BL_ADDR_ID"="T1"."ROW_ID"(+))
57 - access("T27"."BL_ADDR_ID"="T22"."ROW_ID"(+))
59 - access("T8"."BU_ID"="T5"."PAR_ROW_ID"(+))
61 - access("T27"."REMIT_ORG_EXT_ID"="T16"."PAR_ROW_ID"(+))
63 - access("T27"."ACCNT_ID"="T25"."PAR_ROW_ID"(+))
65 - access("T25"."ROW_ID"="T13"."OU_EXT_ID"(+) AND "T25"."PR_POSTN_ID"="T13"."POSITION_ID"(+))
67 - access("T13"."POSITION_ID"="T6"."PAR_ROW_ID"(+))
69 - access("T6"."PR_EMP_ID"="T11"."PAR_ROW_ID"(+))
71 - access("T25"."BU_ID"="T10"."PAR_ROW_ID"(+))
73 - access("T3"."CG_ASSSET_ID"="T17"."ROW_ID"(+))
75 - access("T27"."BL_ADDR_ID"="T9"."ADDR_PER_ID"(+) AND "T27"."ACCNT_ID"="T9"."ACCNT_ID"(+))
filter("T27"."ACCNT_ID"="T9"."ACCNT_ID"(+))
76 - access("T13"."POSITION_ID"="T7"."ROW_ID"(+))
78 - access("T27"."ACCNT_ID"="T24"."PAR_ROW_ID"(+))
117 rows selected.SQL> EXPLAIN PLAN FOR
2 SELECT * FROM SIEBEL.S_INVOICE T27 WHERE T27.INVC_TYPE_CD=:1;
Explained.
SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
PLAN_TABLE_OUTPUT
Plan hash value: 1810797629
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 39M| 9G| 2016K (8)| 00:53:59 |
|* 1 | TABLE ACCESS FULL| S_INVOICE | 39M| 9G| 2016K (8)| 00:53:59 |
Predicate Information (identified by operation id):
1 - filter("T27"."INVC_TYPE_CD"=:1)
13 rows selected.Edited by: KODS on Feb 13, 2013 1:08 PMDear Ivan,
Please find the details below.
select * from dba_indexes where index_name = 'S_INVOICE_U1';
OWNER INDEX_NAME INDEX_TYPE TABLE_OWNER TABLE_NAME TABLE_TYPE UNIQUENESS COMPRESSION PREFIX_LENGTH TABLESPACE_NAME INI_TRANS MAX_TRANS INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS PCT_INCREASE PCT_THRESHOLD INCLUDE_COLUMN FREELISTS FREELIST_GROUPS PCT_FREE LOGGING BLEVEL LEAF_BLOCKS DISTINCT_KEYS AVG_LEAF_BLOCKS_PER_KEY AVG_DATA_BLOCKS_PER_KEY CLUSTERING_FACTOR STATUS NUM_ROWS SAMPLE_SIZE LAST_ANALYZED DEGREE INSTANCES PARTITIONED TEMPORARY GENERATED SECONDARY BUFFER_POOL USER_STATS DURATION PCT_DIRECT_ACCESS ITYP_OWNER ITYP_NAME PARAMETERS GLOBAL_STATS DOMIDX_STATUS DOMIDX_OPSTATUS FUNCIDX_STATUS JOIN_INDEX IOT_REDUNDANT_PKEY_ELIM DROPPED
SIEBEL S_INVOICE_U1 NORMAL SIEBEL S_INVOICE TABLE UNIQUE DISABLED CRMSBL_AEM_INDEX 2 255 65536 1 2147483645 10 NO 3 902796 196739390 1 1 125598294 VALID 196739390 196739390 10-02-13 1 1 NO N N N DEFAULT NO YES NO NO NO
select * from dba_ind_columns where index_name = 'S_INVOICE_U1' order by column_position;
INDEX_OWNER INDEX_NAME TABLE_OWNER TABLE_NAME COLUMN_NAME COLUMN_POSITION COLUMN_LENGTH CHAR_LENGTH DESCEND
SIEBEL S_INVOICE_U1 SIEBEL S_INVOICE INVC_NUM 1 200 50 ASC
SIEBEL S_INVOICE_U1 SIEBEL S_INVOICE INVC_TYPE_CD 2 120 30 ASC
SIEBEL S_INVOICE_U1 SIEBEL S_INVOICE CONFLICT_ID 3 60 15 ASC -
Select query taking more time..
Hi friends..
The below inner join statement is taking more time , can any body sugget me to improve the performance . I tried FOR ALL ENTRIES also but that also taking more time than inner join statement .
SELECT a~vbeln from vbap as a inner join vakpa as b
on avbeln = bvbeln
into corresponding fields of table IT_VAKPA
where a~WERKS IN S_IWERKS
and a~pstyv NE 'ZRS'
and b~vkorg = IVKORG
and b~audat IN IAUDAT
and b~vtweg IN IVTWEG.
Regards
ChetanHi Chetan ,
VAKPA is an index table. From the select query , it has been observed that you are not fetching any data from VAKPA. Only you have added some selection paramenters in where clause of select query.
My suggestion will be instead of using VAKPA in inner join you use VBAK along with VBAP. All the fields that you are using as selection condition from VAKPA are there in VBAK.
I am sure performance of query will be improved.
If still duo to business logic you need to use VAKPA, try to create secondary non unique index on fields VKORD,AUDATand VTWEG on table VAKPA.
However I will recommend you to go for first option only. If this does not work then go for second option.
Hopfully this will help you.
Regards,
Nikhil -
Oracle query taking more time in SSRS
Hi All
we have report which connects to Orale DB . the Query for the datset is running in 9 Secs in PL/sql developer but the same query is taking more than 150 secs in SSRS. we are using Oracleclient type provider.
Surendra ThotaHi Surendra,
Based on the current description, I understand that you may use Oracle Provider for OLE DB to connect Oracle database. If so, I suggest you using Microsoft OLE DB Provider for Oracle to compare the query time between SQLPlus and SSRS.
Here is a relative thread (SSRS Report with Oracle database performance problems) for your reference.
Hope this helps.
Regards,
Heidi Duan
If you have any feedback on our support, please click
here.
Heidi Duan
TechNet Community Support -
Why is query taking too much time ?
Hi gurus,
I have a table name test which has 100000 records in it,now the question i like to ask is.
when i query select * from test ; no proble with responce time, but when the next day i fire the above query it is taking too much of time say 3 times.i would also like to tell you that everything is ok in respect of tuning,the db is properly tuned, network is tuned properly. what could be the hurting factor here ??
take care
All expertise.Here is a small test on my windows PC.
oracle 9i Rel1.
Table : emp_test
number of records : 42k
set autot trace exp stat
15:29:13 jaffar@PRIMEDB> select * from emp_test;
41665 rows selected.
Elapsed: 00:00:02.06 ==> response time.
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=24 Card=41665 Bytes=916630)
1 0 TABLE ACCESS (FULL) OF 'EMP_TEST' (Cost=24 Card=41665 Bytes=916630)
Statistics
0 recursive calls
0 db block gets
2951 consistent gets
178 physical reads
0 redo size
1268062 bytes sent via SQL*Net to client
31050 bytes received via SQL*Net from client
2779 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
41665 rows processed
15:29:40 jaffar@PRIMEDB> delete from emp_test where deptno = 10;
24998 rows deleted.
Elapsed: 00:00:10.06
15:31:19 jaffar@PRIMEDB> select * from emp_test;
16667 rows selected.
Elapsed: 00:00:00.09 ==> response time
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=24 Card=41665 Bytes=916630)
1 0 TABLE ACCESS (FULL) OF 'EMP_TEST' (Cost=24 Card=41665 Bytes=916630)
Statistics
0 recursive calls
0 db block gets
1289 consistent gets
0 physical reads
0 redo size
218615 bytes sent via SQL*Net to client
12724 bytes received via SQL*Net from client
1113 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
16667 rows processed -
Delete query taking too much time
Hi All,
my delete query is taking too much time. around 1hr 30 min for 1.5 lac records.
Though I have dropped mv log on the table & disabled all the triggers on it.
Moreover deletion is based on primary key .
delete from table_name where primary_key in (values)
above is dummy format of my query.
can anyone please tell me what could be other reason that query is performing that slow.
Is there anything to check in DB other than triggers,mv log,constraints in order to improve the performance?
Please reply asap.Delete is the most time consuming operation, as the whole record data has to be stored at the undo segments. On the other hand, there is a part of the query used to select records to delete that probably is adding an extra overhead to the process, the in (values) clause. It would be nice on your side to post another dummy from this (values) clause. I could figure out this is a subquery, and in order for you to obtain this list you have to run a inefficient query.
You can gather the execution plan so you can see where the most heavy part of th query is. This way a better tuning approach and a more accurate diagnostic can be issued.
~ Madrid. -
Query taking more than 1/2 hour for 80 million rows in fact table
Hi All,
I am stuck in this query as it it taking more than 35 mins to execute for 80 million rows. My SLA is less than 30 mins for 160 million rows i.e. double the number.
Below is the query and the Execution Plan.
SELECT txn_id AS txn_id,
acntng_entry_src AS txn_src,
f.hrarchy_dmn_id AS hrarchy_dmn_id,
f.prduct_dmn_id AS prduct_dmn_id,
f.pstng_crncy_id AS pstng_crncy_id,
f.acntng_entry_typ AS acntng_entry_typ,
MIN (d.date_value) AS min_val_dt,
GREATEST (MAX (d.date_value),
LEAST ('07-Feb-2009', d.fin_year_end_dt))
AS max_val_dt
FROM Position_Fact f, Date_Dimension d
WHERE f.val_dt_dmn_id = d.date_dmn_id
GROUP BY txn_id,
acntng_entry_src,
f.hrarchy_dmn_id,
f.prduct_dmn_id,
f.pstng_crncy_id,
f.acntng_entry_typ,
d.fin_year_end_dt
Execution Plan is as:
11 HASH JOIN Cost: 914,089 Bytes: 3,698,035,872 Cardinality: 77,042,414
9 TABLE ACCESS FULL TABLE Date_Dimension Cost: 29 Bytes: 94,960 Cardinality: 4,748
10 TABLE ACCESS FULL TABLE Position_Fact Cost: 913,693 Bytes: 2,157,187,592 Cardinality: 77,042,414
Kindly suggest, how to make it faster.
Regards,
SidThe above is just a part of the query that is taking the maximum time.
Kindly find the entire query and the plan as follows:
WITH MIN_MX_DT
AS
( SELECT
TXN_ID AS TXN_ID,
ACNTNG_ENTRY_SRC AS TXN_SRC,
F.HRARCHY_DMN_ID AS HRARCHY_DMN_ID,
F.PRDUCT_DMN_ID AS PRDUCT_DMN_ID,
F.PSTNG_CRNCY_ID AS PSTNG_CRNCY_ID,
F.ACNTNG_ENTRY_TYP AS ACNTNG_ENTRY_TYP,
MIN (D.DATE_VALUE) AS MIN_VAL_DT,
GREATEST (MAX (D.DATE_VALUE), LEAST (:B1, D.FIN_YEAR_END_DT))
AS MAX_VAL_DT
FROM
proj_PSTNG_FCT F, proj_DATE_DMN D
WHERE
F.VAL_DT_DMN_ID = D.DATE_DMN_ID
GROUP BY
TXN_ID,
ACNTNG_ENTRY_SRC,
F.HRARCHY_DMN_ID,
F.PRDUCT_DMN_ID,
F.PSTNG_CRNCY_ID,
F.ACNTNG_ENTRY_TYP,
D.FIN_YEAR_END_DT),
SLCT_RCRDS
AS (
SELECT
M.TXN_ID,
M.TXN_SRC,
M.HRARCHY_DMN_ID,
M.PRDUCT_DMN_ID,
M.PSTNG_CRNCY_ID,
M.ACNTNG_ENTRY_TYP,
D.DATE_VALUE AS VAL_DT,
D.DATE_DMN_ID,
D.FIN_WEEK_NUM AS FIN_WEEK_NUM,
D.FIN_YEAR_STRT AS FIN_YEAR_STRT,
D.FIN_YEAR_END AS FIN_YEAR_END
FROM
MIN_MX_DT M, proj_DATE_DMN D
WHERE
D.HOLIDAY_IND = 0
AND D.DATE_VALUE >= MIN_VAL_DT
AND D.DATE_VALUE <= MAX_VAL_DT),
DLY_HDRS
AS (
SELECT
S.TXN_ID AS TXN_ID,
S.TXN_SRC AS TXN_SRC,
S.DATE_DMN_ID AS VAL_DT_DMN_ID,
S.HRARCHY_DMN_ID AS HRARCHY_DMN_ID,
S.PRDUCT_DMN_ID AS PRDUCT_DMN_ID,
S.PSTNG_CRNCY_ID AS PSTNG_CRNCY_ID,
SUM
DECODE
PNL_TYP_NM,
:B5, DECODE (NVL (F.PSTNG_TYP, :B2),
:B2, NVL (F.PSTNG_AMNT, 0) * (-1),
NVL (F.PSTNG_AMNT, 0)),
0))
AS MTM_AMT,
NVL (
LAG (
SUM (
DECODE (
PNL_TYP_NM,
:B5, DECODE (NVL (F.PSTNG_TYP, :B2),
:B2, NVL (F.PSTNG_AMNT, 0) * (-1),
NVL (F.PSTNG_AMNT, 0)),
0)))
OVER (
PARTITION BY S.TXN_ID,
S.TXN_SRC,
S.HRARCHY_DMN_ID,
S.PRDUCT_DMN_ID,
S.PSTNG_CRNCY_ID
ORDER BY S.VAL_DT),
0)
AS YSTDY_MTM,
SUM (
DECODE (
PNL_TYP_NM,
:B4, DECODE (NVL (F.PSTNG_TYP, :B2),
:B2, NVL (F.PSTNG_AMNT, 0) * (-1),
NVL (F.PSTNG_AMNT, 0)),
0))
AS CASH_AMT,
SUM (
DECODE (
PNL_TYP_NM,
:B3, DECODE (NVL (F.PSTNG_TYP, :B2),
:B2, NVL (F.PSTNG_AMNT, 0) * (-1),
NVL (F.PSTNG_AMNT, 0)),
0))
AS PAY_REC_AMT,
S.VAL_DT,
S.FIN_WEEK_NUM,
S.FIN_YEAR_STRT,
S.FIN_YEAR_END,
NVL (TRUNC (F.REVSN_DT), S.VAL_DT) AS REVSN_DT,
S.ACNTNG_ENTRY_TYP AS ACNTNG_ENTRY_TYP
FROM
SLCT_RCRDS S,
proj_PSTNG_FCT F,
proj_ACNT_DMN AD,
proj_PNL_TYP_DMN PTD
WHERE
S.TXN_ID = F.TXN_ID(+)
AND S.TXN_SRC = F.ACNTNG_ENTRY_SRC(+)
AND S.HRARCHY_DMN_ID = F.HRARCHY_DMN_ID(+)
AND S.PRDUCT_DMN_ID = F.PRDUCT_DMN_ID(+)
AND S.PSTNG_CRNCY_ID = F.PSTNG_CRNCY_ID(+)
AND S.DATE_DMN_ID = F.VAL_DT_DMN_ID(+)
AND S.ACNTNG_ENTRY_TYP = F.ACNTNG_ENTRY_TYP(+)
AND SUBSTR (AD.ACNT_NUM, 0, 1) IN (1, 2, 3)
AND NVL (F.ACNT_DMN_ID, 1) = AD.ACNT_DMN_ID
AND NVL (F.PNL_TYP_DMN_ID, 1) = PTD.PNL_TYP_DMN_ID
GROUP BY
S.TXN_ID,
S.TXN_SRC,
S.DATE_DMN_ID,
S.HRARCHY_DMN_ID,
S.PRDUCT_DMN_ID,
S.PSTNG_CRNCY_ID,
S.VAL_DT,
S.FIN_WEEK_NUM,
S.FIN_YEAR_STRT,
S.FIN_YEAR_END,
TRUNC (F.REVSN_DT),
S.ACNTNG_ENTRY_TYP,
F.TXN_ID)
SELECT
D.TXN_ID,
D.VAL_DT_DMN_ID,
D.REVSN_DT,
D.TXN_SRC,
D.HRARCHY_DMN_ID,
D.PRDUCT_DMN_ID,
D.PSTNG_CRNCY_ID,
D.YSTDY_MTM,
D.MTM_AMT,
D.CASH_AMT,
D.PAY_REC_AMT,
MTM_AMT + CASH_AMT + PAY_REC_AMT AS DLY_PNL,
SUM (
MTM_AMT + CASH_AMT + PAY_REC_AMT)
OVER (
PARTITION BY D.TXN_ID,
D.TXN_SRC,
D.HRARCHY_DMN_ID,
D.PRDUCT_DMN_ID,
D.PSTNG_CRNCY_ID,
D.FIN_WEEK_NUM || D.FIN_YEAR_STRT || D.FIN_YEAR_END
ORDER BY D.VAL_DT)
AS WTD_PNL,
SUM (
MTM_AMT + CASH_AMT + PAY_REC_AMT)
OVER (
PARTITION BY D.TXN_ID,
D.TXN_SRC,
D.HRARCHY_DMN_ID,
D.PRDUCT_DMN_ID,
D.PSTNG_CRNCY_ID,
D.FIN_YEAR_STRT || D.FIN_YEAR_END
ORDER BY D.VAL_DT)
AS YTD_PNL,
D.ACNTNG_ENTRY_TYP AS ACNTNG_PSTNG_TYP,
'EOD ETL' AS CRTD_BY,
SYSTIMESTAMP AS CRTN_DT,
NULL AS MDFD_BY,
NULL AS MDFCTN_DT
FROM
DLY_HDRS D
Plan
SELECT STATEMENT ALL_ROWSCost: 11,950,256 Bytes: 3,369,680,886 Cardinality: 7,854,734
25 WINDOW SORT Cost: 11,950,256 Bytes: 3,369,680,886 Cardinality: 7,854,734
24 WINDOW SORT Cost: 11,950,256 Bytes: 3,369,680,886 Cardinality: 7,854,734
23 VIEW Cost: 10,519,225 Bytes: 3,369,680,886 Cardinality: 7,854,734
22 WINDOW BUFFER Cost: 10,519,225 Bytes: 997,551,218 Cardinality: 7,854,734
21 SORT GROUP BY Cost: 10,519,225 Bytes: 997,551,218 Cardinality: 7,854,734
20 HASH JOIN Cost: 10,296,285 Bytes: 997,551,218 Cardinality: 7,854,734
1 TABLE ACCESS FULL TABLE proj_PNL_TYP_DMN Cost: 3 Bytes: 45 Cardinality: 5
19 HASH JOIN Cost: 10,296,173 Bytes: 2,695,349,628 Cardinality: 22,841,946
5 VIEW VIEW index$_join$_007 Cost: 3 Bytes: 84 Cardinality: 7
4 HASH JOIN
2 INDEX FAST FULL SCAN INDEX (UNIQUE) proj_ACNT_DMN_PK Cost: 1 Bytes: 84 Cardinality: 7
3 INDEX FAST FULL SCAN INDEX (UNIQUE) proj_ACNT_DMN_UNQ Cost: 1 Bytes: 84 Cardinality: 7
18 HASH JOIN RIGHT OUTER Cost: 10,293,077 Bytes: 68,925,225,244 Cardinality: 650,237,974
6 TABLE ACCESS FULL TABLE proj_PSTNG_FCT Cost: 913,986 Bytes: 4,545,502,426 Cardinality: 77,042,414
17 VIEW Cost: 7,300,017 Bytes: 30,561,184,778 Cardinality: 650,237,974
16 MERGE JOIN Cost: 7,300,017 Bytes: 230,184,242,796 Cardinality: 650,237,974
8 SORT JOIN Cost: 30 Bytes: 87,776 Cardinality: 3,376
7 TABLE ACCESS FULL TABLE proj_DATE_DMN Cost: 29 Bytes: 87,776 Cardinality: 3,376
15 FILTER
14 SORT JOIN Cost: 7,238,488 Bytes: 25,269,911,792 Cardinality: 77,042,414
13 VIEW Cost: 1,835,219 Bytes: 25,269,911,792 Cardinality: 77,042,414
12 SORT GROUP BY Cost: 1,835,219 Bytes: 3,698,035,872 Cardinality: 77,042,414
11 HASH JOIN Cost: 914,089 Bytes: 3,698,035,872 Cardinality: 77,042,414
9 TABLE ACCESS FULL TABLE proj_DATE_DMN Cost: 29 Bytes: 94,960 Cardinality: 4,748
10 TABLE ACCESS FULL TABLE proj_PSTNG_FCT Cost: 913,693 Bytes: 2,157,187,592 Cardinality: 77,042,414 -
Hi All,
I have one request to you..
basically i m running a query on Dev server ,its taking so much time but same query if i run on my production environment then it run so fast.
i checked the indexes on table its all are fine & in valid state.i rebuild the index again.
i also get the explain plan on both the environment,its given below..
EXPLAIN PLAN::: DEV Environment
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
| 0 | SELECT STATEMENT | 1 | 47 | 206K (2)|
| 1 | SORT AGGREGATE | | 1 | 47 | |
| 2 | NESTED LOOPS | | 1 | 47 | 206K (2)|
| 3 | TABLE ACCESS FULL | TRANSACTION_DETAILS | 1 | 22 | 206K (2)|
| 4 | TABLE ACCESS BY INDEX ROWID | TRANSACTIONS | 1 | 25 | 1 (0)|
| 5 | INDEX UNIQUE SCAN | TRA_PK | 1 | | 1 (0)|
EXPLAIN PLAN::: Production Environment.
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 1 | 48 | 296 (1)|
| 1 | SORT AGGREGATE | | 1 | 48 | |
| 2 | TABLE ACCESS BY INDEX ROWID | TRANSACTION_DETAILS | 1 | 23 | 4 (0)|
| 3 | NESTED LOOPS | | 83 | 3984 | 296 (1)|
| 4 | TABLE ACCESS BY INDEX ROWID| TRANSACTIONS | 60 | 1500 | 55 (0)|
| 5 | INDEX RANGE SCAN | TRA_CODE_TYPE | 61 | | 4 (0)|
| 6 | INDEX RANGE SCAN | TRAD_PK | 2 | | 3 (0)|
please help me out ,its very urgent.thanks in advance.
Regards
Sunny.
Edited by: Sunny on Jul 14, 2011 1:24 PMSunny wrote:
Justin,
Please find the replay as per your queries.
Are the statistics on the tables accurate- How can i know the statistics on the tables are accurate?See http://jonathanlewis.wordpress.com/2009/05/11/cardinality-feedback/
>
How do you gather statistics?- i find the statistics on table lavel & schema lavel also.I believe he was asking what command you use to gather the statistics. If, for example, you created the big table with a few rows, then populated them with a lot of rows without regathering statistics, you could have very misleading statistics. The opposite is possible too - some data skew in the large number, followed by gathering statistics with the 10g default statistics gathering, could give you bogus statistics. See http://jonathanlewis.wordpress.com/category/oracle/statistics/histograms/
>
How many rows are in the tables?- its using two table in this query.
Transaction table-40 rows
Transaction_detail-51151804 rows.
advice me more in this.Please show the plans including the estimated and actual cardinalities. Something is telling the optimizer that a full table scan is better than nested loops with index range scans. Also show us the non-default init.ora settings.
>
Regards
sunnyYou also need to show us in detail which version you are on. Remember, this is a volunteer forum, "urgent" is not a nice thing to say.
Maybe you are looking for
-
In songs view, sort by 'album' alone stopped working
I normally prefer to view my songs in iTunes using the 'Songs' view, listing everything with the details shown. I'll usually set it to sort by 'Album'. Clicking on the 'Album' header used to give me options that I could cycle through, but suddenly it
-
Take Control of Workflow with Workflow Analyzer! See Note 1369938.1
Take Control of Workflow with Workflow Analyzer! Immediate Analysis and Output of your EBS Workflow Environment. The EBS Workflow Analyzer is a script that reviews the current Workflow Footprint, analyzes the configurations, environment, p
-
Hi Colleagues, I need to make a function call from 1 SAP system to another SAP system. Please let me know if I should create a new ABAP RFC connection between the 2 systems. If so please let me know the procedure to create a new ABAP connection. Shou
-
Hello All Where do we assign Business Roles to Org Unit / Position. Can somebody please provide the navigation. I am in training and actually I want to get the business role created by me displayed when I log to CRM Web Client. How to do ... Thx DM
-
Windows Mobile 5.0 L2TP/IPSec native VPN to 3030
Has anyone successfully setup a VPN using the built in VPN client in Windows Mobile 5.0 to a Cisco 3030? I am running into problems but have no idea why. I followed chapter 13 of "The Complete Cisco VPN Configuration Guide" from Cisco Press, to confi