Manual Tunning of SQL

Question

Hi Forum Friends,
I have a concern about how to do manual Tunning of SQL .
I have a query:
SELECT /*+ FIRST_ROWS (1) */ * FROM "NRIV" WHERE "CLIENT" = :A0 AND "OBJECT" = :A1 AND "SUBOBJECT" = :A2 AND "NRRANGENR" = :A3 AND "TOYEAR" = :A4 FOR UPDATE;
Pls let me know the way .
Regards,
Vishal Raina

Answer 1

974882 wrote:
I have a query:
SELECT /*+ FIRST_ROWS (1) */ * FROM "NRIV" WHERE "CLIENT" = :A0 AND "OBJECT" = :A1 AND "SUBOBJECT" = :A2 AND "NRRANGENR" = :A3 AND "TOYEAR" = :A4 FOR UPDATE;
Start by getting an execution plan for the  query. Evaluate the plan and consider how different plans might affect performance.  Verify that the new plan will be  used always, always test the changes for performance - it is possible that the new plan will not perform as well as the original one.  Testing should be done by both timing the new and old SQL multiple times and examining run statistics, most easily acquired by the AUTOTRACE utility (Oracle Trace does these things too but is a bit more work to set up and use; AUTOTRACE provides run statistics or a single SQL).  Timing SQL is tricky because after the first execution data is cached in memory and subsequent runs will probably be faster because disk access is unnecessary.
Reading execution plans requires attention to detail.  The bytes, cardinality, and cost are all estimates and can be incorrect.  It is possible for a query with a higher cost to run faster and use fewer resources than a lower cost version of the same query - this is why testing is necessary.  No listed operation is always good or bad although some like FULL [table|index] SCAN and MERGE JOIN CARTESIAN should be investigated - both can under some circumstances be used by the optimizer to improve performance under some conditions.
Your query had some points of interest.  I personally have not seen the FIRST_ROWS hint to be effective for tuning since working with Oracle Forms long ago - hints can help, hurt, or not affect performance.  If your query selects less that about 20% of the rows in the table (this depends on your Oracle version) a composite index on all of the columns in the WHERE clause could allow a fast indexed lookup instead of a more expensive full table scan.  The FOR UPDATE clause always adds overhead to SQL by forcing rows to be locked one by one as they are selected instead of when modified by DML - if you need to lock the rows on SELECT to prevent another process from doing so use it but remember that bulk SQL which avoids context switching is usually more efficient than select loops with DML inside.
Good luck!
Good luck!