10.08.07
Posted in Oracle管理 at 1:51 pm by David.Guo
本来一直想写这个的,不过最近感觉身体不好,今天才写出来.
10月5日晚上,在客户现场配合业务运行.业务开始后,发现作同样业务的系统,有一个系统十分不正常,速度不如另外一个系统的1/4.客户无法忍受,其实我也无法忍受了,如果照那个速度,我估计要联系工作24小时才可以.
没有办法,对系统进行检查.发现在不正常的系统中,产生了严重的latch free等待.当看到这个的时候,我第一反应是sql语句有问题或者产生了热点,因为应用干的活是在一个表中查询,通过索引查询,但是同时有几十个session作同样的事情.仔细检查了sql语句,语句非常简单.
select user_id,nvl(substr(os_status,:”SYS_B_0”,:”SYS_B_1”),:”SYS_B_2”),nvl(substr(os_status,:”SYS_B_3”,:”SYS_B_4”),:”SYS_B_5”) from table_name where acc_id = :f1
而执行计划走的索引,也是在acc_id上的索引.
经过检查索引和表的状态,发现表基本没有碎片,索引也是被最近被重建过的(后来才发现,问题就出在重建这个索引上,这是后话).
分析系统的latch free的小类，发现系统中，排名最高的几种latch free事件如下：
LATCH# NAME GETS MISSES SLEEPS
row cache objects 7309905930 1076355567 24799351
shared pool 1.2642E+10 168368806 28928269
process allocation 102171945 9233300 29316107
library cache 2.9539E+10 1234502998 87366744
session allocation 3091150764 514908537 244535123
从这个看，sleeps最多的事件是session allocation，并且，该事件的misses/gets超过了10％。
跟踪产生latch free的session，发现根本无法获得trace文件。Session会立刻断开。
分析listener.log，发现网络连接并无问题。经过分析和判断，初步认定该问题应该是由session的不断创建和退出引起，查询v$px_session发现，果然有session不断的在创建和退出。
分析后，我们认为，产生该问题，可能是由于并发查询引起。仔细检查使用的表,发现表的degree为1,并无问题,分析使用到的那个索引,该索引的degree为15. 这就是问题所在了,也是为什么查询中,无法trace session,因为session会立刻断开,到此也明白问题所在了.
因为系统不可能允许我停机修改数据库参数,调整并发查询的参数,因此,只能修改该索引的degree了,将该索引的degree修改为1以后,业务立刻正常.
其实我们也经常听人说,并发开高了不好,会有问题,到底有什么问题,估计也没有多少人真的碰到过.另外,在创建索引的时候,我们都喜欢并发创建,可是创建完成以后,喜欢忘记关闭并行.结果列,给后来人造成麻烦,不是吗?
作DBA,关键是要小心,小心再小心,其实这个问题出现,就是因为在系统作一个大的割接的时候,为了加快重建索引的速度,使用了非常大的并发,结果忘记关闭并行,就在业务繁忙的时候,导致问题出现.
DBA,小心一切操作,充分评估你的操作给后续系统带来的隐患.
最后非常感谢处理这个问题的时候,BITI_RAINY给予的帮助:)
Permalink
07.18.07
Posted in Oracle管理 at 5:02 pm by David.Guo
很久没有写技术帖子了，来一个凑凑数。
昨天晚上，兄弟们干活据说到7点，我是7点30到公司的，准备开始看系统了。
检查了下几个大的应用，基本ok，正在拿喝茶列，开发的老大过来告诉我，应用碰到问题，向一个表中插入记录一直报错。
我开工，sqlplus插入数据到那个表，真的报错，不过有点诡异的错误：ORA-01502 index ‘.’ or partition of such index is in unusable state，这个错误，诡异就诡异在那个单引号中，因为正常情况，这里的.前面应该是对象名，后面是索引名，可是这里，啥都没有。我可以理解为，系统认为，此时发生错误的索引的对象名为空，索引名称也是空。
诡异从此开始了，检查系统使用的表，有PK，可是这个PK对应的索引没有。理论上说，如果有PK，并且PK状态正常，没有disable掉，那么应该是不可能删除索引的。
打电话和正在睡觉的同事确认，他确认，PK的索引是肯定有的，而且他昨天晚上还使用过的。
检查seg$和obj$，前者没有关于PK索引的信息，后者有，我靠。这么说来，系统认为这个PK的索引从来就没有出现过。
没办法，先把应用搞起来，然后来对付这玩意。
drop掉那个没有索引的PK，insert数据，一切正常。
重建PK，正常。（正常是正常，俺的表也就几个亿记录，还是弄了会的）
虽然事情就这么正常了，可是，为什么会有这么诡异的事情，在metalink上也没有查到什么有用的信息。
看来改天我要亲自去灵隐烧香了。
Permalink
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
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
04.27.07
Posted in Oracle管理 at 3:57 pm by David.Guo
今天开发的兄弟发了个据说是能提高在线分析索引的procedure过来.
在生产系统跑了下,rebuild 1kw记录的表的三个索引,用了1s,真快.
可是别高兴的太早,在log中发现数据库中报权限不足.
ok,把那个存储过程中的那个动态sql的语句单独执行,没问题,权限够的.
然后,作个匿名块,只写了那段动态sql,还是可以执行的,就是丢到procedure中不行.怀疑是procedure中执行ddl的语句的权限没有,但是作drop和truncate都行,就是不能执行我这个alter index index_name rebuild online;
我真的要丢他老母了,nnd,看起来权限没有错呀.到网络上去看看,发现说如果是不用online的话,是可以执行的,ok,我试试,不用online确实可以.
后来想想,online和不用online,不就是要创建个系统临时表吗.
给该用户显式授权grant create any table to user;
再执行,好了.
靠,oracle也真土的,我这用户可是dba权限,郁闷死.
Permalink
04.26.07
Posted in Oracle管理 at 2:04 pm by David.Guo
昨天将data gurad实施成功,现在把记录的操作写在下面.
仅供参考,也欢迎下载.
Permalink
04.25.07
Posted in Oracle管理 at 9:26 pm by David.Guo
昨天晚上开始对数据库作rman备份,因为是裸设备,所以非要用rman才可以作data guard,没有想到,居然非常顺利,备份片段240多GB,今天全部搞定.开心
这也是最后一次为现在的公司作的比较大的操作了.明天把实施的详细过程写出来.
Permalink
01.30.07
Posted in Oracle管理 at 12:09 pm by David.Guo
这次来天津,在来之前,出现过一个点的小型机的HA中一个主机宕机,另外一个主机死机的情况.当时没有来人,让现场的兄弟重启了下机器就好了.
最近忙,没去看,昨天发现那个地方居然又宕了备机,我靠,不去还不行了.
去了以后,把备机起来,看备机的日志,日志中显示很多网络离线的信息,也就是说,我的网络不好,但是我的小机是通过一个交换机连起来的,交换机正常,以前网络也都正常的.
到小机后面去看,居然每个网线上都加了个东西,问客户,原来是加了个啥避雷器.
问下加避雷器的时间,终于明白为什么双机会宕机了.当时他们拔了我四个网线装避雷器,HA在丢失网络的情况下,宕机了.
而备机宕机,也是因为网络不稳定,想当年,我在公司测试的时候,只是由于交换机速度达不到就导致双机无法配置.
和客户商量了下,毫不留情的拆除避雷器,系统恢复正常.
另外,那避雷器装的位置也不对,如果真要加,也应该是加在交换机的入口网络上,为什么要加在内部网络的每个网线列,想不通.
注意你的网络,不要随便改动,会导致双机瘫痪的.
真希望下次客户改动任何东西,能先让我们知道.
Permalink
12.25.06
Posted in Oracle管理 at 3:44 pm by David.Guo
今天上班,接到HN地区项目部的电话,说是数据库在进行应用升级后,无法正常启动.现象就是启动了windows中的oracle服务后,数据库无法连接,具体原因不明;
系统环境为,windows 2000+oracle 9iR2 9.2.0.7.0
远程登陆上去,打开数据库,报错,具体为ora-01122,ora-01110,ora-01200,提示为undotbs1的数据文件大小不匹配;
我们的数据库是非归档模式,只能想办法把数据库打开了;
首先,俺启动数据库到mount状态,然后offline drop掉这个数据文件,成功了.
然后打开数据库,再次成功,既然这样,就有办法了.
创建一个新的undo tablespace,然后将系统的undo tablespace切换到新的undo tablespace上,再成功;
在os上删除掉出问题的数据文件,这个时候,系统开始报错了.具体如下:
SMON: about to recover undo segment 6
SMON: mark undo segment 6 as needs recovery
SMON: about to recover undo segment 7
SMON: mark undo segment 7 as needs recovery
SMON: about to recover undo segment 8
SMON: mark undo segment 8 as needs recovery
SMON: about to recover undo segment 9
SMON: mark undo segment 9 as needs recovery
SMON: about to recover undo segment 10
SMON: mark undo segment 10 as needs recovery
SMON: about to recover undo segment 6
SMON: mark undo segment 6 as needs recovery
SMON: about to recover undo segment 7
SMON: mark undo segment 7 as needs recovery
SMON: about to recover undo segment 8
SMON: mark undo segment 8 as needs recovery
SMON: about to recover undo segment 9
SMON: mark undo segment 9 as needs recovery
SMON: about to recover undo segment 10
SMON: mark undo segment 10 as needs recovery
还有和这个相关的就是:
Mon Dec 25 15:04:26 2006
Errors in file d:oracleadminorclbdumporcl_cjq0_2752.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-00376: file 2 cannot be read at this time
ORA-01110: data file 2: ‘D:ORACLEORADATAORCLUNDOTBS01.DBF’
这个时候,在系统中drop undotbs1,报错ora-01548,无法drop该表空间,因为有活动的回滚在上面.
郁闷哟,9i是自动管理回滚段的,在数据库中查,确实有10个回滚段状态为需要恢复,而且这些回滚段的表空间都是undotbs1,没办法了,只能用隐含参数了,在init.ora中增加隐含参数_corrupted_rollback_segments,然后再用pfile启动数据库,再次drop掉表空间undotbs1,成功,然后再用spfile重启数据库,搞定,终于没有错误了.
Permalink
12.08.06
Posted in Oracle管理 at 6:45 pm by David.Guo
这两天在VMWare下安装了Linux AS3使用Oracle 9i安装RAC作测试,终于搞定了,中间碰到很多问题,磁盘共享读写有问题,oracm启动不了以及gsdctl无法启动等等,焦头烂额,整个过程非常艰苦,不过好在坚持下来了.
整个安装文档在这里,要的人可以来下载.
Permalink
« Previous entries · Next entries »