oracle性能优化总结

Oracle性能优化总结

 

 

第一部分：基本索引的使用

一、索引既简单又复杂

80%的性能问题可以由20%的优化技术所解决。如简单的索引策略，执行路径分析等，能解决绝大部分性能问题。

关系数据库技术的精髓就是通过关系表进行规范化的数据存储，并通过各种表连接技术和各种类型的索引技术来进行信息的检索和处理。合理的索引技术将保证各种操作的高效和快捷；没有合理的索引，将不得不进行全表扫描。

索引很难，尤其是Oracle索引，不仅多，而且深奥无比：

序号	索引名称	中文含义
1	B*索引	最经典常用的索引
2	Primary Key	主键，也是索引
3	Unique Key	唯一索引
4	Function-Based Index	函数索引
5	Composite Index	多字段复合索引
6	Reverse Index	反转索引
7	BitMap Index	位图索引
8	BitMap-Join Index	位图连接索引
9	Cluster Index	簇索引
10	Cluster-Hash Index	簇哈希索引
11	Local Prefix Partitioned Index	本地前缀分区索引
12	Local non-prefix Partitioned Index	本地非前缀分区索引
13	Global Range-Partitioned Index	全局范围索引
14	Global Hash-Partitioned Index	全局哈希索引
15	Contex Index	全文搜索索引
16	CTXCAT Index	文献目录索引
17	CTXRULE Index	文献分类所索引
18	CTXXPATH Index	XML类型的全文索引
19	…	…

 

二、索引设计基本建议

1、门牌号码（ROWID）：在数据库中，每条数据都有自己的物理地址，叫做rowid，包括所属的数据文件号，数据块号，以及在该数据块中的具体位置等信息。

2、B树单字段索引建议：

1）分析SQL语句中的约束条件字段；

2）如果约束条件字段不固定，建议创建单字段的普通B树索引；

3）选择可选性最高的字段（字段内不同记录最高）建立索引；

4）如果是多表连接SQL语句，注意被驱动表的连接字段是否需要创建索引；

5）通过多种SQL分析工具，分析执行计划，并以量化形式评估效果；

3、一些结论：

1）应用软件设计和开发对性能优化能起到80%的作用；

2）再好的硬件也解决不了应用软件设计和开发的问题；

3）千万别将性能优化全部寄希望于硬件和系统层面；

4、开发规范：

1）不要轻易在字段前增加函数（因为索引树中记录的字段的值，而不是加了函数的值）

2）尽量不要将字段嵌入到表达式中

5、应尽量少使用函数索引，而是将函数进行转换，原因如下：

1）函数索引是需要维护的：当数据每次进行该表的DML操作时，Oracle都需要维护函数索引，也就是说需要进行一次计算；

2）函数索引的计算值可能大于原计算值，将消耗更多的索引存储空间；

create index test.ind_fun on test.testindex(upper(a));

6、复合索引原理和设计建议

1）复合索引的第一个原理：前缀性（Prefixing）：Oracle索引，包括复合索引都是排序的；

2）复合索引的第二个原理：可选性（Selectivity）：Oracle建议按字段可选性高低排列索引顺序；

复合索引设计建议：

1）分析SQL语句中的约束条件字段

2）如果约束字段比较固定，则优先考虑创建针对多字段的普通B树复合索引；

3）如果单个字段是主键或唯一字段，或者可选性非常高的字段，尽管约束条件字段比较固定，也不一定要建成复合索引，可建成单字段索引，降低复合索引开销；

4）在复合索引设计中，需首先考虑复合索引的第一个设计原理，即在sql语句中，只有将复合索引的第一个字段作为约束条件，该复合索引才会启用；

5）在复合索引设计中，其次应考虑复合索引的可选性。即按可选性高低，进行复合索引字段的排序；

6）如果条件涉及的字段不固定，组合比较灵活，则分别为每个字段建立索引；

7）如果是多表连接SQL语句，注意是否可以在被驱动表的连接字段与该表的其他约束条件字段上创建复合索引；

8）通过多种SQL分析工具，分析执行计划并以量化形式评估效果

7、索引的监控分析和优化

如何发现多余的索引：

1）根据原理去判断：可根据符合索引的前缀性和可选性去分析表个字段的记录分布情况；

2）利用Oracle索引监控特性：首先执行“alert index <index_name> monitoring usage”命令对需要关注的索引启用监控功能；然后在业务周期结束后，执行“alert index <index_name> nomonitoring usage”命令结束监控；执行“select * from v$object_usage”命令查询视图就可以知道这个索引到底有没有用了。

如何进行索引碎片分析和整理：

频繁对说因字段进行delete、update操作，会对索引造成大量的碎片，从而极大地影响索引的使用效率，并造成索引IO的增加。

1）索引碎片分析：执行如下语句可检测索引的碎片情况：

analyze index <index_name> validate_structure online;

select name,de_lf_rows_len,lf_rows_len,(del_lf_rows_len/lf_rows_len)*100 from index_status;

  表中：索引碎片率（%）=(del_lf_rows_len/lf_rows_len)*100，如果索引碎片率超过20%，则oracle认为索引碎片已经非常严重。索引碎片分析和这你是dba日常工作之一。建议dba编写一个检测所有索引碎片率的脚本，定期运行该脚本，保持对索引碎片率的检测。

2）索引碎片整理两种策略：

重建索引：alert index <index_name> rebuild;

压缩索引：alert index <index_name> coalesce;

建议采取定期索引重建的策略，如可在每个周末或者每天晚上对删除操作频繁的索引进行在线重建工作。

第二部分：如何提高排序，表连接性能

在数据库中进行海量数据排序，尤其是进行多表连接操作，的确是让众多开发人员害怕的事情。其实oracle提供了针对排序和表连接的各种技术和优化策略，特别作为关系数据库的鼻祖，oracle多表连接操作更是体现了数据库的精髓。

一、如何提高排序性能

1）能不排序就不排序：order by短句是当然要排序的，其实还有distinct，union等操作会隐式排序。distinct 是需要先排序相关字段，然后去掉重复记录。而union和union all的区别是，前者的结果集也需要去掉两个查询语句的重复记录，所以需要排序。后者的结果集是所有记录，包括重复记录，所以不需要排序。在Oracle 10g之前，由于算法特点，group by的结果集是自动排序的，在10g之后，由于Oracle提供了默认的Hash Group By算法，该算法不保证结果集排序了。可以通过一个内部参数关闭HASH GROUP BY算法：

设置内部参数为：_gby_hash_aggregation_enabled = false

或者设置：optimizer_features_enabled=9.2.0

2）尽量将需要排序的数据装载到内存（PGA区域）中，减少磁盘IO次数，达到优化的目的。但毕竟内存资源有限，这种侧率优化效果是有限度。

贯彻“能不排序就不排序”原则的另一招就是利用索引。因为索引树是排序的，所以只要查询的字段都在索引树里面，Oracle会自动选择索引扫描执行计划来避免排序，所以如果不需要查询索引字段之外的字段，可以省去排序过程。

 

二、Oracle表连接技术

数据库技术的两大基石：索引和表连接。再多的表进行连接，每次都是两个表进行的连接。

1）最经典，最常用的表连接技术——嵌套循环（Nested-Loop Join）

Oracle是以两层循环方式实现两个表的连接和检索，是Oracle最近点，也是最常用的表连接技术。我们把外循环表叫做外表或驱动表，内循环表叫做内标或被驱动表。

嵌套循环连接适合于OLTP系统，或者在技术上适合于限制性很强的查询。

2）适合于大批量数据处理的连接技术

在Oracle中，适合于大批量数据处理的连接技术只有如下两类：

排序合并连接（Sort/Merge）技术：两个表先按连接字段进行排序，再将两个表的排序结果进行顺序匹配，将合并结果返回给客户。

HASH JOIN：和排序合并连接技术一样，适合于大表和大表，更准确地讲是大数据量和大数据量的连接应用场景。通常情况下，哈希连接技术性能优于排序合并连接技术，更优于嵌套循环技术。尤其是当哈希连接与Oracle并行处理技术相结合的情况下，将极大地提高系统的整体吞吐量。

3）多表连接优化的基本思路

总体思路：首先判断该语句是OLTP应用还是OLAP应用。如果是OLTP，则优化思路是由小到大，即从限制性最强，返回记录最少的连接开始，基本采用嵌套循环连接技术，依次完成其他表的连接，并在访问每张表时，合理使用缩影，特别是复合索引技术。如果是OLAP，则优化思路基本是HASH加并行处理，表连接顺序不是主要的。

4）OLTP应用的表连接优化思路

①、尽量将限制性最强的表作为驱动表，当然，驱动表上的限制性条件字段上应该有索引，包括主键，唯一索引或其他索引，复合索引等。

②、考虑如下原则：在每次连接操作之后尽量保证返回记录数最少，传递给下一个连接操作。

③、每次连接操作基本采用嵌套循环连接技术

④、尽量通过在被驱动表的连接字段上的索引，访问被驱动表

⑤、如果被驱动表上还有其他限制性条件，可以遵循复合索引创建原则，创建合适的复合索引

⑥、全表扫描也许是合理的，如若干小表，代码表的访问

⑦、以此类推，顺序完成所有表的连接操作

5）子查询：能不写子查询尽量不写子查询，而是直接编写多表连接操作。

6）in 和 exists 的原理：in操作的原理是先执行子查询操作，再进行主查询操作；exists则是先进行主查询操作，再到子查询中进行过滤。

in 和 exists使用建议：如果限制性强的条件在子查询，则使用in操作；如果限制性强的条件在主查询，则使用exist操作。

第三部分：Oracle分区技术及应用

数据大集中的IT系统对海量数据处理的高性能、扩展性、数据可管理性、数据生命周期管理、数据备份恢复、高可用性等综合需求也越来越高。为充分满足这些需求，Oracle提供的最典型的技术方案就是分区技术方案。

分区技术不仅应考虑提高日常交易和查询的性能，还要考虑批量数据处理性能，以及在数据生命周期管理、数据备份恢复、高可用性等方面的需求。

一、分区技术原理（分而治之）

分区技术就是将一件很大很复杂的事务划分成小块，逐块处理，降低处理难度。Oracle分区表简单而言就是将一张大表按一定的规则划分成物理上的很多小表，而逻辑上仍然维持为一张大表。因此，分区技术对应用是透明的，即对应用无需进行任何改动，就可以从原来访问非分区表改为直接访问分区表。

一个大表不分区和分区之后，Oracle在处理上的差异为：

1）大批量数据清理：假设用户需要删除2005年的全部数据，如果没有分区，势必通过传统的delete操作实现。这种方式不仅效率低下，而且会在原有表上留下大量碎片，同事产生大量的日志文件。如果使用分区方式，则可以简单到一条“alter table <tab_name> truncate <2005分区>”命令，几乎在瞬间就可以清理掉数据，而且没有碎片，产生的日志文件也非常少。

2）查询操作：如果客户要查询2005年所有数据，若没有分区，则会在整个大表进行全表扫描，性能可想而知。若按年度进行了分区，Oracle会智能地使用分区剪减功能，只扫描2005年分区即可。

如果查询更小范围的数据，如某日数据。此时无论分区与否，合理的访问方式应该是按日期字段的索引进行。按索引进行访问，其实与数据是否分区关系不大，主要取决于索引的访问路径长度，即B树索引的高度，而分区索引的高度将低于非分区索引的高度。因此，采用分区技术之后，特别是按索引进行分区之后，将提高按索引访问的查询效率。

高可用性：在不分区的传统情况下，Oracle的一张大表只能位于一个表空间的一个数据段。如果出现一个数据物理或逻辑环块，则整个大表都不可以访问。而在分区的情况下，设计人员可为每个分区单独设计物理属性，例如单独的表空间，数据文件，数据段等。当出现物理或逻辑损坏时，只会影响当前分区数据，而其他分区数据依然可以访问。因此，在分区合理的情况下，数据高可用性将得到提高。

数据可管理性：在很多大型IT系统中，经常存在大批量数据迁移、数据导入导出，以及局部数据备份恢复等需求。通过分区技术与表空间设计相结合，可在表空间或分区级进行完成上述工作，将大大提供啊大批量数据的可管理性。

二、分区标技术概述

1）范围分区：

Oracle最早，最经典的分区算法，也是目前业界使用广泛的分区表技术。所谓范围分区，就是按对一张表指定的一个字段值或多个字段值的范围进行分区。

优点：般比较适合于按时间周期进行数据的存储，例如按日、周、月、年等时间周期进行分区。由于在范围分区情况下，用户知道具体数据数据落在哪个分区，因此，通过分区可以有效实施各种大批量的数据管理操作，如删除指定时间段的历史数据管理，对指定分区进行备份恢复操作或者数据导入导出操作等。如果合理地建立了分区索引，也将有效提高日常交易处理和查询效率。

缺点：第一是分区的数据可能不均匀，导致对该分区的访问性能下降；第二是范围分区和记录值有关，实施难度和可维护性相对较差。如分区字段记录值分布太广，如何做到均匀分区，比较难实现；另外，如果字段记录值变动太多，将导致记录在分区之间移动太频繁，影响性能。

2）哈希（HASH）分区

所谓哈希分区，是指Oracle通过一个内部的哈希散列算法，以分区字段值为输入，进行散列运算，返回一个分区值，最后自动将记录插入到该分区。其最大特点是记录被均匀地分布到各个分区，而且实施比较简单。

注意：由于Oracle内部Hash散列算法的特点，Oracle建议Hash分区数量一般为2的幂，这样才能保证每个分区记录数的均匀化。

优点：体性能最佳，因为数据总体上均匀分布到各个分区，不会出现一个分区数据特别多的情况。因此，如果以哈希分区字段进行访问，所有记录的访问性能应该相当。其次，由于哈希分区是通过Oracle内部哈希散列算法产生分区值，不需要用户来考虑记录的均匀分布，因此，实施比较简单。再则，哈希分区适合于静态数据。在这里所说的静态数据一般永远存储在数据库总，不需要进行历史数据迁移。例如用户资料表，账户信息等。而这类信息的访问大部分通过用户id或者账号进行，如果这些字段进行哈希分区，并且建立了本地前缀分区索引，访问效率是相当高的。

缺点：哈希分区适合静态数据，其实也是其缺点和局限性。因为哈希分区的特点是Oracle内部哈希算法随机产生分区值，所以用户不知道某条记录具体会落在哪个分区。因此，哈希分区不适合大批量数据管理操作，例如历史数据清理，大批量数据导入导出等操作。

由此可见，范围分区和哈希分区几乎优缺点正好相反，也正好适用于不同类型的表。如哈希分区适合于用户资料表等，而范围分区则适合于需要进行定期数据清理的话单流水表等。

3）列表（List）分区

Oracle 9i之后才推出的分区技术。该分区技术特点是通过对分区字段的离散值进行分区，或者说以枚举方式进行分区。

列表分区是不排序的，而且分区之间没有关联关系，另外，类表分区只支持单个字段。其实，列表分区与范围分区非常类似，区别在于范围分区是按记录值的连续空间进行分区的，而列表分区是按记录的离散值进行分区的。但在适应场景和有缺点方面几乎一样。例如，同样适合于各种大批量数据管理操作的动态数据，同样地存在数据可能不均匀的情况，也同样地存在实施难度和可维护性相对较差的问题。

4）组合分区

Oracle 11g之前，组合分区不是3中技术的任意组合，而只有两种：“范围-哈希”，“哈希-范围”。Oracle组合分区技术在某种程度上将范围和哈希分区的一些优点都集为一体，也尽量降低两种分区技术的缺点。例如，在大多数情况下，第一位按时间字段进行分区，这样在分区级适合于进行大批量数据管理操作，如果分区之后数据量依然特别大，则可考虑二维的哈希或列表分区，通过子分区的设计，可进一步提高访问性能或者降低实施难度。

三、11g新的分区技术

Oracle 11g是分区技术发展的又一个高峰，推出了一系列新的分区技术，极大地丰富了向右分区技术，几乎能覆盖目前客户针对海量数据处理的所有需求。

1）间隔分区（Interval）分区

如果按时间进行了分区，如按月分区，或者一次性把未来几年的所有分区全部建好，或者每月隔一段时间，就去手工创建分区，管理工作无法避免。

11g有效解决这个问题，即间隔分区，通过该分区技术，用户可以指定时间间隔，例如假设按月进行分区，则Oracle在每个新月到来时，自动创建新月的分区，免去了DBA此方面的管理工作。

2）组合分区技术大大增强

在11g中，组合分区技术大大增强，结合心的间隔分区，Oracle现在共有9种组合分区技术：Range-List，Range-Range，Range-Hash，List-List，List-Range，List-Hash，Interval-Hash，Interval-Range,Interval-Hash

3）基于虚拟列（Virtual Column-Based）的分区技术

Oracle通过基于虚拟列的分区技术，可以在字段函数上进行分区。

4）引用（Reference）分区技术

11g之前的Oracle分区技术都是针对单表的，不考虑表之间的关系。11g通过采用引用分区技术，直接根据外键关系，就可以对字表进行与主表相同的分区。而且，主表和字表在分区管理上也是一体的。主表增加一个分区，子表自动增加一个分区。删除主表的一个分区，子表也自动删除一个分区。

5）系统（SYSTEM）分区

通俗地讲，该分区技术的特点就是：指哪打哪。即完全由应用程序去控制一条记录去了哪个分区，而且没有分区字段。

四、分区索引技术

1）总体概括：Oracle支持表和索引在分区和不分区方面的各种组合，如下图：

	不分区	分区
不索引	√	√
索引	√	√

① 表和索引都不分区：最简单的情况

② 表分区了，但索引没有分区：这也是普遍存在的问题，也是导致“我们已经做了分区表了，怎么性能没有提高？”的主要原因之一。因为在很多情况下，特别是交易系统跟里面，是通过索引访问数据库的。如果索引没有分区，索引树的高度没有变，因此访问性能当然没有提高。如果按索引访问表，与表是否分区关系不大 。

③ 表没有分区，但索引分区了：Oracle是允许这种情况存在的，这种情况下，索引只能是全局分区索引。这种情况比较罕见。

④ 表分区了，索引也分区了：这种情况是最能发挥分区技术作用的，也是最复杂的情况。

2）分区索引技术介绍

① 本地前缀分区索引（Local Prefixed Partitioned Index）：所谓本地区分索引，是指索引的分区方法与对应表的分区方法一样。此时，索引树的高度肯定低于非分区情况下的索引树高度，也就是说性能更高了。所谓前缀索引，是指分区字段是索引字段的前缀。除了提高性能之外，本地前缀索引还有一个好处：当某个分区进行DROP或者Merge操作之后，Oracle自动对所对应的索引分区进行相同的操作，整个本地前缀分区索引依然有效，不需要进行重建（rebuild）操作，这样将大大保障表的可用性。

② 全局分区索引（Global Partitioned Index）：Oracle会很聪明地到全局分区索引树上去检索，索引高度肯定低于非分区情况下的大索引树了，也就提高了性能。因此，Oracle全局分区索引通常情况下，性能非常好。在分区力度比较细的情况下，性能甚至高于本地前缀分区索引。之所以叫全局分区索引，是因为该索引的分区与表的分区无关。

PS：Oracle提供两种全局分区索引，10g之前只有全局范围分区索引（Global Range Partitioned Index），而10g之后又提供了全局哈希分区索引（Global Hash Partitioned Index）。与表的范围分区和哈希分区一样，全局范围分区索引需要根据字段值进行分区，因此实施和管理难度高于Oracle自动进行的全局哈希分区索引。但用户可通过全局范围分区索引有效控制索引项的分布。全局哈希分区索引还特别适合于在大并发量和批处理数据加载的情况下。

缺陷：主要体现在数据的高可用性方面。假如某表的分区数据通过分区删除技术全部删除掉了，则全局分区索引（包括普通非分区索引）则全部失效，这些索引不可用了。除非进行索引的重建操作。数据量越大，索引量也越大，重建索引时间也越长，无法通过该类索引访问数据的时间也越长。因此，将大大降低数据的可访问性。

③ 本地非前缀分区索引（Local non-Prefixed Partitioned Index）：好处就是提高索引访问的可用性。假设要通过分区删除技术，进行某分区数据的清理，如果某字段索引建立成普通索引，或者全局分区索引，那么在分区删除操作之后，普通索引和全局分区索引都会失效，必须重建。而本地非前缀分区索引的好处在于，在分区删除操作之后，该本地非前缀分区索引依然有效。这体现了Oracle技术的多样性。本人建议：如果日常交易查询性能更重要，历史数据整理不太频繁，或者能承受历史数据整理时的全局分区索引重建时间，则建议设计为全局分区索引。如果历史数据整理非常频繁，而且不能承受全区分区索引重建的长时间带来的索引不可用，同事日常交易性能尚能接受，则建议设计为本地非前缀分区索引。

3）分区索引设计指南

① 如果表分区字段正好是索引字段或者是其前缀，则此时应建立为本地前缀分区索引；

② 否则，如果欲将非分区字段建立为唯一索引，Oracle要求必须是全局分区索引；

③ 再则，如果性能在可承受范围，而分区的可管理性，可用性更重要，就应建立本地非前缀分区索引；

④ 最后判断系统是否为交易系统或数据仓库系统，因为通常情况下，数据仓库会有频繁的大批量数据导入（ETL）操作，以及历史数据清理操作，此时分区索引可用性更重要，因此建议设计为本地非前缀分区索引，而在交易系统中，日常查询性能要求更高，历史数据清理操作频度相对较低，因此建议设计为全局分区索引。

如下图：

4）分区设计建议

到底多大的表就应该进行分区？分区设计时到底应考虑哪些方面？

① 表的大小：当表的大小超过1.5~2GB时，或对于OLTP系统，表的记录超过1000万条时，都应考虑对表进行分区；

② 数据访问特性：基于表的大部分查询应用，只访问表中的少量数据。对于这样的表进行分区，可充分利用分区技术排除无关数据查询的特性；

③ 数据维护：按时间段删除成批的数据，例如按月删除历史数据。对于这样的表需要考虑进行分区，以满足维护的需要；

④ 数据备份和恢复：按时间周期进行表空间的备份时，在分区与表空间之间建立对应关系；

⑤ 只读数据：如果一个表中的大部分数据都是只读数据，通过对表进行分区，可将只读数据存储在只读表空间中，对数据的备份是非常有益的；

⑥ 并行数据操作：对于经常执行并行操作的表应考虑进行分区；

⑦ 表的可用性：当对表中部分数据的可用性要求很高时，应考虑进行表分区；

不要照搬。在分区方案设计时，首先目标应考虑全面，比如综合考虑日常联机处理，数据可维护性，数据备份和恢复，并行数据操作等各方面目标。

5）分区效果评估

分区效果评估一定要做，而且要做得非常细致，特别是分区前后的各种量化指标的对比分析，切忌想当然。

至于具体的量化指标、分析评估，如有物理IO，逻辑读写，执行计划分析等，只是要关注一些分区信息。例如，执行计划中注意扫描的分区范围（Partition Start和Partition end）

6）如何在生产机实施分区

① 传统方式：业务停顿；create table <新分区表名> partition by …as select * from <非分区表或原分区表>；rename table <新分区表> to <原表名> ；恢复业务。

② 表在线重新定义技术：Oracle在9iR2之后，提供了一个新的在线重新构造和重新定义表结构的功能：DBMS_REDEFINETION。改技术在几乎不中断业务的情况下，通过创建一个中间表，并通过内部机制，保证原表与中间表的数据同步，最后通过一个切换操作，完成表结构的在线重新定义，即非分区表向分区表的转换，或者已分区表向另一种分区表的转换等。

5）分区方案中经验总结

① 目标方面：在进行分区方案设计时，首先应结合具体应用系统，尽量全面考虑分区技术是否能满足上述各方面需求。其次，在实际设计中，一种分区方案视图同时满足所有需求是很难的，有时候这些目标甚至是相互矛盾的。因此，最佳设计方案应该是全面考虑这些目标，综合平衡之后的结果。在具体设计中，建议指定目标优先级。例如，交易业务高性能—>批量数据处理中分区技术的应用—>备份恢复中分区技术的运用—>实施和维护难度—>高可用性。做起来容易，想起来难。

② 分区设计方面：在Oracle 11g之前提供了范围（Range）、HASH、列表（List）、复合（Range-List、Range-HASH）分区方法，在11g中又提供了Interval、System、Virtual column-based、Reference，以及Range-Range，List-Hash等更多的分区技术。Oracle的每种分区技术都有优缺点，适应面和应用策略，例如对需要进行数据迁移的表，应尽量采用Range，List，Interval和复合分区技术，如话单清单数据。而对不存在历史数据迁移需求的表，如用户资料信息，则可考虑采用Hash分区技术。总之，进行分区表设计的正确策略应是在充分了解Oracle各种分区技术的特点之后，再结合具体应用需求进行针对性设计。

③ 充分考虑应用设计和开发：在进行分区方案设计时，对应用软件设计和开发进行调研分析，特别是对重点SQL语句进行深入分析。应用需求分析是任何设计开发工作的基础。

④ 分区表空间设计方面：在Oracle分区设计中，可指定每个分区的存储属性，特别是可在分区级进行表空间设计。Oracle的分区表空间设计为大批量数据处理提供了良好的技术基础。只有充分理解表空间级的Oracle相关技术，才能在分区方案设计中有的放矢。

⑤ 大批量数据处理方面：数据大集中之后的IT系统存在很多大批量数据处理的需求。例如，数据生命周期管理中的历史数据迁移、数据集市项目中的数据发布、数据仓库中的数据ETL过程等。在很多项目实施中，设计和开发人员仍然在采用最原始的DML语句进行大批量数据处理，不仅运行效率低下，而且会产生大量日志，为备份恢复、资源管理方面的工作增加负担。最终不得不进一步增加主机，存储设备，磁带库等硬件资源的投入。其实，Oracle提供了众多提高大批量数据处理能力的专项技术。例如：表空间迁移技术，分区的truncate、drop、add、exchange、merge、split等操作。建议针对具体应用需求，有机地组合这些技术，设计出有特色的大批量数据处理技术方案。总之，大批量数据处理一定要想到分区技术。

⑥ 分区索引设计方面：在很多项目的分区方案中，在分区索引设计方面存在一些误区：很少甚至没有对索引进行分区设计；只简单将所有分区索引设计成Local分区索引。对于前者，用户经常会发现即便对达标进行了分区，但访问性能并没有得到提升。这是因为正常情况下，特别是交易系统中，查询语句是按索引进行数据访问的。索引没有分区，依然是一棵大B树，访问性能当然不会得到提升。对于后者，分区在进行drop，merge等管理工作之后，Local分区索引依然有效。因此，Local分区索引能有效保证数据的高可用性。同时，Local Prefix分区索引能有效保证访问性能。但Local non-Prefix分区索引却有可能需要访问索引的所有分区。因此，会出现索引分区之后，访问性能反而下降的可能性。导致这些问题的根本原因是设计和开发人员对Oracle分区索引的种类，机制，适应场景了解不深。为提高索引访问性能，增强索引可维护性和管理的灵活性，Oracle提供了多种Local和Global索引技术。在进行分区索引设计上，一方面需要考虑Oracle各种分区索引的特点和机制，另一方面需要考虑项目本身对性能、可维护性、可用性等方面需求的不同。分区索引虽然难，但非常重要，切记随意设计。

⑦ 无止境的分区技术：Oracle丰富的分区技术，包括11g提供的大量新的分区技术，为海量数据库系统设计、开发和维护提供了广阔和深远的技术基础架构，反之也为各种设计误区提供了空间。分区方案设计和实施是一门追求综合平衡、充满辨证统一的哲学，也是经验和技术不断积累的艺术。只有充分了解Oracle分区技术机制和特点，特别是全面考虑不同应用系统需求之后，才能设计出满足海量数据管理需求的高质量分区方案，确保海量数据库建立在坚实的基础之上。