haiross
haiross

Oracle 全表扫描及其执行计划(full table scan)

Oracle 全表扫描及其执行计划(full table scan)

分类： Oracle 性能优化 2013-05-24 21:46 1300人阅读 评论(1) 收藏 举报

    全表扫描是Oracle访问数据库表是较为常见的访问方式之一。很多朋友一看到SQL语句执行计划中的全表扫描，就要考虑对其进行修理一番。全表扫描的存在，的确存在可能优化的余地。但事实上很多时候全表扫描也并非是最低效的，完全要看不同的情形与场合，任一方式都是有利有弊的，也就是具体情况要具体分析。本文描述了什么是全表扫描以及何时发生全表扫描，何时全表扫描才低效。
  本文涉及到的相关链接：
     高水位线和全表扫描
     启用 AUTOTRACE 功能
     Oracle 测试常用表BIG_TABLE
     Oracle db_file_mulitblock_read_count参数
  
1、什么是全表扫描?
    全表扫描就是扫表表中所有的行，实际上是扫描表中所有的数据块，因为Oracle中最小的存储单位是Oracle block。
    扫描所有的数据块就包括高水位线以内的数据块，即使是空数据块在没有被释放的情形下也会被扫描而导致I/O增加。
    在全表扫描期间，通常情况下，表上这些相邻的数据块被按顺序(sequentially)的方式访问以使得一次I/O可以读取多个数据块。
    一次读取更多的数据块有助于全表扫描使用更少的I/O，对于可读取的数据块被限制于参数DB_FILE_MULTIBLOCK_READ_COUNT。

 

2、何时发生全表扫描?
    a、表上的索引失效或无法被使用的情形(如对谓词使用函数、计算、NULL值、不等运算符、类型转换)
    b、查询条件返回了整个表的大部分数据                 
    c、使用了并行方式访问表
    d、使用full 提示
    e、统计信息缺失时使得Oracle认为全表扫描比索引扫描更高效    
    f、表上的数据块小于DB_FILE_MULTIBLOCK_READ_COUNT值的情形可能产生全表扫描

 

3、演示全表扫描的情形

[sql] view plain copy print ?
  1. a、准备演示环境  
  2. scott@ORA11G> select * from v$version where rownum<2;  
  3.   
  4. BANNER  
  5. --------------------------------------------------------------------------------   
  6. Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production  
  7.   
  8. --创建表t   
  9. scott@ORA11G> CREATE TABLE t   
  10.   2  AS  
  11.   3  SELECT rownum AS n, rpad('*',100,'*') AS pad   
  12.   4  FROM dual  
  13.   5  CONNECT BY level <= 1000;  
  14.   
  15. Table created.  
  16.   
  17. --添加索引   
  18. scott@ORA11G> create unique index t_pk on t(n);  
  19.   
  20. Index created.  
  21.   
  22. scott@ORA11G> alter table t add constraint t_pk primary key(n) using index t_pk;  
  23.   
  24. Table altered.  
  25.   
  26. --收集统计信息   
  27. scott@ORA11G> execute dbms_stats.gather_table_stats('SCOTT','T',cascade=>true);  
  28.   
  29. PL/SQL procedure successfully completed.  
  30.   
  31. scott@ORA11G> set autot trace exp;  
  32. scott@ORA11G> select count(*) from t;   --->count(*)的时候使用了索引快速扫描   
  33.   
  34. Execution Plan  
  35. ----------------------------------------------------------   
  36. Plan hash value: 454320086  
  37. ----------------------------------------------------------------------   
  38. | Id  | Operation             | Name | Rows  | Cost (%CPU)| Time     |  
  39. ----------------------------------------------------------------------   
  40. |   0 | SELECT STATEMENT      |      |     1 |     2   (0)| 00:00:01 |  
  41. |   1 |  SORT AGGREGATE       |      |     1 |            |          |  
  42. |   2 |   INDEX FAST FULL SCAN| T_PK |  1000 |     2   (0)| 00:00:01 |  
  43. ----------------------------------------------------------------------   
  44.   
  45. scott@ORA11G> set autot off;  
  46. scott@ORA11G> alter table t move;  --->进行move table   
  47.   
  48. Table altered.  
  49.   
  50. -->move 之后索引失效，如下所示   
  51. scott@ORA11G> @idx_info             
  52. Enter value for owner: scott  
  53. Enter value for table_name: t  
  54.   
  55. Table Name    INDEX_NAME     CL_NAM               CL_POS STATUS   IDX_TYP         DSCD  
  56. ------------- -------------- -------------------- ------ -------- --------------- ----   
  57. T             T_PK           N                         1 UNUSABLE NORMAL          ASC  
  58.   
  59.   
  60. b、索引失效导致全表扫描  
  61. scott@ORA11G> set autot trace exp;  
  62. scott@ORA11G> select count(*) from t;    
  63.   
  64. Execution Plan  
  65. ----------------------------------------------------------   
  66. Plan hash value: 2966233522  
  67. -------------------------------------------------------------------   
  68. | Id  | Operation          | Name | Rows  | Cost (%CPU)| Time     |  
  69. -------------------------------------------------------------------   
  70. |   0 | SELECT STATEMENT   |      |     1 |     7   (0)| 00:00:01 |  
  71. |   1 |  SORT AGGREGATE    |      |     1 |            |          |  
  72. |   2 |   TABLE ACCESS FULL| T    |  1000 |     7   (0)| 00:00:01 |  
  73. -------------------------------------------------------------------   
  74.   
  75. scott@ORA11G> set autot off;  
  76. scott@ORA11G> alter index t_pk rebuild;   -->重建索引   
  77.   
  78. Index altered.  
  79.   
  80. scott@ORA11G> @idx_info  
  81. Enter value for owner: scott  
  82. Enter value for table_name: t  
  83.   
  84. Table Name     INDEX_NAME       CL_NAM               CL_POS STATUS   IDX_TYP         DSCD  
  85. -------------- ---------------- -------------------- ------ -------- --------------- ----   
  86. T              T_PK             N                         1 VALID    NORMAL          ASC  
  87.   
  88.   
  89. c、返回了整个表的大部分数据使用了全表扫描  
  90. scott@ORA11G> select count(pad) from t where n<=990;  
  91.   
  92. Execution Plan  
  93. ----------------------------------------------------------   
  94. Plan hash value: 2966233522  
  95. ---------------------------------------------------------------------------   
  96. | Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |  
  97. ---------------------------------------------------------------------------   
  98. |   0 | SELECT STATEMENT   |      |     1 |   105 |     7   (0)| 00:00:01 |  
  99. |   1 |  SORT AGGREGATE    |      |     1 |   105 |            |          |  
  100. |*  2 |   TABLE ACCESS FULL| T    |   991 |   101K|     7   (0)| 00:00:01 |  
  101. ---------------------------------------------------------------------------   
  102. Predicate Information (identified by operation id):  
  103. ---------------------------------------------------   
  104.    2 - filter("N"<=990)  
  105.   
  106. --返回小部分数据时，使用的是索引扫描   
  107. scott@ORA11G> select count(pad) from t where n<=10;  
  108.   
  109. Execution Plan  
  110. ----------------------------------------------------------   
  111. Plan hash value: 4270555908  
  112. -------------------------------------------------------------------------------------   
  113. | Id  | Operation                    | Name | Rows  | Bytes | Cost (%CPU)| Time     |  
  114. -------------------------------------------------------------------------------------   
  115. |   0 | SELECT STATEMENT             |      |     1 |   105 |     3   (0)| 00:00:01 |  
  116. |   1 |  SORT AGGREGATE              |      |     1 |   105 |            |          |  
  117. |   2 |   TABLE ACCESS BY INDEX ROWID| T    |    10 |  1050 |     3   (0)| 00:00:01 |  
  118. |*  3 |    INDEX RANGE SCAN          | T_PK |    10 |       |     2   (0)| 00:00:01 |  
  119. -------------------------------------------------------------------------------------   
  120. Predicate Information (identified by operation id):  
  121. ---------------------------------------------------   
  122.    3 - access("N"<=10)  
  123.   
  124.   
  125. d、使用并行方式访问表时使用了全表扫描  
  126. scott@ORA11G> select /*+ parallel(3) */ count(pad) from t where n<=10;  
  127.   
  128. Execution Plan  
  129. ----------------------------------------------------------   
  130. Plan hash value: 3126468333  
  131. ----------------------------------------------------------------------------------------------------------------   
  132. | Id  | Operation              | Name     | Rows  | Bytes | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |  
  133. ----------------------------------------------------------------------------------------------------------------   
  134. |   0 | SELECT STATEMENT       |          |     1 |   105 |     3   (0)| 00:00:01 |        |      |            |  
  135. |   1 |  SORT AGGREGATE        |          |     1 |   105 |            |          |        |      |            |  
  136. |   2 |   PX COORDINATOR       |          |       |       |            |          |        |      |            |  
  137. |   3 |    PX SEND QC (RANDOM) | :TQ10000 |     1 |   105 |            |          |  Q1,00 | P->S | QC (RAND)  |  
  138. |   4 |     SORT AGGREGATE     |          |     1 |   105 |            |          |  Q1,00 | PCWP |            |  
  139. |   5 |      PX BLOCK ITERATOR |          |    10 |  1050 |     3   (0)| 00:00:01 |  Q1,00 | PCWC |            |  
  140. |*  6 |       TABLE ACCESS FULL| T        |    10 |  1050 |     3   (0)| 00:00:01 |  Q1,00 | PCWP |            |  
  141. ----------------------------------------------------------------------------------------------------------------   
  142. Predicate Information (identified by operation id):  
  143. ---------------------------------------------------   
  144.    6 - filter("N"<=10)  
  145. Note  
  146. -----   
  147.    - Degree of Parallelism is 3 because of hint  
  148. --Author : Robinson   
  149. --Blog   : http://blog.csdn.net/robinson_0612   
  150.   
  151.   
  152. e、使用full提示时使用了全表扫描  
  153. scott@ORA11G> select /*+ full(t) */ count(pad) from t where n<=10;  
  154.   
  155. Execution Plan  
  156. ----------------------------------------------------------   
  157. Plan hash value: 2966233522  
  158. ---------------------------------------------------------------------------   
  159. | Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |  
  160. ---------------------------------------------------------------------------   
  161. |   0 | SELECT STATEMENT   |      |     1 |   105 |     7   (0)| 00:00:01 |  
  162. |   1 |  SORT AGGREGATE    |      |     1 |   105 |            |          |  
  163. |*  2 |   TABLE ACCESS FULL| T    |    10 |  1050 |     7   (0)| 00:00:01 |  
  164. ---------------------------------------------------------------------------   
  165. Predicate Information (identified by operation id):  
  166. ---------------------------------------------------   
  167.    2 - filter("N"<=10)           
  168.   
  169.   
  170. f、统计信息缺失导致全表扫描的情形  
  171. scott@ORA11G> exec dbms_stats.delete_table_stats('SCOTT','T');  
  172.   
  173. PL/SQL procedure successfully completed.  
  174.   
  175. scott@ORA11G> select count(pad) from t where n<=10;  
  176.   
  177. Execution Plan  
  178. ----------------------------------------------------------   
  179. Plan hash value: 2966233522  
  180. ---------------------------------------------------------------------------   
  181. | Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |  
  182. ---------------------------------------------------------------------------   
  183. |   0 | SELECT STATEMENT   |      |     1 |    65 |     7   (0)| 00:00:01 |  
  184. |   1 |  SORT AGGREGATE    |      |     1 |    65 |            |          |  
  185. |*  2 |   TABLE ACCESS FULL| T    |    10 |   650 |     7   (0)| 00:00:01 |  
  186. ---------------------------------------------------------------------------   
  187. Predicate Information (identified by operation id):  
  188. ---------------------------------------------------   
  189.    2 - filter("N"<=10)  
  190. Note  
  191. -----   
  192.    - dynamic sampling used for this statement (level=2)  
  193.   
  194. --上面的执行计划使用了全表扫描，而且提示使用了动态采样，也就是缺乏统计信息   
  195. --表上的数据块小于DB_FILE_MULTIBLOCK_READ_COUNT值的情形可能产生全表扫描的情形不演示  
a、准备演示环境
scott@ORA11G> select * from v$version where rownum<2;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production

--创建表t
scott@ORA11G> CREATE TABLE t 
  2  AS
  3  SELECT rownum AS n, rpad('*',100,'*') AS pad 
  4  FROM dual
  5  CONNECT BY level <= 1000;

Table created.

--添加索引
scott@ORA11G> create unique index t_pk on t(n);

Index created.

scott@ORA11G> alter table t add constraint t_pk primary key(n) using index t_pk;

Table altered.

--收集统计信息
scott@ORA11G> execute dbms_stats.gather_table_stats('SCOTT','T',cascade=>true);

PL/SQL procedure successfully completed.

scott@ORA11G> set autot trace exp;
scott@ORA11G> select count(*) from t;   --->count(*)的时候使用了索引快速扫描

Execution Plan
----------------------------------------------------------
Plan hash value: 454320086
----------------------------------------------------------------------
| Id  | Operation             | Name | Rows  | Cost (%CPU)| Time     |
----------------------------------------------------------------------
|   0 | SELECT STATEMENT      |      |     1 |     2   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE       |      |     1 |            |          |
|   2 |   INDEX FAST FULL SCAN| T_PK |  1000 |     2   (0)| 00:00:01 |
----------------------------------------------------------------------

scott@ORA11G> set autot off;
scott@ORA11G> alter table t move;  --->进行move table

Table altered.

-->move 之后索引失效，如下所示
scott@ORA11G> @idx_info           
Enter value for owner: scott
Enter value for table_name: t

Table Name    INDEX_NAME     CL_NAM               CL_POS STATUS   IDX_TYP         DSCD
------------- -------------- -------------------- ------ -------- --------------- ----
T             T_PK           N                         1 UNUSABLE NORMAL          ASC


b、索引失效导致全表扫描
scott@ORA11G> set autot trace exp;
scott@ORA11G> select count(*) from t;  

Execution Plan
----------------------------------------------------------
Plan hash value: 2966233522
-------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Cost (%CPU)| Time     |
-------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |     1 |     7   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE    |      |     1 |            |          |
|   2 |   TABLE ACCESS FULL| T    |  1000 |     7   (0)| 00:00:01 |
-------------------------------------------------------------------

scott@ORA11G> set autot off;
scott@ORA11G> alter index t_pk rebuild;   -->重建索引

Index altered.

scott@ORA11G> @idx_info
Enter value for owner: scott
Enter value for table_name: t

Table Name     INDEX_NAME       CL_NAM               CL_POS STATUS   IDX_TYP         DSCD
-------------- ---------------- -------------------- ------ -------- --------------- ----
T              T_PK             N                         1 VALID    NORMAL          ASC


c、返回了整个表的大部分数据使用了全表扫描
scott@ORA11G> select count(pad) from t where n<=990;

Execution Plan
----------------------------------------------------------
Plan hash value: 2966233522
---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |     1 |   105 |     7   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE    |      |     1 |   105 |            |          |
|*  2 |   TABLE ACCESS FULL| T    |   991 |   101K|     7   (0)| 00:00:01 |
---------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter("N"<=990)

--返回小部分数据时，使用的是索引扫描
scott@ORA11G> select count(pad) from t where n<=10;

Execution Plan
----------------------------------------------------------
Plan hash value: 4270555908
-------------------------------------------------------------------------------------
| Id  | Operation                    | Name | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |      |     1 |   105 |     3   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE              |      |     1 |   105 |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID| T    |    10 |  1050 |     3   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN          | T_PK |    10 |       |     2   (0)| 00:00:01 |
-------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   3 - access("N"<=10)


d、使用并行方式访问表时使用了全表扫描
scott@ORA11G> select /*+ parallel(3) */ count(pad) from t where n<=10;

Execution Plan
----------------------------------------------------------
Plan hash value: 3126468333
----------------------------------------------------------------------------------------------------------------
| Id  | Operation              | Name     | Rows  | Bytes | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |          |     1 |   105 |     3   (0)| 00:00:01 |        |      |            |
|   1 |  SORT AGGREGATE        |          |     1 |   105 |            |          |        |      |            |
|   2 |   PX COORDINATOR       |          |       |       |            |          |        |      |            |
|   3 |    PX SEND QC (RANDOM) | :TQ10000 |     1 |   105 |            |          |  Q1,00 | P->S | QC (RAND)  |
|   4 |     SORT AGGREGATE     |          |     1 |   105 |            |          |  Q1,00 | PCWP |            |
|   5 |      PX BLOCK ITERATOR |          |    10 |  1050 |     3   (0)| 00:00:01 |  Q1,00 | PCWC |            |
|*  6 |       TABLE ACCESS FULL| T        |    10 |  1050 |     3   (0)| 00:00:01 |  Q1,00 | PCWP |            |
----------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   6 - filter("N"<=10)
Note
-----
   - Degree of Parallelism is 3 because of hint
--Author : Robinson
--Blog   : http://blog.csdn.net/robinson_0612


e、使用full提示时使用了全表扫描
scott@ORA11G> select /*+ full(t) */ count(pad) from t where n<=10;

Execution Plan
----------------------------------------------------------
Plan hash value: 2966233522
---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |     1 |   105 |     7   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE    |      |     1 |   105 |            |          |
|*  2 |   TABLE ACCESS FULL| T    |    10 |  1050 |     7   (0)| 00:00:01 |
---------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter("N"<=10)         


f、统计信息缺失导致全表扫描的情形
scott@ORA11G> exec dbms_stats.delete_table_stats('SCOTT','T');

PL/SQL procedure successfully completed.

scott@ORA11G> select count(pad) from t where n<=10;

Execution Plan
----------------------------------------------------------
Plan hash value: 2966233522
---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |     1 |    65 |     7   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE    |      |     1 |    65 |            |          |
|*  2 |   TABLE ACCESS FULL| T    |    10 |   650 |     7   (0)| 00:00:01 |
---------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter("N"<=10)
Note
-----
   - dynamic sampling used for this statement (level=2)

--上面的执行计划使用了全表扫描，而且提示使用了动态采样，也就是缺乏统计信息
--表上的数据块小于DB_FILE_MULTIBLOCK_READ_COUNT值的情形可能产生全表扫描的情形不演示

4、全表扫描何时低效?

[sql] view plain copy print ?
  1. --先来做几个实验   
  2. a、演示表上的相关信息  
  3. scott@ORA11G> @idx_info  
  4. Enter value for owner: scott  
  5. Enter value for table_name: big_table  
  6.   
  7. Table Name                Index Name                CL_NAM    CL_POS Status   IDX_TYP         DSCD  
  8. ------------------------- ------------------------- --------- ------ -------- --------------- ----   
  9. BIG_TABLE                 BIG_TABLE_PK              ID             1 VALID    NORMAL          ASC  
  10.   
  11. scott@ORA11G> @idx_stat  
  12. Enter value for input_table_name: big_table  
  13. Enter value for owner: scott  
  14.   
  15.                                                      AVG LEAF BLKS AVG DATA BLKS  
  16. BLEV IDX_NAME        LEAF_BLKS   DST_KEYS       PER KEY       PER KEY CLUST_FACT LAST_ANALYZED         TB_BLKS    TB_ROWS  
  17. ---- -------------- ---------- ---------- ------------- ------------- ---------- ------------------ ---------- ----------   
  18.    1 BIG_TABLE_PK          208     100000             1             1       1483 20130524 10:45:51        1515     100000  
  19.   
  20. --数据库参数设置   
  21. scott@ORA11G> show parameter optimizer_index_  
  22.   
  23. NAME                                 TYPE        VALUE  
  24. ------------------------------------ ----------- ------------------------------   
  25. optimizer_index_caching              integer     0  
  26. optimizer_index_cost_adj             integer     100  
  27. scott@ORA11G> show parameter optimizer_mode  
  28.   
  29. NAME                                 TYPE        VALUE  
  30. ------------------------------------ ----------- ------------------------------   
  31. optimizer_mode                       string      ALL_ROWS  
  32.   
  33.   
  34. b、查询返回20%数据行的情形  
  35. scott@ORA11G> alter system flush buffer_cache;                                                    
  36. scott@ORA11G> select sum(object_id),avg(object_id) from big_table where id between 20000 and 40000;  
  37.   
  38. Execution Plan  
  39. ----------------------------------------------------------   
  40. Plan hash value: 3098837282                             -- 执行计划中，使用了索引范围扫描   
  41. ---------------------------------------------------------------------------------------------   
  42. | Id  | Operation                    | Name         | Rows  | Bytes | Cost (%CPU)| Time     |  
  43. ---------------------------------------------------------------------------------------------   
  44. |   0 | SELECT STATEMENT             |              |     1 |    18 |   341   (0)| 00:00:05 |  
  45. |   1 |  SORT AGGREGATE              |              |     1 |    18 |            |          |  
  46. |   2 |   TABLE ACCESS BY INDEX ROWID| BIG_TABLE    | 20046 |   352K|   341   (0)| 00:00:05 |  
  47. |*  3 |    INDEX RANGE SCAN          | BIG_TABLE_PK | 20046 |       |    43   (0)| 00:00:01 |  
  48. ---------------------------------------------------------------------------------------------   
  49. Predicate Information (identified by operation id):  
  50. ---------------------------------------------------   
  51.    3 - access("ID">=20000 AND "ID"<=40000)  
  52. Statistics  
  53. ----------------------------------------------------------   
  54.           0  recursive calls  
  55.           0  db block gets  
  56.         351  consistent gets  
  57.         351  physical reads  
  58.           0  redo size  
  59.         427  bytes sent via SQL*Net to client  
  60.         349  bytes received via SQL*Net from client  
  61.           2  SQL*Net roundtrips to/from client  
  62.           0  sorts (memory)  
  63.           0  sorts (disk)  
  64.           1  rows processed  
  65.   
  66. scott@ORA11G> alter system flush buffer_cache;   
  67. scott@ORA11G> select /*+ full(big_table) */ sum(object_id),avg(object_id) from big_table where id between 20000 and 40000;  
  68.   
  69. Execution Plan  
  70. ----------------------------------------------------------   
  71. Plan hash value: 599409829                ---- 使用了提示执行为全表扫描   
  72. --------------------------------------------------------------------------------   
  73. | Id  | Operation          | Name      | Rows  | Bytes | Cost (%CPU)| Time     |  
  74. --------------------------------------------------------------------------------   
  75. |   0 | SELECT STATEMENT   |           |     1 |    18 |   413   (1)| 00:00:05 |  
  76. |   1 |  SORT AGGREGATE    |           |     1 |    18 |            |          |  
  77. |*  2 |   TABLE ACCESS FULL| BIG_TABLE | 20046 |   352K|   413   (1)| 00:00:05 |  
  78. --------------------------------------------------------------------------------   
  79. Predicate Information (identified by operation id):  
  80. ---------------------------------------------------   
  81.    2 - filter("ID"<=40000 AND "ID">=20000)  
  82. Statistics  
  83. ----------------------------------------------------------   
  84.           0  recursive calls  
  85.           0  db block gets  
  86.        1486  consistent gets  
  87.        1484  physical reads  
  88.           0  redo size  
  89.         427  bytes sent via SQL*Net to client  
  90.         349  bytes received via SQL*Net from client  
  91.           2  SQL*Net roundtrips to/from client  
  92.           0  sorts (memory)  
  93.           0  sorts (disk)  
  94.           1  rows processed  
  95.   
  96. --注意对比上面两次操作中的consistent gets与physical reads   
  97.   
  98.   
  99. c、查询返回30%数据行的情形  
  100. scott@ORA11G> alter system flush buffer_cache;  
  101. scott@ORA11G> select sum(object_id),avg(object_id) from big_table where id between 20000 and 50000;  
  102.   
  103. Execution Plan  
  104. ----------------------------------------------------------   
  105. Plan hash value: 599409829             --->尽管返回数据的总行数为30%，而此时优化器使用了全表扫描   
  106. --------------------------------------------------------------------------------   
  107. | Id  | Operation          | Name      | Rows  | Bytes | Cost (%CPU)| Time     |  
  108. --------------------------------------------------------------------------------   
  109. |   0 | SELECT STATEMENT   |           |     1 |    18 |   413   (1)| 00:00:05 |  
  110. |   1 |  SORT AGGREGATE    |           |     1 |    18 |            |          |  
  111. |*  2 |   TABLE ACCESS FULL| BIG_TABLE | 30012 |   527K|   413   (1)| 00:00:05 |  
  112. --------------------------------------------------------------------------------   
  113. Predicate Information (identified by operation id):  
  114. ---------------------------------------------------   
  115.    2 - filter("ID"<=50000 AND "ID">=20000)  
  116. Statistics  
  117. ----------------------------------------------------------   
  118.           0  recursive calls  
  119.           0  db block gets  
  120.        1486  consistent gets  
  121.        1484  physical reads  
  122.           0  redo size  
  123.         427  bytes sent via SQL*Net to client  
  124.         349  bytes received via SQL*Net from client  
  125.           2  SQL*Net roundtrips to/from client  
  126.           0  sorts (memory)  
  127.           0  sorts (disk)  
  128.           1  rows processed  
  129.   
  130. --下面使用提示来强制优化器走索引扫描   
  131. scott@ORA11G> alter system flush buffer_cache;  
  132. scott@ORA11G> select /*+ index(big_table big_table_pk) */ sum(object_id),avg(object_id)   
  133.   2  from big_table where id between 20000 and 50000;  
  134.   
  135. Execution Plan  
  136. ----------------------------------------------------------   
  137. Plan hash value: 3098837282  
  138. ---------------------------------------------------------------------------------------------   
  139. | Id  | Operation                    | Name         | Rows  | Bytes | Cost (%CPU)| Time     |  
  140. ---------------------------------------------------------------------------------------------   
  141. |   0 | SELECT STATEMENT             |              |     1 |    18 |   511   (1)| 00:00:07 |  
  142. |   1 |  SORT AGGREGATE              |              |     1 |    18 |            |          |  
  143. |   2 |   TABLE ACCESS BY INDEX ROWID| BIG_TABLE    | 30012 |   527K|   511   (1)| 00:00:07 |  
  144. |*  3 |    INDEX RANGE SCAN          | BIG_TABLE_PK | 30012 |       |    64   (0)| 00:00:01 |  
  145. ---------------------------------------------------------------------------------------------   
  146. Predicate Information (identified by operation id):  
  147. ---------------------------------------------------   
  148.    3 - access("ID">=20000 AND "ID"<=50000)  
  149. Statistics  
  150. ----------------------------------------------------------   
  151.           0  recursive calls  
  152.           0  db block gets  
  153.         526  consistent gets  
  154.         526  physical reads  
  155.           0  redo size  
  156.         427  bytes sent via SQL*Net to client  
  157.         349  bytes received via SQL*Net from client  
  158.           2  SQL*Net roundtrips to/from client  
  159.           0  sorts (memory)  
  160.           0  sorts (disk)  
  161.           1  rows processed  
  162.             
  163. --注意观察每一次测试时所耗用的物理读与逻辑读   
  164. --从上面的测试可以看出，当表上所返回的数据行数接近于表上的30%时，Oracle 倾向于使用全表扫描   
  165. --而对于表上所返回的数据行数接近于表上的30%的情形，我们给与索引提示，此时比全表扫描更高效，即全表扫描是低效的   
  166. --笔者同时测试了数据返回总行数接近80%的情形以及创建了一个百万记录的进行对比测试   
  167. --大致结论，如果查询所返回的数据的总行数仅仅是表上数据的百分之八十以下，而使用了全表扫描，即可认为该全表扫描是低效的   
  168. --注：   
  169. --具体情况需要具体分析，如果你的表是千万级的，返回总数据的百分之零点几都会导致很大的差异   
  170. --其次，表上的索引应具有良好的聚簇因子，如不然，测试的结果可能有天壤之别   
  171. --最后，上面所描述的返回总行数应与执行结果返回的行数有差异，是指多少行参与了sum(object_id)  
--先来做几个实验
a、演示表上的相关信息
scott@ORA11G> @idx_info
Enter value for owner: scott
Enter value for table_name: big_table

Table Name                Index Name                CL_NAM    CL_POS Status   IDX_TYP         DSCD
------------------------- ------------------------- --------- ------ -------- --------------- ----
BIG_TABLE                 BIG_TABLE_PK              ID             1 VALID    NORMAL          ASC

scott@ORA11G> @idx_stat
Enter value for input_table_name: big_table
Enter value for owner: scott

                                                     AVG LEAF BLKS AVG DATA BLKS
BLEV IDX_NAME        LEAF_BLKS   DST_KEYS       PER KEY       PER KEY CLUST_FACT LAST_ANALYZED         TB_BLKS    TB_ROWS
---- -------------- ---------- ---------- ------------- ------------- ---------- ------------------ ---------- ----------
   1 BIG_TABLE_PK          208     100000             1             1       1483 20130524 10:45:51        1515     100000

--数据库参数设置
scott@ORA11G> show parameter optimizer_index_

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
optimizer_index_caching              integer     0
optimizer_index_cost_adj             integer     100
scott@ORA11G> show parameter optimizer_mode

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
optimizer_mode                       string      ALL_ROWS


b、查询返回20%数据行的情形
scott@ORA11G> alter system flush buffer_cache;                                                  
scott@ORA11G> select sum(object_id),avg(object_id) from big_table where id between 20000 and 40000;

Execution Plan
----------------------------------------------------------
Plan hash value: 3098837282                             -- 执行计划中，使用了索引范围扫描
---------------------------------------------------------------------------------------------
| Id  | Operation                    | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |              |     1 |    18 |   341   (0)| 00:00:05 |
|   1 |  SORT AGGREGATE              |              |     1 |    18 |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID| BIG_TABLE    | 20046 |   352K|   341   (0)| 00:00:05 |
|*  3 |    INDEX RANGE SCAN          | BIG_TABLE_PK | 20046 |       |    43   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   3 - access("ID">=20000 AND "ID"<=40000)
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
        351  consistent gets
        351  physical reads
          0  redo size
        427  bytes sent via SQL*Net to client
        349  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

scott@ORA11G> alter system flush buffer_cache; 
scott@ORA11G> select /*+ full(big_table) */ sum(object_id),avg(object_id) from big_table where id between 20000 and 40000;

Execution Plan
----------------------------------------------------------
Plan hash value: 599409829                ---- 使用了提示执行为全表扫描
--------------------------------------------------------------------------------
| Id  | Operation          | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |           |     1 |    18 |   413   (1)| 00:00:05 |
|   1 |  SORT AGGREGATE    |           |     1 |    18 |            |          |
|*  2 |   TABLE ACCESS FULL| BIG_TABLE | 20046 |   352K|   413   (1)| 00:00:05 |
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter("ID"<=40000 AND "ID">=20000)
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       1486  consistent gets
       1484  physical reads
          0  redo size
        427  bytes sent via SQL*Net to client
        349  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

--注意对比上面两次操作中的consistent gets与physical reads


c、查询返回30%数据行的情形
scott@ORA11G> alter system flush buffer_cache;
scott@ORA11G> select sum(object_id),avg(object_id) from big_table where id between 20000 and 50000;

Execution Plan
----------------------------------------------------------
Plan hash value: 599409829             --->尽管返回数据的总行数为30%，而此时优化器使用了全表扫描
--------------------------------------------------------------------------------
| Id  | Operation          | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |           |     1 |    18 |   413   (1)| 00:00:05 |
|   1 |  SORT AGGREGATE    |           |     1 |    18 |            |          |
|*  2 |   TABLE ACCESS FULL| BIG_TABLE | 30012 |   527K|   413   (1)| 00:00:05 |
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter("ID"<=50000 AND "ID">=20000)
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       1486  consistent gets
       1484  physical reads
          0  redo size
        427  bytes sent via SQL*Net to client
        349  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

--下面使用提示来强制优化器走索引扫描
scott@ORA11G> alter system flush buffer_cache;
scott@ORA11G> select /*+ index(big_table big_table_pk) */ sum(object_id),avg(object_id) 
  2  from big_table where id between 20000 and 50000;

Execution Plan
----------------------------------------------------------
Plan hash value: 3098837282
---------------------------------------------------------------------------------------------
| Id  | Operation                    | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |              |     1 |    18 |   511   (1)| 00:00:07 |
|   1 |  SORT AGGREGATE              |              |     1 |    18 |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID| BIG_TABLE    | 30012 |   527K|   511   (1)| 00:00:07 |
|*  3 |    INDEX RANGE SCAN          | BIG_TABLE_PK | 30012 |       |    64   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   3 - access("ID">=20000 AND "ID"<=50000)
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
        526  consistent gets
        526  physical reads
          0  redo size
        427  bytes sent via SQL*Net to client
        349  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed
          
--注意观察每一次测试时所耗用的物理读与逻辑读
--从上面的测试可以看出，当表上所返回的数据行数接近于表上的30%时，Oracle 倾向于使用全表扫描
--而对于表上所返回的数据行数接近于表上的30%的情形，我们给与索引提示，此时比全表扫描更高效，即全表扫描是低效的
--笔者同时测试了数据返回总行数接近80%的情形以及创建了一个百万记录的进行对比测试
--大致结论，如果查询所返回的数据的总行数仅仅是表上数据的百分之八十以下，而使用了全表扫描，即可认为该全表扫描是低效的
--注：
--具体情况需要具体分析，如果你的表是千万级的，返回总数据的百分之零点几都会导致很大的差异
--其次，表上的索引应具有良好的聚簇因子，如不然，测试的结果可能有天壤之别
--最后，上面所描述的返回总行数应与执行结果返回的行数有差异，是指多少行参与了sum(object_id)

5、小表的全表扫描是否高效?

[sql] view plain copy print ?
  1. --使用scott下dept表，仅有4行数据   
  2. scott@ORA11G> select * from dept where deptno>10;  
  3.   
  4. 3 rows selected.  
  5.   
  6. Execution Plan  
  7. ----------------------------------------------------------   
  8. Plan hash value: 2985873453            --->执行计划选择了索引扫描   
  9. ---------------------------------------------------------------------------------------   
  10. | Id  | Operation                   | Name    | Rows  | Bytes | Cost (%CPU)| Time     |  
  11. ---------------------------------------------------------------------------------------   
  12. |   0 | SELECT STATEMENT            |         |     3 |    60 |     2   (0)| 00:00:01 |  
  13. |   1 |  TABLE ACCESS BY INDEX ROWID| DEPT    |     3 |    60 |     2   (0)| 00:00:01 |  
  14. |*  2 |   INDEX RANGE SCAN          | PK_DEPT |     3 |       |     1   (0)| 00:00:01 |  
  15. ---------------------------------------------------------------------------------------   
  16. Predicate Information (identified by operation id):  
  17. ---------------------------------------------------   
  18.    2 - access("DEPTNO">10)  
  19. Statistics  
  20. ----------------------------------------------------------   
  21.           0  recursive calls  
  22.           0  db block gets  
  23.           4  consistent gets                      -->使用了4次逻辑读   
  24.           0  physical reads  
  25.           0  redo size  
  26.         515  bytes sent via SQL*Net to client  
  27.         349  bytes received via SQL*Net from client  
  28.           2  SQL*Net roundtrips to/from client  
  29.           0  sorts (memory)  
  30.           0  sorts (disk)  
  31.           3  rows processed  
  32.   
  33. -->下面强制使用全表扫描   
  34. scott@ORA11G> select /*+ full(dept) */ * from dept where deptno>10;  
  35.   
  36. 3 rows selected.  
  37.   
  38. Execution Plan  
  39. ----------------------------------------------------------   
  40. Plan hash value: 3383998547   
  41. --------------------------------------------------------------------------   
  42. | Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |  
  43. --------------------------------------------------------------------------   
  44. |   0 | SELECT STATEMENT  |      |     3 |    60 |     3   (0)| 00:00:01 |  
  45. |*  1 |  TABLE ACCESS FULL| DEPT |     3 |    60 |     3   (0)| 00:00:01 |  
  46. --------------------------------------------------------------------------   
  47. Predicate Information (identified by operation id):  
  48. ---------------------------------------------------   
  49.    1 - filter("DEPTNO">10)  
  50. Statistics  
  51. ----------------------------------------------------------   
  52.           1  recursive calls  
  53.           0  db block gets  
  54.           4  consistent gets         -->此时的逻辑读同样为4次   
  55.           0  physical reads  
  56.           0  redo size  
  57.         515  bytes sent via SQL*Net to client  
  58.         349  bytes received via SQL*Net from client  
  59.           2  SQL*Net roundtrips to/from client  
  60.           0  sorts (memory)  
  61.           0  sorts (disk)  
  62.           3  rows processed  
  63.   
  64. --下面来看看count(*)的情形   
  65. scott@ORA11G> select count(*) from dept;  
  66.   
  67. 1 row selected.  
  68.   
  69. Execution Plan  
  70. ----------------------------------------------------------   
  71. Plan hash value: 3051237957               --->执行计划选择了索引全扫描   
  72. --------------------------------------------------------------------   
  73. | Id  | Operation        | Name    | Rows  | Cost (%CPU)| Time     |  
  74. --------------------------------------------------------------------   
  75. |   0 | SELECT STATEMENT |         |     1 |     1   (0)| 00:00:01 |  
  76. |   1 |  SORT AGGREGATE  |         |     1 |            |          |  
  77. |   2 |   INDEX FULL SCAN| PK_DEPT |     4 |     1   (0)| 00:00:01 |  
  78. --------------------------------------------------------------------   
  79. Statistics  
  80. ----------------------------------------------------------   
  81.           0  recursive calls  
  82.           0  db block gets  
  83.           1  consistent gets            -->逻辑读仅为1次   
  84.           0  physical reads  
  85.           0  redo size  
  86.         335  bytes sent via SQL*Net to client  
  87.         349  bytes received via SQL*Net from client  
  88.           2  SQL*Net roundtrips to/from client  
  89.           0  sorts (memory)  
  90.           0  sorts (disk)  
  91.           1  rows processed  
  92.   
  93. -->下面强制使用全表扫描   
  94. scott@ORA11G> select /*+ full(dept) */ count(*) from dept;  
  95.   
  96. 1 row selected.  
  97.   
  98. Execution Plan  
  99. ----------------------------------------------------------   
  100. Plan hash value: 315352865  
  101. -------------------------------------------------------------------   
  102. | Id  | Operation          | Name | Rows  | Cost (%CPU)| Time     |  
  103. -------------------------------------------------------------------   
  104. |   0 | SELECT STATEMENT   |      |     1 |     3   (0)| 00:00:01 |  
  105. |   1 |  SORT AGGREGATE    |      |     1 |            |          |  
  106. |   2 |   TABLE ACCESS FULL| DEPT |     4 |     3   (0)| 00:00:01 |  
  107. -------------------------------------------------------------------   
  108. Statistics  
  109. ----------------------------------------------------------   
  110.           0  recursive calls  
  111.           0  db block gets  
  112.           3  consistent gets     -->使用了3次逻辑读   
  113.           0  physical reads  
  114.           0  redo size  
  115.         335  bytes sent via SQL*Net to client  
  116.         349  bytes received via SQL*Net from client  
  117.           2  SQL*Net roundtrips to/from client  
  118.           0  sorts (memory)  
  119.           0  sorts (disk)  
  120.           1  rows processed  
  121.                       
  122. --对于小表，从上面的情形可以看出，使用索引扫描也是比全表扫描高效   
  123. --因此，建议始终为小表建立索引  
--使用scott下dept表，仅有4行数据
scott@ORA11G> select * from dept where deptno>10;

3 rows selected.

Execution Plan
----------------------------------------------------------
Plan hash value: 2985873453            --->执行计划选择了索引扫描
---------------------------------------------------------------------------------------
| Id  | Operation                   | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |         |     3 |    60 |     2   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| DEPT    |     3 |    60 |     2   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | PK_DEPT |     3 |       |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("DEPTNO">10)
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          4  consistent gets                      -->使用了4次逻辑读
          0  physical reads
          0  redo size
        515  bytes sent via SQL*Net to client
        349  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          3  rows processed

-->下面强制使用全表扫描
scott@ORA11G> select /*+ full(dept) */ * from dept where deptno>10;

3 rows selected.

Execution Plan
----------------------------------------------------------
Plan hash value: 3383998547 
--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     3 |    60 |     3   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| DEPT |     3 |    60 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("DEPTNO">10)
Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
          4  consistent gets         -->此时的逻辑读同样为4次
          0  physical reads
          0  redo size
        515  bytes sent via SQL*Net to client
        349  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          3  rows processed

--下面来看看count(*)的情形
scott@ORA11G> select count(*) from dept;

1 row selected.

Execution Plan
----------------------------------------------------------
Plan hash value: 3051237957               --->执行计划选择了索引全扫描
--------------------------------------------------------------------
| Id  | Operation        | Name    | Rows  | Cost (%CPU)| Time     |
--------------------------------------------------------------------
|   0 | SELECT STATEMENT |         |     1 |     1   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE  |         |     1 |            |          |
|   2 |   INDEX FULL SCAN| PK_DEPT |     4 |     1   (0)| 00:00:01 |
--------------------------------------------------------------------
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          1  consistent gets            -->逻辑读仅为1次
          0  physical reads
          0  redo size
        335  bytes sent via SQL*Net to client
        349  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

-->下面强制使用全表扫描
scott@ORA11G> select /*+ full(dept) */ count(*) from dept;

1 row selected.

Execution Plan
----------------------------------------------------------
Plan hash value: 315352865
-------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Cost (%CPU)| Time     |
-------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |     1 |     3   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE    |      |     1 |            |          |
|   2 |   TABLE ACCESS FULL| DEPT |     4 |     3   (0)| 00:00:01 |
-------------------------------------------------------------------
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          3  consistent gets     -->使用了3次逻辑读
          0  physical reads
          0  redo size
        335  bytes sent via SQL*Net to client
        349  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed
                    
--对于小表，从上面的情形可以看出，使用索引扫描也是比全表扫描高效
--因此，建议始终为小表建立索引

更多参考

DML Error Logging 特性 

PL/SQL --> 游标

PL/SQL --> 隐式游标(SQL%FOUND)

批量SQL之 FORALL 语句

批量SQL之 BULK COLLECT 子句

PL/SQL 集合的初始化与赋值

PL/SQL 联合数组与嵌套表
PL/SQL 变长数组
PL/SQL --> PL/SQL记录

SQL tuning 步骤

高效SQL语句必杀技

父游标、子游标及共享游标

绑定变量及其优缺点

dbms_xplan之display_cursor函数的使用

dbms_xplan之display函数的使用

执行计划中各字段各模块描述

使用 EXPLAIN PLAN 获取SQL语句执行计划

上一篇： Oracle datapump expdp/impdp 导入导出数据库时hang住 下一篇： Oracle db_file_mulitblock_read_count参数

你可能感兴趣的:(oracle系统性能优化及管理,oracle转载博文未看)

  • SAX解析xml文件 小猪猪08 xml
    1.创建SAXParserFactory实例 2.通过SAXParserFactory对象获取SAXParser实例 3.创建一个类SAXParserHander继续DefaultHandler，并且实例化这个类 4.SAXParser实例的parse来获取文件     public static void main(String[] args) { //
  • 为什么mysql里的ibdata1文件不断的增长？ brotherlamp linuxlinux运维linux资料linux视频linux运维自学
    我们在 Percona 支持栏目经常收到关于 MySQL 的 ibdata1 文件的这个问题。 当监控服务器发送一个关于 MySQL 服务器存储的报警时，恐慌就开始了 —— 就是说磁盘快要满了。 一番调查后你意识到大多数地盘空间被 InnoDB 的共享表空间 ibdata1 使用。而你已经启用了 innodbfileper_table，所以问题是： ibdata1存了什么？ 当你启用了 i
  • Quartz-quartz.properties配置 eksliang quartz
    其实Quartz JAR文件的org.quartz包下就包含了一个quartz.properties属性配置文件并提供了默认设置。如果需要调整默认配置，可以在类路径下建立一个新的quartz.properties，它将自动被Quartz加载并覆盖默认的设置。   下面是这些默认值的解释 #-----集群的配置 org.quartz.scheduler.instanceName =
  • informatica session的使用 18289753290 workflowsessionlogInformatica
    如果希望workflow存储最近20次的log，在session里的Config  Object设置，log  options做配置，save  session log :sessions  run  ;savesessio log for  these runs:20 session下面的source 里面有个tracing 
  • Scrapy抓取网页时出现CRC check failed 0x471e6e9a != 0x7c07b839L的错误 酷的飞上天空 scrapy
    Scrapy版本0.14.4 出现问题现象： ERROR: Error downloading <GET http://xxxxx  CRC check failed   解决方法   1.设置网络请求时的header中的属性'Accept-Encoding': '*;q=0'   明确表示不支持任何形式的压缩格式，避免程序的解压
  • java Swing小集锦 永夜-极光 java swing
    1.关闭窗体弹出确认对话框   1.1   this.setDefaultCloseOperation (JFrame.DO_NOTHING_ON_CLOSE);   1.2   this.addWindowListener ( new WindowAdapter () { public void windo
  • 强制删除.svn文件夹 随便小屋 java
              在windows上，从别处复制的项目中可能带有.svn文件夹，手动删除太麻烦，并且每个文件夹下都有。所以写了个程序进行删除。因为.svn文件夹在windows上是只读的，所以用File中的delete()和deleteOnExist()方法都不能将其删除，所以只能采用windows命令方式进行删除
  • GET和POST有什么区别？及为什么网上的多数答案都是错的。 aijuans get post
        如果有人问你，GET和POST，有什么区别？你会如何回答？ 我的经历      前几天有人问我这个问题。我说GET是用于获取数据的，POST，一般用于将数据发给服务器之用。     这个答案好像并不是他想要的。于是他继续追问有没有别的区别？我说这就是个名字而已，如果服务器支持，他完全可以把G
  • 谈谈新浪微博背后的那些算法 aoyouzi 谈谈新浪微博背后的那些算法
    本文对微博中常见的问题的对应算法进行了简单的介绍，在实际应用中的算法比介绍的要复杂的多。当然，本文覆盖的主题并不全，比如好友推荐、热点跟踪等就没有涉及到。但古人云“窥一斑而见全豹”，希望本文的介绍能帮助大家更好的理解微博这样的社交网络应用。 微博是一个很多人都在用的社交应用。天天刷微博的人每天都会进行着这样几个操作：原创、转发、回复、阅读、关注、@等。其中，前四个是针对短博文，最后的关注和@则针
  • Connection reset 连接被重置的解决方法 百合不是茶 java字符流连接被重置
    流是java的核心部分,,昨天在做android服务器连接服务器的时候出了问题,就将代码放到java中执行,结果还是一样连接被重置   被重置的代码如下;   客户端代码; package 通信软件服务器; import java.io.BufferedWriter; import java.io.OutputStream; import java.io.O
  • web.xml配置详解之filter bijian1013 javaweb.xmlfilter
    一.定义 <filter> <filter-name>encodingfilter</filter-name> <filter-class>com.my.app.EncodingFilter</filter-class> <init-param> <param-name>encoding<
  • Heritrix Bill_chen 多线程xml算法制造配置管理
    作为纯Java语言开发的、功能强大的网络爬虫Heritrix，其功能极其强大，且扩展性良好，深受热爱搜索技术的盆友们的喜爱，但它配置较为复杂，且源码不好理解，最近又使劲看了下，结合自己的学习和理解，跟大家分享Heritrix的点点滴滴。 Heritrix的下载（http://sourceforge.net/projects/archive-crawler/）安装、配置，就不罗嗦了，可以自己找找资
  • 【Zookeeper】FAQ bit1129 zookeeper
    1.脱离IDE，运行简单的Java客户端程序 #ZkClient是简单的Zookeeper~$ java -cp "./:zookeeper-3.4.6.jar:./lib/*" ZKClient    1. Zookeeper是的Watcher回调是同步操作，需要添加异步处理的代码 2. 如果Zookeeper集群跨越多个机房，那么Leader/
  • The user specified as a definer ('aaa'@'localhost') does not exist 白糖_ localhost
    今天遇到一个客户BUG，当前的jdbc连接用户是root，然后部分删除操作都会报下面这个错误：The user specified as a definer ('aaa'@'localhost') does not exist 最后找原因发现删除操作做了触发器，而触发器里面有这样一句 /*!50017 DEFINER = ''aaa@'localhost' */  原来最初
  • javascript中showModelDialog刷新父页面 bozch JavaScript刷新父页面showModalDialog
    在页面中使用showModalDialog打开模式子页面窗口的时候，如果想在子页面中操作父页面中的某个节点，可以通过如下的进行：       window.showModalDialog('url',self,‘status...’); // 首先中间参数使用self       在子页面使用w
  • 编程之美-买书折扣 bylijinnan 编程之美
    import java.util.Arrays; public class BookDiscount { /**编程之美 买书折扣 书上的贪心算法的分析很有意思，我看了半天看不懂，结果作者说，贪心算法在这个问题上是不适用的。。 下面用动态规划实现。 哈利波特这本书一共有五卷，每卷都是8欧元，如果读者一次购买不同的两卷可扣除5%的折扣，三卷10%，四卷20%，五卷
  • 关于struts2.3.4项目跨站执行脚本以及远程执行漏洞修复概要 chenbowen00 strutsWEB安全
    因为近期负责的几个银行系统软件，需要交付客户，因此客户专门请了安全公司对系统进行了安全评测，结果发现了诸如跨站执行脚本，远程执行漏洞以及弱口令等问题。 下面记录下本次解决的过程以便后续 1、首先从最简单的开始处理，服务器的弱口令问题，首先根据安全工具提供的测试描述中发现应用服务器中存在一个匿名用户，默认是不需要密码的，经过分析发现服务器使用了FTP协议， 而使用ftp协议默认会产生一个匿名用
  • [电力与暖气]煤炭燃烧与电力加温 comsci
          在宇宙中,用贝塔射线观测地球某个部分,看上去,好像一个个马蜂窝,又像珊瑚礁一样,原来是某个国家的采煤区.....       不过,这个采煤区的煤炭看来是要用完了.....那么依赖将起燃烧并取暖的城市,在极度严寒的季节中...该怎么办呢?   &nbs
  • oracle O7_DICTIONARY_ACCESSIBILITY参数 daizj oracle
    O7_DICTIONARY_ACCESSIBILITY参数控制对数据字典的访问.设置为true,如果用户被授予了如select any table等any table权限,用户即使不是dba或sysdba用户也可以访问数据字典.在9i及以上版本默认为false,8i及以前版本默认为true.如果设置为true就可能会带来安全上的一些问题.这也就为什么O7_DICTIONARY_ACCESSIBIL
  • 比较全面的MySQL优化参考 dengkane mysql
    本文整理了一些MySQL的通用优化方法，做个简单的总结分享，旨在帮助那些没有专职MySQL DBA的企业做好基本的优化工作，至于具体的SQL优化，大部分通过加适当的索引即可达到效果，更复杂的就需要具体分析了，可以参考本站的一些优化案例或者联系我，下方有我的联系方式。这是上篇。   1、硬件层相关优化   1.1、CPU相关   在服务器的BIOS设置中，可
  • C语言homework2，有一个逆序打印数字的小算法 dcj3sjt126com c
    #h1#   0、完成课堂例子 1、将一个四位数逆序打印 1234 ==> 4321 实现方法一： # include <stdio.h> int main(void) { int i = 1234; int one = i%10; int two = i / 10 % 10; int three = i / 100 % 10;
  • apacheBench对网站进行压力测试 dcj3sjt126com apachebench
       ab 的全称是 ApacheBench ， 是 Apache 附带的一个小工具 ， 专门用于 HTTP Server 的 benchmark testing ， 可以同时模拟多个并发请求。前段时间看到公司的开发人员也在用它作一些测试，看起来也不错，很简单，也很容易使用，所以今天花一点时间看了一下。 通过下面的一个简单的例子和注释，相信大家可以更容易理解这个工具的使用。
  • 2种办法让HashMap线程安全 flyfoxs javajdkjni
    多线程之--2种办法让HashMap线程安全 多线程之--synchronized 和reentrantlock的优缺点 多线程之--2种JAVA乐观锁的比较( NonfairSync VS. FairSync)     HashMap不是线程安全的,往往在写程序时需要通过一些方法来回避.其实JDK原生的提供了2种方法让HashMap支持线程安全.  
  • Spring Security（04）——认证简介 234390216 Spring Security认证过程
    认证简介 目录 1.1     认证过程 1.2     Web应用的认证过程 1.2.1    ExceptionTranslationFilter 1.2.2    在request之间共享SecurityContext   1
  • Java 位运算 Javahuhui java位运算
    // 左移( << ) 低位补0 // 0000 0000 0000 0000 0000 0000 0000 0110 然后左移2位后，低位补0： // 0000 0000 0000 0000 0000 0000 0001 1000 System.out.println(6 << 2);// 运行结果是24 // 右移( >> ) 高位补"
  • mysql免安装版配置 ldzyz007 mysql
    1、my-small.ini是为了小型数据库而设计的。不应该把这个模型用于含有一些常用项目的数据库。 2、my-medium.ini是为中等规模的数据库而设计的。如果你正在企业中使用RHEL,可能会比这个操作系统的最小RAM需求(256MB)明显多得多的物理内存。由此可见，如果有那么多RAM内存可以使用，自然可以在同一台机器上运行其它服务。 3、my-large.ini是为专用于一个SQL数据
  • MFC和ado数据库使用时遇到的问题 你不认识的休道人 sqlC++mfc
    =================================================================== 第一个 =================================================================== try{ CString sql; sql.Format("select * from p
  • 表单重复提交Double Submits rensanning double
    可能发生的场景： *多次点击提交按钮 *刷新页面 *点击浏览器回退按钮 *直接访问收藏夹中的地址 *重复发送HTTP请求（Ajax） （1）点击按钮后disable该按钮一会儿，这样能避免急躁的用户频繁点击按钮。 这种方法确实有些粗暴，友好一点的可以把按钮的文字变一下做个提示，比如Bootstrap的做法： http://getbootstrap.co
  • Java String 十大常见问题 tomcat_oracle java正则表达式
    　1.字符串比较，使用“==”还是equals()? 　　"=="判断两个引用的是不是同一个内存地址(同一个物理对象)。 　　equals()判断两个字符串的值是否相等。 　　除非你想判断两个string引用是否同一个对象，否则应该总是使用equals()方法。 　　如果你了解字符串的驻留(String Interning)则会更好地理解这个问题。 　 　
  • SpringMVC 登陆拦截器实现登陆控制 xp9802 springMVC
    思路，先登陆后，将登陆信息存储在session中，然后通过拦截器，对系统中的页面和资源进行访问拦截，同时对于登陆本身相关的页面和资源不拦截。   实现方法： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
按字母分类： ABCDEFGHIJKLMNOPQRSTUVWXYZ其他