历史数据归档java 历史数据归档设计

转载

AI大梦想家 2023-09-17 00:51:53

文章标签 历史数据归档java 数据库运维 SAP 数据 文章分类 Java 后端开发

在实际业务中，累计5年的历史业务数据可能比较大，比如可能超过1T的数据，这时可能就会影响业务处理
OLTP的运行效率，一般是将5年以上的数据归档的其他地方，同时从当前业务系统中删除。

有各位哥们对这个过程比较熟悉，ORACLE ERP时什么策略呢？请高手指点。
DBX archiver的功能就是把历史数据放在另一个数据库中，如果在prod中的查询涉及到历史数据，就会到历史库中取数据，实现对客户的透明化，而数据是在两个独立的数据库中存放

类似的ORACLE数据归档的方案应该有不少，但说实话没有一家特别优秀的，因为ORACLE EBS涉及到的业务表太多，数据之间千丝万缕，不是简单的把某些schema的表里的数据移走了事

archive的原理说起来简单，具体实现起来哪些数据走，哪些数据留，那些是事务，哪些不算，没几个人会深入下去搞懂它们。oracle本身提供了archive的接口，也实现了全部的业务逻辑，但它自己也知道这块做的很烂，所以它从来不愿意公开，更没有全面的推广，只是告诉用户有这么一个接口存在而已。想自己利用ORACLE的接口，几乎就是一个字：死。。。。

所以才有了大大小小第三方公司的各种解决方案，Outerbay应该算其中不错的一家吧

我曾经为某家大公司，专门负责做个data archive的归档项目，研究它的archive规则，天天和一群印度人做这个，头都太大了。我从进那个项目开始做这个，一直到我走，还没有结束UAT状态，没办法，数据实在太重要了，有这个需求的肯定都是大公司，数据就是它的命，要它把自己的命都移走，不谨慎那是不可能。。。。

outerbay对EBS的方案也和EMC的类似，把要归档的那些历史数据，整体移到另一个数据库里去，原数据库里数据少了，查询起来当然快

以AP为例，
分别建2类职责：
1个是普通AP查询，专门查近期的数据，比如2000年以后的数据，速度很快
1个是所有AP查询，数据来自一个union的view,速度肯定快不了，这种需求不如1多

发票归档不？没付款的发票归档不？N年前的发票N年后付款归档不？AR的，GL的，PO的，OM的，CE的，，，，，头都大了，最后我把文档，资料，test case,test document，统统归档后，bye-bye了。。。不是人做的事情，谁做谁要吐。。。。。。。。。
SAP用户R/3文档归档解决方案

业务问题描述：对于使用SAP系统的客户来说，归档SAP系统的数据和对象已经变得越来越重要。 SAP用户通常是在系统越来越不行的时候才想到归档数据和对象的需要，SAP系统通常会变得越来越慢和用户响应时间越来越长，SAP用户也需要能快速访问SAP相关的文档。
客户需求表现：
- 你现在的SAP系统的数据库有多大?
- 每个月数据库的增长有多快?
- 你有发现用户响应时间或SAP系统的性能有下降吗?
- 你希望能通过SAP图形界面来归档和查看打印列表、发票、凭证、图像等吗?
- 你的用户是否希望将一些非SAP的对象，例如Word文档、Excel表格，电子邮
- 件或视频片断和SAP的交易进行关联，并且能通过SAP系统来进行查看?

解决方案描述： IBM的 Content Manager CommonStore 解决方案已经通过了SAP的Archivelink接口的认证。CommonStore能运行在UNIX, AIX, NT 和 AS/400 平台上，同时也提供了方法来归档不活动的数据库数据，打印列表，发票，影像和另外的和SAP交易相关的文档。SAP用户能直接通过SAP的图形界面来访问这些文档，并且能查询活动和不活动的数据库数据。客户也能增加另外的IBM Content Manager 应用，例如如果他们需要归档SAP系统以外的内容，可以使用CM或CM Ondemand。
- 带来的好处：
1.开始对SAP系统进行归档，减轻SAP生产系统的压力。
2.通过SAP图形界面归档和提取相关的文档。
3.用户能以浏览器的方式访问SAP系统信息。
- 典型应用：
1.使用SAP R3系统的用户。
- 典型用户：
1.海尔电器
2.长虹电器
案例介绍
CommonStore for SAP R/3在四川长虹的实施案例
系统需求及应用背景
四川长虹电子集团公司是我国大型国有独资公司，始建于1958年，目前拥有多个事业部，包括南通长虹、吉林长虹等多家控股、参股公司，现有员工3万多人，同时，也拥有覆盖全国各地的一万多个营销服务网点，具有强大的营销实力，产品畅销美洲、澳洲、东南亚、中亚等国家和地区，在海外享有盛誉，为中国家电行业第一品牌。
长虹公司的SAP R/3系统为4.5b中文版、从2000年9月开始上线，数据库DB2 V5.2.使用了MM、SD、FI、SM四个模块。从系统投入运行以来，在线数据库急剧膨胀，系统数据库是以每周4G的速度增长，数据库2001年5月容量已经达到110GB,磁盘系统仅有22GB空余空间可以使用。磁盘空间不足的问题非常明显，严重影响了数据库的性能，并增加了R/3用户的等待时间，降低了R/3系统的效率。同时增加了系统管理的复杂程度，备份时间的大大增加。另外购买高端磁盘系统的需求递增。
解决方案
长虹公司对于上述问题所采取的解决方案为：
- IBM CommonStore for SAP R/3 +TSM+3575磁带库
- 使用IBM CommonStore for SAP R/3 通过TSM将R/3数据库中的数据归档到3575磁带库中的磁带。
这个方案充分利用已有的软件和硬件资源：
- 软件： Tivoli Storage Management。
- 硬件： 3575 磁带库、RS/6000 S7a服务器。
- 新增软件： IBM CommonStore for SAP
实施后的效果
系统实施后的归档数据范围从2001年7月到2001年12月，业务数据量达35G，归档后腾出数据28.7G。总结来说有以下几点：
- 系统实施完成后，数据库的大小明显减少了，高速的数据增长得到有效控制，SAP R/3系统的运行效率提高了。
- 已经购买的备份系统与新系统无缝集成，数据备份与归档更趋完善。
- 已有硬件和软件投资得到保护。