請問各位大大
小弟目前只是再公司IT部門實習，碰到以下狀況
目前作業環境為IBM System x3850 M2 (記憶體擴充到24GB CPU兩顆)
使用server 03 R2 Ent版搭 Win SQL 2000
硬碟 SAS 146GB 10000RPM x4 RAID 6
資料庫目前大小 36GB 資料目前約三萬多筆，預計未來會加入的約30%，但不至於超過十萬筆
以上是網管所設置，客戶端軟體Exact Globe
狀況為資料庫的速度過慢，clinet抱怨輸入資料、開啟資料需等待很久，於local端測試後，似乎是硬碟讀取速度不足所導致
今天Exact Globe人員到場處理後，也確定是硬碟速度不足，CPU、RAM、網路都ok
建議把硬碟換置成15000Rpm，然而這台主機只支援2.5"硬碟，去serverbank問後，他說只有3.5"才有15000RPM
跟董事長報告後，他說那乾脆買台支援3.5"的硬碟來用好了，丟50萬預算給我去找主機
請問各位大大我需要重新購置主機嗎？還是只要把記憶體用上即可？
問題到底出在哪？需要更新SQL系統嗎？
明天正式的網管會裝server 03 DataCenter ，不知道有沒有用，然後RAID成4
請問大大們這樣作妥當嗎？
有沒有什麼建議？因為再使用上資料讀寫率實在太高了。
已邀請的邦友 {{ invite_list.length }}/5
我以前也是使用Windows Server 2003 + SQL 2000
理論上才三萬筆資料效能上應該不至於這麼糟糕
不過後我來全部採用64位元 Win2008(x64) + SQL 2008(x64)
效能快很多，SQL 2000 (x32)效能確實比較弱
也許全部換成 64位元 可以解決您目前的問題
因為全64位元的環境下，SQL Server就沒有以前 32 位元的限制了
記憶體可以無限制的一直吃下去
大量的索引以及資料會被暫存到記憶體中
可以減少IO的存取
另外，您可以利用SQL Profiler去偵測您的ERP系統執行哪個動作的時候
會讓資料庫伺服器的CPU飆上去，飆上去的時候，是呼叫了什麼SQL Command
這個SQL Command關連到哪些TABLE，條件式使用了哪些欄位
可以根據這些欄位去設定索引，效能上會有差(有時候加的好速度上會差很多)
如果這些必要欄位有加上索引，那麼SQL Server在查詢的時候
會先將這些索引載入記憶體，索引會指出資料在儲存體的位置
所以可以快速的將符合條件的資料列找出並且載入計憶體，並回傳給你的應用程式
萬一沒有足夠的索引，這個時候就麻煩了..!!
SQL Server會直接從硬碟中，一列一列的打開資料列
去看這個資料列的欄位是否符合條件
如果符合才載入，假設三萬筆，他就再硬碟上找了三萬次
這個時候就會陷入 IO 地獄，大幅降低系統效能
IO的存取會跑到100%，這個時候不管其他人是否也在存取資料庫依定會受到影響
大家就在等某個Query跑完，然後輪下一個
好好檢查一下，你們ERP目前使用最頻繁的功能是哪一個..??
直接先從那個功能開始進行效能調教
哪個功能查詢時候使用的SQL Command
截取出這些SQL Command，並且分析出關聯的TABLE以及欄位
開始建立這些相關的索引
最後，最好每天選定一個離峰時段，讓資料庫維護計畫自動更新索引資料..!!
假設每天 08:00 ~ 21:00 是你們公司作業時間會使用到ERP
那麼你們可以設定在 04:00 ~ 06:00 進行索引的重新組織
以上這些功能在 SQL Server 2008 上面都還滿容易執行的..!!
有時候你只要先解決掉第一個瓶頸，效能上就會加快
解決掉20%的瓶頸，就可以獲得80%的效能提昇
不過我認為
64位元資料庫明顯強過32位元資料庫
SQL 2008 強過 SQL 2000
(在沒有任何效能調教的情況下就是如此，效能調教完成之後會差更多)
昨晚有用Exact的資料庫最佳化功能
最佳化一半發生錯誤....至於大大地作法我會反應給正式網管
畢竟當初叫他安裝SQL 2005他都不裝了....
目前的確是32bit版的OS加資料庫....
PS：資料庫最佳化gbkmut這個資料區
目前是真的陷入IO地獄，因為看工作管理員，cpu使用率低的可憐...記憶體也是用到少少的，SQL只吃掉1.7GB，但不管怎設定都沒有用，可能是32bit的問題。
可以測試一下是寫入慢還是查詢慢?
寫入慢有可能是寫入的table的key或index太多, 造成寫入資料有額外的運算
查詢慢的話盡量要求使用者使用條件去查詢, 不要一次需要載入許多資料
SQL只吃掉1.7GB，但不管怎設定都沒有用，可能是32bit的問題。
==> 所以我另一個問題才問，有沒正確設定使用記憶體。沒設定會只用到1.7G呢 ..
但透過大家的討論，似乎大家的想法都雷同..
換HDD不是根本的解法啊... 依據您的狀況＆需求，透過INDEX或是修改SQL語法，或許比較有效呢...
整個系統最慢的是網路.
程式在寫時,如果寫入動作>讀取動作,減少建置所引.相反的是建所引增加效率.
要會清Log檔.
Exact plans to stop selling SQL Server 2005 as of May 1st. From that moment on, only SQL Server 2008 licenses can be sold to Exact's customers.
SQL Server 2008 licenses grant customers the right to downgrade, which means that customers wanting to use SQL Server 2005 can still do so when purchasing SQL Server 2008 licenses. The upgrade to SQL Server 2008 can then take place at the customer's own convenience.
ExactSoftware
寫太多沒效率的 View
要從核心去改善
要改成 Procedure
不是換 Database
要改寫成 Procedure 請洽 Skype: ADempiere/Compiere
「要改成 Procedure
不是換 Database」
是什麼意思呢？小弟有些不大明白....
目前我們的sql是用2000版
改寫成 Procedure的意思是資料庫優化嗎？
恕小弟才疏學淺，望請大大們指教
View -> Procedure 資料庫優化 ? No..
Please Change your Exact's Retrieve data method !!!
exactsoftware 工程師不敢改 也不敢承認
讀取資料方式是有待改進的
一直加大資料庫是無法解決問題的
目前是一年把舊的DB備份，再建造一個新的DB
董事那邊是說資料庫以會計年度為單位，一年重建一個新的從0開始，舊的備份不使用
一年重建一個新的從0開始，舊的備份不使用??
那是不可能的
未結案訂單 未結案工單 未結案應收帳款 未結案應付帳款
?????
公司內部的資料,單據,你要怎麼作都沒關係.
但如果對外資料,憑證..所有交易流程都要被記錄,根本不能刪除跟切割.
這是8個月前 有關 荷蘭 Exact Software 開發部門工程師 談有關執行效率
會一直低落的相關應調整觀察等事項...不要被越南代理商亂搞了...你需要的是我跟荷蘭原廠團隊的建議...
http://www.keepitsimpleandfast.com/2008/12/optimize-index-structure-which-indexes.html
擬也該查查你的 Gbkmut 超級大資料表 的索引表 是否正常
This script will display the index usage statistics for the table 'Gbkmut' which are never read.
-- Used Indexes with only updates and No reads
SELECT object_name(s.object_id) AS ObjectName,ISNULL(i.name, '(Heap)') AS IndexName,
user_seeks AS IndexSeeks,user_scans AS IndexScans,user_lookups AS LookUps,
user_seeks + user_scans + user_lookups AS TotalReads,user_updates AS Updates,
CASE WHEN (user_seeks + user_scans - user_updates < 0) THEN'Updates > Reads'
WHEN (user_seeks < user_scans) THEN'Scans > Seeks'
ELSE' '
END AS Warning
FROM sys.dm_db_index_usage_stats s
INNER JOIN sys.indexes i ON i.object_id = s.object_id AND i.index_id = s.index_id
WHERE database_id = DB_ID() AND objectproperty(s.object_id,'IsUserTable') = 1
AND object_name(s.object_id) = 'gbkmut'
AND (user_seeks + user_scans + user_lookups)=0
擬也該查查你的 Gbkmut 超級大資料表 的 table space 是否正常
With next query you can see how much diskspace the indexes for table 'Gbkmut' are using.
-- Indes sizes of an table
SELECT Name as Index_name, Type_desc AS IndexType, Space_used_in_mb = (page_count * 8.0 / 1024.0)
FROM SYS.INDEXES I
INNER JOIN SYS.DM_DB_INDEX_PHYSICAL_STATS(db_id(), object_id('gbkmut'), null, null, null) IP
ON I.object_id = IP.[object_id] and I.[index_id] = IP.[index_id]
ORDER BY I.index_id
OK收到,感謝大大提供資源
明天一早上班就去試試
因為之前用Exact內建的Rebuild index功能
gbkmut出現no found的錯誤....
table space的圖，有點大，光是index單一檔案就要吃掉將近9GB
http://img41.imageshack.us/i/dbspace.png/
This script will display the index usage statistics for the table 'Gbkmut' which are never read.
這指令我查了他沒有顯示東西
就算真的換了主機也不一定能夠完整解決問題
有沒有試著去看是不是資料庫的問題
例如索引之類的
那也是會影響到資料庫讀寫
一般來說軟體商都會推硬體,硬體都會推軟體
我遇到的狀況都是這樣子,大家推來推企...
購買2.5高效能的SLC SSD
效果應該會好一些吧
不過還在用sql2000是比較舊了點
購買2.5高效能的SLC SSD 東西也還好,但是需要多少才能填補這個漏洞?
解決問題看你要由上往下看,還是由下往上看到應用層.
我是先建議您檢測硬體各項數據,raid6是不是也是元凶??有些時候陣列卡效能不彰也會這樣.
也可以思考先降回raid 1+e等等來測試,耗時間不耗金錢的方式.
以前sql2000我遇到的如果是效能索引無法調,也很多問題來自ap,甚至...你都可以去檢查switch等等,由您來探索....我是覺得sql2000跑這個32gb的資料內容還好,我還遇過大怪獸....
使用者使用條件去查詢, 不要一次需要載入許多資料!!!
但是如果不將View改成Procedure
View 無法限制只取用要 join 的資料範圍
因此一定要改成 Procedure
Dear albertachen ,
問題出在這位開版大大是IT,通常改這東西普通沒經驗的不十分熟悉Performance Tuning的新手,也無力修改套裝ERP,出包就是死自己阿!!,況且原廠的工程師如果沒建議,您提建議恐怕也是被打槍...例如別處沒有問題等等官話...跟您聊天一下,感謝您的回應
因為之前正式IT被罵很慘，原因是找不到速度慢的原因，且無法解釋到董事長「聽懂」，而董事又有自己的看法與理論，所以不好找到交集，例如：之前DB才25GB，等候時間一秒，現在32GB，成長了30%，那等待時間應該只有1.3秒。可是別忘了，原本BOM展開只有到第二層，現在是全部輸入...還包含一些Transaction在內。我已經盡力解釋，因為牽涉到原因實在太多了
董事長迫切渴望解決問題，故開出50預算升級配備，指硬體部份，但如果購置新硬體仍無法解決，那事情會非常大條...
在公司IT部門實習? 應該交給在IT部門負責的人吧!
SQL 2000(32bit) 最多只能用到1.7G的RAM.
安裝 server 03 DataCenter => 無解.
依現有資訊判斷,有幾個方向來解決:
找出 top 10 sql command. (最耗時的10個sql command)
如果 sql command 筆數過多 => 執行的作業是否合理?若不合理則是程式寫的太爛)
如果時間過長 => 檢查SQL, 分析一下,是否需要增加索引.
若Exact Globe可以支援64Bit DB. 則將 os 改為 Win server 2003 std/ent 64bit + sql server 2005/2008 64bit . 會大幅提昇效能.
若Exact Globe不支援64bit DB. 維持win server 2003 ent. (boot.ini 要設 /pae /3G ) + SQL 2005/2008 32bit. 這樣資料庫才能使用超過2G的記憶體.
執行DBA 的維護工作. (日常reindex. cal statistic info..)
將temp file個數設成與 cup 數相同. 並與主要資料庫的data file放在不同HD.
重整所有資料,再重建所有index. (if needed)
找專門作db tuning 的公司.
更換效能更快的硬體.
目前敝公司使用 鼎新workflowII ERP7 , HP DL380 G4. 10g ram ,win 2003 ent 32bit. sql 2005 std 32bit. (去年從V4升級到V7, os 2003 std => ent, ram 4g => 10G . )
以上請參考.
小弟是在越南阿...所以網管也是越南人，只是我得把問題簡單化、易懂化
第一點小弟是資料庫白痴(完全沒學過的)...但能確定是資料庫的I/O很重
第二點正式網管有弄過，用別台主機充當臨時伺服器，SQL2000有吃超過1.7GB記憶體，但後來不知是否因為防毒軟體不支援64bit系統，所以沒有做繼續嘗試....
第三點在重灌前有設定過，不過沒有+ /3G，結果仍然一樣，我會努力說服正式網管用新版的SQL
第四點我們都固定作備份，似乎外接一顆硬碟作同步(不清楚)備份，至於DBA我就不大清楚了....我只知道網管似乎只會SQL的圖形操作....其他得問問了
第六點的話，能否推薦一下適合主機配備與廠商呢？因為我已經有問過報價了，這禮拜一業務跟我說會出來，只是不知道台灣哪邊還有哪家廠商比較優惠的價格，能否請大大提供一下
更換硬體能解決的問題有限. 如果目前觀察瓶頸是在HD, 若想辦法提昇HD r/w 速度到2倍. 原本執行要等20秒的作業變成等>10秒. 或是要跑10分鐘的批次=>變成>5分.
有時候資料庫只要一個SQL Join 的不好.(full table scan or without index or in (...) 數量過多. 就會使整台DB 效能被影嚮.
台灣廠商: 目前我們公司找產品會請3家廠商報價,再進行議價.
ex: serverbank , 聚碩,群環,.... Server 廠牌(依順序): HP,IBM,Asus
PS: 換硬體提昇的效能真的有限. 如果系統版本都沒變過,只是資料成長30%.到36G. 速度變慢 3倍. 那確實要從硬體設定調整. 如果軟體版本有變,與軟體有關的機率較高.
如果要改Raid. 建議 raid 1 (兩顆HD) + Raid 0+1 (四顆HD)
OS & temp file 放在 raid 1. data db 放在 Raid 0+1
另外: 3萬筆 => 36G 不太合理. 除非所有 cad 檔,包含歷年來的版本變更的cad 檔都在DB中. 若是, 則要把 存放大檔的 table 放在 不同的 data file. 甚至放在不同的raid HD中. 把IO分散在不同的HD.
公司有錢就有這種好處.
3萬多筆,146G用36G,磁碟陣列+26G的RAM.怎麼想都不可能是Server硬體的問題.
3萬多筆,36G資料對我們小公司而言,一台3,5萬的小PC就搞定了.
我認為,網路頻寬,資料庫的調教,程式的邏輯,使用者,程設師,管理師..素質才是關鍵.
通常erp會慢有一半是設計者沒有寫好才會造成這樣的結果
然後erp的客服就會說，這是你們設備不好所造成的
只能說erp還是找大一點的廠商比較好
解決效能問題, 要治標更要治本, 正確的做法是先收集效能進行分析-->進行方案評估-->決定改善方案.
有 50 萬, 花在買 Server, 是很夠用, 但是 I/O 效能不夠, 跟換主機的關係要說清楚啊!!
我一年大概規劃上百套系統, 碰到不少案例都是為了消化預算而消費, 錢太多, 寧可拿去請位SA, 改善系統程式, 反而比較有幫助, 順便還可以提升就業率!!
你有啟用AWE記憶體嗎？如果沒有啟用，SQL是不會使用超過2G記憶體的。
僅記得新人笑,哪會記得舊人哭,您提起了塵封的回憶阿.AWE...呵呵.眼睛一亮阿
開版大大雖說RAM已經排除,但您可以試試,有時候關節會在不起眼的地方,也不見得會如您想像
這部份得等到明早上測試了....
想哭哭，不知道怎跟另一位董事解釋
因為之前我才跟他說不是很迫切換硬體
現在又得順應另一位董事的需求....誰可以幫幫我
只能把報告打中立些了
早上開啟AWE後
目前PF 12GB 記憶體剩餘11GB
但開工作管理員看SQL的程式只有吃掉110多MB記憶體
目前速度尚可.....
PF檔拿掉吧, 效能可以提升兩倍以上的.
Additionally, it entails creating a positive work environment, managing workers, and keeping accurate financial records. All of these factors contribute to the success of a company run by a professional bookkeeping firm in Singapore. If you want more information you can read this blog: https://supperarticles.asia/8-vital-elements-in-bookkeeping/
iThome鐵人賽
看影片追技術
