Oracle数据库高级技术交流案例.doc

数据库分区完善方案及测试报告 Oracle中国公司分区需求及现有分区方案的评估Oracle分区技术简介ORACLE的分区技术(Partitioning Option)是一种处理超大型表的技术。分区是一种“分而治之”的技术，通过将大表和索引分成可以管理的小块，从而避免了对每个表作为一个大的、单独的对象进行管理，为大量数据提供了可伸缩的性能。分区通过将操作分配给更小的存储单元，减少了需要进行管理操作的时间，并通过增强的并行处理提高了性能。通过屏蔽故障数据的分区，还增加了可用性。总之，Oracle的分区技术特别适合于超大规模数据库（VLDB）的处理，并能达到高性能、历史数据迁移、高效的数据备份和恢复、高可用性、易管理性等综合目标。尤其适合于国税系统这样数据日益集中的大系统。国税系统对分区的需求国税各业务系统基本上都将在省级和计划单列市级实现集中化存储和处理。在省级集中平台中，系统高可用性、高性能、扩展性、易管理性等各方面要求都将大大提高。作为最重要的数据库平台，Oracle的体系结构设计、数据库逻辑设计、物理设计、应用软件开发等方面工作都将更加重要。尤其是Oracle的分区技术将为满足上述综合需求提供理想的技术手段。下面将从三个主要方面分析分区技术在国税系统的应用前景。日常交易的高性能需求国税业务系统在技术上虽然综合了交易处理和查询业务，但从本质上讲还是典型的交易处理系统（OLTP）系统。因为大量查询还是依据时间、税务机关等主要查询要素进行操作，极少出现没有时间范围和税务机关限制条件的大型查询。这样，为按时间、税务机关进行分区提供了有利依据，从而通过分区技术可以将这种查询操作定位在更小的操作单元，为满足日益增长的数据量的高性能提供了保障。历史数据迁移需求目前，随着运行时间的增长，数据量快速增长，国税各业务系统整体性能日益下降。针对这种情况，国税总局在综合考虑各省市的需求，以及听取业务部门的意见情况下，准备进行历史数据的迁移，降低生产系统的数据量，从而在一定程度上改善系统运行性能。另外，系统数据增长迅速，其中有相当一部分为历史数据，这些数据使用率很低却占用了不少系统资源，采用科学的方式将这些数据迁移出来，合理规划管理和使用历史数据也将是一项重要工作。但是，历史数据迁移是一件听起来容易理解，实际操作起来却非常复杂的事情。且不说分离生产库和历史库所带来的管理、架构、应用开发的复杂性，以及历史数据迁移业务规则的复杂性。单就迁移的技术方案而言，就需要仔细斟酌。目前的综合征管系统的分区设计主要按税务机关进行。由于与时间无关，这样在进行历史数据迁移时，不能使用分区技术，只能进行DELETE操作。效率将非常低下，产生大量日志，增加系统资源的开销和负担。而且空间并不释放，全表扫描仍然要扫描所有空间。有效进行历史数据迁移的主要技术手段就是首先地对现有系统进行分区的完善，尤其是合理考虑时间因素，并基于分区的相关技术，才能高效、简捷地实现历史数据迁移。数据备份恢复的需求目前，总局运维处正在组织实施省级平台集中统一的数据备份恢复方案的实施工作。在总局的需求中，备份时间要求控制在4小时之内。在目前国税行业中，所有数据库系统都是采取全库备份，随着数据的不断增长，全库备份将变得越来越长，即便硬件做再大的投入，也不可能控制在4个小时之内。例如税控收款机项目，一个省一年的数据量就会达到6TB。实际上，从原理上讲，根本没必要每次都对历年的数据进行全库备份。采取合理的考虑时间因素的分区策略，每次只备份当前（当年）数据，将大大降低备份时间，才能将备份时间控制在4小时之内。现有分区情况总结目前综合征管软件2.0版主要在浙江和河南实施了分区计划，通过实际运行效果分析：分区之后，生产和查询系统的性能有比较明显的改善。以下是我们在浙江国税现场了解到的目前分区情况。分区目标根据对现有分区情况的分析，以及与神州数码公司技术人员的沟通。目前的分区目标重点考虑了生产机和查询机的日常处理性能。分区对象对11张大表进行了分区。分区清单如下：DJ_NSRXXDJ_NSRXX_KZDJ_NSRZT_BGFP_XSFP_YJSB_JKSSB_SBXXSB_TTXXSB_WSZSB_ZSXXWS_DJXX分区方法以NSR_SWJG_DM或FPKF_DM字段按地市进行范围分区。分区索引l 4个local non-prefix索引。l 其它索引为包含NSR_SWJG_DM或FPKF_DM的local prefix索引。共有56个分区索引。分区表空间情况目前分区表依然按业务进行表空间的分配。例如SB_ZSXX数据存储在CTAIS2_SB_DAT表空间，索引存储在CTAIS2_SB_IDX表空间。现有分区方案的评估分区目标的评估现有分区方案专注于生产机和查询机的日常处理性能，而且对应用程序进行了较大幅度的改进，例如查询语句一般都增加了NSR_SWJG_DM或FPKF_DM的条件，使得相应的分区索引得到使用，性能有比较明显的改善。但作为分区的另外两个重要目标：历史数据清理和数据备份，现有方案则没有考虑。而随着应用的不断深入发展，省级平台的征管系统迟早要进行历史数据的清理。目前的全库备份时间，也将随着数据的不断增长，变得越来越长而不可接受。分区索引的评估现有方案的分区索引大多数增加了NSR_SWJG_DM或FPKF_DM字段，使得分区索引成为Local Prefix索引。其实因为应用语句已经增加了NSR_SWJG_DM或FPKF_DM的条件，这样即便分区索引不含NSR_SWJG_DM或FPKF_DM字段，Oracle也会非常聪明地使用分区裁减（pruning）功能，而保证索引的高效性。因此，现有分区索引可以去掉NSR_SWJG_DM或FPKF_DM字段，而变成Local non-Prefix索引。而且可降低DML操作所带来的索引空间和时间的开销。新分区方案设计新分区方案设计目标新分区方案的总体设计目标和原则是：在保持并加强现有分区方案对日常交易性能考虑的基础上，增加对历史数据迁移和数据备份目标的考虑，并在三个大目标之间进行一定的权衡。表分区方案表分区方案概况结合深圳国税的实际情况，深圳国税的表分区方案如下：表名表中文名表记录总数大小（M）表分区字段表分区字段中文名分区方法备注DJ_YZCWSBQC登记_应准迟未申报清册12,247,4182,194ND年度按年度进行范围分区FP_YJ发票_验旧3,362,298560RQ日期按年度进行范围分区KJ_JZPZ_NSR会计_计帐凭证_纳税人20,045,6381,808JZPZBH计帐凭证编号按年度进行范围分区KJ_NSR_KMYE会计_纳税人_科目余额20,045,6381,712KJND会计年度按年度进行范围分区SB_JKS申报_缴款书5,922,6102,488KPRQ开票日期按年度进行范围分区SB_SBXX申报_申报信息10,715,9852,376SSSQ_Q所属时期_起按年度进行范围分区SB_WSZ申报_完税证6,316,9132,536KPRQ开票日期按年度进行范围分区SB_ZSXX申报_征收信息10,640,9285,980RKRQ入库日期按年度进行范围分区设计思路和要点l 分区对象：根据深圳国税的建议，目前只考虑记录数和空间消耗较大的上述8张表。l 分区方法：全部按时间年度进行范围分区。这是因为历史数据迁移基本确定以年为单位进行。l 分区字段的选择：主要考虑是否是历史数据迁移所依据的时间字段。例如SB_ZSXX考虑可能是以RKRQ为历史数据迁移所依据的时间字段。例如，SB_ZSXX的建表语句中分区的定义如下： CREATE TABLE CTAIS2.SB_ZSXX ( , ) PARTITION BY RANGE (RKRQ) (PARTITION P_2002 VALUES LESS THAN (to_date(2003.01.01,YYYY.MM.DD) TABLESPACE CTAIS2_DAT_2002, PARTITION P_2003 VALUES LESS THAN (to_date(2004.01.01,YYYY.MM.DD) TABLESPACE CTAIS2_DAT_2003, PARTITION P_2004 VALUES LESS THAN (to_date(2005.01.01,YYYY.MM.DD) TABLESPACE CTAIS2_DAT_2004, PARTITION P_2005 VALUES LESS THAN (to_date(2006.01.01,YYYY.MM.DD) TABLESPACE CTAIS2_DAT_2005, PARTITION P_2006 VALUES LESS THAN (to_date(2007.01.01,YYYY.MM.DD) TABLESPACE CTAIS2_DAT_2006, PARTITION P_2007 VALUES LESS THAN (to_date(2008.01.01,YYYY.MM.DD) TABLESPACE CTAIS2_DAT_2007, PARTITION P_2008 VALUES LESS THAN (to_date(2009.01.01,YYYY.MM.DD) TABLESPACE CTAIS2_DAT_2008, PARTITION P_9999 VALUES LESS THAN (MAXVALUE) TABLESPACE CTAIS2_DAT_9999 ) enable row movement;索引分区方案新方案索引分区原则l 如果索引字段正好是分区的时间字段，或者复合索引的第一个字段是分区的时间字段，则建立为Local Prefix索引。这是因为Local Prefix索引的效率最高，而且在历史数据迁移之后，Oracle针对该类索引能自动维护。例如，SB_ZSXX的RKRQ字段索引如下：create index IDX_SB_ZSXX_RKRQ on SB_ZSXX (RKRQ) local (PARTITION P_2002 , PARTITION P_2003 , PARTITION P_2004 , PARTITION P_2005 , PARTITION P_2006 , PARTITION P_2007 , PARTITION P_2008 , PARTITION P_9999 ) tablespace CTAIS2_IDX;l 如果索引字段是税务机关，或者复合索引的第一个字段是税务机关，则建立为按税务机关进行分区的Global Partition 索引。例如，深圳国税SB_ZSXX的NSR_SWJG_DM索引如下： CREATE INDEX CTAIS2.IDX_SB_ZSXX_NSR_SWJG_DM ON CTAIS2.SB_ZSXX (NSR_SWJG_DM)global partition by range(NSR_SWJG_DM)(partition p1 values less than , partition p2 values less than , partition p3 values less than , partition p4 values less than , partition p5 values less than , partition p6 values less than , partition p7 values less than , partition p8 values less than , partition p9 values less than , partition p10 values less than , partition p11 values less than , partition p12 values less than , partition p13 values less than (MAXVALUE) tablespace CTAIS2_IDX;深圳国税在区级进行税务机关索引的分区。确定区级税务机关的语句如下：select * from dm_swjg where jcdm=3 and swjg_bz=J order by swjg_dm;这是因为征管软件的大部分查询都含有税务机关条件，按税务机关的分区索引将保证查询的高效性。而且在目前浙江、河南等都得到了验证。l 其它索引建立为普通非分区索引。l 我们此次没有采用Local non-prefix索引的主要理由有两点：1. 首先Local non-prefix索引效率低于Local prefix、Global Partition索引，甚至低于普通非分区索引。有些SQL语句在Local non-prefix索引下，Oracle还会错误地选择INDEX FAST FULL SCAN的执行路径，而不是INDEX RANGE SCAN。而征管软件的日常处理性能应该得到优先保证。2. 在历史数据迁移时，如果采用Local索引，包括Local prefix和Local non-prefix索引，Oracle能自动维护这些索引，保证历史数据迁移的高效，以及系统的高可用性。这是Local non-prefix索引相比Global索引的唯一优点。但是，我们在实际进行历史数据迁移的测试时发现，如果进行Global索引的维护，并不太消耗时间和资源。因此，我们此次不建立Local non-prefix索引，宁可稍微牺牲一点历史数据迁移的性能，也要换取日常处理的高性能。关于分区索引的进一步建议交易系统中SQL语句的高性能关键在于索引设计的高质量。在新分区方案中，希望在分区索引的设计上，进一步采纳如下建议：l 由于大部分SQL语句都涉及税务机关和时间两大要素，因此可以考虑建立在税务机关和时间两个字段上的复合索引。这种索引将比单个字段的索引效率更高。原理很简单：同时按税务机关和时间进行约束，肯定比只按税务机关或时间进行查询的效率高。下一章的SQL语句将验证这一点。l 为了进一步提高性能，可以考虑将其它普通索引建立为Global Partition索引。尤其是针对一些时间字段的索引，可以考虑也按年度进行分区。分区表空间的设计新增分区表空间深圳国税为此次分区方案，在保留现有表空间的情况下，增加了如下表空间：表空间名大小CTAIS2_DAT_10GCTAIS2_IND_10G其中YYYY为年。目前深圳国税设计为2002 2008。另外，CTAIS2_DAT_9999存放分区时间字段为空的记录。分区表和表空间的对应关系在新的分区方案中，为保证备份的高性能，我们设计分区和表空间的对应关系如下：l 所有业务按年存放数据。l 按时间进行分区和表空间的分配。例如2005年所有申报、发票等分区表数据存放在CTAIS2_DATA_2005一个表空间中。详细语句见上述。分区索引的表空间设计l 所有普通索引和Global Partition索引都存放在现有的CTAIS2_IDX表空间中。l 所有Local 索引也存放在现有的CTAIS2_IDX表空间中。即此次深圳国税并没有使用新建的CTAIS2_IND_表空间。原因是Local索引比较少，普通索引和Global Partition索引比较多。而且税务机关的Global索引没办法分配到CTAIS2_IND_表空间中。因此，针对索引的表空间设计，直接采取了暂时都存储在CTAIS2_IDX的简单策略。针对数据量更大的省份，建议将Local索引按年度存储在CTAIS2_IND_表空间中，其它时间字段的Global Partition索引也建议按年度存储在CTAIS2_IND_表空间中。新分区方案中的应用评估新分区方案一定要通过应用的性能对比评估，方能确定其合理性。以下是神州数码公司提供的10几个典型的，在深圳国税运行较慢的应用。通过这些典型SQL语句的分析，我们可以评估分区前后的性能差异，并总结一些通用的优化建议。上解入库查询（按区局）原语句的分析原语句如下：BEGIN INSERT INTO TMP_AUTO_442806002291216005 SELECT /*+RULE*/ DJ_NSRXX.NSRSBH, DJ_NSRXX.NSRMC, SB_ZSXX.YZPZXH, SB_ZSXX.YZPZZL_DM, SB_ZSXX.YZPZLRR_DM, TO_CHAR(SB_ZSXX.YZFSRQ, YYYY-MM-DD) YZFSRQ, SB_ZSXX.ZSFS_DM, SB_ZSXX.SE, SB_ZSXX.TZLX_DM, TO_CHAR(SB_ZSXX.SSSQ_Q, YYYY-MM-DD) SSSQ_Q, TO_CHAR(SB_ZSXX.SSSQ_Z, YYYY-MM-DD) SSSQ_Z, TO_CHAR(SB_ZSXX.JKFSRQ, YYYY-MM-DD) JKFSRQ, TO_CHAR(SB_ZSXX.JKQX, YYYY-MM-DD) JKQX, SB_JKS.YHZL_DM, SB_JKS.YH_DM, SB_JKS.YHZH, SB_JKS.BZ2 YSLWQH, SB_ZSXX.ZSXM_DM, SB_ZSXX.ZSPM_DM, SB_ZSXX.JKPZZL_DM, SB_ZSXX.JKPZXH, SB_ZSXX.YSSPHM, SB_ZSXX.HZJKSH, SB_ZSXX.JKPZLRR_DM, TO_CHAR(SB_ZSXX.KPRQ, YYYY-MM-DD) KPRQ, SB_ZSXX.SKSX_DM, SB_ZSXX.SKZL_DM, SB_ZSXX.SKCSFS_DM, SB_ZSXX.QLQQSLX_DM, SB_ZSXX.DJZCLX_DM, SB_ZSXX.HY_DM, SB_ZSXX.ZSJG_DM, SB_ZSXX.NSR_SWJG_DM, SB_ZSXX.SKSS_SWJG_DM, SB_ZSXX.YSKM_DM, SB_ZSXX.YSFPBL_DM, SB_ZSXX.YSFPBL_ZY, SB_ZSXX.YSFPBL_SS, SB_ZSXX.YSFPBL_DS, SB_ZSXX.YSFPBL_XQ, SB_ZSXX.YSFPBL_XZ, SB_ZSXX.YSFPBL_XC, TO_CHAR(SB_ZSXX.SJRQ, YYYY-MM-DD) SJRQ, TO_CHAR(SB_ZSXX.SJXHRQ, YYYY-MM-DD HH24:MI:SS) SJXHRQ, SB_ZSXX.SJXHR_DM, TO_CHAR(SB_ZSXX.RKRQ, YYYY-MM-DD) RKRQ, TO_CHAR(SB_ZSXX.RKXHRQ, YYYY-MM-DD HH24:MI:SS) RKXHRQ, SB_ZSXX.RKXHR_DM, SB_ZSXX.SL FROM SB_ZSXX, DJ_NSRXX, SB_JKS WHERE SB_ZSXX.ZSXH = SB_JKS.ZSXH AND SB_ZSXX.NSRDZDAH = DJ_NSRXX.NSRDZDAH AND SB_ZSXX.YZPZXH IS NOT NULL AND SB_JKS.ZFRQ IS NULL AND (SELECT JBDM FROM DM_SWJG WHERE DM_SWJG.SWJG_DM = SB_ZSXX.ZSJG_DM) LIKE 0000000100010027%) AND SB_ZSXX.SKCSFS_DM NOT IN 14 AND SB_ZSXX.SJRQ IS NOT NULL AND (SB_ZSXX.SE 0 AND SB_ZSXX.TZLX_DM 3) OR (SB_ZSXX.SE 0 AND SB_ZSXX.TZLX_DM = 3) AND (SB_ZSXX.YZPZZL_DM 644 or SB_ZSXX.YZPZZL_DM IS NULL) AND SB_ZSXX.SJRQ = TO_DATE(2005-07-01, YYYY-MM-DD) AND SB_ZSXX.SJRQ 0 AND SB_ZSXX.TZLX_DM 3) OR (SB_ZSXX.SE 0 AND SB_ZSXX.TZLX_DM = 3) AND (SB_ZSXX.YZPZZL_DM 644 or SB_ZSXX.YZPZZL_DM IS NULL) AND SB_ZSXX.SJRQ = TO_DATE(2005-07-01, YYYY-MM-DD) AND SB_ZSXX.SJRQ TO_DATE(2005-07-31, YYYY-MM-DD HH24:MI:SS) + 1;新语句执行计划如下：即新语句的执行过程如下：1. 首先按主键IDX_DM_SWJG_JBDM访问DM_SWJG。检索出蛇口分局。2. 按SB_ZSXX的SJRQ字段的索引进行检索。3. 将第1步的结果集与第2步SB_ZSXX结果集，进行连接操作。即只检索蛇口分局的SB_ZSXX。4. 将第3步的结果集，按DJ_NSRXX的主键PK_DJ_NSRXX与DJ_NSRXX进行连接操作。5. 将第4步结果集，按SB_JKS的索引IDX_SB_JKS_ZSXH与SB_JKS进行连接操作。即现在的执行过程是先限定为蛇口分局，并限定SJRQ是2005-07-01至2005-07-31条件，再进行SB_ZSXX、DJ_NSRXX、SB_JKS的连接操作，得出最终数据。以下是前后语句的效果分析：原有语句新语句（不分区）响应速度00:01:01.2500:00:26.01内存消耗1568215838891I/O消耗4606022558记录数33可见响应速度大幅度提高，内存和I/O消耗大幅度下降。分区后的效果在新的分区方案中执行新语句，效果得到进一步提高，对比如下：原有语句新语句（不分区）新语句(分区)响应速度00:01:01.2500:00:26.0100:00:12.57内存消耗1568215838891609714I/O消耗460602255822838记录数333进一步的优化再仔细分析该语句，发现该语句具有大多数税务系统查询的主要特征：涉及税务机关和时间两大要素。因此我们尝试建立在税务机关和时间两个字段上的复合索引。在本例中，即在SB_ZSXX表上建立如下复合的Global Partition索引：CREATE INDEX CTAIS2.IDX_SB_ZSXX_ZSJG_SJRQ ON CTAIS2.SB_ZSXX (ZSJG_DM,SJRQ)global partition by range(ZSJG_DM)(partition p1 values less than , partition p2 values less than , partition p3 values less than , partition p4 values less than , partition p5 values less than , partition p6 values less than , partition p7 values less than , partition p8 values less than , partition p9 values less than , partition p10 values less than , partition p11 values less than , partition p12 values less than , partition p13 values less than (MAXVALUE) tablespace CTAIS2_IDX;最终的执行计划如下：最终的对比效果如下：原有语句新语句（不分区）新语句(分区)新语句（分区，新索引）响应速度00:01:01.2500:00:26.0100:00:12.5700:00:02.82内存消耗156821583889160971412401I/O消耗4606022558228383318记录数3333即该语句的响应速度最终由00:01:01.25优化到00:00:02.82，提高近30倍，内存消耗下降了100多倍，I/O消耗下降了10多倍。小结通过对该应用的逐步优化，揭示出很多规律性的结论：1. 20/80规则之一首先是“20%的技术可以解决80%的问题”。在该例中，将速度由00:01:01.25大幅度优化到00:00:26.01，并不是采用分区等复杂技术，而是将子查询修改为多表连接等简单技术，即20%的通用技术提高了性能的80%。分区技术优化到最终的00:00:02.82，只起了20%的作用。2. 征管软件的查询架构问题该案例中，将子查询修改为多表连接，大幅度提高了速度。而无论在CTAIS 1.1还是CTAIS 2.0中，都大量出现子查询操作。原因是征管软件的查询架构所导致。即先固定几种查询语句的模式，再将用户输入的查询条件以子查询方式添加到固定的查询语句中。这种大量的子查询操作，会误导Oracle选择错误的执行路径。即先进行预先定义的固定的大查询操作，再过滤掉用户输入的条件（子查询结果）。该问题是目前导致征管软件性能不佳，尤其是全表扫描的主要原因。解决方式是将查询语句修改为多表连接。3. 索引策略问题首先在技术上合理的复合索引比单字段效率高。如前所述，同时按税务机关和时间进行约束，肯定比只按税务机关或时间进行查询的效率高。在征管系统中，由于大部分SQL语句都涉及税务机关和时间两大要素，因此建议仔细分析SQL语句的共性和查询条件使用频度，可以考虑建立在税务机关和时间两个字段上的复合索引。但另一方面要注意复合索引的前缀性（Prefix），以及复合索引字段的可选性（Cardinality）。申报情况查询原语句的分析原语句如下：SELECT /*+rule*/ NSRSBH, NSRMC, DHHM, SCJYDZ, ZSXM_DM, NSQX_DM, TO_CHAR(SSSQ_Q, YYYY-MM-DD) SSSQ_Q, TO_CHAR(SSSQ_Z, YYYY-MM-DD) SSSQ_Z, ND, YF, TO_CHAR(SBRQ, YYYY-MM-DD) SBRQ, TO_CHAR(SBQX, YYYY-MM-DD) SBQX, SBFS_DM, TO_CHAR(DJ_YZCWSBQC.LRRQ, YYYY-MM-DD HH24:MI:SS) LRRQ, DJ_YZCWSBQC.NSR_SWJG_DM, DJ_YZCWSBQC.SWJG_DM, DJ_YZCWSBQC.DJZCLX_DM, DJ_YZCWSBQC.HY_DM, DJ_NSRXX.NSRZT_DM FROM DJ_YZCWSBQC, DJ_NSRXX WHERE (DJ_YZCWSBQC.NSRDZDAH = DJ_NSRXX.NSRDZDAH + 0 AND DJ_YZCWSBQC.NSRDZDAH = DJ_NSRXX.NSRDZDAH AND DJ_YZCWSBQC.ND = 2006) AND (SELECT JBDM FROM DM_SWJG WHERE DM_SWJG.SWJG_DM = DJ_YZCWSBQC.NSR_SWJG_DM) LIKE 0000%)原语句执行计划如下：新语句的分析原语句的错误是不应该将DM_SWJG的查询以子查询方式进行，而应该直接编写成多表连接。新语句如下：SELECT NSRSBH, NSRMC, DHHM, SCJYDZ, ZSXM_DM, NSQX_DM, TO_CHAR(SSSQ_Q, YYYY-MM-DD) SSSQ_Q, TO_CHAR(SSSQ_Z, YYYY-MM-DD) SSSQ_Z, ND, YF, TO_CHAR(SBRQ, YYYY-MM-DD) SBRQ, TO_CHAR(SBQX, YYYY-MM-DD) SBQX, SBFS_DM, TO_CHAR(OLD_DJ_YZCWSBQC.LRRQ, YYYY-MM-DD HH24:MI:SS) LRRQ, OLD_DJ_YZCWSBQC.NSR_SWJG_DM, OLD_DJ_YZCWSBQC.SWJG_DM, OLD_DJ_YZCWSBQC.DJZCLX_DM, OLD_DJ_YZCWSBQC.HY_DM, DJ_NSRXX.NSRZT_DM FROM OLD_DJ_YZCWSBQC, DJ_NSRXX, DM_SWJG WHERE OLD_DJ_YZCWSBQC.NSRDZDAH = DJ_NSRXX.NSRDZDAH AND DM_SWJG.SWJG_DM = OLD_DJ_YZCWSBQC.NSR_SWJG_DM AND OLD_DJ_YZCWSBQC.ND = 2006 AND DM_SWJG.JBDM LIKE 0000%新语句执行计划如下：该语句的查询条件是整个深圳市局2006年度的DJ_YZCWSBQC信息。因此新语句是直接采取更合理的HASH JOIN技术。以下是前后语句的效果分析：原有语句新语句（不分区）响应速度00:05:17.4300:04:02.96内存消耗8771661504429I/O消耗9246295431记录数27032502703250可见响应速度有一定幅度提高，内存和I/O消耗也一定幅度下降。分区后的效果在新的分区方案中执行新语句，效果没有提高，对比如下：原有语句新语句（不分区）新语句（分区）响应速度00:05:17.4300:04:02.9600:04:51.48内存消耗8771661504429777559I/O消耗9246295431182585记录数270325027032502703250新语句执行计划如下：如果将原语句在分区上运行，对比如下：原有语句新语句（不分区）新语句（分区）原语句（分区）响应速度00:05:17.4300:04:02.9600:04:51.4800:04:05.94内存消耗8771661504429777559185835I/O消耗9246295431182585150728记录数2703250270325027032502703250限定在蛇口的查询如果将查询条件限定为蛇口国税局，则对比情况如下：原有语句新语句（不分区）原语句（分区）新语句（分区）响应速度00:01:24.6200:01:08.0500:00:29.9000:00:21.31内存消耗82729928826953544545153I/O消耗93724649644132916264记录数168310168310168310168310可见在查询范围较小的情况下，新旧语句查询效率明显提高，资源消耗也明显下降。小结在数据按年度分区，税务机关索引也分区之后，通过上述测试，可总结如下规律：l 如果查询范围覆盖到所有税务机关，分区之后效率提高不明显。l 如果查询范围只是局部的税务机关，分区之后效率提高非常明显。其它案例神州数码提供的其它性能不佳的SQL语句基本与前两个案例雷同，不再进行详细分析和描述。历史数据迁移的评估历史数据迁移的时机如果仅仅是为了改善生产系统的运行性能，我们认为目前暂不适宜进行历史数据迁移。因为应用软件本身的优化还有很大空间，而且目前的分区也不合理等。而匆忙进行历史数据迁移，将导致管理、架构、应用开发的进一步复杂性。相应地，我们认为历史数据迁移的条件如下：l 数据量大到必须迁移的程度此时，存储容量也已经达到极限，例如TB级以上，必须进行数据迁移。l SQL语句的优化空间已经几乎达到极限此时，应用已经优化地非常好，例如很少出现大表的全表扫描，分区技术也得到良好的运用等。l CTAIS重新按时间进行分区之后现有分区方案在完善之后，尤其是充分考虑按时间进行分区之后，历史数据迁移可以使用相关的分区技术，从而保证数据迁移的高效性。l 数据迁移的业务逻辑确认之后在数据迁移的业务逻辑确认之后，能保证历史数据迁移之后的数据逻辑完整性。尽量减少应用在历史库、生产库之间数据耦合性，减少跨历史库和生产库的交叉访问。l 历史数据迁移的分析需求确认之后在历史数据的分析和应用需求确认之后，结合数据仓库的抽取、转换、分析（ETL）工作，进行历史数据的迁移。利用分区技术实现历史数据迁移分区交换（exchange）技术简介Oracle的分区交换技术可以实现一个普通表和一