※ 引述《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