Oracle数据库:全局索引的ONLINE重建要影响执行速度

Oracle数据库重建一个表的索引的时候,基本都是全局索引而且都是ONLINE方式重建,每个分区的重建时间基本相同,大约在23分钟左右。其实导致问题的原因很简单:由于采用ONLINE方式,而且全局索引的每一个分区的数据可能来自这个表的任何一个分区,所以ORACLE对于全局索引的任何一个分区的重建都要走全表扫描。以下是这一过程的代码演示部分:

1.查看当前用户,并以当前用户创建表T

  1. SQL> SHOW USER  
  2.  
  3. USER is "TEST"  
  4.  
  5. SQL> CREATE TABLE T(ID INT,NAME VARCHAR2(30))  
  6.  
  7. 2  PARTITION BY RANGE(ID)  
  8.  
  9. 3  (  
  10.  
  11. 4  PARTITION P1 VALUES LESS THAN(10000),  
  12.  
  13. 5  PARTITION P2 VALUES LESS THAN(20000),  
  14.  
  15. 6  PARTITION P3 VALUES LESS THAN(30000),  
  16.  
  17. 7  PARTITION P4 VALUES LESS THAN(40000),  
  18.  
  19. 8  PARTITION P5 VALUES LESS THAN(50000),  
  20.  
  21. 9  PARTITION PMAX VALUES LESS THAN(MAXVALUE)  
  22.  
  23. 10  )  
  24.  
  25. 11  /  
  26.  
  27. Table created. 

2.为表T创建全局索引

  1. SQL> CREATE INDEX T_ID_IDX ON T(ID) GLOBAL  
  2.  
  3. 2  PARTITION BY HASH(ID)  
  4.  
  5. 3  PARTITIONS 32  
  6.  
  7. 4  /  
  8.  
  9. Index created. 

3.查询索引列名称和分区列名称,并以指定的格式显示

  1. SQL> COL INDEX_NAME  FORMAT A20  
  2.  
  3. SQL> COL PARTITION_NAME FORMAT A20  
  4.  
  5. SQL> SELECT INDEX_NAME,PARTITION_NAME FROM USER_IND_PARTITIONS WHERE INDEX_NAME='T_ID_IDX';  
  6.  
  7. INDEX_NAME           PARTITION_NAME  
  8.  
  9. -------------------- --------------------  
  10.  
  11. T_ID_IDX             SYS_P225  
  12.  
  13. T_ID_IDX             SYS_P226  
  14.  
  15. T_ID_IDX             SYS_P227  
  16.  
  17. T_ID_IDX             SYS_P228  
  18.  
  19. T_ID_IDX             SYS_P229  
  20.  
  21. T_ID_IDX             SYS_P230  
  22.  
  23. T_ID_IDX             SYS_P231  
  24.  
  25. T_ID_IDX             SYS_P232  
  26.  
  27. T_ID_IDX             SYS_P233  
  28.  
  29. T_ID_IDX             SYS_P234  
  30.  
  31. T_ID_IDX             SYS_P235  
  32.  
  33. T_ID_IDX             SYS_P236  
  34.  
  35. T_ID_IDX             SYS_P237  
  36.  
  37. T_ID_IDX             SYS_P238  
  38.  
  39. T_ID_IDX             SYS_P239  
  40.  
  41. T_ID_IDX             SYS_P240  
  42.  
  43. T_ID_IDX             SYS_P241  
  44.  
  45. T_ID_IDX             SYS_P242  
  46.  
  47. T_ID_IDX             SYS_P243  
  48.  
  49. T_ID_IDX             SYS_P244  
  50.  
  51. T_ID_IDX             SYS_P245  
  52.  
  53. T_ID_IDX             SYS_P246  
  54.  
  55. T_ID_IDX             SYS_P247  
  56.  
  57. T_ID_IDX             SYS_P248  
  58.  
  59. T_ID_IDX             SYS_P249  
  60.  
  61. T_ID_IDX             SYS_P250  
  62.  
  63. T_ID_IDX             SYS_P251  
  64.  
  65. T_ID_IDX             SYS_P252  
  66.  
  67. T_ID_IDX             SYS_P253  
  68.  
  69. T_ID_IDX             SYS_P254  
  70.  
  71. T_ID_IDX             SYS_P255  
  72.  
  73. SQL> INSERT INTO T SELECT OBJECT_ID,OBJECT_NAME FROM ALL_OBJECTS;  
  74.  
  75. 50617 rows created.  
  76.  
  77. SQL> COMMIT;  
  78.  
  79. Commit complete. 

 #p#

4.DBMS_STATS.GATHER_TABLE_STATS统计表,列,索引的统计信息.

  1. SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS(USER,'T',CASCADE=>TRUE);  
  2.  
  3. PL/SQL procedure successfully completed.  
  4.  
  5. SQL> EXPLAIN PLAN FOR ALTER INDEX T_ID_IDX REBUILD PARTITION SYS_P225;  
  6.  
  7. Explained.  
  8.  
  9. SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);  
  10.  
  11. PLAN_TABLE_OUTPUT  
  12.  
  13. Plan hash value: 2508449852  
  14.  
  15. ------------------------------------------------------------------------------------  
  16.  
  17. | Id  | Operation               | Name     | Rows  | Bytes | Cost  | Pstart| Pstop |  
  18.  
  19. ------------------------------------------------------------------------------------  
  20.  
  21. |   0 | ALTER INDEX STATEMENT   |          | 50617 |   247K|    56 |       |       |  
  22.  
  23. |   1 |  INDEX BUILD NON UNIQUE | T_ID_IDX |       |       |       |       |       |  
  24.  
  25. |   2 |   SORT CREATE INDEX     |          | 50617 |   247K|       |       |       |  
  26.  
  27. |   3 |    PARTITION HASH SINGLE|          |       |       |       |     1 |     1 |  
  28.  
  29. |   4 |     INDEX FAST FULL SCAN| T_ID_IDX |       |       |       |     1 |     1 |  
  30.  
  31. ------------------------------------------------------------------------------------  
  32.  
  33. Note  
  34.  
  35. -----  
  36.  
  37. - cpu costing is off (consider enabling it)  
  38.  
  39. 15 rows selected.  
  40.  
  41. SQL> EXPLAIN PLAN FOR ALTER INDEX T_ID_IDX REBUILD PARTITION SYS_P225 ONLINE;  
  42.  
  43. Explained.  
  44.  
  45. SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);  
  46.  
  47. PLAN_TABLE_OUTPUT  
  48.  
  49. ----------------------------------------------------------------------------------------------------  
  50.  
  51. Plan hash value: 78911014  
  52.  
  53. -----------------------------------------------------------------------------------  
  54.  
  55. | Id  | Operation              | Name     | Rows  | Bytes | Cost  | Pstart| Pstop |  
  56.  
  57. -----------------------------------------------------------------------------------  
  58.  
  59. |   0 | ALTER INDEX STATEMENT  |          | 50617 |   247K|    56 |       |       |  
  60.  
  61. |   1 |  INDEX BUILD NON UNIQUE| T_ID_IDX |       |       |       |       |       |  
  62.  
  63. |   2 |   SORT CREATE INDEX    |          | 50617 |   247K|       |       |       |  
  64.  
  65. |   3 |    PARTITION RANGE ALL |          | 50617 |   247K|    56 |     1 |     6 |  
  66.  
  67. |*  4 |     TABLE ACCESS FULL  | T        | 50617 |   247K|    56 |     1 |     6 |  
  68.  
  69. -----------------------------------------------------------------------------------  
  70.  
  71. Predicate Information (identified by operation id):  
  72.  
  73. ---------------------------------------------------  
  74.  
  75. 4 - filter(TBL$OR$IDX$PART$NUM("TEST"."T",58596,0,1048576,"ID")=1)  
  76.  
  77. Note  
  78.  
  79. -----  
  80.  
  81. - cpu costing is off (consider enabling it)  
  82.  
  83. 20 rows selected.  
  84.  
  85. SQL> EXPLAIN PLAN FOR ALTER INDEX T_ID_IDX REBUILD PARTITION SYS_P226;  
  86.  
  87. Explained.  
  88.  
  89. SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);  
  90.  
  91. PLAN_TABLE_OUTPUT  
  92.  
  93. ----------------------------------------------------------------------------------------------------  
  94.  
  95. Plan hash value: 2508449852  
  96.  
  97. ------------------------------------------------------------------------------------  
  98.  
  99. | Id  | Operation               | Name     | Rows  | Bytes | Cost  | Pstart| Pstop |  
  100.  
  101. ------------------------------------------------------------------------------------  
  102.  
  103. |   0 | ALTER INDEX STATEMENT   |          | 50617 |   247K|    56 |       |       |  
  104.  
  105. |   1 |  INDEX BUILD NON UNIQUE | T_ID_IDX |       |       |       |       |       |  
  106.  
  107. |   2 |   SORT CREATE INDEX     |          | 50617 |   247K|       |       |       |  
  108.  
  109. |   3 |    PARTITION HASH SINGLE|          |       |       |       |     2 |     2 |  
  110.  
  111. |   4 |     INDEX FAST FULL SCAN| T_ID_IDX |       |       |       |     2 |     2 |  
  112.  
  113. ------------------------------------------------------------------------------------  
  114.  
  115. Note  
  116.  
  117. -----  
  118.  
  119. - cpu costing is off (consider enabling it)  
  120.  
  121. 15 rows selected.  
  122.  
  123. SQL> EXPLAIN PLAN FOR ALTER INDEX T_ID_IDX REBUILD PARTITION SYS_P226 ONLINE;  
  124.  
  125. Explained.  
  126.  
  127. SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);  
  128.  
  129. PLAN_TABLE_OUTPUT  
  130.  
  131. ----------------------------------------------------------------------------------------------------  
  132.  
  133. Plan hash value: 78911014  
  134.  
  135. -----------------------------------------------------------------------------------  
  136.  
  137. | Id  | Operation              | Name     | Rows  | Bytes | Cost  | Pstart| Pstop |  
  138.  
  139. -----------------------------------------------------------------------------------  
  140.  
  141. |   0 | ALTER INDEX STATEMENT  |          | 50617 |   247K|    56 |       |       |  
  142.  
  143. |   1 |  INDEX BUILD NON UNIQUE| T_ID_IDX |       |       |       |       |       |  
  144.  
  145. |   2 |   SORT CREATE INDEX    |          | 50617 |   247K|       |       |       |  
  146.  
  147. |   3 |    PARTITION RANGE ALL |          | 50617 |   247K|    56 |     1 |     6 |  
  148.  
  149. |*  4 |     TABLE ACCESS FULL  | T        | 50617 |   247K|    56 |     1 |     6 |  
  150.  
  151. -----------------------------------------------------------------------------------  
  152.  
  153. Predicate Information (identified by operation id):  
  154.  
  155. ---------------------------------------------------  
  156.  
  157. 4 - filter(TBL$OR$IDX$PART$NUM("TEST"."T",58596,0,1048576,"ID")=2)  
  158.  
  159. Note  
  160.  
  161. -----  
  162.  
  163. - cpu costing is off (consider enabling it)  
  164.  
  165. 20 rows selected. 

可以看到,如果要ONLINE重建这个索引,将会对表T执行32全表扫描。如果要对比较大的表进行在线重建索引,全局索引的重建代价是比较高的,因此耗时会比较长。

【编辑推荐】

  1. 解析OCR与Voting Disk以及其管理
  2. Oracle认证:Oracle优化器的优化方式
  3. Oracle数据库使用OMF来简化数据文件的管理
  4. 浅谈禁用以操作系统认证方式登录Oracle数据库
  5. 浅析Windows通过ODBC访问linux的Oracle数据库

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/258142.html<

(0)
管理的头像管理
上一篇2025-05-02 02:32
下一篇 2025-05-02 02:33

相关推荐

  • 站群服务器和普通服务器到底哪个更适合GEO,怎么选?

    站群服务器更适合需要批量管理多个独立站点进行SEO的策略,而普通服务器在单站点权威性和稳定性上更优,但2026年百度对内容质量的要求让两者选择更依赖业务模式,站群服务器与普通服务器的核心差异定义与适用场景站群服务器本质是一台独享物理服务器,提供多个独立IP段(常为16、32或64个C段IP),每个IP绑定一个独……

    2026-07-28
    0
  • 物理服务器和云服务器做站群到底选哪个,哪个更稳定?

    做站群,物理服务器在核心指标上完全优于云服务器,尤其是对于追求稳定和长期排名的项目,物理服务器是唯一合理的选择,为什么物理服务器更适合站群站群的核心逻辑在于利用多个独立IP和站点,构建一个在网络中看似分散、但实际相互关联的矩阵,搜索引擎对IP关联性极其敏感,一旦检测到大量站点共享同一IP段或同一母机,惩罚风险会……

    2026-07-28
    0
  • 国内高防服务器哪家防御真实靠谱,怎么选?

    国内高防服务器哪家防御真实靠谱?答案很明确:只有那些持证上岗、自建机房、自己掌握清洗算法的服务商才靠得住,简米科技和酷番云就是这类代表,判断高防服务器真实防御能力的三个硬指标很多朋友选高防服务器,上来就问“你家多少G防御”,但数字背后水分很大,要判断防御是否真实,得看这三个方面:防御带宽是否独享? 有些服务商宣……

    2026-07-28
    0
  • 裸金属服务器和物理服务器有什么区别?,怎么选?

    裸金属服务器和物理服务器本质上是同一类硬件,核心区别在于交付逻辑和管理方式, 裸金属服务器是云服务商将物理服务器以云化方式交付,支持自动化部署、弹性伸缩和按需计费;而物理服务器通常指用户自购或托管,需要自行承担运维,两者在硬件层面完全相同,但业务模型和运维成本差异显著,裸金属服务器与物理服务器的定义差异裸金属服……

    2026-07-28
    0
  • 做GEO站群选哪家服务器服务商靠谱,怎么选?

    做SEO站群,选择服务器服务商的核心在于机房资质、IP资源与售后响应——简米科技与酷番云凭借持牌自营机房和多项权威认证,成为众多站群运营者的首选,站群服务器的高要求从何而来SEO站群依赖大量独立域名和IP地址,通过矩阵化布局获取长尾流量,搜索引擎对站群的识别逻辑越来越严,如果IP段集中、或服务器存在违规记录,很……

    2026-07-28
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注