不曉得各位IT幫友先進們,在你們公司的ERP資料庫大小是多大呢(以10年的量),目前我的問題是我們公司主資料庫大小mdf檔大小是近20GB大小,壓縮完備份BAK檔近18GB,這些是從2004年導入ERP開始建的一直使用到今,不曉得這樣的使用量算多算少呢,以我個人我是想把它可以壓下到控制在5GB的量,例如:已時間點來切割2012年1月1日已前的資料切置另一個獨立資料庫要查詢舊有資料就換到另一個公司別或清掉在2010年12月31日前所有的資料(已有備份一份完整的以防萬一事後要用),請問如果此方式是可以這樣做的那麼會不會遇到ERP會有什麼狀況呢EX:數量.金額.會計相關等等,那我該如何去執行是下SQL指令方式還是進去ERP系統裡做。
Ｐ.Ｓ目前會想這樣的做法是因為想讓主DB在做備份能較快速那麼我就可以在工作時間內備份好幾份DB一有任何狀況可以還原當日的備份甚至一小時前的資料,USER在跑報表或大量批次主機才不會呈現掛掉狀況,觀察一堆USER報表一跑都要花20分以上才跑完結果出來確有一千多頁資料,不知道是否有人有同感,在此懇求有相關經驗的人指教一下,先謝謝邦友們了
已邀請的邦友 {{ invite_list.length }}/5
你講的很像是交易檔的概念
如果我有一個客戶的基本資料是5年前建立的,但是5年後才跟他交易,
那這個客戶的基本檔對你來說,是算5年前還是5年後?
所以你會面臨到,這些基本檔/交易資料/財會資料,如何切割日期
會計日期? 建立日期 ? 交易日期 ? 最後更新日?
另外備份的機制已經很成熟了,我對硬體不了解,但是我知道很多都有做到即時備原
可以針對異動的資料去做備份,速度也很快,不過這方面我不懂...就等其它的邦友
回答了.
另外分享一個工作經驗,以前我們公司執行MRP 大概要8個小時,公司使用ERP已經
20年了,後來有一次剛好搭上升級計畫,把硬體等級全面提升,沒有異動任何資料.
再執行MRP 只花了20分鐘.中間或許有很多效能調整的部分,可是我們是沒異動
到任何資料的.
如果你不確定什麼資料能搬 什麼資料不能搬
資料庫切割請找原廠做
ERP加速
資料庫切割並不是唯一的方法
查詢語法的最佳化
DB index的最佳化
硬體的最佳化
MSSQL的最佳化
都是可以考慮的方向
此問題曾經詢問過鼎新,但給的回複是說無法這樣做,且沒任何一家公司切資料庫,但是當時有想過說資料庫總不能讓它無限呈長吧??例如總有一天資料庫量達到了100G(單一公司別)這樣掛載在Windows系統下真的不會有其他狀況發生嗎,用想的就感覺有點驚驚,當資料庫有問題要還原需要還原多久
ham783提到：
資料庫有問題要還原需要還原多久
那要看你的備援系統怎麼設計的，我家使用VM，VM 每天做備份，要還原只要把檔案考到新機器掛起來就好，100GB 算少的，大多數的企業都是這個量，很多中大型都是TB 以上在計算的
當你資料是 100GB 你要考量你的硬碟速度再找 100GB 的資料需要多快才能滿足
通常至少要超過 500MB/S 才有可能在200秒讀完所有的紀錄，200秒大約三分鐘，大概是每個人的等待極限了但如果你用普通硬碟需要至少 22.5分鐘才能讀完所有紀錄，萬一你的查詢還有JOIN會更久，所以先進的資料中心全部都是使用SSD當作儲存設備，目前最新的3D TLC 企業用可以從6000IOPS 提升到 90000IOPS甚至 更高的速度，建議你如果真的慢換硬體最實際
小弟今年三月才剛換，進了6個 256GB SSD 花了一萬八而已還含稅價喔
現在更便宜了，六個頂多一萬五，你們只有 20GB 只需要兩顆 128GB就能搞定不到三千
建議立馬換掉才是正確的
基本上就算是技術可行
實務上執行可能也會有很多問題
以我們公司來講,就常會有查詢歷史資料的機會
假設像你講的切在2012年好了
主管需要查2010~2015年某產品的銷售資料
你要使用者先在A公司查2012~2015的資料
然後再去B公司查2010~2011的資料
再轉成EXCEL後做整裡與合併的動作
使用者保證會想把你K到滿頭包
另一種情形則是使用者忘了要分開查詢
只在A公司下2010~2015年的資料
就會得到錯誤得資訊
更不用說清掉某個年度之前資料的傻事了
任何一筆資料的時間點切錯
就可能導至整個ERP都會出現異常
smonkeyy提到：
本上就算是技術可行
實務上執行可能也會有很多問題
以我們公司來講,就常會有查詢歷史資料的機會
假設像你講的切在2012年好了
主管需要查2010~2015年某產品的銷售資料
你要使用者先在A公司查2012~2015的資料
然後再去B公司查2010~2011的資料
再轉成EXCEL...(恕刪)
感謝smonkeyy大的寶貴意見及案例,之前我也有想過如果切了感覺應該會對ERP資料影響到,想上來與各位確認一下是否與原本我的想法是一樣,清掉資料是一位原本在公司裡導入的資深採購前輩(去年己退休)當時她是說感覺查詢所有資料時候會很卡卡的,她想說清除各各單據會不會改善此問題,因為我們公司極少會查詢到3年以前的資料所以才會想到用此方式,感謝smonkeyy大的意見交流
我們有切
如果程式有需要查全部的資料
該程式可以改寫
做跨資料庫查詢
我公司是用 WORKFLOW GP ，你的狀況我大概能了解
簡單說，你遇到的是硬體效能問題
我們一開始用的是一般硬碟，第三年我們換 SSD
簡單說就是為了解決資料存取速度不夠的問題
我們從原本速度只有 75MB/S 提升到 750MB/S
速度加了 10倍，很多的報表本來都要等很久，現在只需要一點點的時間
備份的時間更是大幅縮短，本來需要一小時，現在只要 10分鐘
所以建議你，換硬體吧，鼎新換硬體重新申請授權檔是免費服務
而且都是當天就能結案，SSD 現在很便宜
256GB一個3000有找，買4個作 RAID 10，更安全
既然要換硬碟，順便做虛擬化，虛擬化之後，管理更方便
我們公司一開始就是走虛擬化的，換硬碟對我們來說都是小事
檔案複製轉換很快的，除非授權主機的硬碟有換過，否則不需要重新授權的
以上希望可以幫助到你
20G的DB並不算多,以你的敘述我認為千萬不要想切割DB,出問題你無法處理的.
DB的備份用差異備份就可達成,批次報表跑出來數量過多則應該從使用者操作方式變更,
我猜測你的問題是主機在跑派班中心造成系統緩慢或是太多批次或報表在排隊使用者不耐.
常跑一千多頁報表卻又不是真的要使用到,那就是下的批次條件有問題,
如果常有User要跑大量報表或像月結須執行大量批次作業,就增加派班中心.
20G DB其實不算很多~
硬體方面不知是否有測試過?
主機規格要不列出看看
首先會需要健檢一下啦
看是硬體還是軟體問題
如果確認是跟DB有關
做資料庫的切割說真的不是太難啦 要考慮周全和步驟比較多而已！
20G DB不算很多,不用切割,換硬體和index 欄位即可,我們 [黑又苦] 資料庫有500G,還是一樣跑的很正常。
ERP的資料是有”延續性” & “關聯性”
比如: 傳票最少要保留5年以上
但傳票是從前方進銷存單據拋過來的!
所以前方單據也要保存5年
還有品號/廠商/客戶 等基本資料 要保存
這樣能夠瘦身(搬移)的資料就很少了!
速度沒增加多少!
其實資料庫很大 不會影響資料料KEY IN & 查詢
只會影響 報表 & 批次的執行
我之前幫過很多客戶做ERP加速
方法有
當然其中也做過 依時間切割資料庫方式
雖然做到
現在是大數據時代
如何處理大數據, 加速大數據處理
是越來越會遇到的問題
大家努力!
以上隨談希望幫到忙!
傳票保留 五年那是指 實體傳票，電腦紀錄 是十年
也就是說你使用電腦系統的話，十年內的帳都要能夠查得到
這是會計原則，沒什麼能閃避的
我們公司18年前有DOS 版的會計系統 用了兩年為了上市櫃改 UNIX 網路版
DOS 版的不要以為用兩年而已升級就能廢掉，很抱歉，他等了 整整十年才能把電腦關機停用
我們公司 102年換ERP，換句話說舊系統要等到 111年結束，才能除役，還好我八年前轉VM
我只要硬碟不死，整個VMDK 月備分不停地做，備份做十年再砍掉就好
硬碟死了，把備份檔案還原就能繼續查帳，這個是會計制度的規範
當然你說的方法是目前有會計制度的公司會用的，
三年切一次，這很正常的，對系統也比較好
然後現在有 SSD ，必要的時候轉換到 SSD 就能加速，我們公司去年就換SSD 了減少抱怨
mssql 要壓縮整理是要費時也要利用下班時間來處理
重新建立新的資料庫 用mb方式來建立,建立好之後兩台利用
匯入方式重新匯入到新的資料庫 這樣的方式是重新整理資料避免中間有空隙
整理好之後你會發現原來才這麼一點點,做的時候小心點
iThome鐵人賽
看影片追技術