Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!
optimize oracle query
Hello,
How can I optimize the query insert into tr1234566_tmp_calc VALUES
(:p1,:p2,:p3,:p4,:p5,:p6,:
16,:p17) :
Recommendation 1: SQL Tuning
Estimated benefit is .28 active sessions, 10.88% of total activity.
--------------------------
insert into tr1234566_tmp_calc VALUES
(:p1,:p2,:p3,:p4,:p5,:p6,:
16,:p17)
Rationale
The SQL spent 98% of its database time on CPU, I/O and Cluster waits.
This part of database time may be improved by the SQL Tuning Advisor.
Rationale
Database time for this SQL was divided as follows: 99% for SQL
execution, 1% for parsing, 0% for PL/SQL execution and 0% for Java
execution.
Rationale
SQL statement with SQL_ID "f79cfu8cpyg1b" was executed 464908 times and
had an average elapsed time of 0.0063 seconds.
Thanks
bibi
How can I optimize the query insert into tr1234566_tmp_calc VALUES
(:p1,:p2,:p3,:p4,:p5,:p6,:
16,:p17) :
Recommendation 1: SQL Tuning
Estimated benefit is .28 active sessions, 10.88% of total activity.
--------------------------
insert into tr1234566_tmp_calc VALUES
(:p1,:p2,:p3,:p4,:p5,:p6,:
16,:p17)
Rationale
The SQL spent 98% of its database time on CPU, I/O and Cluster waits.
This part of database time may be improved by the SQL Tuning Advisor.
Rationale
Database time for this SQL was divided as follows: 99% for SQL
execution, 1% for parsing, 0% for PL/SQL execution and 0% for Java
execution.
Rationale
SQL statement with SQL_ID "f79cfu8cpyg1b" was executed 464908 times and
had an average elapsed time of 0.0063 seconds.
Thanks
bibi
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Are you purely going by recommendations OR you are really experiencing performance issues with these insert statements?
Off the top, inserts are commonly optimized with:
As always, your actual results will vary.
add the hint +APPEND so that writes at made at the high-water mark
parallelize the database writers
disable indexes for the load, and rebuild them after the commit
update the table statistics for the cost-based optimizer
find a compromise on how oftern you need to commit vs load on your redo log buffers
with a half-million rows, you are presumably scheduling this to a minimal-impact window (after hours)
As always, your actual results will vary.
Usually, inserts like this don't need any special tuning. But, what is the time period for these half a million rows to be inserted? What else is going on in the database at the time? Can you combine these inserts to be multiple row inserts? If yes, it may make sense to try the "append" hint. But, there are some disadvantages to this approach.
I suggest just don't follow recommendation unless you experience performance issue. As suggested by other experts, Inserts do not need special tuning unless millions of records are being inserted.
I take this from you original post:
What do you expect to improve?
This is a bound statement and the plan is being repeatedly reused. I don't see any problem with the statement at all. It is showing up on a report because it exceeds a threshold, but the reason that it exceeds a threshold is that it has been run so many times.
had an average elapsed time of 0.0063 seconds.
What do you expect to improve?
This is a bound statement and the plan is being repeatedly reused. I don't see any problem with the statement at all. It is showing up on a report because it exceeds a threshold, but the reason that it exceeds a threshold is that it has been run so many times.
Premium Content
You need an Expert Office subscription to comment.Start Free Trial