oracle的complex,Oracle 10g的隐含参数_complex_view_merging引发的性能问题

最新推荐文章于 2021-04-07 11:30:52 发布
最新推荐文章于 2021-04-07 11:30:52 发布
阅读量335 收藏
点赞数
文章标签： oracle的complex

今天在Oracle 10g上碰到一个奇怪的问题，有一条sql在数据库1上很快，在数据库2上很慢，数据库2的数据是从数据库1上导的，数据量差不多。

在数据库1上执行0.01s。

SQL> SELECT A.*,

2        B.INCREASE_ID,

3        B.TRANSACTION_ID,

4        B.LINK_CARD_ID,

5        B.VALIDATE_FLAG,

6        B.ASSET_VALUE_SHARING,

7        B.RELATED_DEVICE_ID,

8        B.PARENT_CARD_CODE,

9        B.PROJECT_VALUE,

10        B.DELETE_FLAG,

11        B.DEPRECIATION_ADJUST_VALUE,

12        T.TRANSACTION_MODE_CODE,

13        T.TRANSACTION_NO,

14        T.TRANSACTION_FROM,

15        T.FROM_MODEL,

16        (SELECT T.FULL_PATH

17            FROM AM_TECH_OBJECT_NODE_0900 T

18          WHERE T.TECH_OBJECT_ID = A.DEVICE_ID

19            AND T.NODE_TYPE = 2

20            AND ROWNUM = 1) AS FULL_PATH,

21        AAC.FULL_NAME CLASSIFY_FULL_PATH

22    FROM V_ASSET_CARD_0900      A,

23        GG_ASSET_INCREASE_ITEM B,

24        GG_ASSET_TRANSACTION  T,

25        AM_ASSET_CLASSIFY      AAC

26  WHERE A.CARD_ID = B.CARD_ID

27    AND B.TRANSACTION_ID = T.TRANSACTION_ID

28    AND A.CLASSIFY_ID = AAC.DEVICE_CLASSIFY_ID(+)

29    AND B.TRANSACTION_ID = '0101109514';

已用时间:  00: 00: 00.01

执行计划

----------------------------------------------------------

Plan hash value: 3643758043

-------------------------------------------------------------------------------------------------------------------

| Id  | Operation                        | Name                          | Rows  | Bytes | Cost (%CPU)| Time    |

-------------------------------------------------------------------------------------------------------------------

|  0 | SELECT STATEMENT                |                                |    21 | 24129 |  167  (0)| 00:00:03 |

|*  1 |  COUNT STOPKEY                  |                                |      |      |            |          |

|  2 |  TABLE ACCESS BY INDEX ROWID    | AM_TECH_OBJECT_NODE_0900      |    1 |    73 |    4  (0)| 00:00:01 |

|*  3 |    INDEX RANGE SCAN              | IDX_TECH_NODE_ID_0900          |    1 |      |    3  (0)| 00:00:01 |

|  4 |  NESTED LOOPS OUTER              |                                |    21 | 24129 |  167  (0)| 00:00:03 |

|  5 |  NESTED LOOPS                  |                                |    21 | 22533 |  146  (0)| 00:00:02 |

|  6 |    NESTED LOOPS                  |                                |    20 | 12700 |  106  (0)| 00:00:02 |

|  7 |    NESTED LOOPS                |                                |    20 | 10900 |    46  (0)| 00:00:01 |

|  8 |      NESTED LOOPS                |                                |    20 |  2000 |    6  (0)| 00:00:01 |

|  9 |      TABLE ACCESS BY INDEX ROWID| GG_ASSET_TRANSACTION          |    1 |    42 |    2  (0)| 00:00:01 |

|* 10 |        INDEX UNIQUE SCAN        | PK_GG_ASSET_TRANSACTION        |    1 |      |    1  (0)| 00:00:01 |

|  11 |      TABLE ACCESS BY INDEX ROWID| GG_ASSET_INCREASE_ITEM        |    20 |  1160 |    4  (0)| 00:00:01 |

|* 12 |        INDEX RANGE SCAN          | TRANSACTION_DETAIL_REF_TRANSAC |    20 |      |    1  (0)| 00:00:01 |

|  13 |      TABLE ACCESS BY INDEX ROWID | GG_ASSET_CARD_0900            |    1 |  445 |    2  (0)| 00:00:01 |

|* 14 |      INDEX UNIQUE SCAN          | PK_GG_ASSET_CARD_0303          |    1 |      |    1  (0)| 00:00:01 |

|  15 |    TABLE ACCESS BY INDEX ROWID  | GG_ASSET_VALUE_0900            |    1 |    90 |    3  (0)| 00:00:01 |

|* 16 |      INDEX RANGE SCAN            | ID_FAV_CARD_VALIDITY_0303      |    1 |      |    2  (0)| 00:00:01 |

|  17 |    TABLE ACCESS BY INDEX ROWID  | AM_ASSET_0900                  |    1 |  438 |    2  (0)| 00:00:01 |

|* 18 |    INDEX UNIQUE SCAN            | PK_AM_ASSET_0900              |    1 |      |    1  (0)| 00:00:01 |

|  19 |  TABLE ACCESS BY INDEX ROWID    | AM_ASSET_CLASSIFY              |    1 |    76 |    1  (0)| 00:00:01 |

|* 20 |    INDEX UNIQUE SCAN            | PK_AM_ASSET_CLASSIFY          |    1 |      |    0  (0)| 00:00:01 |

-------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter(ROWNUM=1)

3 - access("T"."TECH_OBJECT_ID"=:B1 AND "T"."NODE_TYPE"=2)

10 - access("T"."TRANSACTION_ID"='0101109514')

12 - access("B"."TRANSACTION_ID"='0101109514')

14 - access("GG_ASSET_CARD"."CARD_ID"="B"."CARD_ID")

16 - access("GG_ASSET_VALUE"."CARD_ID"="GG_ASSET_CARD"."CARD_ID" AND

"GG_ASSET_VALUE"."VALIDITY_DATE_END"="GG_ASSET_CARD"."DECREASE_DATE")

18 - access("AM_ASSET"."DEVICE_ID"="GG_ASSET_CARD"."DEVICE_ID")

20 - access("AM_ASSET"."CLASSIFY_ID"="AAC"."DEVICE_CLASSIFY_ID"(+))

统计信息

----------------------------------------------------------

8  recursive calls

0  db block gets

28  consistent gets

0  physical reads

0  redo size

12384  bytes sent via SQL*Net to client

338  bytes received via SQL*Net from client

2  SQL*Net roundtrips to/from client

0  sorts (memory)

0  sorts (disk)

1  rows processed

在数据库2上很慢，27.48s

SQL> SELECT A.*,

2        B.INCREASE_ID,

3        B.TRANSACTION_ID,

4        B.LINK_CARD_ID,

5        B.VALIDATE_FLAG,

6        B.ASSET_VALUE_SHARING,

7        B.RELATED_DEVICE_ID,

8        B.PARENT_CARD_CODE,

9        B.PROJECT_VALUE,

10        B.DELETE_FLAG,

11        B.DEPRECIATION_ADJUST_VALUE,

12        T.TRANSACTION_MODE_CODE,

13        T.TRANSACTION_NO,

14        T.TRANSACTION_FROM,

15        T.FROM_MODEL,

16        (SELECT T.FULL_PATH

17            FROM AM_TECH_OBJECT_NODE_0900 T

18          WHERE T.TECH_OBJECT_ID = A.DEVICE_ID

19            AND T.NODE_TYPE = 2

20            AND ROWNUM = 1) AS FULL_PATH,

21        AAC.FULL_NAME CLASSIFY_FULL_PATH

22    FROM V_ASSET_CARD_0900      A,

23        GG_ASSET_INCREASE_ITEM B,

24        GG_ASSET_TRANSACTION  T,

25        AM_ASSET_CLASSIFY      AAC

26  WHERE A.CARD_ID = B.CARD_ID

27    AND B.TRANSACTION_ID = T.TRANSACTION_ID

28    AND A.CLASSIFY_ID = AAC.DEVICE_CLASSIFY_ID(+)

29    AND B.TRANSACTION_ID = '0101109514';

已选择200行。

已用时间:  00: 00: 27.48

执行计划

----------------------------------------------------------

Plan hash value: 2944357796

-------------------------------------------------------------------------------------------------------------------------

| Id  | Operation                      | Name                          | Rows  | Bytes |TempSpc| Cost (%CPU)| Time    |

-------------------------------------------------------------------------------------------------------------------------

|  0 | SELECT STATEMENT              |                                |    25 |  255K|      | 45815  (1)| 00:09:10 |

|*  1 |  COUNT STOPKEY                |                                |      |      |      |        |            |

|  2 |  TABLE ACCESS BY INDEX ROWID  | AM_TECH_OBJECT_NODE_0900      |    1 |    75 |      |    4  (0)| 00:00:01 |

|*  3 |    INDEX RANGE SCAN            | IDX_TECH_NODE_ID_0900          |    1 |      |      |    3  (0)| 00:00:01 |

|  4 |  NESTED LOOPS OUTER            |                                |    25 |  255K|      | 45815  (1)| 00:09:10 |

|*  5 |  HASH JOIN                    |                                |    25 |  253K|      | 45790  (1)| 00:09:10 |

|  6 |    NESTED LOOPS                |                                |    25 |  2750 |      |    6  (0)| 00:00:01 |

|  7 |    TABLE ACCESS BY INDEX ROWID| GG_ASSET_TRANSACTION          |    1 |    53 |      |    2  (0)| 00:00:01 |

|*  8 |      INDEX UNIQUE SCAN        | PK_GG_ASSET_TRANSACTION        |    1 |      |      |    1  (0)| 00:00:01 |

|  9 |    TABLE ACCESS BY INDEX ROWID| GG_ASSET_INCREASE_ITEM        |    25 |  1425 |      |    4  (0)| 00:00:01 |

|* 10 |      INDEX RANGE SCAN          | TRANSACTION_DETAIL_REF_TRANSAC |    25 |      |      |    1  (0)| 00:00:01 |

|  11 |    VIEW                        | V_ASSET_CARD_0900              |  280K|  2744M|      | 45781  (1)| 00:09:10 |

|* 12 |    HASH JOIN                  |                                |  280K|  257M|  141M| 45781  (1)| 00:09:10 |

|* 13 |      HASH JOIN                |                                |  274K|  137M|    27M| 12222  (1)| 00:02:27 |

|  14 |      TABLE ACCESS FULL        | GG_ASSET_VALUE_0900            |  292K|    24M|      |  910  (2)| 00:00:11 |

|  15 |      TABLE ACCESS FULL        | GG_ASSET_CARD_0900            |  274K|  114M|      |  4073  (1)| 00:00:49 |

|  16 |      TABLE ACCESS FULL        | AM_ASSET_0900                  |  756K|  315M|      | 10464  (1)| 00:02:06 |

|  17 |  TABLE ACCESS BY INDEX ROWID  | AM_ASSET_CLASSIFY              |    1 |    76 |      |    1  (0)| 00:00:01 |

|* 18 |    INDEX UNIQUE SCAN          | PK_AM_ASSET_CLASSIFY          |    1 |      |      |    0  (0)| 00:00:01 |

-------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter(ROWNUM=1)

3 - access("T"."TECH_OBJECT_ID"=:B1 AND "T"."NODE_TYPE"=2)

5 - access("A"."CARD_ID"="B"."CARD_ID")

8 - access("T"."TRANSACTION_ID"='0101109514')

10 - access("B"."TRANSACTION_ID"='0101109514')

12 - access("AM_ASSET"."DEVICE_ID"="GG_ASSET_CARD"."DEVICE_ID")

13 - access("GG_ASSET_VALUE"."CARD_ID"="GG_ASSET_CARD"."CARD_ID" AND

"GG_ASSET_VALUE"."VALIDITY_DATE_END"="GG_ASSET_CARD"."DECREASE_DATE")

18 - access("A"."CLASSIFY_ID"="AAC"."DEVICE_CLASSIFY_ID"(+))

统计信息

----------------------------------------------------------

218  recursive calls

0  db block gets

70112  consistent gets

26412  physical reads

348  redo size

38174  bytes sent via SQL*Net to client

480  bytes received via SQL*Net from client

15  SQL*Net roundtrips to/from client

0  sorts (memory)

0  sorts (disk)

200  rows processed

第一次诊断：起初觉得应该是索引的集群因子的问题，检查了下，差不多。

第二次诊断：感觉是环境、参数不一样引起，开始试验。

使用视图v$sql和v$sql_plan、dbms_xplan.display_cursor查出sql真实的执行计划。

select distinct s.SQL_ID, s.HASH_VALUE, s.CHILD_NUMBER, s.SQL_TEXT

from v$sql s, v$sql_plan p

where s.SQL_ID = p.SQL_ID

and p.PLAN_HASH_VALUE = '3643758043';

select * from table(dbms_xplan.display_cursor(150270666, 0, 'advanced'));

性能慢的数据库：

/*+

BEGIN_OUTLINE_DATA

IGNORE_OPTIM_EMBEDDED_HINTS

OPTIMIZER_FEATURES_ENABLE('10.2.0.4')

OPT_PARAM('_complex_view_merging' 'false')

ALL_ROWS

............省略............

*/

性能快的数据库：

/*+

BEGIN_OUTLINE_DATA

IGNORE_OPTIM_EMBEDDED_HINTS

OPTIMIZER_FEATURES_ENABLE('10.2.0.4')

ALL_ROWS

............省略............

*/

看到两个执行的大纲有点不同，于是到两个数据库中查这个_complex_view_merging这个隐含参数，性能慢的数据库设置为false,性能快的数据库的设置则为true。

SQL语句中是有视图的，莫非这个隐含参数有问题，按字面的意思是复杂视图的合并，抱着试一试的心情调整了下这个参数：

alter session set "_complex_view_merging" = true;

结果非常快，0.6s。

SQL> SELECT A.*,

2        B.INCREASE_ID,

3        B.TRANSACTION_ID,

4        B.LINK_CARD_ID,

5        B.VALIDATE_FLAG,

6        B.ASSET_VALUE_SHARING,

7        B.RELATED_DEVICE_ID,

8        B.PARENT_CARD_CODE,

9        B.PROJECT_VALUE,

10        B.DELETE_FLAG,

11        B.DEPRECIATION_ADJUST_VALUE,

12        T.TRANSACTION_MODE_CODE,

13        T.TRANSACTION_NO,

14        T.TRANSACTION_FROM,

15        T.FROM_MODEL,

16        (SELECT T.FULL_PATH

17            FROM sz_1230.AM_TECH_OBJECT_NODE_0900 T

18          WHERE T.TECH_OBJECT_ID = A.DEVICE_ID

19            AND T.NODE_TYPE = 2

20            AND ROWNUM = 1) AS FULL_PATH,

21        AAC.FULL_NAME CLASSIFY_FULL_PATH

22    FROM sz_1230.V_ASSET_CARD_0900      A,

23        sz_1230.FM_ASSET_INCREASE_ITEM B,

24        sz_1230.FM_ASSET_TRANSACTION  T,

25        sz_1230.AM_ASSET_CLASSIFY      AAC

26  WHERE A.CARD_ID = B.CARD_ID

27    AND B.TRANSACTION_ID = T.TRANSACTION_ID

28    AND A.CLASSIFY_ID = AAC.DEVICE_CLASSIFY_ID(+)

29    AND B.TRANSACTION_ID = '0101109514';

已选择200行。

已用时间:  00: 00: 00.06

执行计划

----------------------------------------------------------

Plan hash value: 801438153

-------------------------------------------------------------------------------------------------------------------

| Id  | Operation                        | Name                          | Rows  | Bytes | Cost (%CPU)| Time    |

-------------------------------------------------------------------------------------------------------------------

|  0 | SELECT STATEMENT                |                                |    25 | 28475 |  206  (0)| 00:00:03 |

|*  1 |  COUNT STOPKEY                  |                                |      |      |            |          |

|  2 |  TABLE ACCESS BY INDEX ROWID    | AM_TECH_OBJECT_NODE_0900      |    1 |    75 |    4  (0)| 00:00:01 |

|*  3 |    INDEX RANGE SCAN              | IDX_TECH_NODE_ID_0900          |    1 |      |    3  (0)| 00:00:01 |

|  4 |  NESTED LOOPS                    |                                |    25 | 28475 |  206  (0)| 00:00:03 |

|  5 |  NESTED LOOPS OUTER            |                                |    25 | 26275 |  131  (0)| 00:00:02 |

|  6 |    NESTED LOOPS                  |                                |    25 | 24375 |  106  (0)| 00:00:02 |

|  7 |    NESTED LOOPS                |                                |    25 | 13425 |    56  (0)| 00:00:01 |

|  8 |      NESTED LOOPS                |                                |    25 |  2475 |    6  (0)| 00:00:01 |

|  9 |      TABLE ACCESS BY INDEX ROWID| FM_ASSET_TRANSACTION          |    1 |    42 |    2  (0)| 00:00:01 |

|* 10 |        INDEX UNIQUE SCAN        | PK_FM_ASSET_TRANSACTION        |    1 |      |    1  (0)| 00:00:01 |

|  11 |      TABLE ACCESS BY INDEX ROWID| FM_ASSET_INCREASE_ITEM        |    25 |  1425 |    4  (0)| 00:00:01 |

|* 12 |        INDEX RANGE SCAN          | TRANSACTION_DETAIL_REF_TRANSAC |    25 |      |    1  (0)| 00:00:01 |

|  13 |      TABLE ACCESS BY INDEX ROWID | FM_ASSET_CARD_0900            |    1 |  438 |    2  (0)| 00:00:01 |

|* 14 |      INDEX UNIQUE SCAN          | PK_FM_ASSET_CARD_0303          |    1 |      |    1  (0)| 00:00:01 |

|  15 |    TABLE ACCESS BY INDEX ROWID  | AM_ASSET_0900                  |    1 |  438 |    2  (0)| 00:00:01 |

|* 16 |      INDEX UNIQUE SCAN          | PK_AM_ASSET_0900              |    1 |      |    1  (0)| 00:00:01 |

|  17 |    TABLE ACCESS BY INDEX ROWID  | AM_ASSET_CLASSIFY              |    1 |    76 |    1  (0)| 00:00:01 |

|* 18 |    INDEX UNIQUE SCAN            | PK_AM_ASSET_CLASSIFY          |    1 |      |    0  (0)| 00:00:01 |

|  19 |  TABLE ACCESS BY INDEX ROWID    | FM_ASSET_VALUE_0900            |    1 |    88 |    3  (0)| 00:00:01 |

|* 20 |    INDEX RANGE SCAN              | ID_FAV_CARD_VALIDITY_0303      |    1 |      |    2  (0)| 00:00:01 |

-------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter(ROWNUM=1)

3 - access("T"."TECH_OBJECT_ID"=:B1 AND "T"."NODE_TYPE"=2)

10 - access("T"."TRANSACTION_ID"='0101109514')

12 - access("B"."TRANSACTION_ID"='0101109514')

14 - access("FM_ASSET_CARD"."CARD_ID"="B"."CARD_ID")

16 - access("AM_ASSET"."DEVICE_ID"="FM_ASSET_CARD"."DEVICE_ID")

18 - access("AM_ASSET"."CLASSIFY_ID"="AAC"."DEVICE_CLASSIFY_ID"(+))

20 - access("FM_ASSET_VALUE"."CARD_ID"="FM_ASSET_CARD"."CARD_ID" AND

"FM_ASSET_VALUE"."VALIDITY_DATE_END"="FM_ASSET_CARD"."DECREASE_DATE")

统计信息

----------------------------------------------------------

0  recursive calls

0  db block gets

3029  consistent gets

0  physical reads

0  redo size

38039  bytes sent via SQL*Net to client

480  bytes received via SQL*Net from client

15  SQL*Net roundtrips to/from client

0  sorts (memory)

0  sorts (disk)

200  rows processed

于是将_complex_view_merging全局设置为true, alter system set "_complex_view_merging" = true scope=both;

再看了下其他的oracle 10g的数据库设置都是为true,应该是安装数据库的问题。

0b1331709591d260c1c78e86d0c51c18.png

weixin_39873741
关注
视图合并（View Merging）
Laughing
07-29 8193
在使用视图或嵌套视图的查询语句中，oracle 为了取得最优的执行计划会将这些视图进行合并，将视图中的表与外部查询的表进行连接。 --示例： SQL> select e.first_name, e.last_name, dept_locs_v.street_address, dept_locs_v.postal_code 2 from employees e, 3 (s
oracle optimizer_features_enable,【SQL 性能优化】参数设置
weixin_42324002的博客
04-05 808
QL> select * from v$version;BANNER----------------------------------------------------------------Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64biPL/SQL Release 10.2.0.4.0 - Product...
ORACLE SQL调优之执行计划与隐藏参数_complex_view_merging
clm20482的博客
05-24 462
最近，赤峰windows 版的11.2.0.3的oracle数据库出现一条sql语句执行非常慢，需要1天的时间还出不来，但是观察服务器的IO和CPU都是很空闲，并且将 该sql语句涉及的对象全部导出，然后分别导入其他机...
oracle执行计划px,ORACLE SQL调优之执行计划与隐藏参数_complex_view_merging
weixin_31495827的博客
04-04 479
最近，赤峰windows 版的11.2.0.3的oracle数据库出现一条sql语句执行非常慢，需要1天的时间还出不来，但是观察服务器的IO和CPU都是很空闲，并且将该sql语句涉及的对象全部导出，然后分别导入其他机器oracle数据库与出现性能问题的数据库，发现其他机器数据库执行非常快而问题数据库依旧很慢。尝试收集方案及表的统计信息后，再次执行sql语句还是没有改善，在问题处理的过程中，注意到一...
oracle 10g的隐含参数_complex_view_merging引发的性能问题
关注系统性能调优
03-03 2955
今天在oracle10g上碰到一个奇怪的问题，有一条sql在数据库1上很快，在数据库2上很慢，数据库2的数据是从数据库1上导的，数据量差不多。 在数据库1上执行0.01s。 SQL> SELECT A.*,   2         B.INCREASE_ID,   3         B.TRANSACTION_ID,   4         B.LINK_CARD_ID,   5
_complex_view_merging对执行计划的影响
12-09 442
以下是在10.2.0.1版本下测试，以下实验来着于Jonathan Lewis 《CBO》。1、创建测试表SQL>create table t1 ( id_par numb...
srg.rar_Region merging_SRG
09-19
为了克服这些问题，后续的研究者通常会结合其他的图像处理技术，如边缘检测、形态学操作或者深度学习方法，来提升SRG的性能。例如，可以先用Canny边缘检测或Sobel算子找出图像的初步边界，再进行区域合并，这样可以...
图象合并程序.rar_bmp 256_image merging_图象合并
09-14
在IT领域，图象处理是不可或缺的一部分，而“图象合并程序.rar_bmp 256_image merging_图象合并”这个压缩包显然涉及到的是一个专门用于合并256色BMP图像的软件或代码资源。BMP，全称为Bitmap，是一种常见的位图图像...
RegionGrow.rar_matlab region grow_matlab regiongr_region-merging
07-15
区域生长的matlab源码 region grow
oracle all_tab_columns,[20120507]视图all_tab_columns的定义问题.txt
weixin_32672675的博客
04-07 2077
[20120507]视图all_tab_columns的定义问题.txt生产系统我发现一个问题，开发人员在使用pb9.0维护时要调用如下类似的语句：SELECT synonym_nameFROM SYS.all_synonyms s, SYS.all_tab_columns tWHERE s.owner IN ('SCOTT', 'PUBLIC')AND s.synonym_name = 'DEP...
oracle的查询转换之复杂视图合并
cty48663的博客
12-08 292
本文参考链接：https://blogs.oracle.com/optimizer/entry/optimizer_transformations_view_merging_part_2 Complex vie...
测试 达梦 complex_view_merging
cujiaowu9180的博客
01-14 189
select object_id from test_obj1 a left join(select sum(DATA_OBJECT_ID) sm,b.object_id from test_obj1 b group by b...
View Merging
cr13324309138的博客
06-20 179
1.定义： The purpose of view merging is to reduce the number of query blocks due to views and inline views ...
ORA-01732: 此视图的数据操纵操作非法 解决方案 oracle10g
热门推荐
dacong的专栏
12-17 4万+
ORA-01732: 此视图的数据操纵操作非法 解决方案， ORA-01732: data manipulation operation not legal on this view Oracle 10g的隐含参数_complex_view_merging引发的性能问题
海量数据库解决方案之视图合并应用原理
congxiebiao5773的博客
06-14 183
为了让视图或嵌套视图按照最优化的方式执行，可能需要对其进行必要的转换，下面我们就针对具体的转换方法予以详细说明。虽然这里的内容有些费解，但是它在帮助我们深刻理解执行计划方面有着非常大的作用。在这里我们将把视图查询分为两类：视...
oracle 11.2.0.3 隐含参数
Lixora's DB Home
11-09 2180
System Parameters with Non-Default or Modified Values Collected from GV$SYSTEM_PARAMETER2 where isdefault = 'FALSE' OR ismodified != 'FALSE'. "Is Default" = FALSE means the parameter was set in t
基于Oracle的SQL优化--学习（十五）
qq_34409900的博客
07-05 483
复杂视图合并    复杂视图合并（ComplexViewMerging)是指针对那些所带视图的视图定义SQL语句中含有groupby或distinct的目标SQL的视图合并。    和简单视图合并、外连接视图合并一样，对这种视图定义SQL语句中含有groupby或distinct的复杂视图做视图合并也同样意味着要把其定义SQL语句拆开，并把其中的基表拿出来和外部査询中的表合并。这通常意味着上述视图...
Oracle Warehouse Builder 11g入门教程：设计ETL数据流映射
Oracle Warehouse Builder (OWB) 11g 是一个强大的数据仓库解决方案，旨在简化企业级数据集成和ETL（提取、转换、加载）过程。本教程Part 4是该系列教程的一部分，由作者根据Oracle官方文档进行翻译，旨在帮助读者...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值