关于UDB升级降版本的问题
2013-04-10 10:13
288 查看
现象:
在前台停掉 UDB后,在designer中升级 USERDB,升级进度条走到底,看似升级成功,但是刷新下,版本又降下去了。
遇到这个问题。。。 buddy, you are so unlucky。。。。
如果这个在生产环境上出现了,就不要做处理了,让甲方联系原厂吧,毕竟自己搞弄坏了就不好了。
如果是在自己的开发环境或者是不重要的环境,可以通过数据库的还原来重新升级下。
如果你升级前连数据库都没有备份的话(while in this case , i have to say- buddy,you are on your own)
参考下以前成功解决下的例子吧(每次报的错都不一定一样,所以得具体分析,大致是看报错信息,具体分析):
如果你被迫采取以下这种方法,请做好思想准备,当时搞了差不多一个下午才搞好,这还算幸运的。
首先先看下日志文件,看报错信息,当时首先报的是
existORA-00955:name is
already used by anexisting object
这个意思呢,就是报 表等其他对象已经存在,无法再在数据库造相同的表等对象
找到启动文件 bfd ,然后 找到 -Dhs_debug=false 选项,改值为true
然后重新启动HBP服务。
然后再升级,又报错,信息如下。
。。。。。。。
CREATE TABLE t_usr_s_resouceapply (f_s_resources_examinenotes CLOB,
f_s_resources_realitytime NUMBER(*, 0),
f_s_resources_estimatetime NUMBER(*, 0),
。。。。。。。。。。。。
java.sql.SQLException: ORA-00955: name is already used by an existing object
at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134)
at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:289)
at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:582)
at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1986)
。。。。。。。
这个看出来了。把这张表已经存在了。然后把这张表给删了。然后再升级。
发现还是不行,又报其他表已经存在,然后又删表,再升级还是不行,不是报
A表已经存在,就是报B/C/D已经存在(每次只报一张表已经存在,悲催)。
最后把报已经存在的表一次性全删了。再升级。
这样最后升级成了。
估计得把这次升级涉及到的新建表全给删了,再升级。。。
最后如果有报表的某列已经存在了的话,就把那列也给删了。
这样做下来,2个极端,要么你能够升级了,要么你的环境彻底报废了(当你试了N久再也无法升级成功的时候)。
总结: 1.升级前数据库要有备份,备份都有脚本的,不要偷懒。
2.我现在搭建的是TESTDB,是不需要checkin的,直接升级testdb,这样减少了出现以上这种情况的可能性。
3.求助下原厂也可以,但升级失败这种问题,估计他们也会嫌太麻烦,不大愿意搭理(的确这个是比较麻烦)。
4.出现了升级失败,还是靠数据库还原吧,这样快点。上面那种只适合没有备份的情况。
5. 开个玩笑,最后就是靠你的毅力,RP了。
在前台停掉 UDB后,在designer中升级 USERDB,升级进度条走到底,看似升级成功,但是刷新下,版本又降下去了。
遇到这个问题。。。 buddy, you are so unlucky。。。。
如果这个在生产环境上出现了,就不要做处理了,让甲方联系原厂吧,毕竟自己搞弄坏了就不好了。
如果是在自己的开发环境或者是不重要的环境,可以通过数据库的还原来重新升级下。
如果你升级前连数据库都没有备份的话(while in this case , i have to say- buddy,you are on your own)
参考下以前成功解决下的例子吧(每次报的错都不一定一样,所以得具体分析,大致是看报错信息,具体分析):
如果你被迫采取以下这种方法,请做好思想准备,当时搞了差不多一个下午才搞好,这还算幸运的。
首先先看下日志文件,看报错信息,当时首先报的是
existORA-00955:name is
already used by anexisting object
这个意思呢,就是报 表等其他对象已经存在,无法再在数据库造相同的表等对象
找到启动文件 bfd ,然后 找到 -Dhs_debug=false 选项,改值为true
然后重新启动HBP服务。
然后再升级,又报错,信息如下。
。。。。。。。
CREATE TABLE t_usr_s_resouceapply (f_s_resources_examinenotes CLOB,
f_s_resources_realitytime NUMBER(*, 0),
f_s_resources_estimatetime NUMBER(*, 0),
。。。。。。。。。。。。
java.sql.SQLException: ORA-00955: name is already used by an existing object
at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134)
at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:289)
at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:582)
at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1986)
。。。。。。。
这个看出来了。把这张表已经存在了。然后把这张表给删了。然后再升级。
发现还是不行,又报其他表已经存在,然后又删表,再升级还是不行,不是报
A表已经存在,就是报B/C/D已经存在(每次只报一张表已经存在,悲催)。
最后把报已经存在的表一次性全删了。再升级。
这样最后升级成了。
估计得把这次升级涉及到的新建表全给删了,再升级。。。
最后如果有报表的某列已经存在了的话,就把那列也给删了。
这样做下来,2个极端,要么你能够升级了,要么你的环境彻底报废了(当你试了N久再也无法升级成功的时候)。
总结: 1.升级前数据库要有备份,备份都有脚本的,不要偷懒。
2.我现在搭建的是TESTDB,是不需要checkin的,直接升级testdb,这样减少了出现以上这种情况的可能性。
3.求助下原厂也可以,但升级失败这种问题,估计他们也会嫌太麻烦,不大愿意搭理(的确这个是比较麻烦)。
4.出现了升级失败,还是靠数据库还原吧,这样快点。上面那种只适合没有备份的情况。
5. 开个玩笑,最后就是靠你的毅力,RP了。
相关文章推荐
- 关于升级程序版本时version与build修改的问题
- 关于Python升级版本出现的问题
- 关于AS报 主版本 52 比 51 新, 此编译器支持最新的主版本。 建议升级此编译器 问题
- 关于JDK升级到1.6.0_21 版本后eclipse常常崩溃的问题
- struts升级到最高版本后遇到的问题。关于actionmessage传递问题。
- 关于版本升级或新功能研发思路障碍问题
- 关于db版本升级之后ogg版本也升级时,配置DDL复制时脚本的问题
- 关于LanMsg版本升级的问题
- 关于阿里云centos 2.6下手机表情输入后无法保存到mysql数据库的问题调研及mysql版本从5.1升级到5.7的全过程纪要
- 关于android版本升级迭代过程中需要注意的问题
- 关于React Native 中升级Gradle版本之后打包出现图片重复问题
- 关于项目中依赖的design版本升级过后,项目中的自定义behavivor(上拉隐藏,下拉显示)的view隐藏后不再显示的问题解决方案
- struts升级到最高版本后遇到的问题。关于actionmessage传递问题。
- 关于集成ibatIS框架后 jdk版本升级引起的问题以及解决方案
- 关于hive升级到0.11的版本问题2
- 关于升级Xcode版本后插件不能用的问题解决
- 关于android的apk版本升级的一些建议
- 关于note2等(Android4.1版本)以上无法启动支付宝的问题"java.security.spec.InvalidKeySpecException"
- android应用版本升级时签名冲突问题的原因及解决办法
- 关于esxi的软件安装与版本升级。