【IT168 技术】在向大家详细介绍归档数据之前，首先让大家了解下归档数据，然后全面介绍归档数据。

　　两种策略

　　归档数据与备份对于一个系统而言，是两种不同的策略，发挥着两种不同的、互补的功能。备份用于高速复制和恢复，来减少故障、人员错误或灾难的影响;归档有效地管理数据，实现数据的保留和长期的访问与检索。

　　归档需求

　　归档数据范围：主要是DB中数据和文件数据。呼叫数据(呼叫数据、服务记录、录音数据，还要考虑邮件、传真、IVR留言文件及业务附件)、业务数据(业务记录、业务单据等)，客户资料不归档 ;

　　归档方式：自动归档还是手工操作归档?

　　数据寿命：业务数据保留多长时间进行归档?考虑数据量的大小。

　　归档后数据的访问和检索方式：

　　归档数据的清除：需要清除的归档数据，是已经没有保留价值的数据了。直接删除释放资源……

　　方法思路

　　1、将业务表与历史数据设计成不同的表来存储数据。业务表中只保留正在处理的业务数据。处理完成后即形成历史数据，自动进入历史数据表。

　　分析：此思路是将系统正在处理的数据与需要查询的历史数据在设计上就分开。可以保证系统运行的性能。但目前C6方案在设计时没有进行如此考虑。

　　2、沿用前述思路，仍分业务表和历史数据表，但不是每笔交易完成后都自动形成历史数据，而是在业务表中保留一段时间后(视数据量和实际需求)，系统定时进行归档或人工在界面操作进行归档，将业务数据转移至历史数据表。

　　分析：正在处理的数据和短期内用户关注的数据保留在业务表中，定期归档历史数据。

　　以上两种思路都需要考虑程序来实现归档操作，并提供归档数据查询界面。这并不难实现。文件的归档如何处理?

　　3、直接开两套系统(完全一致)，两套数据库实例。一套为业务系统，另一套为归档系统。定期将前一套数据直接转移至后一套。需要查看归档数据时，直接访问归档系统。

　　分析：倒是挺简单。可是觉得不够友好。譬如，有一些公用数据是不需要归档的，如客户数据、代码参数类数据表等公用资源。但两套系统中肯定都要有。

　　确定设计

　　1、 业务表需要有对应历史表;

　　2、 归档提供界面操作，由操作用户决定按时间归档或者按数据分类归档。

　　3、 归档后的数据提供导出或者清除功能。

　　4、 文件数据不提供归档，如：传真、邮件、留言等文件。但提供清除功能。在归档后，文件仍保留，但归档数据清除时，需清除文件。

　　5、 业务表与历史标分开后，暂不考虑业务操作中对历史数据的查询。意味着对业务数据和历史数据的操作也是分开的。单独提供历史数据的查询界面。

　　6、 不提供归档的逆向操作。

　　7、 备份：采用操作系统定时调度(CRON或计划任务)+export的备份策略。由DBA出具具体方案。