Old query taking substantial CPU time in AWR report
Hi,
We have a particular query which used to generate substantial CPU wait event in the AWR report.On of our DBA's killed the query some days back but still today's AWR report shows that particular query as the largest CPU consumer (50%). When I checked from the view V$SQL the last execution time was of 23-02-2011.
My question is after the query gets killed does it still show in the v$SQL ? And why is it still showing in the SQL BY ELAPSED TIME section ?
Please help.
No it is a select statement. I AM PASTING THE QUERY BELOW.
select /*+ FULL(COMP_TM) FULL(TRANS_TM) FULL(INVC_TM) */
CUST_BE_ID ,
DISTR_BE_ID ,
FG_BE_ID ,
KIT_BE_ID ,
BG_ID_NO_BE_ID ,
ACTL_TERR_BE_ID ,
CORE_TERR_BE_ID ,
sum( JNJ_LIST_AMT ) AS JNJ_LIST_AMT,
sum( JNJ_PYMT_AMT ) AS JNJ_PYMT_AMT,
sum( JNJ_QTY ) AS JNJ_QTY,
sum( JNJ_REB_AMT ) AS JNJ_REB_AMT,
sum( JNJ_SLS_AMT ) AS JNJ_SLS_AMT,
sum( KIT_LIST_AMT ) AS KIT_LIST_AMT,
sum( KIT_QTY ) AS KIT_QTY,
sum( KIT_SLS_AMT ) AS KIT_SLS_AMT,
sum( FG_PYMT_AMT ) AS FG_PYMT_AMT,
sum( FG_QTY ) AS FG_QTY,
sum( FG_REB_AMT ) AS FG_REB_AMT,
sum( FG_SLS_AMT ) AS FG_SLS_AMT,
sum( FG_LIST_AMT ) AS FG_LIST_AMT,
to_date('15'||substr(COMP_TM.FISC_MO_CD,8,2)||substr(COMP_TM.FISC_MO_CD,3,4),'DDMMYYYY') AS TRANS_MO_DATE,
to_number(substr(COMP_TM.FISC_MO_CD,3,4) ) AS PRD_YR_CD,
to_number(substr(COMP_TM.FISC_MO_CD,8,2) ) AS PRD_MO_CD,
CONTR_PRD_TIER_NO,
COMP_TM.FISC_MO_OID AS COMP_MO_BE_ID,
CLSD_YR_FLG,
ADJM_TRANS_CD,
INVC_TM.FISC_MO_OID AS INVC_MO_BE_ID,
ORD_TYP_CD,
TRANS_TM.FISC_MO_OID AS TRANS_MO_BE_ID
from
FACT_DLY_ALGND_SLS F, DIM_TM_MV TRANS_TM,
DIM_TM_MV INVC_TM, DIM_TM_MV COMP_TM
/***** comment out for loading historical data.... ***/
WHERE F.PRD_YR_CD >= (select case when to_number(to_char(sysdate,'MM')) <= 3
then to_number(to_char(sysdate,'YYYY'))-1
else to_number(to_char(sysdate,'YYYY'))
end case from dual
-- and F.PRD_YR_CD = '2008'
AND F.COMP_DT_BE_ID=COMP_TM.BE_ID
AND F.TRANSACTION_DATE = TRANS_TM.DAY_STRT_PRD_OF_TM
AND TRANS_TM.DAY_OID = TRANS_TM.BE_ID
AND F.INVC_DT = INVC_TM.DAY_STRT_PRD_OF_TM
AND INVC_TM.DAY_OID = INVC_TM.BE_ID
group by
CUST_BE_ID ,
DISTR_BE_ID ,
FG_BE_ID ,
KIT_BE_ID ,
BG_ID_NO_BE_ID ,
ACTL_TERR_BE_ID ,
CORE_TERR_BE_ID ,
to_date('15'||substr(COMP_TM.FISC_MO_CD,8,2)||substr(COMP_TM.FISC_MO_CD,3,4),'DDMMYYYY'),
to_number(substr(COMP_TM.FISC_MO_CD,3,4) ),
to_number(substr(COMP_TM.FISC_MO_CD,8,2) ),
CONTR_PRD_TIER_NO,
COMP_TM.FISC_MO_OID ,
CLSD_YR_FLG,
ADJM_TRANS_CD,
INVC_TM.FISC_MO_OID ,
ORD_TYP_CD,
TRANS_TM.FISC_MO_OIDI am wrong in the previous post. Actually the elapsed time in the AWR was showing 840 mins.
Similar Messages
-
Updating AUD$ consumes most of the time in AWR report.
Hi All,
It's really good to see, great people passing their help to folks like us and making our life easier. Going forward,I am investigating on of the performance issue and analyzing the AWR report. By looking AWR, I did find updating aud$ taking most of times in AWR report. Following are the information , I extracted from the database and AWR report. Please see, what can be done to take away the bottlenecks.
Version -- 11.1.0.6.0
OS -- HPUXX Itanium
Event Waits Time(s) (ms) time Wait Class
enq: BF - allocation contentio 9,007 6,893 765 45.5 Other
DB CPU 2,565 16.9
db file scattered read 555,031 2,428 4 16.0 User I/O
read by other session 288,910 1,428 5 9.4 User I/O
PX Deq Credit: Session Stats 22,650 231 10 1.5 Other
209fr01svbb5s
wait % DB
Event Waits Time(s) (ms) time Wait Class
db file scattered read 291,023 1,973 7 61.6 User I/O
DB CPU 890 27.8
read by other session 81,495 340 4 10.6 User I/O
log file sync 1,210 21 17 .6 Commit
db file sequential read 30,452 15 0 .5 User I/O
Elapsed CPU Elap per % Total
Time (s) Time (s) Executions Exec (s) DB Time SQL Id
3,134 833 118 26.6 97.9 209fr01svbb5s
update sys.aud$ set action#=:2, returncode=:3, logoff$time=cast(SYS_EXTRACT_UTC(
systimestamp) as date), logoff$pread=:4, logoff$lread=:5, logoff$lwrite=:6, logo
ff$dead=:7, sessioncpu=:8 where sessionid=:1 and entryid=1 and action#=100
-------------------------- Plan from Cursor ---------------------------------------
SQL_ID 209fr01svbb5s, child number 0
update sys.aud$ set action#=:2, returncode=:3,
logoff$time=cast(SYS_EXTRACT_UTC(systimestamp) as date),
logoff$pread=:4, logoff$lread=:5, logoff$lwrite=:6, logoff$dead=:7,
sessioncpu=:8 where sessionid=:1 and entryid=1 and action#=100
Plan hash value: 1651467381
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | UPDATE STATEMENT | | | | 2 (100)| |
| 1 | UPDATE | AUD$ | | | | |
|* 2 | TABLE ACCESS FULL| AUD$ | 1 | 139 | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - filter(("ENTRYID"=1 AND "ACTION#"=100 AND "SESSIONID"=:1 AND
("SPARE2" IS NULL OR USERENV('ISDBA')='TRUE')))
++++ Last Anylzsed +++++
TABLE_NAME LAST_ANAL
AUD$ 08-NOV-07
++++++++ Table Size ++++++++++++++++++++++
SQL> select sum(bytes)/1024/1024 "Audit Size" from dba_segments where segment_name='AUD$';
Audit Size
2469RegardsBefore purging audit data I would suggest two things. First what is the time period for the report in question? If it is for a low usage period then the audit activity as a percentage of the overall load may be a bit distorted. It may also be worth checking to see what information the audit captured as you could have a contractual or legal obligation to capture the data.
Second and most import look to see what audit rules are in effect. By just removing a few unneeded rules such as auditing successful logins/logoffs or changing from by access to by session for specific objects you could potentially remove most of the activity being shown.
You may also want to check to see if a purge job has been set up. See dba_scheduler_jobs and Oracle proviced package: DBMS_AUDIT_MGMT.
HTH -- Mark D Powell -- -
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 -
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 -
Process SERVER0 its taking High CPU Time in XI
Hi,
We installed XI 3.0 develpoment server ,Process <b>SERVER0</b> its taking more CPU time.
We are using AS/400 OS & DB2 datbase.Can any one tell me the reason & Solution for this.
Thanks & Regards,
Gopinath.hi,
Actually the user XIRWBUSER its an RFC user but its running on many dialog process.I think high CPU time due to this user only.
using 5 work processes and 3/4 of the available CPU for an extended amount of time.
Total Total DB
Job or CPU Sync Async CPU
Task User Number Thread Pty Util I/O I/O Util
WP11 D6464 485368 00000010 20 54.0 25 37 27.8
WP05 X4242 498642 00000098 20 49.6 5 0 36.7
WP04 X4242 498641 00000014 20 48.8 1 0 39.1
WP02 X4242 498639 0000025A 20 47.1 2 0 37.8
WP06 X4242 498643 000001E6 20 43.7 0 0 38.3
WP00 X4242 498637 00000014 20 11.1 502 194 2.9
pls can any one help me
Regards,
Gopinath. -
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? -
Hi,
I have a Oracle 9.2 DB with 2 cpu's,when i took a statspack report i found that CPU Time is very hight i,e more that 81%....
one of the query is taking near about 51% CPU Usage...
i.e
SELECT /*+ INDEX (OM_COURSE_FEE OCF_CFC_CODE) */DISTINCT CF_COURSE_CODE FROM OM_COURSE_FEE,OT_STUDENT_FEE_COL_HEAD,OT_STUDENT_FEE_COL_DETL WHERE SFCH_SYS_ID = SFCD_SFCH_SYS_ID AND
SFCD_FEE_TYPE_CODE = CF_TYPE_CODE AND CF_COURSE_CODE IN ( 'PE1','PE2','CCT','CPT' ) AND SFCH_TXN_CODE = :b1 AND SFCD_SUBSCRBE_JOURNAL_YN IN ( 'T','R','1','C' ) AND SFCH_APPR_UID IS NOT NULL
AND SFCH_APPR_DT IS NOT NULL AND SFCH_NO = :b2 AND NOT EXISTS (SELECT 'X' FROM OM_STUDENT_HEAD WHERE STUD_SRN = SFCH_STUD_SRN_TEMP_NO AND NVL(STUD_CLO_STATUS,0) != 1 AND
NVL(STUD_REG_STATUS,0) != 23 AND STUD_COURSE_CODE != 'CCT' AND CF_COURSE_CODE= STUD_COURSE_CODE ) ORDER BY 1 DESCExplain Plan for......
SQL> select * from table(dbms_xplan.display());
PLAN_TABLE_OUTPUT
| Id | Operation | Name
| Rows | Bytes | Cost | Pstart| Pstop |
| 0 | SELECT STATEMENT |
PLAN_TABLE_OUTPUT
| 1 | 69 | 45 | | |
| 1 | SORT UNIQUE |
| 1 | 69 | 27 | | |
| 2 | TABLE ACCESS BY GLOBAL INDEX ROWID | OT_STUDENT_FEE_COL_DETL
| 1 | 12 | 2 | ROWID | ROW L |
| 3 | NESTED LOOPS |
| 1 | 69 | 9 | | |
PLAN_TABLE_OUTPUT
| 4 | NESTED LOOPS |
| 1 | 57 | 7 | | |
| 5 | TABLE ACCESS BY GLOBAL INDEX ROWID | OT_STUDENT_FEE_COL_HEAD
| 1 | 48 | 5 | ROWID | ROW L |
| 6 | INDEX SKIP SCAN | OT_STUDENT_FEE_COL_HEAD_UK0
1 | 1 | | 4 | | |
| 7 | INLIST ITERATOR |
| | | | | |
PLAN_TABLE_OUTPUT
| 8 | TABLE ACCESS BY INDEX ROWID | OM_COURSE_FEE
| 1 | 9 | 2 | | |
| 9 | INDEX RANGE SCAN | OCF_CFC_CODE
| 1 | | 1 | | |
| 10 | FILTER |
| | | | | |
| 11 | TABLE ACCESS BY GLOBAL INDEX ROWID| OM_STUDENT_HEAD
PLAN_TABLE_OUTPUT
| 1 | 21 | 4 | ROWID | ROW L |
| 12 | INDEX RANGE SCAN | IDM_STUD_SRN_COURSE
| 1 | | 3 | | |
| 13 | INDEX RANGE SCAN | IDM_SFCD_FEE_TYPE_CODE
| 34600 | | 1 | | |
PLAN_TABLE_OUTPUT
Note: cpu costing is off, PLAN_TABLE' is old version
21 rows selected.
SQL>Statspack report
DB Name DB Id Instance Inst Num Release Cluster Host
ai 1372079993 ai11 1 9.2.0.6.0 YES ai1
Snap Id Snap Time Sessions Curs/Sess Comment
Begin Snap: 175 12-Dec-08 13:21:33 ####### .0
End Snap: 176 12-Dec-08 13:56:09 ####### .0
Elapsed: 34.60 (mins)
Cache Sizes (end)
~~~~~~~~~~~~~~~~~
Buffer Cache: 3,264M Std Block Size: 8K
Shared Pool Size: 608M Log Buffer: 977K
Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
Redo size: 5,727.62 21,658.54
Logical reads: 16,484.89 62,336.32
Block changes: 32.49 122.88
Physical reads: 200.46 758.03
Physical writes: 5.08 19.23
User calls: 97.43 368.44
Parses: 11.66 44.11
Hard parses: 0.39 1.48
Sorts: 3.22 12.19
Logons: 0.02 0.06
Executes: 36.70 138.77
Transactions: 0.26
% Blocks changed per Read: 0.20 Recursive Call %: 28.65
Rollback per transaction %: 20.95 Rows per Sort: 131.16
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 98.79 In-memory Sort %: 99.99
Library Hit %: 98.92 Soft Parse %: 96.65
Execute to Parse %: 68.21 Latch Hit %: 99.98
Parse CPU to Parse Elapsd %: 60.50 % Non-Parse CPU: 99.48
Shared Pool Statistics Begin End
Memory Usage %: 90.06 89.79
% SQL with executions>1: 72.46 72.46
% Memory for SQL w/exec>1: 69.42 69.51
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
CPU time 3,337 81.43
db file sequential read 60,550 300 7.32
global cache cr request 130,852 177 4.33
db file scattered read 72,915 101 2.46
db file parallel read 3,384 75 1.84
Cluster Statistics for DB: ai Instance: ai11 Snaps: 175 -176
Global Cache Service - Workload Characteristics
Ave global cache get time (ms): 1.3
Ave global cache convert time (ms): 2.1
Ave build time for CR block (ms): 0.1
Ave flush time for CR block (ms): 0.3
Ave send time for CR block (ms): 0.3
Ave time to process CR block request (ms): 0.7
Ave receive time for CR block (ms): 4.9
Ave pin time for current block (ms): 0.0
Ave flush time for current block (ms): 0.0
Ave send time for current block (ms): 0.3
Ave time to process current block request (ms): 0.3
Ave receive time for current block (ms): 2.8
Global cache hit ratio: 1.5
Ratio of current block defers: 0.0
% of messages sent for buffer gets: 1.4
% of remote buffer gets: 0.1
Ratio of I/O for coherence: 1.1
Ratio of local vs remote work: 9.7
Ratio of fusion vs physical writes: 0.1
Global Enqueue Service Statistics
Ave global lock get time (ms): 0.8
Ave global lock convert time (ms): 0.0
Ratio of global lock gets vs global lock releases: 1.1
GCS and GES Messaging statistics
Ave message sent queue time (ms): 0.4
Ave message sent queue time on ksxp (ms): 2.7
Ave message received queue time (ms): 0.2
Ave GCS message process time (ms): 0.1
Ave GES message process time (ms): 0.1
% of direct sent messages: 19.4
% of indirect sent messages: 43.5
% of flow controlled messages: 37.1
GES Statistics for DB: ai Instance: ai11 Snaps: 175 -176
Statistic Total per Second per Trans
dynamically allocated gcs resourc 0 0.0 0.0
dynamically allocated gcs shadows 0 0.0 0.0
flow control messages received 0 0.0 0.0
flow control messages sent 0 0.0 0.0
gcs ast xid 0 0.0 0.0
gcs blocked converts 1,231 0.6 2.2
gcs blocked cr converts 2,432 1.2 4.4
gcs compatible basts 0 0.0 0.0
gcs compatible cr basts (global) 658 0.3 1.2
gcs compatible cr basts (local) 57,822 27.9 105.3
gcs cr basts to PIs 0 0.0 0.0
gcs cr serve without current lock 0 0.0 0.0
gcs error msgs 0 0.0 0.0
gcs flush pi msgs 821 0.4 1.5
gcs forward cr to pinged instance 0 0.0 0.0
gcs immediate (compatible) conver 448 0.2 0.8
gcs immediate (null) converts 1,114 0.5 2.0
gcs immediate cr (compatible) con 42,094 20.3 76.7
gcs immediate cr (null) converts 396,284 190.9 721.8
gcs msgs process time(ms) 42,220 20.3 76.9
gcs msgs received 545,133 262.6 993.0
gcs out-of-order msgs 5 0.0 0.0
gcs pings refused 1 0.0 0.0
gcs queued converts 0 0.0 0.0
gcs recovery claim msgs 0 0.0 0.0
gcs refuse xid 0 0.0 0.0
gcs retry convert request 0 0.0 0.0
gcs side channel msgs actual 2,397 1.2 4.4
gcs side channel msgs logical 232,024 111.8 422.6
gcs write notification msgs 15 0.0 0.0
gcs write request msgs 278 0.1 0.5
gcs writes refused 1 0.0 0.0
ges msgs process time(ms) 4,873 2.3 8.9
ges msgs received 39,769 19.2 72.4
global posts dropped 0 0.0 0.0
global posts queue time 0 0.0 0.0
global posts queued 0 0.0 0.0
global posts requested 0 0.0 0.0
global posts sent 0 0.0 0.0
implicit batch messages received 39,098 18.8 71.2
implicit batch messages sent 33,386 16.1 60.8
lmd msg send time(ms) 635 0.3 1.2
lms(s) msg send time(ms) 2 0.0 0.0
messages flow controlled 196,546 94.7 358.0
messages received actual 182,783 88.0 332.9
messages received logical 584,848 281.7 1,065.3
messages sent directly 102,657 49.4 187.0
messages sent indirectly 230,329 110.9 419.5
msgs causing lmd to send msgs 9,169 4.4 16.7
msgs causing lms(s) to send msgs 3,347 1.6 6.1
msgs received queue time (ms) 142,759 68.8 260.0
msgs received queued 584,818 281.7 1,065.2
msgs sent queue time (ms) 99,300 47.8 180.9
msgs sent queue time on ksxp (ms) 608,239 293.0 1,107.9
msgs sent queued 230,391 111.0 419.7
msgs sent queued on ksxp 229,013 110.3 417.1
GES Statistics for DB: ai Instance: ai11 Snaps: 175 -176
Statistic Total per Second per Trans
process batch messages received 65,059 31.3 118.5
process batch messages sent 50,959 24.5 92.8
Wait Events for DB: ai Instance: ai11 Snaps: 175 -176
-> s - second
-> cs - centisecond - 100th of a second
-> ms - millisecond - 1000th of a second
-> us - microsecond - 1000000th of a second
-> ordered by wait time desc, waits desc (idle events last)
Avg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
db file sequential read 60,550 0 300 5 110.3
global cache cr request 130,852 106 177 1 238.3
db file scattered read 72,915 0 101 1 132.8
db file parallel read 3,384 0 75 22 6.2
latch free 7,253 1,587 52 7 13.2
enqueue 44,947 0 16 0 81.9
log file parallel write 2,140 0 6 3 3.9
db file parallel write 341 0 5 14 0.6
global cache open x 1,134 3 4 4 2.1
CGS wait for IPC msg 166,993 164,390 4 0 304.2
library cache lock 3,169 0 3 1 5.8
log file sync 494 0 3 5 0.9
row cache lock 702 0 3 4 1.3
DFS lock handle 6,900 0 2 0 12.6
control file parallel write 689 0 2 3 1.3
control file sequential read 2,785 0 2 1 5.1
wait for master scn 687 0 2 2 1.3
global cache null to x 699 0 2 2 1.3
global cache s to x 778 5 1 2 1.4
direct path write 148 0 0 3 0.3
SQL*Net more data to client 3,621 0 0 0 6.6
global cache open s 149 0 0 2 0.3
library cache pin 78 0 0 2 0.1
ksxr poll remote instances 3,536 2,422 0 0 6.4
LGWR wait for redo copy 12 6 0 9 0.0
buffer busy waits 23 0 0 5 0.0
direct path read 9 0 0 10 0.0
buffer busy global CR 5 0 0 17 0.0
SQL*Net break/reset to clien 172 0 0 0 0.3
global cache quiesce wait 4 1 0 7 0.0
KJC: Wait for msg sends to c 86 0 0 0 0.2
BFILE get length 67 0 0 0 0.1
global cache null to s 9 0 0 1 0.0
BFILE open 6 0 0 0 0.0
BFILE read 60 0 0 0 0.1
BFILE internal seek 60 0 0 0 0.1
BFILE closure 6 0 0 0 0.0
cr request retry 4 4 0 0 0.0
SQL*Net message from client 201,907 0 180,583 894 367.8
gcs remote message 171,236 43,749 3,975 23 311.9
ges remote message 79,324 40,722 2,017 25 144.5
SQL*Net more data from clien 447 0 9 21 0.8
SQL*Net message to client 201,901 0 0 0 367.8
Background Wait Events for DB: ai Instance: ai11 Snaps: 175 -176
-> ordered by wait time desc, waits desc (idle events last)
Avg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
enqueue 44,666 0 16 0 81.4
latch free 4,895 108 6 1 8.9
log file parallel write 2,140 0 6 3 3.9
db file parallel write 341 0 5 14 0.6
CGS wait for IPC msg 166,969 164,366 4 0 304.1
DFS lock handle 6,900 0 2 0 12.6
control file parallel write 689 0 2 3 1.3
control file sequential read 2,733 0 2 1 5.0
wait for master scn 687 0 2 2 1.3
ksxr poll remote instances 3,528 2,419 0 0 6.4
LGWR wait for redo copy 12 6 0 9 0.0
db file sequential read 7 0 0 9 0.0
global cache null to x 26 0 0 2 0.0
global cache open x 16 0 0 1 0.0
global cache cr request 1 0 0 0 0.0
rdbms ipc message 28,636 20,600 16,937 591 52.2
gcs remote message 171,254 43,746 3,974 23 311.9
pmon timer 708 686 2,022 2856 1.3
ges remote message 79,305 40,719 2,017 25 144.5
smon timer 125 0 1,972 15776 0.2
SQL ordered by Gets for DB: ai Instance: ai11 Snaps: 175 -176
-> End Buffer Gets Threshold: 10000
-> Note that resources reported for PL/SQL includes the resources used by
all SQL statements called within the PL/SQL code. As individual SQL
statements are also reported, it is possible and valid for the summed
total % to exceed 100
CPU Elapsd
Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash Value
17,503,305 84 208,372.7 51.1 676.25 1218.80 17574787
SELECT /*+ INDEX (OM_COURSE_FEE OCF_CFC_CODE) */DISTINCT CF_COU
RSE_CODE FROM OM_COURSE_FEE,OT_STUDENT_FEE_COL_HEAD,OT_STUDENT
FEECOL_DETL WHERE SFCH_SYS_ID = SFCD_SFCH_SYS_ID AND SFCD_FE
E_TYPE_CODE = CF_TYPE_CODE AND CF_COURSE_CODE IN ( 'PE1','PE2',
'CCT','CPT' ) AND SFCH_TXN_CODE = :b1 AND SFCD_SUBSCRBE_JOURNAuser00726 wrote:
somw of the changes that have been done....
cai11_lmd0_15771.trc.
Thu Oct 2 13:35:48 2008
CKPT: Begin resize of buffer pool 3 (DEFAULT for block size 8192)
CKPT: Current size = 2512 MB, Target size = 3072 MB
CKPT: Resize completed for buffer pool DEFAULT for blocksize 8192
Thu Oct 2 13:35:50 2008
ALTER SYSTEM SET db_cache_size='3072M' SCOPE=BOTH SID='icai11';
Thu Oct 2 14:04:34 2008
ALTER SYSTEM SET sga_max_size='5244772679680' SCOPE=SPFILE SID='*';
ALTER SYSTEM SET sga_max_size='5244772679680' SCOPE=SPFILE SID='*';
Thu Oct 2 15:24:14 2008
CKPT: Begin resize of buffer pool 3 (DEFAULT for block size 8192)
CKPT: Current size = 3072 MB, Target size = 2512 MB
CKPT: Resize completed for buffer pool DEFAULT for blocksize 8192
Thu Oct 2 15:24:20 2008
ALTER SYSTEM SET db_cache_size='2512M' SCOPE=BOTH SID='icai11';
Thu Oct 2 15:32:33 2008
CKPT: Begin resize of buffer pool 3 (DEFAULT for block size 8192)
CKPT: Current size = 2512 MB, Target size = 3072 MB
CKPT: Resize completed for buffer pool DEFAULT for blocksize 8192
Thu Oct 2 15:32:34 2008
ALTER SYSTEM SET db_cache_size='3072M' SCOPE=BOTH SID='icai11';
Thu Oct 2 15:36:46 2008
ALTER SYSTEM SET shared_pool_size='640M' SCOPE=BOTH SID='icai11';
Thu Oct 2 16:33:52 2008
CKPT: Begin resize of buffer pool 3 (DEFAULT for block size 8192)
CKPT: Current size = 3072 MB, Target size = 2512 MB
CKPT: Resize completed for buffer pool DEFAULT for blocksize 8192
Thu Oct 2 16:33:56 2008
ALTER SYSTEM SET db_cache_size='2512M' SCOPE=BOTH SID='icai11';
Thu Oct 2 16:39:30 2008
ALTER SYSTEM SET pga_aggregate_target='750M' SCOPE=BOTH SID='icai11';Just to make certain that I am not missing anything, if the above you set (all scaled to GB just for the sake of comparison):
sga_max_size=4885GB
db_cache_size=3GB
shared_pool_size=0.625GB
pga_aggregate_target=0.733GB
The SQL statement is forcing the use of a specific index, is this the best index?:
SELECT /*+ INDEX (OM_COURSE_FEE OCF_CFC_CODE) */DISTINCT CF_COURSE_CODE FROM OM_COURSE_FEE,OT_STUDENT_FEE_COL_HEAD,OT_STUDENT_FEE_COL_DETL WHERE SFCH_SYS_ID = SFCD_SFCH_SYS_ID AND
SFCD_FEE_TYPE_CODE = CF_TYPE_CODE AND CF_COURSE_CODE IN ( 'PE1','PE2','CCT','CPT' ) AND SFCH_TXN_CODE = :b1 AND SFCD_SUBSCRBE_JOURNAL_YN IN ( 'T','R','1','C' ) AND SFCH_APPR_UID IS NOT NULL
AND SFCH_APPR_DT IS NOT NULL AND SFCH_NO = :b2 AND NOT EXISTS (SELECT 'X' FROM OM_STUDENT_HEAD WHERE STUD_SRN = SFCH_STUD_SRN_TEMP_NO AND NVL(STUD_CLO_STATUS,0) != 1 AND
NVL(STUD_REG_STATUS,0) != 23 AND STUD_COURSE_CODE != 'CCT' AND CF_COURSE_CODE= STUD_COURSE_CODE ) ORDER BY 1 DESC
Unfortunately, explain plans, even with dbms_xplan.display, may not show the actual execution plan - this is more of a problem when the SQL statement includes bind variables (capturing a 10046 trace at level 8 or 12 will help). With the information provided, it looks like the problem is with the number of logical reads performed: 17,503,305 in 84 executions = 208,373 logical reads per execution. Something is causing the SQL statement to execute inefficiently, possibly a join problem between tables, possibly the forced use of an index.
From one of my previous posts related to this same SQL statement:
SELECT /*+ INDEX (OM_COURSE_FEE OCF_CFC_CODE) */ DISTINCT
CF_COURSE_CODE
FROM
OM_COURSE_FEE,
OT_STUDENT_FEE_COL_HEAD,
OT_STUDENT_FEE_COL_DETL
WHERE
SFCH_SYS_ID = SFCD_SFCH_SYS_ID
AND SFCD_FEE_TYPE_CODE = CF_TYPE_CODE
AND CF_COURSE_CODE IN ( 'PE1','PE2','CCT','CPT' )
AND SFCH_TXN_CODE = :b1
AND SFCD_SUBSCRBE_JOURNAL_YN IN ( 'T','R','1','C' )
AND SFCH_APPR_UID IS NOT NULL
AND SFCH_APPR_DT IS NOT NULL
AND SFCH_NO = :b2
AND NOT EXISTS (
SELECT
'X'
FROM
OM_STUDENT_HEAD
WHERE
STUD_SRN = SFCH_STUD_SRN_TEMP_NO
AND NVL(STUD_CLO_STATUS,0) != 1
AND NVL(STUD_REG_STATUS,0) != 23
AND STUD_COURSE_CODE != 'CCT'
AND CF_COURSE_CODE = STUD_COURSE_CODE)
ORDER BY
1 DESC
| Id | Operation | Name | Rows | Bytes | Cost | Pstart| Pstop |
| 0 | SELECT STATEMENT 1 69 34
| 1 | SORT UNIQUE 1 69 22
| 2 | TABLE ACCESS BY GLOBAL INDEX ROWID | OT_STUDENT_FEE_COL_DETL | 1 | 12 | 2 | ROWID | ROW L |
| 3 | NESTED LOOPS 1 69 9
| 4 | NESTED LOOPS 1 57 7
| 5 | TABLE ACCESS BY GLOBAL INDEX ROWID | OT_STUDENT_FEE_COL_HEAD | 1 | 48 | 5 | ROWID | ROW L |
| 6 | INDEX SKIP SCAN OT_STUDENT_FEE_COL_HEAD_UK0| 1 | 1 | 4 |
| 7 | INLIST ITERATOR |
| 8 | TABLE ACCESS BY INDEX ROWID | OM_COURSE_FEE | 1 | 9 | 2 | | |
| 9 | INDEX RANGE SCAN | OCF_CFC_CODE | 1 | | 1 | | |
| 10 | FILTER
| 11 | TABLE ACCESS BY GLOBAL INDEX ROWID| OM_STUDENT_HEAD | 1 | 21 | 4 | ROWID | ROW L |
| 12 | INDEX RANGE SCAN | IDM_STUD_SRN_COURSE | 1 | | 3 | | |
| 13 | INDEX RANGE SCAN | IDM_SFCD_FEE_TYPE_CODE | 34600 | | 1 | | |It appears, based just on the SQL statement, that there is no direct relationship between OM_COURSE_FEE and OT_STUDENT_FEE_COL_HEAD, yet the plan above indicates that the two tables are being joined together, likely as a result of the index hint. There is the possibility of additional predicates being generated by Oracle which will make this possible without introducing a Cartesian join, but those predicates are not displayed with an explain plan (they will appear with a DBMS_XPLAN). I may not be remembering correctly, but if the optimizer goal is set to first rows, a Cartesian join might appear in a plan as a nested loops join - Jonathan will know for certain if that is the case.
Have you investigated the above as a possible cause? If you know that there is a problem with this one SQL statement, a 10046 trace at level 8 or 12 is much more helpful than a Statspack report.
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc. -
Hello all i hav a query which is taking result from 4 tables
select name, date, emp_id, salary from table1, table2, table3,table4 where date= :date and other conditions
but when im doing same query and changin date format
select name, date, emp_id, salary from table1, table2, table3,table4 where date= TO_DATE(:date,'DD/MM/RRRR') and other conditions
the query is gettin hang no response
please advice.
ThanksExecution Plan
Plan hash value: 2265139331
Id Operation Name Rows Bytes Cost (%CPU) Time
0 SELECT STATEMENT 14647 3146K 1443 (1) 00:00:18
1 HASH GROUP BY 14647 3146K
2 CONCATENATION
3 MERGE JOIN CARTESIAN 8444 1814K 738 (1) 00:00:09
4 NESTED LOOPS
5 NESTED LOOPS 1 202 635 (1) 00:00:08
6 NESTED LOOPS 1 138 633 (1) 00:00:08
7 NESTED LOOPS 1 103 632 (1) 00:00:08
8 NESTED LOOPS 1 85 631 (1) 00:00:08
9 VIEW table 3 84 628 (1) 00:00:08
10 UNION-ALL
* 11 HASH JOIN 1 37 279 (1) 00:00:04
* 12 TABLE ACCESS BY INDEX ROWID table 1 31 4 (0) 00:00:01
* 13 INDEX RANGE SCAN table 1 3 (0) 00:00:01
14 TABLE ACCESS FULL table 9472 56832 275 (1) 00:00:04
* 15 HASH JOIN 1 37 319 (1) 00:00:04
* 16 TABLE ACCESS BY INDEX ROWID table 1 31 10 (0) 00:00:01
* 17 INDEX RANGE SCAN table 1 9 (0) 00:00:01
18 TABLE ACCESS FULL table 36233 212K 308 (1) 00:00:04
* 19 HASH JOIN 1 43 31 (4) 00:00:01
* 20 TABLE ACCESS BY INDEX ROWID table 1 37 3 (0) 00:00:01
* 21 INDEX RANGE SCAN table 1 2 (0) 00:00:01
22 TABLE ACCESS FULL table 2546 15276 27 (0) 00:00:01
23 TABLE ACCESS BY INDEX ROWID table 1 57 1 (0) 00:00:01
* 24 INDEX UNIQUE SCAN table 1 0 (0) 00:00:01
25 TABLE ACCESS BY INDEX ROWID table 1 18 1 (0) 00:00:01
* 26 INDEX UNIQUE SCAN table 1 0 (0) 00:00:01
27 TABLE ACCESS BY INDEX ROWID table 1 35 1 (0) 00:00:01
* 28 INDEX UNIQUE SCAN table 1 0 (0) 00:00:01
* 29 INDEX RANGE SCAN table 2 1 (0) 00:00:01
30 TABLE ACCESS BY INDEX ROWID table 2 128 2 (0) 00:00:01
31 BUFFER SORT 7977 140K 736 (1) 00:00:09
32 TABLE ACCESS FULL table 7977 140K 102 (0) 00:00:02
33 NESTED LOOPS 310 68200 704 (1) 00:00:09
34 NESTED LOOPS 1 202 635 (1) 00:00:08
35 NESTED LOOPS 1 138 633 (1) 00:00:08
36 NESTED LOOPS 1 103 632 (1) 00:00:08
37 NESTED LOOPS 1 85 631 (1) 00:00:08
38 VIEW table 3 84 628 (1) 00:00:08
39 UNION-ALL
* 40 HASH JOIN 1 37 279 (1) 00:00:04
* 41 TABLE ACCESS BY INDEX ROWID table 1 31 4 (0) 00:00:01 * 41 TABLE ACCESS BY INDEX ROWID table131 4 (0) 00:00:01
* 42 INDEX RANGE SCAN table 1 3 (0) 00:00:01
43 TABLE ACCESS FULL table 9472 56832 275 (1) 00:00:04
* 44 HASH JOIN 1 37 319 (1) 00:00:04
* 45 TABLE ACCESS BY INDEX ROWID table 1 31 10 (0) 00:00:01
* 46 INDEX RANGE SCAN table 1 9 (0) 00:00:01
47 TABLE ACCESS FULL table 36233 212K 308 (1) 00:00:04
* 48 HASH JOIN 1 43 31 (4) 00:00:01
* 49 TABLE ACCESS BY INDEX ROWID table 1 37 3 (0) 00:00:01
* 50 INDEX RANGE SCAN table 1 2 (0) 00:00:01
51 TABLE ACCESS FULL table 2546 15276 27 (0) 00:00:01
52 TABLE ACCESS BY INDEX ROWID table 1 57 1 (0) 00:00:01
* 53 INDEX UNIQUE SCAN table 1 0 (0) 00:00:01
54 TABLE ACCESS BY INDEX ROWID table 1 18 1 (0) 00:00:01
* 55 INDEX UNIQUE SCAN table 1 0 (0) 00:00:01
56 TABLE ACCESS BY INDEX ROWID table 1 35 1 (0) 00:00:01
* 57 INDEX UNIQUE SCAN table 1 0 (0) 00:00:01
58 TABLE ACCESS BY INDEX ROWID table 2 128 2 (0) 00:00:01
* 59 INDEX RANGE SCAN table 2 1 (0) 00:00:01
* 60 TABLE ACCESS FULL table 293 5274 68 (0) 00:00:01
Predicate Information (identified by operation id):
3 - access("a.id"="b.id")
12 - access("a.id"="b.id")
13 - filter("a.id"="b.id")
14 - access("a.id"="b.id")
16 - access("a.id"="b.id")
17 - filter("a.id"="b.id")
18 - access("a.id"="b.id")
20 - access("a.id"="b.id")
21 - filter("a.id"="b.id")
22 - access("a.id"="b.id")
25 - access("a.id"="b.id")AND ("a.id"="b.id")
27 - access("a.id"="b.id")
28 - access("a.id"="b.id")
32 - access("a.id"="b.id")
36 - access("a.id"="b.id")AND ("a.id"="b.id")
37 - filter("a.id"="b.id")
40 - access("a.id"="b.id")
41 - filter("a.id"="b.id")
42 - access("a.id"="b.id")
44 - access("a.id"="b.id")
45 - filter("a.id"="b.id")
46 - access("a.id"="b.id")
48 - access("a.id"="b.id")
49 - filter("a.id"="b.id")
50 - access("a.id"="b.id")
Statistics
71 recursive calls
0 db block gets
2975 consistent gets
0 physical reads
0 redo size
2172 bytes sent via SQL*Net to client
520 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
1 rows processed -
Urgent: Query taking a long time
Hi, I have this query which is taking about 1 hour to complete. It is suppose to complete in less than 2 min. Please help to tune it. I have given the details below.
SQL> SELECT co_trans_master.co_trans_no, co_charge.co_no,
2 co_charge.charge_no,
3 co_charge.created_date created_date,
4 NVL (co_ch_amt_variation.ch_amt_owing_ind,
5 co_charge_amount.ch_amt_owing_ind
6 ) ch_amt_owing_ind,
7 NVL (co_ch_amt_variation.ch_secured_amt,
8 co_charge_amount.ch_secured_amt
9 ) ch_secured_amt,
10 NVL (co_ch_det_variation.ch_chargee_name,
11 NVL (co_chargee_detail.ch_chargee_name, '-')
12 ) ch_chargee_name,
13 NVL (co_ch_det_variation.ch_chargee_id,
14 co_chargee_detail.ch_chargee_id
15 ) ch_chargee_id,
16 NVL (m_currency_variation.currency_desc,
17 m_currency.currency_desc
18 ) currency_desc,
19 NULL satisfaction_type
20 FROM co_charge co_charge,
21 co_trans_master,
22 co_charge_amount co_charge_amount,
23 co_chargee_detail co_chargee_detail,
24 m_currency,
25 co_charge_variation ch_variation,
26 co_charge_amount co_ch_amt_variation,
27 co_chargee_detail co_ch_det_variation,
28 m_currency m_currency_variation
29 WHERE co_charge.co_trans_no(+) = co_trans_master.co_trans_no
30 AND co_charge.co_trans_no = co_charge_amount.co_trans_no(+)
31 AND co_charge.co_trans_no = co_chargee_detail.co_trans_no(+)
32 AND co_charge_amount.ch_currency_code = m_currency.currency_code(+)
33 AND co_charge.charge_no = ch_variation.charge_no(+)
34 AND ch_variation.co_trans_no = co_ch_amt_variation.co_trans_no(+)
35 AND ch_variation.co_trans_no = co_ch_det_variation.co_trans_no(+)
36 AND co_ch_amt_variation.ch_currency_code = m_currency_variation.currency_code(+)
37 AND NVL (co_trans_master.void_ind, 'N') = 'N'
38 AND NVL (co_trans_master.expunged_ind, 'N') = 'N'
39 AND NVL (co_charge.approved_ind, 'Y') = 'Y'
40 AND NVL (co_charge.void_ind, 'N') = 'N'
41 AND NVL (co_trans_master.status_ind, '1') <> '2'
42 AND NOT EXISTS (
43 SELECT 'x'
44 FROM co_charge_satisfaction a, co_chargee_endorse b
45 WHERE b.co_trans_no = a.co_trans_no
46 AND b.ch_endorse_date IS NULL
47 AND a.receipt_no IS NULL
48 AND a.charge_no = co_charge.charge_no)
49 ORDER BY 3, 7;
6268140 rows selected.
Elapsed: 00:02:01.28
Execution Plan
Plan hash value: 596548904
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 158K| 38M| | 82555 (1)| 00:16:31 |
| 1 | SORT ORDER BY | | 158K| 38M| 41M| 82555 (1)| 00:16:31 |
|* 2 | HASH JOIN RIGHT OUTER | | 158K| 38M| | 73751 (1)| 00:14:46 |
| 3 | INDEX FULL SCAN | PK_M_CURRENCY | 170 | 3910 | | 1 (0)| 00:00:01 |
|* 4 | HASH JOIN RIGHT OUTER | | 158K| 35M| | 73749 (1)| 00:14:45 |
| 5 | INDEX FULL SCAN | PK_M_CURRENCY | 170 | 3910 | | 1 (0)| 00:00:01 |
|* 6 | HASH JOIN RIGHT OUTER | | 158K| 31M| 3368K| 73746 (1)| 00:14:45 |
| 7 | TABLE ACCESS FULL | CO_CHARGE_AMOUNT | 127K| 1867K| | 208 (1)| 00:00:03 |
|* 8 | HASH JOIN RIGHT OUTER | | 124K| 23M| 2944K| 72146 (1)| 00:14:26 |
| 9 | TABLE ACCESS FULL | CO_CHARGEE_DETAIL | 47048 | 2389K| | 223 (1)| 00:00:03 |
|* 10 | HASH JOIN RIGHT OUTER | | 124K| 17M| | 70859 (1)| 00:14:11 |
| 11 | VIEW | index$_join$_006 | 120 | 2280 | | 3 (34)| 00:00:01 |
|* 12 | HASH JOIN | | | | | | |
| 13 | INDEX FAST FULL SCAN | IDX_CO_CH_VARIATION_CHARGENO | 120 | 2280 | | 1 (0)| 00:00:01 |
| 14 | INDEX FAST FULL SCAN | SYS_C0099185 | 120 | 2280 | | 1 (0)| 00:00:01 |
|* 15 | HASH JOIN RIGHT ANTI | | 62457 | 7624K| | 70855 (1)| 00:14:11 |
| 16 | VIEW | VW_SQ_1 | 116 | 928 | | 119 (0)| 00:00:02 |
| 17 | NESTED LOOPS | | | | | | |
| 18 | NESTED LOOPS | | 116 | 3828 | | 119 (0)| 00:00:02 |
|* 19 | TABLE ACCESS FULL | CO_CHARGEE_ENDORSE | 116 | 1392 | | 3 (0)| 00:00:01 |
|* 20 | INDEX UNIQUE SCAN | SYS_C0099142 | 1 | | | 0 (0)| 00:00:01 |
|* 21 | TABLE ACCESS BY INDEX ROWID| CO_CHARGE_SATISFACTION | 1 | 21 | | 1 (0)| 00:00:01 |
|* 22 | HASH JOIN RIGHT OUTER | | 6245K| 696M| 2944K| 70704 (1)| 00:14:09 |
| 23 | TABLE ACCESS FULL | CO_CHARGEE_DETAIL | 47048 | 2389K| | 223 (1)| 00:00:03 |
|* 24 | HASH JOIN RIGHT OUTER | | 6245K| 387M| 3368K| 47539 (1)| 00:09:31 |
| 25 | TABLE ACCESS FULL | CO_CHARGE_AMOUNT | 127K| 1867K| | 208 (1)| 00:00:03 |
|* 26 | FILTER | | | | | | |
|* 27 | HASH JOIN RIGHT OUTER | | 6245K| 297M| 7592K| 28796 (2)| 00:05:46 |
| 28 | TABLE ACCESS FULL | CO_CHARGE | 158K| 5727K| | 932 (2)| 00:00:12 |
|* 29 | TABLE ACCESS FULL | CO_TRANS_MASTER | 6245K| 77M| | 20050 (2)| 00:04:01 |
Predicate Information (identified by operation id):
2 - access("CO_CH_AMT_VARIATION"."CH_CURRENCY_CODE"="M_CURRENCY_VARIATION"."CURRENCY_CODE"(+))
4 - access("CO_CHARGE_AMOUNT"."CH_CURRENCY_CODE"="M_CURRENCY"."CURRENCY_CODE"(+))
6 - access("CH_VARIATION"."CO_TRANS_NO"="CO_CH_AMT_VARIATION"."CO_TRANS_NO"(+))
8 - access("CH_VARIATION"."CO_TRANS_NO"="CO_CH_DET_VARIATION"."CO_TRANS_NO"(+))
10 - access("CO_CHARGE"."CHARGE_NO"="CH_VARIATION"."CHARGE_NO"(+))
12 - access(ROWID=ROWID)
15 - access("ITEM_1"="CO_CHARGE"."CHARGE_NO")
19 - filter("B"."CH_ENDORSE_DATE" IS NULL)
20 - access("B"."CO_TRANS_NO"="A"."CO_TRANS_NO")
21 - filter("A"."RECEIPT_NO" IS NULL)
22 - access("CO_CHARGE"."CO_TRANS_NO"="CO_CHARGEE_DETAIL"."CO_TRANS_NO"(+))
24 - access("CO_CHARGE"."CO_TRANS_NO"="CO_CHARGE_AMOUNT"."CO_TRANS_NO"(+))
26 - filter(NVL("CO_CHARGE"."APPROVED_IND",'Y')='Y' AND NVL("CO_CHARGE"."VOID_IND",'N')='N')
27 - access("CO_CHARGE"."CO_TRANS_NO"(+)="CO_TRANS_MASTER"."CO_TRANS_NO")
29 - filter(NVL("CO_TRANS_MASTER"."VOID_IND",'N')='N' AND NVL("CO_TRANS_MASTER"."STATUS_IND",'1')<>'2' AND
NVL("CO_TRANS_MASTER"."EXPUNGED_IND",'N')='N')
Statistics
225 recursive calls
9 db block gets
78959 consistent gets
101976 physical reads
0 redo size
121969396 bytes sent via SQL*Net to client
690014 bytes received via SQL*Net from client
62683 SQL*Net roundtrips to/from client
0 sorts (memory)
1 sorts (disk)
6268140 rows processedStatistics
225 recursive calls
9 db block gets
78959 consistent gets
101976 physical reads
0 redo size
121969396 bytes sent via SQL*Net to client
690014 bytes received via SQL*Net from client
62683 SQL*Net roundtrips to/from client
0 sorts (memory)
1 sorts (disk)
6268140 rows processedWith 101976 physical reads you get 6268140 rows with 121969396 bytes and send them over SQL*Net to your client application. That's interesting.
Hi, I have this query which is taking about 1 hour to complete. It is suppose to complete in less than 2 minThere is NO system outside of museums that takes 1 hours to do 101976 physical reads.
What is your client? I'd say the DB executes ok but it takes time to transfer the 116MB in 62683 SQL*Net round trips => 20 roundtrips per sec are reasonable.
Try something like
SELECT COUNT(*) FROM (your query);
or
CREATE TABLE mytest AS SELECT * FROM (your query);your will finish in seconds. And that will prove the speed of the DB / query
-- andy -
Query taking so much time..
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. -
DB 11.2.0.3.4
Server HP-UX IA 11.31
One big query is taking very long time. I am giving the explain plan along with stats from tkprof. If needed will give the query also. Can sombody tell me how can we improve this.
call count cpu elapsed disk query current rows
Parse 1 23.26 23.90 0 20 0 0
Execute 1 8055.11 9453.52 684215 348696 18750740 1306001
Fetch 0 0.00 0.00 0 0 0 0
total 2 8078.37 9477.42 684215 348716 18750740 1306001
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 322 (EDW_DM) (recursive depth: 1)
Rows Row Source Operation
0 LOAD TABLE CONVENTIONAL (cr=352254 pr=684215 pw=682074 time=863655932 us)
1306001 PX COORDINATOR (cr=15823 pr=682074 pw=682074 time=499947892 us)
0 PX SEND QC (RANDOM) :TQ20004 (cr=0 pr=0 pw=0 time=0 us cost=276195 size=126736955032 card=9998182)
0 BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
0 VIEW VW_FCT_PLN_SUMM_ADL_WK_XARH317 (cr=0 pr=0 pw=0 time=0 us cost=276195 size=126736955032 card=9998182)
0 UNION-ALL (cr=0 pr=0 pw=0 time=0 us)
0 SORT GROUP BY (cr=0 pr=0 pw=0 time=0 us cost=9167 size=95469948 card=378849)
0 PX RECEIVE (cr=0 pr=0 pw=0 time=0 us cost=9167 size=95469948 card=378849)
0 PX SEND HASH :TQ20003 (cr=0 pr=0 pw=0 time=0 us cost=9167 size=95469948 card=378849)
0 SORT GROUP BY (cr=0 pr=0 pw=0 time=0 us cost=9167 size=95469948 card=378849)
0 HASH JOIN RIGHT SEMI (cr=0 pr=0 pw=0 time=0 us cost=2714 size=95469948 card=378849)
0 BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
0 PX RECEIVE (cr=0 pr=0 pw=0 time=0 us cost=26 size=16428 card=4107)
0 PX SEND BROADCAST :TQ20000 (cr=0 pr=0 pw=0 time=0 us cost=26 size=16428 card=4107)
4857 VIEW VW_SQ_1 (cr=47 pr=0 pw=0 time=25403 us cost=26 size=16428 card=4107)
4857 HASH JOIN (cr=47 pr=0 pw=0 time=23353 us cost=26 size=229992 card=4107)
1115 TABLE ACCESS FULL DMN_PROD (cr=11 pr=0 pw=0 time=863 us cost=6 size=13380 card=1115)
4873 HASH JOIN (cr=36 pr=0 pw=0 time=12991 us cost=20 size=180840 card=4110)
55 TABLE ACCESS FULL DMN_MKT_DEFN (cr=3 pr=0 pw=0 time=286 us cost=4 size=1980 card=55)
18235 TABLE ACCESS FULL FCT_MKT_PROD_BRDG (cr=33 pr=0 pw=0 time=13550 us cost=15 size=145880 card=18235)
0 HASH JOIN (cr=0 pr=0 pw=0 time=0 us cost=2686 size=93954552 card=378849)
0 BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
0 PX RECEIVE (cr=0 pr=0 pw=0 time=0 us cost=111 size=403328 card=8768)
0 PX SEND BROADCAST :TQ20001 (cr=0 pr=0 pw=0 time=0 us cost=111 size=403328 card=8768)
8768 NESTED LOOPS (cr=274 pr=0 pw=0 time=15077 us cost=111 size=403328 card=8768)
1 NESTED LOOPS (cr=5 pr=0 pw=0 time=203 us cost=5 size=28 card=1)
1 TABLE ACCESS FULL DMN_WK_END (cr=2 pr=0 pw=0 time=81 us cost=3 size=8 card=1)
1 TABLE ACCESS BY INDEX ROWID DMN_CALN (cr=3 pr=0 pw=0 time=110 us cost=2 size=20 card=1)
1 INDEX RANGE SCAN XNU1_DMN_CALN (cr=2 pr=0 pw=0 time=73 us cost=1 size=0 card=1)(object id 303867)
8768 TABLE ACCESS FULL DMN_CALN (cr=269 pr=0 pw=0 time=11719 us cost=106 size=157824 card=8768)
0 PX BLOCK ITERATOR PARTITION: KEY KEY (cr=0 pr=0 pw=0 time=0 us cost=2573 size=76527498 card=378849)
0 TABLE ACCESS FULL FCT_NONRET_SLS_CURR_TRANS_WKLY PARTITION: 32 32 (cr=0 pr=0 pw=0 time=0 us cost=2573 size=76527498 card=378849)
0 BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
0 PX RECEIVE (cr=0 pr=0 pw=0 time=0 us cost=267028 size=2741509905 card=9619333)
0 PX SEND ROUND-ROBIN :TQ20002 (cr=0 pr=0 pw=0 time=0 us cost=267028 size=2741509905 card=9619333)
1284599 SORT GROUP BY (cr=15497 pr=682074 pw=682074 time=3839060439 us cost=267028 size=2741509905 card=9619333)
6439189 FILTER (cr=15486 pr=0 pw=0 time=57890179 us)
8986531 PX COORDINATOR (cr=279 pr=0 pw=0 time=52453034 us)
0 PX SEND QC (RANDOM) :TQ10001 (cr=0 pr=0 pw=0 time=0 us cost=80940 size=2741509905 card=9619333)
0 HASH JOIN (cr=0 pr=0 pw=0 time=0 us cost=80940 size=2741509905 card=9619333)
0 BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
0 PX RECEIVE (cr=0 pr=0 pw=0 time=0 us cost=111 size=403328 card=8768)
0 PX SEND BROADCAST :TQ10000 (cr=0 pr=0 pw=0 time=0 us cost=111 size=403328 card=8768)
8768 NESTED LOOPS (cr=274 pr=0 pw=0 time=14462 us cost=111 size=403328 card=8768)
1 NESTED LOOPS (cr=5 pr=0 pw=0 time=345 us cost=5 size=28 card=1)
1 TABLE ACCESS FULL DMN_WK_END (cr=2 pr=0 pw=0 time=193 us cost=3 size=8 card=1)
1 TABLE ACCESS BY INDEX ROWID DMN_CALN (cr=3 pr=0 pw=0 time=136 us cost=2 size=20 card=1)
1 INDEX RANGE SCAN XNU1_DMN_CALN (cr=2 pr=0 pw=0 time=76 us cost=1 size=0 card=1)(object id 303867)
8768 TABLE ACCESS FULL DMN_CALN (cr=269 pr=0 pw=0 time=9447 us cost=106 size=157824 card=8768)
0 PX BLOCK ITERATOR PARTITION: KEY KEY (cr=0 pr=0 pw=0 time=0 us cost=80801 size=2299020587 card=9619333)
0 TABLE ACCESS FULL FCT_PLN_RET_SLS_CURR_WKLY PARTITION: 30 30 (cr=0 pr=0 pw=0 time=0 us cost=80801 size=2299020587 card=9619333)
834 NESTED LOOPS (cr=15207 pr=0 pw=0 time=990747 us)
2269 NESTED LOOPS (cr=12938 pr=0 pw=0 time=1090852 us cost=17 size=56 card=1)
2269 NESTED LOOPS (cr=12101 pr=0 pw=0 time=1065238 us cost=16 size=20 card=1)
834 TABLE ACCESS BY INDEX ROWID DMN_PROD (cr=1676 pr=0 pw=0 time=37175 us cost=1 size=12 card=1)
838 INDEX UNIQUE SCAN XPKDIMENSION_PRODUCT (cr=838 pr=0 pw=0 time=23645 us cost=0 size=0 card=1)(object id 303870)
2269 TABLE ACCESS FULL FCT_MKT_PROD_BRDG (cr=10425 pr=0 pw=0 time=1024973 us cost=15 size=8 card=1)
2269 INDEX UNIQUE SCAN SYS_C0040182 (cr=837 pr=0 pw=0 time=15842 us cost=0 size=0 card=1)(object id 301873)
834 TABLE ACCESS BY INDEX ROWID DMN_MKT_DEFN (cr=2269 pr=0 pw=0 time=16488 us cost=1 size=36 card=1)
It would be appreciated if somebody check this.
Regards,
VirendraBelow is with the index on one of the table:
call count cpu elapsed disk query current rows
Parse 1 49.33 49.61 0 16 0 0
Execute 1 8374.08 10745.82 953712 473861 18818854 1306001
Fetch 0 0.00 0.00 0 0 0 0
total 2 8423.41 10795.43 953712 473877 18818854 1306001
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 322 (recursive depth: 1)
Rows Row Source Operation
0 LOAD TABLE CONVENTIONAL (cr=481416 pr=953712 pw=917687 time=2156047932 us)
1306001 PX COORDINATOR (cr=131828 pr=917687 pw=917687 time=1528317728 us)
0 PX SEND QC (RANDOM) :TQ10004 (cr=0 pr=0 pw=0 time=0 us cost=144212 size=16362383616 card=1290816)
0 BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
0 VIEW VW_FCT_PLN_SUM_ADL_WK_XRH317_1 (cr=0 pr=0 pw=0 time=0 us cost=144212 size=16362383616 card=1290816)
0 UNION-ALL (cr=0 pr=0 pw=0 time=0 us)
0 SORT GROUP BY (cr=0 pr=0 pw=0 time=0 us cost=9568 size=101394468 card=402359)
0 PX RECEIVE (cr=0 pr=0 pw=0 time=0 us cost=9568 size=101394468 card=402359)
0 PX SEND HASH :TQ10003 (cr=0 pr=0 pw=0 time=0 us cost=9568 size=101394468 card=402359)
0 SORT GROUP BY (cr=0 pr=0 pw=0 time=0 us cost=9568 size=101394468 card=402359)
0 HASH JOIN RIGHT SEMI (cr=0 pr=0 pw=0 time=0 us cost=2714 size=101394468 card=402359)
0 BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
0 PX RECEIVE (cr=0 pr=0 pw=0 time=0 us cost=26 size=16428 card=4107)
0 PX SEND BROADCAST :TQ10000 (cr=0 pr=0 pw=0 time=0 us cost=26 size=16428 card=4107)
4857 VIEW VW_SQ_1 (cr=47 pr=0 pw=0 time=25732 us cost=26 size=16428 card=4107)
4857 HASH JOIN (cr=47 pr=0 pw=0 time=23041 us cost=26 size=229992 card=4107)
1115 TABLE ACCESS FULL DMN_PROD (cr=11 pr=0 pw=0 time=1040 us cost=6 size=13380 card=1115)
4873 HASH JOIN (cr=36 pr=0 pw=0 time=12797 us cost=20 size=180840 card=4110)
55 TABLE ACCESS FULL DMN_MKT_DEFN (cr=3 pr=0 pw=0 time=185 us cost=4 size=1980 card=55)
18235 TABLE ACCESS FULL FCT_MKT_PROD_BRDG (cr=33 pr=0 pw=0 time=10014 us cost=15 size=145880 card=18235)
0 HASH JOIN (cr=0 pr=0 pw=0 time=0 us cost=2686 size=99785032 card=402359)
0 BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
0 PX RECEIVE (cr=0 pr=0 pw=0 time=0 us cost=111 size=403328 card=8768)
0 PX SEND BROADCAST :TQ10001 (cr=0 pr=0 pw=0 time=0 us cost=111 size=403328 card=8768)
8768 NESTED LOOPS (cr=274 pr=0 pw=0 time=13429 us cost=111 size=403328 card=8768)
1 NESTED LOOPS (cr=5 pr=0 pw=0 time=206 us cost=5 size=28 card=1)
1 TABLE ACCESS FULL DMN_WK_END (cr=2 pr=0 pw=0 time=82 us cost=3 size=8 card=1)
1 TABLE ACCESS BY INDEX ROWID DMN_CALN (cr=3 pr=0 pw=0 time=111 us cost=2 size=20 card=1)
1 INDEX RANGE SCAN XNU1_DMN_CALN (cr=2 pr=0 pw=0 time=80 us cost=1 size=0 card=1)(object id 303867)
8768 TABLE ACCESS FULL DMN_CALN (cr=269 pr=0 pw=0 time=9306 us cost=106 size=157824 card=8768)
0 PX BLOCK ITERATOR PARTITION: KEY KEY (cr=0 pr=0 pw=0 time=0 us cost=2573 size=81276518 card=402359)
0 TABLE ACCESS FULL FCT_NONRET_SLS_CURR_TRANS_WKLY PARTITION: 32 32 (cr=0 pr=0 pw=0 time=0 us cost=2573 size=81276518 card=402359)
0 BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
0 PX RECEIVE (cr=0 pr=0 pw=0 time=0 us cost=134645 size=256764073 card=888457)
0 PX SEND ROUND-ROBIN :TQ10002 (cr=0 pr=0 pw=0 time=0 us cost=134645 size=256764073 card=888457)
1284599 HASH GROUP BY (cr=131502 pr=917687 pw=917687 time=1052831032 us cost=134645 size=256764073 card=888457)
6439189 HASH JOIN RIGHT SEMI (cr=131490 pr=138092 pw=138092 time=374140098 us cost=100193 size=256764073 card=888457)
4857 VIEW VW_SQ_2 (cr=47 pr=0 pw=0 time=22869 us cost=26 size=16428 card=4107)
4857 HASH JOIN (cr=47 pr=0 pw=0 time=21073 us cost=26 size=229992 card=4107)
1115 TABLE ACCESS FULL DMN_PROD (cr=11 pr=0 pw=0 time=687 us cost=6 size=13380 card=1115)
4873 HASH JOIN (cr=36 pr=0 pw=0 time=12522 us cost=20 size=180840 card=4110)
55 TABLE ACCESS FULL DMN_MKT_DEFN (cr=3 pr=0 pw=0 time=242 us cost=4 size=1980 card=55)
18235 TABLE ACCESS FULL FCT_MKT_PROD_BRDG (cr=33 pr=0 pw=0 time=9883 us cost=15 size=145880 card=18235)
8986531 HASH JOIN (cr=131443 pr=138092 pw=138092 time=402921160 us cost=100161 size=253210245 card=888457)
8768 TABLE ACCESS FULL DMN_CALN (cr=269 pr=0 pw=0 time=11228 us cost=106 size=157824 card=8768)
8986531 MERGE JOIN CARTESIAN (cr=131174 pr=138092 pw=138092 time=382931385 us cost=100049 size=237218019 card=888457)
1 NESTED LOOPS (cr=5 pr=0 pw=0 time=251 us)
1 NESTED LOOPS (cr=4 pr=0 pw=0 time=225 us cost=5 size=28 card=1)
1 TABLE ACCESS FULL DMN_WK_END (cr=2 pr=0 pw=0 time=127 us cost=3 size=8 card=1)
1 INDEX RANGE SCAN XNU1_DMN_CALN (cr=2 pr=0 pw=0 time=88 us cost=1 size=0 card=1)(object id 303867)
1 TABLE ACCESS BY INDEX ROWID DMN_CALN (cr=1 pr=0 pw=0 time=17 us cost=2 size=20 card=1)
8986531 BUFFER SORT (cr=131169 pr=138092 pw=138092 time=378126634 us cost=100047 size=212341223 card=888457)
8986531 TABLE ACCESS BY GLOBAL INDEX ROWID FCT_PLN_RET_SLS_CURR_WKLY PARTITION: 30 30 (cr=131157 pr=0 pw=0 time=144384133 us cost=100044 size=212341223 card=888457)
9066976 INDEX RANGE SCAN SUBSTR_FCT_RET_SLS_CUR_WLY (cr=84385 pr=0 pw=0 time=93762049 us cost=83615 size=0 card=2856894)(object id 311617)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
os thread startup 2 0.08 0.15
PX Deq: Join ACK 4 0.00 0.00
PX Deq Credit: send blkd 455 2.21 55.10
PX Deq: Parse Reply 4 0.01 0.01
PX Deq: Execute Reply 250046 247.89 439.12
asynch descriptor resize 9 0.00 0.00
PX Deq Credit: need buffer 549 1.54 15.84
PX qref latch 235 0.01 0.18
Disk file operations I/O 42 0.00 0.00
direct path write temp 62665 0.25 365.50
direct path read temp 99442 0.46 1024.89
db file sequential read 36025 0.15 186.86
latch: object queue header operation 17 0.00 0.00
latch free 2 0.00 0.00
log file switch (private strand flush incomplete)
1 0.07 0.07
latch: messages 1 0.00 0.00
log file switch completion 14 0.08 0.79
latch: cache buffers chains 2 0.00 0.00
latch: redo allocation 1 0.00 0.00
PX Deq: Signal ACK RSG 4 0.06 0.07
PX Deq: Signal ACK EXT 4 0.00 0.01
PX Deq: Slave Session Stats 4 0.00 0.00
enq: PS - contention 1 0.00 0.00 -
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. -
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 -
Simple query taking so long time to run
Below are the queries which are taking very long time to run. It pulls 4 million records approx on first query.
How can it run fast?
Thank you.
SELECTPerson_DEID[CP1] ,
Admit_DT,
Discharge_DT, DRG_CD,
cast (LineAllowedAmount
AS money)
as FacAA
into
FOET
FROMdbo.mh_fac_claims_final[CP2]
group
by Person_DEID,
Admit_DT,
Discharge_DT, DRG_CD,
LineAllowedAmount;
go
select
Person_DEID,
Admit_DT, Discharge_DT,
DRG_CD, sum(facAA)
as FacAA_SUM[CP3]
from
dbo.FOET
group
by Person_DEID,
Admit_DT,
Discharge_DT, DRG_CD,
facAA;Below are the queries which are taking very long time to run. It pulls 4 million records approx on first query.
How can it run fast?
Thank you.
SELECTPerson_DEID[CP1] ,
Admit_DT,
Discharge_DT, DRG_CD,
cast (LineAllowedAmount
AS money)
as FacAA
into
FOET
FROMdbo.mh_fac_claims_final[CP2]
group
by Person_DEID,
Admit_DT,
Discharge_DT, DRG_CD,
LineAllowedAmount;
go
select
Person_DEID,
Admit_DT, Discharge_DT,
DRG_CD, sum(facAA)
as FacAA_SUM[CP3]
from
dbo.FOET
group
by Person_DEID,
Admit_DT,
Discharge_DT, DRG_CD,
facAA;
select Person_DEID,Admit_DT,Discharge_DT,DRG_CD, convert(money,sum(LineAllowedAmount)) as FacAA_SUM[CP3]
into FOET
FROM dbo.mh_fac_claims_final[CP2]
group by Person_DEID, Admit_DT, Discharge_DT, DRG_CD
There is no grouping, u are calculating 4m records in second query. Maybe try above instead (already suggested)? Can u check how long above query takes to run?
Maybe you are looking for
-
Calling report from form with lexical parameter
hi DECLARE repid REPORT_OBJECT; v_rep VARCHAR2(1000); rep_status VARCHAR2(20); BEGIN repid := FIND_REPORT_OBJECT( 'REPORT34' ); set_report_object_property(repid,report_other,'p_SEASON_YEAR='||:SALE_ORDER.SEASON_YEAR
-
How to access APEX variables within compiled pl/sql function.
Hi, My initial problem is to create pl/sql code returning column names for my custom calendar report. There are 7 columns for each day of the week and I want it to be on two rows - first the day of the week, such as 'Monday' and below it (with BR tag
-
IDOC-XI-JDBC scenario, jdbc sent too slow
i have a IDOC-XI-JDBC scenario, the problem is that near 5 Lac IDOC is sent to XI, each IDOC is processes by an instance of the scenario, and the sent to the Database is too clow...means 4000 records per hour, can i configure the JDBC receiver adapte
-
HT1212 i forgot my password for my ipod. how do i get into it
i forgot my password how do i get into my ipod
-
HT204088 How can you delete your payment details
Can you delete your payment method?