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

数据库分区完善方案及测试报告Oracle中国公司第1页共30页分区需求及现有分区方案的评估Oracle分区技术简介ORACLE的分区技术(PartitioningOption)是一种处理超大型表的技术。分区是一种“分而治之”的技术，通过将大表和索引分成可以管理的小块，从而避免了对每个表作为一个大的、单独的对象进行管理，为大量数据提供了可伸缩的性能。分区通过将操作分配给更小的存储单元，减少了需要进行管理操作的时间，并通过增强的并行处理提高了性能。通过屏蔽故障数据的分区，还增加了可用性。总之，Oracle的分区技术特别适合于超大规模数据库（VLDB）的处理，并能达到高性能、历史数据迁移、高效的数据备份和恢复、高可用性、易管理性等综合目标。尤其适合于国税系统这样数据日益集中的大系统。国税系统对分区的需求国税各业务系统基本上都将在省级和计划单列市级实现集中化存储和处理。在省级集中平台中，系统高可用性、高性能、扩展性、易管理性等各方面要求都将大大提高。作为最重要的数据库平台，Oracle的体系结构设计、数据库逻辑设计、物理设计、应用软件开发等方面工作都将更加重要。尤其是Oracle的分区技术将为满足上述综合需求提供理想的技术手段。下面将从三个主要方面分析分区技术在国税系统的应用前景。日常交易的高性能需求国税业务系统在技术上虽然综合了交易处理和查询业务，但从本质上讲还是典型的交易处理系统（OLTP）系统。因为大量查询还是依据时间、税务机关等主要查询要素进行操作，极少出现没有时间范围和税务机关限制条件的大型查询。这样，为按时间、税务机关进行分区提供了有利依据，从而通过分区技术可以将这种查询操作定位在更小的操作单元，为满足日益增长的数据量的高性能提供了保障。历史数据迁移需求目前，随着运行时间的增长，数据量快速增长，国税各业务系统整体性能日益下降。针对这种情况，国税总局在综合考虑各省市的需求，以及听取业务部门的意见情况下，准备进行历史数据的迁移，降低生产系统的数据量，从而在一定程度上改善系统运行性能。另外，系统数据增长迅速，其中有相当一部分为历史数据，这些数据使用率很低却占用了不少系统资源，采用科学的方式将这些数据迁移出来，合理规划管理和使用历史数据也将是一项重要工作。但是，历史数据迁移是一件听起来容易理解，实际操作起来却非常复杂的事情。且不说分离生产库和历史库所带来的管理、架构、应用开发的复杂性，以及历史数据迁移业务规则的复杂性。单就迁移的技术方案而言，就需要仔细斟酌。目前的综合征管系统的分区设计主要按税务机关进行。由于与时间无关，这样在进行历史数据迁移时，不能使用分区技术，只能进行DELETE操作。效率将非常低下，产生大量日志，增加系统资源的开销和负担。而且空间并不释放，全表扫描仍然要扫描所有空间。数据库分区完善方案及测试报告Oracle中国公司第2页共30页有效进行历史数据迁移的主要技术手段就是首先地对现有系统进行分区的完善，尤其是合理考虑时间因素，并基于分区的相关技术，才能高效、简捷地实现历史数据迁移。数据备份恢复的需求目前，总局运维处正在组织实施省级平台集中统一的数据备份恢复方案的实施工作。在总局的需求中，备份时间要求控制在4小时之内。在目前国税行业中，所有数据库系统都是采取全库备份，随着数据的不断增长，全库备份将变得越来越长，即便硬件做再大的投入，也不可能控制在4个小时之内。例如税控收款机项目，一个省一年的数据量就会达到6TB。实际上，从原理上讲，根本没必要每次都对历年的数据进行全库备份。采取合理的考虑时间因素的分区策略，每次只备份当前（当年）数据，将大大降低备份时间，才能将备份时间控制在4小时之内。现有分区情况总结目前综合征管软件2.0版主要在浙江和河南实施了分区计划，通过实际运行效果分析：分区之后，生产和查询系统的性能有比较明显的改善。以下是我们在浙江国税现场了解到的目前分区情况。分区目标根据对现有分区情况的分析，以及与神州数码公司技术人员的沟通。目前的分区目标重点考虑了生产机和查询机的日常处理性能。分区对象对11张大表进行了分区。分区清单如下：DJ_NSRXXDJ_NSRXX_KZDJ_NSRZT_BGFP_XSFP_YJSB_JKSSB_SBXXSB_TTXXSB_WSZSB_ZSXXWS_DJXX数据库分区完善方案及测试报告Oracle中国公司第3页共30页分区方法以NSR_SWJG_DM或FPKF_DM字段按地市进行范围分区。分区索引4个localnon-prefix索引。其它索引为包含NSR_SWJG_DM或FPKF_DM的localprefix索引。共有56个分区索引。分区表空间情况目前分区表依然按业务进行表空间的分配。例如SB_ZSXX数据存储在CTAIS2_SB_DAT表空间，索引存储在CTAIS2_SB_IDX表空间。现有分区方案的评估分区目标的评估现有分区方案专注于生产机和查询机的日常处理性能，而且对应用程序进行了较大幅度的改进，例如查询语句一般都增加了NSR_SWJG_DM或FPKF_DM的条件，使得相应的分区索引得到使用，性能有比较明显的改善。但作为分区的另外两个重要目标：历史数据清理和数据备份，现有方案则没有考虑。而随着应用的不断深入发展，省级平台的征管系统迟早要进行历史数据的清理。目前的全库备份时间，也将随着数据的不断增长，变得越来越长而不可接受。分区索引的评估现有方案的分区索引大多数增加了NSR_SWJG_DM或FPKF_DM字段，使得分区索引成为LocalPrefix索引。其实因为应用语句已经增加了NSR_SWJG_DM或FPKF_DM的条件，这样即便分区索引不含NSR_SWJG_DM或FPKF_DM字段，Oracle也会非常聪明地使用分区裁减（pruning）功能，而保证索引的高效性。因此，现有分区索引可以去掉NSR_SWJG_DM或FPKF_DM字段，而变成Localnon-Prefix索引。而且可降低DML操作所带来的索引空间和时间的开销。数据库分区完善方案及测试报告Oracle中国公司第4页共30页新分区方案设计新分区方案设计目标新分区方案的总体设计目标和原则是：在保持并加强现有分区方案对日常交易性能考虑的基础上，增加对历史数据迁移和数据备份目标的考虑，并在三个大目标之间进行一定的权衡。表分区方案表分区方案概况结合深圳国税的实际情况，深圳国税的表分区方案如下：表名表中文名表记录总数大小（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入库日期按年度进行范围分区设计思路和要点分区对象：根据深圳国税的建议，目前只考虑记录数和空间消耗较大的上述8张表。分区方法：全部按时间年度进行范围分区。这是因为历史数据迁移基本确定以年为单位进行。分区字段的选择：主要考虑是否是历史数据迁移所依据的时间字段。例如SB_ZSXX考虑可能是以RKRQ为历史数据迁移所依据的时间字段。例如，SB_ZSXX的建表语句中分区的定义如下：CREATETABLECTAIS2.SB_ZSXX(……,)数据库分区完善方案及测试报告Oracle中国公司第5页共30页PARTITIONBYRANGE(RKRQ)(PARTITIONP_2002VALUESLESSTHAN(to_date('2003.01.01','YYYY.MM.DD'))TABLESPACECTAIS2_DAT_2002,PARTITIONP_2003VALUESLESSTHAN(to_date('2004.01.01','YYYY.MM.DD'))TABLESPACECTAIS2_DAT_2003,PARTITIONP_2004VALUESLESSTHAN(to_date('2005.01.01','YYYY.MM.DD'))TABLESPACECTAIS2_DAT_2004,PARTITIONP_2005VALUESLESSTHAN(to_date('2006.01.01','YYYY.MM.DD'))TABLESPACECTAIS2_DAT_2005,PARTITIONP_2006VALUESLESSTHAN(to_date('2007.01.01','YYYY.MM.DD'))TABLESPACECTAIS2_DAT_2006,PARTITIONP_2007VALUESLESSTHAN(to_date('2008.01.01','YYYY.MM.DD'))TABLESPACECTAIS2_DAT_2007,PARTITIONP_2008VALUESLESSTHAN(to_date('2009.01.01','YYYY.MM.DD'))TABLESPACECTAIS2_DAT_2008,PARTITIONP_9999VALUESLESSTHAN(MAXVALUE)TABLESPACECTAIS2_DAT_9999)enablerowmovement;索引分区方案新方案索引分区原则如果索引字段正好是分区的时间字段，或者复合索引的第一个字段是分区的时间字段，则建立为LocalPrefix索引。这是因为LocalPrefix索引的效率最高，而且在历史数据迁移之后，Oracle针对该类索引能自动维护。例如，SB_ZSXX的RKRQ字段索引如下：createindexIDX_SB_ZSXX_RKRQonSB_ZSXX(RKRQ)local(PARTITIONP_2002,PARTITIONP_2003,PARTITIONP_2004,PARTITIONP_2005,PARTITIONP_2006,PARTITIONP_2007,数据库分区完善方案及测试报告Oracle中国公司第6页共30页PARTITIONP_2008,PARTITIONP_9999)tablespaceCTAIS2_IDX;如果索引字段是税务机关，或者复合索引的第一个字段是税务机关，则建立为按税务机关进行分区的GlobalPartition索引。例如，深圳国税SB_ZSXX的NSR_SWJG_DM索引如下：CREATEINDEXCTAIS2.IDX_SB_ZSXX_NSR_SWJG_DMONCTAIS2.SB_ZSXX(NSR_SWJG_DM)globalpartitionbyrange(NSR_SWJG_DM)(partitionp1valueslessthan('14403040000'),partitionp2valueslessthan('14403050000'),partitionp3valueslessthan('14403060000'),partitionp4valueslessthan('14403070000'),partitionp5valueslessthan('14403080000'),partitionp6valueslessthan('14403910000'),partitionp7valueslessthan('14403920000'),partitionp8valueslessthan('14403930000'),partitionp9valueslessthan('14403940000'),partitionp1