05.31.07
Posted in Oracle管理 at 5:10 pm by David.Guo
最近碰到一个奇怪的问题.某个应用,突然redo log的生成增长了10倍,持续了两天后,自己又正常了.
这事情碰到就郁闷,出问题了,自己好了,最难受,因为会睡不着,不知道那玩意什么时候会出现.
如是,去分析statspack,发现在出问题的时间段和正常的时间段里面.每秒的事务和sql的执行次数都没有什么改变.
只是某些语句执行的时候,要获得的记录条数增加了一个数量级.捕获到这些语句,执行的都是select for update nowait之类的.难道是这些语句引起的redo log激增吗?
继续分析,发现这些语句只要执行,是肯定会引起undo的使用增加,这个是可以理解的,但是应该redo不会增加那么多的,按照常理来说,这些语句我并没有真实的去修改,而只是加了个锁,然后释放.并没有作修改,还是select语句列,虽然说会有itl的改变,产生log,感觉不会那么多.
啥都不说了,测试才是王道.如是用create table as select from创建测试表.然后,一边观察v$mystat中的redo的改变,一边对这个表进行for update nowait的操作.
观察的结果,居然验证了猜测,基本上,我的数据量的大小是6M左右(3600行记录,每行不到200字节),只要作了for update nowait的操作,则立刻会生成接近6M的redo文件.相反,在commit或者rollback命令的时候,倒没有多少日志生成.
再回到那个问题,以前好好的应用,为什么那个时候redo会暴增,statspack中,为什么没有特别明显的异常,原来,在出问题的时候,那个for update nowait锁定的记录,在那个时候,由于应用的问题,增加了一个数量级.这就是表象上为什么事务数没有变,每秒执行的sql次数没有变,可是redo log却暴涨的原因了.因为每个事务变大了.但是由于是select操作,并没有真的作update,所以在statspack中很不容易看到明显的变化.
嗯,最后我想不通的是,oracle能确保在同一个事务中,多次读到的结果是一样的,为什么还要用for update nowait去锁定记录列.难道是sybase中带过来的习惯(sybase中如果想在一个事务中多次读到的结果一致,推荐这么干的.),当然了,这个是推测,无论如何,解决问题是最开心的.
Permalink
Posted in David.Guo的心情随笔 at 4:56 pm by David.Guo
今天下午,正在干活
msn上收到原来同事的support请求,注意,是她个人说有问题,要求我给她处理.
看来以前同事一场的份上,我给support了.
那个问题也比较有代表性,所以下面还是先说说那个问题吧.
问题描述:client通过小型机的dblink连接到另外一个中间库,一直在报ORA-12154: TNS:could not resolve the connect dentifier specified故障,这个故障很有意思,明显的是网络故障.一般由于tnsnames.ora配置不对引起.
如是,让她在现场,登录到小型机上,tnsping那个中间库的tnsnames.ora中的服务,正常,sqlplus去连接那个中间库,也正常的,dba_db_links中的信息也没有什么看起来不对的东西.
这就有点奇怪了,再仔细想想,记得哪里的小机是10g的RAC,对,是RAC,为什么要着重提醒是RAC列,因为问题就在这里,他们在作的时候,延续了以前的风格(以前都是单机),只在一个主机上修改了tnsnames.ora文件,而RAC对于client上来的连接,是会按照自己的规则分配由那个node处理的,如果刚好是分配到那个没有配置tnsnames.ora的node去处理这个请求,报12154错误也就在所难免.
调整第二个node的tnsnames.ora文件,问题随即得到解决.
问题解决了,现在俺要申明的是,为什么对原来公司同事个人的support要终止.因为,在我个人看来,原来同事碰到的工作问题,都是原来公司的问题,以个人的名义找我,我很为难.处理不好,不处理也不好.处理的话,我现在已经跳槽,我既然现在在新的公司干活,我就要对新的公司的BOSS负责,如果我是BOSS,我是坚决反对自己的员工老是在干原来公司的活,这和接私活没有什么两样,而且还是免费的私活.不处理,那些人肯定要说我什么走了就不认识人了,什么见死不救不厚道.ok,既然是公司的事情,请将问题提交给老板,不要自己私下就找我处理了,如果是原来老板找我,那又是另外一个层面的问题了,而且,原来公司还有dba在的,这些问题,他们应该会处理的.
无论如何,我只想对我的工作尽责,因此,请原来的同事多多谅解.如果碰到类似的问题,请提交给你的老板,而不是提交给我,谢谢.
Permalink
05.30.07
Posted in David.Guo的心情随笔 at 9:55 pm by David.Guo
啥都不说,很背.
工作上很背,生活上也很背.
Permalink
05.24.07
Posted in Oracle管理 at 6:04 pm by David.Guo
生产需要在一个主机上创建一个db_name相同,instance_name不同的数据库.先作测试.
按照oracle的理论,定位一个数据库的是ip地址和sid,既然instance_name不同,那么理论上,应该是可以创建成功的.
如是,使用创建数据库的文件,创建了两个数据库,除了instance_name不同,其他都相同,当然,文件的路径是不同的的数据库.
启动第一个,可以,启动第二个,报错,说是instance_number已经在使用了.
关闭第一个,然后启动第二个,正常,再启动第一个,同样的错误.看来直接这么作是有问题的.
按照提示,将其中一个数据库的instance_name修改到2,再后启动他,提示说无法启动数据库到专有模式.
由此看来可能是不行了,情急之下,打电话给eygle,他告诉我说普通模式是不行的,但是加一个参数应该是可以的,参数是lock_name_space
查了下该参数的说明:
LOCK_NAME_SPACE
LOCK_NAME_SPACE specifies the namespace that the distributed lock manager (DLM) uses to generate lock names. Consider setting this parameter if a standby or clone database has the same database name on the same cluster as the primary database.
If the standby database resides on the same file system as the primary database, set LOCK_NAME_SPACE in the standby initialization parameter file to a distinct value such as the following:
LOCK_NAME_SPACE = standby
然后将两个的这个参数分别修改为自己的instance_name,重新启动两个数据库,ok了.
记录之.
Permalink
05.21.07
Posted in David.Guo的心情随笔 at 5:34 pm by David.Guo
最近一直很忙,忙什么,忙换工作呗.
上周2在公司搞定了所有的手续,拿到了离职证明,休息了半天,享受了半天失业的快感,周3就正式报道入职了.
周3的晚上,Gototop从广州过来,刚好是在我入职的第一天.然后和新同事交待了下以后的工作,也第一次见识了新老板雷厉风行的工作作风,不过总体来说,和新同事在一起和融洽,大家虽然才开始共事,可是却感觉是认识很久的朋友.
周四,周五无事,将上百g的数据折腾来折腾去.因为网络和处理方法,耗时还是有点久的,差点没有按时完成任务.真的是郁闷到家.
周末就是ali的网络工程师侠客行大会了,第一天去的太早,老外的发言听不懂,同声翻译的就更听不懂了,唉,真惨.估计是翻译没有IT从业背景的原因吧.而且没有请到Tom Kyte,也就没有多大的兴趣去听的了.由于当天晚上实在拗不过巴乔的邀请,继续打牌,也继续保持了不胜的记录.
周日和那些大师们一起吃饭,我差点迟到了,反正我到的时候,biti,dcba,chao_ping,eygle,piner,wanghai等人都到了,然后大家吃饭,闲聊,下午就是去听那个讲座了.吃饭的时候终于知道了wanghai是抽烟的,终于找到一个抽烟的dba了,不容易呀.
总体来说,新工作压力是大的;eygle说10g是稳定的;biti说选型是困难的;wanghai是抽烟的;chao_ping是不招抽烟的dba的;巴乔的人品是很差的;最重要的是,饭是it168付钱的.
Permalink
05.15.07
Posted in David.Guo的心情随笔 at 4:36 pm by David.Guo
本来准备这里的事情完成后,休息几天再去上班,可惜的是,自己生来就闲不下来,一个人在家觉得特别无聊.刚好,新公司也让我明天去上班.
明天,对我来说,就是新的开始,新的同事,新的工作环境,当然也有新的工作压力.
只是希望,不会让招我进来的老板失望就好!
David,加油!
Permalink
« Previous entries ·