데이터 베이스 MySQL 튜토리얼 有关DBLINK操作的语句执行机制及优化方式

有关DBLINK操作的语句执行机制及优化方式

Jun 07, 2016 pm 04:38 PM
최적화 구현하다 작동하다 방법 기구 성명

?分布式查询语句对于远程对象的查询在远程库执行,在远程可以执行的语句会通过优化器的查询转换,执行的是转换后的语句,然后结果集返回到本地,再与本地表运算。当然, 本地还是远程是相对的,我们可以通过driving_hint改变主查询计划的执行位置,但是对DML

?分布式查询语句对于远程对象的查询在远程库执行,在远程可以执行的语句会通过优化器的查询转换,执行的是转换后的语句,然后结果集返回到本地,再与本地表运算。当然,
本地还是远程是相对的,我们可以通过driving_hint改变主查询计划的执行位置,但是对DML,driving_site是失效的。另外对远程表也可以使用其他hint。

???分布式查询可能一条SQL语句中有不同远程库的表,优化分布式查询要达到3点效果
1.访问同一个远程库的次数要尽量少,也就是同一远程库的对象应该尽量转为一条SQL运算,一次运算,运算后将结果返回给本地库
2.从远程库上返回到本地库的结果要尽量少,只访问远程对象需要的字段
3.远程库上执行的语句的计划以及远程库返回的结果与本地可以联合查询的计划应该高效
?优化分布式查询需要从以上3个方面着手。

下面的local_tab 7万多条,remote_big_tab百万条,remote_small_tab 7万多条。

?1.使用Collocated内联视图
? 也就是SQL要对引用不同远程库的表,要组织好,将相同库的表放一起组织成内联视图,这样ORACLE就很容易知道这个内联视图里的表是在同一远程库作完查询
? 后再返回给本地库,这样减少了本地库与远程库的交互次数和传输结果集的数量和次数。比如上面的查询

SELECT ?* FROM local_tab a
?WHERE EXISTS
?(SELECT ?1 FROM remote_big_tab@remote b,remote_small_tab@remote c
?WHERE b.object_id=c.object_id AND a.object_type=b.object_type);

执行计划
———————————————————-
Plan hash value: 49311412
————————————————————————————————
| Id ?| Operation ? ? ? ? ?| Name ? ? ?| Rows ?| Bytes | Cost (%CPU)| Time ? ? | Inst ? |IN-OUT|
————————————————————————————————
| ? 0 | SELECT STATEMENT ? | ? ? ? ? ? | 42747 | ?4508K| ?2152 ? (4)| 00:00:26 | ? ? ? ?| ? ? ?|
|* ?1 | ?HASH JOIN ? ? ? ? | ? ? ? ? ? | 42747 | ?4508K| ?2152 ? (4)| 00:00:26 | ? ? ? ?| ? ? ?|
| ? 2 | ? VIEW ? ? ? ? ? ? | VW_SQ_1 ? | ? ?26 | ? 286 | ?1855 ? (4)| 00:00:23 | ? ? ? ?| ? ? ?|
| ??3 | ? ?REMOTE???? ? ? ?| ? ? ? ? ? | ? ? ? | ? ? ? | ? ? ? ? ? ?| ? ? ? ? ?| REMOTE | R->S |
| ? 4 | ? TABLE ACCESS FULL| LOCAL_TAB | 73985 | ?7008K| ? 296 ? (1)| 00:00:04 | ? ? ? ?| ? ? ?|
————————————————————————————————
Predicate Information (identified by operation id):
—————————————————
? ?1 – access(“A”.”OBJECT_TYPE”=”ITEM_0″)
Remote SQL Information (identified by operation id):
—————————————————-
? ?3 – EXPLAIN PLAN SET STATEMENT_ID=’PLUS5801659′ INTO PLAN_TABLE@!?FOR SELECT
? ? ? ?DISTINCT “A2″.”OBJECT_TYPE” FROM “REMOTE_BIG_TAB” “A2″,”REMOTE_SMALL_TAB” “A1″ WHERE
? ? ? ?”A2″.”OBJECT_ID”=”A1″.”OBJECT_ID”?(accessing ‘REMOTE’ )

? 可以看出,在远程库remote上执行的语句是两个远程表关联后,并经过查询转换(全转为大写,自己取了别名A1,A2,ORACLE内部自己改造为止查询DISTINCT ??remote_big_tab.object_type),之后远程查询结果返回给本地,可以去远程库里查询实际的计划,走的是HASH JOIN。

2.了解CBO优化器对分布式查询的处理
? ?CBO对分布式查询的处理,也是尽量转为Collocated内联视图,CBO会做如下动作:
? ?1)所有可mergeable的视图会merge
? ?2 ) CBO会测试Collocated内联视图的query BLOCK
? ?3 ) 如果可以使用,就使用合并
? ?当然,CBO对分布式查询的处理,可能是不高效的,这时候得用其他的方法,比如使用HINT,改造SQL,改造分布式查询的方法(远程库用视图)等。
???特别当分布式查询包含下列情况,CBO可能是不高效的:
? ?1)有分组运算
? ?2)有子查询
? ?3)SQL很复杂
? ?
? ?比如下面语句含有子查询:

SELECT ?* FROM local_tab a,remote_big_tab@remote b,remote_small_tab@remote c
?WHERE b.object_id=c.object_id AND a.object_type=b.object_type
?AND a.object_id IN (SELECT object_id from sub);
执行计划
———————————————————-
Plan hash value: 252158753
———————————————————————————————————-
| Id ?| Operation ? ? ? ? ? ? | Name ? ? ? ? ? ? | Rows ?| Bytes | Cost (%CPU)| Time ? ? | Inst ? |IN-OUT|
———————————————————————————————————-
| ? 0 | SELECT STATEMENT ? ? ?| ? ? ? ? ? ? ? ? ?| ? ?79M| ? ?20G| ?3843 ?(46)| 00:00:47 | ? ? ? ?| ? |
|* ?1 | ?HASH JOIN ? ? ? ? ? ?| ? ? ? ? ? ? ? ? ?| ? ?79M| ? ?20G| ?3843 ?(46)| 00:00:47 | ? ? ? ?| ? |
| ? 2 | ??REMOTE ? ? ? ? ? ? ?| REMOTE_SMALL_TAB?| ?5320 | ? 431K| ? ? 8 ? (0)| 00:00:01 | REMOTE | R->S |
|* ?3 | ? HASH JOIN ? ? ? ? ? | ? ? ? ? ? ? ? ? ?| ? 172M| ? ?31G| ?2978 ?(31)| 00:00:36 | ? ? ? ?| ? |
|* ?4 | ? ?HASH JOIN ? ? ? ? ?| ? ? ? ? ? ? ? ? ?| ?5260 | ? 565K| ? 303 ? (2)| 00:00:04 | ? ? ? ?| ? |
| ? 5 | ? ? SORT UNIQUE ? ? ? | ? ? ? ? ? ? ? ? ?| ?5320 | 69160 | ? ? 5 ? (0)| 00:00:01 | ? ? ? ?| ? |
| ? 6 | ? ? ?TABLE ACCESS FULL| SUB ? ? ? ? ? ? ?| ?5320 | 69160 | ? ? 5 ? (0)| 00:00:01 | ? ? ? ?| ? |
| ? 7 | ? ? TABLE ACCESS FULL | LOCAL_TAB ? ? ? ?| 73985 | ?7008K| ? 296 ? (1)| 00:00:04 | ? ? ? ?| ? |
| ? 8 | ???REMOTE ? ? ? ? ? ? | REMOTE_BIG_TAB?? | ?1479K| ? 119M| ?1819 ? (2)| 00:00:22 | REMOTE | R->S |
———————————————————————————————————-
Predicate Information (identified by operation id):
—————————————————
? ?1 – access(“B”.”OBJECT_ID”=”C”.”OBJECT_ID”)
? ?3 – access(“A”.”OBJECT_TYPE”=”B”.”OBJECT_TYPE”)
? ?4 – access(“A”.”OBJECT_ID”=”OBJECT_ID”)

Remote SQL Information (identified by operation id):
—————————————————-

???2 – SELECT “OBJECT_NAME”,”SUBOBJECT_NAME”,”OBJECT_ID”,”DATA_OBJECT_ID”,”OBJECT_TYPE”,”CREATED”,
? ? ? ?”LAST_DDL_TIME”,”TIMESTAMP”,”STATUS”,”TEMPORARY”,”GENERATED”,”SECONDARY” FROM “REMOTE_SMALL_TAB”
? ? ? ?”C” (accessing ‘REMOTE’ )

? ?8 – SELECT “OWNER”,”OBJECT_NAME”,”SUBOBJECT_NAME”,”OBJECT_ID”,”DATA_OBJECT_ID”,”OBJECT_TYPE”,”C
? ? ? ?REATED”,”LAST_DDL_TIME”,”TIMESTAMP”,”STATUS”,”TEMPORARY”,”GENERATED”,”SECONDARY” FROM
? ? ? ?”REMOTE_BIG_TAB” “B” (accessing ‘REMOTE’ )

?

?通过计划可以看到REMOTE有两个,两张远程表无法做Collocated inline VIEW运算。
?
? 再比如下面的语句,有分组运算:

SELECT ?* FROM local_tab a,remote_big_tab@remote b,(SELECT max(object_id) object_id FROM remote_small_tab@remote c GROUP BY c.object_type) c
WHERE b.object_id=c.object_id AND a.object_type=b.object_type;

执行计划
———————————————————-
Plan hash value: 2122363341
—————————————————————————————————–
| Id ?| Operation ? ? ? ? ?| Name ? ? ? ? ? | Rows ?| Bytes | Cost (%CPU)| Time ? ? | Inst ? |IN-OUT|
—————————————————————————————————–
| ? 0 | SELECT STATEMENT ? | ? ? ? ? ? ? ? ?| ?2321K| ? 431M| ?2144 ? (3)| 00:00:26 | ? ? ? ?| ? ? ?|
|* ?1 | ?HASH JOIN ? ? ? ? | ? ? ? ? ? ? ? ?| ?2321K| ? 431M| ?2144 ? (3)| 00:00:26 | ? ? ? ?| ? ? ?|
|* ?2 | ? HASH JOIN ? ? ? ?| ? ? ? ? ? ? ? ?| ?1412 | ? 135K| ?1836 ? (3)| 00:00:23 | ? ? ? ?| ? ? ?|
| ? 3 | ? ?VIEW ? ? ? ? ? ?| ? ? ? ? ? ? ? ?| ? ?11 | ? 143 | ? ? 9 ?(12)| 00:00:01 | ? ? ? ?| ? ? ?|
| ? 4 | ? ??REMOTE ? ? ? ??| ? ? ? ? ? ? ? ?| ? ? ? | ? ? ? | ? ? ? ? ? ?| ? ? ? ? ?| REMOTE | R->S |
| ? 5 | ???REMOTE ? ? ? ? ?| REMOTE_BIG_TAB?| ?1479K| ? 119M| ?1819 ? (2)| 00:00:22 | REMOTE | R->S |
| ? 6 | ? TABLE ACCESS FULL| LOCAL_TAB ? ? ?| 73985 | ?7008K| ? 296 ? (1)| 00:00:04 | ? ? ? ?| ? ? ?|
—————————————————————————————————–
Predicate Information (identified by operation id):
—————————————————
? ?1 – access(“A”.”OBJECT_TYPE”=”B”.”OBJECT_TYPE”)
? ?2 – access(“B”.”OBJECT_ID”=”C”.”OBJECT_ID”)

Remote SQL Information (identified by operation id):
—————————————————-
? ?4 – EXPLAIN PLAN SET STATEMENT_ID=’PLUS5801659′ INTO PLAN_TABLE@! FOR SELECT
? ? ? ?MAX(“A1″.”OBJECT_ID”) FROM “REMOTE_SMALL_TAB” “A1″ GROUP BY “A1″.”OBJECT_TYPE” (accessing
? ? ? ?’REMOTE’ )
? ?5 – SELECT “OWNER”,”OBJECT_NAME”,”SUBOBJECT_NAME”,”OBJECT_ID”,”DATA_OBJECT_ID”,”OBJECT_TYP
? ? ? ?E”,”CREATED”,”LAST_DDL_TIME”,”TIMESTAMP”,”STATUS”,”TEMPORARY”,”GENERATED”,”SECONDARY” FROM
? ? ? ?”REMOTE_BIG_TAB” “B” (accessing ‘REMOTE’ )

?? 通过计划看出,将远程表进行分组运算后,传输给本地库,然后大表传输给本地库,之后做HASH JOIN,这是不高效的。运行时间:已用时间: ?00: 02: 12.22

?可以改造分布式查询,手动组织Collocated inline VIEW,在远程库建立view:

CREATE OR REPLACE VIEW v_remote
AS
SELECT ?b.* FROM remote_big_tab b,(SELECT max(object_id) object_id FROM remote_small_tab c GROUP BY c.object_type) c
WHERE b.object_id=c.object_id;?

查询改为:
?SELECT ? * FROM local_tab a,v_remote@remote v WHERE a.object_type=v.object_type;

SQL> SELECT ? * FROM local_tab a,v_remote@remote v WHERE a.object_type=v.object_type;
已选择1727104行。
已用时间: ?00: 01: 02.81

执行计划
———————————————————-
Plan hash value: 2216230941
————————————————————————————————
| Id ?| Operation ? ? ? ? ?| Name ? ? ?| Rows ?| Bytes | Cost (%CPU)| Time ? ? | Inst ? |IN-OUT|
————————————————————————————————
| ? 0 | SELECT STATEMENT ? | ? ? ? ? ? | ? ? 1 | ? 274 | ? 299 ? (2)| 00:00:04 | ? ? ? ?| ? ? ?|
|* ?1 | ?HASH JOIN ? ? ? ? | ? ? ? ? ? | ? ? 1 | ? 274 | ? 299 ? (2)| 00:00:04 | ? ? ? ?| ? ? ?|
| ? 2 | ??REMOTE ? ? ? ? ? | V_REMOTE??| ? ? 1 | ? 177 | ? ? 2 ? (0)| 00:00:01 | REMOTE | R->S |
| ? 3 | ? TABLE ACCESS FULL| LOCAL_TAB | 73985 | ?7008K| ? 296 ? (1)| 00:00:04 | ? ? ? ?| ? ? ?|
————————————————————————————————
Predicate Information (identified by operation id):
—————————————————
? ?1 – access(“A”.”OBJECT_TYPE”=”V”.”OBJECT_TYPE”)

?通过计划可以看出,现在是远程表做整体操作之后才返回到本地了。

?3.使用HINT,特别是driving_site HINT
? 对远程表可以使用hint,比如parallel,use_nl,use_hash,FULL等。
? driving_site hint能够指定执行计划在远程还是本地做,比如下面使用driving_site(b),那么原来的远程表就相当于本地表,本地表要传输给remote库,主计划在remote库上执行
??

SELECT/*+driving_site(b)*/ ?* FROM local_tab a,remote_big_tab@remote b,(SELECT max(object_id) object_id FROM remote_small_tab@remote c GROUP BY c.object_type) c
WHERE b.object_id=c.object_id AND a.object_type=b.object_type;

? ?当然,如果是driving_site(a)那么就是本地驱动的,默认的是本地驱动的。
? ?
? ?使用driving_site,特别是本地小结果集,远程大结果集的时候,总体结果集较小,希望计划在远程驱动,这样远程执行完毕,将结果集传输到本地,这样避免大结果集的传输。
? ?
? ?例1:
?? ? ? ??小表9998条,大表3169376条记录,远程大表sub_id,acc_id上联合索引

SQL> ?SELECT ?COUNT(*) ?FROM small_tab_local a, big_tab_remote@remote b
? 2 ? WHERE a.sub_id=b.sub_id AND a.acc_id=b.acc_id;
?
??? ? ?859
已用时间: ?00: 00: 50.76

执行计划
———————————————————-
Plan hash value: 1507576754
——————————————————————————————————–
| Id ?| Operation ? ? ? ? ? ?| Name ? ? ? ? ? ?| Rows ?| Bytes | Cost (%CPU)| Time ? ? | Inst ? |IN-OUT|
——————————————————————————————————–
| ? 0 | SELECT STATEMENT ? ? | ? ? ? ? ? ? ? ? | ? ? 1 | ? ?41 | ? ?44 ? (3)| 00:00:01 | ? ? ? ?| ? ? ?|
| ? 1 | ?SORT AGGREGATE ? ? ?| ? ? ? ? ? ? ? ? | ? ? 1 | ? ?41 | ? ? ? ? ? ?| ? ? ? ? ?| ? ? ? ?| ? ? ?|
| ? 2 | ??MERGE JOIN ? ??? ? | ? ? ? ? ? ? ? ? | ?9998 | ? 400K| ? ?44 ? (3)| 00:00:01 | ? ? ? ?| ? ? ?|
| ? 3 | ???REMOTE ? ? ? ? ? ?| BIG_TAB_REMOTE ?| ?6771K| ? 167M|?? ?26 ? (0)| 00:00:01 | REMOTE | R->S |
|* ?4 | ? ?SORT JOIN ? ? ? ? | ? ? ? ? ? ? ? ? | ?9998 | ? 146K| ? ?18 ? (6)| 00:00:01 | ? ? ? ?| ? ? ?|
| ? 5 | ? ? TABLE ACCESS FULL| SMALL_TAB_LOCAL | ?9998 | ? 146K| ? ?17 ? (0)| 00:00:01 | ? ? ? ?| ? ? ?|
——————————————————————————————————–

Predicate Information (identified by operation id):
—————————————————
? ?4 – access(“A”.”SUB_ID”=”B”.”SUB_ID” AND “A”.”ACC_ID”=”B”.”ACC_ID”)
? ? ? ?filter(“A”.”ACC_ID”=”B”.”ACC_ID” AND “A”.”SUB_ID”=”B”.”SUB_ID”)

Remote SQL Information (identified by operation id):
—————————————————-

? ?3 – SELECT “SUB_ID”,”ACC_ID” FROM “BIG_TAB_REMOTE” “B” ORDER BY “SUB_ID”,”ACC_ID”
? ? ? ?(accessing ‘REMOTE’ )

? ? 查询876条数据,耗时50s,显然将大结果集拉到本地做运算是不好的,因为本地表很小,远程大表有索引,如果能在远端执行,并走nl,那么显然效率非常好。使用driving_site hint改造查询如下:
??

SELECT/*+driving_site(b) ?ordered use_nl(b)*/ ?COUNT(*) FROM small_tab_local a, big_tab_remote@remote b
?WHERE a.sub_id=b.sub_id AND a.acc_id=b.acc_id;

计划如下:
———————————————————————————————
| Id ?| Operation ? ? ? ? ? ? ?| Name ? ? ? ? ? ? ? | Rows ?| Bytes | Cost ?| Inst ? |IN-OUT|
———————————————————————————————
| ? 0 | SELECT STATEMENT REMOTE| ? ? ? ? ? ? ? ? ? ?| ? ? 1 | ? ?52 | 10009 | ? ? ? ?| ? ? ?|
| ? 1 | SORT AGGREGATE ? ? ? ? | ? ? ? ? ? ? ? ? ? ?| ? ? 1 | ? ?52 | ? ? ? | ? ? ? ?| ? ? ?|
| ? 2 |?NESTED LOOPS ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ?| ? 681 | 35412 | 10009 | ? ? ? ?| ? ? ?|
| ? 3 |?REMOTE ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ?| ?9998?| ? 253K| ? ?11 | ? ? ?! | R->S |
|* ?4 | INDEX RANGE SCAN ? ? ? | IDX_BIG_TAB_REMOTE | ? ? 1 | ? ?26 | ? ? 1 | MZT~ | ? ? ?|
———————————————————————————————

Predicate Information (identified by operation id):
—————————————————
? ?4 – access(“A2″.”SUB_ID”=”A1″.”SUB_ID” AND “A2″.”ACC_ID”=”A1″.”ACC_ID”)

Remote SQL Information (identified by operation id):
—————————————————-
???3 – SELECT “SUB_ID”,”ACC_ID” FROM “SMALL_TAB_LOCAL” “A2″ (accessing ‘!’ )

? ? ?现在主计划是在远端remote上执行的,本地表small_tab_local变成了远程表,会讲small_tab_local结果集送到远端,只查询了sub_id,acc_id,然后作为驱动表,与远端表做nl运算,
计划里可以看到远端表走索引了,最后将远端结果返回到本地。(事实上这里的远端库与本地库换了)

? driving_site hint注意点:
??driving_site对dml无效,dml以目标表所在库驱动SQL计划。比如下面的driving_site失效,后面的hint还是有效的。
? ?

? CREATE TABLE test_cnt (cnt NUMBER);
? INSERT INTO test_cnt
? SELECT/*+driving_site(b) ordered use_nl(b)*/ ?COUNT(*) FROM small_tab_local a, big_tab_remote@remote b
? WHERE a.sub_id=b.sub_id AND a.acc_id=b.acc_id;
已用时间:??00: 01: 31.48

执行计划
———————————————————-
Plan hash value: 259989953
————————————————————————————————————
| Id ?| Operation ? ? ? ? ? ? ? ?| Name ? ? ? ? ? ?| Rows ?| Bytes | Cost (%CPU)| Time ? ? | Inst ? |IN-OUT|
————————————————————————————————————
| ? 0 | INSERT STATEMENT ? ? ? ? | ? ? ? ? ? ? ? ? | ? ? 1 | ? ?41 | 10035 ? (1)| 00:02:01 | ? ? ? ?| ? ? ?|
| ? 1 | ?LOAD TABLE CONVENTIONAL | TEST_CNT ? ? ? ?| ? ? ? | ? ? ? | ? ? ? ? ? ?| ? ? ? ? ?| ? ? ? ?| ? ? ?|
| ? 2 | ? SORT AGGREGATE ? ? ? ? | ? ? ? ? ? ? ? ? | ? ? 1 | ? ?41 | ? ? ? ? ? ?| ? ? ? ? ?| ? ? ? ?| ? ? ?|
| ? 3 | ???NESTED LOOPS ? ????? ?| ? ? ? ? ? ? ? ? | ?9998 | ? 400K| 10035 ? (1)| 00:02:01 | ? ? ? ?| ? ? ?|
| ? 4 | ? ? TABLE ACCESS FULL ? ?| SMALL_TAB_LOCAL | ?9998 | ? 146K| ? ?17 ? (0)| 00:00:01 | ? ? ? ?| ? ? ?|
| ? 5 | ? ? REMOTE ? ? ? ? ? ? ? | BIG_TAB_REMOTE ?| ? ? 1 | ? ?26 | ? ? 1 ? (0)| 00:00:01 | REMOTE | R->S |
————————————————————————————————————

Remote SQL Information (identified by operation id):
—————————————————-

? ?5 – SELECT?/*+ OPAQUE_TRANSFORM USE_NL (“B”) */?”SUB_ID”,”ACC_ID” FROM “BIG_TAB_REMOTE” “B”
? ? ? ?WHERE?:1=”SUB_ID” AND :2=”ACC_ID”?(accessing ‘REMOTE’ )

? 语句执行1分31s,driving_site hint失效,但是后面的NL没有失效,可以从计划中看出类似绑定变量的东西,这实际对于每个small_tab_local的结果集的行,将sub_id,acc_id传给远端表big_tab_remote,也就是:1,:2,这样本地的表筛选出多少行,远程语句?SELECT?/*+ OPAQUE_TRANSFORM USE_NL (“B”) */?”SUB_ID”,”ACC_ID” FROM “BIG_TAB_REMOTE” “B”
?WHERE?:1=”SUB_ID” AND :2=”ACC_ID” 就执行多少次。

?这里本地表9998条,无过滤条件,因此远程表语句运行了9998次,虽然远程查询也是走索引的,但是SQL被执行了9998次,是非常影响性能的。可以去远程库查询下:
?

SQL> SELECT sql_text,executions FROM v$sql WHERE sql_text LIKE ‘%SELECT /*+ USE_NL (“B”) */ “SUB_ID”,”ACC_ID” FROM “BIG_TAB_REMOTE”%’
? 2 ?/
?
SQL_TEXT ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? EXECUTIONS
——————————————————————————– ————————————————————–
SELECT /*+ USE_NL (“B”) */ “SUB_ID”,”ACC_ID” FROM “BIG_TAB_REMOTE” “B” WHERE :1= ? ??? 9998

? ?这里driving_site失效,但是后面的nl还有效,远程表执行的次数是small_tab_local表的数量(因为这里没有谓词过滤small_tab_local),可以使用其他hint,比如。

? INSERT INTO test_cnt
? SELECT/*+ordered use_hash(b)*/ ? COUNT(*) FROM small_tab_local a, big_tab_remote@remote b
? WHERE a.sub_id=b.sub_id AND a.acc_id=b.acc_id;
??
??当然效率不一定很好,因为这里由远程驱动效率最好,为了不想driving_site失效,可以使用PL/SQL(这里是只查询数量,如果查询结果集可以使用PL/SQL批处理插入)。

BEGIN
? ? FOR i IN (SELECT/*+driving_site(b) ordered use_nl(b)*/ ?COUNT(*) cnt FROM small_tab_local a, big_tab_remote@remote b
? ? ? ? ? ? ? ? ? ?WHERE a.sub_id=b.sub_id AND a.acc_id=b.acc_id)
? ?LOOP
? ? ?INSERT INTO test_cnt VALUES(i.cnt);
? END LOOP;
? COMMIT;
END;
已用时间:??00: 00: 00.89

? ? ?
? 例2:
? ? ? 查询语句:

SELECT * FROM?v_remote?WHERE object_id IN (
??SELECT c.object_id FROM c WHERE c.object_name
? ? ? ? ?? IN (SELECT d.object_name FROM d WHERE d.object_id=11)
);

?比较慢,返回32行,需要10来秒。其中v_remote是个视图,此视图连接到远程表,其中远程的两张表的object_id都有索引

CREATE OR REPLACE VIEW v_remote
AS
SELECT object_name,object_id,object_type FROM a@remote ?
UNION ALL
SELECT ?object_name,object_id,object_type FROM b@remote;

两表记录数如下:
SQL> SELECT COUNT(*) FROM a;
?
? COUNT(*)
———-
??? 369888
SQL> SELECT COUNT(*) FROM b;
?
? COUNT(*)
———-
? ? ??5323

? c和d是本地表,d.object_id以及c.object_name有索引。单独查询很快,

–单独本地语句消耗时间00: 00: 00.01
SQL> SELECT c.object_id FROM c WHERE c.object_name IN (SELECT d.object_name FROM d WHERE d.object_id=11);
已用时间: ?00: 00: 00.01
执行计划
———————————————————-
Plan hash value: 2528799293
—————————————————————————————-
| Id ?| Operation ? ? ? ? ? ? ? ? ? ? ?| Name ?| Rows ?| Bytes | Cost (%CPU)| Time ? ? |
—————————————————————————————-
| ? 0 | SELECT STATEMENT ? ? ? ? ? ? ? | ? ? ? | ? ? 2 | ? ?94 | ? ? 6 ?(17)| 00:00:01 |
| ? 1 | ?NESTED LOOPS ? ? ? ? ? ? ? ? ?| ? ? ? | ? ? ? | ? ? ? | ? ? ? ? ? ?| ? ? ? ? ?|
| ? 2 | ? NESTED LOOPS ? ? ? ? ? ? ? ? | ? ? ? | ? ? 2 | ? ?94 | ? ? 6 ?(17)| 00:00:01 |
| ? 3 | ? ?SORT UNIQUE ? ? ? ? ? ? ? ? | ? ? ? | ? ? 1 | ? ?17 | ? ? 2 ? (0)| 00:00:01 |
| ? 4 | ? ? TABLE ACCESS BY INDEX ROWID| D ? ? | ? ? 1 | ? ?17 | ? ? 2 ? (0)| 00:00:01 |
|* ?5 | ? ? ?INDEX RANGE SCAN ? ? ? ? ?| IDX_D | ? ? 1 | ? ? ? | ? ? 1 ? (0)| 00:00:01 |
|* ?6 | ? ?INDEX RANGE SCAN ? ? ? ? ? ?| IDX_C | ? ? 2 | ? ? ? | ? ? 2 ? (0)| 00:00:01 |
| ? 7 | ? TABLE ACCESS BY INDEX ROWID ?| C ? ? | ? ? 2 | ? ?60 | ? ? 3 ? (0)| 00:00:01 |
—————————————————————————————-
Predicate Information (identified by operation id):
—————————————————
? ?5 – access(“D”.”OBJECT_ID”=11)
? ?6 – access(“C”.”OBJECT_NAME”=”D”.”OBJECT_NAME”)

–单独远程语句消耗时间?00: 00: 00.06
SQL> SELECT * FROM v_remote WHERE object_id=11;
已选择32行。
已用时间: ?00: 00: 00.06
执行计划
———————————————————-
Plan hash value: 1788691278
————————————————————–
| Id ?| Operation ? ? ? ?| Name | Cost (%CPU)| Inst ? |IN-OUT|
————————————————————–
| ? 0 | SELECT STATEMENT | ? ? ?| ? ? 0 ? (0)| ? ? ? ?| ? ? ?|
| ? 1 |??REMOTE ? ? ? ? ?| ? ? ?| ? ? ? ? ? ?| REMOTE | R->S?|
————————————————————–

Remote SQL Information (identified by operation id):
—————————————————-
???1 – EXPLAIN PLAN SET STATEMENT_ID=’PLUS5821518′ INTO PLAN_TABLE@!
? ? ? ?FOR SELECT “A1″.”OBJECT_NAME”,”A1″.”OBJECT_ID”,”A1″.”OBJECT_TYPE” FROM
? ? ? ?( (SELECT “A4″.”OBJECT_NAME” “OBJECT_NAME”,”A4″.”OBJECT_ID”
? ? ? ?”OBJECT_ID”,”A4″.”OBJECT_TYPE” “OBJECT_TYPE” FROM “A” “A4″ WHERE
? ? ? ?”A4″.”OBJECT_ID”=11) UNION ALL ?(SELECT “A3″.”OBJECT_NAME”
? ? ? ?”OBJECT_NAME”,”A3″.”OBJECT_ID” “OBJECT_ID”,”A3″.”OBJECT_TYPE”
? ? ? ?”OBJECT_TYPE” FROM “B” “A3″ WHERE “A3″.”OBJECT_ID”=11)) “A1″ (accessing
? ? ? ?’REMOTE’ )
–联合查询消耗时间00: 00: 10.95
SQL> SELECT * FROM v_remote WHERE object_id IN (
? 2 ?SELECT c.object_id FROM c WHERE c.object_name IN (SELECT d.object_name FROM d WHERE d.object_id=11)
? 3 ?);
已选择32行。
已用时间: ?00: 00: 10.95
执行计划
———————————————————-
Plan hash value: 2118901120
————————————————————————————————————-
| Id ?| Operation ? ? ? ? ? ? ? ? ? ? ? ?| Name ? ? | Rows ?| Bytes | Cost (%CPU)| Time ? ? | Inst ? |IN-OUT|
————————————————————————————————————-
| ? 0 | SELECT STATEMENT ? ? ? ? ? ? ? ? | ? ? ? ? ?| ? ?65 | ?6695 | ? 471 ? (3)| 00:00:06 | ? ? ? ?| ? ? ?|
|* ?1 | ?HASH JOIN ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ?| ? ?65 | ?6695 | ? 471 ? (3)| 00:00:06 | ? ? ? ?| ? ? ?|
| ? 2 | ? VIEW ? ? ? ? ? ? ? ? ? ? ? ? ? | VW_NSO_1 | ? ? 2 | ? ?26 | ? ? 6 ?(17)| 00:00:01 | ? ? ? ?| ? ? ?|
| ? 3 | ? ?HASH UNIQUE ? ? ? ? ? ? ? ? ? | ? ? ? ? ?| ? ? 2 | ? ?94 | ? ? 6 ?(17)| 00:00:01 | ? ? ? ?| ? ? ?|
| ? 4 | ? ? NESTED LOOPS ? ? ? ? ? ? ? ? | ? ? ? ? ?| ? ? ? | ? ? ? | ? ? ? ? ? ?| ? ? ? ? ?| ? ? ? ?| ? ? ?|
| ? 5 | ? ? ?NESTED LOOPS ? ? ? ? ? ? ? ?| ? ? ? ? ?| ? ? 2 | ? ?94 | ? ? 5 ? (0)| 00:00:01 | ? ? ? ?| ? ? ?|
| ? 6 | ? ? ? TABLE ACCESS BY INDEX ROWID| D ? ? ? ?| ? ? 1 | ? ?17 | ? ? 2 ? (0)| 00:00:01 | ? ? ? ?| ? ? ?|
|* ?7 | ? ? ? ?INDEX RANGE SCAN ? ? ? ? ?| IDX_D ? ?| ? ? 1 | ? ? ? | ? ? 1 ? (0)| 00:00:01 | ? ? ? ?| ? ? ?|
|* ?8 | ? ? ? INDEX RANGE SCAN ? ? ? ? ? | IDX_C ? ?| ? ? 2 | ? ? ? | ? ? 2 ? (0)| 00:00:01 | ? ? ? ?| ? ? ?|
| ? 9 | ? ? ?TABLE ACCESS BY INDEX ROWID | C ? ? ? ?| ? ? 2 | ? ?60 | ? ? 3 ? (0)| 00:00:01 | ? ? ? ?| ? ? ?|
| ?10 | ? VIEW ? ? ? ? ? ? ? ? ? ? ? ? ? | V_REMOTE | ? 375K| ? ?32M| ? 462 ? (2)| 00:00:06 | ? ? ? ?| ? ? ?|
|??11 | ? ?UNION-ALL ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ?| ? ? ? | ? ? ? | ? ? ? ? ? ?| ? ? ? ? ?| ? ? ? ?| ? ? ?|
| ?12 | ? ? REMOTE ? ? ? ? ? ? ? ? ? ? ? | A ? ? ? ?| ? 369K| ? ?29M| ? 454 ? (2)| 00:00:06 | REMOTE | R->S |
| ?13 | ? ? REMOTE ? ? ? ? ? ? ? ? ? ? ? | B ? ? ? ?| ?5323 | ? 431K| ? ? 8 ? (0)| 00:00:01 | REMOTE | R->S?|
————————————————————————————————————-

Predicate Information (identified by operation id):
—————————————————
? ?1 – access(“OBJECT_ID”=”OBJECT_ID”)
? ?7 – access(“D”.”OBJECT_ID”=11)
? ?8 – access(“C”.”OBJECT_NAME”=”D”.”OBJECT_NAME”)

Remote SQL Information (identified by operation id):
—————————————————-
??12 – SELECT “OBJECT_NAME”,”OBJECT_ID”,”OBJECT_TYPE” FROM “A” “A” (accessing ‘REMOTE’ )
? 13 – SELECT “OBJECT_NAME”,”OBJECT_ID”,”OBJECT_TYPE” FROM “B” “B” (accessing ‘REMOTE’ )

?

? ? ?单独查询很快,为什么联合查询就慢了呢?原因在于:
?

单独执行远程查询 本地与远程混合查询
直接执行视图,并将OBJECT_ID=11谓词推入到视图中,走索引,最后只将32行结果返回给本地 从计划中可以看到,本地查询与远程查询做HASH JOIN,但是访问远程的SQL是没有谓词的,这样必然全表从远程拉到本地,因为行数较多,所以慢

?

? ??因此,优化此混合查询的语句可以由多种办法(比如本地查询的数量较少,可以采用上面的方法,本地与远程查询拆分为2条语句),另外就是可以使用driving_site hint,将主计划推到远程库去执行,本地的结果集少,推到远程,远程视图走索引,效率高。如下:

–耗时已用时间: ?00: 00: 00.08
SQL> SELECT/*+driving_site(v_remote.a)*/ * FROM v_remote WHERE object_id IN (
? 2 ?SELECT c.object_id FROM c WHERE c.object_name IN (SELECT d.object_name FROM d WHERE d.object_id=11
? 3 ?);
已选择32行。
已用时间: ?00: 00: 00.08
—————————————————————————————
| Id ?| Operation ? ? ? ? ? ? ? ? ?| Name ? ? | Rows ?| Bytes | Cost ?| Inst ? |IN-OUT|
—————————————————————————————
| ? 0 | SELECT STATEMENT REMOTE ? ?| ? ? ? ? ?| ? ?15 | ?1425 | ? 109 | ? ? ? ?| ? ? ?|
| ? 1 | NESTED LOOPS ? ? ? ? ? ? ? | ? ? ? ? ?| ? ?15 | ?1425 | ? 109 | ? ? ? ?| ? ? ?|
| ? 2 | SORT UNIQUE ? ? ? ? ? ? ? ?| ? ? ? ? ?| ? ? ? | ? ? ? | ? ? ? | ? ? ? ?| ? ? ?|
| ? 3 | VIEW ? ? ? ? ? ? ? ? ? ? ? | VW_NSO_1 | ? ? 3 | ? ?39 | ? ? 8 | MZT~ | ? ? ?|
| ? 4 |?REMOTE ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ?| ? ? ? | ? ? ? | ? ? ? | ? ? ?! | R->S?|
| ? 5 | VIEW ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ?| ? ? 5 | ? 410 | ? ?33 | ? ? ? ?| ? ? ?|
| ? 6 |?UNION-ALL PARTITION ? ? ? ?| ? ? ? ? ?| ? ? ? | ? ? ? | ? ? ? | ? ? ? ?| ? ? ?|
| ? 7 | TABLE ACCESS BY INDEX ROWID| A ? ? ? ?| ? ?32 | ? 960 | ? ?35 |MZT~ | ? ? ?|
|* ?8 | INDEX RANGE SCAN ? ? ? ? ? | IDX_A ? ?| ? ?32 | ? ? ? | ? ? 3 |MZT~ | ? ? ?|
| ? 9 | TABLE ACCESS BY INDEX ROWID| B ? ? ? ?| ? ? 1 | ? ?32 | ? ? 2 | MZT~ | ? ? ?|
|* 10 | INDEX RANGE SCAN ? ? ? ? ? | IDX_B ? ?| ? ? 1 | ? ? ? | ? ? 1 | MZT~ | ? ? ?|
—————————————————————————————

Predicate Information (identified by operation id):
—————————————————
? ?8 – access(“A6″.”OBJECT_ID”=”VW_NSO_1″.”OBJECT_ID”)
? 10 – access(“A5″.”OBJECT_ID”=”VW_NSO_1″.”OBJECT_ID”)

Remote SQL Information (identified by operation id):
—————————————————-
? ?4 – SELECT /*+ */ “A1″.”OBJECT_ID” FROM “D” “A2″,”C” “A1″ WHERE
? ? ? ?”A1″.”OBJECT_NAME&

본 웹사이트의 성명
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.

핫 AI 도구

Undresser.AI Undress

Undresser.AI Undress

사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover

AI Clothes Remover

사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool

Undress AI Tool

무료로 이미지를 벗다

Clothoff.io

Clothoff.io

AI 옷 제거제

AI Hentai Generator

AI Hentai Generator

AI Hentai를 무료로 생성하십시오.

인기 기사

R.E.P.O. 에너지 결정과 그들이하는 일 (노란색 크리스탈)
4 몇 주 전 By 尊渡假赌尊渡假赌尊渡假赌
R.E.P.O. 최고의 그래픽 설정
4 몇 주 전 By 尊渡假赌尊渡假赌尊渡假赌
R.E.P.O. 아무도들을 수없는 경우 오디오를 수정하는 방법
4 몇 주 전 By 尊渡假赌尊渡假赌尊渡假赌
R.E.P.O. 채팅 명령 및 사용 방법
4 몇 주 전 By 尊渡假赌尊渡假赌尊渡假赌

뜨거운 도구

메모장++7.3.1

메모장++7.3.1

사용하기 쉬운 무료 코드 편집기

SublimeText3 중국어 버전

SublimeText3 중국어 버전

중국어 버전, 사용하기 매우 쉽습니다.

스튜디오 13.0.1 보내기

스튜디오 13.0.1 보내기

강력한 PHP 통합 개발 환경

드림위버 CS6

드림위버 CS6

시각적 웹 개발 도구

SublimeText3 Mac 버전

SublimeText3 Mac 버전

신 수준의 코드 편집 소프트웨어(SublimeText3)

Linux Deploy 작업 단계 및 주의사항 Linux Deploy 작업 단계 및 주의사항 Mar 14, 2024 pm 03:03 PM

LinuxDeploy 작업 단계 및 주의 사항 LinuxDeploy는 사용자가 Android 장치에 다양한 Linux 배포판을 신속하게 배포하여 모바일 장치에서 완전한 Linux 시스템을 경험할 수 있도록 도와주는 강력한 도구입니다. 이 기사에서는 LinuxDeploy의 작동 단계와 주의 사항을 자세히 소개하고 독자가 이 도구를 더 잘 사용할 수 있도록 구체적인 코드 예제를 제공합니다. 작업 단계: Linux 설치배포: 먼저 설치

Huawei Mate60 Pro 스크린샷 작업 단계 공유 Huawei Mate60 Pro 스크린샷 작업 단계 공유 Mar 23, 2024 am 11:15 AM

스마트폰이 대중화되면서 스크린샷 기능은 일상적인 휴대폰 사용에 필수적인 기술 중 하나로 자리 잡았습니다. Huawei의 주력 휴대폰 중 하나인 Huawei Mate60Pro의 스크린샷 기능은 자연스럽게 사용자로부터 많은 관심을 끌었습니다. 오늘은 모두가 더욱 편리하게 스크린샷을 찍을 수 있도록 Huawei Mate60Pro 휴대폰의 스크린샷 작업 단계를 공유하겠습니다. 우선, Huawei Mate60Pro 휴대폰은 다양한 스크린샷 방법을 제공하며, 개인 습관에 따라 자신에게 맞는 방법을 선택할 수 있습니다. 다음은 일반적으로 사용되는 몇 가지 차단에 대한 자세한 소개입니다.

C++ 프로그램 최적화: 시간 복잡도 감소 기술 C++ 프로그램 최적화: 시간 복잡도 감소 기술 Jun 01, 2024 am 11:19 AM

시간 복잡도는 입력 크기를 기준으로 알고리즘의 실행 시간을 측정합니다. C++ 프로그램의 시간 복잡성을 줄이는 팁에는 데이터 저장 및 관리를 최적화하기 위한 적절한 컨테이너(예: 벡터, 목록) 선택이 포함됩니다. Quick Sort와 같은 효율적인 알고리즘을 활용하여 계산 시간을 단축합니다. 여러 작업을 제거하여 이중 계산을 줄입니다. 불필요한 계산을 피하려면 조건부 분기를 사용하세요. 이진 검색과 같은 더 빠른 알고리즘을 사용하여 선형 검색을 최적화합니다.

PHP 문자열 조작: 공백을 효과적으로 제거하는 실용적인 방법 PHP 문자열 조작: 공백을 효과적으로 제거하는 실용적인 방법 Mar 24, 2024 am 11:45 AM

PHP 문자열 작업: 공백을 효과적으로 제거하는 실용적인 방법 PHP 개발 시 문자열에서 공백을 제거해야 하는 상황에 자주 직면하게 됩니다. 공백을 제거하면 문자열이 더 깔끔해지고 후속 데이터 처리 및 표시가 쉬워집니다. 이 기사에서는 공백을 제거하는 몇 가지 효과적이고 실용적인 방법을 소개하고 구체적인 코드 예제를 첨부합니다. 방법 1: PHP 내장 함수인 Trim()을 사용합니다. PHP 내장 함수인 Trim()을 사용하면 문자열 양쪽 끝의 공백(공백, 탭, 개행 등 포함)을 제거할 수 있어 매우 편리하고 쉽습니다. 사용.

Ele.me에서 WeChat을 연결하는 방법 Ele.me에서 WeChat을 연결하는 방법 Apr 01, 2024 pm 03:46 PM

Ele.me는 다양한 종류의 음식을 온라인으로 선택하고 주문할 수 있는 소프트웨어입니다. 판매자는 주문을 받은 후 즉시 주문을 처리합니다. 사용자는 소프트웨어를 통해 WeChat을 연결할 수 있습니다. 작동 방법을 알아보려면 PHP 중국어 웹사이트를 확인하세요. Ele.me를 WeChat에 바인딩하는 방법: 1. 먼저 Ele.me 소프트웨어를 열고 홈페이지에 들어간 후 오른쪽 하단에 있는 [내]를 클릭합니다. 2. 그런 다음 내 페이지에서 [계정]을 클릭합니다. ] 왼쪽 상단에 있는 3. 그런 다음 휴대폰, WeChat, Alipay 및 Taobao를 연결할 수 있는 개인 정보 페이지로 이동합니다. 4. 마지막 클릭 후 필요한 WeChat 계정을 선택합니다. WeChat 인증 페이지에 접속하고 [허용]을 클릭하세요.

Astar 스테이킹 원칙, 수입 해체, 에어드랍 프로젝트 및 전략 및 운영 보모 수준 전략 Astar 스테이킹 원칙, 수입 해체, 에어드랍 프로젝트 및 전략 및 운영 보모 수준 전략 Jun 25, 2024 pm 07:09 PM

목차 Astar Dapp 스테이킹 원리 스테이킹 수익 잠재적 에어드랍 프로젝트 해체: AlgemNeurolancheHealThreeAstar Degens DAOVeryLongSwap 스테이킹 전략 및 운영 "AstarDapp 스테이킹"이 올해 초 V3 버전으로 업그레이드되었으며 스테이킹 수익에 많은 조정이 이루어졌습니다. 규칙. 현재 첫 번째 스테이킹 주기는 종료되었으며 두 번째 스테이킹 주기의 "투표" 하위 주기가 막 시작되었습니다. '추가 보상' 혜택을 받으려면 이 중요한 단계(6월 26일까지 지속 예정, 5일 미만 남았음)를 파악해야 합니다. 아스타 스테이킹 수익을 자세하게 분석해보겠습니다.

WIN7 시스템의 시작 항목을 최적화하는 방법 WIN7 시스템의 시작 항목을 최적화하는 방법 Mar 26, 2024 pm 06:20 PM

1. 바탕화면에서 키조합(Win키 + R)을 눌러 실행창을 연 후, [regedit]를 입력하고 Enter를 눌러 확인하세요. 2. 레지스트리 편집기를 연 후 [HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorer]를 클릭하여 확장한 다음 디렉터리에 Serialize 항목이 있는지 확인합니다. 없으면 탐색기를 마우스 오른쪽 버튼으로 클릭하고 새 항목을 생성한 다음 이름을 Serialize로 지정합니다. 3. 그런 다음 직렬화를 클릭한 다음 오른쪽 창의 빈 공간을 마우스 오른쪽 버튼으로 클릭하고 새 DWORD(32) 비트 값을 만들고 이름을 Star로 지정합니다.

Win8 컴퓨터 시작 비밀번호를 잊으셨나요? 이 작업을 수행하면 즉시 복원됩니다! Win8 컴퓨터 시작 비밀번호를 잊으셨나요? 이 작업을 수행하면 즉시 복원됩니다! Mar 27, 2024 pm 10:12 PM

Win8 컴퓨터 시작 암호를 잊어버리는 것은 많은 사람들이 매일 컴퓨터를 사용할 때 직면하는 문제입니다. 로그인 비밀번호를 잊어버리면 정상적으로 시스템에 진입할 수 없어 일상적인 사용에 불편을 겪게 됩니다. 이 문제가 발생하더라도 걱정하지 마십시오. 아래에서는 Win8 컴퓨터의 시동 암호를 신속하게 복원하는 데 도움이 되는 몇 가지 간단한 작업을 소개합니다. 방법 1: Microsoft 계정 비밀번호 사용 Microsoft 계정을 사용하여 Win8 컴퓨터에 로그인하는 경우 해당 계정의 비밀번호를 사용해 볼 수 있습니다.

See all articles