今天重慶ORACLE社區(qū)有位哥們提問(wèn)，為啥索引重建(alter index rebuil)之后，SQL變慢了，以前15秒就可以完成，現(xiàn)在要2分多種，于是問(wèn)他要了執(zhí)行計(jì)劃

SQL> set autotrace traceonly SQL> SELECT SEQ_PAY_CUSTOMEROPER.Nextval,u.ID,'admin',1,t.LAST_LOGIN_TIME,t.LOGIN_TIMES,t.LOGIN_IP2 FROM EFB_USER_MOVE@WODBLINK t,T_PAY_USERINFO u3 WHERE t.ID = u.ID AND u.ID > 3500000 AND u.ID<400000AND t.ID > 3500000 AND t.ID <= 40000004 /123832 rows selected.Execution Plan ---------------------------------------------------------- Plan hash value: 4225832519----------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Inst |IN-OUT| ----------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 77 | 5 (0)| 00:00:01 | | | | 1 | SEQUENCE | SEQ_PAY_CUSTOMEROPER | | | | | | | | 2 | NESTED LOOPS | | 1 | 77 | 5 (0)| 00:00:01 | | | |* 3 | INDEX RANGE SCAN| PK_T_PAY_USERINFO | 1 | 6 | 3 (0)| 00:00:01 | | | | 4 | REMOTE | EFB_USER_MOVE | 1 | 71 | 2 (0)| 00:00:01 | WODBL~ | R->S | -----------------------------------------------------------------------------------------------------------Predicate Information (identified by operation id): ---------------------------------------------------3 - access("U"."ID">3500000 AND "U"."ID"<=4000000)Remote SQL Information (identified by operation id): ----------------------------------------------------4 - SELECT "ID","LAST_LOGIN_TIME","LOGIN_TIMES","LOGIN_IP" FROM "EFB_USER_MOVE" "T" WHERE"ID"<=4000000 AND "ID">3500000 AND "ID"=:1 (accessing 'WODBLINK' )Statistics ----------------------------------------------------------86691 recursive calls18753 db block gets14781 consistent gets0 physical reads4035364 redo size5163224 bytes sent via SQL*Net to client91297 bytes received via SQL*Net from client8257 SQL*Net roundtrips to/from client0 sorts (memory)0 sorts (disk)123832 rows processed

這個(gè)SQL太簡(jiǎn)單了，可以說(shuō)是我見過(guò)的SQL中最簡(jiǎn)單的，執(zhí)行計(jì)劃也非常簡(jiǎn)單。

這個(gè)SQL要返回123832條記錄，然后執(zhí)行計(jì)劃走的是nested loops，問(wèn)題顯而易見了，原因是表EFB_USER_MOVE是通過(guò)DBLINK過(guò)來(lái)的，本地?zé)o法得知表EFB_USER_MOVE的統(tǒng)計(jì)信息(也就是無(wú)法知道它有多少行)，所以CBO默認(rèn)給它設(shè)置為1行，但是返回了123832條記錄，所以給這個(gè)SQL加了個(gè)HINT

SELECT /*+ full(u)*/ SEQ_PAY_CUSTOMEROPER.Nextval,u.ID,'admin',1,t.LAST_LOGIN_TIME,t.LOGIN_TIMES,t.LOGIN_IPFROM EFB_USER_MOVE@WODBLINK t, T_PAY_USERINFO uWHERE t.ID = u.IDAND u.ID > 3500000AND u.ID < 400000AND t.ID > 3500000AND t.ID <= 4000000;

這樣SQL就能幾秒跑完了，這里的sequence還值得注意，因?yàn)橐祷?23832條記錄，如果sequence上的cache很小，也必然導(dǎo)致SQL慢，建議設(shè)置cache到1000

總結(jié)：遇到SQL語(yǔ)句中要引用DBLINK，需要特別留意，通常這樣的SQL需要DBA添加HINT，其實(shí)這只是DBLINK中一個(gè)需要注意的地方，還有地方就是 有時(shí)候需要添加

????????????driving_site 這個(gè)HINT來(lái)優(yōu)化，具體就不多說(shuō)了。

轉(zhuǎn)載于:https://www.cnblogs.com/hehe520/archive/2011/11/01/6330560.html

總結(jié)

以上是生活随笔為你收集整理的DBLINK 无统计信息导致SQL变慢的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。