Practice Manual: How to optimize SQL statement of using DBLINK on Oracle

Transcription

1 Practice Manual: How to optimize SQL statement of using DBLINK on Oracle Usually, a good approach of optimizing SQL statement using DBLINK is that you could try your best to reduce data returned calling remote table that is an inline view. furthermore it also reduces the data via network transmission. At the same time, it even hasn t consumed the resource (more network waiting-events) from data transmission, this waiting-event is named to SQL*Net message from DBLINK on Oracle. This practice manual introduces some experience and approach of SQL optimizing from 6 numbers of ways. The entire optimizing processes and steps as follows: (1) Finding problem (2) Problem analysis -1 (3) Describing the structure of entire SQL statement (4) Checking data size of in-line view r from remote db (5) Problem analysis -2 (6) Conclusion Next we do some practice in order, 1. Firstly, I ve discovered a SQL statement which is executing long time on my EMCC monitor platform, and its SQL_ID is 83gn36c1fu9dw, 2. Problem analysis -1 (1) According to the value of SQL_ID, I ve captured its sql_fulltext is as follows,

2 select sql_fulltext from v$sql where sql_id = 83gn36c1fu9dw ; (2) From snapshot above, you can find a bind variable :1 on that SQL statement. Next I use dynamic performance view of v$sql_bind_capture (or view dba_hist_sqlbind ) to check what the value of :1 is, see my snapshot as follows, set linesize 400 set pagesize 400 col sql_id for a15 col name for a5 col value_string for a40 select sql_id, name, value_string from v$sql_bind_capture where sql_id = 83gn36c1fu9dw ;

3 (3) And then, I ve replaced :1 on original SQL using ff c605e20141c9691f5a000c which I have discovered from the snapshot above, and used SQL*Plus to execute it. After waiting for five minutes and twenty-six seconds, it has returned to query result. Obviously, it s not weird that such a SQL statement has spent long time to execute on the situation of high concurrency and executing process kept on going. My test process is as follows, set linesize 400 set pagesize 400 set timing on

4

5 3. Describing the structure of entire SQL statement It is a ROWNUM operation in the outermost select, that s to say, querying out inner resultset and return to top five rows; The second inner select near to outermost could be eliminated (It s feasible because I have tested for it); The third inner select is in-line view of naming r (querying remote table sd_res_id_case and returning to resultset) and local table t is doing operation of left-join; Via three points previous, this SQL return to entire query result finally. By the way, there has a subquery that is located underneath and rowid in in the in-line view r. Afterwards, I ve generated the execution plan with row source that is as follows, select * from table(dbms_xplan.display_cursor(null, NULL, ALLSTATS ALL ));

6 We observe the third step named NESTED LOOPS that line of Id is 3, you ve found that Starts * E-Rows is equal to 1 * 2 = 2, and A-Rows is 926K. It s a common principle that the value of Starts * E-Rows and A-Rows is almost equal or not more different. Next, we look at the eighth step named REMOTE that line of Id is 8, you ve found Starts * E-Rows is equal to 926K * 3 and A-Rows is 5, these two values have much difference. By the way, the Starts of REMOTE is 926K, that s to say, it has executed too many times, this operation has extremely consumed resource and is on the table from remote db. Afterwards, there have two operations of REMOTE under Remote SQL Information next to the execution plan. It s obvious that in-line view r on that SQL hasn t overall queried the result from remote table and then it has returned to local db. However, it has executed the fifth steps firstly and the eighth step secondly querying remote table twice as a whole. It s assumed that whether we could make remote table being queried only once, furthermore, in-line view r has just executed once and then returned the query result from remote table sd_res_id_case? Sure, we could use the Hint of no_merge which would insert closely the first select located on in-line view r. Rewriting that SQL finally is as follows,

7 It s amazing that it has spent about 7 seconds to show query result, see my snapshot as follows, And then, checking the execution plan with plan statistics, select * from table(dbms_xplan.display_cursor(null, NULL, ALLSTATS ALL ));

8 Mainly, the execution time has reduced too much this time. You have even found that there has one operation of REMOTE and the second step (that line of Id is 2) has been HASH JOIN (the original execution plan is NESTED LOOPS ) and E-Rows A-Rows is equal to 5. Next, we can find that it s the operation of VIEW on line 5 that Id is, Starts is 1, E-Rows is 5754, A-Rows is and it has almost 10 times than E-Rows. I estimate that this SQL could maybe improve better if retuning. 4. Checking data size of in-line view r from remote db Due to we can t see the execution plan from remote table on local db, hence we ll check in-line view r and observe how much data there has on remote db. Doing some query as follows on remote db, set linesize 400 set pagesize 400

9 set timing on It has shown (about 196K) rows, this figure is very high much beyond my imagination. And then, we checked the execution plan with row source that is as follows, select * from table(dbms_xplan.display_cursor(null, NULL, ALLSTATS ALL ));

10 From snapshot above, we can see the second step NESTED LOOPS ( Id is 2) has returned actually 196K rows and it is also about the content of select count(*) located outermost on that SQL statement; The seventh step TABLE ACCESS BY USER ROWID ( Id is 7) has returned 196K rows too (checking seriously, its Starts is 196K, the same as, it has executed 196K times, this s so terrible), the operation of line 7 is a subquery about select min(rowid) from. Due to Starts of line 2 is equal to 1, so the row numbers returned about this SQL has depended on that subquery. If this subquery would return massive data, even I can t assume that how slow about original SQL statement s query speed is. In gerenal, adding a Hint of no_merge, it s obvious that the execution time of SQL is faster than original SQL s. Thereupon, I ve communicated with the colleague of developer and finally understood that the SQL is a timed-task running on web application server, it executes at 4:00 AM every day. According to my opinion, he added the Hint of no_merge that I ve mentioned previous to those SQLs come from his program. 5. Problem analysis -2 The next day, I ve checked the wait-event of DBLINK at 4:00 AM ~ 6:00 AM during that time period via v$active_session_history. See my two snapshots as follows, set linesize 400 set pagesize 500

11 col sql_id for a15 col event for a30 col count(*) for select sql_id, event, count(*) from v$active_session_history where sample_time between to_date ( :00:00, yyyy-mm-dd hh24:mi:ss ) and to_date ( :00:00, yyyy-mm-dd hh24:mi:ss ) and event like %dblink% group by sql_id, event order by count(*) desc, sql_id ;

12 According to query above, we can see there are top 2 sql_id total cumulative number of wait-event of DBLINK are greater more than any other sql_id. Another SQL is different than what I have analyzed previous and it has only added a condition of ROWNUM <= :2 on the outermost select. Now, we have just analyzed original SQL. Next, I rechecked it at 6:00 AM ~ 7:00 AM during that time period. As a result, it has returned to no rows selected having no wait-event of DBLINK, that s to say, the execution of related SQL statements have been all completed as follows, select sql_id, event, count(*) from v$active_session_history where sample_time between to_date ( :00:00, yyyy-mm-dd hh24:mi:ss ) and to_date ( :00:00, yyyy-mm-dd hh24:mi:ss ) and event like %dblink% group by sql_id, event order by count(*) desc, sql_id ; no rows selected. On the other hand, we can also see that the query result from the comparison report of AWR below (AWR has read related information from DBA_HIST_ACTIVE_SESS_HISTORY ).

13

14

15 From AWR report above, we can also see the execution times of those two SQL is 3106 and According to the analysis of execution plan previous, we have understood that the query speed of SQL is slow because of returning too much rows on the in-line view r. Then, if optimizing this SQL continually, we should rewrite the in-line view. Firstly, via adding the condition of where and which is the same as inner select query on the outermost select of in-line view r.

16 If this, it can eliminate many rows and at the same time do the equal associated operation by the field school_id of two-layer select query as follows, Nevertheless, it only spent 4 millisecond to show query result and the execution plan with row source is as follows,

17 select * from table(dbms_xplan.display_cursor(null, NULL, ALLSTATS ALL )); Next, I have communicated with the colleague of developer again and sent SQL that I ve rewritten to him and he has also done some comparison. Afterwards, he has rewritten original SQL according to business requirement, entire SQL statement having rewritten is as follows,

18

19 Checking the execution plan with plan statistics again that is as follows, select * from table(dbms_xplan.display_cursor(null, NULL, ALLSTATS ALL )); From the execution plan above, we can see the value of Starts, E-Rows or A-Rows is very small and A-Time is about only 1 ~ 2 millisecond. On the third day, I ve checked total cumulative number of wait-event of DBLINK again during that time period and found that it has reduced more than original SQL. select sql_id, event, count(*) from v$active_session_history where sample_time between to_date ( :00:00, yyyy-mm-dd hh24:mi:ss ) and to_date ( :00:00, yyyy-mm-dd hh24:mi:ss )

20 and event like %dblink% group by sql_id, event order by count(*) desc, sql_id ; 6. Conclusion Generally speaking, there are five steps about optimizing SQL using DBLINK, they are as follows, (1) Capturing problematical SQL from EMCC monitor platform; (2) Testing SQL via adding Hint of gather_plan_statistics ; (3) Generating related execution plan with row source and analyzing which step has most time-consuming; (4) Finding out the suitable solution (Not necessarily rewritten, this depends on the specific circumstances) and doing some test again; (5) Communicating with developers, reviewing and modifying SQL code (If you don t need change code, it would be better); Related References Classic case - How to optimize SQL statement of using DBLINK on Oracle