solix归档规范

阅读量：7210 次

发布时间：2019-06-29

本文共 8996 字，大约阅读时间需要 29 分钟。

1.1 背景及目的

随着公司各项业务的快速发展，各系统的生产数据库数据量日益庞大，多年积累的业务数据占据了大量的存储空间。而且，随着表中的数据量的不断增长，导致数据操作的性能和效率逐渐降低，影响了各应用系统的正常使用，严重时甚至导致系统故障；另外，庞大的数据库也给运营维护工作带来挑战，增加了生产数据库出现异常和故障的风险。

信息也是有生命周期的，通常情况下，从其生命周期的初期到末期，数据的重要性会逐渐降低，使用频率也会随之下降,直至不再使用。伴随着这些变化的发生，我们就可以根据数据的生命周期特性实施归档，为其提供适当的可用性、成本、性能和保护、及业务数据存储空间，这样，在整个生命周期的不同阶段都能对数据进行高效有序的管理。

本规范的目的是为了实现生产数据在不同的使用阶段进行针对性的管理，以达到节省存储成本和运维成本，提高数据库的性能和效率，进而提升应用系统的可用率之目的。

1.2 适用范围

本规范适用于业务人员、开发人员、测试人员、运营接口人员、数据库管理员。

1.3 术语和缩略语

序号	术语/缩略语	全称和说明
1.	ILM	Information Lifecycle Management （信息生命周期管理）:信息生命周期是指信息从产生、保护、读取、更改、迁移、存档、回收、再次激活以及退出的整个生命过程；信息生命周期管理是对信息在贯穿其整个生命的过程中，采取相应的策略和技术实现手段进行针对性管理，目的在于帮助企业在信息生命周期的各个阶段以最低的成本获得最大的价值。
2.	DA	DB 架构师，主要负责DB的架构设计、数据模型设计、协助开发人员制定应用解决方案等。
3.	SA	软件需求需求分析师，主要负责需求获取，需求分析以及协助需求排期等工作。
4.	IA	基础架构架构师。
5.	Solix EDMS	Solix Enterprise Data Management Suite (EDMS) Solix 公司数据归档产品，我们采用该产品实现数据库的数据归档。

二、管理规范

2.1 数据分类

按照数据性质，将数据分为5大类：

业务数据

业务数据是指在日常业务系统运营的过程中，记录业务处理各个流程环节中产生的数据。这类数据是公司进行业务活动所必须的重要数据，对于业务系统的正常运行和业务方的日常经营都是不可缺少的。

临时数据

临时数据指数据库中不需长期保存的、清除后不影响业务系统的正常运行、且可以重新生成的数据。如数据库中创建的用于清单报表打印、业务中间处理、关联系统数据同步、上传和下载中间处理的数据等。

日志数据

日志数据指数据库中创建的用于记录程序运行状态、业务操作过程、数据修改、安全审计等信息的数据。

备份数据

备份数据是指在对生产数据实施DML前，将受影响的数据先复制保存下来而产生的数据。

归档数据

归档数据是指在实施信息生命周期过程中，已经进行归档的历史数据。

2.2 数据管理方式

删除

直接将数据删掉。

归档

是指将数据从业务表中剥离出来，转移到另外的表中。

分区

是指利用数据库提供的分区功能，将数据表中的数据按照某种规则来分类存放。

压缩

是指利用数据库提供的压缩技术，对数据表进行压缩，以便减小数据占用的空间，节约存储。

磁带存储

是指将数据保存在磁带中。由于磁带的成本低廉，可以节约数据的存储成本。

2.3 数据分类与对应的管理方式

：业务数据

：基表数据

基表数据是用于记录业务系统的基础信息，例如产品、险种等数据，由于这类数据是系统运行不可缺少的基本信息，因此，基表数据将会一直保留，不做归档。

：非基表数据

非基表数据是指除了基表数据之外的所有业务数据, 这类数据具有很强的时效性，随着时间的推移，数据被使用到的频率逐渐降低而成为历史数据, 并使得这些业务表日益臃肿, 对业务系统的运行效率有很大影响, 可管理性, 可维护性也愈渐降低。因此,非常有必要对这些历史数据实施归档。

归档项目有两个归档目标:

首次实施归档率到达20%

年持续归档率达到20%

归档率的计算公式为:

归档率 = (归档数据总容量) / (生产库数据总容量(归档后)+归档数据总容量)

注: 1. 数据容量计算中不包括索引容量

年归档率是按照整年计算, 即从1月份到12月份, 首次归档的数据量计算在当年的归档率

中;

举例如下:

	数据库总容量 (归档后)	归档数据容量	归档率 = (归档数据总容量) / (生产库数据总容量(归档后)+归档数据总容量)
2011 年9月（首次归档实施）	750G	190G	190/(750+190) =20.21%
2011 年	800G	200G	200/(200+800) =20%
2012 年	1000G	60G	(60+200)/(1000+200+60) =20.63%
2013 年	1200G	100G	(200+60+100)/(1200+200+60+100) =23.07%

可按年持续归档率达到20%的基本目标,对业务表历史数据进行可归档分析。在分析过程中, 可首先按业务表数据容量大小排序, 数据容量越大的业务表归档优先级越高。再依据表的增长率, 业务发展期等多个纬度综合分析, 整理出详细的归档需求, 以达成归档目标。

增长率的计算方法如下:

增长率= (今年数据总容量-去年数据总容量) / 去年数据总容量

具体选择归档表可按如下方法:

►

将大于2G的表做为首选范围,按表的Size排序，取排前位的表进行依次分析。

►

从多个维度对选出的表进行分析,包括:

首年归档size,以保证达到20%目标。

对该表过去五年的增长率进行分析,了解表的增长规律,通常会有如下一些情况：

表的年增长率较为稳定；

有些表的数据量随业务的发展呈现稳定增长率,此情况,可取该值作为增长率。

表的年增长数据量较为稳定；

这些表每年的数据量呈现稳定增长,因此增长率出现逐年下降趋势,因此在未来三年的归档预估中,要按该表稳定的数据增长量来分析。

有些表的年增长率并没有明变化规律, 可按照5年增长率的平均值计算,注意要排出因为数据迁移,导入,系统上线等原因出现的一些突增的情况。

根据以上这些具体的情况,分析表的增长率,以确保归档实施以后,达到每年持续归档20%的目标。

业务增长期, 某个单一业务不会无限增长下去,需要评估该业务的增长周期，即多少年后可能会出现停止增长的情况,使得原有归档策略会失效,无法达成归档目标。

对于初步筛选出的表,需要分析其主外键关系, 业务层级关系, 分析出与这些表有关的可关联归档的表, 已在归档配置中建立归档树。

此外: 可计算Rownum归档率作为参考:

Rownum

归档率 = (归档rownum) / (现有原表rownum+归档rownum)

：临时数据

参见公司制定的

，对临时表进行管理。

：日志数据

日志表管理分为两类：

：数据不需要归档保留

参见公司制定的

，对日志表进行管理。；

：数据需要归档保留

若日志表的数据需要归档备查，不能使用自动清理，需要用归档工具定期将数据进行归档。

如果数据量较大的话，还可以对日志数据进行分区和压缩。

：备份数据

参见公司制定的

《

》，

对备份数据进行管理。

：归档数据

归档数据是指从生产迁移出去的历史数据。

归档数据表容量较大的，可以进行对表进行压缩；10年以上的历史数据，必须用磁带归档保留；

数据分类与对应的管理方式如下表，有多种方式的，括号中是优先级：

管理方式数据分类	删除	归档	分区	压缩	磁带存储+删除
业务数据	基表数据	不作要求
非基表数据		√（高）	√（中）	√（低）
临时数据	√
日志数据	√（高）	√（中）	√（最低）	√（低）
备份数据	√
归档数据			√	√	√

三、信息生命周期管理――数据归档

3.1 数据归档简介

数据归档是信息生命周期管理中的重要组成部分，数据在其生命初期到末期的过程中,需要将其从原业务表中分离出来,存放在对应的归档目标表中,这个过程就是归档。所有的归档表存储在单独的表空间中。数据归档对于减少业务数据容量, 提高数据库运行效率,提升可管理性,可维护性方面有着重要的意义

3.2 数据归档实施过程

数据归档是一个不断实施和完善的过程，在起初定下一个归档目标后，需要对数据库中的现状进行分析，为了达到既定的归档任务，选择合适的表进行，明确归档条件，配置归档程序，然后对数据进行初始化归档，并定期运行归档，其后定期对归档效果进行检视，归档数据达不到设定的归档目标或重新设定了下一个目标，则需要从头开始再进行一次归档过程，如此循环往复，其示意图如下所示：

3.2.1 数据库首次实施数据归档的方法

一般来说，数据库首次实施归档的工作量比较大，时间跨度较长，因此这项工作一般会作为PPR来开展，主要工作序列和工作内容如下：

阶段	活动	负责人	实施人	交付物	详细说明
需求分析阶段	确定归档范围	DA	SA 、业务人员		为了达到首次归档率和年持续归档20%的归档目标，需要分析和明确哪些业务表需要做归档。 Note: 归档范围去定的详细方法:请参考
确定各表的归档规则、归档条件, 进行归档分析	DA	SA 、开发人员、业务人员	《归档需求分析》	由SA,开发人员,业务人员分析每个表的归档需求, 确定归档条件。由DA或者开发DBA对这些归档条件进行验证,并进行归档分析分析方法请见 Note: 《归档需求分析》的详细说明请见
归档目标分析	DA	SA 、开发DBA	《未来三年可归档数据分析》	根据归档需求说明书，预估未来三年可归档数据量和比例，并评估是否达到归档目标。若未达到目标, 则需扩大归档分析范围, 或重新分析归档条件, 直到达成目标 Note: 《未来三年可归档数据分析》的详细说明请见
归档实施方案制定	DA	开发DBA、SA	《归档实施方案》	根据需求分析结果, 制定归档实施方案, 内容包括:CC,CQ创建说明；Solix User、 KB创建方案；Configure配置规则；归档目标表创建；归档条件配置方案；实施批次方案；首次归档实施方案；空间回收实施方案等等 Note: 方案文档编写请见《归档实施方案》模板已及
方案设计阶段	资源申请	DA	SA 、IA		总的来说, 归档项目不会引起存储使用需求的增加。但是, 在归档过程中,实施空间回收之前, 归档项目需要临时增加一些存储来存放归档数据。而当实施空间回收之后, 会从原来的业务数据表空间释放出相应的存储空间, 即可冲抵临时增加的存储空间。因此,需要评估是否有足够的空间作为中转存储,如果不够,需要申请。另一方面, 需要评估数据的Redo存放空间是否满足归档的需求, 如果不满足,需要申请扩容. 此外, 如果需要搭建新的Staging环境,开发环境, 需要评估是否有足够存储。
CC, CQ 创建	DA	开发DBA,		创建CQ、PIR通道,以及CC代码库, 做为开发准备 Note: CC 、CQ创建申请的模板请见
开发阶段	归档用户,归档空间打包创建	DA	开发DBA, 运维DBA、SA		在正式开发之前,需要按照《归档实施方案》在开发,Staging,生产三套环境创建归档用户,归档空间。
源表变更的Impact Analyze 分析	DA	开发DBA	《Impact Analyzer测试报告》	为便于归档运行，可能会在一些表的外键字段上建立索引，增加索引等变更。需要测试这种变更对数据库性能的影响。因此需要做Impact Analyze分析 Note ：Impact Analyzer分析请见
归档开发	DA	开发DBA	DB 脚本、Solix配置导出文件	根据归档需求和归档方案, 进行归档开发.主要包括：DB脚本开发, SOLIX归档配置 Note:SOLIX 配置的详细方法请参考
空间回收脚本开发	DA	开发DBA		根据空间回收实施方案,开发回收脚本。主要包括以下部分：重建索引脚本、表空间回收脚本、统计信息收集脚本。
版本移交	DA	开发DBA	《移交清单》	按照版本移交流程, 实施版本移交，并部署Staging库。
Stagin 库归档实施	DA	开发DBA		在测试库完成归档实施操作
测试阶段	Staging 环境功能测试	DA	测试人员、开发DBA	《常规测试报告》	测试归档功能应用功能的回归测试
部署上线	DA	部署人员、开发DBA		部署人员按照部署说明部署DB脚本和SOLIX归档配置。
系统上线及运行阶段	生产环境-首次归档实施	DA	开发DBA，运营人员	《首次归档实施报告》	由于首次归档的数据量巨大, 所以部署上线后,在进行日常归档之前, 需要由开发DBA,运营按照《首次归档实施方案》实施首次归档。归档操作要安排非业务高峰时间,且需要运营人员确认归档的时间安排。 Note: 首次归档实施报告的详细说明请参考
空间回收,统计信息收集的Impact analyze分析	DA	开发DBA	《空间回收实施Impact analyze报告》	在空间回收实施, 统计信息重新收集之前, 一定要进行Impact Analyze分析。确保空间回收实施对数据库性能的影响. Note ：Impact Analyzer分析请见对空间回收的变更影响分析要求请参见
生产环境-重建索引、表空间回收、收集统计信息	DA	开发DBA、运维DBA	《空间回收报告》	在生产环境进行空间回收实施,按下列顺序实施变更：重建索引、表空间回收、收集统计信息。空间回收实施也须通过版本下发方式执行。
常规归档运行	常规归档运行	DA	运营人员、开发DBA		根据预定的归档计划, 定期进行日常归档实施。
发送常规归档运行报告,检视归档效果	DA	开发DBA	《常规归档运行月度汇报》	并发送归档报告。并且检视归档效果, 跟踪分析是否达到归档目标。 Note ：常规归档月度汇报详细说明请参见
新建表审计	新建表归档策略纳入流程	DA	SA 、开发DBA		对于实施了归档项目的数据库,需要对新建表进行归档分析,若有例外不做归档的表,要记录在dbmgr.archive_exception_info Table中.
定期审计表是否进行了归档	DA	开发DBA	《审计报告》	新建表需要纳入归档，审计中若发现未纳入审计并没有申请例外的表，需要进行评估并纳入归档。

3.2.2 已实施归档的数据库新建表或修改归档规则的管理办法

已经实施过归档的数据库中增加新表时，也要将新表纳入归档管理；另外，当已归档的表需要变更归档条件，同样需要按照开发流程来进行变更。

新建表若不能进行归档，需要提交例外申请，并在数据库中记录通过例外申请不进行归档的表。

具体流程如下：

通过例外申请不做归档的表记录在如下表中：

create table dbmgr.archive_exception_info

( schema varchar2(30) not null,

table_name varchar2(30) not null,

exception_reason varchar2(2000) not null,

exception_proposer varchar2(200) not null,

exception_approver varchar2(200) not null,

date_approved date not null

);

-- Add comments to the table

comment on table dbmgr.archive_exception_info is '

业务表不做归档例外申请登记表';

-- Add comments to the columns

comment on column dbmgr.archive_exception_info.schema is '

通过例外申请的表属主' ;

comment on column dbmgr.archive_exception_info.table_name is '

通过例外申请的表名';

comment on column dbmgr.archive_exception_info.exception_reason is '

例外申请原因';

comment on column dbmgr.archive_exception_info.exception_proposer is '

例外申请提出人';

comment on column dbmgr.archive_exception_info.exception_approver is '

例外申请审批人';

comment on column dbmgr.archive_exception_info.date_approved is '

例外申请通过时间';

-- Create/Recreate primary, unique and foreign key constraints

create unique index UK_archive_exception_info on dbmgr.archive_exception_info (SCHEMA, TABLE_NAME);

alter table dbmgr.archive_exception_info

add constraint PK_archive_exception_info primary key (SCHEMA, TABLE_NAME)

using index UK_archive_exception_info;

3.2.3 已实施归档的数据库中还未纳入归档的表的处理

数据库进行首次归档可能只是对部分表进行了归档处理，若有新的表需要纳入归档,可参照首次实施归档的办法，分批将其进行归档。

3.2.4 归档目标表需要进行分区

归档目标表的数据量巨大,必须进行分区处理,通常情况下,可以按照归档时间进行分区,并预建五年的分区。

3.2.5 定期检视归档情况

当数据库归档实施后，虽然定期进行归档，但由于数据库一直是动态变化的，包括不断有新创建的表进来、原来表中的数据分布发生变化等，这些都可能影响实际归档目标的达成，因此，需要定期对数据库的归档情况进行检视，跟踪分析是否满足既定的归档目标。若发现未达到目标，则需要考虑对数据库中还未归档的表进行归档，或修改已归档表的归档条件。

对于已实施归档的数据库，需要每月要有归档情况的报告。定期汇报的样例见附录