注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

欢迎光临我的博客

 
 
 

日志

 
 

12月5日ifs问题  

2008-12-09 14:32:39|  分类: 总结 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

  125ifs问题

126 ifs周例会上高军灿提到数据丢失的问题,我当时不明白是怎么回事,会后松林找长山查找问题,我也跑去看了一下情况,反映的实际情况是:登陆erp2 正式库点客户订单------客户订单--客户订单 检索数据能显示出来,点客户订单------客户订单-----客户订单追踪, 检索客户订单窗口已存在的某条数据不能检索出来。

当时我考虑问题的几个方面:1权限问题2人员是否是完整操作问题3ifs 本身软件表操作关联问题4数据库本身问题5服务器硬件问题,6是否有人对软件进行了某方面的设置问题,当时没有想到从后台看看命令的执行情况。然后进行了逐个排除,使用ifs 超级用户登陆系统问题依然,说明不是用户权限的问题。我让松林从新输入一个订单,并下达订单,进行一次完整的操作,让松林检索数据,问题依然,说明不是人员是否是完整操作问题。我让长山登陆到测试库,让松林对以上两个窗口进行同一订单数据检索,发现测试库没有问题,说明了不是服务器硬件问题,可以确定正式库是有问题的。在5号之前erp2 正式库中没有出现以上问题,问题可能是谁对正式库进行了某些设置造成的。

查询了一下备份的数据,长山说有星期四的数据,但不确定就是星期四的数据。当时考虑进行数据的恢复,考虑到如果数据导入到测试库,测试库数据就会丢失,而且如果恢复不成功的话,不便于数据库对照查找原因,而正式库已出现问题,如果恢复不成功的话,为了能方便查找原因,最好也不覆盖现有的正式库,给长山建议建一个新库。但长山具体怎么做了我也不清楚,我吃过饭问长山的时候,他已经做完了,并说数据是星期五的数据,也就没有在多问。我现在对说的那是星期五的数据有点疑问,是那确实是星期五的数据还是他恢复之后发现以上的问题存在来断定不是星期四的数据,因为当时我没看长山是否建数据库,是否对数据库两个窗口进行数据验证,如果验证了,都谁验证过,没有进行仔细问。当时我也是想查找操做记录,但不知道从何查找。

127日上午松林打电话说他发现了问题的原因,登陆ifs正式库系统,在概要--------背景查询操作情况,从状态字段和时间字段看,发现申建民在125日下午1548分执行的操作到现在为止还在执行,在执行过程中产生了错误,而且有好些都是同一个操作,可能是他在调整时出现错误而进行了好几次的重复动作,造成了125日下午和126日其他操作员执行的命令排队不能执行的原因。从系统中导出的申建民操作的情况见附件

我登陆admin界面在背景中查出申建民的用户并删除了他的相关操作,然后松林对没有执行的命令进行了手动执行。执行之后,我让松林查问题是否存在,他说还是存在,随后让我启动一下数据库。

我登陆v440服务器执行ora10/bin下的stoperp2.sh命令时发现光标一直停在那闪烁,数据库不能停止,随后我问了一下长山情况确认操作正确后给闫老师说了一下情况,看了一下停止的脚本,进行分开执行

$ ORACLE_SID=erp2;export ORACLE_SID

$ sqlplus /nolog

 

SQL*Plus: Release 10.1.0.4.0 - Production on Sun Dec 7 12:13:32 2008

 

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

 

SQL> connect / as sysdba

Connected.

SQL> shutdown immediate

 

ORA-01013: user requested cancel of current operation

SQL> SQL>1210分开始,光标大约停了半个多小时,出现了上面的提升错误随后我执行了

SQL> shutdown abort

ORACLE instance shut down.

SQL> startup

ORACLE instance started.

 

Total System Global Area 2415919104 bytes

Fixed Size                  1303896 bytes

Variable Size             601488040 bytes

Database Buffers         1811939328 bytes

Redo Buffers                1187840 bytes

Database mounted.

Database opened.

SQL>

数据库启动后时间是1315分问了一下ifs用户说系统可以连接并可以使用了 。快到下班的时候登陆系统 点客户订单------客户订单-----客户订单追踪 检索客户订单窗口已能检索出127日下午之后的数据,但查不出6号。说明系统正常了,但由于松林下午请假,没有确认,128日上午得到了松林的确认,1257号的数据能检索到了,说明次问题已经基本解决。

     从此次问题的情况来看,是因为申建民执行某个耗时处理作业而导致别人执行的作业长期处于等待状态造成上述问题的,造成上述问题是服务器性能跟不上,还是软件本身问题,还不能查出来。建民都执行了那写操作,这个也不清楚,为了能让以后出现问题时能够方便问题查询,我感觉核心用户对系统的操作应该归档。而且建民的那些是需要执行的,如果执行的话,就可能产生这样的问题,这也是需要考虑和解决的问题。从此次问题来看,数据备份的天数少也是一个隐患,现在服务器上的空间不多了,如果要是操作人员进行一些设置,不能及时发现问题,要恢复到前三天的数据,那也就麻烦了。在127日中午停止数据库的时候不能正常停止,现在原因还不清楚,从当时从进程来看有一个oracle cp 的进程,可能时当时进行数据备份而造成的数据库不能正常停止。以后出现问题时也要想到进入后台看看命令执行的情况。这是一点经验。由于这次在结束申建民的命令后,问题仍然没有解决,则说明是重新关闭和启动数据库变好的,但是为什么长山在星期六那天关闭和启动数据库不能好呢,理论上应该是能好的,现在只能理解为没有删除申建民的操作而导致长山启动数据库后又开始执行那些耗时命令造成的了。

 

  评论这张
 
阅读(405)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017