過程：
本次出差去dyey配合公升級10.30的過程中，給我的總體感覺就是醫院資訊科能力的強大、專業，這是我從前接觸使用者中不多見的。由於這個原因，公升級過程非常輕鬆順利，公升級過後雖然也出現了一些邊緣模組的小問題，但是由於有研發同事的現場跟蹤除錯，都得到了立即的處理，而我負責的整體效能這塊，通過觀察也沒有發現非常嚴重的問題，但是還是有一些sql語句對效能消耗比較突出，導致系統效能下降，主要集中在以下2點：
1.高頻sql的系統整體效能的影響
通過醫院業務高峰期的awr報告觀察，整個醫院的效能比公升級前還是有所下降，通過分析，發現主要表現在邏輯讀增大，原因是一條藥品發藥重新整理的高頻sql效能不好導致，如下：
調整前的效能報告：
通過28號早高峰（9點~10點）的效能報告可以看到，醫院的邏輯讀每秒有30w,db time達到了300分鐘，這些都比公升級前有所提高，再分析邏輯讀最高的sql語句，可以發現主要集中在藥品發藥重新整理和體檢的一條求和sql語句上，如下：
通過分析我們發現，這些sql語句都加了rule規則，而在目前的cbo環境下，統計資訊收集準確，走成本的執行計畫效率要優於規則很多，因此我聯絡了研發人員，請他們把強制規則取消，然後再行觀察。
調整後的效能報告：
調整後，第二天的同樣時段的高峰期（29號9~10點），邏輯讀已經下降到16w,db time也只有199分鐘，基本和醫院公升級前整體效能持平，之前的高頻sql也沒有再出現在邏輯讀前列的sql列表中，孫工對於調整後的效能也比較滿意。
2.個別子系統的模組sql影響效能
除了前面提到的高頻sql，在前面的sql列表中，體檢的sql語句排在效能消耗的前列，而且體檢模組的使用本身並不頻繁，而他的sql會出現在這裡就表示這條sql語句確實存在比較嚴重的效能問題，事實也確實如此。最後我和孫工通過檢視分析，給出調整建議後聯絡研發人員對這些sql進行調整。
總結：
本次出差歸來，給我的總體感覺就是少有的難得輕鬆，歸納出原因主要有以下幾點：
做得比較好的：
1.醫院資訊科能力的強大，前期公升級測試、公升級過程都由醫院自行完成，而且測試仔細，公升級謹慎。
2.公司對醫院的全力支援，出現問題都得到第一時間的處理，醫院都非常的感動。
做得不好的：
1.程式中sql語句的效能是影響每次公升級效能下降的主要因素，如何有效的規範程式設計師sql的書寫和效能測試，是以後研發應該重點思考的問題。
2.高頻sql對效能的影響確實很大，需要引起足夠的重視，還是應該建立機制進行重點關注。
程式sql語句中的強制rule是否有更好的處理方式，便用現場處理，提高效率。
寧夏出差記錄
還有就是那裡的賀蘭山風景區，摘抄一段介紹 賀蘭山滾鐘口。寧夏歷史文化的濃縮，賀蘭山自然奇觀的精髓，賀蘭山主山之地。曠世奇觀，北方石林。佛 道 伊斯蘭教 三教合一 福報靈山，諸神百靈的數十處道場。數處西夏離宮遺址，馬鴻遠避暑山莊，賀蘭石原產地，珍稀天然礦泉水。從銀川去蘭州非常方便，坐火車乙個晚上，睡一...
記錄第一次出差的經歷
2020年6月19日的下午，是乙個周五。在這個悠閒的時光裡，我翹著二郎腿，寫著再普通不過的curd。突然，主管彷彿捕捉到了我迷離的眼神，慢慢地走到我的旁邊，拉著我的衣角。我想 該不會我摸魚被發現了吧，主管想炸了我的魚塘？主管 成都某行那邊有個專案，需要暫時找個人過去支撐一下。你看我們這邊有家室的有家...
xe 最大連線數限制 記錄客戶連線 心跳
keepalivetime cardinal 多長時間 ms 沒有資料就開始send心跳包 keepaliveinterval cardinal 每隔多長時間 ms send乙個心跳包，發5次 系統值 end tservercontainer1 class tdatamodule dsserver1...