[20160604]淺談出錯提示.txt

[20160604]淺談出錯提示.txt

--這個問題主要由於上個禮拜正常上班時間遇到的問題,導致整個業務停頓10分鐘上下,出錯提示"解析URL錯誤",實際上這個問題我遇到過
--一次,當時不是我解決的,我提交軟體組,我記得對方提到1臺伺服器服務出現問題,重啟服務就ok了.但是我不知道那臺伺服器IP地址.

--這個問題是我想到錯誤提示,這個提示明顯不明確,導致"浪費了許多時間".有同事定位dns問題,要求檢查dns服務.

1.首先-舉一個oracle的錯誤提示:http://blog.itpub.net/267265/viewspace-750075/

Errors in file /opt/oracle/admin/conner/udump/conner_ora_31607.trc:
ORA-00600: internal error code, arguments: [2662], [0], [897694446], [0], [897695488], [8388697], [], []

ORA-600 [2662] "Block SCN is ahead of Current SCN"，說明當前資料庫的資料塊的SCN早於當前的SCN，主要是和儲存在UGA變數中的
dependent SCN進行比較，如果當前的SCN小於它，資料庫就會產生這個ORA-600 [2662]的錯誤了。這個錯誤一共有五個引數，分別代表不
同的含義

ORA-600 [2662] [a] [b] {c} [d] [e]
Arg [a] Current SCN WRAP
Arg [b] Current SCN BASE
Arg {c} dependent SCN WRAP
Arg [d] dependent SCN BASE
Arg [e] Where present this is the DBA where the dependent SCN came from.
注：897694446<897695488

--oracle 的錯誤提示 只要google或者metalink賬戶,查詢到相關資訊.

2.很明顯上面的資訊很難定位那臺伺服器出了問題.再來看看另外的錯誤提示:
--錯誤提示內容如下:
病區藥品醫囑與醫生醫囑首日次數不一致.

--這個提示看上去還可以,如果給你看出錯介面,你就知道這個寫有多麼的不好.這個設計到具體的應用問題,就是護士工作站停止醫囑時遇
到的問題,不知道是否能講清楚?

--//首先出錯介面上有許多醫囑,如果操作員打電話給維護人員請求解決問題,一般維護人員會要求操作人員先縮小範圍,也就是先操作部分
--//醫囑,最後剩下有問題的醫囑.再來解決問題,操作人員往往覺得很煩,有時候事情一多,撂下一句話"我現在手頭許多事情,你先給我看
--//看吧". 嚴重一點,xxx都上來...當然可以透過後臺找到sql語句,寫出找到問題的問題的"病區藥品醫囑",修改兩者保持一致.

--//真正的提示應該如下寫呢?以這個為例子我自己寫一個:

病人ID: AAAA 住院號:BBBB 姓名:CCCC 醫生醫囑本號:EEEEE 病區藥品醫囑名稱:GGGGGG
病區藥品醫囑本首日次數XX與醫生醫囑本首日次數YY兩者不一致.

--//這樣寫多麼清晰明確.我真不知道為什麼開發不這樣做.首先這些資訊已經存在,這樣即使許多新加入的運維人員也很容易知道修改定
--//位問題,修改涉及那些表?這很難嗎? 以前我還就這個問題跟一個專案經理講,在他看來這樣做無形在增加許多"負擔".而且不通用,真
--//不知道他理解的"通用"就是寫給開發嗎?這些細節能浪費多少時間.

--//在我的系統存在大量這些無用的提示? 我很想問一下開發就是這樣寫程式碼的,懶也不能這麼懶法.

--//再說一些細節:上面提到的住院號:XXXX,實際上在應用介面上無法看到這個號碼的,介面上僅僅顯示病人ID或者叫病人卡號.
--//運維在解決問題的時候,我看到不止一次透過查詢病人卡號找到住院號,再透過住院號查詢相關表.這樣天天重複難道不煩嗎?
--//而這樣不到10分鐘完成的修改程式碼,以後定位問題不是變得很簡單嗎?

3.再繼續探究問題:
--//為什麼會出現上述問題?醫生開了醫囑,護士轉抄醫囑,兩者的首日次數應該一樣,護士不可能改轉抄的這部分資訊?
--//到底哪裡出了問題呢?以下完全基於我的猜測:

--//醫生開了醫囑,應該一般有一個狀態欄位表示"新開",而在沒有提交之前,護士站轉抄是看不見的.
--//而只有在醫生提交之後,護士站轉抄介面才能看到.這個時候的狀態"提交"

--//有一種可能就是護士站轉抄介面看到後,護士並沒有及時操作提交到病區醫囑本,比如一些事情接個電話或者幹別的事情,這個時候是
--//否醫生可以修改,如果能修改首日次數,問題產生.

--//而醫生這個時候要操作必須把狀態改為別的狀態,至少不能是"提交",修改完成後再次"提交",而護士不可能再去重新整理介面,而是直接轉
--//抄,這樣就出現病區醫囑本首日次數與醫生醫囑本首日次數不一致.

--//再繼續假設,應用程式醫生提交後不能再修改醫囑,要修改必須要求護士站執行一個退回操作.
--//但是不要忘記,醫生經常喜歡登入並開啟多個應用程式,這樣1個可以拿來看,另外一個拿來操作,這樣一個介面上提交了醫囑,但是另外
--//一個介面上還是"新開"狀態,有可能在這個介面上修改,甚至嚴重的刪除一些醫囑,這樣護士上操作嚴重問題.
--//不知道是否會出現護士站已經轉抄,而醫生一樣可以修改的情況.

--//總之就是多個使用者多個介面操作,"併發"的問題,你要控制使用者的行為相對困難,只能在後臺加入更多的檢查與控制.

4.有點扯遠了,繼續回到錯誤提示的問題:
--//再舉一個例子.病人在轉科時提示如下:
轉科床號與實際床號不符.

--//注:具體顯示內容可能有點不同,大概就是這個意思.
--//真不懂為什麼不把住院號帶出來.寫成如下:

病人ID: AAAA 住院號:BBBB 姓名:CCCC 轉科床號FF與實際床號GG不符.

--//這樣寫很難嗎?我們的提示幾乎都是像上面那樣.再具體一點還可以這樣寫:

病人ID: AAAA 住院號:BBBB 姓名:CCCC 住院病人資訊的當前床號FF與住院轉科記錄的床號GG不符.

--//這樣查詢範圍減少了許多,僅僅需要查詢住院病人資訊表與住院轉科記錄就可以定位問題.

--//繼續講講這個問題的產生,還是多個操作併發的問題,為什麼不把問題放在前面,而是等轉科來解決,難道你半夜上喜歡爬起來解決問題
--//這樣做事很有成就感嗎?讓運維運算元據庫,執行dml,難道不存在風險嗎?

--//試問一下,這樣提示會洩露秘密嗎?純屬無稽之談.

--//透過例子來說明,這並需要什麼高深的資料庫知識
.
--假設病人現在在5床,現在要轉科,但是還有一些收尾工作沒有完成,但是馬上就有新病人入住5床,護士的操作就是一般是把病人在轉移到
--當前科室某個空床假設是33床,這樣住院轉科記錄有1條記錄記錄的是5=>33,轉科科室前後不變.住院病人資訊的當前床號=33床.

--另外一個護士在自己的操作介面上看到的病人還是在5床(因為沒有重新整理,除非她做重新整理操作,或者等幾分鐘程式自己會重新整理,我喜歡給應
--用起另外的名字叫刷屏軟體),她做完相關操作,做轉科操作,這樣操作相當於又修改了住院病人資訊的當前床號=5床.而住院轉科記錄的
--床號是33.

--這樣在在轉入的科室操作就出現"轉科床號FF與實際床號GG不符",實際上在第二個護士做轉科時多加入一個條件就ok了:
update 住院病人資訊表 set ... where 住院號=:zyh and 病人床號=:brch

--這個時候帶入的:brch=5,修改不會成功,呼叫刷屏,最好能告之病人現在在哪一床,再次執行轉科操作就ok了.

--依靠刷屏能解決問題嗎? 團隊有多少人認真思考這些問題,解決很複雜嗎?再這些介面操作時加入床號條件,許多問題很容易解決.

總之:
不從小處根本解決問題,成天干那些重複的事情有意義嗎?
但願開發能看看寫的這些,不然做一輩子開發,到頭來就是一場空....