Oracle三组难缠的hint no_unnest/unnest，push_subq，push_pred--平展化(转)

经常有人把这三个hint搞混，主如果因为对三种重写道理不清楚。特总结如下。（实验景象为10204）
1. no_unnest， unnest
unnest我们称为对子查询展开，顾名思义，就是别让子查询孤单地嵌套（nest）在里面。
所以un_unnest双重否定代表必然，即让子查询不展开，让它嵌套（nest）在里面。
现做一个简单的实验：
create table hao1 as * dba_objects;
create table hao2 as * dba_objects;
analyze table hao1 compute statistics;
analyze table hao2 compute statistics;
SQL> hao1.object_id hao1 where exists
2 （ 1 hao2 where hao1.object_id=hao2.object_id*10）;
1038 rows ed.

ution Plan
----------------------------------------------------------
Plan hash value: 2662903432
---------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost （％CPU）| Time |
---------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 8 | 80 （3）| 00:00:01 |
|* 1 | HASH JOIN SEMI | | 1 | 8 | 80 （3）| 00:00:01 |
| 2 | TABLE ACCESS FULL| HAO1 | 10662 | 42648 | 40 （3）| 00:00:01 |
| 3 | TABLE ACCESS FULL| HAO2 | 10663 | 42652 | 40 （3）| 00:00:01 |
---------------------------------------------------------------------------
Predicate Information （identified by operation id）:
---------------------------------------------------
1 - access（"HAO1"."OBJECT_ID"="HAO2"."OBJECT_ID"*10）

Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
352 consistent gets
0 physical reads
0 redo size
18715 bytes sent via SQL*Net to client
1251 bytes received via SQL*Net client
71 SQL*Net roundtrips to/ client
0 sorts （memory）
0 sorts （disk）
1038 rows processed

这里子查询主动展开（unnest），即HAO2和HAO1 hash join在一路。
接下来若是我们不HAO2展开，想先让它零丁的履行完，然后再来和外部查询进行一种叫做FILTER的操纵。
那么我们参加hint no_unnest:
SQL> hao1.object_id hao1 where exists
2 （ /*+no_unnest*/ 1 hao2 where hao1.object_id=hao2.object_id*10）;
1038 rows ed.

ution Plan
----------------------------------------------------------
Plan hash value: 2565749733
---------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost （％CPU）| Time |
---------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 4 | 10750 （1）| 00:01:48 |
|* 1 | FILTER | | | | | |
| 2 | TABLE ACCESS FULL| HAO1 | 10662 | 42648 | 40 （3）| 00:00:01 |
|* 3 | TABLE ACCESS FULL| HAO2 | 1 | 4 | 2 （0）| 00:00:01 |
---------------------------------------------------------------------------
Predicate Information （identified by operation id）:
---------------------------------------------------
1 - filter（ EXISTS （SELECT /*+ NO_UNNEST */ 0 FROM "HAO2" "HAO2"
WHERE "HAO2"."OBJECT_ID"*10=:B1））
3 - filter（"HAO2"."OBJECT_ID"*10=:B1）

Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
1369157 consistent gets
0 physical reads
0 redo size
18715 bytes sent via SQL*Net to client
1251 bytes received via SQL*Net client
71 SQL*Net roundtrips to/ client
0 sorts （memory）
0 sorts （disk）
1038 rows processed
这里HAO1和HAO2进行了一种FILTER操纵，这个操纵在《Cost Based Oracle Fundamental》此书第九章有介绍。他其实很像我们熟悉的neested loop，但它的独特之处在于会保护一个hash table。
举例，若是HAO1里取出object_id=1，那么对于HAO2来说即 1 hao2 where hao2.object_id*10=1，若是前提满足，那么对于子查询，输入输出对，即为（1（HAO1.object_id），1（常量））。
他存储在hash table里，并且因为前提满足，HAO1.object_id=1被放入成果集。
然后接着从HAO1取出object_id=2，若是子查询依旧前提满足，那么子查询产生另一个输入和输出，即（2，1），被放入hash table里；并且HAO1.object_id=2被放入成果集。
接着假设HAO1里有反复的object_id，例如我们第三次从HAO1取出的object_id=2，那么因为我们对于子查询来说，已经有输入输出对（2，1）在hash table里了，所以就不消去再次全表扫描HAO2了，ORACLE很是聪慧地知道object_id=2是成果集。这里，filter和neested loop比拟，省去了一次全表扫描HAO2。
这个hash table是有大小限制的，当被占满的时辰，后续新的HAO1.object_id的FILTER就类似neested loop了。
由此可见，从buffer gets层面上来看，FILTER是应当优于neested loop的，尤其当外部查询须要传递给子查询的输入（此例中为HAO1.object_id）的distinct value很是小时，FILTER就会显得更优。
即使在我这个例子中，HAO1.object_id的distinct value上万，我对比了一下neested loop，FILTER仍然略优：
SQL> /*+use_nl（hao1 hao2）*/ hao1.object_id hao1，hao2 where hao1.object_id=hao2.object_id*10;

1038 rows ed.

ution Plan
----------------------------------------------------------
Plan hash value: 251947914
---------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost （％CPU）| Time |
---------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 10663 | 85304 | 404K （2）| 01:07:23 |
| 1 | NESTED LOOPS | | 10663 | 85304 | 404K （2）| 01:07:23 |
| 2 | TABLE ACCESS FULL| HAO1 | 10662 | 42648 | 40 （3）| 00:00:01 |
|* 3 | TABLE ACCESS FULL| HAO2 | 1 | 4 | 38 （3）| 00:00:01 |
---------------------------------------------------------------------------
Predicate Information （identified by operation id）:
---------------------------------------------------
3 - filter（"HAO1"."OBJECT_ID"="HAO2"."OBJECT_ID"*10）

Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
1503621 consistent gets
0 physical reads
0 redo size
18715 bytes sent via SQL*Net to client
1251 bytes received via SQL*Net client
71 SQL*Net roundtrips to/ client
0 sorts （memory）
0 sorts （disk）
1038 rows processed
FILTER的consistent gets是1369157，neested loop的consistent gets是1503621。
若是我们验证我前面的结论，我们可以用distinct value较小的object_type来做个类似的对比实验。
SQL> hao1.object_id hao1 where exists
2 （ /*+no_unnest*/ 1 hao2 where hao1.object_type=hao2.object_type）;
10662 rows ed.

ution Plan
----------------------------------------------------------
Plan hash value: 2565749733
---------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost （％CPU）| Time |
---------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 288 | 3168 | 114 （1）| 00:00:02 |
|* 1 | FILTER | | | | | |
| 2 | TABLE ACCESS FULL| HAO1 | 10662 | 114K| 40 （3）| 00:00:01 |
|* 3 | TABLE ACCESS FULL| HAO2 | 2 | 14 | 2 （0）| 00:00:01 |
---------------------------------------------------------------------------
Predicate Information （identified by operation id）:
---------------------------------------------------
1 - filter（ EXISTS （SELECT /*+ NO_UNNEST */ 0 FROM "HAO2" "HAO2"
WHERE "HAO2"."OBJECT_TYPE"=:B1））
3 - filter（"HAO2"."OBJECT_TYPE"=:B1）

Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
17012 consistent gets
0 physical reads
0 redo size
187491 bytes sent via SQL*Net to client
8302 bytes received via SQL*Net client
712 SQL*Net roundtrips to/ client
0 sorts （memory）
0 sorts （disk）
10662 rows processed
可见，同样是HAO1和HAO2的全表扫描后的FILTER操纵，却因为传给子查询的输入的distinct value的差别，两者相差的consistent gets却如此重大，这跟neested loop是完全不一样的。
当然，对于如此的两个全表扫描的成果集，应用hash join是最佳办法。
SQL> hao1.object_id hao1 where exists
2 （ 1 hao2 where hao1.object_type=hao2.object_type）;
10662 rows ed.

ution Plan
----------------------------------------------------------
Plan hash value: 3371915275
-----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost （％CPU）| Time |
-----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 10662 | 187K| 81 （4）| 00:00:01 |
|* 1 | HASH JOIN RIGHT SEMI| | 10662 | 187K| 81 （4）| 00:00:01 |
| 2 | TABLE ACCESS FULL | HAO2 | 10663 | 74641 | 40 （3）| 00:00:01 |
| 3 | TABLE ACCESS FULL | HAO1 | 10662 | 114K| 40 （3）| 00:00:01 |
-----------------------------------------------------------------------------
Predicate Information （identified by operation id）:
---------------------------------------------------
1 - access（"HAO1"."OBJECT_TYPE"="HAO2"."OBJECT_TYPE"）

Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
985 consistent gets
0 physical reads
0 redo size
187491 bytes sent via SQL*Net to client
8302 bytes received via SQL*Net client
712 SQL*Net roundtrips to/ client
0 sorts （memory）
0 sorts （disk）
10662 rows processed
所以，什么时辰该用no_unnest使得子查询可以或许自力的履行完毕之后再跟外围的查询做FILTER？
起首，子查询的返回成果集应当较小，然后外围查询的输入的distinct value也应当较小（例如object_type）。

2.push_subq
若是说no_unnest是为了让子查询不展开，自力的完成，那么push_subq就是为了让子查询最进步前辈行join。
所以，这个hint其实是把握的join的次序。
例如某次在临盆库中碰到的一个SQL，简化一下然后模仿一下：
create table hao1 as * dba_objects;
create table hao2 as * dba_objects;
create table hao3 as * dba_objects;
create table hao4 as * dba_objects;
create index hao3idx on hao3（object_id）;
（analyze all tables。）
hao1.object_name 
hao1，hao2，hao4
where hao1.object_name like ""％a％""
and hao1.object_id+hao2.object_id>50
and hao4.object_type=hao1.object_type
and 11 in
（SELECT hao3.object_id FROM hao3 WHERE hao1.object_id = hao3.object_id）;
对于如上的SQL，此中hao3和hao1在子查询中join，
很明显，若是先让hao1和hao3经由过程join，成果集估计只有一行，或者没有。
然则，此时CBO做出的履行规划为：
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost （％CPU）| Time |
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 89077 | 3131K| 2070M （1）|999:59:59 |
|* 1 | FILTER | | | | | |
|* 2 | HASH JOIN | | 3234M| 108G| 289K （24）| 00:48:17 |
| 3 | TABLE ACCESS FULL | HAO4 | 36309 | 212K| 126 （3）| 00:00:02 |
| 4 | NESTED LOOPS | | 3296K| 94M| 224K （2）| 00:37:28 |
|* 5 | TABLE ACCESS FULL| HAO1 | 1816 | 47216 | 126 （3）| 00:00:02 |
|* 6 | TABLE ACCESS FULL| HAO2 | 1815 | 7260 | 124 （2）| 00:00:02 |
|* 7 | FILTER | | | | | |
|* 8 | INDEX RANGE SCAN | HAO3IDX | 1 | 4 | 1 （0）| 00:00:01 |
--------------------------------------------------------------------------------
Predicate Information （identified by operation id）:
---------------------------------------------------
1 - filter（ EXISTS （SELECT /*+ */ 0 FROM "HAO3" "HAO3" WHERE 11=:B1
AND "HAO3"."OBJECT_ID"=11））
2 - access（"HAO4"."OBJECT_TYPE"="HAO1"."OBJECT_TYPE"）
5 - filter（"HAO1"."OBJECT_NAME" LIKE ""％a％""）
6 - filter（"HAO1"."OBJECT_ID"+"HAO2"."OBJECT_ID">50）
7 - filter（11=:B1）
8 - access（"HAO3"."OBJECT_ID"=11）
由上可见，hao1和hao2，hao4进步前辈行无穷无尽的join之后，最后才跟hao3 join，这是很是坏的plan。
于是，我们hao1和hao3地点子查询先join，可以采取push_subq：
/*+push_subq（＠tmp）*/ hao1.object_name 
hao1，hao2，hao4
where hao1.object_name like ""％a％""
and hao1.object_id+hao2.object_id>50
and hao4.object_type=hao1.object_type
and 11 in
（SELECT /*+QB_Name（tmp）*/ hao3.object_id FROM hao3 WHERE hao1.object_id = hao3.object_id）;
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost （％CPU）| Time |
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 161M| 5552M| 14749 （24）| 00:02:28 |
|* 1 | HASH JOIN | | 161M| 5552M| 14748 （24）| 00:02:28 |
| 2 | TABLE ACCESS FULL | HAO4 | 36309 | 212K| 126 （3）| 00:00:02 |
| 3 | NESTED LOOPS | | 164K| 4828K| 11386 （2）| 00:01:54 |
|* 4 | TABLE ACCESS FULL | HAO1 | 91 | 2366 | 126 （3）| 00:00:02 |
|* 5 | FILTER | | | | | |
|* 6 | INDEX RANGE SCAN| HAO3IDX | 1 | 4 | 1 （0）| 00:00:01 |
|* 7 | TABLE ACCESS FULL | HAO2 | 1815 | 7260 | 124 （2）| 00:00:02 |
--------------------------------------------------------------------------------
Predicate Information （identified by operation id）:
---------------------------------------------------
1 - access（"HAO4"."OBJECT_TYPE"="HAO1"."OBJECT_TYPE"）
4 - filter（"HAO1"."OBJECT_NAME" LIKE ""％a％"" AND EXISTS （SELECT /*+
PUSH_SUBQ QB_NAME （"TMP"） */ 0 FROM "HAO3" "HAO3" WHERE 11=:B1 AND
"HAO3"."OBJECT_ID"=11））
5 - filter（11=:B1）
6 - access（"HAO3"."OBJECT_ID"=11）
7 - filter（"HAO1"."OBJECT_ID"+"HAO2"."OBJECT_ID">50）

加上hint后，SQL会在1秒以内完成。

3.push_pred
在谈到push_pred这个hint时，起首要搞清楚mergeable view和unmergeable view的差别。
这个在concept上有明白申明：
Mergeable and Unmergeable ViewsThe optimizer can merge a view into a referencing query block when the view has one or more base tables， provided the view does not contain:

      set operators （UNION， UNION ALL， INTERSECT， MINUS）

真谛，哪怕只见到一线，我们也不克不及让它的光辉变得暗淡。

      a CONNECT BY clause
    a ROWNUM pseudocolumn

  • aggregate functions （AVG， COUNT， MAX， MIN， SUM） in the list

When a view contains one of the following structures， it can be merged into a referencing query block only if complex view merging is enabled （as described below）:

    a GROUP BY clause

  • a DISTINCT operator in the list

View merging is not possible for a view that has multiple base tables if it is on the right side of an outer join. If a view on the right side of an outer join has only one base table， however， the optimizer can use complex view merging even if an expression in the view can return a non-null value for a NULL. See "Views in Outer Joins" for more information.
这里在最后，我们发明一个unmergeable view的一种景象就是view在outer join的右侧。
对于这种景象，我们熟知的merge hint也无效。
例如：
create or replace view haoview as
hao1.* hao1，hao2
where hao1.object_id=hao2.object_id;
那么对于如许一个简单的查询，可见谓词hao3.object_name=haoview.object_name被merge到了view中：
hao3.object_name 
hao3，haoview
where hao3.object_name=haoview.object_name
and hao3.object_id=999;
-----------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost （％CPU）| Time |
-----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 44 | 129 （3）| 00:00:02 |
| 1 | NESTED LOOPS | | 1 | 44 | 129 （3）| 00:00:02 |
|* 2 | HASH JOIN | | 1 | 40 | 128 （3）| 00:00:02 |
| 3 | TABLE ACCESS BY INDEX ROWID| HAO3 | 1 | 20 | 2 （0）| 00:00:01 |
|* 4 | INDEX RANGE SCAN | HAO3IDX | 1 | | 1 （0）| 00:00:01 |
| 5 | TABLE ACCESS FULL | HAO1 | 36311 | 709K| 125 （2）| 00:00:02 |
|* 6 | INDEX RANGE SCAN | HAO2IDX | 1 | 4 | 1 （0）| 00:00:01 |
-----------------------------------------------------------------------------------------
Predicate Information （identified by operation id）:
---------------------------------------------------
2 - access（"HAO3"."OBJECT_NAME"="HAO1"."OBJECT_NAME"）
4 - access（"HAO3"."OBJECT_ID"=999）
6 - access（"HAO1"."OBJECT_ID"="HAO2"."OBJECT_ID"）
接着，我把haoview放到outer join的右侧，这是haoview就属于unmergeable view了，优化器默认无法将谓词merge进这个haoview中，于是就看到了haoview零丁先履行：
hao3.object_name 
hao3，haoview
where hao3.object_name=haoview.object_name（+）
and hao3.object_id=999;
----------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost （％CPU）| Time |
----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 86 | 153 （5）| 00:00:02 |
|* 1 | HASH JOIN OUTER | | 1 | 86 | 153 （5）| 00:00:02 |
| 2 | TABLE ACCESS BY INDEX ROWID| HAO3 | 1 | 20 | 2 （0）| 00:00:01 |
|* 3 | INDEX RANGE SCAN | HAO3IDX | 1 | | 1 （0）| 00:00:01 |
| 4 | VIEW | HAOVIEW | 36309 | 2340K| 150 （4）| 00:00:02 |
|* 5 | HASH JOIN | | 36309 | 850K| 150 （4）| 00:00:02 |
| 6 | INDEX FAST FULL SCAN | HAO2IDX | 36309 | 141K| 22 （5）| 00:00:01 |
| 7 | TABLE ACCESS FULL | HAO1 | 36311 | 709K| 125 （2）| 00:00:02 |
----------------------------------------------------------------------------------------
Predicate Information （identified by operation id）:
---------------------------------------------------
1 - access（"HAO3"."OBJECT_NAME"="HAOVIEW"."OBJECT_NAME"（+））
3 - access（"HAO3"."OBJECT_ID"=999）
5 - access（"HAO1"."OBJECT_ID"="HAO2"."OBJECT_ID"）
接着，我们来应用这里的hint push_pred强迫优化器将谓词merge进view中，可见到“VIEW PUSHED PREDICATE”：
/*+push_pred（haoview）*/ hao3.object_name 
hao3，haoview
where hao3.object_name=haoview.object_name（+）
and hao3.object_id=999;
----------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost （％CPU）| Time |
----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 40 | 128 （2）| 00:00:02 |
| 1 | NESTED LOOPS OUTER | | 1 | 40 | 128 （2）| 00:00:02 |
| 2 | TABLE ACCESS BY INDEX ROWID| HAO3 | 1 | 36 | 2 （0）| 00:00:01 |
|* 3 | INDEX RANGE SCAN | HAO3IDX | 1 | | 1 （0）| 00:00:01 |
| 4 | VIEW PUSHED PREDICATE | HAOVIEW | 1 | 4 | 126 （2）| 00:00:02 |
| 5 | NESTED LOOPS | | 1 | 24 | 126 （2）| 00:00:02 |
|* 6 | TABLE ACCESS FULL | HAO1 | 1 | 20 | 125 （2）| 00:00:02 |
|* 7 | INDEX RANGE SCAN | HAO2IDX | 1 | 4 | 1 （0）| 00:00:01 |
----------------------------------------------------------------------------------------
Predicate Information （identified by operation id）:
---------------------------------------------------
3 - access（"HAO3"."OBJECT_ID"=999）
6 - filter（"HAO1"."OBJECT_NAME"="HAO3"."OBJECT_NAME"）
7 - access（"HAO1"."OBJECT_ID"="HAO2"."OBJECT_ID"）
于是，会有同窗问，那么merge hint可否有同样的结果呢？答案是，对于这种unmergeable view来说，merge hint无效。
/*+merge（haoview）*/ hao3.object_name 
hao3，haoview
where hao3.object_name=haoview.object_name（+）
and hao3.object_id=999;

----------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost （％CPU）| Time |
----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 86 | 153 （5）| 00:00:02 |
|* 1 | HASH JOIN OUTER | | 1 | 86 | 153 （5）| 00:00:02 |
| 2 | TABLE ACCESS BY INDEX ROWID| HAO3 | 1 | 20 | 2 （0）| 00:00:01 |
|* 3 | INDEX RANGE SCAN | HAO3IDX | 1 | | 1 （0）| 00:00:01 |
| 4 | VIEW | HAOVIEW | 36309 | 2340K| 150 （4）| 00:00:02 |
|* 5 | HASH JOIN | | 36309 | 850K| 150 （4）| 00:00:02 |
| 6 | INDEX FAST FULL SCAN | HAO2IDX | 36309 | 141K| 22 （5）| 00:00:01 |
| 7 | TABLE ACCESS FULL | HAO1 | 36311 | 709K| 125 （2）| 00:00:02 |
----------------------------------------------------------------------------------------
Predicate Information （identified by operation id）:
---------------------------------------------------
1 - access（"HAO3"."OBJECT_NAME"="HAOVIEW"."OBJECT_NAME"（+））
3 - access（"HAO3"."OBJECT_ID"=999）
5 - access（"HAO1"."OBJECT_ID"="HAO2"."OBJECT_ID"）

可见，对于此种身处outger join右侧的view来说，merge hint已经力所不及了。

综上，对于大师斗劲轻易混合的三个hint：
no_unnest/unnest是针对子查询是否展开的，push_subq是针对子查询的连接次序的，push_pred则是针对unmergeable view应用外部查询谓词。

http://www.cnpetweb.com/a/xinxizhongxin/lanmu9/2012/0224/35636.html

时间： 2024-10-15 00:21:37

Oracle三组难缠的hint no_unnest/unnest，push_subq，push_pred--平展化(转)的相关文章

qlserver、Mysql、Oracle三种数据库的优缺点总结

这篇文章主要介绍了sqlserver.Mysql.Oracle三种数据库的优缺点总结,需要的朋友可以参考下 一.sqlserver优点:易用性.适合分布式组织的可伸缩性.用于决策支持的数据仓库功能.与许多其他服务器软件紧密关联的集成性.良好的性价比等:为数据管理与分析带来了灵活性,允许单位在快速变化的环境中从容响应,从而获得竞争优势.从数据管理和分析角度看,将原始数据转化为商业智能和充分利用Web带来的机会非常重要.作为一个完备的数据库和数据分析包,SQLServer为快速开发新一代企业级商业应

ORACLE使用WITH AS和HINT MATERIALIZE优化SQL解决FILTER效率低下

 在做项目的过程中,一个页面使用类似如下的SQL查询数据,为了保密和使用方便,我把项目中有关的表名和字段替换使用ORACLE数据库中的系统表和字段. 在我所做的项目中,类似ALL_TABLES的表中大概有8W多条数据,下面这个查询SQL很慢. WITH PARAMS AS (SELECT '' USER_ID, '' SDATE, '%' || '' || '%' SNAME FROM DUAL) SELECT AU.USERNAME, AU.USER_ID FROM ALL_USERS A

Oracle DB 组函数

? 组函数: – 类型和语法 – 使用AVG.SUM.MIN.MAX.COUNT – 在组函数中使用DISTINCT关键字 – 组函数中的NULL值 何谓组函数 组函数会对行集进行计算,为每个组提供一个结果. 与单行函数不同,组函数用于对行集进行计算,从而为每个组提供一个结果.这些集合可以包含整个表,也可以包含表分割成的组. 组函数的类型 ? AVG ? COUNT ? MAX ? MIN ? STDDEV ? SUM ? VARIANCE 每个函数都接受一个参数.下表列出了在语法中可使用的选项

oracle三种类型坏块的处理思路总结（没有物理备份）

坏块的发生,很罕见,但生产系统偶尔还是会出现.如果有物理备份,处理起来相对简单,直接进行块级recover即可,但如果只有逻辑备份呢?处理起来要分四种情况,在此总结一下: 一.块的data部分坏了,在sql执行扫描到这个块的时候会报ORA-01578: ERROR at line 1:ORA-01578: ORACLE data block corrupted (file # 21, block # 12)ORA-01110: data file 21: '/u01/app/oracle/ora

评论第三组

团队博客每天发布站立会议信息(配站立会议照片).任务进度.任务看板(图).燃尽图(图).个人博客发表每天个人工作总结昨天干了什么:今天准备干什么:遇到困难没有: 检查第三组:发布站立会议信息(配站立会议照片).任务进度.任务看板(图).燃尽图(图).都已完成要求.只是连续发表七天 组员:张学晴,个人冲刺10天,发表完全,表明任务,进行总结,表明困难 牛俊燕:个人冲刺7天,发表完全,表明任务,进行总结,表明困难 谷伟华:个人冲刺10天,发表完全,表明任务,进行总结,表明困难 尤凯莉:个人冲刺10天

飞谷云六期第三组——基于Spark的机器学习

项目正式开始时间:2015.10.15. 随笔内容:本次项目的主题是基于Spark的ML.对于ML的学习有大概半年了,正好在网上关注到了由上海交通大学所主办的这个飞谷云的大数据项目,我所报名的这期已经是飞谷云的第六期了,在网上和群里了解了一段时间后大算报名参与一次,毕竟之前没有参与过真正的项目开发,也刚好趁着在学习ML的这个时间通过项目把理论和实践都加强.在这篇随笔中,我打算把这次项目的每个过程都写进来,一是为了给正在进行的项目提供一个全程记录:二是给自己一个留念,毕竟是自己独立完成的一个ML方

三组I/O复用模型的比较

概论: select.poll和epoll三组I/O复用系统调用,这3组系统调用都能同时监听多个文件描述符.它们将等待由timeout参数指定的超时时间,直到一个或者多个文件描述符上有事件发生时返回.返回值是就绪的文件描述符的数量.返回0表示没有事件发生,超时. 我们从事件集.最大支持文件描述符的数量.工作模式和具体实现等四个方面进一步比较它们的异同. 事件集: 这三个函数都是通过某种结构体变量来告诉内核监听哪些文件描述符上的哪些事件,并使用该结构体类型的参数来获取内核处理的结果. select

PBOC金融IC卡，卡片与终端交互的13个步骤，简介-第三组

七:终端风险管理-必选但包含可选步骤异常文件:终端检查应用主账号是否在异常文件列表(卡号黑名单)中.商户强制联机:商户可以将当前交易强制为联机处理.最低限额:控制交易当前交易金额或同一张卡片连续几笔交易累积金额超过某个数值时则要求联机授权.随机交易选择:控制交易基于当前交易的金额随机决定交易是否联机授权.(可选支持)频度检查:要求卡片在连续脱机交易一定次数后要求进行一次联机交易.新卡检查:判断卡片是否为初次使用. 6个 [终端必须具备风险管理功能,但其中的检查项是可以选择的.终端通过终端和卡片提

mysql、sqlserver、oracle三种数据库维护索引、外键、字段语法总结

mysql.sqlserver.oracle三种数据库维护索引.外键.字段语法总结 1.     MYSQL数据库 1)    创建索引 CREATE INDEX index_name ON table_name(column_list) CREATE UNIQUE INDEX index_name ON table_name(column_list) 修改表的方式添加索引 ALTER TABLE table_name ADD INDEX index_name(column_list) ALTE