在實際業(yè)務(wù)中，累計5年的歷史業(yè)務(wù)數(shù)據(jù)可能比較大，比如可能超過1T的數(shù)據(jù)，這時可能就會影響業(yè)務(wù)處理
OLTP的運行效率，一般是將5年以上的數(shù)據(jù)歸檔的其他地方，同時從當(dāng)前業(yè)務(wù)系統(tǒng)中刪除。

有各位哥們對這個過程比較熟悉，ORACLE ERP時什么策略呢？ 請高手指點。
DBX archiver的功能就是把歷史數(shù)據(jù)放在另一個數(shù)據(jù)庫中，如果在prod中的查詢涉及到歷史數(shù)據(jù)，就會到歷史庫中取數(shù)據(jù)，實現(xiàn)對客戶的透明化，而數(shù)據(jù)是在兩個獨立的數(shù)據(jù)庫中存放

類似的ORACLE數(shù)據(jù)歸檔的方案應(yīng)該有不少，但說實話沒有一家特別優(yōu)秀的，因為ORACLE EBS涉及到的業(yè)務(wù)表太多，數(shù)據(jù)之間千絲萬縷，不是簡單的把某些schema的表里的數(shù)據(jù)移走了事

archive的原理說起來簡單，具體實現(xiàn)起來哪些數(shù)據(jù)走，哪些數(shù)據(jù)留，那些是事務(wù)，哪些不算，沒幾個人會深入下去搞懂它們。oracle本身提供了archive的接口，也實現(xiàn)了全部的業(yè)務(wù)邏輯，但它自己也知道這塊做的很爛，所以它從來不愿意公開，更沒有全面的推廣，只是告訴用戶有這么一個接口存在而已。想自己利用ORACLE的接口，幾乎就是一個字：死。。。。

所以才有了大大小小第三方公司的各種解決方案，Outerbay應(yīng)該算其中不錯的一家吧

我曾經(jīng)為某家大公司，專門負(fù)責(zé)做個data archive的歸檔項目，研究它的archive規(guī)則，天天和一群印度人做這個，頭都太大了。我從進那個項目開始做這個，一直到我走，還沒有結(jié)束UAT狀態(tài)，沒辦法，數(shù)據(jù)實在太重要了，有這個需求的肯定都是大公司，數(shù)據(jù)就是它的命，要它把自己的命都移走，不謹(jǐn)慎那是不可能。。。。

outerbay對EBS的方案也和EMC的類似，把要歸檔的那些歷史數(shù)據(jù)，整體移到另一個數(shù)據(jù)庫里去，原數(shù)據(jù)庫里數(shù)據(jù)少了，查詢起來當(dāng)然快

以AP為例，
分別建2類職責(zé)：
1個是普通AP查詢，專門查近期的數(shù)據(jù)，比如2000年以后的數(shù)據(jù)，速度很快
1個是所有AP查詢，數(shù)據(jù)來自一個union的view,速度肯定快不了，這種需求不如1多

發(fā)票歸檔不？沒付款的發(fā)票歸檔不？N年前的發(fā)票N年后付款歸檔不？AR的，GL的，PO的，OM的，CE的，，，，，頭都大了，最后我把文檔，資料，test case,test document，統(tǒng)統(tǒng)歸檔后，bye-bye了。。。不是人做的事情，誰做誰要吐。。。。。。。。。
SAP用戶R/3文檔歸檔解決方案

業(yè)務(wù)問題描述：對于使用SAP系統(tǒng)的客戶來說，歸檔SAP系統(tǒng)的數(shù)據(jù)和對象已經(jīng)變得越來越重要。 SAP用戶通常是在系統(tǒng)越來越不行的時候才想到歸檔數(shù)據(jù)和對象的需要，SAP系統(tǒng)通常會變得越來越慢和用戶響應(yīng)時間越來越長，SAP用戶也需要能快速訪問SAP相關(guān)的文檔。
客戶需求表現(xiàn)：
- 你現(xiàn)在的SAP系統(tǒng)的數(shù)據(jù)庫有多大?
- 每個月數(shù)據(jù)庫的增長有多快?
- 你有發(fā)現(xiàn)用戶響應(yīng)時間或SAP系統(tǒng)的性能有下降嗎?
- 你希望能通過SAP圖形界面來歸檔和查看打印列表、發(fā)票、憑證、圖像等嗎?
- 你的用戶是否希望將一些非SAP的對象，例如Word文檔、Excel表格，電子 郵
- 件或視頻片斷和SAP的交易進行關(guān)聯(lián)，并且能通過SAP系統(tǒng)來進行查看?

解決方案描述： IBM的 Content Manager CommonStore 解決方案已經(jīng)通過了SAP的Archivelink接口的認(rèn)證。CommonStore能運行在UNIX, AIX, NT 和 AS/400 平臺上，同時也提供了方法來歸檔不活動的數(shù)據(jù)庫數(shù)據(jù)，打印列表，發(fā)票，影像和另外的和SAP交易相關(guān)的文檔。SAP用戶能直接通過SAP的圖形界面來訪問 這些文檔，并且能查詢活動和不活動的數(shù)據(jù)庫數(shù)據(jù)。客戶也能增加另外的IBM Content Manager 應(yīng)用，例如如果他們需要歸檔SAP系統(tǒng)以外的內(nèi)容，可以使用CM或CM Ondemand。
- 帶來的好處：
1.開始對SAP系統(tǒng)進行歸檔，減輕SAP生產(chǎn)系統(tǒng)的壓力。
2.通過SAP圖形界面歸檔和提取相關(guān)的文檔。
3.用戶能以瀏覽器的方式訪問SAP系統(tǒng)信息。
- 典型應(yīng)用：
1.使用SAP R3系統(tǒng)的用戶。
- 典型用戶：
1.海爾電器
2.長虹電器
案例介紹
CommonStore for SAP R/3在四川長虹的實施案例
系統(tǒng)需求及應(yīng)用背景
四川長虹電子集團公司是我國大型國有獨資公司，始建于1958年，目前擁有多個事業(yè)部，包括南通長虹、吉林長虹等多家控股、參股公司，現(xiàn)有員工3萬多人， 同時，也擁有覆蓋全國各地的一萬多個營銷服務(wù)網(wǎng)點，具有強大的營銷實力，產(chǎn)品暢銷美洲、澳洲、東南亞、中亞等國家和地區(qū)，在海外享有盛譽，為中國家電行業(yè) 第一品牌。
長虹公司的SAP R/3系統(tǒng)為4.5b中文版、從2000年9月開始上線，數(shù)據(jù)庫DB2 V5.2.使用了MM、SD、FI、SM四個模塊。從系統(tǒng)投入運行以來，在線數(shù)據(jù)庫急劇膨脹，系統(tǒng)數(shù)據(jù)庫是以每周4G的速度增長，數(shù)據(jù)庫2001年5月容 量已經(jīng)達到110GB,磁盤系統(tǒng)僅有22GB空余空間可以使用。磁盤空間不足的問題非常明顯，嚴(yán)重影響了數(shù)據(jù)庫的性能，并增加了R/3用戶的等待時間，降 低了R/3系統(tǒng)的效率。同時增加了系統(tǒng)管理的復(fù)雜程度，備份時間的大大增加。另外購買高端磁盤系統(tǒng)的需求遞增。
解決方案
長虹公司對于上述問題所采取的解決方案為：
- IBM CommonStore for SAP R/3 +TSM+3575磁帶庫
- 使用IBM CommonStore for SAP R/3 通過TSM將R/3數(shù)據(jù)庫中的數(shù)據(jù)歸檔到3575磁帶庫中的磁帶。
這個方案充分利用已有的軟件和硬件資源：
- 軟件： Tivoli Storage Management。
- 硬件： 3575 磁帶庫、RS/6000 S7a服務(wù)器。
- 新增軟件： IBM CommonStore for SAP
實施后的效果
系統(tǒng)實施后的歸檔數(shù)據(jù)范圍從2001年7月到2001年12月，業(yè)務(wù)數(shù)據(jù)量達35G，歸檔后騰出數(shù)據(jù)28.7G。總結(jié)來說有以下幾點：
- 系統(tǒng)實施完成后，數(shù)據(jù)庫的大小明顯減少了，高速的數(shù)據(jù)增長得到有效控制，SAP R/3系統(tǒng)的運行效率提高了。
- 已經(jīng)購買的備份系統(tǒng)與新系統(tǒng)無縫集成，數(shù)據(jù)備份與歸檔更趨完善。
- 已有硬件和軟件投資得到保護。

http://www-01.ibm.com/software/cn/data/solution/db2_content_solution02.html

總結(jié)

以上是生活随笔為你收集整理的历史数据归档(转)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。