[請益] 鼎新SQL Server重置後執行速度緩慢?

看板MIS作者 (無限解、解無限)時間10年前 (2014/06/16 11:44), 7年前編輯推噓10(10推 0噓 36→)
留言46則, 11人參與, 最新討論串1/1
先跟各位大大們問好 事情是這樣的，前陣子公司鼎新SQL Server被hacker入侵 萬幸的是，只把program files資料夾的東西都刪掉 除了erp停用了一陣子外，損失還不算嚴重 後來請鼎新報價，整個重置要價好幾萬(我們沒簽約了就是) 後來我就自已試著重灌了，灌完後，因為啟動時一直出現序號錯誤 所以只好請鼎新重新申請序號(明明沒更換主雞說)，要價好幾千(上述1/10) 結果，遠端連線進來，只是將其中一個序號檔copy到system32就好了=.= 前前後後也沒重新申請序號，也處理了五分鐘，好吧，這只能說是他們的know how!? 後來，雞本上ERP跟EFlow是都可以正常使用，但整個執行速度就變很慢 去年底，我們曾經將他們家的HRM Server移到中國去，這段也是我自已移的 但有重新申請序號(有換主雞)，剛開始也是速度超慢，每個table第一次查詢都超慢 例如查員工雞本資料，第一次查大概要30sec左右，第二次大概1~2sec就好了 後來對方的客服有協助我做處理，只看到他對SQL做了一些處理 但因為我也是遠端切進server觀看，再加上當時手頭上有事在忙而且對SQL指令不是很熟 雞本上沒看到什麼就結束了，我在想，這次是不是也是類似的問題?(感覺是索引的問題?) 但是這次這個客服不太鳥我，說不是同件事他沒辦法處理(經驗是鼎新男客服比較好溝通) 拜了估狗大神，是有找到一篇鼎新釋出的工具，將資料庫欄位類型nchar改成nvarchar 雖然看了一下當初鼎新給我的安裝程式裡就有這隻工具 但檢查了db卻發現我家的欄位類型都還是nchar 也就是其實那時就有這工具了，只是當初安裝人員不知道在幹嘛沒做這個動作=.= 我預計這幾天會試試，不過不確定是不是這個問題，想請問各位前輩有遇到類似的問題嗎 另外，也歡迎各個有在用鼎新的前輩們一起來交流交流囉!! 文很長，先謝謝各位前輩耐心看完，感激不儘!! -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.133.61.86 ※ 文章網址: http://www.ptt.cc/bbs/MIS/M.1402890291.A.C5E.html
→
06/16 11:46, , 1F
忘了說，EFlow看起來是有用nvachar的，只是速度一樣慢
06/16 11:46, 1F
推
06/16 13:09, , 2F
Problem files XDDD
06/16 13:09, 2F
→
06/16 13:10, , 3F
應該是index問ㄅ
06/16 13:10, 3F
→
06/16 13:10, , 4F
問題
06/16 13:10, 4F
→
06/16 13:45, , 5F
呃，我在打啥毛XDD
06/16 13:45, 5F
推
06/16 13:45, , 6F
留一點錢給別人賺嘛~~自己那麼辛苦幹嘛
06/16 13:45, 6F
※ 編輯: esla (220.133.61.86), 06/16/2014 13:45:59
→
06/16 13:46, , 7F
就，想說看能不能自已搞定，畢竟搞定能省下好幾萬
06/16 13:46, 7F
→
06/16 13:47, , 8F
然後事實上我自已的想法是能自已搞定也算是多學會一招啦
06/16 13:47, 8F
→
06/16 13:48, , 9F
我家老闆也頗摳的就是，他甚至會有那種，反正員工沒忙到沒
06/16 13:48, 9F
→
06/16 13:49, , 10F
時間等系統多反應個幾秒，所以這樣他也能接受就是
06/16 13:49, 10F
→
06/16 13:49, , 11F
然後是我自已龜毛想弄好他啦，因為我個人覺得速度差頗多
06/16 13:49, 11F
→
06/16 13:54, , 12F
我也是覺得是index問題，我是直接匯入原資料庫的
06/16 13:54, 12F
→
06/16 13:54, , 13F
需要再做什麼處理動作嗎?(我對SQL其實不是很熟><)
06/16 13:54, 13F
→
06/16 15:02, , 14F
先謝謝g大，我剛試著估狗後重組index，發現速度有稍稍快了點
06/16 15:02, 14F
→
06/16 15:03, , 15F
所以看來應該是index的問題比較大，我再朝這個方面查查，謝謝
06/16 15:03, 15F
→
06/16 16:38, , 16F
沒有簽維護合約嗎？
06/16 16:38, 16F
→
06/16 18:18, , 17F
沒簽耶，之前簽一年3x萬，結果一整年下來只有打了十來通電話
06/16 18:18, 17F
→
06/16 18:18, , 18F
過去客服詢問問題，老闆覺得case by case比較划算
06/16 18:18, 18F
→
06/16 18:18, , 19F
事實上也是啦
06/16 18:18, 19F
→
06/17 15:09, , 20F
複數年合約可以多砍一點。看業務夠不夠力..
06/17 15:09, 20F
→
06/17 15:15, , 21F
其實他們現在有新合約了，沒版更的，只有簡單的電話客服
06/17 15:15, 21F
→
06/17 15:16, , 22F
e-learning、e-service跟大班課，價格會壓到十萬內
06/17 15:16, 22F
→
06/17 15:16, , 23F
我是覺得還可以了啦，至少很難說服出錢的人啊，唉
06/17 15:16, 23F
推
06/17 15:29, , 24F
請問你們導入時大約金額是多少 簽一年要3X萬?
06/17 15:29, 24F
→
06/17 15:38, , 25F
我記得含硬體是近三百萬，軟體的部份我忘了
06/17 15:38, 25F
→
06/17 15:39, , 26F
維護價我記得是訂價的15%好像
06/17 15:39, 26F
推
06/17 15:53, , 27F
鼎新的錢真的比我們好賺很多T_T
06/17 15:53, 27F
→
06/17 16:22, , 28F
好賺很多啊，不過聽說他們顧問薪水還好就是
06/17 16:22, 28F
→
06/17 16:22, , 29F
顧問出來一小時是ntd 3K，但他們領月薪的
06/17 16:22, 29F
推
06/17 17:18, , 30F
其實鼎新的客服還算滿不錯的，都會把問題處理到好…
06/17 17:18, 30F
鼎新在erp這段的客服還算ok啦，不過有些系統邏輯上的問題他們就無法處理 (像LRP算料的邏輯就很莫名其妙，算出來的需求都有問題，或是我5/15時才進貨 在5/15當天打5/12的出貨單他可以成立，然後5/12就變負庫存=.=) 這部份雞本上就是得靠版更才能解決，但版更這件事有時是有風險的 ERP我是不知道，但我們有買他們家的HRM，每次版更就出新問題 可能我們是他們一出我們就購買，所以當白老鼠吧，一開始bug超多 前前後後搞了超過一年，而且問題雞本上都是他們家的bug 什麼樣的bug呢，像是匯入打卡時間，欄位格式沒鎖定為時間格式 要不然匯入資料全型半型沒控管(中國人超愛用全型的=.=) 格式沒控管，長度沒控管，什麼鬼東西都沒控管，匯入時也沒做檢查動作 一開始常常匯完資料做考勤運算時才發現錯誤，系統也不跳提示 錯在什麼地方也不知道，然後一卡死可能整個table 都出問題 派來的顧問一問三不知，連怎麼檢查SQL都不會，雞本上bug都我自已抓出來的 不然就是前一個版本用餐段加班用實際加班可匯入，後一個版本就不行 反正諸如此類的bug一堆，邏輯也一變再變 然後每次版更修好一個bug，另一個bug就跟著來 跟他們要版更內容也從來沒給過，搞到我們第二年的MA不敢跟我們收費=.= 所以事實上我們對鼎新也是頗沒信心的就是，不太敢亂版更 (雖然我老闆有念過說為啥我們簽MA的那幾年鼎新也不通知我們做版更) 至於不簽MA這件事，主要是我們之前統計過，第一年我還會去上上大班課 剛準備導入也滿多問題打去客服問，但到了第二年，大班課沒上過了 ELearning雞本上也沒在用(第一年強執員工上，但我看也都是掛著而已) 電話客服一整年扣掉HRM的部份，大概也就十幾二十通，而且都是問操作方法而已 算一算等於一通電話要一萬多塊，所以後來才會選擇停掉MA 當然，我們公司內部也有問題啦，ERP到現在根本也只算導了進銷存部份 成本端本來就打算最後導，財務端，因為之前奇怪的財務長莫名其妙的堅持 所以工廠他打死不肯從應付應收拋傳票，一定要先手key 後來他離職了，底下的人也不願做，上頭的因為工廠在轉型也沒強執要求 (中國財務總認為國稅帳，也就是外帳才重要，內帳對他們來說沒意義=.=) 所以工廠整個財務端中斷了一年沒在動，都是給外帳讓台灣這裡來手動併表=.= 前陣子終於說服上頭的要求他們要把財務端導入，結果我這個月被借調出去玩SAP 是希望我這裡搞完回去能成功導入啦(財務端應該是不難，應付應收都有在跑了) 至於成本端，就再看著辦吧(遠目~) 反正他們現在有新的合約模式，不用追溯之前的MA 所以或許到了要玩成本時再來簽MA吧，沒辦法，上頭的很會算啊 ※ 編輯: esla (220.133.61.86), 06/17/2014 18:28:56
→
06/17 22:01, , 31F
只導了進銷存的話 其實也差不多算失敗了=.=
06/17 22:01, 31F
→
06/17 22:01, , 32F
會計不想從應收應付拋這不奇怪啦 因為維護會有困擾
06/17 22:01, 32F
→
06/17 22:02, , 33F
我公司會計也都想直接手開傳票啊 我們也都是強制執行
06/17 22:02, 33F
沒辦法啊，事實上我們公司員工超被動，中國人又超難管 一開始導入第一個月，請顧問來協助，每次會議結束完 要求各單位回去順流程完全沒人鳥，第二次會議來一問三不知 這樣白花了一個月的顧問時數費，完全沒任何進展 後來讓他們看了一個月的E-Learning還有人連新建修改在那都不知道 最後沒辦法了，雞乎是我自已一個人把所有流程模組全摸熟 然後編碼原則雞本資料都我一個人決定出來讓他們去輸進去 再一個單位一個單位的去教，這才至少進銷存有正常跑完 沒辦法，當初還有另一套舊系統(益維)在跑，上頭的強制性也不強 所以他們也有恃無恐，就慢慢拖拖拖，後來我火大直接把舊系統強制關掉 才認真的開始用鼎新，不過卡在那個天才財務長，才會卡關，不然財務應該也跑完了 我當然知道直接拋維護會有難度，但就是這樣才能抓到問題啊 前端有問題後端會發現，整段資料是串起來的，而不是你高興怎麼開傳票 或怎麼出應收付就怎麼出啊，這不就是erp的用意所在嗎 啊沒辦法，那財務長一天到晚嗆我老闆不出報表啥洨的 然後強勢的不得了，訂了一堆規矩，感覺似乎很有想法很有作為 我老闆剛開始頗相信他的，所以也就隨他了，他說先手key傳票一陣子 等我前端順了再來自動拋傳票，結果我前端順了，他也就滾了，唉.. 不過事實上其實很多雞礎資料都有在建，就看要不要跑而已 前陣子公司算是在轉型，內部也有些異動，是希望接下來能順利往下導就是 ※ 編輯: esla (1.34.78.69), 06/17/2014 22:42:15 ※ 編輯: esla (1.34.78.69), 06/17/2014 22:55:14
→
06/18 08:13, , 34F
流程把關是用意之一沒錯啊 所以你們導失敗了=.=+
06/18 08:13, 34F
→
06/18 08:13, , 35F
不願意配合新流程制度的員工或幹部隨便抓都馬有~
06/18 08:13, 35F
→
06/18 08:14, , 36F
公司導的立場不強硬的話 基本上 下場都不太好
06/18 08:14, 36F
→
06/18 08:15, , 37F
我們一開始推點工時完整記錄製令時間 也是很排斥啊
06/18 08:15, 37F
→
06/18 08:15, , 38F
我也只能說 我知道大家不想點 但現在公司是叫你們配合
06/18 08:15, 38F
→
06/18 08:15, , 39F
不是在問你們意見 謝謝合作
06/18 08:15, 39F
推d大的說法啊，所以其它單位我態度強硬，他們只能配合，所以原則上順利的完成了 但財務長我管不動啊，上頭的那時又太過放任她，所以囉~~ 希望接下來能順利完成了，不過感覺現在在玩另一間公司的SAP又是兇多吉少，唉 ※ 編輯: esla (118.99.191.211), 06/18/2014 09:58:53
推
06/18 16:32, , 40F
這篇的經驗很不錯，我接的案子都會盡量讓上位者參與
06/18 16:32, 40F
推
06/18 22:12, , 41F
我寧願去維護自製的也不想碰這種只能打電話的...
06/18 22:12, 41F
推
06/18 22:15, , 42F
導這種東西上面不主導只推給資訊導的起來才有鬼...
06/18 22:15, 42F
→
06/19 08:32, , 43F
在研究系統導入的過程中發現 最高決策者的支持很重要 尤其是台
06/19 08:32, 43F
→
06/19 08:32, , 44F
灣這種奴性強的社會 MIS努力的要死也比不上上頭一句話的~
06/19 08:32, 44F
推
06/19 18:08, , 45F
應該說MIS要努力的說服老闆去講那"一句話" 不要努力錯方向
06/19 18:08, 45F
推
06/21 12:31, , 46F
他們家的HRM，每次版更就出新問題 (笑) XDXD
06/21 12:31, 46F
補充一下後續 後來我在2016年5月左右離職改玩tiptop 舊公司的workflow在2015年約12月份左右就開始導入成本這塊流程 啊由於workflow就像我之前講的，其實前端資料一直都是ready好的 其實導入成本的速度非常快，大概在2月還3月就導入成功 中間花了2個月在修正成本(成本其實是對的，但換經營團隊，某些成本想重認) 所以其實還是老話，導入erp，問題都是在人啊(茶~ ※ 編輯: esla (118.163.139.100), 02/08/2017 09:20:03
‣ 更多 esla 的文章
文章代碼(AID): #1JdcWpnU (MIS)