[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了.
--依靠刷屏能解决问题吗? 团队有多少人认真思考这些问题,解决很复杂吗?再这些界面操作时加入床号条件,许多问题很容易解决.
总之:
不从小处根本解决问题,成天干那些重复的事情有意义吗?
但愿开发能看看写的这些,不然做一辈子开发,到头来就是一场空....
--这个问题主要由于上个礼拜正常上班时间遇到的问题,导致整个业务停顿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了.
--依靠刷屏能解决问题吗? 团队有多少人认真思考这些问题,解决很复杂吗?再这些界面操作时加入床号条件,许多问题很容易解决.
总之:
不从小处根本解决问题,成天干那些重复的事情有意义吗?
但愿开发能看看写的这些,不然做一辈子开发,到头来就是一场空....
