CN113656380A - 数据生命周期管理方法及装置 - Google Patents

Abstract

本申请实施例提供一种数据生命周期管理方法及装置，方法包括：在核对业务表、中间表、本地历史表以及历史库历史表的数据字段和索引属性一致且判断所述本地历史表中无数据时，获取所述业务表中的待迁移数据；将所述业务表中的待迁移数据迁移至所述本地历史表中，并根据所述待迁移数据的时间字段确定对应的历史库历史表；将所述本地历史表中的待迁移数据迁移至所述历史库历史表中；本申请能够有效提升数据清理的效率和准确性。

Description

数据生命周期管理方法及装置

技术领域

本申请涉及数据处理领域，也可用于金融领域，具体涉及一种数据生命周期管理方法及装置。

背景技术

在系统上线运行过程中，随着时间的推移、业务的推广和用户的增长，需要存储的业务数据也随之增多。通常这部分数据会存储在数据库当中，并且核心系统多为关系型数据库。随着数据量的持续增长，关系型数据库的性能将会持续下降，用户使用系统也会感觉越来越慢。同时需要存储数据的磁盘也将越来越大，因此数据库服务器需要持续扩容，不仅磁盘需要扩容，还需要对CPU和内存资源进行扩容，才能满足系统正常运行的要求。但是单台服务器存在扩容上限，当超过一定的规模后，再也无法继续扩容，此时系统将面临很大的危险。

发明人发现，在现有技术中一些系统数据清理必须通过Delete命令执行，无法进行按日分表，这部分数据的特点是仅能根据状态码进行删除指定日期的部分数据。这类数据表创建分表需要同步改造应用系统，有些系统改造难度非常大，代价非常高，因此这类数据表将不进行按日创建分表的操作，而采用Delete的方式，基于日期删除指定时间的数据。这种情况下，由于Delete删除数据将占用大量的服务器资源，因此此时数据库提供服务的能力将受到影响，所以通常这类操作选择在业务低峰期，也就是凌晨执行。这类数据在删除前还需要进行备份，将数据导出，传输到归档数据库服务器，并执行导入操作。导入完成后需要进行数据量的核对，确保两边数据量一致后，才能执行删除操作。全流程都需要人工参与，随着运维系统的增加，人员成本也越来越高，而且效率极低。

发明内容

针对现有技术中的问题，本申请提供一种数据生命周期管理方法及装置，能够有效提升数据清理的效率和准确性。

为了解决上述问题中的至少一个，本申请提供以下技术方案：

第一方面，本申请提供一种数据生命周期管理方法，包括：

在核对业务表、中间表、本地历史表以及历史库历史表的数据字段和索引属性一致且判断所述本地历史表中无数据时，获取所述业务表中的待迁移数据；

将所述业务表中的待迁移数据迁移至所述本地历史表中，并根据所述待迁移数据的时间字段确定对应的历史库历史表；

将所述本地历史表中的待迁移数据迁移至所述历史库历史表中。

进一步地，在所述核对业务表、中间、本地历史表以及历史库历史表的数据字段和索引属性一致后，包括：

判断所述业务表是否为分区表；

若是，则根据所述分区表的分区字段和迁移日期判断所述分区表中是否存在历史数据，若存在，则将所述历史数据迁移至所述历史库历史表中。

进一步地，所述获取所述业务表中的待迁移数据，包括：

判断所述中间表是否为空，若是，则根据待迁移数据的时间字段确定所述分区表的分区名；

根据所述分区名确定所述待迁移数据的数据量并获取所述待迁移数据。

进一步地，所述将所述业务表中的待迁移数据迁移至所述本地历史表中，包括：

根据预设交换分区命令，通过包含所述待迁移数据的分区表与所述中间表进行分区交换操作将所述待迁移数据迁移至所述中间表中，并删除所述分区表；

通过所述中间表与所述本地历史表进行分区交换操作将所述待迁移数据迁移至所述本地历史表中。

第二方面，本申请提供一种数据生命周期管理装置，包括：

待迁移数据获取模块，用于在核对业务表、中间表、本地历史表以及历史库历史表的数据字段和索引属性一致且判断所述本地历史表中无数据时，获取所述业务表中的待迁移数据；

本地迁移模块，用于将所述业务表中的待迁移数据迁移至所述本地历史表中，并根据所述待迁移数据的时间字段确定对应的历史库历史表；

历史库迁移模块，用于将所述本地历史表中的待迁移数据迁移至所述历史库历史表中。

进一步地，所述待迁移数据获取模块还包括：

分区表判断单元，用于判断所述业务表是否为分区表；

分区历史数据处理单元，用于若判断所述业务表为分区表，则根据所述分区表的分区字段和迁移日期判断所述分区表中是否存在历史数据，若存在，则将所述历史数据迁移至所述历史库历史表中。

进一步地，所述待迁移数据获取模块还包括：

分区名确定单元，用于判断所述中间表是否为空，若是，则根据待迁移数据的时间字段确定所述分区表的分区名；

分区待迁移数据确定单元，用于根据所述分区名确定所述待迁移数据的数据量并获取所述待迁移数据。

进一步地，所述本地迁移模块包括：

中间表交换单元，用于根据预设交换分区命令，通过包含所述待迁移数据的分区表与所述中间表进行分区交换操作将所述待迁移数据迁移至所述中间表中，并删除所述分区表；

本地历史表交换单元，用于通过所述中间表与所述本地历史表进行分区交换操作将所述待迁移数据迁移至所述本地历史表中。

第三方面，本申请提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现所述的数据生命周期管理方法的步骤。

第四方面，本申请提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现所述的数据生命周期管理方法的步骤。

由上述技术方案可知，本申请提供一种数据生命周期管理方法及装置，通过在核对业务表、中间表、本地历史表以及历史库历史表的数据字段和索引属性一致且判断所述本地历史表中无数据时，获取所述业务表中的待迁移数据，将所述业务表中的待迁移数据迁移至所述本地历史表中，并根据所述待迁移数据的时间字段确定对应的历史库历史表，将所述本地历史表中的待迁移数据迁移至所述历史库历史表中，由此自动将不再被使用的数据从业务数据库中迁移到历史数据库，通常能使数据库磁盘的使用量保持稳定，也节省了备份所需的磁盘空间，在数据量恒定的情况下，数据库所需要的CPU和内存资源同通常也较为稳定，同时也避免了随着数据量的增长而导致的性能问题，能够有效提升数据清理的效率和准确性。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例中的数据生命周期管理方法的流程示意图之一；

图2为本申请实施例中的数据生命周期管理方法的流程示意图之二；

图3为本申请实施例中的数据生命周期管理方法的流程示意图之三；

图4为本申请实施例中的数据生命周期管理方法的流程示意图之四；

图5为本申请实施例中的数据生命周期管理装置的结构图之一；

图6为本申请实施例中的数据生命周期管理装置的结构图之二；

图7为本申请实施例中的数据生命周期管理装置的结构图之三；

图8为本申请实施例中的数据生命周期管理装置的结构图之四；

图9为本申请实施例中的电子设备的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整的描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

考虑到在现有技术中一些系统数据清理必须通过Delete命令执行，无法进行按日分表，这部分数据的特点是仅能根据状态码进行删除指定日期的部分数据。这类数据表创建分表需要同步改造应用系统，有些系统改造难度非常大，代价非常高，因此这类数据表将不进行按日创建分表的操作，而采用Delete的方式，基于日期删除指定时间的数据。这种情况下，由于Delete删除数据将占用大量的服务器资源，因此此时数据库提供服务的能力将受到影响，所以通常这类操作选择在业务低峰期，也就是凌晨执行。这类数据在删除前还需要进行备份，将数据导出，传输到归档数据库服务器，并执行导入操作。导入完成后需要进行数据量的核对，确保两边数据量一致后，才能执行删除操作。全流程都需要人工参与，随着运维系统的增加，人员成本也越来越高，而且效率极低的问题，本申请提供一种数据生命周期管理方法及装置，通过在核对业务表、中间表、本地历史表以及历史库历史表的数据字段和索引属性一致且判断所述本地历史表中无数据时，获取所述业务表中的待迁移数据，将所述业务表中的待迁移数据迁移至所述本地历史表中，并根据所述待迁移数据的时间字段确定对应的历史库历史表，将所述本地历史表中的待迁移数据迁移至所述历史库历史表中，能够有效提升数据清理的效率和准确性。

为了能够有效提升数据清理的效率和准确性，本申请提供一种数据生命周期管理方法的实施例，参见图1，所述数据生命周期管理方法具体包含有如下内容：

步骤S101：在核对业务表、中间表、本地历史表以及历史库历史表的数据字段和索引属性一致且判断所述本地历史表中无数据时，获取所述业务表中的待迁移数据。

可选的，本申请主体程序代码封装到dba_rotate_main_prc存储过程中，数据治理程序将由此开始执行，主体程序执行时将依次调用子程序，子程序也被封装到存储过程中，这样做的好处是易于调试，在发生问题时容易判断和解决问题。并且修改时，也可以保证影响仅控制在单个存储过程中。

可选的，依次调用的子程序分别为：

(1)dba_rotate_compare_prc：核对业务表、中间表字段及属性信息，若不一致则进行修复。

(2)dba_rotate_diff_prc：核对业务表、本地历史表、历史库历史表的字段及索引信息，确认一致才允许继续执行下面的流程。

可选的，本申请可以调用dba_rotate_precheck_normal_prc存储过程，该存储过程用于检查本地历史表数据是否为0，若为0则统计本次数据迁移的行数，否则程序终止。首先通过Count命令检查本地历史表数据量是否为0，若不为0则说明上次数据治理程序运行失败，存在未完成数据，需要人工介入，将数据同步到历史库历史表中。若统计后的数据为0，则通过Count和时间字段统计当日需要迁移的数据量，并将该数据量以参数的形式传递给下一流程。

在本申请的一些实施例中，启动dba_rotate_main_prc任务时，首先需要调用dba_rotate_compare_prc存储过程。该存储过程主要检查分区表、历史表的字段及属性信息是否一致。通过查询数据库的数据字典sys.dba_tab_columns可以得到业务表和本地历史表的字段及属性信息，若信息一致，则此流程执行结束，程序将进入下一流程。若信息不一致，则进行此流程的修复模块。

可选的，修复模块首先将创建业务表和本地历史表的副本，副本与原表除表名不一致外，其余均一致。再通过dbms_metadata_diff.compare_alter函数进行对比，生成修复字段不一致的SQL命令。该命令将首先在历史表副本执行，若执行成功，则使用本地历史表的表名、中间表和历史库历史表的表名替换修复SQL中本地历史表副本的表名，然后依次在业务库和历史库执行该命令，最终确保业务表的字段及属性与中间表、本地历史表及历史库历史表一致。

在本申请的一些实施例中，本申请还可以调用dba_rotate_diff_prc存储过程，该存储过程主要用于检查业务表、本地历史表、历史库历史表的字段、索引信息是否一致。若业务表存在中间表，并且属于分区表，则需要检查业务表和中间表字段及属性信息是否一致，可以通过数据字典dba_tab_cols查询到业务表和中间表的字段信息。并用同样的方法检查业务表和本地历史表的字段及属性是否一致。最后再检查业务表和历史库历史表的字段及属性是否一致。

这里需要注意，由于历史库与业务数据库分别部署在不同的服务器上面，因此在查询历史库历史表的字段信息时，需要通过dblink进行查询操作。接下来将进行索引信息的检查，首先将检查业务表和中间表索引信息是否一致，可以通过查询数据字典dba_ind_columns，dba_indexes进行确认。再通过同样的方法检查业务表和本地历史表索引信息是否一致。历史库历史表索引信息不需要检查，因为分区表在清理数据时通过分区交换实现，而数据导入到历史库是通过Insert命令实现。原理不一样，所以历史库不要求索引与业务库一致。若字段及索引信息均一致，则进入下一步。

步骤S102：将所述业务表中的待迁移数据迁移至所述本地历史表中，并根据所述待迁移数据的时间字段确定对应的历史库历史表。

可选的，本申请可以调用dba_rotate_normal_prc存储过程，该存储过程用于将业务表需要迁移的数据通过Insert命令插入到本地历史表中，再从业务表删除迁移数据。首先根据时间字段确认需要迁移的数据，执行拼接好的Insert命令后，数据将被插入到本地历史表中。此时可通过SQL％ROWCOUNT函数记录插入的数据量。若此数据量与上一步统计的当日数据迁移量一致，则在业务表中通过delete删除这部分迁移数据，并通过SQL％ROWCOUNT函数记录删除的数据量。若删除数据量与迁移数据量一致则将事务提交。否则回滚事务，并终止程序。

步骤S103：将所述本地历史表中的待迁移数据迁移至所述历史库历史表中。

可选的，本申请可以调用dba_rotate_dblink_prc存储过程，该存储过程依据迁移日期，生成DBLINK，便于程序自动识别该将数据插入到哪个历史库当中。受限于磁盘容量，每年的数据均存储在不同的历史库当中，因此便要求根据待迁移数据的时间字段动态生成对应的历史库dblink。此流程将依据普通表和分区表进行判断，若为普通表则根据数据中的时间字段提取年的信息，创建的dblink命名格式为：MIGRATE_LINK_YYYY，例如待迁移的数据时间字段为2016年，则创建的dblink为MIGRATE_LINK_2016。通过这种方式，不同日期的数据，将自动归档到不同的历史库当中。后面再介绍分区表流程时在讲解分区表创建dblink的方法。

可选的，本申请可以调用dba_rotate_hist_prc存储过程，该存储过程负责将本地历史表的数据迁移到历史库历史表中。首先通过Insert和dblink命令将数据插入到历史库历史表中，通过SQL％ROWCOUNT函数记录插入的数据量，若此数据量与当日需要迁移的数据量一致，则通过Truncate命令，清空本地历史表的数据。到此为止，普通表数据治理流程结束，数据已从业务表经过本地历史表，最终迁移到历史库历史表中

从上述描述可知，本申请实施例提供的数据生命周期管理方法，能够通过在核对业务表、中间表、本地历史表以及历史库历史表的数据字段和索引属性一致且判断所述本地历史表中无数据时，获取所述业务表中的待迁移数据，将所述业务表中的待迁移数据迁移至所述本地历史表中，并根据所述待迁移数据的时间字段确定对应的历史库历史表，将所述本地历史表中的待迁移数据迁移至所述历史库历史表中，能够有效提升数据清理的效率和准确性。

为了能够准确区分出分区表，在本申请的数据生命周期管理方法的一实施例中，参见图2，上述步骤S101还可以具体包含如下内容：

步骤S201：判断所述业务表是否为分区表。

步骤S202：若是，则根据所述分区表的分区字段和迁移日期判断所述分区表中是否存在历史数据，若存在，则将所述历史数据迁移至所述历史库历史表中。

可选的，本申请可以将区分业务表属于普通表还是分区表，首先我们介绍普通表的调用流程。普通表的数据治理流程与分区表区别很大，分区表的主要技术采用分区交换，该技术的优点是仅需修改数据字典，并不需要消耗服务器CPU、IO资源。而普通表则通过Delete和Insert方法进行数据迁移及删除。此方法对服务器资源消耗较大，因此通常建议将普通表修改为分区表。但有些业务模块无停机窗口，或该表属于核心表修改为分区表无适合的字段，需要新增分区字段，因此需要进行验证的步骤将非常多，为了业务的运行稳定，通常这类普通表将不修改为分区表。

可选的，如果需要迁移的业务表属于分区表，首先要调用dba_rotate_par_rows_check_prc存储过程，该存储过程用于检查分区表中是否存在历史数据，此处的历史数据表示已经迁移过的分区中存在数据的情况。通常这类情况是由于业务的故障导致，此时业务重新跑批量数据，导致了数据的插入。遇到这种情况，通常需要与开发确认后，将这部分数据人工迁移至历史库历史表中。此存储过程任务开始时需要通过查询数据字典dba_part_key_columns确认分区字段的数量，若分区字段不等于1则报错，若为1则记录分区字段的名字。通过使用分区字段和迁移日期可以确认业务表历史分区中是否存在数据。若无数据，则进入下一流程。

为了能够准确确定分区表中的待迁移数据，在本申请的数据生命周期管理方法的一实施例中，参见图3，上述步骤S101还可以具体包含如下内容：

步骤S301：判断所述中间表是否为空，若是，则根据待迁移数据的时间字段确定所述分区表的分区名。

步骤S302：根据所述分区名确定所述待迁移数据的数据量并获取所述待迁移数据。

可选的，本申请可以调用dba_rotate_precheck_par_prc存储过程，此存储过程用于检查中间表、本地历史表的数据量是否为0，如果为0则统计今日迁移的数量，否则数据治理程序终止。首先通过Count命令统计中间表和本地历史表的数据量，若均为0则通过待迁移数据的时间字段找到该分区的High_value，通过High_value可以确定分区名。最后则利用分区名统计今日需要迁移的数据量，并将此信息通过参数传递给下一步骤。

为了能够准确对分区表进行数据迁移，在本申请的数据生命周期管理方法的一实施例中，参见图4，上述步骤S102还可以具体包含如下内容：

步骤S401：根据预设交换分区命令，通过包含所述待迁移数据的分区表与所述中间表进行分区交换操作将所述待迁移数据迁移至所述中间表中，并删除所述分区表。

步骤S402：通过所述中间表与所述本地历史表进行分区交换操作将所述待迁移数据迁移至所述本地历史表中。

可选的，本申请可以调用dba_rotate_par_prc存储过程，此存储过程负责将数据从当前分区迁移到中间表，然后再迁移到本地历史表。首先通过交换分区命令，将包含当日迁移数据的分区与中间表进行分区交换，此时数据由分区表交换到中间表中。再将中间表与本地历史表进行分区交换，则数据由中间表迁移到本地历史表中。分区交换的耗时极短，仅需要修改数据字典，因此效率极高。但需要注意的是，如果分区表存在全局索引的情况下，需要在执行分区交换时指定'INCLUDING INDEXES without validation updateglobal indexes'参数，此参数可以在分区交换执行后更新全局索引的信息，确保全局索引有效。最后则统计本地历史表中的数据量，确保与迁移前统计的数据量一致。若一致则进入下一步，否则数据治理程序终止。

可选的，本申请可以调用dba_rotate_dblink_prc存储过程，此存储过程依据迁移日期，生成DBLINK。此处仅介绍分区表的流程，区别于普通表，此处是根据迁移分区的时间字段提取年的信息，并动态生成dblink。

可选的，本申请可以调用dba_rotate_hist_prc存储过程，该存储过程负责将本地历史表的数据迁移到历史库历史表中。首先通过Insert和dblink命令将数据插入到历史库历史表中，通过SQL％ROWCOUNT函数记录插入的数据量，若此数据量与当日需要迁移的数据量一致，则通过Truncate命令，清空本地历史表的数据。

可选的，本申请可以调用dba_rotate_auto_drop_prc存储过程，此存储过程用于删除已迁移走数据的空分区，并且仅删除超过规定时间的空分区。首先需要检查待删除分区的数据是否为0，若为0则通过drop命令删除此分区，删除时需要使用'update globalindexes'参数，避免全局索引失效。本地历史表也通过此方法删除空分区。到此为止，分区表的数据治理流程已全部结束。

为了能够有效提升数据清理的效率和准确性，本申请提供一种用于实现所述数据生命周期管理方法的全部或部分内容的数据生命周期管理装置的实施例，参见图5，所述数据生命周期管理装置具体包含有如下内容：

待迁移数据获取模块10，用于在核对业务表、中间表、本地历史表以及历史库历史表的数据字段和索引属性一致且判断所述本地历史表中无数据时，获取所述业务表中的待迁移数据。

本地迁移模块20，用于将所述业务表中的待迁移数据迁移至所述本地历史表中，并根据所述待迁移数据的时间字段确定对应的历史库历史表。

历史库迁移模块30，用于将所述本地历史表中的待迁移数据迁移至所述历史库历史表中。

从上述描述可知，本申请实施例提供的数据生命周期管理装置，能够通过在核对业务表、中间表、本地历史表以及历史库历史表的数据字段和索引属性一致且判断所述本地历史表中无数据时，获取所述业务表中的待迁移数据，将所述业务表中的待迁移数据迁移至所述本地历史表中，并根据所述待迁移数据的时间字段确定对应的历史库历史表，将所述本地历史表中的待迁移数据迁移至所述历史库历史表中，能够有效提升数据清理的效率和准确性。

为了能够准确区分出分区表，在本申请的数据生命周期管理装置的一实施例中，参见图6，所述待迁移数据获取模块10还包括：

分区表判断单元11，用于判断所述业务表是否为分区表。

分区历史数据处理单元12，用于若判断所述业务表为分区表，则根据所述分区表的分区字段和迁移日期判断所述分区表中是否存在历史数据，若存在，则将所述历史数据迁移至所述历史库历史表中。

为了能够准确确定分区表中的待迁移数据，在本申请的数据生命周期管理装置的一实施例中，参见图7，所述待迁移数据获取模块10还包括：

分区名确定单元13，用于判断所述中间表是否为空，若是，则根据待迁移数据的时间字段确定所述分区表的分区名。

分区待迁移数据确定单元14，用于根据所述分区名确定所述待迁移数据的数据量并获取所述待迁移数据。

为了能够准确对分区表进行数据迁移，在本申请的数据生命周期管理装置的一实施例中，参见图8，所述本地迁移模块20包括：

中间表交换单元21，用于根据预设交换分区命令，通过包含所述待迁移数据的分区表与所述中间表进行分区交换操作将所述待迁移数据迁移至所述中间表中，并删除所述分区表。

本地历史表交换单元22，用于通过所述中间表与所述本地历史表进行分区交换操作将所述待迁移数据迁移至所述本地历史表中。

为了更进一步说明本方案，本申请还提供一种应用上述数据生命周期管理装置实现数据生命周期管理方法的具体应用实例，具体包含有如下内容：

步骤1，首先需要创建错误代码，当数据治理程序异常时，通过日志中的错误代码，可以很快的定位并修复问题，错误代码对应信息如下：

--20001业务表与中间表字段属性不一致

--20002业务表与本地历史表字段属性不一致

--20003业务表与历史库历史表字段属性不一致

--20004业务表与中间表索引字段属性不一致

--20005业务表与本地历史表索引字段属性不一致

--20006本地历史表不为空

--20007本地历史表、中间表不为空

--20008业务表删除数据与当日迁移数据不一致

--20009普通表本地历史表插入数据与迁移数据不一致

--20010分区表本地历史表插入数据与迁移数据不一致

--20011配置表更新失败

--20012历史库历史表插入数据与迁移数据不一致

--20013要删除的本地历史表历史分区不为空

--20014要删除的业务表历史分区不为空

--20015表类型既不是普通表也不是分区表

--20016如果配置表中current_data_date大于target_data_date报警

--20017检测小于current_data_date是否存在数据

--20018分区表存在多个分区字段

步骤2，主体程序代码封装到dba_rotate_main_prc存储过程中，数据治理程序将由此开始执行，主体程序执行时将依次调用子程序，子程序也被封装到存储过程中，这样做的好处是易于调试，在发生问题时容易判断和解决问题。并且修改时，也可以保证影响仅控制在单个存储过程中。

依次调用的子程序分别为：

2.1dba_rotate_compare_prc：核对业务表、中间表字段及属性信息，若不一致则进行修复。

2.2dba_rotate_diff_prc：核对业务表、本地历史表、历史库历史表的字段及索引信息，确认一致才允许继续执行下面的流程。

普通表调用流程：

2.3dba_rotate_precheck_normal_prc：检查本地历史表数据量是否为零，如果为零，返回本次迁移行数，否则程序终止。

2.4dba_rotate_normal_prc：将数据从业务表迁移到本地历史表。

2.5dba_rotate_dblink_prc：依据迁移日期，生成DBLINK。

2.6dba_rotate_hist_prc：将数据从本地历史表迁移到历史库历史表。

分区表调用流程：

2.3dba_rotate_par_rows_check_prc：检测历史数据是否有值。

2.4dba_rotate_precheck_par_prc：检查中间表、本地历史表数据量是否为零，如果为零，返回本次迁移分区行数，否则程序终止。

2.5dba_rotate_par_prc：首先将数据从业务表的分区迁移到中间表，然后再迁移到本地历史表。

2.6dba_rotate_dblink_prc：依据迁移日期，生成DBLINK。

2.7dba_rotate_hist_prc：将数据从本地历史表迁移到历史库历史表。

2.8dba_rotate_auto_drop_prc：删除业务表N天前的空分区，N需要根据业务对数据的保留时间进行确定。

步骤3，启动dba_rotate_main_prc任务时，首先需要调用dba_rotate_compare_prc存储过程。该存储过程主要检查分区表、历史表的字段及属性信息是否一致。通过查询数据库的数据字典sys.dba_tab_columns可以得到业务表和本地历史表的字段及属性信息，若信息一致，则此流程执行结束，程序将进入下一流程。若信息不一致，则进行此流程的修复模块。

修复模块首先将创建业务表和本地历史表的副本，副本与原表除表名不一致外，其余均一致。再通过dbms_metadata_diff.compare_alter函数进行对比，生成修复字段不一致的SQL命令。该命令将首先在历史表副本执行，若执行成功，则使用本地历史表的表名、中间表和历史库历史表的表名替换修复SQL中本地历史表副本的表名，然后依次在业务库和历史库执行该命令，最终确保业务表的字段及属性与中间表、本地历史表及历史库历史表一致。

步骤4，调用dba_rotate_diff_prc存储过程，该存储过程主要用于检查业务表、本地历史表、历史库历史表的字段、索引信息是否一致。若业务表存在中间表，并且属于分区表，则需要检查业务表和中间表字段及属性信息是否一致，可以通过数据字典dba_tab_cols查询到业务表和中间表的字段信息。并用同样的方法检查业务表和本地历史表的字段及属性是否一致。最后再检查业务表和历史库历史表的字段及属性是否一致。

这里需要注意，由于历史库与业务数据库分别部署在不同的服务器上面，因此在查询历史库历史表的字段信息时，需要通过dblink进行查询操作。接下来将进行索引信息的检查，首先将检查业务表和中间表索引信息是否一致，可以通过查询数据字典dba_ind_columns，dba_indexes进行确认。再通过同样的方法检查业务表和本地历史表索引信息是否一致。历史库历史表索引信息不需要检查，因为分区表在清理数据时通过分区交换实现，而数据导入到历史库是通过Insert命令实现。原理不一样，所以历史库不要求索引与业务库一致。若字段及索引信息均一致，则进入下一步。

步骤5，此步将区分业务表属于普通表还是分区表，首先我们介绍普通表的调用流程。普通表的数据治理流程与分区表区别很大，分区表的主要技术采用分区交换，该技术的优点是仅需修改数据字典，并不需要消耗服务器CPU、IO资源。而普通表则通过Delete和Insert方法进行数据迁移及删除。此方法对服务器资源消耗较大，因此通常建议将普通表修改为分区表。但有些业务模块无停机窗口，或该表属于核心表修改为分区表无适合的字段，需要新增分区字段，因此需要进行验证的步骤将非常多，为了业务的运行稳定，通常这类普通表将不修改为分区表，下面将介绍普通表的调用流程。

步骤6，调用dba_rotate_precheck_normal_prc存储过程，该存储过程用于检查本地历史表数据是否为0，若为0则统计本次数据迁移的行数，否则程序终止。首先通过Count命令检查本地历史表数据量是否为0，若不为0则说明上次数据治理程序运行失败，存在未完成数据，需要人工介入，将数据同步到历史库历史表中。若统计后的数据为0，则通过Count和时间字段统计当日需要迁移的数据量，并将该数据量以参数的形式传递给下一流程。

步骤7，调用dba_rotate_normal_prc存储过程，该存储过程用于将业务表需要迁移的数据通过Insert命令插入到本地历史表中，再从业务表删除迁移数据。首先根据时间字段确认需要迁移的数据，执行拼接好的Insert命令后，数据将被插入到本地历史表中。此时可通过SQL％ROWCOUNT函数记录插入的数据量。若此数据量与上一步统计的当日数据迁移量一致，则在业务表中通过delete删除这部分迁移数据，并通过SQL％ROWCOUNT函数记录删除的数据量。若删除数据量与迁移数据量一致则将事务提交。否则回滚事务，并终止程序。

步骤8，调用dba_rotate_dblink_prc存储过程，该存储过程依据迁移日期，生成DBLINK，便于程序自动识别该将数据插入到哪个历史库当中。受限于磁盘容量，每年的数据均存储在不同的历史库当中，因此便要求根据待迁移数据的时间字段动态生成对应的历史库dblink。此流程将依据普通表和分区表进行判断，若为普通表则根据数据中的时间字段提取年的信息，创建的dblink命名格式为：MIGRATE_LINK_YYYY，例如待迁移的数据时间字段为2016年，则创建的dblink为MIGRATE_LINK_2016。通过这种方式，不同日期的数据，将自动归档到不同的历史库当中。后面再介绍分区表流程时在讲解分区表创建dblink的方法。

步骤9，调用dba_rotate_hist_prc存储过程，该存储过程负责将本地历史表的数据迁移到历史库历史表中。首先通过Insert和dblink命令将数据插入到历史库历史表中，通过SQL％ROWCOUNT函数记录插入的数据量，若此数据量与当日需要迁移的数据量一致，则通过Truncate命令，清空本地历史表的数据。到此为止，普通表数据治理流程结束，数据已从业务表经过本地历史表，最终迁移到历史库历史表中，接下来将介绍分区表的迁移流程。

步骤10，如果需要迁移的业务表属于分区表，则从步骤5以后需要走下面的流程。首先要调用dba_rotate_par_rows_check_prc存储过程，该存储过程用于检查分区表中是否存在历史数据，此处的历史数据表示已经迁移过的分区中存在数据的情况。通常这类情况是由于业务的故障导致，此时业务重新跑批量数据，导致了数据的插入。遇到这种情况，通常需要与开发确认后，将这部分数据人工迁移至历史库历史表中。此存储过程任务开始时需要通过查询数据字典dba_part_key_columns确认分区字段的数量，若分区字段不等于1则报错，若为1则记录分区字段的名字。通过使用分区字段和迁移日期可以确认业务表历史分区中是否存在数据。若无数据，则进入下一流程。

步骤11，调用dba_rotate_precheck_par_prc存储过程，此存储过程用于检查中间表、本地历史表的数据量是否为0，如果为0则统计今日迁移的数量，否则数据治理程序终止。首先通过Count命令统计中间表和本地历史表的数据量，若均为0则通过待迁移数据的时间字段找到该分区的High_value，通过High_value可以确定分区名。最后则利用分区名统计今日需要迁移的数据量，并将此信息通过参数传递给下一步骤。

步骤12，调用dba_rotate_par_prc存储过程，此存储过程负责将数据从当前分区迁移到中间表，然后再迁移到本地历史表。首先通过交换分区命令，将包含当日迁移数据的分区与中间表进行分区交换，此时数据由分区表交换到中间表中。再将中间表与本地历史表进行分区交换，则数据由中间表迁移到本地历史表中。分区交换的耗时极短，仅需要修改数据字典，因此效率极高。但需要注意的是，如果分区表存在全局索引的情况下，需要在执行分区交换时指定'INCLUDING INDEXES without validation update global indexes'参数，此参数可以在分区交换执行后更新全局索引的信息，确保全局索引有效。最后则统计本地历史表中的数据量，确保与迁移前统计的数据量一致。若一致则进入下一步，否则数据治理程序终止。

步骤13，调用dba_rotate_dblink_prc存储过程，此存储过程依据迁移日期，生成DBLINK。此处仅介绍分区表的流程，区别于普通表，此处是根据迁移分区的时间字段提取年的信息，并动态生成dblink。

步骤14，调用dba_rotate_hist_prc存储过程，该存储过程负责将本地历史表的数据迁移到历史库历史表中。首先通过Insert和dblink命令将数据插入到历史库历史表中，通过SQL％ROWCOUNT函数记录插入的数据量，若此数据量与当日需要迁移的数据量一致，则通过Truncate命令，清空本地历史表的数据。

步骤15，调用dba_rotate_auto_drop_prc存储过程，此存储过程用于删除已迁移走数据的空分区，并且仅删除超过规定时间的空分区。首先需要检查待删除分区的数据是否为0，若为0则通过drop命令删除此分区，删除时需要使用'update global indexes'参数，避免全局索引失效。本地历史表也通过此方法删除空分区。到此为止，分区表的数据治理流程已全部结束。

有上述内容可知，本申请可以根据业务的需求，自动将不再被使用的数据从业务数据库中迁移到历史数据库。通常能使数据库磁盘的使用量保持稳定，也节省了备份所需的磁盘空间，在数据量恒定的情况下，数据库所需要的CPU和内存资源同通常也较为稳定，所以经过数据治理的数据库通常不需要进行服务器资源的扩容，也不再需要人工进行定期的数据清理，尤其是在业务系统较多的环境下，节省的服务器扩容成本和人工维护成本极大，同时也避免了随着数据量的增长而导致的性能问题。

从硬件层面来说，为了能够有效提升数据清理的效率和准确性，本申请提供一种用于实现所述数据生命周期管理方法中的全部或部分内容的电子设备的实施例，所述电子设备具体包含有如下内容：

处理器(processor)、存储器(memory)、通信接口(Communications Interface)和总线；其中，所述处理器、存储器、通信接口通过所述总线完成相互间的通信；所述通信接口用于实现数据生命周期管理装置与核心业务系统、用户终端以及相关数据库等相关设备之间的信息传输；该逻辑控制器可以是台式计算机、平板电脑及移动终端等，本实施例不限于此。在本实施例中，该逻辑控制器可以参照实施例中的数据生命周期管理方法的实施例，以及数据生命周期管理装置的实施例进行实施，其内容被合并于此，重复之处不再赘述。

可以理解的是，所述用户终端可以包括智能手机、平板电子设备、网络机顶盒、便携式计算机、台式电脑、个人数字助理(PDA)、车载设备、智能穿戴设备等。其中，所述智能穿戴设备可以包括智能眼镜、智能手表、智能手环等。

在实际应用中，数据生命周期管理方法的部分可以在如上述内容所述的电子设备侧执行，也可以所有的操作都在所述客户端设备中完成。具体可以根据所述客户端设备的处理能力，以及用户使用场景的限制等进行选择。本申请对此不作限定。若所有的操作都在所述客户端设备中完成，所述客户端设备还可以包括处理器。

上述的客户端设备可以具有通信模块(即通信单元)，可以与远程的服务器进行通信连接，实现与所述服务器的数据传输。所述服务器可以包括任务调度中心一侧的服务器，其他的实施场景中也可以包括中间平台的服务器，例如与任务调度中心服务器有通信链接的第三方服务器平台的服务器。所述的服务器可以包括单台计算机设备，也可以包括多个服务器组成的服务器集群，或者分布式装置的服务器结构。

图9为本申请实施例的电子设备9600的系统构成的示意框图。如图9所示，该电子设备9600可以包括中央处理器9100和存储器9140；存储器9140耦合到中央处理器9100。值得注意的是，该图9是示例性的；还可以使用其他类型的结构，来补充或代替该结构，以实现电信功能或其他功能。

一实施例中，数据生命周期管理方法功能可以被集成到中央处理器9100中。

其中，中央处理器9100可以被配置为进行如下控制：

步骤S101：在核对业务表、中间表、本地历史表以及历史库历史表的数据字段和索引属性一致且判断所述本地历史表中无数据时，获取所述业务表中的待迁移数据。

步骤S102：将所述业务表中的待迁移数据迁移至所述本地历史表中，并根据所述待迁移数据的时间字段确定对应的历史库历史表。

步骤S103：将所述本地历史表中的待迁移数据迁移至所述历史库历史表中。

从上述描述可知，本申请实施例提供的电子设备，通过在核对业务表、中间表、本地历史表以及历史库历史表的数据字段和索引属性一致且判断所述本地历史表中无数据时，获取所述业务表中的待迁移数据，将所述业务表中的待迁移数据迁移至所述本地历史表中，并根据所述待迁移数据的时间字段确定对应的历史库历史表，将所述本地历史表中的待迁移数据迁移至所述历史库历史表中，能够有效提升数据清理的效率和准确性。

在另一个实施方式中，数据生命周期管理装置可以与中央处理器9100分开配置，例如可以将数据生命周期管理装置配置为与中央处理器9100连接的芯片，通过中央处理器的控制来实现数据生命周期管理方法功能。

如图9所示，该电子设备9600还可以包括：通信模块9110、输入单元9120、音频处理器9130、显示器9160、电源9170。值得注意的是，电子设备9600也并不是必须要包括图9中所示的所有部件；此外，电子设备9600还可以包括图9中没有示出的部件，可以参考现有技术。

如图9所示，中央处理器9100有时也称为控制器或操作控件，可以包括微处理器或其他处理器装置和/或逻辑装置，该中央处理器9100接收输入并控制电子设备9600的各个部件的操作。

其中，存储器9140，例如可以是缓存器、闪存、硬驱、可移动介质、易失性存储器、非易失性存储器或其它合适装置中的一种或更多种。可储存上述与失败有关的信息，此外还可存储执行有关信息的程序。并且中央处理器9100可执行该存储器9140存储的该程序，以实现信息存储或处理等。

输入单元9120向中央处理器9100提供输入。该输入单元9120例如为按键或触摸输入装置。电源9170用于向电子设备9600提供电力。显示器9160用于进行图像和文字等显示对象的显示。该显示器例如可为LCD显示器，但并不限于此。

该存储器9140可以是固态存储器，例如，只读存储器(ROM)、随机存取存储器(RAM)、SIM卡等。还可以是这样的存储器，其即使在断电时也保存信息，可被选择性地擦除且设有更多数据，该存储器的示例有时被称为EPROM等。存储器9140还可以是某种其它类型的装置。存储器9140包括缓冲存储器9141(有时被称为缓冲器)。存储器9140可以包括应用/功能存储部9142，该应用/功能存储部9142用于存储应用程序和功能程序或用于通过中央处理器9100执行电子设备9600的操作的流程。

存储器9140还可以包括数据存储部9143，该数据存储部9143用于存储数据，例如联系人、数字数据、图片、声音和/或任何其他由电子设备使用的数据。存储器9140的驱动程序存储部9144可以包括电子设备的用于通信功能和/或用于执行电子设备的其他功能(如消息传送应用、通讯录应用等)的各种驱动程序。

通信模块9110即为经由天线9111发送和接收信号的发送机/接收机9110。通信模块(发送机/接收机)9110耦合到中央处理器9100，以提供输入信号和接收输出信号，这可以和常规移动通信终端的情况相同。

基于不同的通信技术，在同一电子设备中，可以设置有多个通信模块9110，如蜂窝网络模块、蓝牙模块和/或无线局域网模块等。通信模块(发送机/接收机)9110还经由音频处理器9130耦合到扬声器9131和麦克风9132，以经由扬声器9131提供音频输出，并接收来自麦克风9132的音频输入，从而实现通常的电信功能。音频处理器9130可以包括任何合适的缓冲器、解码器、放大器等。另外，音频处理器9130还耦合到中央处理器9100，从而使得可以通过麦克风9132能够在本机上录音，且使得可以通过扬声器9131来播放本机上存储的声音。

本申请的实施例还提供能够实现上述实施例中的执行主体为服务器或客户端的数据生命周期管理方法中全部步骤的一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中的执行主体为服务器或客户端的数据生命周期管理方法的全部步骤，例如，所述处理器执行所述计算机程序时实现下述步骤：

步骤S101：在核对业务表、中间表、本地历史表以及历史库历史表的数据字段和索引属性一致且判断所述本地历史表中无数据时，获取所述业务表中的待迁移数据。

步骤S102：将所述业务表中的待迁移数据迁移至所述本地历史表中，并根据所述待迁移数据的时间字段确定对应的历史库历史表。

步骤S103：将所述本地历史表中的待迁移数据迁移至所述历史库历史表中。

从上述描述可知，本申请实施例提供的计算机可读存储介质，通过在核对业务表、中间表、本地历史表以及历史库历史表的数据字段和索引属性一致且判断所述本地历史表中无数据时，获取所述业务表中的待迁移数据，将所述业务表中的待迁移数据迁移至所述本地历史表中，并根据所述待迁移数据的时间字段确定对应的历史库历史表，将所述本地历史表中的待迁移数据迁移至所述历史库历史表中，能够有效提升数据清理的效率和准确性。

本领域内的技术人员应明白，本发明的实施例可提供为方法、装置、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(装置)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

本发明中应用了具体实施例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (10)

1.一种数据生命周期管理方法，其特征在于，所述方法包括：

在核对业务表、中间表、本地历史表以及历史库历史表的数据字段和索引属性一致且判断所述本地历史表中无数据时，获取所述业务表中的待迁移数据；

将所述业务表中的待迁移数据迁移至所述本地历史表中，并根据所述待迁移数据的时间字段确定对应的历史库历史表；

将所述本地历史表中的待迁移数据迁移至所述历史库历史表中。

2.根据权利要求1所述的数据生命周期管理方法，其特征在于，在所述核对业务表、中间、本地历史表以及历史库历史表的数据字段和索引属性一致后，包括：

判断所述业务表是否为分区表；

若是，则根据所述分区表的分区字段和迁移日期判断所述分区表中是否存在历史数据，若存在，则将所述历史数据迁移至所述历史库历史表中。

3.根据权利要求2所述的数据生命周期管理方法，其特征在于，所述获取所述业务表中的待迁移数据，包括：

判断所述中间表是否为空，若是，则根据待迁移数据的时间字段确定所述分区表的分区名；

根据所述分区名确定所述待迁移数据的数据量并获取所述待迁移数据。

4.根据权利要求2所述的数据生命周期管理方法，其特征在于，所述将所述业务表中的待迁移数据迁移至所述本地历史表中，包括：

根据预设交换分区命令，通过包含所述待迁移数据的分区表与所述中间表进行分区交换操作将所述待迁移数据迁移至所述中间表中，并删除所述分区表；

通过所述中间表与所述本地历史表进行分区交换操作将所述待迁移数据迁移至所述本地历史表中。

5.一种数据生命周期管理装置，其特征在于，包括：

待迁移数据获取模块，用于在核对业务表、中间表、本地历史表以及历史库历史表的数据字段和索引属性一致且判断所述本地历史表中无数据时，获取所述业务表中的待迁移数据；

本地迁移模块，用于将所述业务表中的待迁移数据迁移至所述本地历史表中，并根据所述待迁移数据的时间字段确定对应的历史库历史表；

历史库迁移模块，用于将所述本地历史表中的待迁移数据迁移至所述历史库历史表中。

6.根据权利要求5所述的数据生命周期管理装置，其特征在于，所述待迁移数据获取模块还包括：

分区表判断单元，用于判断所述业务表是否为分区表；

分区历史数据处理单元，用于若判断所述业务表为分区表，则根据所述分区表的分区字段和迁移日期判断所述分区表中是否存在历史数据，若存在，则将所述历史数据迁移至所述历史库历史表中。

7.根据权利要求6所述的数据生命周期管理装置，其特征在于，所述待迁移数据获取模块还包括：

分区名确定单元，用于判断所述中间表是否为空，若是，则根据待迁移数据的时间字段确定所述分区表的分区名；

分区待迁移数据确定单元，用于根据所述分区名确定所述待迁移数据的数据量并获取所述待迁移数据。

8.根据权利要求6所述的数据生命周期管理装置，其特征在于，所述本地迁移模块包括：

中间表交换单元，用于根据预设交换分区命令，通过包含所述待迁移数据的分区表与所述中间表进行分区交换操作将所述待迁移数据迁移至所述中间表中，并删除所述分区表；

本地历史表交换单元，用于通过所述中间表与所述本地历史表进行分区交换操作将所述待迁移数据迁移至所述本地历史表中。

9.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1至4任一项所述的数据生命周期管理方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1至4任一项所述的数据生命周期管理方法的步骤。

Images