Ellapsed time too much in tkprof output

Question

Hi All,
I don't know exactly how to interprete Tkprof output file but i have a problem of performance inserting data to my one table, it takes around 1min but before it was 10 secs. i trace the program and analyze the output from tkprof and i get the following portion:
insert /*+ APPEND +*/ into T_NAME(COL1,  COL2, COL3, .....)
values
(:s1 ,:s2 ,:s3 ,:s4 ,:s5 ,:s6 ,:s7 ,:s8 ,:s9 ,:s10 ,:s11 ,:s12 ,:s13 ,:s14 ,
:s15 ,:s16 ,:s17 ,:s18 ,:s19 ,:s20 ,:s21 ,:s22 ,:s23 ,:s24 ,:s25 ,:s26 ,
:s27 ,:s28 ,:s29 ,:s30 ,:s31 ,:s32 ,:s33 ,:s34 ,:s35 ,:s36 ,:s37 ,:s38 ,
:s39 ,:s40 ,:s41 ,:s42 ,:s43 ,:s44 ,:s45 ,:s46 ,:s47 ,:s48 ,:s49 ,:s50 ,
:s51 ,:s52 ,:s53 ,:s54 ,:s55 ,:s56 ,:s57 ,:s58 ,:s59 ,:s60 ,:s61 ,:s62 ,
:s63 ,:s64 ,:s65 ,:s66 ,:s67 ,:s68 )
call count cpu elapsed disk query current rows
Parse 2 0.00 0.00 0 0 0 0
Execute 3 2.94 292.24 12144 1501 57125 4728
Fetch 0 0.00 0.00 0 0 0 0
total 5 2.94 292.24 12144 1501 57125 4728
Misses in library cache during parse: 2
Misses in library cache during execute: 3
Optimizer mode: ALL_ROWS
Parsing user id: 103 (USERNAME)
Rows Execution Plan
0 INSERT STATEMENT MODE: ALL_ROWS
When interpreting this, i got huge value on Ellapsed, disk column during execution:
The command was exectued 3 times and it was taking 292 secs means 97 secs per execution. I thought it was making my insert problem slow.
So if i'm not wrong how to avaoid this insertion problem, how to reduce this time of ellapsed.
What is the problem causing table insertion slow.
Please help because it is affecting our business
Thanks for your help
Raitsarevo

Answer 1

raitsarevo wrote:
Hi,
Gathering statistics will affect performance or not. I mean when i gather statistics of my table now, will this affect operation in this table during execution, the table will be locked or not, indexes will be also or not. Can users work in the table during stat gathering.
Can anybody give me script to gather stats for partitionned table please.
Gathering statistics is a good idea in general but it's very unlikely that will help in your particular case. The data needs to be inserted into the table and indexes need to be maintained, this in independent from any statistics. Still it's a good idea in general to refresh statistics if e.g. bulk inserts increased the size and number of rows significantly.
Have you followed up the advices already given so far regarding further checks and running your statement with tracing enabled at a higher level?
You can enable this using the following instead of using sql_trace = true:
ALTER SESSION SET EVENTS '10046 trace name context forever, level 8';and switch it off like that:
ALTER SESSION SET EVENTS '10046 trace name context off';For more information regarding this, e.g. enabling trace in another session, see e.g. here:
http://www.juliandyke.com/Diagnostics/Trace/EnablingTrace.html
raitsarevo wrote:
Hi guys,
Reading an output fromENterprise manager, i found that this insert statement is consuming to much "db file sequential read ". I know that is causing wait event. So my question is how to reduce this consumption.
Thanks
Raitsarevo.That's very likely caused by the required index maintenance and there is not much you can do about it apart from dropping the indexes. As already mentioned by Jonathan you might hits bugs of the ASSM space management, therefore it would also be good to know if the tablespace the object resides in uses ASSM or not (check the columns EXTENT_MANAGEMENT, ALLOCATION_TYPE, SEGMENT_SPACE_MANAGEMENT of DBA_TABLESPACES).
Try to generate the extended trace as advised and post the tkprof output here.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/