这两天在VMWare下安装了Linux AS3使用Oracle 9i安装RAC作测试,终于搞定了,中间碰到很多问题,磁盘共享读写有问题,oracm启动不了以及gsdctl无法启动等等,焦头烂额,整个过程非常艰苦,不过好在坚持下来了.

整个安装文档在这里,要的人可以来下载.

年关到了,进来问题也不少:

1:一个windows的mscs宕机,每天定时死机;

2:一个windows的Oracle 8.1.7.4.1每10来天就报12500错误,内存使用到达1.7GB的极限;

3:一个IBM AIX的小机无法启动,报错ba210000;不幸的是,这机器是HACMP的1号主机,它宕机了,双机无法启动;

... ...

看来要过年了,DB也觉得不爽了,难道它们也想休息?

今天开发的兄弟找我,说是一个更新语句,在9i上面没有问题,在8i中碰到问题了,执行不过去.

俺过去学习了下(俺对开发一向很差劲).

问题大概如此:一个update语句,要向一个表中插入一个数据,该表中有一个字段名字为sql(汗一个先,历史遗留的超强字段),由于这个字段为long型,要增加的内容就是一个select语句到里面,长度大概6k,所以不能直接用insert into的方法来作,因为这样,会报字符串超长的错误.也就是ora-01704错误.解决ora-01704错误的方法,就是先申明一个变量,然后把那个超级长的字符先赋值给变量,然后更新的时候,用这个变量来更新就好了.这么作,就必须使用匿名块,在8i中,匿名块中,是不认识直接的关键字作列名的,会报错.大概是pls-00103错误.

也就是说,为了能插入数据,我必须使用变量,也就是说必须使用匿名块,可是用了匿名块,就不认识关键字作列名了.

俺记得直接加引号就可以解决的,俺加,先加双引号,报错,说没有这个列,nnd,再加单引号,还是报错.郁闷呀,郁闷呀,metalink,asktom一起上,终于发现一个不大注意的问题,原来使用了双引号来转换那个关键字的列名后,双引号中是区分大小写的,而oracle一向不怎么区分这玩意的.原来我一直作的”sql”这样的是不行的,修改成”SQL”,问题就解决了.

看来以后要多关注开发的东西.

这两天,开发的兄弟在某地和其他系统作接口,不可避免的使用了dblink.

我这边的环境为Oracle 8.1.7.4.0,对方为Oracle9.2.0.1.0,dblink建好以后,作dblink的查询,报错,ora-03106.

俺介入处理,首先俺作了一个select * from v$parameter@dblink,查询是成功的,那么说,整个dblink都是通的;

然后select * from table@dblink,报错,ora-03106,查了下手册,发现可能是由于字符集的问题引起,核对两边的字符集,并无异常.然后作查询,select col1 from table@dblink,这里的col1是不含中文内容的字段,查询成功;然后select col1,col2 fromtable@dblink,这里的col2含有中文内容,查询依然成功,但是如果增加另外一个字段进去,就报错.

严重怀疑是bug,因为整个dblink看起来正常,中文的转换也正常.metalink看看,发现确实会有一个bug,bug id为3982017,看描述如下:

ORA-3106 can occur during a fetch in the server combination: 8i(local_server) < --> 9i(remote1_server)< --> 8i(remote2_serve) This can occur when executing a PL/SQL block which selects a remote synonym (9i) which is created for remote table in 8i(remote2_server) by opening a cursor and fetching data.

从这个描述看,和我的问题比较符合,于是,建议现场升级到9207,可惜现场使用我的升级包,一直无法在服务器上升级成功,直接就是不能安装.

郁闷了,现场兄弟继续修改,原来作查询的table是一个同义词,不查询同义词,直接查询基表,就不存在这样的问题.

至此问题解决,不过还是不明白到底是不是这个bug的问题.有机会再测试下.