※ 引述《iFEELing (ing)》之銘言： : 1. 這種問題應該用 UNIT TEST tool 找，不應該丟上正式區爆炸了再改正式區的資料 其實我們寫好的程式會想到測試環境，做完測試後再上正式區 但因為種種因素(測試人員素質、正式測試資料不一致...)等 難免還是會有資料面的問題產生 : 2. 目前程式run到哪一行...除非正式區只有幾個人在用? 這就聊到監控軟體resource的問題了.... 如果會影響到server的效能.... 那就要評估使用的時機了 總不能系統都正常的時候，還一直去看程式跑到哪一行了吧?! : 3. 修改卡在半途的資料... : 除非原本的程式就有考慮到這種情況，不然一般來說， : 隨意修改"不屬於自己的資料"是很危險動作 當然.... 萬不得已我們也不希望這樣做 ^^" 因為我們公司是屬於一直在出貨的狀態. 系統一出包的話，外面可能就幾十台車在等你了 囧rz 所以才希望有這樣的功能來做危機處理 當然，如果程式測得夠完整或AP可以馬上debug上傳正確的程式 就不需要做這種事了 所以這是下策中的下策 : 4. table lock 或許可以用 APM ( Application Performance Monitor ) 軟體看 : 被卡住的區塊會花很多時間。不然你的 DBA 應該也知道什麼東西被鎖住。 我們DBA提供給我們的內容其實都只是SQL而已 實際上造成table lock的主因還是connection沒有被正常使用所造成的 但我們更需要DBA告訴我們是哪一行程式造成table lock 因為正常情況下，SQL其實都能正常執行的 : 5. 邏輯錯誤...這個是人的問題。除非你有可量化的數據可用程式抓， : 不然工具能幫的忙有限。 這其實也和AP的能力有關.... 結論：其實我也很無奈啊 XD --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 220.140.38.213